Выбор сервера для 1С

Как выбрать оптимальное оборудование для 1С:Предприятие ? Как выбрать сервер для 1С и систему хранения данных?
При выборе оборудования для 1С необходимо учесть особенность и структуру вычислительной нагрузки. В условиях ограниченного бюджета эту задачу поможет решить мониторинг основных подсистем сервера в условиях решения реальных задач. При выборе оборудования следует исходить из существующих условий, задач и доводов здравого смысла.
Даже при небольшом количестве пользователей пакет 1С:Предприятие является приложением, весьма требовательным к ресурсам. Поэтому при выборе серверного оборудования для 1С необходимо тщательно проанализировать потребности, чтобы избежать впоследствии узких мест. При этом в условиях ограниченного бюджета никто не приобретает серверы избыточной мощности. Анализ задач, для решения которых приобретается сервер, важен еще и потому, что спроектировать конфигурацию оборудования для конкретных задач намного проще.
Рассмотрим наиболее популярные базовые конфигурации платформы 1С:Предприятие: Бухгалтерский учет, Зарплата и Управление персоналом, Управление торговлей, Управление торговым предприятием и Управление Производственным предприятием. Оговоримся, что будем рассматривать вариант работы с «1С: Предприятие 8.2 Сервер приложений» в режиме удаленного рабочего стола для одновременной работы до 100-150 пользователей базы данных. При более обширных базах данных наши рекомендации могут быть применены лишь отчасти, поскольку работа с большими базами данных требует отдельного рассмотрения в каждом конкретном случае.

Процессоры и оперативная память сервера 1C:
В организациях небольшого размера с количеством пользователей в системе не более семи человек база данных, как правило, невелика (обычно не более 1ГБ) и платформа 1С:Предприятие работает на пользовательском компьютере в файловом режиме. Для решения таких задач применяются классические файл-серверы. В таком случае можно порекомендовать установку процессоров Intel Xeon E3-12xx, в случае сильно ограниченного бюджета можно обойтись даже Intel Core i3. Объем оперативной памяти необходимо установить из расчета 4 ГБ на нужды операционной системы и 4 ГБ для системного файлового кэша.
При количестве пользователей от 7 до 25 размер базы данных больше, обычно до 4ГБ. В таком случае с нагрузкой могут справиться четырехъядерный процессор Intel Xeon E3-12xx или AMD Opteron 4хх. В случае такого количества пользователей объем оперативной памяти также должен быть более 4ГБ для работы операционной системы, от 2 до 8 ГБ для работы «1С: Предприятие 8.2 Сервер приложений» и столько же для кэша MS SQL Server. При этом следует помнить, что для баз данных небольшого объема лучше кэшировать не часть базы данных, а весь объем.
Таким образом, для одновременного обслуживания от 7 до 25 пользователей в системе рекомендуется около 16-24 ГБ оперативной памяти. Известно, что иногда при выгрузке операционной системой «1С:Предприятие 8.2. Сервер приложений» на жесткий диск в файл подкачки, может быть потерян отклик. Поэтому по возможности следует иметь запас свободного места в оперативной памяти.
Этим требованиям отвечают стоечные серверы HP Proliant DL320e, DELL PowerEdge R320, DELL R420, IBM System x3250 M4, Fujitsu Primergy RX100 и Primergy RX200. В напольном (tower) исполнении это серверы: HP Proliant ML310e, ML350e, DELL PowerEdge T110, DELL T420, IBM System x3200 M4.
В более крупных организациях для доступа к приложению используется терминальный режим (режим удаленного доступа Remote Desktop). Обычно при количестве пользователей от 10 до 100 с базой данных объемом от 1 ГБ и выше сервер приложений 1С:Предприятие 8.2 и пользовательская часть работают на одном и том же сервере.
Рассмотрим, какие процессорные решения подходят для обслуживания таких задач. В силу внутренней архитектуры процессоров одно физическое ядро способно эффективно обслуживать около 8-12 потоков пользовательских терминальных сессий. Из практики известно, что для работы с 1С:Предприятие в режиме Remote Desktop серверные процессоры с низкими частотами из младших линеек малопригодны. В случае небольшого числа пользователей (до 20) будет достаточно четырехъядерного процессора из серии Intel Xeon E3-12xx. При этом распределение нагрузки будет выглядеть следующим образом: два ядра для нужд операционной системы и терминальных пользователей, одно ядро для «1С: Предприятие 8.2 Сервер приложений» и одно ядро для обслуживания SQL Server. В случае, если пользователей больше 20, либо если объем базы данных составляет более 4 ГБ, придется рассмотреть двухпроцессорные системы на базе Intel Xeon E5-26xx или AMD Opteron 62xx.
При расчете требуемого объема памяти следует учесть, что 4ГБ будут использоваться операционной системой, еще 4 ГБ и более – в качестве кэша MS SQL Server, и от 2 до 8 ГБ — для обслуживания «1С: Предприятие 8.2 Сервер приложений». При этом еще необходима память для работы терминальных сессий.
В зависимости от конфигурации в приложениях «Бухгалтерский учет» и «Торговля и склад» для работы одного терминального пользователя необходимо от 200 до 240 МБ, в приложениях «Зарплата и Управление персоналом» и «Управление торговым предприятием» — от 240 до 320 МБ, в приложении «Управление предприятием» до 480 МБ. При этом, если пользователь дополнительно запускает на сервере иные приложения, например, приложения MS Office, то на каждое такое приложение необходимо около 200 МБ. Таким образом, нижний порог объема оперативной памяти для сервера терминалов составит 24 ГБ.
В качестве примера приведем расчет конфигурации для сервера 1С с полным пакетом программного обеспечения в конфигурации «Управление Торговым Предприятием» с базой данных объемом 8 ГБ и 50-ю терминальными пользователями. Здесь оптимальным вариантом будут два процессора Intel Xeon E5-2650 (или аналогичные им) с тактовой частотой 2 ГГц и восемью ядрами в каждом. Минимальный необходимый объем оперативной памяти составит 36 ГБ, а лучше от 48 до 64 ГБ.
Для обслуживания этих задач (до 100 пользователей 1С:Предприятие 8.2, объем БД от 1Гб), когда и сервер приложений 1С:, и пользовательская часть могут обслуживаться на одной серверной машине. Отлично подойдут решения на базе серверов HP Proliant DL360p, DL380p, DL385p, DELL PowerEdge R620, R720, IBM System x3550 M4, IBM x3650 M4, Fujitsu Primergy RX300 и RX350.

Дисковая подсистема для систем 1C:
Многие проблемы, связанные с медленной работой серверов 1С: Предприятие вызваны неправильной конфигурацией дисковой подсистемы. Правильно выбранная дисковая подсистема обеспечивает высокий уровень производительности сервера. Особенно актуальным вопрос выбора дисковой подсистемы является для пользователей нагруженных баз данных, где основной проблемой является блокировка таблиц при одновременной работе многих пользователей.
Система 1С: Предприятие работает с пятью потоками данных для дисковой подсистемы: таблицы базы данных, индексные файлы, лог-файлы SQL, временные файлы tempDB, лог-файл пользовательских приложений 1С.
Основной особенностью данных в системе 1С является объектно-ориентированная структура. В системе представлено множество объектов и связей. Поэтому исключительно важна способность дисковой подсистемы выполнять большое количество операций чтения и записи в единицу времени (IOPS), поскольку даже небольшая база данных объемом 200-300 МБ и 4-5 пользователями может требовать скорости до 400-600 операций чтения-записи в секунду. Потоковая скорость передачи данных, как правило, имеет меньшее значение. Более объемные базы данных могут требовать до 18000 операций чтения и записи в секунду.

Приведем примерные требования производительности в зависимости от нагрузок:

База объемом до 300 МБ, 3-5 пользователей – 400-600 IOPS
База объемом до 800 МБ, 10-15 пользователей – 1500-2500 IOPS
База объемом до 4 ГБ, 40-50 пользователей – 5000-7500 IOPS
База объемом до 20 ГБ, до 100 пользователей – до 18000 IOPS.

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

Приведем основные характеристики современных носителей:

HDD 7200 об/мин, SATA: чтение 100-120 IOPS / запись 80-100 IOPS
HDD 15000 об/мин, SAS: чтение 200-220 IOPS / запись 180-200 IOPS
SSD Intel 320 160GB: чтение 35 000 IOPS / запись 600-8600 IOPS
SSD Intel 710 200GB: чтение 35 000 IOPS / запись 2400-8600 IOPS
SSDIntel 910 400GB: чтение 90 000 IOPS / запись 38 000 IOPS

При анализе данных, приведенных в таблице видно, что запись является узким местом как для жестких дисков, так и для твердотельных накопителей. Твердотельные носители SSD обгоняют традиционные жесткие диски по скорости чтения на несколько порядков. Разница в производительности при выполнении операции записи конечно меньше, однако и здесь твердотельные накопители выигрывают по скорости в несколько десятков раз. Наибольшую производительность в операциях чтения и записи дают твердотельные накопители класса Intel 910 или LSI WarpDrive.

Приведенные характеристики относятся к одиночным дискам, однако в базах данных чаще всего используются RAID-массивы, поэтому для более точного расчета производительности дисковой подсистемы необходимо принять во внимание потери производительности (в IOPS), которые несет группа носителей в составе RAID-массива.

Из таблицы следует, что при использовании RAID 10 на основе 6 дисков, на каждую запись в 1 IOPS фактически будет потрачено 2 IOPS. Поэтому при расчете возможностей дисковой группы на запись необходимо сложить IOPS всех накопителей, входящих в RAID-массив, а затем разделить их на число из таблицы. Например, при использовании RAID1 на основе двух жестких дисков с интерфейсом SATA и скоростью вращения 7200 об/мин обеспечат на запись (100 IOPS*2)/2=100 IOPS. Другой пример: при объединении в RAID5 четырех жестких дисков SATA 7200 можно ожидать производительности записи (100 IOPS*4)/4=100 IOPS. При объединении этих же накопителей в RAID10 будет достигнута производительность (100 IOPS *4) / 2 = 200 IOPS. Этот пример хорошо доказывает, что для хранения баз данных, для которых как правило отношение операций чтения к операциям записи составляет 68/32, лучше выбирать RAID 10.

Из приведенных выше данных очевидно, что двух жестких дисков SATA 7200, объединенных в RAID1 серверу будет явно недостаточно. В моменты пиковых нагрузок очередь обращений к диску будет слишком велика.
Чтобы увеличить производительность дисковой подсистемы на запись можно увеличить количество дисков в RAID-массиве, выбрать RAID с меньшим штрафом на запись, установить носители с большей производительностью. Увеличить производительность также помогает кэширование RAID-контроллером с активированным режимом отложенной записи Write back. В этом случае данные сначала попадают в кэш контроллера, а затем в упорядоченном виде в пакетном режиме записываются на диски. С помощью такого решения удается поднять производительность записи на 30-100%.
В случае малонагруженных или небольших баз данных можно использовать гибридный RAID-массив из комбинации жестких дисков и твердотельных накопителей. Для малых баз данных (до 20 ГБ) на 3-15 пользователей в распределенной структуре организации (например сеть кафе или СТО) этого вполне достаточно.
Если речь идет об обслуживании крупных баз данных (200 ГБ и более) или нескольких объемных баз данных увеличения скорости дисковых операций можно добиться с помощью технологий LSI CacheCade 2.0 или Adaptec MaxCache 3.0 (SSD-кэширование). С помощью указанных технологий можно добиться увеличения скорости дисковых операций на 20-50% в задачах, решаемых 1С, без существенных изменений в инфраструктуре и относительно недорого.

Самые высокие скорости обеспечивают RAID-массивы на основе серверных SSD (как с использованием SAS RAID-контроллера, так и с использованием PCIe SSD). К сожалению, существенными недостатками такого подхода являются необходимость существенно изменять структуру хранения, а также достаточно высокая цена.
Следует отметить, что индексные файлы базы данных обновляются очень редко, примерно один раз в сутки, однако постоянно читаются. Поэтому такие данные лучше хранить на SSD-носителях, которые отличаются высокой производительностью при выполнении операций чтения. Файлы TempDB используются для хранения временных данных и как правило невелики по объему. Однако они требовательны к скорости записи. В связи с тем, что потеря индексных файлов и файлов TempDB не приведет к потере реальных данных, удобнее всего размещать эти файлы на отдельном SSD-носителе.
Для повышения надежности и быстродействия для хранения TempDB имеет смысл выделить массив RAID1 на основе SSD с обязательным выключением всех кэшей на запись. Для этих целей отлично подходят и накопители типа дисков Intel серии 520. Благодаря выделению этих данных из общей системы хранения на отдельную подсистему с высокими скоростными характеристиками, удается повысить производительность системы в целом, особенно в моменты пиковых нагрузок.

Иногда возникает необходимость вынести временные файлы на RAMDrive. Такое решение имеет смысл, при необходимости решать сложные расчетные задачи, например задачи складской или транспортной логистики, и если есть возможность обеспечить максимально быструю реакцию при сбоях. Такой подход позволяет увеличить общую производительность системы на 4-12%. Однако следует иметь ввиду, что в случае рестарта сервера может потребоваться запуск RAMDrive вручную, если не произойдет автоматического запуска.

Еще одним важным компонентом системы являются лог-файлы. При пиковых нагрузках быстродействие сервера 1С может существенно снизиться из-за постоянного потока мелких обращений на запись со стороны лог-файлов. Поэтому решением этой проблемы может стать перенос лог-файла на отдельный физический носитель, необязательно с высокими показателями IOPS, на который будет вестись почти линейная запись. При необходимости для этих же целей может быть создано зеркало из недорогих дисков SATA/NL SAS или из десктопных SSD (например носители серии Intel 520).

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

В идеале дисковая подсистема сервера 1С может выглядеть следующим образом:

1. Для хранения таблиц базы данных используются RAID 10 (для баз данных небольшого объема RAID1) на основе надежных серверных SSD-накопителей с обязательным использованием аппаратного RAID-контроллера. В случаю высоких требований к производительности можно использовать вариант PCIe SSD. При наличии объемных баз данных эффективным может оказаться SSD-кэширование массивов HDD. В случае не слишком высоких требований к IOPS и малом количестве пользователей вполне можно обойтись и традиционным массивом из жестких дисков SAS 15K rpm.
2. Индексные файлы базы данных хранятся на отдельном, быстром и недорогом SSD-носителе, временные файлы – на SSD-носителей, массиве RAID1 на основе SSD носителей или на RAMDrive.
3. Для хранения лог-файлов SQL и, по возможности, 1С выделяется отдельный том, представленный одиночным диском или RAID1 на основе жестких дисков SATA/NL SAS или дешевых SSD. В качестве альтернативы может использоваться логический диск на RAID-массиве, который используется для размещения операционной системы и пользовательских данных.
4. Для размещения операционной системы и пользовательских данных используется RAID1 на основе жестких дисков или твердотельных накопителей.

В случае использования виртуализированной IT-инфраструктуры желательно устанавливать SQL Server непосредственно на физический сервер, без использования виртуальной машины. Это обеспечит увеличение производительности дисковой подсистемы от 15 до 35% (в зависимости от характеристик оборудования, драйверов, способов подключения и программного обеспечения). В случае использования SQL-сервера в виртуализированной среде, обязательно подключение томов с таблицами базы данных, индексными и временными файлами к виртуальной машине в монопольном режиме с использованием Direct Access.

Но важно понимать, что наибольшую производительность, вне зависимости, используется виртуализация или нет, можно получить все же в случае использования систем хранения данных в качестве дисковой подсистемы, и правило: «чем больше дисков – тем быстрее» не потеряло своей актуальности. Между тем, лишь некоторые серверы, например, DELL PowerEdge R720xd, DELL T620, HP Proliant DL380p позволяют установить сравнительно большое количество дисков в один физический сервер (до 24 HDD SAS 2.5 дюйма), что, конечно, накладывает некоторые ограничения. Кроме того, контроллеры систем хранения данных априори быстрее и надежней (благодаря возможности дублирования) RAID-контроллеров, устанавливаемых в серверах, и имеют большую кеш-память, и, главное, могут использоваться при построении отказоустойчивых кластеров серверов SQL, ORACLE или 1С. Впрочем, об отказоустойчивости еще пойдет речь ниже.

Сетевые интерфейсы систем 1C:

Одним из важных аспектов, которые следует учитывать при развертывании систем 1С:Предприятие 8 в малых и средних организациях, являются потери на сетевых операциях через интерфейс Ethernet. Для минимизации таких потерь идеальным решением будет обслуживание SQL Server, 1С:Предприятие и пользовательских сессий 1С с использованием Remote Desktop на одном физическом сервере. Такой вариант позволяет использовать оборудование и программное обеспечение по максимуму, однако является достаточно спорным с точки зрения отказоустойчивости. Проблема безопасности в таком случае может быть частично решена с помощью виртуализации и «повторяемости среды» на другом оборудовании.

Сетевой интерфейс неизбежно будет создавать задержки при передаче данных из-за необходимости упаковки данных в относительно небольшие блоки для передачи. Особенностью платформы 1С:Предприятие является то, что достаточно большие объемы информации передаются для обработки и отображения по всей цепочке SQL-сервер – Сервер приложений 1С:Предприятие 8 – пользовательская сессия 1С:Предприятие8. При непосредственной передаче информации от одного процесса другому через оперативную память одного сервера (в случае использования варианта без виртуализации) или через виртуальный сетевой интерфейс (так же в рамках одного физического сервера), задержки оказываются намного ниже. Современные двухпроцессорные серверные системы с большим объемом оперативной памяти и дисковой подсистемой на основе SSD отлично справляются с обслуживанием базы данных 1С на 100-150 активных пользователей.

К сожалению, в случае баз данных с высокой нагрузкой использование нескольких физических платформ неизбежно, поэтому крайне желательно использовать для соединения всех серверов технологию Ethernet 10 Gb. В случае, если это невозможно, хотя бы два-четыре агрегированных соединения Ethernet1Gb с аппаратным ускорением TCP/IP и поддержкой виртуализации на аппаратном уровне.

Наиболее часто от потерь производительности на портах Ethernet страдают бюджетные решения. Как правило, сетевые адаптеры 1Гб используемые на сетевых материнских платах не предназначены для поддержки интенсивного сетевого трафика. Даже в случае, когда плата укомплектована двумя или тремя портами GbE, они часто реализованы на десктопных чипах. Они, как правило, порождают дополнительные накладные расходы по обслуживанию сетевого обмена, особенно в виртуализированных средах. В таких случаях передача информации через такие чипы приводит к использованию ресурсов процессора, оперативной памяти и внутренних шин. Поэтому ускорения передачи IP-трафике не происходит, каждый передаваемый и принимаемый пакет требует отдельного прерывания. В случае использования виртуализации снижение производительности сетевого интерфейса могут составлять до 30%. К сожалению, очень часто средства мониторинга не отображают перегрузку именно сетевого интерфейса. Основная проблема здесь в том, что центральный процессор загружается решением задачи обслуживания трафика, а если не работает, то простаивает в ожидании ответа от сетевой карты. Поэтому по возможности порты на десктопных чипах необходимо исключить из потока данных в виртуализированных средах. Их отлично можно использовать для решения задачи управления сервером. Для обслуживания интенсивного сетевого трафика имеет смысл добавить дискретную сетевую карту на серверном чипсете.

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

Для организаций с большим числом одновременно работающих пользователей (от 25 до 150) при размещении всех приложений на одном сервере обязательным является использование источников бесперебойного питания, избыточных блоков питания в самих серверах, элементов с возможностью горячей замены и RAID-массивов с горячим резервированием. Обязательным является также плановое резервирование данных, поскольку при наличии ежедневной резервной копии и оперативного файла с полным логом SQL, база данных 1С может быть восстановлена достаточно быстро.
Для малых и средних предприятий допустимым уровнем аварийности является 1-2 аварийных случая в месяц продолжительностью 1-4 часа. Для быстрого рестарта необходимы образы всех виртуальных и физических серверов в виде виртуальных машина на отдельном томе (используются для восстановления самой инфраструктурной части на резервном сервере). Обязательно должно выполняться ежедневное резервное копирование на отдельное физическое устройство и сохраняться Full SQL log, для тех случаев, когда потеря данных с начала рабочего дня имеет критическое значение и трудновосстановима вручную.
Резервное копирование данных производится как на жесткие диски в серверах или СХД, так и на ленточные носители. Оба подхода имеют свои плюсы и минусы. Резервное копирование на жесткие диски значительно дороже, чем на ленточные носители, но значительно быстрее, с точки зрения ввода данных из бекапа в работу.

Ленточные носители, в свою очередь, дешевле жестких дисков и долговечнее их, а использование автозагрузчиков и ленточных библиотек (HP MSL 2024, IBM TS3100, TS3200, TS3500, Fujitsu ETERNUS LT40 S2 LT60 S2, DELL PowerVault ML6010, PowerVault TL4000) делает резервное копирование на ленту вполне удобным и технологичным.

Отдельно следует упомянуть, что большинство производителей серверного оборудования предлагают так же и специальные устройства для резервного копирования (DELL PowerVault DL4000, Dell DR4100, HP StoreOnce 6500 Backup, HP StoreOnce 4700, HP StoreOnce 2700), имеющие такой важный функционал, как дедупликация данных. Использование таких устройств в конечном итоге вполне оправдывает затраты на их приобретение.
При наличии резервного оборудования и выполнении указанных выше условий, работоспособность системы может быть восстановлена за 1-2 часа. В случаях, когда есть потребность в поддержке непрерывной работы круглые сутки семь дней в неделю, основной задачей будет выбор подходящей архитектуры, оборудования с минимальным числом точек отказа и полноценных технологий кластеризации.
В этом случае интересны решения типа DELL VRTX или Fujitsu PRIMERGY CX400 S2, Fujitsu PRIMERGY CX400 S1, Fujitsu Server PRIMERGY CX420 S1, когда 2 или 4 сервера с общей дисковой подсистемой собраны в рамках одного устройства.

При использовании виртуализации и/или при построении серверных кластеров отказоустойчивых систем 1С обычно используют несколько физических серверов и общую для них систему хранения данных. В системах средней производительности используются достаточно скромные (с точки зрения IOPS и возможностей тиеринга данных) системы хранения данных, например, HP MSA 2040, DELL MD3620, IBM Storwize V3700 и д.р.
Для высокопроизводительных сверхотказоустойчивых и катастрофоустойчивых решений используют СХД большой производительности, имеющих функционал синхронной репликации данных между двумя и более СХД, зачастую расположенных в разных ЦОД (DELL Compellent, HP 3PAR, IBM Storwize V7000, Fujitsu ETERNUS DX100, DX200, DX500 DX600, HITACHI HUS130, HUS150). Так же для таких систем характерно использование либо мощных многопроцессорных серверов (например, DELL R820, IBM x3750 M4, x3850 X5, HP DL560 Gen8, DL980 G7, Fujitsu RX500 S7, RX900 S2 ) либо кластеров на базе блейд-серверов, установленных в блейд-шасси (IBM HS23, HX5, DELL M620, M820, HP BL660c Gen8, Hitachi Compute Blade 2000).