Как связать разные лицензии 1С с конкретными информационными базами: детальное руководство

При администрировании серверов 1С в компаниях с несколькими независимыми филиалами или юридическими лицами часто возникает специфическая задача. Имеется один производительный сервер 1С и несколько купленных комплектов программных лицензий (например, для Фирмы 1 и Фирмы 2). По умолчанию сервер 1С раздает лицензии из общего пула по принципу "первой свободной". Это приводит к тому, что пользователи Фирмы 2 могут полностью исчерпать лицензии Фирмы 1, заблокировав им работу.

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

Почему нельзя настроить разделение внутри одного кластера?

Многие администраторы пытаются решить проблему через механизм Требований назначения функциональности (ТНФ) в консоли администрирования кластера 1С. Логика кажется простой: создать правило, при котором определенный рабочий сервер обслуживает конкретную информационную базу.

Однако здесь мы упираемся в жесткое техническое ограничение платформы. Согласно официальной документации 1С, параметр ТНФ Имя информационной базы может использоваться для фильтрации практически всех сервисов кластера, кроме сервиса лицензирования. Сервис лицензирования работает глобально для всего кластера и не умеет анализировать, к какой именно базе подключается пользователь в данный момент. Следовательно, распределить лицензии по базам внутри одного стандартного кластера штатными настройками невозможно.

Для решения этой задачи нам потребуется применить более глубокие архитектурные подходы. Ниже мы детально проанализируем самые надежные методы.

Способ 1. Создание микро-серверов лицензирования в разных кластерах

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

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

Разберем этот процесс по шагам:

1. Создание дополнительных кластеров. На основном рабочем сервере 1С в консоли администрирования создаем дополнительный кластер серверов. По умолчанию основной кластер работает на порту 1541. Для второго кластера назначаем другой порт менеджера кластера (например, 1641).
2. Распределение баз. Переносим информационную базу Фирмы 2 во второй кластер (порт 1641), удалив ее из первого кластера. Теперь наши базы физически изолированы на уровне разных кластеров.
3. Подготовка виртуальных машин лицензирования. Разворачиваем небольшую виртуальную машину (ВМ) с минимальными системными ресурсами. На нее устанавливаем ту же версию платформы 1С:Предприятие, что и на основном сервере. Лицензия на сервер 1С для этой ВМ не требуется.
4. Интеграция ВМ в кластер. В консоли администрирования основного сервера 1С (для кластера 1641) добавляем новый рабочий сервер, указав сетевой адрес нашей виртуальной машины.
5. Настройка требований назначения функциональности. Для добавленного сервера ВМ настраиваем ТНФ следующим образом:
   • Для объекта Любой объект устанавливаем значение Не назначать.
   • Для объекта Сервис лицензирования устанавливаем значение Назначать.
   На основном рабочем сервере кластера 1641 для сервиса лицензирования устанавливаем значение Не назначать. Таким образом, сервер кластера будет выполнять все вычислительные задачи, но за лицензиями он будет принудительно обращаться к нашей ВМ.
6. Активация лицензии. Заходим в базу кластера 1641 и активируем лицензию Фирмы 2. В диалоговом окне активации в разделе "Дополнительно" указываем, что лицензия должна быть привязана и зарегистрирована на сервере нашей виртуальной машины.

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

Способ 2. Оптимизированный метод с запуском нескольких служб 1С на одном сервере

Если баз много (например, более 10), разворачивать под каждую базу отдельную виртуальную машину может быть слишком затратно с точки зрения ресурсов гипервизора. В этом случае мы можем модернизировать первый способ и обойтись всего одной вспомогательной виртуальной машиной (или выполнить все действия прямо на физическом сервере).

Рассмотрим, как настроить изоляцию лицензий через системные службы:

1. На выделенном сервере лицензирования создаем столько независимых системных служб сервера 1С, сколько у нас изолированных баз данных. Создание служб под управлением Windows выполняется через командную строку утилитой sc create. Каждую службу вешаем на свой порт.
2. Каждую службу запускаем от имени отдельного локального пользователя операционной системы (например, USR1CV8_Firm1, USR1CV8_Firm2 и т.д.).
3. В операционной системе переходим в каталог, где хранятся файлы программных лицензий (по умолчанию это C:\ProgramData\1C\Licenses).
4. Для каждого файла лицензии .lic заходим в свойства безопасности файла и жестко ограничиваем права доступа: разрешаем чтение файла только тому пользователю ОС, под которым запущена служба соответствующей фирмы. Все остальные пользователи (включая учетные записи других служб 1С) должны быть лишены прав на этот файл.
5. На основном сервере привязываем каждый кластер к соответствующей службе лицензирования по ее уникальному порту.

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

Способ 3. Изоляция лицензий на уровне терминального сервера (для RDP-клиентов)

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

Платформа 1С осуществляет поиск файлов лицензий по приоритетным путям, одним из которых является папка conf каталога исполняемых файлов конкретной версии платформы. Мы можем использовать это для разделения пулов:

1. Устанавливаем на терминальный сервер два разных релиза платформы 1С (например, 8.3.23.1865 и 8.3.24.1350). Также можно использовать один релиз, просто скопировав содержимое папки установки в две разные директории (например, в C:\1C_Firm1\bin и C:\1C_Firm2\bin).
2. Файлы лицензий .lic для Фирмы 1 копируем строго в каталог C:\1C_Firm1\bin\conf.
3. Файлы лицензий для Фирмы 2 помещаем в каталог C:\1C_Firm2\bin\conf.
4. В настройках списка баз в окне запуска 1С для каждой информационной базы переходим в свойства и в поле "Версия платформы" жестко прописываем путь или версию, которую необходимо использовать при запуске.

Когда пользователь запустит базу Фирмы 1, стартует экземпляр платформы из папки C:\1C_Firm1\bin. Он найдет файл лицензии в своем локальном каталоге conf и успешно запустится. При этом лицензия Фирмы 2 останется недоступной и нетронутой, так как платформа из первого каталога ничего не знает о файлах во второй директории.

Способ 4. Сегментация на уровне сети с помощью аппаратных ключей HASP

В случае, если в вашей инфраструктуре используются многопользовательские аппаратные USB-ключи защиты, задача разделения лицензий решается стандартными конфигурационными файлами HASP License Manager.

Для разграничения доступа выполним следующие настройки:

1. Устанавливаем USB-ключи на разные физические компьютеры или пробрасываем их в разные виртуальные машины в сети. На каждой машине должен быть запущен свой сетевой менеджер лицензий HASP License Manager.
2. На терминальном сервере или клиентских компьютерах пользователей переходим в каталог настроек 1С и находим файл конфигурации сетевого ключа nethasp.ini.
3. Для пользователей Фирмы 1 прописываем в файле nethasp.ini явный IP-адрес того менеджера лицензий, в который вставлен ключ Фирмы 1. Пример настройки секции:

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; IP-адрес HASP-сервера Фирмы 1
NH_PORT_NUMBER = 475

4. Для пользователей Фирмы 2 настраиваем аналогичный файл nethasp.ini, но указываем IP-адрес сервера лицензий Фирмы 2 (например, 192.168.1.200).

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

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

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

Малоизвестный, но крайне полезный факт: начиная с версии платформы 8.3.12.1790, программную лицензию при активации можно привязать не к физическим параметрам компьютера, а к сетевому аппаратному ключу защиты HASP. Если в вашей сети присутствует хотя бы один аппаратный ключ 1С, вы можете активировать программную лицензию с привязкой к его ID. После этого виртуальные машины серверов лицензирования можно свободно перемещать, изменять их конфигурацию и перезапускать — лицензии никогда не "слетят", пока в сети доступен указанный USB-ключ.