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

← На главную

При администрировании крупных сетей «1С:Предприятия» системные администраторы часто сталкиваются с ситуацией, когда на балансе организации находится несколько многопользовательских аппаратных ключей защиты USB HASP (например, два ключа на 20 пользователей и один на 10). Казалось бы, суммарно сеть должна обеспечивать работу 50 пользователей. Однако на практике возникает классическая проблема: пользователи периодически получают ошибку «Нет свободной лицензии», а утилита мониторинга Aladdin Monitor (HL Monitor) упорно показывает, что занята всего одна или две лицензии, игнорируя реальные сессии пользователей.

В этой статье мы подробно разберем, почему возникает такое поведение системы защиты, как устроена раздача лицензий сервером «1С» и менеджером лицензий HASP LM, а также как настроить стабильную совместную работу нескольких аппаратных ключей по схеме «20 + 20 + 10».

Почему Aladdin Monitor не видит все активные лицензии?

Выясним причину, по которой утилита мониторинга Aladdin Monitor (AKSMon) может некорректно отображать сетевую активность ключей или не видеть подключенных пользователей вовсе. Для этого проанализируем специфику работы самой утилиты:

Ограничение по первому запросу: Утилита Aladdin Monitor спроектирована таким образом, что она не отображает сетевой ключ в списке доступных до тех пор, пока с этого конкретного ключа не будет запрошена и успешно выдана хотя бы одна лицензия. Если менеджер лицензий HASP LM на одном из серверов запущен, но к нему еще никто не обратился за лицензией, этот ключ будет невидим в мониторе.
Особенности сетевых протоколов: Монитор работает строго по протоколу UDP через порт 475. При этом сама платформа «1С» способна запрашивать лицензии у HASP LM как по протоколу UDP, так и по TCP. Если в вашей локальной сети или на брандмауэрах серверов заблокирован UDP-трафик на порт 475, но открыт TCP, пользователи будут успешно запускать «1С» и работать, однако утилита Aladdin Monitor их сессии не зафиксирует.
Несовместимость типов ключей: Современная панель управления Sentinel ACC (Admin Control Center, порт 1947) предназначена для более современных ключей HASP HL/SR. Классические многопользовательские USB-ключи HASP4 (серии ORGL8 красного цвета) в ней не отображаются. Для работы со старыми ключами «1С» необходимо использовать именно классический Aladdin Monitor.

Различие между раздачей лицензий сервером 1С и напрямую через HASP LM

Чтобы понять, почему платформа не задействует все доступные USB-ключи, рассмотрим два принципиально разных механизма выдачи лицензий:

Вариант А: Раздача лицензий сервером «1С»

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

Здесь вступают в силу жесткие ограничения архитектуры защиты «1С»:

Лицензии выдаются на каждый запуск (сессию). Если один пользователь на своем ПК запустит три разные базы «1С», сервер спишет у него 3 отдельные лицензии.
Сервер «1С» умеет работать одновременно только с одним локальным ключом одной серии и только с одним сетевым ключом той же серии.

Поскольку все многопользовательские ключи для «1С» (на 20, 50, 100 пользователей) относятся к одной серии ORGL8, сервер «1С» при включенной раздаче физически сможет использовать максимум два ключа (один локальный, установленный в сервер, и один сетевой, найденный в сети). Третий ключ (например, на 10 пользователей) будет полностью проигнорирован. Именно поэтому формула «20 + 20 + 10» в данном режиме не работает.

Вариант Б: Раздача лицензий напрямую через HASP LM (рекомендуемый)

В настройках свойств базы в консоли кластера установлена опция Разрешить выдачу лицензий сервером 1С:Предприятия = Нет. В этом сценарии клиентские приложения при старте самостоятельно ищут ключи защиты в локальной сети, отправляя широковещательные запросы или обращаясь по конкретным IP-адресам к службам HASP Loader (HASP LM).

Преимущества этого режима:

Лицензия выдается на компьютер (рабочее место). Пользователь может запустить сколько угодно баз «1С» на своем ПК, но при этом будет израсходована всего одна лицензия.
Снимаются ограничения сервера на количество используемых ключей. Каждый клиент забирает лицензию с того менеджера HASP LM, до которого смог достучаться. Схема «20 + 20 + 10» начинает работать на полную мощность, суммируя все 50 лицензий.

Анализируем статусы лицензий в консоли кластера 1С

Разберем подробнее, что значат обозначения в колонке «Лицензия» списка активных сеансов консоли администрирования кластера «1С»:

«Локальный HASP4 ORGL8 20»: Означает, что сервер приложений «1С» обнаружил многопользовательский ключ на 20 лицензий, установленный непосредственно в USB-порт самого сервера, и успешно раздает его лицензии сеансам.
«Сетевой HASP4 ORGL8 20»: Указывает на то, что лицензия получена с ключа на 20 пользователей, установленного на другом компьютере в сети через службу менеджера лицензий HASP LM.
«Локальный HASP4 ORGL8 1»: Платформа обнаружила локальный однопользовательский ключ (фиолетовый USB-токен с маркировкой H4 M1 ORGL8), подключенный непосредственно к компьютеру пользователя.

Проблема «эффекта блуждающих лицензий» и зависания на 36 часов

Если в вашей сети работает несколько служб HASP LM на разных компьютерах, вы можете столкнуться с дефицитом лицензий из-за их зависания. Рассмотрим механизм этой проблемы.

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

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

Пошаговый план настройки совместной работы схемы 20 + 20 + 10

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

Шаг 1. Отключение раздачи лицензий сервером «1С»

Нам необходимо перевести клиенты на самостоятельный поиск ключей. Для этого:

Откроем консоль администрирования кластера серверов «1С:Предприятия».
Перейдем в список информационных баз.
Откроем свойства каждой информационной базы.
Найдем параметр «Разрешить выдачу лицензий сервером 1С:Предприятия» и установим для него значение «Нет» (или False).

Шаг 2. Разделение клиентов по менеджерам лицензий через nethasp.ini

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

Этот файл обычно находится по пути: C:\Program Files\1cv8\conf\nethasp.ini (или в каталоге конкретной версии платформы).

Разделим пользователей на три группы. Например, для первой группы в 20 человек укажем адрес первого сервера лицензий:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCP/IP]
NH_SERVER_ADDR = 192.168.1.10  ; IP-адрес первого сервера HASP LM (ключ на 20)
NH_USE_BROADCAST = Disabled
NH_TCPIP_METHOD = TCP

Для второй группы пользователей (следующие 20 человек) укажем в файле nethasp.ini адрес второго сервера:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCP/IP]
NH_SERVER_ADDR = 192.168.1.11  ; IP-адрес второго сервера HASP LM (ключ на 20)
NH_USE_BROADCAST = Disabled
NH_TCPIP_METHOD = TCP

Для оставшихся 10 пользователей пропишем адрес третьего ПК с ключом:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCP/IP]
NH_SERVER_ADDR = 192.168.1.12  ; IP-адрес третьего сервера HASP LM (ключ на 10)
NH_USE_BROADCAST = Disabled
NH_TCPIP_METHOD = TCP

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

Шаг 3. Устранение коллизий имен в файле nhsrv.ini

Когда в пределах одной подсети работают три службы HASP LM, они по умолчанию регистрируют одинаковое NetBIOS-имя в сети, что может приводить к конфликтам. Чтобы избежать этого, зададим уникальное имя для каждой службы HASP LM.

На каждом из трех серверов, где физически установлены USB-ключи, найдем файл конфигурации службы менеджера лицензий nhsrv.ini (он располагается в папке установки HASP LM, например, C:\Program Files (x86)\Aladdin\HASP LM\):

На первом сервере (IP 192.168.1.10) раскомментируем и изменим строку:

NHS_SERVERNAMES = LM_SERVER_1

На втором сервере (IP 192.168.1.11) пропишем:

NHS_SERVERNAMES = LM_SERVER_2

На третьем сервере (IP 192.168.1.12) укажем:

NHS_SERVERNAMES = LM_SERVER_3

После внесения изменений в файл nhsrv.ini обязательно перезапустим службу HASP Loader на каждом из серверов через оснастку services.msc.

Анализ последствий изменения настроек «на горячую»

Рассмотрим, можно ли проводить данные изменения в разгар рабочего дня и к чему это приведет:

Для активных сессий: Те пользователи, которые уже запущены и успешно работают в «1С», получив лицензию от сервера приложений, не будут отключены сразу. Они смогут продолжить свою работу до закрытия программы.
Для новых подключений: Сразу после изменения настройки в свойствах СУБД новые сеансы начнут запрашивать лицензию локально со своих рабочих мест.
Основные риски: Если вы решите отключить раздачу лицензий сервером «на горячую» без предварительной настройки файлов nethasp.ini на рабочих станциях пользователей и без проверки доступности портов 475 (UDP/TCP), новые пользователи не смогут запустить систему и получат ошибку отсутствия лицензии. Рекомендуется выполнять данные изменения в технологическое окно, когда в базах нет активных пользователей.

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