Как устранить двойной расход HASP-лицензий в 1С при совместном использовании платформ 8.1, 8.2 и 8.3?

← На главную

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

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

Почему один IP-адрес занимает несколько лицензий с разных ключей?

Рассмотрим классическую ситуацию: на предприятии развернуто несколько аппаратных ключей защиты (например, один ключ на 5 пользователей, другой — на 10), которые обслуживаются разными менеджерами лицензий (HASP License Manager) на разных серверах в локальной сети. На рабочих местах пользователей отключена выдача лицензий сервером «1С:Предприятие» (в настройках информационных баз параметр «Разрешить выдачу лицензий сервером» установлен в значение «Нет»). Это сделано для того, чтобы лицензировался именно компьютер пользователя (клиентское место), а не каждый запущенный сеанс.

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

Выясним причину, почему это правило нарушается в многоплатформенной среде:

Широковещательный опрос (Broadcast): По умолчанию клиентское приложение 1С при запуске отправляет UDP-запрос по всей локальной сети в поисках доступных ключей. Если в сети работают несколько менеджеров лицензий, ответ может прийти от любого из них. Скорость ответа зависит от загрузки сети и производительности серверов.
Разделение запросов по версиям: Когда пользователь запускает базу на платформе 8.2, система выполняет поиск и захватывает свободный слот, например, на ключе №1. Спустя минуту этот же пользователь запускает базу на платформе 8.3. Новая платформа инициирует собственный поиск лицензии. Из-за сетевых задержек или занятости первого ключа запрос перенаправляется на ключ №2.
Фиксация разных лицензий: Поскольку сессии одной рабочей станции оказались привязаны к разным физическим ключам на разных серверах, механизм HASP LM не может объединить их под одной лицензией. В мониторе лицензий (Aladdin Monitor) системный администратор увидит, что один и тот же компьютер с одним IP-адресом занял две сетевые лицензии на разных ключах.

Шаг 1. Жесткая настройка nethasp.ini на рабочих станциях

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

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

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


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.10 ; IP-адрес конкретного сервера с менеджером лицензий HASP LM
NH_PORT_NUMBER = 475          ; Стандартный порт службы NetHASP
NH_TCPIP_METHOD = TCP         ; Использовать надежный протокол TCP вместо UDP
NH_USE_BROADCAST = Disabled   ; КРИТИЧЕСКИ ВАЖНО: отключить широковещательный поиск ключей

Обратите внимание на параметр NH_USE_BROADCAST = Disabled. Именно он предотвращает неконтролируемый опрос всей сети и исключает ситуацию, когда разные сеансы одного пользователя «разлетаются» по разным ключам.

Шаг 2. Учет разницы каталогов nethasp.ini для версий 8.1, 8.2 и 8.3

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

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

Для платформы 1С:Предприятие 8.1 (в зависимости от разрядности ОС):
C:\Program Files\1cv81\bin\conf\nethasp.ini или C:\Program Files (x86)\1cv81\bin\conf\nethasp.ini
Для платформы 1С:Предприятие 8.2:
C:\Program Files (x86)\1cv82\bin\conf\nethasp.ini
Для платформы 1С:Предприятие 8.3:
Общий каталог для всех релизов: C:\Program Files\1cv8\conf\nethasp.ini (или C:\Program Files (x86)\1cv8\conf\nethasp.ini для 32-битного клиента). Также допускается размещение в папке конкретного релиза, например: C:\Program Files\1cv8\8.3.22.1709\bin\conf\nethasp.ini.

Рекомендация: Чтобы обеспечить стабильное поведение лицензирования, скопируйте идентичный, предварительно настроенный файл nethasp.ini во все вышеуказанные каталоги на рабочей станции пользователя. Только в этом случае запуск баз на 8.1, 8.2 и 8.3 будет подчиняться единому правилу маршрутизации запросов.

Решение проблемы: «Запущено Предприятие, но Конфигуратор требует лицензию»

Рассмотрим еще одну частую проблему: на пользовательском компьютере успешно запущена и работает информационная база в режиме «Предприятие», но при попытке зайти в эту же или соседнюю базу в режиме «Конфигуратор» система выдает ошибку: «Доступная лицензия не найдена». Выясним основные причины этой неполадки:

1. Опрос неверного ключа из-за кэширования

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

2. Локальное исчерпание лимита на ключе

Если на сервере лицензирования установлен ключ небольшой емкости (например, на 5 пользователей) и в момент запуска «Конфигуратора» все 5 лицензий уже заняты активными сессиями «Предприятия» других сотрудников, HASP License Manager не сможет выделить временный технический слот для авторизации сессии «Конфигуратора». Несмотря на то, что для одного компьютера лицензия должна «схлопываться», при физическом отсутствии свободных слотов на ключе в момент инициации запроса менеджер лицензий может вернуть отказ.

Оптимизация «зависающих» лицензий в терминальных сессиях (RDP)

Системные администраторы часто сталкиваются с ситуацией, когда пользователи закрыли 1С или их RDP-сессия завершилась аварийно, но лицензия продолжает удерживаться менеджером лицензий. По умолчанию HASP License Manager может удерживать неактивное соединение до 36 часов.

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

Откройте файл nhsrv.ini на сервере лицензирования.
Найдите и отредактируйте параметры, ограничивающие время простоя сессий и интервалы проверки активности клиентов. Например, с помощью параметра NHS_CLIENT_TIMEOUT можно задать интервал времени в минутах, по истечении которого неактивный клиент будет отключен от ключа.
Дополнительно настройте параметры сетевой активности операционной системы (KeepAlive) в реестре Windows на сервере терминалов, чтобы ОС быстрее закрывала оборванные сетевые сокеты. Для этого в ветке реестра HKLM\System\CurrentControlSet\Services\Tcpip\Parameters установите значение параметра KeepAliveTime на уровне 300 000 миллисекунд (5 минут).

Переход на программные лицензии: подводные камни, о которых нужно знать заранее

Когда руководство компании сталкивается с дороговизной объединения или замены старых аппаратных USB-ключей у партнеров-франчайзи, часто принимается решение о переходе на программные лицензии (пин-коды). Рассмотрим важные технические нюансы такого перехода, которые могут кардинально изменить экономику проекта.

Главное отличие аппаратных лицензий от программных заключается в методике их подсчета:

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

Таким образом, при переходе с аппаратных ключей на программные (при серверной раздаче) вам может потребоваться приобрести в 1.5–2 раза больше лицензий для обеспечения бесперебойной работы того же штата сотрудников. Альтернативный вариант — активировать программные лицензии локально на каждом клиентском компьютере (тогда они будут работать «покомпьютерно»), однако это существенно усложнит администрирование при модернизации ПК, переустановке Windows или замене комплектующих, так как каждая конфигурация потребует траты резервных пин-кодов для повторной активации.