При администрировании крупных и динамично развивающихся инфраструктур «1С:Предприятие» системные администраторы часто сталкиваются с ситуацией, когда в эксплуатации одновременно находятся несколько информационных баз, работающих на разных версиях платформы. Например, одна критически важная база требует стабильной работы на старом проверенном релизе (скажем, 8.3.14.1976), в то время как новые конфигурации уже переведены на более свежую версию платформы (например, 8.3.15.1830).
Если при этом у организации имеется единый крупный пакет программных лицензий (например, многопользовательский программный ключ на 500 рабочих мест), возникает резонный вопрос: как организовать раздачу этих лицензий на все рабочие серверы, независимо от версии используемой ими платформы? Можно ли использовать один выделенный сервер лицензирования для разных версий платформ «1С»?
В этой статье мы подробно разберем, как устроена раздача программных лицензий, проанализируем ограничения платформы и пошагово настроим отказоустойчивую схему с выделенным сервером лицензирования для нескольких версий «1С:Предприятия».
Для начала проясним важный технический момент, который часто вызывает путаницу среди начинающих администраторов. В отличие от аппаратных ключей защиты HASP, для которых требуется сетевая служба HASP License Manager, программные лицензии (файлы с расширением .lic) обрабатываются непосредственно самой платформой «1С:Предприятие». Никакие сторонние утилиты для раздачи программных лицензий по сети не используются.
В роли сервера лицензирования выступает обычный рабочий сервер кластера «1С:Предприятия», которому через механизмы требований назначения функциональности (ТНФ) делегирована единственная роль — Сервис лицензирования.
Важное ограничение платформы: процесс ragent (агент сервера 1С) конкретной версии может напрямую взаимодействовать и обслуживать только те рабочие серверы, которые функционируют на точно такой же версии платформы. Версия сервера лицензирования должна строго соответствовать версии подключающегося к нему рабочего сервера. Сервер лицензирования более ранней версии не сможет выдать лицензию серверу с более поздней версией платформы, и наоборот.
Официальная техническая поддержка «1С» подтверждает это правило. Однако это не означает, что нам придется приобретать отдельные ключи или разворачивать множество физических серверов. Решение заключается в параллельном запуске нескольких служб агентов разных версий на одном физическом или виртуальном сервере лицензирования, которые будут обращаться к одному общему файлу программной лицензии.
Рассмотрим по шагам, как реализовать эту схему на практике.
Первым делом нам необходимо установить все требуемые версии платформы «1С:Предприятие» на наш выделенный сервер лицензирования. В нашем примере это будут версии 8.3.15.1830 и 8.3.14.1976.
При установке платформы через стандартный установщик Windows или пакетный менеджер Linux файлы платформы устанавливаются в разные каталоги, что позволяет им сосуществовать без конфликтов. Однако по умолчанию установщик создает только одну службу автоматического запуска агента сервера (для последней установленной версии), которая занимает стандартные сетевые порты.
Наша задача — вручную зарегистрировать и настроить две параллельно работающие службы агента сервера для каждой версии платформы.
Чтобы две службы ragent могли работать одновременно на одной операционной системе, мы должны развести их по разным сетевым портам и выделить каждой службе свой собственный каталог данных кластера (параметр srvinfo). Если запустить их с общим каталогом данных, произойдет повреждение файлов конфигурации кластера.
Допустим, версия 8.3.15.1830 будет использовать стандартные порты, а для версии 8.3.14.1976 мы настроим альтернативные.
Стандартные порты:
154015411560-1591C:\Program Files\1cv8\srvinfoАльтернативные порты для версии 8.3.14.1976:
254025412560-2591C:\1C_Data\srvinfo_8_3_14Для создания второй службы в Windows воспользуемся утилитой командной строки sc.exe. Запустим командную строку от имени Администратора и выполним следующую команду (обратите внимание на обязательные пробелы после знаков равенства):
sc create "1C:Enterprise 8.3.14.1976 Server Agent" binPath= "\"C:\Program Files\1cv8\8.3.14.1976\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"C:\1C_Data\srvinfo_8_3_14\"" start= auto
Если сервер лицензирования работает под управлением ОС Linux, настройка выполняется путем создания отдельного конфигурационного файла службы в каталоге /etc/systemd/system/. Мы создаем копию unit-файла службы, переименовываем его (например, в srv1cv83_8_3_14.service) и правим параметры запуска в строке ExecStart, указывая альтернативные порты и каталог данных через ключи -port, -regport, -range и -d.
Теперь разберемся, где должны физически располагаться файлы программных лицензий, чтобы обе службы разных версий платформ имели к ним беспрепятственный доступ.
Платформа «1С:Предприятие» производит поиск файлов лицензий (файлов с расширением .lic) в строго определенных каталогах. Чтобы лицензия была видна всем запущенным на сервере службам, мы не должны привязывать ее к каталогам конкретных релизов платформ. Вместо этого файлы лицензий необходимо разместить в общей системной директории, которая сканируется любыми версиями платформы.
Рекомендуемые общие пути для размещения лицензий:
%ProgramData%\1C\licenses (обычно это путь C:\ProgramData\1C\licenses)/var/1C/licensesКрайне важный нюанс: права доступа операционной системы.
По умолчанию службы «1С» запускаются от имени специального системного пользователя (например, USR1CV8). Если вы настроили запуск разных служб от имени разных учетных записей (например, для разграничения прав или безопасности), убедитесь, что обе эти учетные записи имеют полные права (на чтение, запись и изменение) к общей папке с лицензиями. При активации или обновлении лицензий файлы привязки могут перезаписываться, и отсутствие прав у одной из служб приведет к тому, что эта служба перестанет видеть программный ключ.
После запуска служб на сервере лицензирования нам необходимо правильно распределить роли в консоли администрирования кластеров «1С». Это необходимо для того, чтобы наш сервер лицензирования занимался исключительно раздачей лицензий и не забирал на себя вычислительную нагрузку (сеансы пользователей, фоновые и регламентные задания), что может снизить общую производительность системы. Для удобного управления кластерами различных версий без конфликтов штатных утилит можно использовать мультиверсионную консоль администрирования кластера серверов 1С.
Проанализируем настройку требований назначения функциональности для обоих серверов в составе нашего кластера.
На основном рабочем сервере приложений (где выполняются вычисления и работают пользователи):
Нам нужно явно указать серверу, что он должен обрабатывать все клиентские соединения, но не должен сам выполнять функции сервиса лицензирования. Настроим следующие правила:
Клиентское соединение с ИБ, тип требования — Назначать.Сервис лицензирования, тип требования — Не назначать.На выделенном сервере лицензирования (который мы только что настроили):
Здесь ситуация зеркальная. Сервер должен брать на себя только выдачу лицензий и полностью отказываться от любых других задач:
Сервис лицензирования, тип требования — Назначать.Любой объект требования, тип требования — Не назначать.Убедитесь, что правила на серверах расположены именно в такой последовательности. После создания требований примените их, выполнив команду обновления конфигурации кластера в консоли.
Выделение сервера лицензирования часто вызывает вопрос: требуется ли покупать дополнительную серверную лицензию («1С:Предприятие x64») для самого сервера лицензирования?
Рассмотрим эту ситуацию. Если сервер лицензирования работает в составе общего кластера, он технически выступает в роли дополнительного рабочего сервера кластера. На нем запущены рабочие процессы, которые требуют лицензирования сервера.
Чтобы избежать необходимости тратить отдельную лицензию на сервер «1С» для сервера лицензирования, рекомендуется применить следующий архитектурный прием:
Сразу после установки и запуска платформы на сервере лицензирования зайдите в консоль администрирования и полностью удалите локальный кластер, созданный по умолчанию на этом сервере. Таким образом, сервер лицензирования перестанет быть самостоятельным кластером. Затем мы просто добавляем этот сервер как дополнительный рабочий сервер в наш основной рабочий кластер. В таком режиме выделенный сервер будет выполнять только сервисные функции распределения лицензий и не потребует отдельной активации серверного ключа, если файлы привязки единой серверной лицензии лежат в общей доступной папке.
Программные лицензии «1С» чрезвычайно чувствительны к изменению конфигурации оборудования. Изменение объема оперативной памяти, добавление ядер процессора, замена сетевой карты или обновление BIOS приводят к тому, что лицензия «слетает», и требуется повторная активация с использованием резервного пин-кода (количество которых ограничено).
Для минимизации этих рисков мы настоятельно рекомендуем разворачивать сервер лицензирования в среде виртуализации (например, Hyper-V, VMware vSphere, Proxmox VE) в виде отдельной малоресурсной виртуальной машины. Зафиксируйте для этой виртуальной машины минимальные параметры (например, 2 ядра процессора, 4 ГБ оперативной памяти) и никогда не меняйте их.
При такой архитектуре вы сможете абсолютно свободно масштабировать ваши основные рабочие серверы приложений (добавлять ресурсы при росте нагрузки, менять конфигурацию дисков, переносить на другое физическое железо) без малейшего риска деактивации лицензий, поскольку стабильная виртуальная машина сервера лицензирования останется неизменной.
Мы подробно разобрали схему организации единого сервера лицензирования для разных версий платформ «1С:Предприятие». Данный подход позволяет эффективно утилизировать имеющиеся многопользовательские программные ключи, упрощает администрирование лицензий и повышает отказоустойчивость всей корпоративной системы. Следуя описанным шагам по настройке портов, разделению каталогов данных и правильному конфигурированию ТНФ, вы без труда сможете развернуть стабильную инфраструктуру для обслуживания любых версий платформы в вашей организации.