В крупных инфраструктурах часто используется разделение ролей: один сервер отвечает за работу приложений (rphost), а другой — за раздачу клиентских лицензий. Однако администраторы часто сталкиваются с ситуацией, когда сервер приложений внезапно «теряет» связь с сервером лицензирования. При этом сеть работает стабильно, порты открыты, но пользователи не могут войти в систему. Разберем эту проблему подробно, проанализируем причины и выработаем алгоритм решения.
Прежде всего, нам необходимо понять, что именно «видит» система в момент возникновения ошибки. Рассмотрим типичное сообщение из журнала поиска лицензий, которое возникает при потере связи:
«Ошибка программного лицензирования. Файл программной лицензии не предусматривает возможность запуска клиентских приложений... Ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=15»
Проанализируем эти данные. Ошибка Warning=15 в контексте сетевого поиска часто указывает на то, что менеджер лицензий не найден или не отвечает в отведенное время. Если сервер приложений сообщает, что локальные ключи не установлены (Status=-100), это нормально для серверной части, но отсутствие ответа от сервиса лицензирования в кластере говорит о нарушении внутренней логики взаимодействия процессов ragent и rmngr.
Одной из наиболее эффективных мер является явное указание кластеру, какой именно сервер должен заниматься лицензированием. Если в кластере несколько серверов, автоматическое распределение ролей может давать сбои. Рассмотрим, как настроить это вручную:
Этот метод позволяет жестко закрепить роль за конкретной машиной, исключая попытки сервера приложений искать лицензии там, где их нет. Для быстрой настройки параметров кластера и назначения ролей можно использовать кроссплатформенную консоль администрирования кластера серверов 1С.
Часто проблема кроется в механизмах DNS. Если сервер лицензирования и сервер приложений находятся в разных подсетях или имеют проблемы с разрешением имен, связь может периодически разрываться. Проанализируем ситуацию: сервер приложений обращается к серверу лицензирования по его сетевому имени, которое прописано в настройках кластера.
Рассмотрим решение через файл hosts. На сервере лицензирования и на сервере приложений рекомендуется принудительно прописать соответствие IP-адресов и имен всех участников кластера. Это исключит задержки, связанные с работой DNS-серверов. Запись должна выглядеть примерно так:
192.168.1.10 app-server-01
192.168.1.11 license-server-01
Важно убедиться, что сервер лицензирования доступен по имени с сервера приложений и наоборот. Это критично для поддержания стабильной TCP-сессии между процессами rmngr.
Выясним еще одну важную деталь: порядок запуска серверов в кластере. Практика показывает, что если сервер приложений стартует раньше, чем сервер лицензирования успевает инициализировать свои сервисы, связь может не установиться корректно. Рекомендуется придерживаться следующего правила: сервер лицензирования должен быть полностью запущен (служба 1C:Enterprise 8.3 Server Agent находится в статусе «Выполняется») до того, как начнут стартовать остальные серверы приложений.
Если один из рабочих серверов был перезагружен и перестал видеть лицензии, попробуйте перезапустить службу агента сначала на сервере лицензирования, а затем на проблемном сервере приложений. Для оперативного завершения сеансов пользователей и перезапуска рабочих процессов перед проведением таких работ подойдёт веб-приложение для управления сеансами и процессами сервера 1С.
Иногда причина кроется в «залипших» данных в папке службы сервера. В каталоге srvinfo (путь по умолчанию C:\Program Files\1cv8\srvinfo`) хранятся данные кластера. Перед тем как приступать к изменениям, полезно изучить подробную информацию по рабочему каталогу центрального сервера и его структуре. Рассмотрим процесс очистки:</p>
<ol>
<li>Остановим службу <code>1C:Enterprise 8.3 Server Agent.
reg_).snccntx. В ней хранятся данные сеансов и информация о выданных лицензиях.Важно: очистка этой папки приведет к разрыву текущих соединений, поэтому выполнять ее нужно в технологическое окно, предварительно завершив сеансы пользователей, например, с помощью специализированного WEB-приложения для управления сеансами (поможет утилита для принудительного завершения сеансов 1С).
Проанализируем влияние системных настроек на стабильность лицензирования. Существует несколько неочевидных факторов:
Несмотря на то, что мы обсуждаем программные лицензии, платформа 1С при запуске все равно пытается опрашивать аппаратные ключи HASP. Если их нет, этот процесс может создавать лишнюю нагрузку и задержки. Мы можем ускорить инициализацию, отредактировав файл nethasp.ini (обычно находится в C:\Program Files\1cv8\conf). Рассмотрим пример настройки, отключающей широковещательный поиск:
[NH_COMMON]
NH_IPX = Disabled
NH_NETBIOS = Disabled
NH_TCPIP = Enabled
[NH_TCPIP]
NH_USE_BROADCAST = Disabled
; Если у вас нет аппаратных ключей вообще, можно оставить только эти настройки
Такая конфигурация заставит систему быстрее переходить к проверке программных лицензий, не тратя время на ожидание ответов от несуществующих менеджеров HASP по всей сети.
Проанализируем работу антивируса. Процесс rmngr (менеджер кластера) отвечает за связь с сервером лицензирования. Антивирусы часто блокируют или задерживают пакеты этого процесса для проверки. Необходимо добавить в исключения (в белый список) следующие компоненты:
ragent.exe, rmngr.exe, rphost.exe. Для более гибкого управления последними можно использовать автоматический перезапуск рабочих процессов.C:\ProgramData\1C\licenses.C:\Program Files\1cv8\srvinfo.Соблюдение этих рекомендаций позволит стабилизировать работу распределенного кластера 1С и избежать внезапных потерь лицензий на серверах приложений.