При переходе на 64-битную версию сервера «1С:Предприятие 8.3» перед ИТ-специалистами и системными администраторами встает классическая дилемма: какую лицензию приобрести — программную (электронную) или аппаратную (физический USB-ключ)? С одной стороны, аппаратный ключ кажется более надежным решением, которое легко перенести с одного физического сервера на другой. С другой стороны, программная лицензия существенно дешевле и избавляет от необходимости физического подключения устройств к серверу, что особенно важно в эпоху виртуализации.
В этой статье мы подробно проанализируем достоинства и недостатки обоих вариантов, рассмотрим специфику их использования на виртуальных машинах, выясним причины «слета» программных лицензий и пошагово разберем профессиональное решение — настройку выделенного сервера лицензирования в кластере 1С.
Прежде чем принять окончательное решение, давайте детально сопоставим оба типа защиты по ключевым критериям: надежность, удобство администрирования, масштабируемость и поведение в критических ситуациях.
Аппаратные USB-ключи (HASP)
Основное преимущество USB-ключа заключается в его мобильности и полной независимости от конфигурации сервера. Вы можете обновить аппаратную часть компьютера, заменить процессор, добавить оперативную память или полностью переустановить операционную систему — ключ продолжит работать без каких-либо дополнительных манипуляций. В случае аварии основного сервера вы можете оперативно развернуть резервный сервер 1С, просто переставив физический ключ в новый системный блок.
Однако у аппаратного решения есть существенные недостатки:
Программные лицензии (файлы .lic)
Программная лицензия представляет собой файл с расширением .lic, который создается в результате активации пин-кода и привязывается к ключевым параметрам конкретного компьютера.
К преимуществам программных лицензий можно отнести:
Основной недостаток программного метода — жесткая привязка к аппаратной конфигурации компьютера. При изменении ключевых параметров сервера лицензия деактивируется («слетает»), и ее требуется активировать заново, используя резервный пин-код из комплекта поставки.
Проанализируем ситуацию, при которой программный ключ может потерять свою валидность. Платформа «1С:Предприятие» при активации лицензии собирает уникальный цифровой отпечаток компьютера. Этот отпечаток формируется на основе следующих ключевых параметров:
Если вы используете виртуальную машину (например, под управлением VMware vSphere, Hyper-V или Proxmox VE), то любое динамическое распределение ресурсов может привести к деактивации ключа. Например, если в настройках гипервизора включена функция динамического управления оперативной памятью (Dynamic Memory) или автоматическая миграция виртуальной машины между хостами кластера (vMotion / Live Migration), параметры виртуального «железа» могут незаметно измениться. Платформа 1С мгновенно отреагирует на это отключением лицензии.
Чтобы минимизировать риски «слета» лицензии, придерживайтесь следующих правил:
licdata.txt, в котором фиксируются регистрационные данные организации при первичной активации. При восстановлении лицензии все данные организации должны быть введены символ в символ, иначе система не примет резервный пин-код.Рассмотрим важную особенность работы программной защиты, о которой знают не все администраторы. В платформе «1С:Предприятие 8.3» реализован защитный механизм, сглаживающий последствия внезапного изменения конфигурации сервера. Если программная лицензия перестает соответствовать аппаратным параметрам компьютера, сервер 1С не прекращает работу мгновенно.
Система переходит в «льготный режим» функционирования, который длится 5 дней. В течение этого времени администратор может зайти в консоль управления, подготовить файл сведений, ввести резервный пин-код и активировать лицензию заново. Это полностью исключает простой критически важных бизнес-процессов даже в том случае, если сбой конфигурации произошел в выходные или праздничные дни.
Что делать, если конфигурация ваших рабочих серверов 1С регулярно меняется (происходит масштабирование, оптимизация, перенос баз), но вы не хотите постоянно тратить время на повторную активацию программных лицензий?
Разберем по шагам продвинутую архитектурную схему, рекомендованную разработчиками «1С». Мы можем развернуть небольшую, максимально простую виртуальную машину с фиксированными характеристиками, которая будет выполнять исключительно роль сервиса лицензирования. Все программные лицензии (как серверные, так и клиентские) будут активированы именно на этой машине. Поскольку ее аппаратные параметры (память, процессор, диски) никогда не будут меняться, лицензии не «слетят». А рабочие серверы приложений, на которых выполняются тяжелые вычисления, смогут динамически масштабироваться без угрозы для лицензирования.
Рассмотрим процесс настройки такой схемы в консоли администрирования кластера «1С:Предприятия».
Создайте виртуальную машину с минимальными системными требованиями (например, 2 ядра процессора, 4 ГБ оперативной памяти) и жестко зафиксируйте ее параметры в гипервизоре (отключите динамическую память и миграцию). Установите на нее серверную часть платформы «1С:Предприятие». Активируйте на этой машине все имеющиеся у вас программные лицензии на сервер и клиентов.
Откройте консоль администрирования кластера 1С. Добавьте в существующий кластер новый рабочий сервер (это будет наш выделенный сервер лицензирования). Теперь в вашем кластере присутствуют как минимум два рабочих сервера: основной рабочий сервер приложений (допустим, Server-App) и сервер лицензирования (Server-Lic).
Чтобы рабочий сервер Server-App не пытался выполнять функции лицензирования, а сервер лицензирования Server-Lic не тратил свои ресурсы на обслуживание пользовательских сеансов и баз данных, нам необходимо жестко разграничить их роли.
Перейдите в свойства сервера Server-Lic в консоли кластера, откройте раздел «Требования назначения функциональности» и создайте два правила в строгой последовательности:
Сервис лицензирования. Способ применения: Назначать. Это правило сообщает кластеру, что данный сервер обязан выполнять функции раздачи лицензий.Любой объект требования. Способ применения: Не назначать. Данное правило запрещает серверу выполнять любые другие задачи кластера (такие как работа с базами данных, сеансы пользователей, фоновые задания и т.д.).После создания правил нажмите кнопку «Применить требования назначения функциональности».
Перейдите к настройкам основного рабочего сервера Server-App. В его требованиях назначения функциональности также можно явно указать правила:
Сервис лицензирования. Способ применения: Не назначать. Это гарантирует, что основной сервер даже не попытается искать лицензии локально или запускать у себя этот сервис.Любой объект требования. Способ применения: Назначать (или использовать настройки по умолчанию).Схематично распределение требований назначения функциональности в консоли кластера выглядит следующим образом:
// Настройки требований назначения функциональности (ТНФ)
// для выделенного сервера лицензирования (Server-Lic):
1. Объект: "Сервис лицензирования" -> Способ: "Назначать"
2. Объект: "Любой объект" -> Способ: "Не назначать"
// Настройки требований назначения функциональности (ТНФ)
// для основного рабочего сервера приложений (Server-App):
1. Объект: "Сервис лицензирования" -> Способ: "Не назначать"
2. Объект: "Любой объект" -> Способ: "Назначать"
Благодаря такой архитектуре основной сервер приложений Server-App при подключении новых пользователей будет автоматически перенаправлять запросы на получение лицензий серверу Server-Lic. Если вам потребуется добавить оперативной памяти на основной сервер приложений или полностью перенести его на другой физический хост, это никак не повлияет на работу пользователей, поскольку программные лицензии привязаны к неизменяемому серверу лицензирования.
Подведем итог нашему анализу. Выбор между программной и аппаратной лицензией должен основываться на архитектуре вашей ИТ-инфраструктуры: