Как запустить тестовый сервер 1С на виртуальной машине или параллельно с рабочим сервером с использованием одного ключа лицензии?

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

В этой статье мы подробно разберем, как правильно организовать тестовую среду для 1С, рассмотрим несколько рабочих сценариев обхода лицензионных ограничений и научимся запускать несколько независимых служб 1С на одном физическом сервере или на выделенной виртуальной машине.

Вариант 1. Запуск второго сервера 1С на одном физическом сервере (Рекомендуемый способ)

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

Рассмотрим, почему это работает. Файлы программных лицензий (.lic) или аппаратный USB-ключ привязаны к физическому оборудованию и операционной системе. Если мы запускаем две разные службы в рамках одной ОС, они обе получают доступ к локальному ключу защиты.

Разберем по шагам процесс установки и настройки второго сервера 1С:

1. Установка новой платформы. Скачиваем дистрибутив новой версии платформы. При установке на рабочий сервер крайне важно выбрать режим установки, а не обновление поверх существующей версии. Нам нужно, чтобы на сервере физически присутствовали две папки с бинарными файлами, например: C:\Program Files\1cv8\8.3.12.1714 и C:\Program Files\1cv8\8.3.15.1534. Во время установки новой версии снимите галочку автоматической регистрации службы сервера 1С, чтобы установщик не затер настройки вашей рабочей службы.
2. Регистрация второй службы в Windows. Нам необходимо вручную зарегистрировать вторую службу ragent в операционной системе, назначив ей альтернативные порты, чтобы она не конфликтовала с рабочей службой (которая по умолчанию использует порт 1540 для агента и 1541 для кластера). Для этого открываем командную строку от имени администратора и выполняем команду регистрации службы с уникальным именем и измененными портами.

Посмотрим на пример команды для регистрации тестовой службы 1С (версии 8.3.15.1534) с портами 2540 (порт агента) и 2541 (порт кластера), а также выделенным диапазоном портов 2560:2591:

sc create "1C:Enterprise 8.3 Server Test" binpath= "\"C:\Program Files\1cv8\8.3.15.1534\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"C:\ProgramData\1C\1cv8_test\"" start= auto depend= Dnscache/LanmanServer

Проанализируем параметры этой команды:

• -srvc — указывает, что процесс запускается в режиме службы Windows.
• -agent — запускает агент сервера.
• -regport 2541 — порт главного менеджера кластера (вместо стандартного 1541).
• -port 2540 — порт агента сервера (вместо стандартного 1540).
• -range 2560:2591 — диапазон портов для рабочих процессов (вместо стандартного 1560:1591).
• -d "C:\ProgramData\1C\1cv8_test" — отдельный каталог для реестра тестового кластера. Крайне важно указать новый каталог, чтобы тестовый сервер не затер и не повредил реестр боевых баз!

После успешного создания службы запускаем её через консоль services.msc или командой net start "1C:Enterprise 8.3 Server Test". Теперь на одном сервере работают два независимых кластера 1С разной версии, использующие общую лицензию.

Вариант 2. Использование выделенного сервера лицензирования 1С

Если политика безопасности или архитектурные требования компании обязывают тестировать новую платформу исключительно на изолированной виртуальной машине, мы можем воспользоваться штатным механизмом платформы 1С — выделенным сервером лицензирования (доступен начиная с версии 8.3.5). Это позволяет раздавать имеющиеся на основном сервере лицензии по сети на тестовую виртуальную машину.

Выясним, как настроить эту схему работы:

1. На основном рабочем сервере 1С разворачиваем консоль администрирования кластера.
2. В свойствах основного кластера переходим в раздел «Требования назначения функциональности».
3. Создаем новое правило назначения, в котором указываем тип объекта требования — Клиентское соединение или Сеанс работы, а в качестве операции выбираем Сервис лицензирования.
4. На тестовом сервере (в виртуальной машине) при создании кластера или регистрации баз указываем адрес нашего основного рабочего сервера в качестве сервера лицензирования. Наш боевой кластер начнет централизованно выделять свободные клиентские и серверные лицензии для тестовой виртуальной машины по сетевому протоколу. При этом физически переносить ключи или файлы лицензий не потребуется.

Вариант 3. Проброс аппаратного USB HASP-ключа в виртуальную машину

Если ваша компания использует физические ключи защиты (USB HASP), вы столкнетесь с аппаратным ограничением. Серверный ключ 1С (в отличие от многопользовательских клиентских ключей) принципиально нельзя раздавать по сети с помощью стандартной утилиты HASP License Manager. Служба сервера 1С (ragent) должна видеть его подключенным непосредственно к той операционной системе, в которой она выполняется.

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

• VMware ESXi и Proxmox VE: Эти гипервизоры имеют встроенный, стабильно работающий механизм USB Passthrough. В настройках виртуальной машины достаточно добавить новое устройство (USB Device) и выбрать физический ключ HASP, подключенный к серверу-донору. Гостевая ОС определит его как локально подключенное USB-устройство.
• Microsoft Hyper-V: Данный гипервизор встроенными средствами пробрасывать USB-устройства в гостевую систему не умеет. Чтобы решить эту проблему, нам придется использовать стороннее программное обеспечение класса USB-over-IP.

Для проброса ключей в среде Hyper-V отлично зарекомендовали себя следующие программные решения:

1. VirtualHere: Популярный и производительный инструмент. Позволяет бесплатно пробрасывать одно USB-устройство по сети, чего вполне достаточно для одного тестового ключа 1С.
2. USB Network Gate: Коммерческое ПО, обеспечивающее наиболее стабильное шифрованное соединение и гарантирующее, что служба защиты 1С не «потеряет» ключ при кратковременных сетевых сбоях.
3. USB Redirector: Надежная утилита для организации клиент-серверной связи для USB-портов.
4. AnywhereUSB: Аппаратные USB-концентраторы, которые подключаются в серверную стойку по Ethernet. Они позволяют подключать множество ключей защиты 1С и распределять их по разным виртуальным машинам через сеть.

Важные нюансы использования программных лицензий на виртуальных машинах

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

Проанализируем параметры, за изменением которых нужно строго следить:

• Динамическая память (Dynamic Memory): При использовании технологий динамического выделения ОЗУ в Hyper-V или VMware объем оперативной памяти виртуальной машины постоянно колеблется в зависимости от нагрузки. При первом же изменении выделенного объема памяти лицензия 1С заблокируется. Решение: выделяйте оперативную память для виртуальной машины с сервером 1С исключительно статически.
• Сетевые параметры и MAC-адрес: По умолчанию виртуальные машины могут динамически изменять свой MAC-адрес при перезагрузке или миграции. Зафиксируйте статический MAC-адрес в настройках сетевого адаптера вашей ВМ.
• Миграция между хостами (vMotion / Live Migration): Перемещение виртуальной машины на другой физический сервер в кластере виртуализации изменит UUID материнской платы или модель процессора хоста, что приведет к аннулированию лицензии. Для виртуальных машин с программными лицензиями 1С рекомендуется отключать автоматическую миграцию или привязывать лицензию к аппаратному ключу защиты, если он присутствует на хосте.

Решение проблемы совместимости версий платформы у пользователей

Автор исходной темы на форуме столкнулся со следующей проблемой: при попытке подключиться к тестовой базе SQL через обычный тонкий клиент система выдает ошибку несовместимости версий платформы. Это происходит потому, что версия клиентского приложения на компьютере пользователя должна строго соответствовать версии сервера 1С, к которому выполняется подключение.

Выясним, как правильно решить эту проблему на рабочих местах пользователей без вреда для работы с боевой базой:

1. Установка обеих платформ на клиенте. На компьютерах тестировщиков должны быть физически установлены обе версии платформы 1С:Предприятие (и старая рабочая, и новая тестовая). Например, версии 8.3.12.1714 и 8.3.15.1534.
2. Настройка автовыбора версии в окне запуска. В окне запуска 1С (список информационных баз) выбираем тестовую базу, нажимаем кнопку «Изменить» и переходим на вкладку «Дополнительно». В поле «Версия платформы» мы можем жестко прописать требуемый релиз, например, 8.3.15.1534. Также можно оставить это поле пустым — в таком случае программа запуска 1cestart.exe автоматически опросит тестовый сервер, определит его версию, найдет на локальном компьютере соответствующий релиз клиента и запустит именно его.

Таким образом, пользователи смогут беспрепятственно работать в штатном режиме с боевой базой (на старой платформе) и параллельно проводить полноценное тестирование новой платформы в тестовой базе, не испытывая проблем с совместимостью программного обеспечения.