При работе с системой 1С:Предприятие 8.3 в клиент-серверной архитектуре мы часто сталкиваемся с необходимостью правильно настроить и контролировать использование лицензий. В этой статье мы подробно разберем, как мониторить клиентские лицензии, как они выдаются в смешанной инфраструктуре (программные и аппаратные), и что делать в случае, если программные лицензии перестали работать из-за ошибки привязки.
Представим типовую ситуацию, когда у нас есть два сервера 1С:Предприятия в одном домене и одной подсети, оба настроены на клиент-серверный режим:
Сервер 1С (СРВ1): На нем установлена галка "Разрешить выдачу лицензий сервером". В него воткнут аппаратный USB-ключ на 100 клиентов, и на этом же сервере работает Hasp LM (License Manager) для раздачи аппаратных лицензий.
Сервер 1С (СРВ2): Также установлена галка "Разрешить выдачу лицензий сервером". На этом сервере установлены программные лицензии на 50 клиентов.
С такой архитектурой возникают вопросы о том, как правильно будут выдаваться лицензии и как контролировать их использование. Давайте вместе проанализируем эти аспекты.
Один из ключевых вопросов – как получить информацию о том, сколько программных лицензий фактически используется и кто их потребляет. Рассмотрим доступные методы:
Консоль кластера серверов 1С:Предприятия: Это основной инструмент для мониторинга активных сеансов и используемых ими лицензий. В разделе "Сеансы" или "Активные сеансы" консоли кластера мы можем увидеть список подключений. Колонка "Лицензия" в этом списке обычно отображает тип и количество используемых лицензий, например, ORGL Сет 100 для аппаратного ключа или клиент 1/50 для программной лицензии.
Важно: Иногда мы можем увидеть сеансы с пустым значением в колонке "Лицензия". Это может произойти по нескольким причинам:
Лицензия получена непосредственно клиентом: Если клиентское приложение 1С самостоятельно получило лицензию (например, локальную клиентскую лицензию или сетевую лицензию от HASP LM), минуя сервер 1С:Предприятия, сервер может не отображать информацию об этой лицензии в своей консоли, так как он не участвовал в ее выдаче.
Проблемы с отображением или кэшированием: Иногда это может быть связано с особенностями отображения данных в консоли или с кэшированием информации.
"Тонкий" клиент в режиме веб-сервера: Если используется веб-клиент или тонкий клиент, который взаимодействует с веб-сервером, а веб-сервер уже подключен к кластеру 1С, то информация о лицензии может быть менее детализирована в консоли кластера 1С, так как сеанс проходит через промежуточное звено.
Временные сбои: В редких случаях это может быть результатом временных сбоев в работе системы лицензирования 1С.
Для точного определения причины в таких случаях рекомендуется использовать технологический журнал 1С:Предприятия.
Технологический журнал 1С:Предприятия: Для более глубокого анализа мы можем включить технологический журнал 1С:Предприятия. Он фиксирует все события, связанные с получением и использованием лицензий, что поможет нам выявить, какие процессы и пользователи используют лицензии, и с какого сервера они были получены. Настройка технологического журнала позволяет отслеживать события по компонентам, таким как LIC (лицензирование).
Утилита lmtool (License Manager Tool): Если программные лицензии 1С привязаны к системам защиты Guardant или Aladdin (HASP), мы можем использовать утилиту lmtool, входящую в комплект поставки драйверов этих систем. Она позволяет просматривать информацию о доступных и используемых аппаратных ключах и иногда может давать косвенную информацию и о связанных программных лицензиях. Однако для чисто программных лицензий 1С, не связанных с HASP, основным инструментом остается консоль кластера 1С.
Рассмотрим, как будут выдаваться клиентские лицензии в описанной смешанной архитектуре (СРВ1 с USB-ключом и СРВ2 с программными лицензиями). Порядок выдачи лицензий определяется следующими факторами:
Локальные лицензии: В первую очередь всегда ищутся лицензии, доступные непосредственно на том же компьютере, где запускается сервер 1С:Предприятия или клиентское приложение. Это включает как аппаратные ключи, так и файлы программных лицензий. Например, если клиент запускается на СРВ2, он в первую очередь попытается найти локальные программные лицензии на СРВ2.
Служба сеансовых данных и служба лицензирования: Если менеджер кластера сервера 1С:Предприятия назначен на компьютер, где также запущены службы сеансовых данных и лицензирования, то поиск лицензий происходит в соответствии с внутренней логикой сервера 1С. Служба лицензирования отвечает за выдачу программных лицензий, установленных на данном сервере.
Сетевой поиск: Если локальные лицензии не найдены или их недостаточно, сервер 1С:Предприятия или клиентское приложение обращается к сети для поиска доступных лицензий, в том числе через HASP License Manager для аппаратных ключей. Это означает, что если у СРВ2 закончатся программные лицензии, или они не будут найдены, он может обратиться к СРВ1 за аппаратной лицензией.
Файл nethasp.ini: Этот файл играет ключевую роль в настройке того, какие сетевые адреса и протоколы будут использоваться для поиска сетевых аппаратных ключей. Изменения в nethasp.ini на стороне сервера 1С обычно требуют перезапуска службы "Агент сервера 1С:Предприятия" для их полного применения, хотя в некоторых случаях для клиента изменения могут подхватываться сразу.
Параметр запуска /UseHwLicenses-: Этот параметр, используемый при запуске клиентского приложения 1С, указывает клиенту не искать аппаратные ключи самостоятельно. Он не влияет на поведение сервера 1С:Предприятия в части поиска аппаратных лицензий. То есть, сервер все равно может попытаться найти аппаратный ключ, даже если клиент запущен с этим параметром.
При описанной архитектуре, если оба сервера находятся в одном кластере 1С, пользователи СРВ2 смогут сначала использовать программные лицензии на 50 клиентов. После того как программные лицензии на СРВ2 закончатся (или если они недоступны), пользователи СРВ2 вполне смогут использовать аппаратные лицензии на 100 клиентов, предоставляемые СРВ1 через HASP LM, при условии, что в nethasp.ini на СРВ2 прописан IP СРВ1 для получения лицензии с аппаратного ключа. Если же СРВ1 и СРВ2 находятся в разных кластерах, то программные лицензии будут выданы только пользователям, подключенным к СРВ2, а пользователи СРВ1 смогут использовать только USB-ключ на 100.
Возникает вопрос: может ли кластер 1С:Предприятия работать еще и как сервер лицензий? Ответ: Да. Кластер 1С может выступать в роли сервера лицензий, но с важным ограничением – такой сервер умеет раздавать только программные лицензии. Аппаратные ключи всегда раздаются через HASP License Manager (или аналогичный менеджер для Guardant), который является отдельной службой и может быть установлен на любом компьютере в сети.
Для того чтобы кластер мог раздавать программные лицензии, на компьютере менеджера кластера, на который назначен сервис лицензирования, выполняется поиск программных лицензий, установленных на этом же компьютере. Также выполняется попытка получения лицензии из того файла программной лицензии, откуда лицензия была получена при последнем успешном подключении.
В нашем кейсе, несмотря на наличие программных лицензий на СРВ2 и соответствующих настроек, пользователи продолжали получать лицензии с аппаратного ключа ORGL Сет 100, а в консоли кластера СРВ2 программные лицензии не отображались. Это указывает на то, что программные лицензии по какой-то причине не активировались или не работали должным образом.
Разберем по шагам, как мы проводили диагностику для выявления причины:
Проверка приоритета лицензий: Мы предположили, что СРВ2 должен был сначала использовать локальные программные лицензии, а затем искать их в других местах. Это не происходило.
Блокировка доступа к USB-ключу через nethasp.ini: Чтобы убедиться, что проблема именно в программных лицензиях, а не в конфликте с аппаратным ключом, мы попробовали заблокировать доступ к USB-ключу на СРВ1, отредактировав файл nethasp.ini на СРВ2. Это делается путем комментирования или отключения всех протоколов:
[NH_COMMON]
NH_IPX=Disabled
NH_NETBIOS=Disabled
NH_TCPIP=Disabled
-------------------------------
Важно: Изменения в nethasp.ini на сервере 1С могут потребовать перезапуска службы "Агент сервера 1С:Предприятия" для их полного применения. На клиентских машинах изменения иногда подхватываются сразу.
Использование параметра /UseHwLicenses- при запуске клиента: Добавление этого ключа в параметры запуска клиентского приложения 1С (`1cv8.exe /UseHwLicenses-`) позволяет клиенту не искать аппаратные ключи самостоятельно. Однако, как мы выяснили, это не мешает серверу 1С самостоятельно искать и выдавать аппаратные лицензии.
Запуск файловой базы с параметром /UseHwLicenses-: Это был критически важный шаг. Запуск файловой базы на СРВ2 с параметром /UseHwLicenses- полностью исключает сервер 1С из цепочки получения лицензии и заставляет клиентское приложение искать лицензию только локально. В этом случае мы получили следующее сообщение:
Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия! по причине: Поиск лицензии на клиенте: Ошибка программного лицензирования. Ошибка привязки программной лицензии к компьютеру: file://C:/ProgramData/1C/licenses/
Это сообщение стало ключевым и указывало на истинную причину проблемы.
Сообщение об "Ошибке привязки программной лицензии к компьютеру" означает, что программная лицензия, хотя и установлена, не работает. Программные лицензии 1С привязываются к аппаратным параметрам компьютера, на котором они были активированы. Эта привязка осуществляется по нескольким параметрам, таким как:
Изменение любого из этих параметров (например, замена жесткого диска, обновление BIOS, существенное изменение конфигурации сети, установка новой операционной системы или миграция виртуальной машины без учета лицензирования) может привести к "слету" лицензии. Система защиты 1С считает, что лицензия используется на другом компьютере, и блокирует ее работу. Именно это и произошло в нашем случае: программные лицензии были "живыми" в файле, но неработоспособными из-за изменений в аппаратной конфигурации СРВ2 после их активации.
Установив, что программные лицензии "слетели", решение проблемы стало очевидным:
Получение новой лицензии с помощью резервного ПИН-кода: Для таких случаев фирма "1С" предусматривает резервные ПИН-коды. Используя один из них, мы активировали программную лицензию заново на СРВ2. Это создало новый файл лицензии, привязанный к текущей аппаратной конфигурации сервера.
Подтверждение работы лицензии: После повторной активации при запуске клиентского приложения 1С на СРВ2 мы увидели подтверждение получения программной лицензии:
Текущая: хххххххх, клиент 1/50, ......, file://C:/ProgramData/1C/licenses/20240129154233.lic, получило клиентское приложение ......
Это сообщение однозначно указывает на то, что клиентское приложение получило программную лицензию на 50 рабочих мест с локального сервера. Проблема была успешно решена.
Таким образом, мы видим, что даже при кажущейся правильной настройке системы лицензирования, необходимо учитывать нюансы привязки программных лицензий к аппаратному обеспечению. Регулярная диагностика и понимание приоритетов выдачи лицензий позволяют оперативно решать возникающие проблемы и обеспечивать бесперебойную работу 1С:Предприятия.