Как перенести сервер 1С на Linux и настроить работу USB-ключей HASP без физического перемещения?

Переезд сервера 1С на новое оборудование под управлением Linux — задача ответственная и часто сопряженная с техническими нюансами лицензирования. Одной из главных сложностей является работа с физическими USB-ключами HASP, особенно когда требуется провести тестирование нового сервера без остановки основного рабочего процесса. Разберем подробно, как организовать доступ к ключам по сети и почему после миграции база данных может существенно «похудеть».

Организация сетевого доступа к ключам защиты (USB-over-IP)

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

Проанализируем основные инструменты для решения этой задачи:

1. USBIP — это свободный проект, интегрированный непосредственно в ядро Linux. Он позволяет передавать трафик USB-устройств по протоколу TCP/IP. Рассмотрим принцип работы: на машине с физическим ключом (сервер-экспортёр) запускается демон, который «публикует» USB-порт. На новой машине (сервер-импортёр) монтируется виртуальный порт, и система начинает считать, что ключ вставлен непосредственно в неё.
2. Специализированные концентраторы (DistKontrol, VirtualHere) — это более стабильные коммерческие решения. Они создают виртуальную шину USB, которая работает гораздо надежнее стандартного usbip, особенно при кратковременных разрывах сетевого соединения. Это крайне важно для 1С, так как при потере связи с ключом rphost может аварийно завершить сеансы пользователей.

Важный нюанс: помните, что проброс ключа — это монопольный захват. Если вы пробросили ключ на тестовый сервер с помощью usbip, он «исчезнет» из операционной системы основного сервера. Одновременная работа одного локального ключа на двух физических ОС невозможна на низком уровне драйверов.

Проверка статуса лицензий в интерфейсе 1С

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

В блоке «Текущая:» отображается лицензия, которая удерживается данным конкретным сеансом. Например:

Сетевой HASP4 ORGL8 100 — это клиентская лицензия, полученная через менеджер лицензий.

В блоке «Информационная база:» фиксируется серверная лицензия. Если вы видите запись:

Локальный HASP4 EN8SA 1

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

Установка драйверов HASP на Linux

Для того чтобы сервер 1С увидел ключ (даже проброшенный по сети), в системе должен быть установлен пакет Sentinel LDK Runtime. В современных дистрибутивах Linux (Ubuntu, Debian) процесс установки обычно выглядит следующим образом:

sudo dpkg -i aksusbd_*.deb
sudo systemctl enable aksusbd
sudo systemctl start aksusbd

После установки проверьте доступность ключей через веб-интерфейс Sentinel Runtime Environment (обычно доступен по адресу http://localhost:1947). Если проброс через usbip настроен верно, ключ появится в списке Sentinel Keys.

Анализ размера базы данных после миграции (PostgreSQL)

Часто системные администраторы сталкиваются с феноменом: база данных на старом сервере весила 260 Гб, а после восстановления из бекапа на новом сервере стала занимать всего 80 Гб. Разберем ситуацию и выясним, не пропали ли данные.

Причина кроется в механизме работы PostgreSQL, который называется MVCC (Multi-Version Concurrency Control). Рассмотрим по шагам, что происходит в процессе эксплуатации:

1. При удалении или изменении записи в PostgreSQL старые данные не удаляются физически. Они помечаются как «мертвые кортежи» (dead tuples).
2. Если на сервере не настроен или плохо работает autovacuum, эти пустые места накапливаются внутри файлов базы данных. Это называется «раздуванием» (bloat).
3. За 3–4 года без должного обслуживания (без выполнения команд VACUUM FULL или REINDEX) объем «пустоты» может в разы превышать объем реальных данных.

Когда мы делаем выгрузку базы (через pg_dump или через создание .dt файла в 1С), выгружаются только актуальные живые данные. При загрузке этой выгрузки в новую базу данных:

• Таблицы создаются заново.
• Индексы перестраиваются с нуля.
• Мертвые записи и пустоты отсутствуют.

Таким образом, уменьшение размера — это признак того, что база прошла «естественную» оптимизацию. Для поддержания базы в таком состоянии в будущем, проанализируем настройки postgresql.conf и убедимся, что параметры autovacuum активны:

autovacuum = on
autovacuum_max_workers = 3
autovacuum_naptime = 1min
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50

Регламентное обслуживание как залог стабильности

Посмотрим на ситуацию шире: если сервер не обслуживался годами, простого переноса недостаточно. Мы рекомендуем настроить план обслуживания в самой 1С или на уровне СУБД, который будет включать:

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

Подводя итог, можно сказать, что перенос сервера 1С на Linux с использованием usbip — это эффективный метод тестирования, позволяющий сохранить работоспособность ключей защиты. А существенное уменьшение объема базы при миграции является нормальным следствием очистки от накопленного мусора (bloat) в PostgreSQL.