← На главную

Рассмотрим частую ситуацию, с которой сталкиваются системные администраторы после обновления платформы «1С:Предприятие» (например, при переходе с ветки 8.3.24 на 8.3.27). Имеется кластер серверов из нескольких узлов. На одном узле используется программная лицензия, на другом — установлен аппаратный USB-ключ (например, Sentinel HL). После обновления второй сервер внезапно перестает принимать клиентские соединения и просто «висит» в ожидании, а в консоли администрирования кластера аппаратная лицензия не отображается. При этом сам ключ исправен и определяется утилитой Sentinel ACC.

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

Отображение аппаратных ключей в консоли кластера

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

Встроенный в кластер «Сервис лицензирования» (выполняемый компонентом менеджера кластера rmngr) архитектурно спроектирован для централизованной работы исключительно с программными лицензиями. Аппаратные ключи защиты (HASP или Sentinel HL) не централизуются этим сервисом и не раздаются по сети кластера.

Проверка аппаратной серверной лицензии всегда осуществляется каждым рабочим процессом rphost строго локально на том физическом или виртуальном сервере, к которому физически подключен USB-ключ. Именно поэтому в оснастке управления кластером аппаратные лицензии не отображаются. Если вы извлечете ключ и попробуете запустить сервер отдельно, вы получите ошибку «Лицензия не обнаружена». Вставленный ключ позволяет серверу работать, даже если консоль его «не видит».

Идентификация серверных ключей защиты

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

• Зеленый ключ (серия EN8SA, код вендора 84553) — это 100% ключ для 64-разрядной версии сервера 1С.
• Красные ключи — это клиентские многопользовательские ключи (от 5 до 500 рабочих мест). Они не делятся на 32/64 бит.
• Фиолетовые ключи — могут быть 32-битным сервером (серия ENSR8) или клиентским однопользовательским ключом (серия ORGL8).

Почему сервер перестал принимать соединения?

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

1. Конфликт лицензий ПРОФ и КОРП. Аппаратные ключи для сервера выпускаются только уровня ПРОФ. Если на первом узле стоит программная лицензия КОРП, кластер не может работать в смешанном режиме. Начиная с версий 8.3.25 и выше, платформа жестко контролирует использование функций КОРП. Если в кластере заданы расширенные параметры (ручное распределение сервисов, профили безопасности), при обнаружении узла с лицензией ПРОФ кластер отключит его от балансировки нагрузки.
2. Сброс Требований назначения функциональности (ТНФ). При изменении структуры метаданных правила ТНФ могли сброситься. Если второму серверу явно не назначено исполнение рабочих процессов конкретных баз или сервиса сеансов, центральный сервер будет замыкать все подключения на себе.
3. Сброс степени производительности. В свойствах рабочего сервера есть параметр веса в балансировке. Если после обновления он сбросился в 0, менеджер кластера исключит узел из распределения.

Шаги по восстановлению работоспособности кластера

Выполним пошаговую настройку для возвращения второго сервера в строй:

1. Проверка фактического использования ключа. Подключитесь к базе так, чтобы сеанс оказался на втором сервере (например, временно отключив первый). В меню «О программе» проверьте блок «Лицензия: текущая». Там должна быть строка с информацией о локальном аппаратном ключе (например, HASP... EN8SA).
2. Настройка свойств кластера и сервера. Откройте свойства кластера. Если используются лицензии ПРОФ, убедитесь, что параметры расхода памяти и допустимого отклонения ошибок равны 0, чтобы не активировались функции КОРП. Далее откройте свойства второго рабочего сервера и проверьте параметр «Степень производительности» — он должен быть равен значению первого узла (по умолчанию 1000).
3. Очистка служебных кэшей кластера. При межверсионных обновлениях часто помогает сброс кэша. Остановите службу агента сервера ragent на обоих узлах. Найдите каталог реестра кластера (обычно reg_1541), перейдите в подкаталоги snccntx и очистите их содержимое. Запустите службы снова.
4. Проверка прав службы. Убедитесь, что служба сервера 1С на втором узле запускается от пользователя, имеющего права на доступ к USB-устройствам. При запуске от системной учетной записи SYSTEM в изолированном контексте процесс может терять связь с драйвером ключа.

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