← На главную

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

Проблематика выбора: картриджные системы против многопроцессорных серверов

Рассматривая архитектурные варианты, сравним два крайних подхода к построению системы:

1. Картриджные микросерверы (модульные архитектуры типа HPE Moonshot): Идея разнести по 5–10 пользователей на отдельный физический модуль кажется привлекательной для изолирования нагрузок. Однако платформа 1С требует лицензирования каждого сервера приложений. Содержание десятков независимых экземпляров ОС и серверов 1С влечет за собой огромные затраты на лицензирование и сложность администрирования.
2. Многопроцессорные сервера (4 сокета и более, например DELL R930/R940): Использование 4-процессорных платформ сталкивается со спецификой архитектуры процессоров с низкой базовой частотой (около 2.0 ГГц) и проблемами связности оперативной памяти.

Ключевой фактор производительности 1С: однопоточная скорость процессора

Разберем специфику работы платформы 1С на аппаратном уровне. В отличие от веб-серверов или систем видеообработки, ключевые транзакционные операции 1С (проведение документов, проведение регламентных операций, запуск сложных отчетов) выполняются строго последовательно в один поток.

Следовательно, производительность системы критически зависит не от общего количества ядер, а от однопоточной производительности (Single-Thread Performance) и тактовой частоты процессора. Процессор с частотой 3.8–4.2 ГГц в режимах Turbo Boost покажет существенный прирост скорости работы 1С по сравнению с процессором, имеющим 24 ядра, но с частотой 2.0 ГГц.

Ограничения архитектуры NUMA на многопроцессорных серверах

Проанализируем работу многопроцессорных систем с точки зрения архитектуры памяти (Non-Uniform Memory Access — NUMA):

1. Каждый процессор в многопроцессорном сервере имеет прямой доступ к своей локальной оперативной памяти и доступ через межпроцессорную шину к памяти других процессоров.
2. Платформа 1С самостоятельно не управляет распределением потоков по узлам NUMA, перекладывая эту задачу на операционную систему.
3. При обращении рабочего процесса 1С (rphost) к удаленному узлу памяти возникают задержки (latency), что приводит к существенной падению скорости работы и неравномерной загрузке ядер.

По этой причине переход на системы с количеством сокетов больше двух в средах 1С не рекомендуется, если нет крайней необходимости в согласовании сверхбольших объемов RAM на одну ОС.

Рекомендуемая архитектура для 100–150 пользователей

Разберем классическую и наименее рискованную схему построения инфраструктуры для организации работы 100–150 пользователей 1С:

1. Выделенный сервер СУБД (MS SQL Server или PostgreSQL):

   Требует максимальную частоту на ядро, высокий объем оперативной памяти под кэши баз данных и быстродействующую дисковую подсистему на NVMe-накопителях (желательно в RAID 10 или RAID 1).

2. Выделенный сервер приложений 1С:Предприятие:

   Требует высокочастотный процессор (1 или 2 сокета с высокой базовой частотой). Объем RAM рассчитывается из нормы 1–2 ГБ на каждого активного пользователя плюс резерв под процессы rmngr и фоновые задания.

3. Терминальная ферма (RDP) или Web-серверы:

   Для тонких клиентов рекомендуется поднимать ферму веб-серверов (IIS / Nginx). При работе через RDP-сессии рассчитывают 6–8 терминальных серверов (из расчета 20–25 пользователей на север) для равномерной нагрузки по памяти (300–500 МБ RAM на тонкого клиента в сессии).

4. Серверы инфраструктуры и бэкапов:

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

Тонкая настройка СУБД и виртуализации под 1С

Выясним, какие настройки необходимо выполнить для оптимизации взаимодействия СУБД и платформы 1С:

1. Настройка NUMA в средах виртуализации:

   При использовании гипервизоров (VMware ESXi, Hyper-V, Proxmox) размер виртуальной машины (число vCPU и объем RAM) не должен выходить за пределы одного физического сокета (NUMA-узла). Для виртуальных машин 1С и СУБД обязательно включается полная резервация оперативной памяти (RAM Reservation).

2. Оптимизация MS SQL Server:

   Установим параметр MAXDOP (Maximum Degree of Parallelism) равным 1 (или количеству ядер одного NUMA-узла) во избежание взаимных блокировок. Файлы временной базы данных TempDB распределим на несколько равных файлов по числу доступных логических ядер процессора.

3. Разделение процессов 1С:

   В консоли кластера 1С пропишем ограничения на создаваемые процессы rphost, установив параметр «Максимальное число соединений на процесс», чтобы распределить нагрузку и снизить риски разрастания оперативной памяти отдельным процессом.