При развитии ИТ-инфраструктуры предприятия часто возникает ситуация, когда необходимо одновременно поддерживать работу старых информационных баз на специфических релизах платформы (например, 8.3.13) и внедрять новые программные продукты, требующие актуальных версий 1С (например, 8.3.23 и выше). Рассмотрим подробно, как правильно настроить лицензирование в такой гибридной среде, разберем архитектурные нюансы и выясним, стоит ли использовать виртуализацию для сервера лицензирования.
Разберем ситуацию, когда нам необходимо запустить два разных кластера 1С на одной физической или виртуальной машине. По умолчанию сервер 1С занимает порты 1540, 1541 и диапазон 1560-1591. Чтобы запустить вторую версию платформы, нам потребуется разнести их по портам и создать отдельную службу Windows.
Проанализируем шаги по настройке второго экземпляра сервера:
sc create.1640, 1641 и диапазон 1660-1691).Пример команды для регистрации второго сервера 1С:
sc create "1C:Enterprise 8.3.23 Server" binPath= "C:\Program Files\1cv8\8.3.23.XXXX\bin\ragent.exe -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \"C:\ProgramData\1C\1cv8_alt_cluster\"" displayname= "1C:Enterprise 8.3.23 Server Custom" start= auto
Важный нюанс лицензирования: При такой схеме оба кластера будут работать в рамках одной операционной системы. Программные лицензии 1С (файлы с расширением .lic) обычно располагаются в общих каталогах, доступных для всех установленных версий платформы. Основной путь поиска лицензий в Windows — C:\ProgramData\1C\licenses. Рассмотрим, как это работает: оба экземпляра ragent.exe обращаются к этой папке. Благодаря механизмам файловых блокировок ОС, платформа корректно «дербанит» лицензии из общего файла, распределяя их между сессиями пользователей разных баз. Вам не потребуется покупать два комплекта лицензий на 50 пользователей, если общее число одновременно работающих сотрудников в обеих базах не превышает 50.
Выясним, всегда ли нужно плодить сущности и ставить несколько платформ. В свойствах любой конфигурации 1С существует параметр Режим совместимости. Рассмотрим подробнее этот механизм. Если у вас есть самописная база, которая стабильно работала на релизе 8.3.13, вы можете запустить её на актуальной платформе 8.3.23, установив в свойствах конфигурации режим совместимости "Версия 8.3.13".
Это решение имеет ряд преимуществ:
ragent, один набор портов и одна версия исполняемых файлов.Однако, перед окончательным переходом, проанализируем риски. Необходимо провести тщательное тестирование самописки на новой платформе. Хотя вероятность успеха составляет более 99%, стоит обратить внимание на работу внешних компонент и специфических запросов к СУБД, которые могли измениться в движке платформы.
Разберем вопрос автора о целесообразности выноса сервера лицензирования на отдельную виртуальную машину. Современная технология 1С (на базе Ring) позволяет развернуть отдельный Сервер лицензирования.
Это оправдано в следующих случаях:
Внимание: Программная лицензия 1С «привязывается» к характеристикам железа. Если вы измените количество ядер на сервере, где активированы лицензии, они «слетят». Если же лицензии активированы на маленькой, стабильной виртуальной машине (сервере лицензирования), параметры которой никогда не меняются, вы можете свободно масштабировать основные рабочие сервера 1С без риска потери активации.
Чтобы «соломка была постелена» правильно при виртуализации, проанализируем ключевые параметры, которые нельзя менять в настройках гипервизора (ESXi, Hyper-V, Proxmox):
В архитектуре, предложенной автором (SQL + Сервер 1С на одной машине, RDS + WEB на другой), есть два способа доставки клиентских лицензий пользователю:
Способ А. Выдача лицензий сервером 1С. В настройках информационной базы в консоли администрирования кластера установите флаг Разрешить выдачу лицензий сервером 1С в значение Да. В этом случае сервер 1С сам забирает лицензию из своего локального хранилища и передает её клиенту. Это идеальный вариант для веб-клиентов и тонких клиентов, работающих через интернет.
Способ Б. Получение лицензии терминальным сервером (RDS). Вы можете активировать многопользовательскую лицензию прямо на сервере RDS. В этом случае клиентское приложение 1С, запущенное в сессии пользователя, само находит файл лицензии в папке C:\ProgramData\1C\licenses терминального сервера. Этот метод эффективен тем, что одна лицензия тратится на одну терминальную сессию пользователя, сколько бы баз 1С он ни открыл внутри этой сессии.
Подводя итог, проанализируем оптимальную стратегию: для двух баз на разных платформах в рамках одного сервера проще всего использовать общий каталог лицензий. Если же планируется активное расширение и изменение серверных мощностей, вынос активации на отдельную «замороженную» по параметрам виртуальную машину с Сервером лицензирования станет профессиональным и надежным решением.