← На главную

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

Суть проблемы: математика против реальности

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

Количество серверов = Уровень отказоустойчивости + 1

Если мы хотим установить уровень отказоустойчивости равный «1» (чтобы система пережила падение одного сервера), то по формуле нам нужно:

1 + 1 = 2 сервера

Однако на форумах и в профессиональных сообществах часто звучит рекомендация использовать минимум три сервера. Почему возникает это расхождение? Зачем нужен третий сервер, если математически достаточно двух? Давайте проанализируем архитектуру кластера и поймем логику.

Официальная позиция: Формула N+1

Разберем, как работает механизм отказоустойчивости с точки зрения платформы 1С версии 8.3.

Для обеспечения уровня отказоустойчивости со значением N действительно требуется наличие в кластере N+1 работоспособных серверов. Это официальный технический минимум.

Если у вас есть два физических (или виртуальных) сервера и вы настраиваете уровень отказоустойчивости «1», происходит следующее:

1. Данные сеансов пользователей реплицируются. Они хранятся на основном сервере и дублируются на резервном.
2. Сервис кластера (менеджер кластера) следит за состоянием обоих узлов.
3. При выходе из строя одного центрального сервера, второй сервер берет на себя управление и обслуживание сеансов.

В этом сценарии, если один сервер падает, пользователи могут заметить кратковременное "подвисание" (обычно 2–3 секунды), но их сеансы не прервутся, ошибки не выскочат, и работа продолжится. То есть, формально задача выполнена: отказ одного узла не привел к остановке сервиса. Для сдачи экзамена на знание платформы правильным ответом будет именно два сервера.

Инженерный подход: Концепция "Устойчивого состояния"

Теперь давайте посмотрим на ситуацию глазами системного администратора, отвечающего за непрерывность бизнеса (Business Continuity). Почему опытные коллеги настаивают на трех серверах?

Рассмотрим сценарий катастрофы на кластере из двух серверов (Уровень отказоустойчивости = 1):

1. Система работает штатно. Есть Сервер А и Сервер Б. Отказоустойчивость активна.
2. Сервер А выходит из строя (сгорает блок питания, падает ОС и т.д.).
3. Кластер отрабатывает штатно: все сеансы переезжают на Сервер Б. Пользователи продолжают работать.
4. Внимание, вопрос: какой уровень отказоустойчивости у нас остался в этот момент?

Ответ неутешительный: уровень отказоустойчивости стал равен нулю. У нас остался всего один живой сервер (Сервер Б). Кластер превратился в обычный одиночный сервер ("single point of failure"). Если в этот момент (пока мы чиним Сервер А) произойдет сбой на Сервере Б — вся работа встанет.

Теперь рассмотрим сценарий с тремя серверами (Уровень отказоустойчивости = 1):

1. Система работает штатно. Есть Серверы А, Б и В.
2. Сервер А выходит из строя.
3. Нагрузка перераспределяется между Б и В.
4. Самое главное: между серверами Б и В продолжает работать репликация сеансовых данных.

В этом случае, даже после аварии одного узла, наш кластер сохраняет статус отказоустойчивого (Уровень = 1). Мы можем спокойно, без паники ремонтировать первый сервер, зная, что у нас все еще есть запас прочности. Именно поэтому для построения надежной системы ("High Availability") рекомендуется схема из трех узлов.

Технические детали: Менеджер кластера (rmngr)

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

1. rphost — рабочий процесс, который выполняет код 1С.
2. rmngr — менеджер кластера, который управляет всем кластером.

Отказоустойчивость кластера критически зависит от отказоустойчивости процесса rmngr. Если у вас настроен уровень отказоустойчивости, но сервис менеджера кластера назначен только на один "Центральный" сервер, то при падении этого сервера кластер развалится, сколько бы рабочих серверов rphost у вас ни было на других машинах.

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

Давайте представим, как это выглядит в настройках:

У нас есть три сервера: Server1, Server2, Server3. На каждом из них мы должны разрешить запуск сервиса лицензирования и сервиса сеансовых данных. Если мы жестко привяжем rmngr только к Server1, то наличие Server2 и Server3 не спасет нас от падения именно Server1.

Производительность и синхронизация

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

При уровне отказоустойчивости «1» каждое изменение сеансовых данных записывается дважды: на активный сервер и на резервный. Это создает дополнительный сетевой трафик и нагрузку на процессоры (сериализация данных).

Давайте проанализируем разницу в нагрузке:

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

Разделение ответственности: Кластер 1С и СУБД

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

Кластер 1С (на уровне платформы) спасает сеанс пользователя.
Его задача — сделать так, чтобы окно программы не закрылось, переменные в оперативной памяти сервера не потерялись, а временные таблицы сохранились.

Кластер СУБД (MS SQL AlwaysOn или PostgreSQL Patroni) спасает данные.
Его задача — гарантировать, что транзакция, которая была закоммичена, физически записана на диск и не пропадет при сгорании сервера БД.

Для полноценной защиты инфраструктуры (Enterprise уровня) мы рекомендуем следующую схему:

1. Кластер серверов 1С: минимум 2 сервера (лучше 3) для обеспечения непрерывности сеансов.
2. Кластер СУБД: отдельный отказоустойчивый кластер (минимум 2 узла) для сохранности данных.

Итоговый ответ на вопрос

Подведем итог нашему исследованию. Ответ зависит от того, какую задачу вы решаете.

Ситуация 1: Вы сдаете экзамен "1С:Эксперт".
Правильный ответ: Вам нужно 2 сервера. Обоснование: Формула N + 1. Для уровня отказоустойчивости 1 достаточно одного дополнительного сервера.

Ситуация 2: Вы проектируете надежную систему для бизнеса (Production).
Правильный ответ: Вам нужно 3 сервера. Обоснование: Чтобы при выходе из строя одного сервера система не переходила в аварийный режим без защиты, а сохраняла уровень отказоустойчивости N=1 на оставшихся двух узлах. Это дает вам время на ремонт и замену оборудования без риска полной остановки бизнеса при повторном сбое.

Резюме действий при настройке:

1. Устанавливаем уровень отказоустойчивости кластера в значение 1.
2. Добавляем в кластер 3 рабочих сервера.
3. Настраиваем требования назначения функциональности так, чтобы сервис Центральный сервер и Сервис сеансовых данных могли функционировать на любом из узлов.
4. Проверяем, что список администраторов кластера актуален (чтобы не потерять доступ при смене активного менеджера).

Следуя этим рекомендациям, вы получите систему, которая не просто "соответствует документации", но и реально готова к нештатным ситуациям.