← На главную

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

Выбор версии платформы: ПРОФ или КОРП?

Первое, с чего мы начнем наш анализ — это лицензионная политика. При планировании системы на 500+ пользователей вопрос выбора между ПРОФ и КОРП перестает быть финансовым и становится чисто техническим. Разберем ключевые ограничения:

1. Ограничение по ядрам: Лицензия уровня ПРОФ позволяет использовать не более 12 ядер процессора на один кластер. Для ERP и 500 пользователей этого критически мало. Система быстро упрется в очереди к процессору, и добавление оперативной памяти не поможет.
2. Функциональность управления нагрузкой: Только в версии КОРП доступны расширенные настройки распределения нагрузки, которые позволяют гибко управлять сессиями и рабочими процессами.

Следовательно, для стабильной работы такой системы обязательно использование лицензий КОРП. Это развяжет нам руки в настройке кластера.

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

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

• По производительности: Кластер направляет новые соединения на сервер с наивысшим свободным индексом производительности.
• По памяти: Кластер анализирует объем свободной оперативной памяти на каждом рабочем сервере.

В ситуации, когда основной риск — это «прожорливость» сессий ERP по ОЗУ (до 1 Гб и выше на активного пользователя), нам следует выбирать стратегию балансировки по памяти. Это позволит системе автоматически перекидывать новых пользователей на тот сервер, где в данный момент больше свободных ресурсов.

Ограничение ресурсов через параметры рабочего сервера

Теперь выясним, как предотвратить ситуацию, когда один рабочий процесс rphost или весь сервер «съедает» всю доступную память. В консоли администрирования кластера для каждого рабочего сервера можно задать критические пороги:

1. Безопасный расход памяти за один вызов: Этот параметр позволяет прервать выполнение конкретного тяжелого запроса (например, огромного отчета), если он потребляет слишком много памяти, не давая ему уронить весь рабочий процесс.
2. Объем памяти рабочих процессов, до которого сервер считается производительным: Это именно тот механизм, который поможет «ограничить» количество сессий. Как только суммарная память всех rphost достигнет этого порога, кластер перестанет назначать новые соединения на этот сервер и отправит их на другие узлы.
3. Максимальный объем памяти рабочих процессов: Жесткий лимит, после которого сервер начнет перезапускать наиболее нагруженные процессы для высвобождения ресурсов.

Требования назначения функциональности (TNF)

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

• Выделение сервера под фоновые задания: ERP генерирует огромное количество фоновых и регламентных заданий (расчет себестоимости, проведение документов, актуализация индексов). Мы можем создать правило, которое запрещает запуск BackgroundJob.CommonModule на «клиентских» серверах и разрешает их только на выделенном сервере.
• Изоляция сервисов: Мы можем вынести Сервис лицензирования или Сервис полнотекстового поиска на отдельный узел кластера, чтобы их работа не мешала интерактивным пользователям.
• Распределение по информационным базам: Если у нас несколько баз, мы можем жестко закрепить конкретную базу за определенным рабочим сервером.

Оптимизация работы рабочих процессов (rphost)

Для ERP крайне важно правильно настроить количество и поведение процессов rphost. Рассмотрим рекомендации:

Количество ИБ на процесс: Рекомендуется ограничивать это число (например, 1 процесс на 1 ИБ), чтобы проблемы в одной базе не влияли на пользователей другой. При 500 пользователях лучше иметь несколько десятков рабочих процессов на каждом сервере.

Перезапуск процессов: Из-за фрагментации памяти процессы rphost со временем начинают потреблять больше ресурсов. Настройте в параметрах кластера Интервал перезапуска (например, 86400 секунд — раз в сутки) и Допустимый объем памяти. Это обеспечит «свежесть» системы каждое утро.

Взаимодействие с СУБД и сетью

Проанализируем ситуацию с передачей данных. При использовании нескольких серверов 1С нагрузка на сеть возрастает кратно. Выясним причины:

Когда сервер приложений 1С и сервер СУБД (MS SQL или PostgreSQL) разнесены на разные физические хосты, весь объем данных передается по сети. Для ERP это сотни гигабайт трафика. Критически важно иметь канал 10 Гбит/с между всеми узлами кластера 1С и сервером БД. Также следует минимизировать задержки (Latency), так как 1С выполняет тысячи мелких последовательных запросов к БД при открытии форм или проведении документов.

Резюме по настройке инфраструктуры

Для успешного взлета ERP на 500–600 пользователей мы рекомендуем следующую схему:

1. Используйте 3 мощных сервера для кластера 1С.
2. Установите лицензии КОРП.
3. Настройте Стратегию балансировки по памяти.
4. Через Требования назначения функциональности выделите один сервер под фоновые задания, а два других оставьте под работу пользователей.
5. Установите пороги производительности по памяти для каждого сервера (например, при 128 Гб ОЗУ на борту, поставьте порог в 100 Гб), чтобы новые сессии уходили на менее нагруженные узлы автоматически.

Такой системный подход позволит вам не «гадать» на количестве сессий, а управлять реальными ресурсами оборудования, обеспечивая максимальный комфорт для пользователей ERP.