Как настроить раздачу лицензий 1С через HASP LM при наличии программных лицензий и нескольких серверов?

В современной инфраструктуре «1С:Предприятие 8.3» часто встречается гибридная схема лицензирования, когда на одном сервере сосуществуют аппаратные ключи защиты (HASP) и программные лицензии (активационные коды). При добавлении в сеть второго сервера 1С системные администраторы часто сталкиваются с проблемой: пользователи нового сервера не могут получить лицензии с первого сервера, хотя сетевой менеджер лицензий (HASP LM) настроен и исправно работает. Разберем детально, как устроена эта механика и как правильно сконфигурировать систему.

Различие между аппаратными и программными лицензиями

Проанализируем первую и самую важную ошибку в понимании процесса: HASP LM (License Manager) не имеет никакого отношения к программным лицензиям. Это специализированная утилита, предназначенная исключительно для «проброса» по сети ресурсов аппаратного USB-ключа.

Рассмотрим, как распределяются задачи:

1. HASP LM — видит только «железо». Если у вас стоит ключ на 20 пользователей, менеджер лицензий будет раздавать именно эти 20 слотов. О программных лицензиях (файлах с расширением .lic), установленных на этом же сервере, он «не знает».
2. Сервер 1С (rmngr) — умеет раздавать и программные лицензии, и аппаратные (если он их видит локально или по сети).

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

Порядок поиска лицензий платформой

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

1. Локальный поиск: сначала проверяются программные лицензии на компьютере пользователя, затем локальный USB-ключ.
2. Сетевой поиск (HASP LM): если локально ничего не найдено, клиент обращается к сетевым менеджерам лицензий, настройки которых описаны в файле nethasp.ini.
3. Запрос у сервера 1С: если клиент сам не нашел лицензию, он просит её у сервера приложений 1С. Сервер выдает её из своего пула (сначала программные, затем аппаратные), если в настройках информационной базы разрешена выдача лицензий сервером.

Настройка файла nethasp.ini для гарантированного получения лицензий

Когда в сети появляется второй сервер, клиенты которого должны забирать аппаратные лицензии с первого сервера, необходимо точно настроить файл nethasp.ini. Разберем типичную ситуацию, когда широковещательная рассылка (broadcast) в сети отключена или ограничена маршрутизаторами (например, при использовании разных подсетей или VPN).

Посмотрим на пример правильной настройки файла nethasp.ini на стороне клиента:

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
;; Указываем адрес сервера, где физически установлен ключ и запущен HASP LM
NH_SERVER_ADDR = 192.168.1.10 
;; Рекомендуется использовать IP-адрес для исключения проблем с DNS
NH_TCPIP_METHOD = TCP
;; Отключаем широковещание, если адрес указан явно
NH_USE_BROADCAST = Disabled

Важный нюанс: как показала практика (сообщение 22 обсуждения), иногда платформа ведет себя специфически, и вместо IP-адреса в параметре NH_SERVER_ADDR может потребоваться указание DNS-имени сервера. Если лицензия не «откусывается» по IP, попробуйте указать имя хоста.

Ограничение «Один ключ одной серии»

Проанализируем техническое ограничение, которое часто становится «невидимой» преградой. Программный комплекс 1С использует ключи серии ORGL8 для клиентских лицензий.

Важно: HASP LM на одном физическом сервере может обслуживать только один ключ серии ORGL8. Если вы вставите в сервер два ключа (например, на 20 и на 50 пользователей), менеджер лицензий выберет только один из них (обычно с меньшим количеством лицензий или первый инициализированный).

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

Проблема «поглощения» лицензий сервером 1С

Рассмотрим ситуацию: на сервере №1 установлены программные лицензии (20 шт.) и аппаратный ключ (20 шт.). Сервер №1 по умолчанию будет пытаться задействовать все доступные ресурсы.

Если вы хотите, чтобы аппаратный ключ гарантированно доставался пользователям сервера №2, необходимо запретить серверу №1 «трогать» аппаратный ключ. Для этого выполним следующие шаги:

1. Найдем файл конфигурации сервера conf.cfg (обычно в каталоге conf установленной платформы).
2. Добавим или изменим параметр: Hasps=0.

Это заставит Сервер 1С №1 игнорировать аппаратные ключи и работать только с программными лицензиями. Таким образом, все 20 лицензий аппаратного ключа останутся свободными для выдачи через HASP LM пользователям второго сервера.

Привязка программных лицензий к HASP-ключу

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

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

Мониторинг использования лицензий

Чтобы убедиться, что всё работает правильно, используем специализированные инструменты:

• Aladdin Monitor (AKS Monitor): Позволяет видеть в реальном времени, сколько лицензий занято именно на аппаратном ключе, с каких IP-адресов пришли запросы и сколько слотов свободно.
• Консоль администрирования сервера 1С: В разделе «Сеансы» можно проанализировать колонку «Лицензия». Там будет четко указано, какая лицензия используется сеансом: программная (с указанием пути к файлу или серийного номера) или аппаратная (через HASP LM или локально).

Таким образом, для решения проблемы раздачи лицензий на второй сервер мы должны: четко разделить зоны ответственности программного и аппаратного метода, правильно настроить nethasp.ini на клиентах, при необходимости изолировать сервер от ключа через conf.cfg и убедиться в отсутствии конфликтов серий ключей.