← На главную

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

Различие в архитектуре 8.2 и 8.3: уходим от групп резервирования

В первую очередь нам необходимо прояснить важный технический момент. В старых версиях платформы (8.2) существовало понятие Группы резервирования кластеров. В версии 8.3 этот механизм был полностью переработан. Теперь отказоустойчивость обеспечивается наличием нескольких Центральных серверов внутри одного кластера. Мы больше не создаем «запасной» кластер, мы расширяем текущий, добавляя в него новые рабочие серверы и назначая им роль центральных.

Уровень отказоустойчивости: что это такое?

Основной параметр, определяющий поведение системы при сбое — это Уровень отказоустойчивости. Давайте разберем, что означают его значения:

1. Уровень 0: Это стандартная настройка. Если один из серверов кластера выходит из строя, все сеансы, которые он обслуживал, завершаются с ошибкой. Пользователю придется перезапустить 1С, и система переподключит его к оставшемуся рабочему серверу. Это не является «бесшовным» переключением, но обеспечивает работоспособность базы после аварии.
2. Уровень 1 и выше: Это режим, при котором платформа реплицирует (копирует) данные сеансов между серверами. Если основной сервер падает, другой сервер подхватывает работу без прерывания сеанса. Для пользователя это может выглядеть как кратковременное зависание на несколько секунд.

Важное уточнение: Настройка уровня отказоустойчивости выше нуля требует наличия лицензий уровня КОРП. В версии ПРОФ этот параметр жестко зафиксирован на значении 0.

Проблема кворума: почему двух серверов может быть недостаточно?

Рассмотрим ситуацию, когда в нашем кластере всего два центральных сервера. Для принятия решений кластер использует алгоритм большинства (majority). Если связь между серверами разрывается или один из них падает, оставшийся сервер «видит», что он один из двух (50%), что не является большинством. В такой ситуации кластер может стать нестабильным или прекратить работу для предотвращения повреждения данных. Это называется потерей кворума.

Поэтому мы рекомендуем использовать формулу: Количество центральных серверов = Уровень отказоустойчивости * 2 + 1. Для обеспечения надежной работы при выходе из строя одного сервера (уровень 1) желательно иметь три центральных сервера. В этом случае при падении одного сервера оставшиеся два (66%) составят кворум и продолжат работу в штатном режиме.

Настройка требований назначения функциональности

Чтобы система работала максимально эффективно, мы можем использовать Требования назначения функциональности. Это позволяет нам гибко распределять нагрузку. Проанализируем сценарий, в котором у нас три сервера:

1. Сервер 1 и Сервер 2: Назначаем им высокий приоритет для обслуживания клиентских соединений и работы rphost.
2. Сервер 3: Назначаем ему приоритет для сервиса лицензирования и хранения сеансовых данных.

В такой конфигурации, если упадет один из «рабочих» серверов (1 или 2), сеансовые данные сохранятся на третьем сервере, и переключение для пользователя произойдет максимально прозрачно.

Особенности лицензирования в отказоустойчивом кластере

Разберем вопрос, который часто ставит в тупик администраторов: где хранить лицензии? В отказоустойчивом кластере есть два пути:

• Использование аппаратных USB-ключей: Если ключи доступны по сети или проброшены в виртуальные машины, серверы могут использовать их совместно.
• Программные лицензии: Программная лицензия «привязывается» к параметрам конкретного сервера. Если вы активировали лицензию на первом сервере, а он упал, второй сервер не сможет использовать этот же файл лицензии.

Решение: Нам необходимо либо активировать дополнительные комплекты лицензий на резервном сервере, либо вынести Сервис лицензирования на отдельный маломощный сервер (возможно, виртуальный), параметры которого не будут меняться при сбое основных физических серверов. В настройках кластера через Требования назначения функциональности мы жестко фиксируем Сервис лицензирования за этим стабильным узлом.

Пример настройки через консоль администрирования

Посмотрим на логику действий при добавлении второго сервера в существующий кластер:

1. Запускаем консоль администрирования серверов 1С.
2. В ветке Рабочие серверы добавляем новый сервер (указываем его имя и порт 1540).
3. В свойствах кластера устанавливаем Уровень отказоустойчивости равным 1 (требуется лицензия КОРП).
4. Заходим в свойства нового рабочего сервера и ставим галочку Центральный сервер.
5. Настраиваем Требования назначения функциональности. Например, для переноса журналов регистрации на конкретный сервер:
   Скопировать код

   
   Тип объекта требования: Сервис регистрации событий
   Действие: Назначать
   Имя сервера: Server02
   Приоритет: 10
   

Хранение сеансовых данных и журнала регистрации

Выясним причину, по которой пользователи могут «вылетать» даже при настроенной репликации. Если ваш Журнал регистрации хранится в текстовом формате (.lgp), он физически находится на диске конкретного сервера. При падении этого сервера другие узлы кластера не смогут получить доступ к его части журнала.

Мы рекомендуем переводить журнал регистрации в формат СУБД (.lgd). Аналогично, начиная с версии платформы 8.3.18, можно настроить хранение сеансовых данных во внешнем хранилище (например, Redis). Это гарантирует, что даже при полной остановке всех процессов rphost, информация о том, что делал пользователь, не будет потеряна.

Итоги: взлетит или не взлетит?

Возвращаясь к вопросу «взлетит ли система с двумя серверами», проанализируем ситуацию:

1. Если у вас лицензии ПРОФ: Взлетит, но при падении первого сервера пользователи получат ошибку и будут вынуждены перезайти. Автоматического «подхвата» сеанса не будет.
2. Если у вас лицензии КОРП и 2 сервера: Взлетит, будет работать репликация сеансов, но есть риск потери кворума при проблемах с сетью между ними.
3. Если у вас лицензии КОРП и 3 сервера: Это наиболее надежный вариант, обеспечивающий истинную отказоустойчивость и возможность проведения регламентных работ на одном из серверов без остановки всей системы.

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