← На главную

При проектировании высокодоступных систем на базе 1С:Предприятие 8.3 одним из самых критичных вопросов является расчет необходимого количества клиентских лицензий. Часто возникает ситуация, когда после включения механизмов отказоустойчивости привычное количество лицензий внезапно исчерпывается. Проанализируем, почему это происходит, как работает механизм резервирования сеансов и на что следует обратить внимание при настройке кластера.

Механизм «избыточности» и формула N+1

Для начала разберем базовый принцип работы отказоустойчивого кластера 1С. В платформе 8.3 отказоустойчивость реализована через дублирование данных сеанса. Уровень отказоустойчивости — это параметр в настройках кластера, который определяет, какое количество рабочих серверов может одновременно выйти из строя без прерывания работы пользователей.

Рассмотрим стандартную логику: если мы устанавливаем уровень отказоустойчивости равным 1, система должна гарантировать, что при падении любого одного сервера пользователь продолжит работу. Для этого для каждого активного сеанса кластер автоматически создает резервную копию на другом рабочем сервере. Таким образом, на каждый вход пользователя в систему фактически открывается 2 сеанса: один основной (активный) и один резервный. Если уровень отказоустойчивости равен 2, то будут созданы 1 основной и 2 резервных сеанса (всего 3).

Проанализируем влияние этой настройки на расход лицензий. В случае использования программных лицензий, которые выдаются сервером «1С», каждое соединение с информационной базой считается отдельно. Это означает, что при уровне отказоустойчивости 1 расход лицензий увеличивается ровно в два раза. Рассмотрим пример: если у вас 100 пользователей и включена отказоустойчивость 1, сервер попытается списать 200 лицензий.

Зависимость от типа лицензирования (Программные vs Аппаратные)

Важно понимать, что кратный расход лицензий проявляется не всегда. Выясним, как ведут себя разные типы ключей защиты:

1. Программные лицензии, выдаваемые сервером: Это наиболее «затратный» вариант. Менеджер лицензий на стороне сервера учитывает каждый созданный сеанс (включая резервные). Если лицензий в пуле недостаточно для создания резервного сеанса, отказоустойчивость для конкретного пользователя просто не будет обеспечена, либо вход будет заблокирован.
2. Аппаратные ключи (HASP) сетевые: При использовании HASP License Manager лицензия обычно выдается на рабочее место (на компьютер). Поскольку и основной, и резервный сеансы инициируются с одной и той же клиентской машины под одной учетной записью, License Manager видит это как одно рабочее место и занимает только один слот в ключе. В этом случае расход лицензий не увеличивается.
3. Локальные программные лицензии: Если лицензия активирована непосредственно на компьютере пользователя, она также позволяет запускать несколько сеансов в рамках одного терминального сеанса или рабочего места, что нивелирует проблему кратного расхода.

Технические нюансы резервных сеансов

Резервные сеансы — это не просто записи в базе данных, это живые объекты, которые требуют ресурсов. Проанализируем, на что еще, кроме лицензий, влияет отказоустойчивость:

Во-первых, это потребление оперативной памяти. Каждый резервный сеанс на рабочих серверах (rphost) потребляет память для хранения состояния переменных, открытых форм и временных таблиц. В среднем, включение уровня отказоустойчивости 1 увеличивает потребление RAM кластером на 70–100%.

Во-вторых, это нагрузка на сеть. Между рабочими серверами постоянно происходит синхронизация данных сеанса. Рассмотрим процесс: пользователь меняет значение реквизита на форме — эта информация должна быть мгновенно передана на все серверы, где хранятся резервные копии этого сеанса. При большом количестве пользователей и высоком уровне отказоустойчивости это может создать значительный трафик внутри кластера.

Ограничения и правила настройки центральных серверов

Разберем важную зависимость между уровнем отказоустойчивости и количеством физических машин. Существует правило: уровень отказоустойчивости не может быть больше, чем (Количество центральных серверов - 1).

Центральный сервер — это узел, на котором запущен менеджер кластера (rmngr), управляющий реестром сеансов. Если у вас всего один центральный сервер, то установка уровня отказоустойчивости в значение 1 не имеет смысла: при падении этого сервера упадет весь кластер целиком, независимо от наличия резервных сеансов на рабочих серверах.

Посмотрим на практический пример из экспертных тестов: в кластере 2 центральных сервера и 1 рабочий сервер. Мы устанавливаем уровень отказоустойчивости 2. Сколько будет создано соединений? Теоретически — 3. Однако на практике система ограничит количество резервных копий физически доступными узлами. Поскольку менеджер кластера старается разносить копии сеансов на разные машины, для полноценной работы уровня 2 нам потребовалось бы минимум 3 центральных сервера.

Лицензирование серверной части

Не забудем про серверные лицензии. Для работы полноценного отказоустойчивого кластера с несколькими центральными серверами необходимо, чтобы на каждом сервере, где запущен rmngr, была доступна серверная лицензия 1С (32-разрядная или 64-разрядная). В случае с программными лицензиями их необходимо активировать на каждом узле кластера отдельно.

Итоги и рекомендации

Подводя итог, при планировании инфраструктуры с отказоустойчивостью следует придерживаться следующих шагов:

1. Определите тип ваших клиентских лицензий. Если они программные и раздаются сервером — закладывайте бюджет на покупку дополнительных лицензий в соответствии с формулой КоличествоПользователей * (УровеньОтказоустойчивости + 1).
2. Проверьте количество центральных серверов. Их количество должно быть минимум на единицу больше желаемого уровня отказоустойчивости.
3. Оцените объем оперативной памяти на рабочих серверах. Резервные сеансы «прожорливы», и нехватка памяти может привести к аварийному завершению рабочих процессов rphost, что обесценит саму идею отказоустойчивости.
4. Для критически важных систем рассмотрите использование аппаратных ключей защиты, чтобы избежать дополнительных затрат на лицензии при масштабировании кластера.

В современных версиях платформы (8.3.20 и выше) механизмы работы с сеансовыми данными постоянно оптимизируются, однако фундаментальный принцип избыточности остается неизменным. Отказоустойчивость в 1С — это всегда компромисс между надежностью и стоимостью владения системой.