Что делать, если после обновления платформы 1С перестали видеться свободные лицензии HASP?

После обновления платформы «1С:Предприятие 8.3» системные администраторы часто сталкиваются со странным поведением системы защиты: при наличии большого пула свободных лицензий (например, несколько ключей на 50 и 100 пользователей) пользователи внезапно начинают получать ошибку «Недостаточно свободных лицензий». Особенно остро эта проблема проявляется в базах, к которым настроен доступ через веб-интерфейс (веб-клиент через Apache или IIS), в то время как остальные пользователи работают через толстый или тонкий клиент.

В этой статье мы подробно разберем, почему возникает этот конфликт, как меняется логика работы платформы с лицензиями и какие конкретные шаги необходимо предпринять для стабилизации работы системы. Мы рассмотрим как аппаратные методы решения, так и тонкую настройку конфигурационных файлов nethasp.ini и nhsrv.ini.

Выясняем причину: почему старая схема работы ломается после обновления?

Для начала проанализируем ситуацию. В нашем распоряжении имеются три сетевых ключа серии ORGL8 (два по 50 лицензий и один на 100). Они установлены на разных компьютерах в локальной сети. Часть баз (например, зарплатная база) раздает лицензии через сервер «1С:Предприятия» (опция Разрешить выдачу лицензий сервером включена), так как сотрудники заходят в личные кабинеты через браузер. Остальные базы запускаются обычным способом через толстый или тонкий клиент, забирая лицензии напрямую у менеджера лицензий HASP License Manager (HASP LM).

До обновления платформы (например, до версий линейки 8.3.17 и выше) система могла работать годами без видимых сбоев. Однако в новых релизах платформы разработчики «1С» существенно ужесточили механизмы контроля целостности системы защиты и проверки лицензий. Это привело к обострению трех фундаментальных проблем:

1. Конфликт совместного использования ключа. Крайне не рекомендуется использовать один и тот же многопользовательский ключ HASP одновременно для прямой раздачи клиентам (через HASP LM) и для раздачи сервером «1С» (веб-клиентам). Когда толстый клиент забирает лицензию напрямую с HASP LM, в системе мониторинга Aladdin Monitor это соединение отображается с параметром Timeout = 0 (вечно активное соединение). Как только веб-клиент обращается к серверу, сервер пытается запросить лицензию с того же ключа. При подсчете лицензий сервер видит сеансы с Timeout = 0 как занятые, путается в их реальном количестве и мгновенно блокирует выдачу новых лицензий, выдавая ошибку нехватки, даже если физически занято лишь несколько лицензий из 50.
2. Ограничение на один сетевой ключ одной серии. Сервер «1С:Предприятия» по сети через HASP LM физически способен увидеть только один многопользовательский ключ одной серии. В нашем случае все три ключа (50, 50, 100) принадлежат к одной серии ORGL8. Сервер при запуске находит один случайный ключ (например, на 50) и работает только с ним. Два других ключа для сервера просто не существуют. Клиенты же по сети видят все три ключа. Когда веб-пользователи исчерпывают лимит этого единственного видимого серверу ключа, сервер не может переключиться на другие ключи и блокирует вход.
3. Специфика веб-сессий. Веб-клиенты расходуют лицензии по схеме «на сеанс» (каждый запуск — новая лицензия), в отличие от схемы «на хост» у обычных клиентов. При нестабильном соединении или частом обновлении страниц сессии веб-клиентов могут зависать в процессах rphost, продолжая неоправданно удерживать дефицитные лицензии сервера.

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

Решение 1: Физическое разделение ключей защиты (Самый надежный способ)

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

Организуем архитектуру следующим образом:

1. Возьмем один из ключей на 50 пользователей и установим его локально в USB-порт физического сервера, на котором развернута служба «1С:Предприятие» (кластер серверов).
2. Важное условие: На этом сервере 1С не должна быть установлена и запущена служба менеджера лицензий HASP License Manager (HASP LM). Локальный ключ должен быть виден только самому серверу 1С напрямую через драйвер.
3. Поскольку менеджер лицензий на сервере отсутствует, обычные сетевые клиенты (толстые и тонкие клиенты на рабочих станциях) не смогут «дотянуться» до этого ключа по сети. Он будет находиться в монопольном распоряжении сервера «1С».
4. Сервер «1С» будет использовать этот локальный ключ исключительно для раздачи лицензий веб-клиентам (для нашей зарплатной базы).
5. Два оставшихся ключа (на 50 и 100 пользователей) мы размещаем на других компьютерах в сети, где обязательно запускаем HASP License Manager. Они будут отданы под нужды пользователей остальных баз, запускающих программу напрямую.

Таким образом, мы полностью исключаем конкуренцию за лицензии на одном ключе между сервером 1С и сетевыми клиентами.

Решение 2: Тонкая настройка поиска ключей через файлы конфигурации

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

Рассмотрим настройку файла nethasp.ini на стороне сервера «1С». По умолчанию платформа опрашивает сеть широковещательными пакетами и может случайно цеплять чужие ключи, вызывая коллизии. Нам нужно запретить серверу искать ключи в сети, оставив ему только локальный ключ.

Для этого откроем файл nethasp.ini, расположенный на сервере «1С» по пути C:\Program Files\1cv8\conf\nethasp.ini (или в папке настроек конкретной версии платформы), и приведем его к следующему виду, отключив сетевые протоколы поиска:

[NH_COMMON]
NH_TCPIP = Disabled
NH_IPX = Disabled
NH_NETBIOS = Disabled

После сохранения файла и перезапуска службы 1C:Enterprise 8.3 Server Agent наш сервер 1С перестанет сканировать локальную сеть в поисках сетевых HASP LM. Он будет видеть исключительно локально установленный в него ключ.

Теперь настроим клиентские машины (или терминальный сервер, где работают пользователи остальных 29 баз). Нам нужно сделать так, чтобы они искали только два сетевых ключа (50 и 100) и игнорировали машину сервера «1С». Для этого в их файлах nethasp.ini мы явно пропишем адреса менеджеров лицензий:

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.10, 192.168.1.11
NH_USE_BROADCAST = Disabled

В параметре NH_SERVER_ADDR мы указываем IP-адреса только тех компьютеров, где установлены сетевые ключи на 50 и 100 пользователей с запущенными службами HASP LM. Адрес сервера «1С» сюда вносить не нужно. Отключение широковещательного поиска с помощью параметра NH_USE_BROADCAST = Disabled гарантирует, что клиенты не займут лицензии с «серверного» ключа случайным образом.

Решение 3: Использование ключей запуска для тонких клиентов

Если часть пользователей подключается к зарплатной базе не через браузер, а с помощью тонкого клиента 1С, они по умолчанию могут пытаться получить лицензию самостоятельно из сети через HASP LM. Чтобы заставить их получать лицензии строго от сервера 1С, проанализируем параметры запуска информационной базы.

В окне запуска «1С:Предприятия» выделим нужную базу, нажмем кнопку «Изменить», перейдем на последнюю вкладку параметров и в поле «Дополнительные параметры запуска» пропишем специальный ключ:

/UseHwLicenses-

Этот параметр принудительно запрещает локальному тонкому клиенту опрашивать локальные порты компьютера и искать сетевые ключи HASP по сети. Клиент будет запускаться только в том случае, если лицензию ему выделит сам сервер «1С:Предприятия».

Решение 4: Оптимизация времени жизни веб-сессий в кластере

Чтобы минимизировать проблему «зависания» лицензий из-за некорректно закрытых вкладок браузера веб-клиентами, нам необходимо настроить параметры очистки спящих сеансов в консоли администрирования кластера «1С».

Выполним следующие шаги:

1. Откроем утилиту «Администрирование серверов 1С Предприятия».
2. Подключимся к нашему кластеру и перейдем в ветку Информационные базы.
3. Найдем нашу зарплатную базу, откроем ее свойства (потребуется ввести логин и пароль администратора базы).
4. Обратим внимание на параметры времени жизни сеансов. По умолчанию они могут быть отключены или настроены на слишком длительный период. Нам необходимо установить оптимальные значения:
   • Время засыпания пассивного сеанса: установим значение 1200 секунд (20 минут). Если пользователь не проявляет активность в веб-кабинете 20 минут, его сеанс «засыпает», высвобождая лицензию в общий пул сервера.
   • Время завершения спящих сеансов: установим значение 120 секунд (2 минуты). Спящий сеанс будет окончательно удален сервером, если активность не возобновится.
5. Нажмем «Применить» для сохранения настроек.

Эти параметры позволят серверу оперативно реагировать на закрытые вкладки браузеров и возвращать лицензии обратно в пул, предотвращая их лавинообразное исчерпание.

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