← На главную

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

Почему происходит лавинообразный перекос нагрузки на новый рабочий сервер?

Для понимания причин такого поведения проанализируем внутреннюю логику работы диспетчера кластера 1С. Алгоритм распределения новых подключений опирается на вычисляемую оценку доступной производительности каждого рабочего процесса (rphost) и сервера в целом:

1. Эффект «чистого листа» и задержка снятия метрик. Когда в кластер подключается новый сервер, на нем отсутствуют активные сеансы, потребление оперативной памяти минимально, а процессор не нагружен. Центральный менеджер кластера (rmngr) оценивает такой узел как обладающий максимальной производительностью.
2. Утренний шквал подключений (Logon storm). Статистика нагрузки с рабочих серверов собирается менеджером не непрерывно, а с определенным временным интервалом в несколько секунд. Когда сотни пользователей одновременно запускают клиентские приложения, центральный менеджер отправляет весь поток соединений на «наиболее производительный» узел. За время, пока обновятся счетчики утилизации процессора, новый сервер успевает получить критический объем сеансов и зависает от 100% загрузки ЦП.
3. Особенности учета оперативной памяти. Параметр «Объем памяти рабочих процессов, до которого сервер считается производительным» отслеживает исключительно суммарную память, занятую процессами rphost, а не общую память операционной системы. При массовом старте клиентских сеансов узел упирается в предел по вычислениям ЦП (компиляция модулей, авторизация) задолго до того, как память процессов физически вырастет до порогового значения. В результате ограничение не успевает сработать вовремя.
4. Роль менеджеров кластера. Процессы rmngr создаются платформой автоматически при необходимости обслуживания определенных сервисов. Отсутствие дополнительного менеджера на новом узле не является ошибкой и не ломает балансировку, так как управление сеансами централизовано. Однако в версиях платформы 8.3.7–8.3.8 присутствуют известные погрешности в формулах расчета доступной производительности, усугубляющие перекос.

Решение 1. Функциональное разделение нагрузки через требования назначения функциональности

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

Рассмотрим по шагам схему функционального разделения для кластера из трех узлов:

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

Для реализации этой схемы настроим требования назначения функциональности в консоли администрирования кластера:

1. Для пользовательских серверов добавляем требования:
   1. Объект требования: Клиентское соединение с информационной базой — Тип требования: Назначать.
   2. Объект требования: Фоновое задание — Тип требования: Не назначать.
   3. Объект требования: Сервис фоновых заданий — Тип требования: Не назначать.
2. Для выделенного сервисного сервера задаем противоположные правила:
   1. Объект требования: Клиентское соединение с информационной базой — Тип требования: Не назначать.
   2. Объект требования: Фоновое задание — Тип требования: Назначать.
   3. Объект требования: Сервис фоновых заданий — Тип требования: Назначать.
   4. При необходимости выносим сюда же: Сервис полнотекстового поиска, Сервис журналов регистрации и внешние подключения (COM-соединения, Web-сервисы).
3. После внесения правил обязательно выполняем команду «Применить требования назначения функциональности».

Обратите внимание: если фоновое задание запускается непосредственно из контекста клиентской сессии, недостаточно указать только тип соединения Фоновое задание. Обязательно переносите сам Сервис фоновых заданий, иначе кластер продолжит исполнять код на сервере инициатора.

Решение 2. Тонкая настройка параметров рабочих серверов и кластера

Если функциональное разделение невозможно и все серверы должны принимать пользователей, оптимизируем параметры балансировки:

1. Регулирование «Коэффициента производительности». В свойствах каждого рабочего сервера в кластере задан параметр Коэффициент производительности (по умолчанию 1000). Для нового или менее производительного узла понизьте это значение (например, установите 300–500). Кластер начнет пропорционально отправлять на него меньше сеансов, что предотвратит захлебывание в пиковые утренние часы.
2. Режим распределения нагрузки. Переключите режим распределения нагрузки кластера со значения «Приоритет по производительности» на «Приоритет по памяти». В этом режиме менеджер стремится максимально плотно укомплектовать существующие процессы перед созданием новых и менее агрессивно перебрасывает сеансы на «холодный» сервер.
3. Ограничение соединений на процесс. Установка параметров Количество ИБ на один процесс = 1 и явное лимитирование соединений (например, до 60–80 на один рабочий процесс rphost) повышают отказоустойчивость, предотвращая разрастание отдельных процессов свыше 2–3 ГБ оперативной памяти.

Решение 3. Архитектурный пересмотр: вертикальное масштабирование (Scale-Up)

Проанализируем физическую инфраструктуру. Кластер 1С активно использует межпроцессные сетевые вызовы (RPC) для синхронизации контекстов сеансов, кэшей и транзакционных блокировок. Разделение базы на несколько виртуальных машин под управлением Hyper-V часто создает существенные накладные расходы на сетевую задержку и синхронизацию vCPU.

Если в инфраструктуре имеется аппаратный сервер высокой мощности (например, 32 физических ядра и 256 ГБ ОЗУ), наилучшим решением для 1500–2000 пользователей будет отказ от кластера виртуальных машин в пользу одного мощного физического сервера 1С без виртуализации. Это дает следующие преимущества:

1. Полное устранение сетевых задержек между узлами кластера и накладных расходов на вызовы RPC.
2. Отсутствие проблем с перекосом балансировки и конкуренцией за ресурсы виртуального процессора (CPU Ready / Wait).
3. Высокая производительность работы журнала регистрации (особенно при размещении каталогов службы srvinfo на быстрых SSD-накопителях класса Enterprise).

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