В современных отказоустойчивых системах на базе 1С:Предприятие 8.3 часто используется кластеризация для распределения нагрузки. Однако администраторы нередко сталкиваются с ситуацией, когда один из серверов в кластере «засыпает», а второй берет на себя все клиентские соединения. Особенно остро эта проблема проявилась в последних релизах платформы, начиная с 8.3.25. Разберем детально, почему это происходит и как вернуть систему в состояние баланса.
Первым делом проанализируем, как кластер 1С принимает решение о назначении нового соединения на конкретный рабочий сервер. Ключевым параметром здесь является Доступная производительность. Если вы заметили, что на одном сервере этот показатель значительно выше, чем на другом (например, 136 против 73), балансировщик будет игнорировать сервер с меньшим значением.
Выясним причину падения этого показателя. Важно понимать, что Доступная производительность — это не статическая величина. Она рассчитывается динамически на основе следующих факторов:
rphost.Если на сервере падает производительность, rmngr (менеджер кластера) считает такой узел «проблемным» и перестает создавать на нем новые процессы. В результате rphost может даже не успеть получить лицензию, так как кластер превентивно блокирует его использование.
Рассмотрим ситуацию, когда в кластере выделен отдельный сервер лицензирования. Рассмотрим по шагам, что может пойти не так:
Проанализируем работу сервера лицензирования. Если процесс rphost на сервере лицензирования потребляет аномально много памяти или «раздувается», это приводит к задержкам при выдаче лицензий рабочим серверам. Когда рабочий сервер запрашивает лицензию и не получает её за отведенный таймаут, менеджер кластера снижает его приоритет. В консоли администрирования это выглядит так, будто сервер «спит», хотя он физически доступен.
Проверим настройки портов. Часто администраторы оставляют порты по умолчанию. Рассмотрим рекомендацию: если на одном физическом сервере или в одной подсети развернуто несколько служб, стоит развести диапазоны портов для рабочих серверов, чтобы исключить конфликты при динамическом распределении портов IP.
Одной из наиболее частых причин «отвала» сервера является некорректное распределение оперативной памяти между службами 1С и СУБД. Выясним, как правильно ограничить потребление ресурсов, чтобы стабилизировать Доступную производительность.
Разберем план мероприятий по оптимизации памяти, предварительно проанализировав SQL сервер глазами 1С-ника:
Max Server Memory для SQL. Если СУБД и 1С находятся на одной машине, SQL может «вытеснить» процессы 1С, что мгновенно обрушит показатели производительности рабочего сервера.Если железо идентично, но производительность разная, проанализируем состояние операционной системы. 1С получает данные о производительности через службу WMI (Windows Management Instrumentation). Если база данных счетчиков повреждена, кластер получает «мусорные» данные.
Попробуем восстановить счетчики производительности. Для этого будет использована командная строка Windows. От имени администратора выполним:
lodctr /R
lodctr /Q
Также проверим план электропитания. На обоих серверах должен быть установлен режим Максимальная производительность (High Performance). Это критично для стабильного времени отклика процессора, на основе которого вычисляется вес сервера в кластере.
Посмотрим на настройки Требований назначения функциональности. Даже при правильной балансировке, специфические правила могут принудительно уводить нагрузку. Проверим, нет ли в списке правил тех, которые запрещают выполнение определенных сервисов (например, сервиса лицензирования или фоновых заданий) на «спящем» сервере.
Иногда полезно временно переключить тип распределения нагрузки с «По производительности» на «По памяти» (если позволяет лицензия КОРП). Это поможет понять, является ли проблема программным багом расчета весов или реальным дефицитом ресурсов.
Если визуальный осмотр консоли не дает ответа, разберем настройку технологического журнала (ТЖ) для поиска причин падения производительности. Создадим файл logcfg.xml со следующей структурой, чтобы отследить события лицензирования и балансировки:
<config xmlns="http://v8.1c.ru/7.4/v8/config/log">
<dump location="C:\dumps" create="false" type="0"/>
<log location="C:\logs\cluster_balance" history="24">
<event>
<eq property="Name" value="HASP"/>
</event>
<event>
<eq property="Name" value="SESN"/>
</event>
<event>
<eq property="Name" value="CLSTR"/>
</event>
<property name="all"/>
</log>
</config>
Анализируя события CLSTR и HASP, мы сможем точно определить момент, когда rmngr принимает решение о снижении доступной производительности конкретного рабочего сервера. Обращайте внимание на длительность операций (параметр Duration) — если запросы к серверу лицензирования занимают более нескольких секунд, это и есть корень проблемы.
Подводя итог, для решения проблемы с распределением нагрузки выполним следующие действия:
snacc.bin в каталоге srvinfo), предварительно остановив службу 1C:Enterprise 8.3 Server Agent.Проанализировав эти аспекты, мы сможем добиться стабильного и равномерного распределения сеансов пользователей между всеми серверами кластера, обеспечив максимальную отдачу от имеющегося оборудования.