При росте нагрузки на информационные базы 1С:Предприятие перед системными администраторами и архитекторами неизбежно встает вопрос обеспечения высокой доступности и отказоустойчивости (High Availability). Классический сценарий, с которого начинают многие компании — построение кластера из двух физических или виртуальных серверов приложений. В этой статье мы подробно разберем, насколько жизнеспособна схема из двух серверов, как правильно ее спроектировать, какие технические и лицензионные ограничения накладывает платформа, и как защитить систему от критических сбоев.
Для начала разберем базовое понятие платформы 1С:Предприятие — Центральный сервер кластера. Центральный сервер отвечает за управление кластером, хранение реестра кластера и координацию работы всех рабочих процессов. В стандартной (неотказоустойчивой) конфигурации центральный сервер в кластере всего один. Если он выходит из строя, вся работа пользователей прекращается.
Чтобы защитить систему от падения центрального сервера, платформа позволяет назначить роль центрального нескольким серверам в составе одного кластера. Для расчета необходимого количества таких серверов используется классическая формула платформы:
Количество центральных серверов = Уровень отказоустойчивости + 1
Разберем, как это работает на практике в конфигурации из двух серверов приложений:
Рассмотрим детальнее риски использования уровня отказоустойчивости «1» на двух серверах. Постоянная репликация данных сеансов по сети создает колоссальную нагрузку. При возникновении малейших сетевых задержек между двумя серверами система может начать «застревать», генерируя системные ошибки формата потока или сообщения о потере сеанса. Именно поэтому для полноценного бесшовного перехода рекомендуется закладывать в архитектуру не менее трех серверов приложений.
Проанализируем важнейший юридический и технический аспект построения кластера. Начиная с версии платформы 8.3.14, фирма 1С жестко разграничила функционал лицензий уровней ПРОФ и КОРП на техническом уровне. Попытка настроить отказоустойчивый кластер на обычных лицензиях ПРОФ заблокирована платформой.
Если у вас установлены лицензии уровня ПРОФ, для вас действуют следующие жесткие ограничения:
Таким образом, для реализации любой схемы отказоустойчивости (даже с уровнем 0 на двух серверах) вам в обязательном порядке потребуются серверные и клиентские лицензии уровня КОРП.
Выясним причину, почему классические кластерные системы избегают четного количества узлов без внешних арбитров. Представим ситуацию: у нас есть Сервер А и Сервер Б. Между ними неожиданно пропадает сетевой линк (например, из-за сбоя коммутатора), но оба сервера продолжают физически работать.
В этот момент возникает ситуация Split-Brain (расщепление мозга):
Пользователи, подключенные к разным коммутаторам, продолжают работать с разными серверами одного и того же кластера, что приводит к рассинхронизации реестра, конфликтам транзакций и гарантированной порче данных в СУБД. Для предотвращения этой ситуации полноценным кластерам требуется нечетное число участников (минимум 3) для организации кворума (голосования) или выделенный внешний сервис-арбитр.
Рассмотрим по шагам, как правильно настроить совместную работу двух серверов в составе одного кластера с помощью консоли администрирования. Одним из главных преимуществ КОРП-лицензий является возможность тонкого распределения нагрузки с помощью механизма ТНФ. Это позволяет решить проблему «тяжелых» отчетов и фоновых заданий, которые могут монополизировать ресурсы одного из серверов.
Для создания правил распределения выполните следующие действия в консоли администрирования кластера:
Server-App-1).Server-App-2) настроим обработку тяжелых фоновых и регламентных задач:
Такое распределение гарантирует, что если один из пользователей запустит ресурсоемкий отчет или групповое проведение документов за несколько лет, это фоновое задание выполнится на втором сервере, не вызывая зависаний и задержек интерфейса у пользователей, работающих интерактивно на первом сервере.
Построение отказоустойчивого кластера серверов приложений 1С бессмысленно, если у вас остаются другие единые точки отказа (Single Point of Failure). Разберем, как защитить смежные компоненты системы.
1. Сервер баз данных (СУБД)
Если ваши сервера 1С зарезервированы, а СУБД развернута на единственном сервере без репликации, при его выходе из строя работа остановится. Для обеспечения отказоустойчивости базы данных на двух серверах применяют следующие решения:
AlwaysOn Availability Groups в режиме синхронной репликации (один сервер активен на чтение/запись, второй находится в горячем резерве).Patroni. Стоит учитывать, что для корректной работы распределенного реестра настроек (etcd или Consul) в Patroni также крайне рекомендуется иметь третий узел-арбитр (им может выступать легкая виртуальная машина).2. Сервер лицензирования
Программные лицензии 1С привязываются к конкретным аппаратным характеристикам сервера. Если вы активировали лицензии на Сервере А, при его падении Сервер Б не сможет раздавать лицензии пользователям. Существует два основных способа решения этой проблемы:
Чтобы защитить сервера от падения из-за утечек памяти или неоптимального кода, в настройках кластера обязательно нужно задать лимиты потребления ресурсов рабочими процессами rphost. Посмотрим на параметры конфигурации, которые необходимо задать в свойствах вашего кластера:
rphost. Рекомендуется устанавливать на уровне 80-90% от физической оперативной памяти сервера, деленной на количество рабочих процессов.Пример настройки лимитов позволяет платформе своевременно реагировать на перегрузку: «провинившийся» процесс помечается как выключаемый, новые соединения на него не направляются, а активные пользователи постепенно и незаметно переносятся на новые, чистые процессы rphost.
Подводя итог, можно утверждать: создание отказоустойчивого кластера на двух серверах — это нормальная и широко распространенная практика. Однако для ее успешной реализации необходимо четко понимать ограничения лицензирования КОРП, правильно распределять роли процессов и обеспечивать резервирование СУБД и сервера лицензий.