Когда одного сервера 1С мало: что решает кластер и как его спланировать

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

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

Из чего состоит кластер 1С и что делает центральный сервер

Клиент-серверная 1С работает в три звена: клиент → кластер серверов 1С → СУБД (MS SQL Server, PostgreSQL и др.). Кластер не хранит данные базы, он исполняет код конфигурации и держит сеансы. Данные лежат в СУБД.

Внутри кластера работают три типа процессов:

• 🛰 Агент сервера (ragent) — принимает первое обращение клиента и консоли администрирования. Порт по умолчанию — 1540.
• 🧭 Менеджер кластера (rmngr) — ведёт реестр кластера, сеансы, блокировки, распределение соединений. Порт по умолчанию — 1541.
• ⚙️ Рабочие процессы (rphost) — исполняют код конфигурации, обращаются к СУБД. Работают на портах из диапазона, заданного в свойствах рабочего сервера (по умолчанию 1560–1591).

Путь подключения клиента: агент (1540) → менеджер кластера (1541) → рабочий процесс. Консоль администрирования тоже идёт через агент.

Центральный и рабочий сервер

Рабочий сервер — любой компьютер кластера, на котором запускаются рабочие процессы. Центральный сервер — рабочий сервер, который дополнительно хранит реестр кластера: список баз, настройки, администраторов. Реестр лежит в каталоге srvinfo (в подпапке reg_1541 для кластера на стандартном порту).

В 8.3 центральных серверов может быть несколько — это основа отказоустойчивости. Признак «Центральный сервер» ставится в свойствах рабочего сервера в консоли администрирования.

Масштабирование кластера серверов 1С и распределение нагрузки

Производительность одного сервера упирается в ядра процессора и память. Кластер решает это горизонтально: добавляете рабочий сервер — получаете ещё рабочие процессы и ещё память.

Как кластер раскладывает соединения

Менеджер кластера постоянно замеряет доступную производительность каждого рабочего процесса (видна в консоли в списке процессов). Новое соединение получает процесс с лучшим показателем. Медленный или перегруженный процесс получает меньше новых сеансов.

Режим распределения задаётся в свойствах кластера:

Что настраивают в свойствах рабочего сервера

• 📦 Количество ИБ на процесс и количество соединений на процесс — сколько баз и сеансов один rphost обслуживает до запуска следующего.
• 🧠 Максимальный объём памяти рабочих процессов — общий потолок для всех процессов этого сервера.
• 🚦 Безопасный расход памяти за один вызов — защита от «тяжёлого» отчёта, который съедает всю память и роняет процесс вместе с чужими сеансами.
• 🔌 Диапазон IP-портов для рабочих процессов.

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

Это правила, какой сервер чем занимается. Типовые приёмы:

1. Вынести фоновые и регламентные задания на отдельный сервер, чтобы ночной расчёт себестоимости или обмен не тормозили пользователей.
2. Закрепить конкретную тяжёлую базу за мощным сервером, а мелкие базы — за остальными.
3. Запретить клиентские соединения на сервере, который держит сервисы кластера.

Требования задаются в консоли на уровне рабочего сервера. Учтите: расширенные возможности управления кластером, включая назначение функциональности, поставщик относит к редакции КОРП — сверьте состав редакции до покупки лицензий.

Отказоустойчивость: что происходит, когда сервер 1С падает

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

В консоли задаётся уровень отказоустойчивости — сколько рабочих серверов может выйти из строя одновременно без остановки кластера. Уровень 1 означает: переживём отказ одного сервера. Для этого нужны минимум два центральных сервера; для уровня 2 — три.

Что увидит пользователь

• 🔁 Сеанс, который работал на отказавшем сервере, переподключается к другому рабочему процессу. Тонкий и веб-клиент обычно показывают окно восстановления соединения.
• ↩️ Транзакция, которая выполнялась в момент сбоя, откатывается. Документ, который проводился, придётся провести повторно.
• ⏳ Фоновое задание, прерванное сбоем, нужно перезапустить; регламентные задания продолжат работу по расписанию.

Чего кластер не спасает

Кластер 1С не защищает данные. Если отказала СУБД или испортилась база, все серверы 1С останутся без данных. Отказоустойчивость нужна на всех трёх звеньях:

Репликация баз данных и распределённые вычисления: кто за что отвечает

Здесь много путаницы, потому что три разных механизма называют похожими словами.

Кластер серверов 1С ≠ репликация базы

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

• 🗄 MS SQL Server — группы доступности Always On, зеркалирование в старых версиях.
• 🐘 PostgreSQL — потоковая репликация на резервный сервер, переключение через средства вроде Patroni.

Для 1С реплика — это резерв на случай отказа. Писать в неё 1С не умеет, все изменения идут в основной экземпляр.

Распределённая информационная база (РИБ)

РИБ — механизм обмена данными между разными базами, например центральным офисом и филиалами. Он работает через планы обмена и пакеты сообщений, не в реальном времени. Кластер серверов для РИБ не требуется, и наоборот — кластер не делает базу распределённой.

Распределённые вычисления внутри кластера

Распараллеливание в 1С идёт через фоновые задания. Конфигурации на БСП разбивают тяжёлые операции (обновление информационной базы, некоторые обработки) на несколько фоновых заданий, а кластер раскидывает их по свободным рабочим процессам — в том числе на разных серверах. Чем больше серверов и процессов, тем больше заданий выполняется одновременно.

Требования к инфраструктуре и сети кластера 1С

Кластер чувствителен к сети сильнее, чем к процессору. Основные требования:

1. Одна версия платформы на всех серверах кластера, вплоть до номера сборки. Сервер с другой версией к кластеру не подключится.
2. Быстрая сеть между серверами 1С и СУБД: минимум 1 Гбит/с, для нагруженных систем — 10 Гбит/с, задержка доли миллисекунды. Серверы 1С и СУБД держат в одном сегменте сети, не через VPN или удалённую площадку.
3. Разрешение имён: каждый сервер должен находить остальные по имени компьютера — через DNS или файл hosts. Кластер обменивается именами, не IP-адресами.
4. Синхронное время на всех узлах через общий NTP-источник.
5. Открытые порты в брандмауэре между серверами и от клиентов.

Порты, которые проверяют первыми:

Лицензии

Каждому рабочему серверу кластера, на котором запускаются рабочие процессы, нужна своя серверная лицензия. Клиентские лицензии могут выдаваться с любого сервера кластера. Ориентировочно лицензия на сервер обычной редакции стоит порядка 80–100 тыс. руб., КОРП — в несколько раз дороже; точную цену уточняйте у партнёра.

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

Если запущен сервер администрирования ras, состав кластера удобно смотреть утилитой rac из каталога bin платформы:

rac cluster list
rac server list --cluster=<uuid-кластера>
rac process list --cluster=<uuid-кластера>

Первая команда выдаёт идентификатор кластера, вторая — список рабочих серверов, третья — рабочие процессы с их нагрузкой. Остальные параметры смотрите в rac help.

Как внедряют кластер: сценарии и ошибки на практике

Типовой порядок расширения

1. Снимите замеры на текущем сервере в часы пик: загрузка процессора, память rphost, число сеансов, время отклика ключевых операций.
2. Убедитесь, что узкое место — сервер 1С, а не СУБД или диск. Если тормозит СУБД, второй сервер 1С не поможет.
3. Установите на новый компьютер ту же сборку платформы и службу агента сервера.
4. В консоли администрирования добавьте рабочий сервер в существующий кластер, задайте диапазон портов и лимиты памяти.
5. Если нужна отказоустойчивость — отметьте второй сервер как центральный и поднимите уровень отказоустойчивости.
6. При необходимости настройте требования назначения функциональности, например фоновые задания на отдельный сервер.
7. Проверьте под нагрузкой: подключите пользователей, посмотрите, как распределились соединения.

Добавление рабочего сервера обычно не требует остановки кластера. Но изменение лимитов и перезапуск рабочих процессов обрывают сеансы, которые на них работают.

Частые ошибки и как их избежать

• ❌ Второй сервер вместо оптимизации. Медленный запрос в отчёте будет медленным на любом количестве серверов. Сначала технологический журнал и план запроса, потом железо.
• ❌ СУБД на удалённой площадке. Серверы 1С в одном ЦОД, СУБД в другом — задержка сети съедает всю выгоду от кластера.
• ❌ Разные сборки платформы. Обновили платформу на одном сервере, забыли на втором — он выпадает из кластера.
• ❌ Один центральный сервер при «отказоустойчивом» кластере. Добавили рабочие серверы, но центральный оставили один: при его отказе подключиться не сможет никто.
• ❌ Лимиты памяти не заданы. Один тяжёлый отчёт съедает память, рабочий процесс падает, а с ним — все сеансы на нём.
• ❌ Каталог srvinfo на медленном диске. Там лежат журналы регистрации и сеансовые данные; на перегруженном HDD кластер начинает тормозить.
• ❌ Не проверено восстановление. Резервные копии СУБД есть, но восстановить из них базу ни разу не пробовали.