Рассмотрим ситуацию, которая часто возникает при масштабировании инфраструктуры 1С:Предприятие. Организация планирует добавить второй сервер лицензирования в существующий кластер, надеясь либо увеличить общее количество доступных лицензий, либо обеспечить бесперебойную работу при отказе одного из узлов. В этой статье мы подробно разберем, как ведет себя платформа в такой конфигурации, опираясь на справку по решениям различных задач администрирования 1С, и выясним, почему простое добавление сервера не всегда решает задачу расширения лимитов.
Для начала проанализируем, как именно 1С:Предприятие 8.3 взаимодействует с лицензиями. В современной архитектуре за раздачу программных лицензий отвечает специальный компонент — Сервис лицензирования (ServiceLicensing). В рамках одного кластера этот сервис может быть назначен на один или несколько рабочих серверов с помощью механизма Требований назначения функциональности (ТНФ).
Важно понимать ключевой принцип: в один момент времени для конкретной информационной базы или сеанса активным является только один экземпляр сервиса лицензирования. Если мы добавим в кластер два сервера с ролью "Сервис лицензирования", платформа выстроит их в иерархию согласно приоритетам, указанным в ТНФ.
Рассмотрим сценарий работы:
Таким образом, мы выяснили важный нюанс: второй сервер в кластере служит для отказоустойчивости, а не для автоматического суммирования емкости лицензий при их исчерпании на первом узле.
Разберем по шагам, как правильно настроить кластер, чтобы при падении основного сервера лицензирования работа не остановилась. Для этого мы будем использовать стандартную оснастку или кроссплатформенную консоль администрирования OneS Cluster Admin, которая позволяет более гибко управлять параметрами кластера.
Проанализируем необходимые настройки требований назначения функциональности:
Сервис лицензированияНазначать10Сервис лицензированияНазначать5 (ниже, чем у основного)При такой настройке, если основной сервер станет недоступен (отключится питание, пропадет сеть или упадет служба ragent), кластер переведет сервис лицензирования на второй сервер. Однако здесь кроется главная экономическая ловушка.
Программных лицензии 1С жестко привязываются к ключевым характеристикам сервера: имени компьютера, модели процессора, объему оперативной памяти, параметрам ОС и BIOS. Это накладывает серьезные ограничения при создании резервного сервера.
Проанализируем ситуацию с лицензированием: Нельзя просто скопировать файлы лицензий (.lic) с одного сервера на другой. На втором сервере они не пройдут проверку подлинности, так как "железо" отличается. К слову, для тестовых контуров часто используется специальная методология установки комьюнити-лицензии разработчика, которая помогает обойти некоторые ограничения при работе без GUI.
Следовательно, чтобы схема с двумя серверами лицензирования в одном кластере работала, вам необходимо:
Важный вывод: Если вы хотите, чтобы при отказе основного сервера все 100 пользователей продолжали работать, вам фактически нужно иметь 100 лицензий на первом сервере и еще 100 лицензий на втором. Они не суммируются "на лету" — работает либо один набор, либо другой.
Часто в обсуждениях возникает путаница между программными лицензиями и старыми аппаратными ключами HASP. Выясним разницу, чтобы не совершать ошибок в настройке.
Файл nethasp.ini используется только для настройки поиска аппаратных ключей через HASP License Manager. Если вы используете программные лицензии (пин-коды), редактирование этого файла никак не повлияет на работу системы. Сервис лицензирования платформы 8.3 не использует протоколы HASP для поиска своих программных лицензий.
Для аппаратных ключей логика иная: вы можете установить несколько ключей на разные серверы в сети, и менеджеры лицензий (License Manager) будут "вещать" их в сеть. Но даже в этом случае платформа 1С имеет ограничения: она не суммирует ключи одной серии (например, два ключа по 100 пользователей) на одном компьютере без специальных ухищрений.
Если ваша цель — не отказоустойчивость, а просто увеличение количества доступных мест (например, было 100, а стало нужно 150), наиболее правильным и простым решением будет:
C:\ProgramData\1C\1cv8\conf).В этом случае вам не нужно поднимать второй сервер лицензирования в кластере, и вы избежите сложностей с настройкой ТНФ. Для контроля текущей нагрузки и высвобождения лицензий можно использовать WEB приложение для управления сеансами, которое позволяет удаленно завершать лишние процессы.
Рассмотрим случай из практики: два офиса в разных частях города. Автор вопроса опасается, что при обрыве связи между офисами второй офис перестанет работать.
В такой ситуации использование общего кластера с двумя серверами лицензирования может быть не лучшим решением, так как кластер требует стабильной связи между своими узлами. Рассмотрим более надежные варианты:
Подведем итоги нашего исследования работы двух серверов лицензирования:
1. Суммирование: Внутри одного кластера 1С через механизм ServiceLicensing лицензии двух серверов не суммируются автоматически для увеличения емкости. Система работает по принципу "Основной / Резервный".
2. Отказоустойчивость: Настройка второго сервера лицензирования оправдана только для создания резерва. При этом лицензии на резервном сервере должны быть активированы отдельно (потребуются дополнительные пин-коды).
3. Приоритеты: Используйте Требования назначения функциональности для четкого определения, какой сервер должен раздавать лицензии первым. Помните, что переключение произойдет только при критическом сбое узла. Чтобы минимизировать влияние сбоев на уровне процессов, полезно внедрить автоматический перезапуск рабочих процессов rphost.
Проанализировав все технические нюансы, мы рекомендуем системным администраторам сначала определить приоритетную цель: если это масштабирование — добавляйте лицензии на текущий сервер; если это выживаемость системы — готовьтесь к дублированию лицензий на резервном узле.