При администрировании крупных инфраструктур 1С часто возникает необходимость развернуть несколько независимых контуров (например, рабочий и тестовый) или организовать резервную систему для обеспечения отказоустойчивости. В процессе проектирования системные администраторы неизбежно сталкиваются с вопросами лицензирования: сколько лицензий потребуется, если создать второй кластер 1С на том же «железе», как правильно настроить программные ключи и какие ограничения накладывают различные версии платформы? В этой статье мы подробно разберем все тонкости лицензирования кластеров 1С на одном и нескольких серверах.
Для начала проанализируем фундаментальный принцип, на котором строится вся лицензионная политика фирмы 1С в отношении серверной части платформы. Серверная лицензия (как программная, так и аппаратная) привязывается к экземпляру операционной системы (хосту), на котором функционирует сервер приложений.
Из этого правила вытекают следующие ключевые выводы:
Рассмотрим наглядную схему, которая поможет окончательно закрепить это понимание:
На практике администраторы часто сталкиваются с неприятной ситуацией: на сервере успешно активирована программная лицензия, первый кластер работает без проблем, но при запуске второй службы (например, под другой порт или другой версии платформы) система выдает ошибку отсутствия лицензии. Давайте выясним причину этого поведения.
Проблема кроется в механизме поиска файлов лицензий (файлов с расширением .lic) и правах доступа операционной системы. По умолчанию при активации программного ключа файл лицензии создается в профиле того пользователя ОС, от имени которого выполнялась активация (например, учетная запись администратора). Если ваши службы сервера 1С запущены от имени разных системных пользователей (например, одна служба работает под учетной записью USR1CV8, а вторая — под LocalSystem или другим локальным пользователем), то вторая служба физически не сможет прочитать файл лицензии из чужого профиля.
Чтобы решить эту проблему раз и навсегда, выполним перенос лицензий в общую директорию по шагам:
.lic в профиле пользователя, выполнявшего активацию (обычно это папка %USERPROFILE%\AppData\Local\1C\1cv8\conf или каталог установки платформы).C:\ProgramData\1C\1cv8\shared\licenses
/var/1C/licenses
USR1CV8), есть полные права на чтение и запись в этой директории.Для создания второй службы сервера 1С на альтернативных портах в Windows мы можем использовать следующую команду в командной строке (запущенной от имени администратора):
sc create "1C:Enterprise 8.3 Server Agent (Port 1640)" binPath= "\"C:\Program Files\1cv8\8.3.24.1368\bin\ragent.exe\" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \"C:\srvinfo_1640\"" start= auto obj= ".\usr1cv8" password= "YourStrongPassword"
После этого не забудьте настроить права на каталог C:\srvinfo_1640 для пользователя usr1cv8.
Если в вашей организации развернуто множество серверов и баз данных, постоянный перенос файлов лицензий и их повторная активация при смене конфигурации оборудования могут стать настоящим кошмаром. Для решения этой проблемы в платформе 1С:Предприятие предусмотрен механизм выделенного сервера лицензирования.
Рассмотрим, как работает эта технология:
Главный плюс такого подхода для отказоустойчивости заключается в том, что сам выделенный сервер лицензирования не требует покупки отдельной серверной лицензии 1С, если на нем физически не запускаются рабочие процессы баз данных. При выходе из строя основного рабочего сервера приложений вы сможете безболезненно переключить пользователей на резервный сервер без необходимости повторной активации лицензий и траты драгоценных пин-кодов, ведь лицензии жестко привязаны к неизменному серверу лицензирования. Для удобного управления серверами в таких сценариях можно использовать кроссплатформенную консоль администрирования кластера.
Планируя архитектуру резервирования и создания кластеров, критически важно учитывать технологические различия между лицензиями уровней ПРОФ и КОРП. Попытка построить отказоустойчивый кластер на лицензиях ПРОФ приведет к тому, что система просто не позволит использовать расширенные функции резервирования.
Давайте проанализируем ключевые ограничения лицензий уровня ПРОФ:
rphost).Таким образом, если перед вами стоит задача создать полноценный «горячий» отказоустойчивый кластер из двух параллельно работающих серверов приложений, которые страхуют друг друга в режиме реального времени, вам технически и юридически потребуются лицензии КОРП (как серверные, так и клиентские). Смешивать лицензии ПРОФ и КОРП в рамках одного кластера категорически запрещено лицензионным соглашением.
Если бюджет компании ограничен и покупка двух серверных лицензий (или лицензий КОРП) невозможна, администраторы часто прибегают к схеме «холодного» резерва. При такой схеме у нас есть основной сервер (активный) и резервный сервер (на котором служба 1С установлена, но выключена).
В случае аварии на основном сервере администратор вручную запускает службу на резервном сервере. С точки зрения лицензирования здесь есть важные нюансы:
Подводя итог, отметим: для разворачивания нескольких кластеров на одной машине достаточно одной серверной лицензии. Но для построения надежной, масштабируемой и отказоустойчивой системы на разных физических хостах необходимо детально планировать бюджет с учетом покупки дополнительных серверных лицензий и выбора правильного уровня платформы (ПРОФ или КОРП). Для организации отдельных контуров разработки можно использовать скрипт для автоматической установки серверной комьюнити-лицензии.