Отказоустойчивый кластер 1С 8.3: настройка failover и резервирования

Один сервер 1С — единая точка отказа. Сбой ragent, обновление ОС, перезагрузка по питанию — и 100+ пользователей не работают. Отказоустойчивый кластер 1С 8.3 решает эту проблему: несколько серверов приложений, резервирование СУБД и автоматический failover без участия администратора.

В этой статье: архитектура отказоустойчивого кластера, настройка резервирования ragent/rmngr/rphost, session fault tolerance, Always On для SQL Server, Patroni для PostgreSQL, балансировка нагрузки и мониторинг доступности. Результат — кластер, который переживает отказ любого одного сервера без потери пользовательских сеансов.

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

Зачем нужен отказоустойчивый кластер 1С

Обычный кластер 1С из двух серверов разделяет нагрузку: сервер приложений отдельно, СУБД отдельно. Но каждый компонент всё ещё в единственном экземпляре. Упал ragent — новые сеансы не создаются. Упал SQL Server — все пользователи теряют соединение.

Отказоустойчивый кластер добавляет резервирование на каждом уровне. Два или три сервера приложений 1С, каждый с ragent и rmngr. СУБД в режиме Active-Standby (Always On или Patroni). При отказе одного узла — нагрузка автоматически переходит на оставшиеся.

Три сценария, когда это оправдано:

• Непрерывность бизнеса. Бухгалтерия, ERP, управление торговлей — остановка 1С на час в рабочее время обходится дороже, чем второй сервер
• Обслуживание без простоев. Обновление платформы 1С, патчи ОС, замена дисков — всё делается поочерёдно на каждом узле. Пользователи не замечают
• 100+ пользователей. При таком числе сеансов даже кратковременный сбой критичен. Переподключение 100 клиентов одновременно — лавина нагрузки на сервер

Архитектура отказоустойчивого кластера 1С 8.3

Отказоустойчивый кластер состоит из трёх уровней, каждый резервируется независимо.

Как это работает. Клиент 1С подключается к любому из серверов приложений. Менеджер кластера rmngr распределяет сеанс на наименее загруженный rphost. Если один сервер приложений падает — rmngr на другом узле подхватывает управление кластером и перенаправляет сеансы на оставшиеся rphost.

СУБД работает в режиме Active-Standby. Основной узел обрабатывает все запросы. При отказе — Standby автоматически становится Primary (failover за 15-60 секунд). Серверы приложений 1С переподключаются к новому Primary автоматически.

Минимальная конфигурация: 3 сервера

Для полной отказоустойчивости СУБД нужен четвёртый сервер — Standby-реплика. В минимальном варианте СУБД остаётся единой точкой отказа, но серверы приложений уже зарезервированы.

Рекомендуемая конфигурация: 4 сервера

При этой схеме отказ любого одного сервера не останавливает работу. Два сервера приложений — кластер 1С продолжает работать на оставшемся. Два сервера СУБД — Always On или Patroni выполняет автоматический failover.

Что потребуется

Важно про лицензии SQL Server. Always On Availability Groups требует редакцию Enterprise на каждом узле СУБД. Это существенная статья расходов. Для PostgreSQL с Patroni лицензионных затрат нет — только стоимость серверов. Подробнее о выборе — в нашем сравнении SQL Server и PostgreSQL для 1С.

Шаг 1. Резервирование серверов приложений 1С

Кластер серверов 1С поддерживает несколько рабочих серверов из коробки. Механизм встроен в платформу — не нужны сторонние решения для балансировки уровня приложений.

Установка 1С на оба сервера

Установите 1С:Предприятие 8.3 в режиме «Сервер» на оба сервера приложений. Версия платформы должна быть одинаковой на обоих узлах — разница даже в минорной версии вызовет ошибку «различаются версии клиента и сервера».

Подробная процедура установки — в статьях по установке на Windows и установке на Linux.

После установки на обоих серверах ragent запускается и создаёт кластер по умолчанию. Проверьте на каждом узле:

# На сервере 1
rac cluster list --server=server1:1540

# На сервере 2
rac cluster list --server=server2:1540

Добавление второго сервера в кластер

На сервере 2 удалите кластер по умолчанию (он нам не нужен — будем присоединяться к кластеру сервера 1). Откройте консоль администрирования серверов 1С или используйте rac.

Через консоль администрирования. Подключитесь к серверу 1 (порт 1540). Раскройте кластер → «Рабочие серверы». Правый клик → «Создать» → «Рабочий сервер». Укажите имя сервера 2 и порт 1540. После добавления сервер 2 появится в списке рабочих серверов. Подробнее о работе с консолью — в статье консоль кластера серверов 1С.

Через rac:

# Получить UUID кластера
rac cluster list --server=server1:1540

# Добавить server2 как рабочий сервер
rac server --cluster=<cluster-uuid> insert \
  --server=server1:1540 \
  --agent-host=server2 \
  --agent-port=1540 \
  --port-range=1560:1591 \
  --name="server2" \
  --using=normal

После добавления rmngr на сервере 1 начнёт запускать рабочие процессы rphost на сервере 2. Нагрузка распределяется между rphost обоих серверов автоматически.

Резервирование менеджера кластера (rmngr)

По умолчанию rmngr работает только на одном сервере. Если этот сервер падает — весь кластер останавливается, даже если второй сервер жив. Нужно включить резервирование rmngr.

В свойствах кластера установите параметр «Уровень отказоустойчивости» (Fault Tolerance Level). Значение 1 означает: кластер продолжает работать при отказе одного сервера. Для этого rmngr запускается на двух серверах — основной и резервный.

# Установить уровень отказоустойчивости = 1
rac cluster --cluster=<cluster-uuid> update \
  --server=server1:1540 \
  --fault-tolerance-level=1

После применения rmngr запустится на обоих серверах. Один — основной (Central), второй — резервный (Backup). При отказе основного — резервный подхватывает управление за 10-30 секунд.

Проверка:

# Список менеджеров кластера — должно быть два
rac manager --cluster=<cluster-uuid> list --server=server1:1540

# Ожидаемый результат:
# manager: uuid1 host=server1 pid=... main-manager=true
# manager: uuid2 host=server2 pid=... main-manager=false

Шаг 2. Настройка Session Fault Tolerance

Резервирование серверов — половина дела. Без Session Fault Tolerance при отказе сервера пользователи теряют сеансы и должны переподключаться вручную. С включённым SFT — сеанс автоматически мигрирует на другой rphost.

Как работает Session Fault Tolerance

Платформа 1С периодически сохраняет состояние сеанса (session data) в общее хранилище кластера. При отказе rphost — другой рабочий процесс на другом сервере восстанавливает сеанс из сохранённого состояния. Пользователь видит кратковременную задержку (5-30 секунд), но не теряет данные.

Ограничения. SFT не спасает при ошибках в коде конфигурации (фоновые задания, длительные операции). Если rphost упал во время проведения документа — транзакция откатится. Пользователю нужно будет повторить операцию. Но сеанс и контекст сохранятся.

Включение SFT

Session Fault Tolerance включается в свойствах информационной базы в кластере.

# Получить UUID информационной базы
rac infobase --cluster=<cluster-uuid> summary list --server=server1:1540

# Включить SFT для конкретной ИБ
rac infobase --cluster=<cluster-uuid> update \
  --server=server1:1540 \
  --infobase=<ib-uuid> \
  --sessions-fault-tolerance=on

Через консоль администрирования: правый клик на информационной базе → Свойства → установите флаг «Отказоустойчивость сеансов».

Что учесть. SFT потребляет дополнительную RAM и сеть — состояние сеансов реплицируется между серверами. Для 100 пользователей с тяжёлыми конфигурациями (ERP, КА) это 2-4 ГБ дополнительной RAM на каждом узле. Заложите этот запас при планировании ресурсов.

Шаг 3. Отказоустойчивость СУБД: Always On (SQL Server)

Кластер серверов 1С зарезервирован. Следующий уровень — СУБД. Для SQL Server стандартное решение — Always On Availability Groups.

Что такое Always On Availability Groups

Always On AG — механизм высокой доступности SQL Server Enterprise. Основной узел (Primary Replica) обрабатывает все запросы и синхронно реплицирует изменения на вторичный узел (Secondary Replica). При отказе Primary — Secondary автоматически становится Primary за 15-30 секунд.

Клиенты (серверы приложений 1С) подключаются через Listener — виртуальный сетевой адрес. После failover Listener автоматически указывает на новый Primary. Серверам 1С не нужно менять строку подключения.

Требования для Always On

• SQL Server Enterprise на обоих узлах (Standard поддерживает Basic AG — только одна БД, нет читаемой реплики)
• Windows Server Failover Cluster (WSFC) — Always On работает поверх него
• Active Directory — узлы WSFC должны быть в домене
• Общий диск или файловый свидетель — для кворума WSFC
• Одинаковые пути к файлам БД на обоих узлах

Порядок настройки Always On

1. Настройте WSFC. На обоих серверах СУБД установите роль «Отказоустойчивая кластеризация» (Failover Clustering). Создайте кластер через Failover Cluster Manager. Добавьте оба узла. Настройте кворум — рекомендуем File Share Witness на третьем сервере (можно на одном из серверов приложений 1С).

2. Включите Always On в SQL Server. SQL Server Configuration Manager → свойства службы SQL Server → вкладка «Always On High Availability» → включите «Enable Always On Availability Groups». Перезапустите SQL Server на обоих узлах.

3. Создайте Availability Group. В SSMS на Primary-узле: правый клик на «Always On High Availability» → «New Availability Group Wizard». Добавьте базы данных 1С. Укажите Secondary-узел. Режим репликации — Synchronous Commit (для нулевой потери данных). Режим failover — Automatic.

4. Создайте Listener. В мастере создания AG укажите имя Listener (например, sql-1c-listener) и виртуальный IP-адрес. Listener — это адрес, который указывается в настройках ИБ кластера 1С вместо имени конкретного сервера СУБД.

5. Настройте подключение 1С. В параметрах информационной базы кластера 1С замените имя сервера СУБД на имя Listener. При failover 1С автоматически переподключится к новому Primary через Listener.

# Обновить подключение ИБ на Listener
rac infobase --cluster=<cluster-uuid> update \
  --server=server1:1540 \
  --infobase=<ib-uuid> \
  --db-server="sql-1c-listener"

Шаг 4. Отказоустойчивость СУБД: Patroni (PostgreSQL)

Если вместо SQL Server используете PostgreSQL — для автоматического failover нужен Patroni. Это решение с открытым исходным кодом, стандарт отрасли для HA PostgreSQL.

Архитектура Patroni

Patroni управляет кластером PostgreSQL через распределённое хранилище конфигурации (etcd, Consul или ZooKeeper). На каждом узле СУБД работает агент Patroni, который следит за состоянием PostgreSQL и выполняет failover при необходимости.

Порядок настройки Patroni

1. Установите etcd. Три узла etcd для кворума — можно совместить с серверами приложений 1С, если ресурсы позволяют. etcd потребляет минимум CPU и RAM.

# Ubuntu/Debian
apt install etcd

# Конфигурация /etc/etcd/etcd.conf.yaml
name: etcd1
data-dir: /var/lib/etcd
initial-cluster: etcd1=http://server1:2380,etcd2=http://server2:2380,etcd3=http://server3:2380
listen-client-urls: http://0.0.0.0:2379
advertise-client-urls: http://server1:2379

2. Установите PostgreSQL и Patroni на оба узла СУБД.

# Установка
apt install postgresql-14 patroni

# Конфигурация /etc/patroni/config.yml (пример для узла 1)
scope: pg-1c-cluster
name: pg-node1
restapi:
  listen: 0.0.0.0:8008
  connect_address: server3:8008
etcd:
  hosts: server1:2379,server2:2379,server3:2379
bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
  postgresql:
    use_pg_rewind: true
    parameters:
      max_connections: 200
      shared_buffers: 32GB
      effective_cache_size: 96GB
postgresql:
  listen: 0.0.0.0:5432
  connect_address: server3:5432
  data_dir: /var/lib/postgresql/14/main
  authentication:
    replication:
      username: replicator
      password: "надёжный_пароль"
    superuser:
      username: postgres
      password: "надёжный_пароль"

3. Настройте HAProxy для маршрутизации. HAProxy направляет подключения от серверов 1С к текущему Leader PostgreSQL. При failover Patroni обновляет статус узлов, HAProxy автоматически переключается.

# /etc/haproxy/haproxy.cfg
frontend pg_frontend
  bind *:5433
  default_backend pg_backend

backend pg_backend
  option httpchk GET /primary
  http-check expect status 200
  server pg-node1 server3:5432 check port 8008
  server pg-node2 server4:5432 check port 8008

4. Настройте подключение 1С. В параметрах ИБ кластера 1С укажите адрес HAProxy и порт 5433 (или тот, что настроили). При failover HAProxy автоматически перенаправит подключения на нового Leader.

Преимущество Patroni перед Always On: не требует лицензий (PostgreSQL и Patroni бесплатны), работает на Linux, проще в автоматизации. Недостаток: сложнее первоначальная настройка, нужен опыт работы с Linux.

Шаг 5. Балансировка нагрузки и подключение клиентов

Два сервера приложений настроены, СУБД зарезервирована. Остаётся вопрос: как клиенты 1С подключаются к кластеру? Три варианта.

Вариант 1: Прямое подключение к одному серверу

Клиенты 1С указывают в строке подключения адрес сервера 1 (Primary). rmngr сам распределяет rphost между серверами 1 и 2. При отказе сервера 1 — клиентам нужно вручную переключиться на сервер 2.

Плюс: простота. Минус: ручное переключение при отказе Primary.

Вариант 2: DNS Round Robin

Создайте DNS-запись 1c-cluster.company.local, указывающую на оба IP серверов приложений. Клиенты подключаются по DNS-имени. При отказе одного сервера — удалите его A-запись из DNS.

Плюс: не нужен дополнительный софт. Минус: DNS-кеш на клиентах (TTL), переключение не мгновенное.

Вариант 3: Keepalived (виртуальный IP)

Keepalived создаёт виртуальный IP-адрес (VIP), который всегда указывает на активный сервер. При отказе Primary — VIP переезжает на Secondary за 2-3 секунды. Клиенты подключаются к VIP и не замечают переключения.

# /etc/keepalived/keepalived.conf на сервере 1 (MASTER)
vrrp_instance VI_1C {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
}

# На сервере 2 (BACKUP) — то же, но state BACKUP и priority 90

Рекомендация: для Windows-среды используйте DNS Round Robin с минимальным TTL. Для Linux — Keepalived. Это самые простые и надёжные варианты.

Шаг 6. Мониторинг доступности кластера

Отказоустойчивый кластер без мониторинга — иллюзия надёжности. Вы узнаете о проблеме только когда позвонят пользователи. К этому моменту может быть уже поздно — оба узла отказали.

Что мониторить

Автоматическая проверка через rac

Простой скрипт мониторинга для cron или Планировщика задач. Проверяет состояние кластера и отправляет алерт при проблемах.

#!/bin/bash
# Проверка кластера 1С — запуск каждые 60 секунд через cron
CLUSTER_UUID="ваш-uuid"
SERVER="server1:1540"

# Проверка менеджеров кластера
MANAGERS=$(rac manager --cluster=$CLUSTER_UUID list --server=$SERVER | grep -c "manager")
if [ "$MANAGERS" -lt 2 ]; then
  echo "ALERT: Only $MANAGERS manager(s) in cluster" | mail -s "1C Cluster Alert" admin@company.ru
fi

# Проверка рабочих процессов
PROCESSES=$(rac process --cluster=$CLUSTER_UUID list --server=$SERVER | grep -c "running")
if [ "$PROCESSES" -lt 2 ]; then
  echo "ALERT: Only $PROCESSES running rphost(s)" | mail -s "1C Cluster Alert" admin@company.ru
fi

Для промышленной эксплуатации рекомендуем Zabbix или Prometheus с Grafana. Настройте дашборд с метриками всех узлов и алерты в Telegram или email. Так вы узнаете о проблеме до того, как позвонят пользователи.

Пошаговая инструкция: настройка отказоустойчивого кластера 1С

Типичные ошибки при настройке отказоустойчивого кластера

Разные версии платформы 1С на узлах

Серверы в кластере обмениваются данными по внутреннему протоколу. Если версии отличаются хотя бы в патче (8.3.23.2040 vs 8.3.23.2100) — рабочие процессы не смогут взаимодействовать. Результат: ошибки «различаются версии клиента и сервера», сеансы не мигрируют. Обновляйте оба узла одновременно.

Уровень отказоустойчивости = 0

Добавили второй сервер, но не установили Fault Tolerance Level. rmngr работает только на одном узле. Второй сервер запускает rphost, но при падении первого сервера — кластер останавливается. Обязательно установите уровень отказоустойчивости в соответствии с числом резервных узлов.

Always On на SQL Server Standard

SQL Server Standard поддерживает Basic Availability Groups — но с ограничениями: одна база данных на группу, нет читаемой Secondary реплики. Для 1С, где часто 5-10 информационных баз — это 5-10 отдельных AG. Проще и надёжнее Enterprise или PostgreSQL с Patroni.

Нет тестирования failover

Настроили кластер — и забыли. Через полгода реальный failover: оказывается, Listener не работает, Patroni не может промотить реплику, Session Fault Tolerance выключен на половине баз. Проводите тестовый failover каждый месяц. Остановите ragent, переключите СУБД — убедитесь, что всё работает.

Серверы СУБД в разных дата-центрах

Идея «один сервер в офисе, второй в облаке» выглядит надёжно, но убивает производительность. Синхронная репликация при задержке 5+ мс замедляет каждую транзакцию. 1С выполняет десятки SQL-запросов на одну операцию пользователя. Для HA-кластера — все узлы в одном ЦОД с задержкой менее 1 мс.

Вопросы и ответы

Итог

Отказоустойчивый кластер 1С 8.3 — это три уровня резервирования: серверы приложений (ragent, rmngr, rphost на нескольких узлах), СУБД (Always On для SQL Server или Patroni для PostgreSQL) и единая точка подключения для клиентов (VIP или DNS).

Ключевые моменты: установите одинаковую версию 1С на все узлы, включите Fault Tolerance Level и Session Fault Tolerance, настройте автоматический failover СУБД через Listener или HAProxy. Обязательно мониторьте все компоненты и тестируйте failover ежемесячно.

Для базовой настройки кластера читайте статью по настройке кластера серверов 1С. Если нужна двухсерверная конфигурация без полного HA — кластер из двух серверов. Описание методологии тестирования — на отдельной странице.

Нужна помощь с проектированием и настройкой отказоустойчивого кластера 1С? Оставьте заявку — подберём архитектуру под ваше количество пользователей и требования к доступности.