← На главную

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

Правила лицензирования сервера 1С на виртуальных машинах

Проанализируем базовые правила лицензирования серверной части платформы 1С:Предприятие при использовании виртуализации:

1. Лицензия на каждый экземпляр операционной системы: если создается несколько виртуальных машин (независимо от того, используется Windows или Linux), и на каждой из них разворачивается служба сервера 1С (процессы ragent, rmngr, rphost), для каждой такой виртуальной машины требуется отдельная лицензия на сервер 1С:Предприятия (32-разрядная или 64-разрядная).
2. Локальная доступность ключа: в отличие от многопользовательских клиентских лицензий, которые могут раздаваться по сети через HASP License Manager, лицензия на сервер 1С должна быть доступна локально тому экземпляру ОС, где запускаются серверные службы.
3. Ограничение по числу пользователей на Linux: платформа 1С на Linux может технически стартовать без ключа сервера при небольшом количестве сессий, однако запуск рабочего сервера без соответствующей лицензии является прямым нарушением лицензионного соглашения правообладателя. Для промышленной эксплуатации наличие лицензии обязательно.

Особенности работы программных лицензий и миграция ВМ

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

Программная лицензия формирует цифровой слепок виртуального оборудования на основе нескольких параметров: BIOS UUID виртуальной машины, число ядер и модель виртуального процессора, MAC-адрес сетевого интерфейса, объем выделенной оперативной памяти, идентификатор системного диска и версия операционной системы.

Чтобы программная лицензия не слетала при «живой» миграции (например, через VMware vMotion или Live Migration в KVM/Proxmox), выполним предварительную настройку параметров виртуальной машины:

1. Фиксация UUID виртуальной машины: настроим гипервизор так, чтобы директива BIOS UUID оставалась неизменной при миграции на другой физический хост и не генерировалась заново.
2. Статический MAC-адрес: назначим виртуальному сетевому адаптеру жестко заданный статический MAC-адрес, исключив динамическое выделение из пула гипервизора.
3. Отключение динамической памяти: отключим механизмы динамического перераспределения памяти (Dynamic RAM / Memory Ballooning) и зафиксируем точный объем выделенной RAM.
4. Совместимость процессоров (EVC / CPU Model): в кластерах с серверами разных поколений включим режим совместимости CPU (например, VMware EVC или режим виртуального процессора kvm64/host-model в Linux KVM), чтобы гостевая ОС не фиксировала изменение набора инструкций и CPUID при переезде на соседний хост.
5. Привязка к аппаратному ключу: платформа 1С позволяет привязать программную лицензию не к характеристикам виртуального оборудования, а к ID физического USB-ключа. В таком сценарии изменение параметров ВМ не приведет к аннулированию программной лицензии, пока ключ доступен в системе.

Проброс аппаратных USB-ключей в гостевую ОС Linux

Выясним, как подключить физические USB-токены (HASP/Sentinel) к виртуальным машинам на базе Linux:

1. Штатный проброс через гипервизор: большинство современных гипервизоров (VMware ESXi, Proxmox VE, KVM, Hyper-V) поддерживают прямое подключение USB-устройств с хоста в гостевую ОС. Для аппаратных ключей 1С рекомендуется добавлять в конфигурацию ВМ контроллер стандарта USB 2.0 (EHCI), так как с версиями USB 3.0 контроллеров токены защиты старых серий могут работать нестабильно.
2. Правило «один физический ключ — одна ВМ»: один реальный аппаратный ключ невозможно одновременно пробросить средствами гипервизора в две разные виртуальные машины.
3. Исключение конфликтов одинаковых ключей: если к одной виртуальной машине подключить два аппаратных ключа одной серии (например, два ключа сервера 1С), платформа увидит только один из них. Поэтому для разных ВМ используются отдельные ключи.
4. Использование сетевых концентраторов (USB-over-IP): для обеспечения высокой доступности и независимости от конкретного физического хоста применяются аппаратные сетевые концентраторы USB или программный стек USB/IP в Linux. Это позволяет монтировать USB-порт с ключом по протоколу TCP/IP на любую ВМ в локальной сети.

Альтернативные варианты изоляции баз данных без покупки лишних лицензий

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

1. Разделение СУБД в рамках одного кластера: в консоли администрирования 1С для каждой информационной базы можно указать свой собственный сервер баз данных (PostgreSQL или MS SQL), оставаясь в рамках единого кластера 1С. Это позволяет изолировать тяжелые базы на уровне дисковой подсистемы и СУБД без разворачивания дополнительных виртуальных серверов 1С.
2. Запуск нескольких экземпляров службы на одной ОС: в Linux можно настроить несколько независимых служб systemd для сервера 1С, выделив для каждого экземпляра свой каталог данных кластера (srvinfo) и собственный диапазон сетевых портов (например, основной экземпляр на портах 1540/1541/1560-1591, второй — на портах 2540/2541/2560-2591). Все запущенные в рамках одного сервера службы смогут использовать общую локальную лицензию сервера 1С.