При развертывании инфраструктуры 1С:Предприятия нередко возникают ситуации, когда часть компонентов работает корректно, а другие сталкиваются с необъяснимыми на первый взгляд проблемами. Одна из таких распространенных сложностей – это когда серверы приложений 1С по-разному взаимодействуют с выделенным сервером лицензий. В нашей ситуации один сервер 1С:Предприятия успешно получает лицензии, в то время как другой, казалось бы, идентично настроенный, упорно сообщает об их отсутствии.
Представим сценарий: у нас развернута инфраструктура, включающая 2 сервера приложений 1С:Предприятия и 1 выделенный сервер лицензий. Все серверы работают под управлением Astra Linux.
1clic): На нем успешно установлен и настроен сервер лицензий 1С:Предприятия согласно многочисленным инструкциям (можно использовать сценарий автоматизации установки). На этот сервер была установлена серверная лицензия, и ее наличие было подтверждено.1cprodapl): Этот сервер был настроен как положено, с использованием «Требований назначения функциональности» (ТНФ), чтобы ограничить его задачи. После настройки он успешно подключился к серверу 1clic, получил лицензию и позволил пользователям работать с базами данных.1ctestapl): Этот сервер был развернут как тестовый. Его настройка была выполнена абсолютно так же, как и для первого сервера, за исключением того, что на него не устанавливалась лицензия, так как предполагалось ее получение с 1clic. Однако этот сервер не видит лицензии.Несмотря на то, что на всех серверах были корректно прописаны записи в файлах /etc/hosts для взаимного разрешения имен по IP-адресам, и все серверы успешно пинговали друг друга как по имени, так и по IP-адресу, сервер 1ctestapl выдавал сообщение об отсутствии серверной лицензии. В консоли кластера 1С было видно, что у менеджера кластера второго сервера (1ctestapl) отсутствуют PID и порт, что явно указывает на проблемы с его запуском или функционированием из-за отсутствия лицензии.
Давайте подробнее рассмотрим сообщение об ошибке, которое выдавал проблемный сервер:
На сервере 1С:Предприятия не найдена лицензия.
Не обнаружен ключ защиты программы или полученная программная лицензия!
по причине: Файл программной лицензии не найден локальный ключ недоступен:
Status=-100, EN8SA Локальный, не установлен
Поиск лицензии в сервисе лицензирования:
Ошибка вызова сервиса лицензирования: Не найдено ни одного сервера с размещенным сервисом serviceName=LicenseService;serviceID=0a3db51c-6b29-4c6c-9e4b-8174fc77afd6;
Это сообщение содержит несколько важных деталей: оно говорит о том, что локальный ключ не найден, и самое главное — «Не найдено ни одного сервера с размещенным сервисом serviceName=LicenseService». Это прямо указывает на то, что сервер приложений не может обнаружить или связаться с сервисом лицензирования, который, как мы знаем, развернут на 1clic.
Для выявления корневой причины проблемы мы проделали ряд диагностических шагов:
hosts и доступности по ping: Первым делом мы убедились, что базовое сетевое взаимодействие между всеми серверами установлено. Все серверы успешно пинговали друг друга по именам и IP-адресам, а файлы /etc/hosts были корректно настроены. Это исключило проблемы с разрешением имен и общей сетевой связностью.1clic. Для выделенного сервера лицензий они должны быть настроены таким образом, чтобы он выполнял только функцию лицензирования. То есть, объект требования: "Сервис лицензирования" должен быть установлен в "Назначать", а "Любой объект требования" – в "Не назначать". Пользователь подтвердил, что эти настройки были применены полностью и неоднократно, а также производился перезапуск всех серверов в различных последовательностях. Тот факт, что 1cprodapl успешно видит лицензии, также косвенно подтверждает корректность настройки 1clic как сервера лицензий.telnet: Это оказался ключевой шаг в диагностике. Мы решили проверить доступность порта 1540 (стандартный порт агента сервера 1С) на сервере лицензий 1clic с обоих серверов приложений.
1cprodapl (который успешно работал) команда telnet <IP_1clic> 1540 показала успешное соединение.1ctestapl (который не видел лицензий) команда telnet <IP_1clic> 1540 завершилась неудачей, показывая, что порт недоступен.Этот результат стал решающим. Стало очевидно, что проблема не в настройках 1С как таковых или в ошибках активации лицензий, а в сетевой доступности порта 1540 между проблемным сервером приложений (1ctestapl) и сервером лицензий (1clic). Наиболее вероятной причиной такой блокировки является брандмауэр на одном из серверов (1ctestapl или 1clic) или сетевое оборудование (маршрутизатор) между ними, особенно учитывая, что на сервере лицензий все порты были заявлены как открытые.
Основываясь на проведенной диагностике и полученных результатах, мы предлагаем комплексный подход к устранению подобных проблем. Важно последовательно проверить все аспекты, начиная с сетевого взаимодействия, которое, как показала практика, является наиболее частой причиной.
Если telnet или nc не могут подключиться к порту 1540 с проблемного сервера, это однозначно указывает на блокировку на сетевом уровне. Нам необходимо убедиться, что все необходимые порты открыты и доступны между сервером приложений и сервером лицензий.
Сервер 1С:Предприятия по умолчанию использует следующие порты, которые должны быть открыты на брандмауэрах как на сервере лицензий (1clic), так и на сервере приложений (1ctestapl):
1540/tcp: Порт агента сервера 1С. Критически важен для обнаружения кластера.1541/tcp: Порт менеджера кластера 1С.1560-1591/tcp: Диапазон портов для рабочих процессов 1С.На Astra Linux (и других дистрибутивах, использующих ufw или firewalld) вы можете проверить и открыть порты следующим образом:
Для ufw (Uncomplicated Firewall):
# Проверить текущий статус ufw
sudo ufw status verbose
# Открыть необходимые порты
sudo ufw allow 1540/tcp
sudo ufw allow 1541/tcp
sudo ufw allow 1560:1591/tcp
# Перезагрузить правила ufw для применения изменений
sudo ufw reload
Для firewalld (если установлен):
# Проверить текущие правила firewalld
sudo firewall-cmd --list-all
# Открыть необходимые порты (постоянно)
sudo firewall-cmd --permanent --add-port=1540/tcp
sudo firewall-cmd --permanent --add-port=1541/tcp
sudo firewall-cmd --permanent --add-port=1560-1591/tcp
# Перезагрузить firewalld для применения изменений
sudo firewall-cmd --reload
Важно: Проверяем и, при необходимости, открываем порты на обоих серверах – на 1clic (для входящих подключений от серверов приложений) и на 1ctestapl (для исходящих подключений к серверу лицензий, хотя для исходящих обычно разрешено, но стоит проверить).
telnet или nc:
После внесения изменений в настройки брандмауэра, вернитесь на сервер 1ctestapl и повторите проверку доступности порта 1540 на 1clic:
telnet <IP_сервера_лицензий> 1540
# или
nc -zv <IP_сервера_лицензий> 1540
Успешное выполнение этих команд должно показать установленное соединение или статус "Connected". Если по-прежнему соединение не устанавливается, то проблема может быть на уровне сетевого оборудования (маршрутизатора, коммутатора) между серверами. В этом случае потребуется вмешательство сетевых инженеров для проверки правил маршрутизации и безопасности.
hosts и DNS:
Хотя вы и подтвердили корректность hosts и ping, давайте еще раз убедимся. На всех серверах (1clic, 1cprodapl, 1ctestapl) в файле /etc/hosts должны быть корректные записи, связывающие IP-адреса с именами серверов. Это особенно важно для 1С.
# Пример записей в /etc/hosts на каждом сервере:
192.168.1.10 1clic
192.168.1.11 1cprodapl
192.168.1.12 1ctestapl
Также проверьте, что DNS-разрешение имен работает правильно, если вы используете DNS-серверы вместо или в дополнение к hosts. Используйте команду nslookup <имя_сервера>.
В некоторых случаях, если в вашей сети активно не используется IPv6, но он включен на серверах, это может вызывать проблемы с разрешением адресов и подключением. Если вы сталкиваетесь с постоянными проблемами, попробуйте временно отключить IPv6.
# Временно отключить IPv6
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
Для постоянного отключения добавьте следующие строки в файл /etc/sysctl.conf и примените изменения командой sudo sysctl -p:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
Даже если сетевая проблема будет решена, крайне важно, чтобы сервер 1clic был правильно настроен как выделенный сервер лицензирования. Это гарантирует, что он будет выполнять только свои прямые обязанности и не будет пытаться выполнять другие функции кластера, которые могут конфликтовать или потреблять лишние ресурсы.
На сервере 1clic (сервере лицензирования) должны быть настроены ТНФ следующим образом:
"Сервис лицензирования""Назначать"Это требование явно указывает серверу 1clic, что он должен предоставлять сервис лицензирования.
"Любой объект требования""Не назначать"Это требование запрещает серверу 1clic выполнять любую другую функциональность кластера 1С, кроме сервиса лицензирования.
После внесения или проверки этих настроек обязательно выполните полное применение ТНФ через консоль администрирования сервера 1С и затем перезапустите службу сервера 1С на 1clic. Это гарантирует, что все изменения вступят в силу.
После устранения сетевых и конфигурационных проблем, мы должны убедиться, что сами лицензии и кластер 1С находятся в корректном состоянии.
1clic. Если она была случайно активирована на 1cprodapl или 1ctestapl, это может вызвать проблемы. Программные лицензии привязываются к параметрам оборудования, поэтому важно, где они были активированы. Для контроля вы можете использовать утилиту licsrv.exe (в Windows) или аналогичные средства в Linux для просмотра активных лицензий.1clic) и на серверах приложений (1cprodapl, 1ctestapl) совпадает. Например, 32-разрядная лицензия не будет работать с 64-разрядной платформой 1С.1ctestapl. Новое сообщение об ошибке может дать более точную информацию о текущей проблеме, если она изменилась.Для Astra Linux это обычно делается так:
sudo systemctl restart srv1cv83
При работе с 1С на Astra Linux могут проявляться специфические нюансы. Убедитесь, что служба сервера 1С запущена и работает стабильно. Вы можете проверить ее статус:
sudo systemctl status srv1cv83
Если служба не запущена или находится в состоянии ошибки, необходимо проанализировать логи службы и системы для выявления причин. В некоторых случаях могут потребоваться дополнительные настройки для 1С, связанные с переменными окружения, системными библиотеками или шрифтами, но это менее вероятно для проблем с лицензированием.
В большинстве случаев, когда один сервер 1С видит лицензии, а другой нет, при общей кажущейся идентичности настроек, корневая причина кроется в сетевой доступности. Брандмауэры на хостах или сетевое оборудование могут избирательно блокировать трафик между определенными серверами или на определенных портах. Тщательная проверка открытых портов, настроек брандмауэра и сетевого соединения с помощью таких инструментов, как telnet или nc, позволяет быстро локализовать и устранить такую проблему. После обеспечения сетевой связности необходимо убедиться в корректности ТНФ и общем состоянии кластера 1С, чтобы гарантировать стабильную работу всей инфраструктуры.