Как задействовать два сетевых аппаратных ключа 1С в файловой базе при работе через веб-сервер?

Разберем распространенную ситуацию: организация использует файловую базу 1С:Предприятие 8.3, опубликованную на веб-сервере Apache для подключения тонких и веб-клиентов. Для обеспечения доступа имеются два аппаратных сетевых ключа защиты по 10 лицензий каждый. Первый ключ установлен непосредственно в сервере, второй подключен к соседнему компьютеру в локальной сети, где функционирует менеджер лицензий HASP License Manager. При подключении одиннадцатого пользователя возникает ошибка: свободных лицензий нет. Выясним, почему веб-сервер не видит второй ключ, и рассмотрим практические способы решения этой проблемы без дорогостоящей покупки объединенного ключа.

Почему веб-сервер не суммирует аппаратные ключи одной серии

Проанализируем механику работы системы защиты 1С. Сетевые аппаратные ключи на 10 рабочих мест принадлежат к одной серии — ORGL8. Согласно протоколу NetHASP, одно приложение (в данном случае рабочий процесс веб-сервера httpd.exe) не способно самостоятельно суммировать лицензии с нескольких менеджеров лицензий, если они раздают ключи одной и той же серии.

При запуске процесс веб-сервера выполняет широковещательный поиск (broadcast-запрос по порту UDP 475) или опрашивает локально вставленный USB-ключ. Обнаружив первый ответивший ключ, модуль расширения веб-сервера монопольно закрепляется за ним. Когда лимит в 10 подключений исчерпывается, процесс не опрашивает сеть повторно в поисках других доступных ключей той же серии, а сразу генерирует ошибку нехватки лицензий. В файловом режиме именно веб-сервер выступает в роли клиента, получающего лицензии от имени пользователей, что и порождает данное ограничение.

Способ 1. Запуск двух экземпляров веб-сервера с жесткой привязкой через nethasp.ini

Рассмотрим вариант разделения сеансов на одном сервере. Для этого запустим две независимые службы Apache на разных сетевых портах (например, 80 и 8080), каждая из которых будет принудительно направлена на свой менеджер лицензий.

Разберем настройку по шагам:

1. Настроим службы HASP License Manager. На обоих компьютерах (на сервере и на втором ПК с ключом) откроем файл конфигурации менеджера лицензий nhsrv.ini. Зададим уникальные имена серверов защиты с помощью параметра NHS_SERVERNAMES, например LM_SRV1 на первом сервере и LM_SRV2 на соседнем компьютере.
2. Установим и сконфигурируем два независимых экземпляра веб-сервера Apache в отдельные каталоги, настроив их конфигурационные файлы httpd.conf на разные порты прослушивания. В обоих экземплярах опубликуем одну и ту же файловую базу 1С.
3. В каталог исполняемых файлов первой службы Apache (в папку bin) поместим файл nethasp.ini, жестко связывающий службу с первым ключом. Отключим широковещательный поиск и укажем точный IP-адрес:

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

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.10
NH_SERVER_NAME = LM_SRV1
NH_USE_BROADCAST = Disabled

1. В каталог bin второго экземпляра Apache поместим другой файл nethasp.ini, указывающий на IP-адрес соседнего компьютера:

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

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.20
NH_SERVER_NAME = LM_SRV2
NH_USE_BROADCAST = Disabled

Теперь первая служба берет 10 лицензий от первого ключа, а вторая — 10 от второго. Распределим пользователей: 10 человек подключаются по порту 80, а остальные 10 — по порту 8080. При необходимости прозрачного входа перед веб-серверами можно настроить обратный прокси-сервер с балансировкой и обязательной фиксацией сессий (sticky sessions), чтобы активная пользовательская сессия не переключалась между серверами.

Способ 2. Публикация базы на втором компьютере

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

1. Откроем общий сетевой доступ к каталогу с базой данных на основном сервере, предоставив полные права учетной записи, от имени которой запускается веб-сервер.
2. Установим платформу 1С и веб-сервер (Apache или IIS) на второй машине.
3. Опубликуем базу на втором компьютере, указав в качестве пути к данным сетевой UNC-путь к файловой базе (например, \\SERVER\1C_Base).
4. Первый веб-сервер будет черпать лицензии из локального ключа, а второй веб-сервер — со своего локального ключа. Десять пользователей заходят по адресу первого веб-сервера, десять — по адресу второго.

Способ 3. Получение лицензий на стороне клиентов через VPN

Если удаленные сотрудники используют тонкий клиент 1С (а не веб-браузер), можно полностью снять нагрузку по лицензированию с веб-сервера. Тонкий клиент способен находить ключ защиты самостоятельно на машине пользователя.

1. Организуем защищенное VPN-подключение пользователей к локальной сети компании.
2. Убедимся, что сетевой порт UDP 475 доступен через VPN-туннель до обоих компьютеров с ключами.
3. В свойствах информационной базы в окне запуска тонкого клиента отключим использование лицензии, предоставляемой сервером (параметр «Использовать аппаратную лицензию сервера»).
4. Половине удаленных пользователей в локальный конфигурационный файл nethasp.ini (расположенный в каталоге платформы conf) пропишем IP-адрес первого менеджера лицензий, а второй половине — IP-адрес второго менеджера, обязательно установив параметр NH_USE_BROADCAST = Disabled.

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

Способ 4. Переход на программные лицензии

Рассмотрим финансовую сторону вопроса. Замена двух USB-ключей по 10 пользователей на один аппаратный ключ на 20 лицензий требует доплаты разницы в стоимости ключей (апгрейд "железо на железо"). Однако фирма «1С» предоставляет процедуру перехода с аппаратных USB-ключей на программные лицензии (пинкоды). Стоимость обмена двух аппаратных ключей на один комплект программной лицензии на 20 пользователей обходится значительно дешевле покупки нового USB-ключа и решает вопрос ограничений сетевого поиска навсегда.

Критические риски и ограничения файлового режима

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

1. Разрядность веб-сервера: Крайне важно использовать исключительно 64-разрядные версии Apache и модуля расширения wsap24.dll. 32-разрядный процесс ограничен адресным пространством в 2–3 ГБ. При работе 20 пользователей в файловой базе память процесса быстро исчерпывается, что приводит к аварийному завершению службы с ошибкой нехватки памяти.
2. Блокировки файла 1Cv8.1CD: При одновременной активной работе 20 пользователей файловая база испытывает серьезные проблемы с табличными блокировками. Это может приводить к взаимным блокировкам (deadlocks), снижению производительности при проведении документов и риску повреждения файла базы. При таком количестве рабочих мест штатным и надежным решением является переход на клиент-серверный вариант (SQL).