← На главную

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

Архитектурные варианты размещения сервера 1С и СУБД

Проанализируем основные подходы к размещению ключевых компонентов системы: службы сервера 1С и СУБД MS SQL Server.

1. Разнесение 1С и MS SQL на разные виртуальные машины: Это наиболее гибкая схема, рекомендуемая при числе активных пользователей от 100 и выше. При такой конфигурации процессы СУБД (sqlservr.exe) и кластера 1С (rphost, rmngr) не конкурируют за оперативную память и процессорное время. При этом критически важно обеспечить минимальную сетевую задержку между виртуальными машинами 1С и SQL (Round-Trip Time не более 0.5–1 мс).
2. Совмещение 1С и MS SQL на одном сервере: Данный вариант демонстрирует высокую скорость за счет протокола взаимодействия через разделяемую память (Shared Memory), исключающего накладные расходы сети. Однако совмещение требует строгого ручного разграничения оперативной памяти, так как SQL Server по умолчанию захватывает всю доступную RAM хоста.

Правила выделения ресурсов и тонкая настройка СУБД

Рассмотрим, как правильно рассчитать и распределить аппаратные ресурсы для исключения деградации быстродействия:

1. Память для MS SQL Server: В свойствах экземпляра SQL Server обязательно задаем параметр Maximum server memory (in MB). Оставляем под нужды операционной системы минимум 4–8 ГБ RAM (или больше, если на этом же сервере работает служба 1С). Для работы базы объемом от 40–100 ГБ требуется не менее 24–32 ГБ RAM для эффективного кэширования страниц данных в буферном пуле.
2. Память для службы сервера 1С: Для каждого рабочего процесса rphost выделяется память из расчета порядка 1–1.5 ГБ RAM на каждые 10–15 активных пользователей толстого клиента.
3. Организация дисковой подсистемы SQL: Разносим данные на разные независимые виртуальные диски (желательно SSD/NVMe):
   1. Диск для файлов данных баз (.mdf, .ndf);
   2. Диск для файлов журналов транзакций (.ldf);
   3. Выделенный быстрый диск для системной базы tempdb и файла подкачки ОС.
4. Конфигурация TempDB: Количество файлов данных tempdb настраиваем равным числу ядер vCPU (до 8 файлов) с одинаковым фиксированным размером и фиксированным шагом авторасширения в мегабайтах.
5. Ограничение параллелизма (MAXDOP): Для баз данных 1С параметр экземпляра СУБД Max Degree of Parallelism выставляем в значение 1, чтобы исключить взаимные блокировки потоков.
6. Мгновенная инициализация файлов: Предоставляем сервисной учетной записи SQL Server привилегию Perform volume maintenance tasks для мгновенного расширения файлов баз данных.

Организация терминального доступа (RDS) и работа с лицензиями

Выясним, как взаимодействуют терминальные серверы (RDP), толстые клиенты и система лицензирования 1С:

1. Роль RDP-фермы: Для конфигураций на обычных формах запуск толстого клиента выполняется внутри RDP-сессии. Нагрузка на память составляет в среднем от 500 МБ до 1 ГБ на одного пользователя. Разделение пользователей между двумя и более терминальными серверами защищает систему от сбоев: падение сессии одного пользователя или перезагрузка сервера не останавливает работу всего предприятия.
2. Централизованное лицензирование: Программные клиентские лицензии (или аппаратные USB-ключи с HASP License Manager) устанавливаются на сервер 1С:Предприятия. Клиентские приложения 1С, запускаемые на любых RDS-серверах, автоматически получают лицензии от кластера 1С при установке сеанса. Устанавливать отдельные лицензии на каждый RDS-сервер не требуется.
3. Балансировка сессий RDS: Для равномерного распределения нагрузки между несколькими терминальными серверами используется роль Remote Desktop Connection Broker (посредник подключений), которая автоматически распределяет новые подключения и возвращает пользователей в отключенные сессии.

Почему контроллер домена (AD) должен быть изолирован

Разберем, почему контроллер Active Directory нельзя совмещать с серверами 1С и SQL:

1. Отказоустойчивость: Сбой в работе СУБД или перегрузка процессора сервером 1С не должны приводить к недоступности служб доменной аутентификации (Kerberos/LDAP) и DNS.
2. Системные требования: Для контроллера домена достаточно минимальной виртуальной машины (1–2 vCPU и 2–4 ГБ RAM), что практически не увеличивает затраты на аренду мощностей.
3. Дисковая подсистема: Совмещение роли контроллера домена с базами данных не рекомендуется разработчиками из-за специфики кэширования дисковых операций и повышенных требований к безопасности учетных записей служб.

Итоговая рекомендуемая конфигурация инфраструктуры

Сведем оптимальное распределение компонентов в единую архитектурную схему:

1. Виртуальная машина 1 (MS SQL Server): Выделенные ресурсы vCPU и RAM с жестким ограничением верхней границы памяти, диски SSD под базу, журнал и tempdb.
2. Виртуальная машина 2 (Сервер 1С): Кластер 1С:Предприятия с активированной серверной лицензией и многопользовательскими клиентскими лицензиями. Настроены рабочие процессы с ограничением соединений на процесс (20–40 соединений) и интервалом перезапуска rphost.
3. Виртуальные машины 3 и 4 (RDS-серверы): Установлена только платформа 1С. Пользователи подключаются по RDP и запускают клиентские приложения.
4. Виртуальная машина 5 (Active Directory / DNS): Легковесная изолированная машина для обеспечения авторизации и разрешения сетевых имен в контуре.

При виртуализации хостов критически важно зафиксировать оперативную память (отключить Dynamic Memory / Ballooning), исключить переподписку vCPU для хостов с СУБД и сервером 1С, а также перевести профили электропитания гипервизора в режим высокой производительности (High Performance).