Когда от 1С зависит работа всего бизнеса — отгрузки на складе, кассы в рознице, выплата зарплат — простой даже в полчаса превращается в десятки и сотни тысяч рублей убытка. Кластер серверов 1С нужен именно для того, чтобы такого простоя не случилось: даже если один из узлов выйдет из строя, пользователи продолжают работать на втором, и зачастую этого переключения не замечают.
Дальше разберем, что такое отказоустойчивость 1С на практике, какие бывают уровни, как устроена архитектура из rphost, rmngr и ragent, как пошагово настраивается кластер серверов 1С 8.3 и какие требования он предъявляет к СУБД и сети.
Зачем нужен кластер серверов 1С: отказоустойчивость и высокая доступность
В обычной схеме «один сервер 1С плюс одна СУБД» все держится на этом единственном сервере. Если на нем выйдет из строя диск, сгорит блок питания или просто зависнет операционная система, бизнес встает целиком: бухгалтерия не может провести документ, склад не отгружает товар, кассы переключаются в офлайн. Кластер 1С устраняет этот сценарий: рабочие процессы поднимаются на нескольких физических серверах одновременно, и при отказе одного из них пользователи автоматически переезжают на соседний.
Высокая доступность (то, что в индустрии называют HA) для 1С означает не «работает всегда без перерывов», а «время простоя укладывается в заранее заявленные минуты в год». Под кластер обычно идут крупные внедрения от 50–100 пользователей, торговые сети с активной розницей, банки и любой бизнес, где остановка учета означает прямые убытки. Для файловой базы на пять человек кластер не нужен — там цена внедрения и обслуживания не окупится.
Уровни отказоустойчивости 0 и 1: какой выбирать
Платформа 1С:Предприятие предлагает два уровня отказоустойчивости. Нулевой — это базовый сценарий, в котором при падении узла сеансы пользователей пересоздаются на резервном сервере, но людям приходится заново открыть базу и продолжить с того места, где они остановились.
Время переключения — от пяти до тридцати секунд. Первый уровень добавляет резервирование менеджера кластера (служба rmngr) и обеспечивает почти бесшумный failover: миграция сеансов идет в фоне, и пользователь чаще всего просто видит короткое подвисание интерфейса.
На практике уровень 0 закрывает потребности большинства средних компаний, где допустима пауза в полминуты и не критично, что часть несохраненных действий придется повторить. Уровень 1 нужен там, где простой даже на полминуты обходится дорого: розничные сети с кассовым оборудованием, банковский фронт, операторы связи. За первый уровень платят дополнительной памятью и процессорным временем на репликацию сеансов между узлами и третьим сервером для резервного rmngr.
Архитектура кластера 1С 8.3: rphost, rmngr, ragent
Сервер 1С:Предприятия в кластере 8.3 строится на трех ключевых службах. Агент сервера (ragent) — это «портье» узла: он принимает соединения и запускает остальные процессы. Менеджер кластера (rmngr) — «диспетчер»: он раздает сеансы по узлам, ведет учет блокировок и отвечает за журнал регистрации. Рабочие процессы (rphost) — это «исполнители», которые непосредственно держат сеансы пользователей и выполняют их код.
Один центральный сервер в кластере отвечает за роль главного rmngr и хранит список информационных баз. Остальные серверы в кластере — это рабочие серверы: они принимают сеансы пользователей и выполняют рабочие процессы rphost.
На уровне отказоустойчивости 1 центральный rmngr дублируется на втором сервере, чтобы при отказе главного узла кластер не остался без диспетчера. Сама СУБД (MS SQL Server или PostgreSQL) живет отдельно и резервируется собственными средствами — кластер серверов 1С базу данных не реплицирует.
Пошаговая настройка кластера серверов 1С через консоль
Настройка начинается с подготовки минимум двух одинаковых систем. На обоих ставится одна и та же версия операционной системы, одна и та же сборка платформы 1С:Предприятие (от 8.3.20 и выше) и обязательно настраивается синхронизация времени по протоколу NTP — расхождение часов в кластере приводит к проблемам с блокировками и репликацией сеансов.
Дальше на каждой системе устанавливается агент сервера и регистрируется как служба. На первом узле через консоль создается сама вычислительная группа, добавляется второй сервер в качестве рабочего узла, выставляется уровень отказоустойчивости и подключается информационная база.
После этого нужно обязательно протестировать failover: остановить ragent на одном из серверов и проверить, что пользователи продолжают работу на втором. Тест переключения — единственный способ убедиться, что схема собрана правильно. Под рабочую нагрузку имеет смысл сразу заложить сервер для 1С с запасом по памяти и процессору, чтобы при падении одного узла второй вытянул всю нагрузку.
Резервный сервер и сценарии failover
В сценарии failover платформа делает несколько вещей одновременно. Менеджер кластера фиксирует, что один из узлов перестал отвечать, и переносит активные сеансы на оставшиеся серверы — это и есть миграция сеансов. На уровне 0 каждый сеанс пересоздается заново, на уровне 1 — продолжается с того же места благодаря репликации. Параллельно с этим клиентское приложение получает короткую паузу и подключается к новому узлу автоматически, без участия пользователя.
Важно понимать, что кластер систем 1С резервирует только сами процессы платформы. СУБД, сеть, дисковое хранилище и отказоустойчивый сервер для самой базы данных нужно резервировать отдельно: для MS SQL это AlwaysOn Availability Groups, для PostgreSQL — потоковая репликация с Patroni и кворумом etcd.
Без этого при отказе сервера базы данных весь кластер 1С встанет, как бы хорошо ни был настроен сам failover. Регулярные учения по переключению (раз в квартал) и контроль показателей RTO и RPO — обязательная гигиена.
Требования к серверам, СУБД и сети
Для рабочего сервера разумный минимум — 16 ядер процессора и 64 гигабайта оперативной памяти, для центрального — 8 ядер и 32 гигабайта. Диски — SSD или NVMe; на жестких дисках производительность кластера деградирует на пиковой нагрузке. Под СУБД обычно ставят отдельный сервер баз данных с собственным резервированием. Лицензирование требует отдельной серверной лицензии 1С на каждый узел кластера и общей пачки клиентских лицензий на пользователей.
Сеть — отдельная тема. Между узлами кластера задержка должна быть меньше одной миллисекунды, поэтому размещать их в разных дата-центрах разрешено только при наличии прямого темного оптоволокна. Минимум — гигабитный канал в выделенном виртуальном сегменте, для нагруженных кластеров рекомендуется 10 Гбит.
Используются порты 1540 (агент), 1541 (центральный сервер) и диапазон 1560–1591 для рабочих процессов. Платформа поддерживает Windows Server 2019 и 2022, RHEL-семейство, Astra Linux Special Edition и ALT Сервер 10–11. Совместимые СУБД — MS SQL Server 2019 и 2022, PostgreSQL 14–16 и Postgres Pro 14–16. Для крупных кластеров балансировка нагрузки иногда дополняется HAProxy или аппаратным балансировщиком, но для большинства внедрений хватает встроенных средств платформы.
Сравнительная таблица: уровни отказоустойчивости и требования
Чтобы было проще сравнить два варианта, основные параметры собрали в одной таблице.
Из таблицы видно: уровень 0 — недорогой минимум для большинства средних компаний, уровень 1 — выбор для тех, кому критичны секунды простоя. Для проверки гипотез по нагрузке часто разворачивают пилотный кластер из 3 узлов и обкатывают на нем сценарии переключения, прежде чем масштабироваться.
Часто задаваемые вопросы
Чем кластер 1С отличается от кластера Windows Failover?
Это разные уровни решения. Windows Failover управляет физическими и виртуальными ресурсами на уровне операционной системы, а 1С — это логическая группа процессов самой платформы. На один кластер Windows Failover могут опираться несколько кластеров 1С, но заменить один другим нельзя.
Сколько минимум систем нужно для кластера 1С?
Для нулевого уровня — два сервера. Для первого, с резервированием центрального rmngr, — три. На двух серверах первый уровень собрать тоже технически можно, но смысл резервирования теряется: при падении одного узла кластер останется без полноценного диспетчера.
Можно ли в кластер объединять системы с разной мощностью?
Можно, но платформа будет распределять нагрузку с учетом весов, и слабый узел получит меньше сеансов. На практике лучше держать узлы одинаковыми — это упрощает обслуживание и предсказуемый split-brain не возникает при асимметричных ресурсах.
Скользящим обновлением: сначала выводим из кластера один узел, обновляем на нем платформу, возвращаем обратно, проверяем работу — потом то же самое со вторым. Версии платформы на узлах должны совпадать, поэтому окно полного обновления все равно занимает несколько минут.
Что делать, если узел кластера потерял связь с СУБД?
Этот узел перестает обслуживать сеансы и помечается в кластере как недоступный. Платформа переносит сеансы на оставшиеся серверы. Восстановление автоматическое: как только связь возвращается, узел снова включается в работу и начинает принимать новые сеансы.
Заключение
Кластер серверов 1С — это не способ ускорить базу, а способ застраховать бизнес от простоев. Для большинства средних компаний достаточно нулевого уровня отказоустойчивости и двух одинаковых рабочих серверов. Розничным сетям, банкам и любым внедрениям, где простой стоит дорого, имеет смысл сразу разворачивать первый уровень с резервированным менеджером кластера и трехсерверной конфигурацией.
Конкретный следующий шаг — провести аудит текущей нагрузки, выбрать уровень отказоустойчивости под свои показатели простоя и собрать архитектуру: серверы, сеть, СУБД и резервирование на каждом из этих слоев.
