Материал рассчитан на технических специалистов, проектирующих серверные решения для нужд «1С:Предприятие 8» с нагрузкой 25-250 пользователей и более. Рассматриваются вопросы оценки требуемой производительности по компонентам сервера, с учетом экстремальных по загруженности случаев, влияние виртуализации. Вопросы построения отказоустойчивой корпоративной инфраструктуры для крупных предприятий будут рассмотрены в следующем материале.

Оценка требуемой производительности оборудования.

Для подбора оборудования необходима хотя бы предварительная оценка потребности в ресурсах CPU, RAM, дисковой подсистемы и сетевых интерфейсов.
Здесь можно рассматривать два пути:
а) Экспериментальный, который позволяет получить объективные данные о нагрузке на текущее оборудование, и выявить узкие места;
б) Расчетный, который позволяет сделать оценку на основании эмпирически полученных усредненных данных.
Наиболее эффективным является совместное использование обеих методологий.

1. Мониторинг нагрузки, оценка результатов, поиск узких мест и формирование требований

Почему важно проводить анализ нагрузки, если у вас есть уже работающая система?
Тут наиболее корректно будет сравнивать с медициной. Когда пациент приходит к врачу, то вначале проводится осмотр, назначаются анализы, затем оценивается весь комплекс имеющейся информации и назначается лечение. Точно та же ситуация и при проектировании сервера.
Приложив усилия к замерам параметров нагрузки и анализу результатов, в качестве вознаграждения мы получим наилучшее соответствие проектируемого сервера своим задачам. Итоговым результатом станут - существенная экономия, как начальных затрат, так и операционных затрат в дальнейшем.

Оценивать производительность сервера мы будем в рамках основных подсистем: центральных процессоров, оперативной памяти, дисковой подсистемы ввода/вывода и сетевых интерфейсов. В среде Windows существует стандартный инструментарий оценки вычислительной нагрузки Windows Performance Monitor (perfmon). В других системах есть свои аналогичные средства оценки.
В общем и целом нагрузка на каждую подсистему сильно зависит от приложений и типов данных, с которыми они работают. Для блока приложений, связанных с 1С, наиболее критичными являются CPU, RAM, а для SQL-сервера еще и дисковая подсистема. При разнесении на несколько серверов критичным также является сетевой интерфейс. Работать будем только с теми параметрами, которые нам важны с точки зрения прикладной задачи.
Данные для анализа необходимо собирать не менее чем за сутки в типовой рабочий день. Идеально – накопить данные за три типовых рабочих дня. Для поиска узких мест желательно снять данные в день наибольшей нагрузки.
Все описанное ниже пригодится, как на этапе подготовки к проектированию нового сервера (для постановки задачи поставщику), так затем и в процессе эксплуатации, для объективной оценки изменений параметров оборудования и возможного дальнейшего «тюнинга» программно-аппаратного комплекса под «1С:Предприятеи 8» в целом.

CPU. В наибольшей степени нас интересует один параметр – «Processor: % Processor Time» («Процессор: % загруженности процессора»). Microsoft про этот параметр говорит следующее: «Этот счетчик отслеживает время, которое ЦП тратит на выполнение потока во время работы. Постоянный уровень загрузки ЦП в диапазоне от 80 до 90 % может указывать на необходимость обновления ЦП или на необходимость добавления нескольких процессоров». Таким образом, если загрузка CPU в среднем находится на уровне 70-80% - это оптимальное соотношение эффективности использования ресурсов CPU и запаса по производительности на пиковые периоды. Меньше – система недогружена. Более 80% - в зоне риска, 90% - система перегружена, необходимо либо разносить нагрузку на другие хосты, либо переезжать на новый, более производительный сервер.

Анализ CPU. Для современных процессоров в первую очередь имеет смысл выяснить, сколько ядер вам необходимо. Сама Windows довольно эффективно распределяет нагрузку между ядрами, и за исключением редких случаев, когда на уровне ПО есть четкая привязка к ядрам – все ядра процессора будут нагружены более-менее равномерно. В общем случае, если у вас параметр «% загруженности процессора» находится в пределах 50-70% - все хорошо, есть резерв. Если менее 50% - значит в вашей системе уже имеется избыточное количество ядер, их число можно уменьшить, либо загрузить сервер другими задачами. Средняя загрузка 80% и более – вашей системе необходимо большее количество ядер.

RAM. Здесь имеет смысл отслеживать два параметра:
«Memory: Available Mbytes» («Память: Доступно МБ»). В нормально работающей системе значение этого счетчика должно быть не менее 10% от объема физической памяти, установленной в сервере. Если объем доступной памяти слишком мал – система вынуждена будет использовать файл подкачки для активных процессов. Как результат - возникают заметные задержки вплоть до эффекта «зависания» системы.
«Memory: % Committed Bytes In Use», «Память: % использования выделенной памяти». Высокое значение данного счетчика указывает на то, что в системе наблюдается большая нагрузка на оперативную память. Крайне желательно, чтобы данный параметр был ниже 90%, т.к. при 95% появляется вероятность возникновения ошибки OutOfMemory.

Анализ RAM. Ключевым параметром является наличие доступного объема RAM на сервере, что вполне эффективно позволяют мониторить выше приведённые счетчики.

Дисковая подсистема. Очень часто вопросы о быстродействии «1С:Предпряитие 8» связаны с недостаточной производительностью именно дисковой подсистемы. И именно здесь у нас появляются довольно большие возможности по оптимизации оборудования под задачу. Поэтому анализу счетчиков дисковой подсистемы мы уделим максимум внимания.

1. «% Free Space» — процент свободного пространства на логическом диске. Если свободно менее 15% емкости диска, он считается перегруженным, а его дальнейший анализ скорее всего будет не совсем корректным — на него будет сильно влиять фрагментированность данных на диске. Рекомендуемый объем свободного места на серверном диске — не менее 20%, для SSD желательно больше.
2. «Avg. Disk sec/Transfer» — среднее время обращения к диску. Счетчик показывает усредненное время в миллисекундах, требуемое для одной операции обмена данными с диском. Для слабо нагруженных систем (например, файловых хранилищ, хранилищ VM) его значение желательно удерживать в пределах 25 – 30 мс. Для высоконагруженных серверов (SQL) — желательно не превышать 10 мс. Большие значения счетчика говорят о перегрузке дисковой подсистемы. Это интегральный показатель, нуждающийся в более детальном анализе. Какие именно операции, чтения или записи, и в какой пропорции, показывают счетчики Avg. Disk sec/Read (среднее время чтения с диска в секундах) и Avg. Disk sec/Write (среднее время обращения к диску на запись).
   Интегральный показатель Avg. Disk sec/Transfer в RAID5/RAID6 при существенном преобладании операций чтения может быть в пределах нормы, а операции записи будут производиться с существенными задержками.
   3. Avg. Disk Queue Length (средняя длина очереди диска) по сути, является интегральным показателем и состоит из Avg. Disk Read Queue Length (средняя длина очереди к диску на чтение) и Avg. Disk Write Queue Length (средняя длина очереди к диску на запись). Он сообщает, сколько операций ввода/вывода в среднем ожидают, когда жесткий диск станет доступным. Это не измеряемый показатель, а вычисляемый по закону Литтла из теории очередей как N = A * Sr, где N — число ожидающих запросов в системе, A — скорость поступления запросов, Sr — время отклика. Для нормально работающей дисковой подсистемы этот показатель не должен превышать больше чем на 1 количество дисков в RAID-группе. В приложениях класса SQL Server его среднее значение желательно удерживать на уровне менее 0,2.
   4. Current Disk Queue Length (текущая длина очереди диска) показывает число не выполненных и ожидающих обработки запросов, адресованных выбранному диску. Это текущее значение, моментальный показатель, а не среднее значение за интервал времени. Время задержки обработки запросов к дисковой подсистеме пропорционально длине очереди. Для комфортной работы в установившемся режиме количество ожидающих запросов не должно превышать количество физических дисков в массиве более чем в 1,5-2 раза (исходим из того, что в массиве из нескольких дисков каждый диск может одновременно выбирать из очереди по одному запросу).
   5. Disk Transfers/sec (обращений к диску/сек) — количество отдельных дисковых запросов ввода-вывода, завершённых в течение одной секунды. Показывает реальные потребности приложений по случайному чтению и записи к дисковой подсистеме. Как показатель, суммирующий несколько отдельных счетчиков — позволяет быстро оценить общую ситуацию.
   6. Disk Reads/sec — количество обращений чтения в секунду, то есть частота выполнения операций чтения с диска. Важнейший параметр для приложений класса SQL Server, определяющий реальную производительность дисковой подсистемы.
   В нормальном устоявшемся режиме интенсивность обращений не должна превышать физические возможности дисков — их индивидуальным пределам, умноженным на количество дисков в массиве.

- 100-120 IOPS на каждый SATA или NL SAS диск;

- 200-240 IOPS на каждый SAS 15000 rpm диск;

- 65 000 IOPS на каждый диск SSD класса Intel SSD s3500 series (SATA);

- 450 000 IOPS для Intel SSD p3600 series (PCIe).

7. Disk Writes/sec — количество обращений записи в секунду, то есть частота выполнения операций записи на диск. Чрезвычайно важный параметр для приложений класса SQL Server. При работе в нормальном режиме интенсивность обращений не должна превышать физические пределы дисков, умноженные на их количество в массиве и с учетом штрафа на запись для выбранного типа RAID.

- 80-100 IOPS на каждый SATA или NL SAS диск;

- 180-220 IOPS на каждый SAS диск;

- 16 000 IOPS для SSD класса Intel SSD s3500 series (SATA);

- 56 000 IOPS для Intel SSD p3600 series (PCIe).
Для RAID 10 (штраф на запись «2») приведённые выше показатели соответственно делим на 2.

8. Disk Bytes/sec — скорость обмена с диском в байт/сек. Это пропускная способность дисковой системы при выполнении операций чтения и записи. Данный параметр важен для задач потокового чтения/записи и редко бывает критичным для баз данных. Как и Disk Transfers/sec, зависит к физическим возможностям дисков.
9. Disk Read Bytes/sec — скорость чтения с диска в байт/сек. Для правильного расчета предела возможностей дисков в различных вариантах RAID необходимо учитывать те из них, которые выдают информацию (для RAID 6 из 6 дисков — учитываем 4 диска, для RAID 10 из 6 дисков — учитываем 6 дисков, RAID 1 из 2 дисков – учитываем 2 диска).
10. Disk Write Bytes/sec — скорость записи на диск в байт/сек. Учитываются те диски, которые одновременно сохраняют различные данные (для RAID 6 из 6 дисков — учитываем 4 диска, для RAID 10 из 6 дисков — учитываем 3 диска, RAID 1 из 2 дисков – учитываем 2 диска).

Анализ Дисковой подсистемы.
Первым шагом при оценке состояния и потребностей дисковой подсистемы имеет смысл посмотреть счетчик «% Free Space». Если свободного пространства на диске менее 10-15%, весь дальнейший анализ может содержать существенные погрешности, т.к. уже может сказываться фрагментация данных. И чем больше том по объему – тем это более важно. Если же используются SSD, то желательно не превышать их заполнения более чем на 70%.
Второй шаг – оценка латентности дисковой подсистемы на чтение и на запись - Avg. Disk sec/Read и Avg. Disk sec/Write. К примеру, Microsoft для Azure дает предельные значения по данным параметрам для виртуальных сред – до 30 мс. На самом деле для баз данных это очень много. Комфортно себя чувствует тот же SQL при уровне 2-5мс, максимум до 10мс – и по чтению, и по записи. Если же дисковая подсистема показывает пики в сотни миллисекунд, а то и в секунды на этапе стандартной работы (процессы backup не учитываем) – значит она очень жестко перегружена.
Третий шаг по сути, контрольный, оценка счетчика «Avg. Disk Queue Length». Как интегральный показатель, он позволяет сделать быструю оценку, и по счетчикам Avg. Disk Read Queue Length и Avg. Disk Write Queue Length прикинуть, где может быть проблемное место – в чтении или в записи. Для учетных систем узким местом чаще всего является запись.
Четвертый шаг – проверка текущей длины очереди к диску посредством счетчика Current Disk Queue Length. Здесь важно знать, из каких носителей состоит дисковая подсистема – HDD, пользовательские SSD или серверные SSD.
Ключевым при анализе является не среднее или пиковое значение, а форма графика.
Если пики очень узкие, по сути вертикальные линии – значит, дисковая подсистема успешно справляется с задачей. Если же пики выглядят как «треугольники» с плавным нарастанием и плавным снижением – скорее всего, дисковая подсистема перегружена, надо дальше считать исходя из возможностей оборудования (будет показано ниже).
В численном выражении исходим из того, что средний показатель количества ожидающих запросов не должен превышать количество физических дисков в массиве более чем в 1,5-2 раза. Наличие длительных очередей даже в 50-70 запросов могут указывать на недостаточную производительность дисковой подсистемы. При этом узкие (в виде вертикальной линии) пики очереди в 100-200 запросов дисковой подсистемы не есть признак перегрузки, а скорее говорит о ее соответствии задаче и наличии резерва.

Рис. 1 «PerfMon - Current Disk Queue Length»

Пятый шаг – оценка общего количества обращений к дисковой подсистеме по счетчику Disk Transfers/sec и принципиальной способности это количество обращений обработать. Это важно для дисковых подсистем на даже дисков HDD, т.к. каждый HDD на 7200 prm способен выдать 100-120 IOPS, а на 10 000 – 15 000 prm – 200-240 IOPS. Понятно, что если у вас в RAID 10 находится 6 дисков HDD 15 000 prm, то даже теоретически на длительных нагрузках они не смогут выдать более чем 6 x 240 = 1440 IOPS на чтение и 1440/2 = 720 IOPS на запись.
Для современных серверных SSD данный параметр в RAID 10 мало актуален виду высоких стартовых показателей (самый «слабый» Intel SSD s3520 выдает на запись 16 000 IOPS, остальные выше). При сборе RAID5 или RAID6 из 6-8 серверных SSD данный параметр уже может иметь значения и должен учитываться (хотя такие варианты RAID для размещения баз данных SQL и не рекомендуются).
Шестой шаг – оценка достаточности производительности в IOPS на чтение по счетчику Disk Reads/sec. Для дисковых подсистем на HDD это может быть узким местом ввиду технологических ограничений по IOPS. Как только дисковая подсистема будет не справляться к приходящими запросами – мы тут же получим рост очереди к диску Current Disk Queue Length и рост латентности по чтению Avg. Disk sec/Read. При длительной перегрузке дисковая подсистема выходит на «полочку», и держится на ней.
Если вышли на «полочку», и счетчики Current Disk Queue Length и Avg. Disk sec/Read находятся в норме – значит это предел потребности ПО к дисковой подсистеме, можем смело его вписывать в требования к новому серверу (естественно, с резервом).
Если же вышил на полочку и счетчики Current Disk Queue Length и Avg. Disk sec/Read находятся вне нормы (большая «пологая» очередь, отклик более 30 мс) – система перегружена, и потребности ПО к ней могут быть в 3-10 раз выше имеющихся ресурсов. В таком случае оптимальной стратегией будет взять у поставщика оборудования дисковую подсистему на условиях ”Try&Buy” и выяснить реальные потребности. Либо же понадеяться на эмпирические расчеты, для начала умножив текущую нагрузку минимум на 3.
Еще одним неприятным моментом при перегрузке дисковой подсистемы могут быть неверные показания загрузки CPU – мы видим загрузку, а на самом деле CPU находится в ожидании ответа от дисковой подсистемы. Это необходимо учесть, и заново снять нагрузку на CPU после установки более производительной дисковой подсистемы – нагрузка может как уменьшиться, так и возрасти.
Для дисковых подсистем на базе серверных SSD ситуации перегрузки по чтению встречаются крайне редко, т.к. возможности на чтение у них стартуют от 50 000 - 60 000 IOPS.
Седьмой шаг - оценка достаточности производительности в IOPS на запись по счетчику Disk Writes/sec. Это самый важный показатель для серверов под базы данных, т.к. его образной стороной является латентность дисковой подсистемы Avg. Disk sec/Write (и рост очереди к диску Current Disk Queue Length), при чрезмерном росте латентности на запись легко получить блокировку транзакций.
Здесь все так же, как и в предыдущем пункте, и точно так же в наибольшей зоне риска дисковые подсистемы на HDD.
При длительной перегрузке дисковая подсистема может выходить на «полочку», и держаться на ней.
Если вышли на «полочку», и счетчики Current Disk Queue Length и Avg. Disk sec/ Write находятся в норме – значит это предел потребности ПО к дисковой подсистеме, все хорошо.
Если же вышли на полочку, и счетчики Current Disk Queue Length и Avg. Disk sec/ Write находятся вне нормы (большая «пологая» очередь, отклик более 30 мс) – здесь также оптимальной стратегией будет взять у поставщика оборудования дисковую подсистему на условиях ”Try&Buy” и выяснить реальные потребности в производительности на запись. Либо же понадеяться на эмпирические расчеты, для начала умножив текущую нагрузку минимум на 3-5.
Если говорить в цифрах, то для БД «1С:Предпритие 8» на 100-200 одновременных пользователей нагрузка на запись редко превышает 1500–3500 IOPS. В то же время на этапах автоматического обмена данными или в процессе сложных обработок может достигать и 12 000–16 000 IOPS на запись (больше автор не встречал пока). Как не сложно заметить, таким потребностям вполне соответствуют практически все серверные SSD, независимо от типа интерфейса.
Восьмой шаг имеет скорее контрольные функции, и оценивает показания счетчиков Disk Read Bytes/sec и Disk Write Bytes/sec. Т.к. у нас идет работа с базами данных, то мы имеем большое количество маленьких запросов, т.е. критичным параметром будет IOPS. IOPS и пропускная способность измеряют разные аспекты производительности дисковой подсистемы.
Приложение, выполняющее большое число небольших дисковых операций, скорее всего, никогда не упрется в лимит по пропускной способности.
Пропускная способность может быть важна в 2-х случаях – в аналитических системах, обрабатывающих большие объемы данных, и при создании backup. Здесь риски если и есть, то только в дисковых подсистемах с HDD, где она стартует с 100 MBp/s. Даже для младшего SSD класса Intel SSD s3500 series пропускная способность превышает 300 MBp/s, в старших моделях доходя до 2800 MBp/s.
Задача для новой дисковой подсистемы – обеспечить показания не меньше, чем требуется в моменты пиковых нагрузок.

Сетевой интерфейс. Ввиду того, что мы говорим об одиночном сервере под нужды «1С:Предприятие 8», либо о группе серверов под те же задачи – сетевой интерес в подавляющем большинстве случаев не является узким местом при соблюдении набора простых правил. Потому снимать показания счетчиков и анализировать необходимости зачастую нет.

Результаты мониторинга и оценки производительности.

Что же мы получаем в финале?
1. По сути, получены объективные «Технические требования», которые смело можно транслировать в «Техническое задание».
- По CPU общая нагрузка определяет количество ядер, а наиболее требовательные к времени выполнения процессы – частоту процессора;
- Четко определена потребность в объеме RAM, что позволяет оптимально подобрать модули памяти;
- Определены численные значения по емкости и скоростным параметрам требования к дисковой подсистеме в формате:
а) емкости в GB или TB,
б) производительности при записи и чтении в IOPS,
в) пропускная способность в MBp/s.
Плюс контрольные точки в виде латентности системы при записи и чтении данных.
Добавив к имеющейся нагрузке еще и расчетную величину с учетом прироста на 1-2-3 года (у кого какая глубина планирования), по сути, получаем практически исчерпывающие требования к серверному обрудованию.
Почему это важно?
Такой набор требований позволяет с одной стороны, не приобрести сервер с заведомо недостаточными параметрами. Либо же делать это сознательно. А также на уровне проектирования , исключить неподходящие серверные компоненты. С другой стороны – точные данные позволяют избежать трат на ресурсы, которые в данной задаче не востребованы.
К примеру, зачем покупать 14-ти ядерные процессоры, если достаточно 8-ми ядерных? Да которые еще можно взять и более высокочастотные. Или зачем ставить 6 шт. SSD там, где достаточно 4 шт.?
Причем, результаты мониторинга позволяют IT-специалисту обосновать Техническое задание и перед собственным руководством, и перед потенциальным поставщиком. А в случае несоответствия поставленного оборудования Техническому заданию – требовать его замены или возврата средств.

2. Данные мониторинга являются основой для отслеживания в дальнейшем изменения нагрузки на оборудование, что позволит IT-службе избежать необоснованных претензий и по простою, и по недостаточной производительности оборудования.

3. Отдельно необходимо выделить «экстремальные» случаи.
Допустим, у вас есть сеть из 20 крупных филиалов по 100-500 пользователей или сеть в 2000 аптек, и каждые сутки должен быть полный обмен данными через центральный сервер. Для такого сервера критическим вопросом будет скорость загрузки данных из периферийных БД и выгрузки обменов для них. И обычно на это дается ночь. Если не успел – значит на следующий раз придётся выгружать данные, накопленные уже за 2 дня…
Вот здесь и начинаются игры с высокочастотными процессорами, с NVMe SSD на шине PCI Express с латентностью в 25 мкс (вместо 55-75 мкс у SAS/SATA SSD), подбор модулей RAM с наименьшей латентностью и установка всего по одному модулю на каждый канал памяти, и еще целый ряд программных ухищрений вроде использования RAMDrive.
Без объективных данных по реальной нагрузке подобный тюнинг невозможен или просто оборудование покупается по принципу «всё по максимуму» без оглядки на бюджет.

Еще раз подчеркнем, что только результаты мониторинга с последующим анализом на выявление «узких мест», плюс планирование нагрузки позволяют выработать оптимальное Техническое задание. И в результате получить сервер (или набор серверов), максимально оптимизированный под задачу, а значит обеспечивающий наилучшее соотношение цена/производительность.

1. Типовой расчет нагрузки на сервер под нужды «1С:Предриятие 8»

Необходимость приблизительно оценить потребности в вычислительных мощностях возникает всегда при новых внедрениях, когда базы данных еще нет, и провести измерения невозможно.
Также не лишним будет провести «теоретический» расчет в дополнение к результатам описанного мониторинга – это позволит лучше спрогнозировать поведение системы при росте нагрузки, а также учесть факторы, не подлежащие прямому измерению. Например, переход с доступа по ЛВС с «толстого» клиента к новой версии конфигурации под «Управляемыми формами» и с доступом через «тонкий» клиент или Web.
Данный расчет применим как для подбора физического оборудования, так и для просчета требований к виртуальной среде.

Для начала определим программные компоненты, которые мы будем принимать в расчет:
- Операционная система (OS);
- Сервер баз данных, в нашем случае MS SQL Server;
- Серверная часть «1С:Предприятие 8. Сервер приложений»;
- работа пользователей в режиме «Удалённого рабочего стола» (RDP);
- прочие приложения в режиме «Удалённого рабочего стола» (MS Office – Excel, Word, Outlook и т.д.);
- работа удаленных пользователей посредством «тонкого клиента» или Web-доступа.

Далее оценим потребности в CPU, RAM и дисковой подсистеме каждого из них.
Расчет вначале будем вести в «логических» ядрах CPU, объеме RAM в МБ, а также в ориентировочных требованиях к дисковой подсистеме.

1. Операционная система. Под нужды OS, как правило, достаточно зарезервировать 1-2 ядра CPU, не менее 4GB RAM, и порядка 120 GB дискового пространства, по возможности на томе с кэшированием или тирингом, а идеально – на дисковом томе на SSD. При этом больших нагрузок на дисковую подсистему сама OS в штатном режиме не создает, за исключением непрерывных мелких «дерганий» системного диска.
2. Сервер баз данных. Мы будем рассматривать MS SQL Server как наиболее часто используемый, но принципы расчёта сохраняются и для других SQL Server.
По CPU исходим из расчета 1 ядро на 20-25 пользователей «1С:Предприятие 8» вне зависимости от варианта доступа. Таким образом, разделив общее количество одновременных пользователей на 20 (для «тяжёлых» конфигураций вроде УПП) или на 25 – получаем потребность в ядрах CPU под нужды SQL Server. Для 250 пользователей это 10-12 логических ядер.
Для расчета потребности в RAM можно использовать две методики. Обе они сводятся к цели разместить как можно большую часть «горячих» данных в SQL RAM Cache.
Первая опирается на объем таблиц базы данных, или общий объем таблиц всех баз данных (если баз несколько). Она хорошо применима для небольших и средних по объему баз данных, или с глубиной до 5 лет. Для комфортной работы пользователей как минимум необходимо разместить в SQL RAM Cache 20-30% объема таблиц базы данных (DB). Если баз данных несколько – то 20-30% от объема таблиц данных каждой из баз данных. Таким образом для БД объемом в 60 GB под SQL RAM Cache надо выделить 12-18 GB RAM.
Второй вариант, как критерий расчета потребностей RAM на SQL RAM Cache, берет объем данных за 1 год (последний год). Этот вариант часто применяется для очень больших и многолетних баз данных. Таким образом для БД объемом в 60 GB за 5 лет под SQL RAM Cache надо выделить 12-15 GB RAM.
Обычно обе методики дают близкие результаты расчета.
Если у организаций база данных 1С не слишком большая, то идеально в SQL RAM Cache поместить всю базу данных, т.е. 100% объема таблиц базы данных.
Минимальный объем, выделяемый под SQL RAM Cache – от 2 GB RAM.
Дисковая подсистема.
Для систем под MS SQL Server необходимо хранить 3 типа данных:
– таблицы с данными DB,
– временные таблицы tempDB,
– лог-файлы SQL log.
Вначале давайте разберемся с размещением этих данных.
Исходя из соображений безопасности хранения данных, DB и SQL log желательно разместить на различных физических дисках. Причем на разных именно физических устройствах, а не логических томах.
Размещать оба эти типа данных следует на дисковых подсистемах с минимальной латентностью. Типичной ошибкой является размещение DB на быстрых SSD, а SQL log, исходя из того, что это линейная запись – на HDD без кэширующего на запись RAID-контроллера. В виду того, что транзакция в SQL считается завершённой после записи данных и в таблицы DB, и в лог-файл SQL log, даже при очень быстром томе для DB узким местом по скорости записи может оказаться том с SQL log.
Отдельный разговор про tempDB. Технологически, если он небольшой и не нагружен – его вполне можно разместить на том же томе, что и DB. А вот для нагруженных систем с большим количеством транзакций в автоматическом режиме (те же ситуации обмена с периферийными базами данных), либо мощные расчетные нагрузки (производство, логистика) – tempDB желательно выносить на отдельный том, на других физических носителях. Это связано с тем, что во время интенсивной работы с tempDB, например записью, как правило противоположная интенсивная нагрузка в виде чтения ложится на таблицы DB. И тут вступает в игру малоизвестный фактор резкого падения производительности при одновременной смешанной нагрузке при чтении и записи. Причем падение наблюдается в меньшей степени у HDD (10-20%), и в большей степени для SSD (до 50%). Наглядно это видно на графике ниже, приведенном для блока 64 KB (с которым работает MS SQL Server с дисковой подсистемой) для трех SSD дисков Intel s3700 series, Intel s3610 series и Intel s3710 series с изменением соотношения R/W от 100%/0% до 0%/100% с шагом 10%.

Рис. 2 – Измерение производительности SSD в IOPS в зависимости от соотношения R/W

Конкретные цифры в графике не имеют критического значения, в данном случае важна тенденция снижения производительности в IOPS почти на 50% при соотношении R/W как 50%/50%.
Естественно, наблюдаем и соответствующее увеличение латентности у диска.

Рис. 3 – Измерение латентности SSD в зависимости от соотношения R/W

Из приведенных графиков несложно сделать вывод, что в «экстремальных» случаях, когда требуется минимальное время выполнения сложных операций – таблицы DB и tempDB имеет смысл разнести на разные физические устройства. Если же производительности имеющихся дисков хватает с запасом – вполне можно разместить DB и tempDB на одном и том же носителе, тем самым сэкономив бюджет.
В самых сложных случаях вполне можно разместить tempDB на виртуальном диске, сформированном в RAM сервера – так называемом RAMDrive. Это дороже SSD и не всегда удобно, но зато обеспечивает предельно возможную производительность для tempDB.
Далее давайте разберемся с ёмкостью томов под данные.
Здесь необходимо точно знать текущий объем всех данных и средний прирост за период. И далее рассчитать так, чтобы на каждом из томов через 3 года эксплуатации оставалось не менее 20-30% свободного пространства. Либо же выбирать дисковую подсистему с хорошим запасом.
Для вновь создаваемых баз данных абсолютно необходимо рассчитать (а лучше еще и уточнить путем эксперимента) объем таблиц DB на начало старта и планируемый прирост объема за период.
Отдельно проговорим по резерву пространства для лог-файла SQL log. Как правило, это файл, который по окончании периода можно безболезненно архивировать (он сжимается приблизительно до 8-12 % начальной ёмкости), и даже переместить на другой носитель. Потому делать расчет ёмкости под SQL log на все 3 года вперед нет необходимости – вполне достаточно резерва на 4-6 месяцев плюс прописанные и автоматизированные процедуры по его архивированию.
Следующий параметр, который нуждается в расчете – это потребность в IOPS.
Здесь разброс параметров может быть очень большим, и многое зависит от того, какой процент «горячих» данных находится в SQL RAM Cache. Но для расчетов можно грубо взять потребность в 10-20 IOPS по записи и 30-60 IOPS по чтению на каждого отдельного пользователя «1С:Предприятие 8». Таким образом, к примеру, для 250 пользователей «1С:Предприятие 8» потребуется 2500 – 5000 IOPS на запись и 7500-15000 IOPS на чтение. При этом совсем не факт, что вся эта нагрузка будет постоянно приходиться на дисковую подсистему – при грамотно подобранном объеме SQL RAM Cache большая часть запросов на чтение будет отрабатываться именно им.
Особняком идут различные модули автоматизации – обмен с другими БД, массовые выгрузки, восстановления последовательности и перепроведения. Они обычно создают пиковую нагрузку порядка 1500-6500 IOPS на запись и где-то в два раза больше на чтение. Почти без зависимости от количества пользователей и объема базы данных.
Если задачи автоматизации не являются критичными по времени – то смотрим на показатели младшей модели серверных SSD Intel SSD s3500, которая обеспечивает 16000 IOPS при записи и 65 000 IOPS при чтении и мирно ставим два или четыре таких диска в RAID. Для критичных случаев – смело устанавливаем NVMe SSD класса Intel SSD p3600 или выше.
Относительно же потоковой нагрузки в MBp/s на чтение и запись в современных дисковых подсистемах на основе SSD можно не переживать – её, как правило, вполне достаточно даже с двумя SSD в RAID1.

3. Серверная часть «1С:Предприятие 8. Сервер приложений».
По ресурсам CPU считаем одно ядро под нужды «1С:Предприятие 8. Сервер приложений х64» (процесс rphost) на 15-25 пользователей. Больше пользователей – больше процессов rphost, больше ядер. Таким образом, разделив общее количество одновременных пользователей на 15 (для «тяжёлых» конфигураций вроде УПП, или доступ через Web/«тонкий клиент») или на 25 – получаем потребность в ядрах CPU под нужды SQL Server. Таким образом, для «тяжелых» случаев для 250 пользователей может потребоваться 16-17 потоков rphost и соответственно 16-17 ядер, или же порядка 10 потоков rphost и ядер для «легких» ситуаций.
RAM рассчитывается исходя из количества запущенных процессов rphost, где-то по 1GB на каждый процесс rphost. Данный параметр – эмпирический, поток rphost вполне может потреблять и 400 MB, и 2,5 GB. Тем не менее наиболее эффективно «1С:Предприятие 8. Сервер приложений х64» работает при распределении 0,8-1,2 GB на каждый процесс rphost. Таким образом, для «тяжелых» случаев для 250 пользователей может потребоваться 16-17 потоков rphost и соответственно 16-17 GB RAM, или же порядка 10 GB RAM для «легких» ситуаций.
Хотелось бы отдельно выделать ситуацию, когда доступ к базе данных осуществляется посредством «тонкого» клиента или Web-доступа. В таком режиме существенная часть нагрузки переходит от «толстого» клиента к «Серверу приложений», тем самым повышая требования к нему на 50-100%. Что и отражено в расчетах выше.
Каких-то особых требований к дисковой подсистеме «1С:Предприятие 8. Сервер приложений х64» не предъявляет. Для своих операций используя с низкой интенсивностью системный диск.

5. Работа пользователей в режиме «Удалённого рабочего стола» (RDP).
В таком варианте по CPU резервируем одно логическое ядро на 8-12 терминальных пользователей. Таким образом, на 250 пользователей Remote Desktop требуется 21-31 процессорное ядро.
RAM рассчитывается исходя из типа клиента и типа конфигурации. Для «тонкого» клиента это 120-150 MB RAM, для «толстого» клиента от 250 MB RAM для конфигурации «Бухгалтерский учет» до порядка 400 MB RAM для «УТП» на каждого пользователя. Тут наиболее верный способ – уточнить по уже использующейся вашей конфигурации после как минимум двух часов обычной работы пользователя. В среднем же требуется на 250 пользователей порядка 30-38 GB RAM для «тонкого» клиента и 62-100 GB RAM для различных конфигурации, работающих под «толстым» клиентом.
Особых требований к дисковой подсистеме нет, может использоваться системный диск и личные папки пользователей.

6. Прочие приложения в режиме «Удалённого рабочего стола»
Чаще всего среди приложений MS Office при работе через Remote Desktop используется MS Excel. Для систем документооборота – MS Word. Также встречаются среды, где конечные пользователи используют «Тонкие клиенты» для доступа в корпоративную среду, применяя в терминале и MS Outlook, и Internet Explorer (или другой браузер). В таком случае необходимо учесть и их потребности.
CPU. Здесь всё просто – ресурсы CPU уже посчитаны выше в п.5 для пользователей 1С. От количества запущенных пользователем приложений, в которых он осуществляет ввод данных или их просмотр нагрузка сильно не меняется, т.к. ограничивающим фактором является человек. Исключение – Интернет-браузер, в котором может быть запущено что угодно, даже игровые приложения – но мы такие случаи не учитываем и исходим из того, что браузер используется изредка для доступа к преимущественно текстовым данным, а не медиа.
RAM потребуется посчитать для каждого пользователя в разрезе приложений отдельно. В среднем MS Word и MS Excel потребляют порядка 100 MB RAM, а MS Outlook и Internet Explorer порядка 150 MB RAM на каждый запущенный экземпляр. Как пример, если из 250 пользователей 50 регулярно использует MS Word и MS Excel, то потребуется дополнительно (100+100)*50 = 10 GB RAM.
Требования к дисковой подсистеме обычно незначительны, если не используется MS Outlook и Internet Explorer.

7. Работа удаленных пользователей посредством «тонкого» клиента или Web-доступа.
Ресурсы, необходимые для «тонкого» клиента или Web-доступа на стороне «1С:Предприятие 8. Сервер приложений» мы уже посчитали выше. Необходимо учесть только IIS или другой Web-сервер для Web-доступа. Здесь очень сложно прогнозировать, т.к. нагрузка на Web-сервер сильно зависит и от используемой конфигурации, и от выполняемых задач, но в среднем она небольшая даже для Web-сервера на 250 пользователями 1С.
По загрузке CPU считаем одно ядро на 30-50 пользователей. RAM необходимо выделить стартовые 4 GB RAM и далее добавляем по 1 GB RAM на каждые 50 пользователей. При таких расчетах Web-сервер под нужды «1С:Предпряитие 8» для Web-доступа 100 пользователей потребует порядка 2-3 ядер CPU и 4-6 GB RAM. Потребности дисковой подсистемы – незначительны.

Примеры расчетов.
В качестве итогового примера мы посчитаем различные сценарии для сервера на 250 пользователей в разных вариантах доступа и с «опциями». Для простоты будем считать, что используем конфигурацию «Бухгалтерский учет», объем DB - 60 GB, tempDB - 4 GB, SQL log - 6 GB.
а) Все 250 пользователей работают по ЛВС через «толстый» клиент.
CPU: 2 ядра на OS, 12 ядер на MS SQL, 10 ядер на «1С Сервер приложений» - итого 24 логических ядра.
RAM: 4 GB на OS, 18 GB на MS SQL, 10 GB на «1С Сервер приложений» - итого 32 GB RAM.
Дисковая подсистема: 2 х SSD 240 GB RAID1 для DB и tempDB, 2 х SSD 240 GB RAID1 для OS и SQL log, 2500 – 5000 IOPS на запись и 7500-15000 IOPS на чтение для тома DB.
б) Все 250 пользователей работают через «тонкий» клиент в режиме «Удалённого рабочего стола».
CPU: 2 ядра на OS, 12 ядер на MS SQL, 17 ядер на «1С Сервер приложений», 21 ядро для Remote Desktop - итого 56 логических ядра.
RAM: 4 GB на OS, 18 GB на MS SQL, 17 GB на «1С Сервер приложений», 38 GB для Remote Desktop - итого 77 GB RAM.
Дисковая подсистема: та же.
в) Все 250 пользователей работают через Web-клиент.
CPU: 2 ядра на OS, 12 ядер на MS SQL, 17 ядер на «1С Сервер приложений», 5 ядер для IIS - итого 36 логических ядра.
RAM: 4 GB на OS, 18 GB на MS SQL, 17 GB на «1С Сервер приложений», 8 GB для IIS - итого 37 GB RAM.
Дисковая подсистема: та же.
г) Все 250 пользователей работают через «толстый» клиент в режиме «Удалённого рабочего стола», 50 пользователей используют MS Word и MS Excel.
CPU: 2 ядра на OS, 12 ядер на MS SQL, 10 ядер на «1С Сервер приложений», 31 ядро для Remote Desktop - итого 66 логических ядра.
RAM: 4 GB на OS, 18 GB на MS SQL, 10 GB на «1С Сервер приложений», 62 GB для Remote Desktop, 10 GB для MS Word и MS Excel - итого 104 GB RAM.
Дисковая подсистема: та же.

Как видим, ничего сложного в расчетах нет, обычная арифметика.
Зато, как и в разделе по Мониторингу нагрузки, при наличии исходных данных позволяет быстро сформировать минимальные Технические требования к оборудованию или виртуальной среде.

1. Нюансы подбора оборудования и обход «узких мест».

CPU. В первую очередь напомним, что средняя загрузка CPU не должна превышать 80%.
Все расчёты по ядрам выше приведены в «логических ядрах CPU», где одно логическое ядро соответствует на физическом сервере одному ядру в «Диспетчере задач» при включенном Hyper-Threading (т.е. каждое физическое ядро процессора представлено как два логических). Это удобно, и соответствует наиболее часто применяемому варианту использования процессоров – с включенным HT.
Суть технологии Intel® Hyper-Threading сводится к тому, что на один вычислительный модуль ядра процессора приходится два блока дешифрации команд. И для OS это представляется как два отдельных логических ядра процессора.
Такая схема вполне оправдана для хорошо распараллеливаемых задач, т.к. в очень многих случаях на дешифрацию команд у процессора уходит в 1,5-2 раза больше процессорных тактов, чем на их исполнение (это касается в первую очередь логических операций, целочисленных вычислений и вычислений с плавающей запятой невысокой точности – что чаще всего и востребовано в учетных системах). Сказать на 100%, что технология Hyper-Threading всегда дает прирост – нельзя. К примеру, в научных вычислениях она скорее снижает производительность. А вот для SQL, и для «1С:Предпряите 8», она чаще всего оказывается полезной – при средней загрузке CPU она дает прирост производительности, причем в зависимости от задачи до 25-40%. Если нагрузка на CPU превышает 80%, Hyper-Threading, как правило, лучше отключить.
Здесь, еще раз подчеркну, необходим именно эксперимент на рабочей системе в виде наблюдения за загрузкой процессора и за «удовлетворенностью пользователей» хотя бы на промежутке 3-5 дней.

При выборе процессора важно учитывать не только количество ядер, но и рабочую частоту процессора в стандартном режиме. В виду того, что «1С:Предприятие 8» по-прежнему весьма чувствительно относится к частоте процессора. Особенно важно иметь высокочастотный процессор, если «узким местом» является какая-либо нагрузка, связанная с массовым обменом данными или массовой обработкой объектов – к примеру, обмен данными между центральной и периферийными БД 1С, либо обмены с другими системами, либо перерповедение за период. Как правило, такая нагрузка создаёт практически однопоточную нагрузку на каждый из компонентов (клиентская часть «1С:Предприятие 8», «1С :Сервер приложений», SQL Server), и время выполнения такой операции будет напрямую зависеть от частоты процессоров.
Относительно технологии Intel® Turbo Boost Technology. В ситуациях, когда в 1С работает всего один поток (обмен данными, перерповедение документов или сложный отчет) она позволяет поднять производительность одного ядра на 15-30%, а то и больше. Что, соответственно, может очень положительно сказываться на времени выполнения операции. Но в реальности в серверном чипе, работающем в рамках термопакета, частота поднимается на краткий промежуток времени, в среднем на 30-90 сек, а затем снижается до штатной (в связи с нагревом процессора). Таким образом выигрыш – очень краткосрочный. Более того, на переключение частоты также тратится до сотни тактов процессора. Потому сама по себе технология не является лишней, но при выборе процессора необходимо ориентироваться именно на его штатную частоту.

Важной причиной, по которой при прочих равных следует выбирать процессор с более высокой тактовой частотой – это его характеристики работы с памятью. Чем более высокочастотный процессор – тем с большими частотами памяти он работает, а значит меньше латентность всей системы. Для сравнения ниже в таблице приведены данные двух процессоров.

Табл.1 – Параметры работы с RAM

RAM. На быстродействие всего сервера будет влиять тип установленной памяти. К примеру, LR DIMM в силу своей архитектуры всегда будет иметь большую латентность, чем обычная память RDIMM DDR4. Особенно на относительно коротких запросах, типичных для SQL при работе с 1С. Исходя из большей латентности и существенно более высокой цены, LR DIMM имеет смысл устанавливать только, если нет возможности набрать необходимый объем RAM за счет RDIMM.
Точно так же DDR4 2400 будет работать чуть быстрее, чем DDR4 2133 - если высокие частоты поддерживает CPU.

Сетевой интерфейс. Здесь желательно придерживаться простых правил:
а) На сервере должны быть минимум три сетевых интерфейса 1Gb Ethernet или выше (10Gb, 40Gb), и не менее двух из них на серверных сетевых чипах. Безусловно, при прочих равных следует отдать преимущество 10Gb Ethernet инфраструктуре, особенно с учетом исчезающей малой разницы в цене оборудования (сетевых карт 10Gb и портов 10Gb на коммутаторах 1GB/10Gb).
б) Сервер должен поддерживать ту или иную технологию KVM-over-IP для удалённого управления.
Из тонкостей можно выделить очень хорошую поддержку всеми серверными сетевыми чипами Intel инструментов виртуализации и умение эффективно распределять нагрузку между ядрами CPU для 10Gb+.

Дисковая подсистема:

Дисковая подсистема состоит из двух компонентов:
- подсистема ввода/вывода в виде контроллеров SAS HBA и RAID-контроллеров;
- устройства хранения данных, или в нашем случае – дисков SSD и HDD.

RAID.
Для задач хранения OS и баз данных, как правило, используется RAID 1 или RAID 10, а также их различные программные аналоги.

1. Полностью программный RAID (Soft RAID) средствами Windows Server не может использоваться для загрузочного диска, зато вполне походит для хранения DB, tempDB и SQL log. Технология Windows Storage Spaces обеспечивает достаточно высокие показатели по надежности хранения и по быстродействию, а также предлагает целый ряд дополнительных функций, самой интересной из которых примирительно к задачам 1С является «Многоуровневое хранение» (tiered storage). Преимущество данной технологии в том, что часть наиболее часто запрашиваемых данных система автоматически размещается на SSD.
Применительно к задачам 1С обычно используют или All-Flash массив из SSD, или для очень больших по объёму (1TB и выше) и многолетних баз данных – Многоуровневое хранение.
Одно из преимуществ технологии Windows Storage Spaces – ее способность создать RAID на дисках NVMe.

2. Для размещения OS эффективен аппаратно-программный RAID1, построенный на основе чипсета от Intel и технологии Intel® Rapid Storage Technology (Intel RST).
В нем операции по вводу-выводу на аппаратном уровне выполняет чипсет материнской платы, практически не задействуя ресурсы CPU. А управление массивом осуществляется на программном уровне, за счет драйверов под Windows.
Как любое компромиссное решение, у Intel RST есть некоторое недостатки.
а) Работа Intel RST зависит от драйверов, загружаемых в операционную систему. И это несет некоторый потенциальный риск, что при обновлении драйверов или OS может возникнуть ситуация, что диск RAID будет недоступен. Она чрезвычайно маловероятна, т.к. компании Intel и Microsoft весьма дружны и очень качественно тестируют свое ПО, но не исключена.
б) Исходя из результатов экспериментов, по косвенным признакам можно предположить, что драйверная модель Intel RST для кэширования на запись использует ресурсы RAM. Это дает прирост производительности, но при этом несет некоторые риски потери данных при незапланированном отключении электропитания сервера.
Есть у данного решения и преимущества.
Одно из них – всегда очень высокая производительность, находящаяся на уровне, а иногда и выше чем у полностью аппаратных RAID-контролеров.
Второе – поддержка аппаратно-программного RAID1 для дисков NVMe (на момент написания материала – не для загрузочных дисков). И вот здесь кроется интересная особенность для тех, у кого используются высоконагруженные дисковые подсистемы. В отличие от Windows Storage Spaces, которая «догружает» занятое вводом/выводом ядро практически до 100%, Intel RST при достижении приблизительно 70% загрузки ядра подключает к процессу ввода/вывода следующее ядро. Как результат – более равномерная нагрузка на ядра CPU и чуть большая производительность при высоких нагрузках.

Рис 4 – Утилизация CPU Windows Storage Spaces vs. Intel RST

3. Полностью аппаратный RAID в сервере с 2-6 SSD в RAID 1 вполне можно получить за счет SAS HBA на чипсете LSI SAS 3008, например, на Intel® RAID Controller RS3WC080. Для этого в SAS HBA устанавливается специальная “IR”-прошивка. Причем данный SAS HBA поддерживает стандарт SAS 3.0 (12 Gb/s), при цене около $300. Отличным выбором тут будет Intel® RAID Controller RS3WC080, который идет сразу с необходимой прошивкой.
Суть этого решения в том, что серверным SSD не нужен кэш на запись. Более того, более продвинутые RAID-контроллеры также отключают свой встроенный кэш на запись при работе с SSD. Таким образом, не имеющий кэша SAS HBA в режиме RAID-контроллера вполне успешно справляется с задачами скоростной записи и чтения напрямую с SSD, обеспечивая вполне пристойную производительность.

4. Для высоконагруженных серверов с большим количество дисков SSD SAS или SATA желательно установить полноценный RAID-контроллер класса Intel® RAID Controller RS3MC044 или Adaptec RAID 8805. Они обладают более производительными процессорами ввода/вывода и продвинутыми алгоритмами для работы с дисками HDD и SSD, в том числе позволяющими ускорить сборку массива после замены вышедшего из строя диска.

Устройства хранения данных (SSD и HDD).
а) Надежность SSD и HDD.
Обычно теоретическою надежность дисков оценивают по параметру «Non-recoverable Read Errors per Bits Read», что можно перевести как «Вероятность появления невосстановимой ошибки чтения на количество считанных бит». Он показывает, после чтения какого объема данных с диска, согласно статистике, следует ожидать появления невосстановимой ошибки.
Еще один важный параметр показывает вероятность отказа диска – AFR (annual failure rate), или «Годовая интенсивность отказов».
Далее в таблице приведены данные для типовых дисков SATA Enterprise HDD 7200 prm (SATA Raid Edition), SAS HDD Enterprise 15 000 prm, SATA SSD Enterprise.

Таб. 2 – теоретическая надежность HDD и SSD

Вероятности появления невосстановимых ошибок у Enterprise SATA SSD класса Intel® SSD DC S3510 Series, в 10 раз ниже, чем у SAS HDD Enterprise 15 000 prm, и в 100 раз ниже, чем у SATA Enterprise HDD 7200 prm. Таким образом, SSD Enterprise-класса теоретически и более надежны, чем любые HDD.

б) Далее оценим производительность SSD и HDD.
С точки зрения базы данных, которой, по сути, является 1С, наиболее важными являются всего три параметра диска:
– латентность (Latency), или время отклика диска, измеряется в микросекундах (меньше - лучше);
– количество операций чтения в секунду (Disk Reads/sec) , измеряемой в IOPS (больше – лучше);
– количество операций записи в секунду (Disk Writes/sec), измеряемой в IOPS.
Сведем эти три параметра в одну таблицу :

Таб. 3 – Производительность HDD и SSD.

Как хорошо заметно из таблицы, NVMe SSD (на примере Intel® SSD DC P3600 Series) по латентности превосходит Enterprise SAS HDD в 100 раз, а по количеству операций ввода-вывода в секунду - в 200 раз на запись и в 1500 раз на чтение.
Разумно ли при этом использовать для размещения баз данных технологии HDD?

в) Объем перезаписи в день для серверных SSD.
Кроме всяких «плюшек» в виде суперконденсатора на случай отключения питания и аппаратных модулей шифрования, серверные SSD имеют важнейший параметр – расчётный объем перезаписи в день от общей ёмкости диска SSD. Если мы говорим о серверных SSD Intel – то подразумеваем ежедневную перезапись этого объема в течении 5 лет, что входит в гарантийные обязательства. Этот параметр позволяет отсортировать SSD на «предназначенные преимущественно для чтения», «ориентированные на запись и чтение» и «рассчитанные на большие нагрузки по перезаписи». В табличной форме это выглядит так:

Таб 4. – Объем перезаписи SSD в день.

Соответственно, можно правильно подбирать диски именно под задачу в сервере.
К примеру, для хранения OS и SQL log вполне достаточно Intel SSD s3510.
Для хранения DB и tempDB больше подойдут Intel SSD s3610 или Intel SSD s3710.

Примеры проектирования дисковых подсистем.
Вооружившись описанным выше, давайте соберем несколько дисковых подсистем под различные требованя.
а) Сервер на 45 пользователей, DB – 15 GB, прирост в год - 4 GB, tempDB - 0,5 GB, SQL log – 2 GB.
Здесь экономически оправданно установить RAID1 из двух дисков Intel SSD s3510 240 GB для нужд OS и SQL Log, и RAID1 из двух дисков Intel SSD s3510 120 GB для нужд DB и tempDB. В качестве RAID-контроллера подойдет «бортовой» Intel® RAPID.
б) Сервер на 100 пользователей, DB – 55 GB, прирост в год – 15 GB, tempDB – 4 GB, SQL log - 8 GB.
Для такого сервера можно предложить RAID1 из двух дисков Intel SSD s3510 240 GB для нужд OS и SQL Log, и RAID1 из двух дисков Intel SSD s3610 200 GB для нужд DB и tempDB. В качестве RAID-контроллера оптимальным будет Intel® RAID Controller RS3WC080 (простой аппаратный, без кэша).
в) Сервер на 200 пользователей, DB – 360 GB, прирост в год – 70 GB, tempDB – 24 GB, SQL log – 17 GB.
Это сервер уже довольно нагруженный. Для OS по-прежнему берем RAID1 из двух дисков Intel SSD s3510 240 GB. SQL Log и tempDB можно разместить на выделенном RAID1 из двух дисков Intel SSD s3510 120 GB. А для таблиц DB собрать RAID10 из четырех дисков Intel SSD s3610 400 GB. В качестве RAID-контроллера уместно использовать «продвинутый» Intel® RAID Controller RS3MC044.

Виртуализация
Производительность современных серверов часто позволяет разместить на одном физическом - целый ряд виртуальных. Для их оптимального размещения желательно помнить, как виртуализация влияет на каждый из компонентов сервера.
CPU и RAM – это участки, которые несут наименьшие потери производительности в виртуальной среде. Соответственно, те программные компоненты, которые задействуют преимущественно их – могут быть безболезненно помещены в Виртуальную машину (VM). К ним относится «1С:Предприятие 8. Сервер приложений х64», сервис Remote Desktop и IIS.
Подсистемы ввода-вывода несут заметно бОльшие потери при виртуализации: 5-15% - сетевой интерфейс и до 25% - дисковая подсистема. У нас есть программный компонент SQL Serve, чувствительный к производительности дисковой подсистемы – вполне логично его разместить не в «VM», а физическом «железе».
Обычно так и делают с отдельно стоящими серверами или группой серверов под 1С:
- на «железо» устанавливается OS Windows и MS SQL Server;
- в VM запускается «1С:Предприятие 8. Сервер приложений х64» и в той же VM «Сервер лицензирования»;
- в отдельной VM сервис Remote Desktop или IIS.
При использовании на одном сервере нескольких программных компонентов, в т.ч. на разных VM, необходимо на уровне дисковой подсистемы предусмотреть дополнительное место для их размещения. Как правило, это системные диски с OS – их увеличивают до 480 GB или более.

Резервное копирование
Достаточно распространенной практикой является установка в сервер двух дисков HDD большой ёмкости (4-8 TB) в RAID1 для хранения локальных копий баз данных, а также в роли файлового хранилища. К такому хранилищу не предъявляется высоких требований по скорости случайного доступа. А линейная скорость как чтения, так и записи получается вполне достаточной для сохранения на нем ежедневной резервной копии и пользовательских файлов. Собрать такой том можно на любом имеющемся варианте RAID-контроллера, а на Intel® RAPID он еще будет и довольно шустро работать.

И, пожалуйста, не забывайте, что у отдельного сервера под ответственные задачи обязательно должно быть избыточное питание.