Перевод ИТ-инфраструктуры предприятия на операционные системы семейства Linux — один из наиболее популярных сценариев оптимизации затрат на лицензирование. Связка Linux (Debian/Ubuntu/CentOS) + PostgreSQL + Сервер 1С:Предприятие показывает отличные результаты производительности. Однако в процессе развертывания администраторы часто сталкиваются со специфическими трудностями, связанными с защитой платформы (HASP) и конфигурацией рабочих процессов кластера.
В этой статье мы подробно разберем, как определить, видит ли сервер 1С физический USB-ключ лицензии под Linux, правильно установить необходимые драйверы, а также разберем критическую ошибку распределения рабочих процессов rphost при схеме «один процесс на одну информационную базу».
При запуске сервера «1С:Предприятие» в клиент-серверном режиме критически важно понимать, откуда именно система получает лицензии. Лицензирование 1С состоит из двух уровней:
Для проверки того, видит ли сервер 1С установленные ключи защиты, воспользуемся штатным механизмом платформы. Запустим клиентское приложение и перейдем в меню Справка — О программе (или нажмем кнопку с буквой «i» в правом верхнем углу интерфейса).
В открывшемся окне нас интересует раздел Лицензия. Рассмотрим две ситуации: когда сервер не видит ключ защиты и когда ключ успешно определен.
Ситуация А: Серверный ключ НЕ обнаружен
Если в списке лицензий отображаются только многопользовательские клиентские ключи, это означает, что сервер работает либо без ключа (в демо-режиме, если это старая платформа, либо вовсе заблокирует работу при превышении лимита сессий), либо берет лицензию из неожиданного места. Типичный вывод в этом случае выглядит так:
Информационная база:
Сетевой HASP4 ORGL8 20
Конфигурация:
Локальный HASP4 ORGL8 10
Сетевой HASP4 ORGL8 50
В этом списке присутствуют только ключи серии ORGL8 (пользовательские лицензии) разного номинала. Упоминания о ключе сервера нет.
Ситуация Б: Серверный ключ успешно обнаружен
После корректной настройки драйверов и перезапуска служб в окне «О программе» должна появиться строка, идентифицирующая серверную лицензию. Пример успешного обнаружения ключа:
Текущая:
Сетевой HASP4 ORGL8 20, получило клиентское приложение
Локальный HASP4 EN8SA 1
Информационная база:
Локальный HASP4 ORGL8 20
Конфигурация:
Локальный HASP4 ORGL8 10
Сетевой HASP4 ORGL8 50
Обратите внимание на строчку Локальный HASP4 EN8SA 1. Это ключевой маркер, подтверждающий работоспособность серверной лицензии.
Для правильной диагностики администратору необходимо знать буквенные обозначения на физических USB-накопителях и в окне программы:
ORGL8 10, ORGL8 20, ORGL8 50, ORGL8 100).---
Если физический ключ вставлен в USB-порт сервера (светодиод на ключе может как гореть, так и не гореть в зависимости от состояния драйвера), но платформа его не определяет, необходимо выполнить установку и настройку службы защиты.
Ранее популярный пакет haspd_eter от компании Etersoft на современных дистрибутивах Linux (с версиями ядра 4.x и выше и диспетчером системных служб systemd) часто работает некорректно или вызывает сбои. Рассмотрим современный и надежный способ настройки с помощью официального пакета Sentinel LDK Run-time.
Выполним установку по шагам:
Шаг 1. Проверка физического подключения устройства
Убедимся, что операционная система на аппаратном уровне видит подключенный USB-токен. Для этого выполним команду в терминале:
lsusb
В выводе команды найдем строку, содержащую информацию об устройстве от компании Aladdin. Она должна выглядеть примерно так:
Bus 002 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP v1.12
Если строка присутствует, значит, USB-порт исправен и плата инициализировала устройство.
Шаг 2. Загрузка и установка официального драйвера
Рекомендуется использовать Sentinel LDK Run-time Installer. Скачаем архив с драйверами (для Debian/Ubuntu используются .deb пакеты, для RedHat/CentOS — .rpm):
wget https://download.savannah.gnu.org/releases/lshw/lshw-B.02.18.tar.gz (Примечание: скачивайте актуальный пакет Sentinel LDK с официального сайта Thales/Sentinel под вашу версию ОС).
Распакуем архив и перейдем в каталог с пакетами. Установим драйвер с помощью пакетного менеджера:
dpkg -i sentinel-runtime_X.XX_amd64.deb
Шаг 3. Запуск и проверка службы защиты
Драйвер Sentinel устанавливает в систему демон защиты aksusbd. Проверим его статус с помощью systemctl:
systemctl status aksusbd
Если служба не запущена, выполним ее принудительный запуск и добавим в автозагрузку системы:
systemctl enable aksusbd --now
После успешного запуска демона aksusbd индикатор на USB-ключе HASP должен загореться ровным красным светом. Теперь можно перезапустить сервер 1С:
systemctl restart srv1cv83
---
Рассмотрим вторую проблему, описанную автором темы: при активации в настройках кластера режима «один процесс на одну информационную базу», пользователи не могут войти во вторую базу. Система выдает сообщение об ошибке:
«Ошибка установки соединения. Выполняется ожидание возможности запуска. При появлении возможности запуск будет выполнен автоматически.»
При этом наблюдается странная аномалия: если запустить базы в обратной последовательности (например, сначала ЗУП, а затем УПП), то соединение устанавливается успешно, и менеджер кластера запускает два параллельных процесса rphost.
Выясним причину этой проблемы и рассмотрим способы ее решения.
В релизах платформы 8.3.13.1513 (и некоторых смежных сборках ветки 8.3.13) присутствует критическая ошибка механизма распределения рабочих процессов кластера. При жестком ограничении количества баз на один процесс менеджер кластера rmngr не может корректно инициализировать и выделить порт для нового процесса rphost, если базы запускаются в определенной последовательности (это связано со спецификой кэширования метаданных и разницей в структуре конфигураций баз).
Решение: Данный баг был официально признан фирмой «1С» и исправлен, начиная с тестовой версии 8.3.13.1576 и во всех последующих стабильных релизах (8.3.14 и старше). Для полного устранения проблемы настоятельно рекомендуется обновить платформу «1С:Предприятие» до актуального релиза.
Если обновление платформы временно невозможно, необходимо исключить инфраструктурные ограничения. При схеме «один процесс на одну базу» сервер создает для каждой базы индивидуальный процесс rphost, каждый из которых требует выделения отдельного TCP-порта.
По умолчанию кластер 1С использует следующие порты:
1540 — главный менеджер кластера (ras);1541 — менеджер кластера (rmngr);1560:1591 — диапазон портов для рабочих процессов (rphost).Если на сервере Linux активен брандмауэр (например, ufw или iptables), но открыты только порты 1540 и 1541, то первый запущенный процесс займет первый свободный порт из динамического пула, а последующие процессы не смогут принимать сетевые пакеты из-за блокировки брандмауэра.
Для решения этой проблемы откроем весь рабочий диапазон портов. Пример настройки для утилиты ufw (Debian/Ubuntu):
ufw allow 1540:1541/tcp
ufw allow 1560:1591/tcp
ufw reload
Пример настройки для iptables:
iptables -A INPUT -p tcp --dport 1540:1541 -j ACCEPT
iptables -A INPUT -p tcp --dport 1560:1591 -j ACCEPT
service iptables save
Если на вашем сервере развернуто большое количество информационных баз (более 30), и для каждой базы включена изоляция процессов, стандартного диапазона портов 1560–1591 (всего 32 порта) может просто не хватить. В этом случае новые процессы rphost не смогут запуститься.
Чтобы расширить диапазон портов кластера, выполните следующие действия:
rac на Linux).1560:1591).1560:1690.Как отметил автор темы, в некоторых случаях избавиться от ошибки «ожидания возможности запуска» помогает удаление базы из кластера 1С и её повторное добавление (с возможным переименованием). Этот метод работает потому, что при удалении базы менеджер кластера полностью очищает записи о распределении процессов в конфигурационном файле кластера 1CV8Clst.lst. Однако это лишь временная мера, и при изменении состава пользователей или перезапуске служб ошибка может вернуться, поэтому обновление платформы остается приоритетным решением.