Как протестировать новый сервер 1С:Предприятие, если ключ защиты занят в рабочей базе?

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

Проблема проверки лицензии при загрузке базы

Разберем ситуацию: сервер 1С позволяет создать пустую базу, но при попытке загрузки данных конфигуратор или сервер приложений обращаются к менеджеру лицензий. Если ключ не найден, сеанс аварийно завершается. Это происходит потому, что операция загрузки данных является ресурсоемкой и требует полноценного рабочего процесса rphost, который в штатном режиме обязан иметь лицензию. Выясним причину, почему это происходит именно через 5-10 минут: это стандартный интервал проверки наличия аппаратного ключа защитными механизмами платформы.

Решение 1: Использование особенностей платформы 1С для Linux

Проанализируем техническую особенность работы платформы 8.3 на операционных системах семейства Linux. Исторически сложилось, что серверная часть 1С для Linux имела «льготный» режим: до 12 одновременных сеансов (не путать с пользователями) могли работать без наличия серверной лицензии.

Важно помнить, что в последних релизах (начиная с 8.3.22.2239 и 8.3.23.1865) компания 1С закрыла эту возможность. Однако, если ваша версия платформы ниже указанных (например, 8.3.22.2175, как в рассматриваемом случае), вы можете воспользоваться этим функционалом для тестов. Рассмотрим по шагам, как обеспечить стабильность в этом режиме:

1. Убедимся, что на сервере запущен только один рабочий процесс rphost. При запуске нескольких процессов система может потребовать лицензию для их балансировки.
2. В консоли администрирования кластера серверов 1С установим ограничение: «Количество информационных баз на процесс» — 1, «Количество соединений на процесс» — не более 12.
3. Попробуем загрузить базу. В данном режиме сервер должен позволить выполнить операцию без обращения к HASP-ключу.

Решение 2: Загрузка через утилиту ibcmd (без сервера приложений)

Посмотрим на современный инструмент, который появился в платформе начиная с версии 8.3.15 — утилиту командной строки ibcmd. Проанализируем её преимущество: она позволяет работать с данными информационной базы напрямую, минуя запуск службы сервера 1С (ragent) и проверку клиент-серверных лицензий в привычном понимании.

Для загрузки данных из .dt напрямую в PostgreSQL используем следующую схему:

ibcmd infobase restore --dbms=PostgreSQL --db-server=localhost --db-name=test_db --db-user=postgres --db-pwd=password --file=/path/to/backup.dt

После завершения работы утилиты структура таблиц в PostgreSQL будет полностью готова. Нам останется только зайти в консоль администрирования 1С и «зарегистрировать» существующую базу данных. Поскольку данные уже внутри, серверу не потребуется выполнять длительную операцию загрузки, и вы сможете войти в базу (в рамках лимита 12 сеансов для старых версий или под комьюнити-лицензией).

Решение 3: Миграция на уровне СУБД (pg_dump и pg_restore)

Рассмотрим самый надежный метод для системного администратора — копирование базы данных средствами самой СУБД. Этот метод полностью исключает участие механизмов 1С в процессе переноса данных, а значит, и проверку лицензий на этапе загрузки.

Выполним следующие шаги:

1. На старом сервере создадим дамп базы данных PostgreSQL: pg_dump -U postgres -d work_db -F c -f work_db_backup.dump
2. Перенесем файл дампа на новый сервер.
3. Восстановим базу данных: pg_restore -U postgres -d test_db work_db_backup.dump
4. В консоли администрирования нового сервера 1С создадим новую информационную базу, указав в параметрах имя базы test_db, которую мы только что восстановили. Важно: снимите галочку «Создать базу данных в случае ее отсутствия».

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

Решение 4: Использование комьюнити-лицензии

Проанализируем вариант использования официальной «Лицензии для разработчиков» или «Комьюнити-лицензии». Многие ошибочно полагают, что она предназначена только для написания кода. На самом деле, она позволяет запустить полноценный сервер 1С для целей тестирования и отладки.

Особенности этого метода:

• Необходимо зарегистрироваться на портале 1С и получить программный код активации.
• Лицензия позволяет работать в клиент-серверном варианте.
• Существует ограничение на количество одновременных сеансов (до 3 сеансов).
• Для тестирования функционала (расчет зарплаты, проведение документов, закрытие месяца) этого объема вполне достаточно.

Рассмотрим нюанс: комьюнити-лицензия требует версии платформы не ниже 8.3.23. Если ваш основной контур работает на 8.3.22, вы можете установить 8.3.23 на новый сервер только для тестов. Если конфигурация успешно пройдет тесты на более новой платформе, она гарантированно будет работать и на старой после переноса ключа.

Решение 5: Метод «Двух серверов»

Рассмотрим хитроумный способ, предложенный опытными администраторами. Если на новом сервере база не грузится из-за отсутствия ключа, мы можем использовать старый сервер (где ключ есть) как «транспорт».

1. На старом (рабочем) сервере 1С создадим новую информационную базу (через консоль).
2. В параметрах СУБД укажем адрес нового сервера PostgreSQL и имя базы на нем.
3. Запустим загрузку .dt через консоль или конфигуратор старого сервера.
4. Поскольку ключ вставлен в старый сервер, загрузка пройдет без ошибок, но данные будут физически записываться в базу на новом сервере.
5. После завершения загрузки удалим регистрацию базы на старом сервере и добавим её на новом.

Рекомендации по нагрузочному тестированию

Выясним причину, по которой простого входа в базу недостаточно. Для боевого тестирования нового сервера важно проверить взаимодействие 1С и PostgreSQL. Мы рекомендуем использовать встроенный механизм ТестЦентр или запустить обработку «Оценка производительности» по методике APDEX. Даже без ключа (на Linux до 12 сеансов) вы сможете запустить замеры под нагрузкой от нескольких пользователей, чтобы убедиться, что дисковая подсистема и оперативная память нового сервера настроены корректно.

Важный момент по USB-ключам: Не пытайтесь использовать технологии USB-over-IP (проброс ключа по сети) без специализированного оборудования. Программные средства проброса часто вызывают нестабильность драйвера aksusbd, что может привести к «вылетам» пользователей даже в рабочем контуре. Самый надежный путь — миграция данных на уровне СУБД и кратковременный перенос физического ключа для финальной проверки.