+7 (495) 545-44-85 8 (800) 775-04-59

Российский системный интегратор
Серверы и сетевое оборудование
Суперкомпьютеры и HPC-кластеры
Импортозамещение в сфере ИТ

Надёжность
16:25

Выбор серверного оборудования для 1С:Предприятие 8.

Спецпредложения
x
Посмотреть все
спецпредложения

Как выбрать оптимальное оборудование для 1С:Предприятие 8? Как выбрать сервер для 1С и систему хранения данных?

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

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

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

Процессоры и оперативная память сервера 1C:

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

Относительно оперативной памяти сам разработчик рекомендует по 8 ГБ на каждые 100 пользователей. Однозначно, стоит отказаться от устаревших стандартов и выбирать DDR4. Установка модулей RDIMM или LRDIMM позволяют не только увеличить объем памяти, но и добиться большей производительности и надежности.

В организациях небольшого размера с количеством пользователей в системе не более 10-15 человек база данных, как правило, невелика (обычно не более 1ГБ) и платформа 1С:Предприятие работает на пользовательском компьютере в файловом режиме. Для такого сценария использования достаточно четырехъядерного или шестиядерного процессора Intel Xeon E-2224 или E-2226. В зависимости от числа пользователей будет достаточно 16-32 ГБ оперативной памяти.

Для таких задач скорее всего будет достаточно небольшого стоечного сервера начального уровня, например: Dell PowerEdge T40, HPE ProLiant ML110 Gen10, HPE ProLiant ML350 Gen10, Dell PowerEdge T110 II.

Для обслуживания 30-50 пользователей нужна большая вычислительная мощность, поэтому лучше выбирать сервер на базе шести- или восьмиядерного процессора. Подойдут модели Intel Xeon E-2276G или E-2288G, AMD EPYC 7003 второго или третьего поколения. Необходимое количество памяти – 32-64 ГБ.

Этим требованиям отвечают стоечные серверы HPE ProLiant DL325 Gen10, HPE Proliant DL325 Gen10 Plus, HPE Proliant DL325 Gen10 Plus v2, Dell PowerEdge R230, Dell PowerEdge R330.

Если нужен сервер для поддержки 50-100 пользователей 1C, стоит рассмотреть более мощные двухсокетные модели. Подойдут процессоры Intel Xeon Silver 4210, 4214 или 4216. Если ожидается высокая интенсивность запросов, можно рассмотреть модели с более высокой тактовой частотой: Intel Xeon Silver 4215R или 5218. Объем оперативной памяти необходимо увеличить до 64-128 ГБ.

В более крупных организациях для доступа к приложению используется терминальный режим (режим удаленного доступа Remote Desktop). Обычно при количестве пользователей от 10 до 100 с базой данных объемом от 1 ГБ и выше сервер приложений 1С:Предприятие 8.3 и пользовательская часть работают на одном и том же сервере.

Рассмотрим, какие процессорные решения подходят для обслуживания таких задач. В силу внутренней архитектуры процессоров одно физическое ядро способно эффективно обслуживать около 8-12 потоков пользовательских терминальных сессий. Из практики известно, что для работы с 1С:Предприятие в режиме Remote Desktop серверные процессоры с низкими частотами из младших линеек малопригодны. В случае небольшого числа пользователей (до 20) будет достаточно четырехъядерного процессора Intel Xeon E-2224 или E-2226. В случае, если пользователей больше 20, либо если объем базы данных составляет более 4 ГБ, стоит рассмотреть двухпроцессорные системы.

При расчете требуемого объема памяти следует учесть, что 4ГБ будут использоваться операционной системой, еще не менее 4 ГБ и более – в качестве кэша MS SQL Server, и от 2 до 8 ГБ - для обслуживания «1С: Предприятие 8.3 Сервер приложений». При этом еще необходима память для работы терминальных сессий.

В зависимости от конфигурации в приложениях «Бухгалтерский учет» и «Торговля и склад» для работы одного терминального пользователя необходимо от 200 до 240 МБ, в приложениях «Зарплата и Управление персоналом» и «Управление торговым предприятием» - от 240 до 320 МБ, в приложении «Управление предприятием» до 480 МБ. При этом, если пользователь дополнительно запускает на сервере иные приложения, например, приложения MS Office, то на каждое такое приложение необходимо около 200 МБ. Таким образом, нижний порог объема оперативной памяти для сервера терминалов составит 24 ГБ.

Например, при подборе сервера для 1С с полным пакетом программного обеспечения в конфигурации «Управление Торговым Предприятием» с базой данных объемом 8 ГБ и 50-ю терминальными пользователями следует выбрать двухсокетную модель с восьмиядерными процессорами с тактовой частотой не менее 2 ГГц. Минимальный необходимый объем оперативной памяти составит 36 ГБ, а лучше от 48 до 64 ГБ.

Для обслуживания этих задач (до 100 пользователей 1С:Предприятие 8.2, объем БД от 1Гб), когда и сервер приложений 1С:, и пользовательская часть могут обслуживаться на одной серверной машине. Отлично подойдут решения на базе серверов HPE ProLiant DL360 Gen10 Plus, HPE ProLiant DL380 Gen10 Plus, HPE Proliant DL385 Gen10, HPE Proliant DL385 Gen10 Plus v2, HPE Proliant DL385 Gen10 Plus, Dell PowerEdge R630, FusionServer 1288H V5.

Дисковая подсистема для систем 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

HDD 15000 об/мин, SAS

SSD Intel 320 160GB

SSD Intel 710 200GB

SSDIntel 910 400 GB

чтение

100-120 IOPS

200-220 IOPS

35 000 IOPS

35 000 IOPS

90 000 IOPS

запись

80-100 IOPS

180-200 IOPS

600-8600 IOPS

2400 – 8600 IOPS

38 000 IOPS

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

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


RAID 0

RAID 1 (или 10)

RAID 5

RAID 6

чтение

1

1

1

1

запись

1

2

4

6

Из таблицы следует, что при использовании 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.

Таким образом, можно сказать, что 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 R740xd, Dell PowerEdge T640, HPE ProLiant DL380 Gen10 Plus позволяют установить сравнительно большое количество дисков в один физический сервер (до 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, Fujitsu ETERNUS LT40 S2, Fujitsu ETERNUS LT60 S2, Dell PowerVault ML6010, Dell PowerVault TL4000) делает резервное копирование на ленту вполне удобным и технологичным.

Отдельно следует упомянуть, что большинство производителей серверного оборудования предлагают так же и специальные устройства для резервного копирования (Dell PowerVault DL4000, Dell DR4100, HP StoreOnce 6500 Backup), имеющие такой важный функционал, как дедупликация данных. Использование таких устройств в конечном итоге вполне оправдывает затраты на их приобретение.

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

В этом случае интересны решения типа Dell VRTX или Fujitsu PRIMERGY CX400 M6, когда 2 или 4 сервера с общей дисковой подсистемой собраны в рамках одного устройства.

При использовании виртуализации и/или при построении серверных кластеров отказоустойчивых систем 1С обычно используют несколько физических серверов и общую для них систему хранения данных. В системах средней производительности используются достаточно скромные (с точки зрения IOPS и возможностей тиеринга данных) системы хранения данных, например, HPE MSA 2050, Huawei OceanStor 2200 V3 и др.

Для высокопроизводительных сверхотказоустойчивых и катастрофоустойчивых решений используют СХД большой производительности, имеющих функционал синхронной репликации данных между двумя и более СХД, зачастую расположенных в разных ЦОД (Dell Compellent, HPE 3PAR StoreServ, Fujitsu ETERNUS). Так же для таких систем характерно использование либо мощных многопроцессорных серверов (например, Dell EMC PowerEdge R840, HPE Proliant DL560 Gen10, HPE ProLiant DL380 Gen10 Plus, HPE Proliant DL580 Gen10) либо кластеров на базе блейд-серверов.