Кластер серверов 1С: как настроить с нуля

Кластер серверов 1С — это основной механизм масштабирования и отказоустойчивости клиент-серверной архитектуры «1С:Предприятие». Он объединяет один или несколько физических серверов, распределяет между ними клиентские сеансы, фоновые задания и соединения с СУБД, а при выходе узла из строя переносит нагрузку на оставшиеся. Без правильно настроенного кластера даже мощный сервер рано или поздно становится узким местом: рабочие процессы упираются в память, сеансы начинают аварийно завершаться, а перезапуск службы превращается в остановку работы всей компании.

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

Что понадобится перед началом настройки

Для развёртывания кластера потребуется дистрибутив технологической платформы «1С:Предприятие» той же версии, что планируется использовать в работе, лицензии на сервер и клиентские лицензии, а также сервер под управлением Windows Server или поддерживаемого дистрибутива Linux. Сервер 1С и сервер СУБД желательно размещать на разных машинах: совмещение допустимо на небольших внедрениях, но при росте нагрузки они начнут конкурировать за память и процессор.

Заранее определите роли серверов. Центральный сервер кластера хранит реестр кластера (служебные данные о сеансах, соединениях, блокировках) и управляет остальными узлами. Рабочие серверы выполняют рабочие процессы rphost, в которых непосредственно обслуживаются сеансы пользователей. В минимальной конфигурации обе роли совмещает один сервер, но для отказоустойчивости нужны как минимум два рабочих сервера.

Проверьте сетевую инфраструктуру: между серверами кластера и сервером СУБД должны быть открыты порты агента сервера (по умолчанию 1540), менеджера кластера (1541) и диапазон портов рабочих процессов (1560–1591 по умолчанию). Имена серверов должны корректно разрешаться через DNS — обращения по именам используются в реестре кластера, и проблемы с разрешением имён приводят к недоступности узлов.

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

На каждом сервере, который войдёт в кластер, установите компоненты «Сервер 1С:Предприятия» из дистрибутива платформы. В Windows при установке выберите вариант «Сервер 1С:Предприятия» и укажите, что агент должен запускаться как служба. Учётная запись службы по умолчанию — USR1CV8, она создаётся установщиком; для продуктивной среды задайте этой учётной записи надёжный пароль и минимально необходимые права.

На Linux агент сервера устанавливается из пакетов дистрибутива платформы и запускается скриптом srv1cv8. Каталог реестра кластера (srvinfo, по умолчанию в каталоге данных агента) должен располагаться на быстром и надёжном диске: при повреждении реестра кластер теряет информацию о сеансах и настройках, и восстановление потребует резервной копии этого каталога.

После установки убедитесь, что служба агента запущена и слушает порт 1540. Проверить это можно командой просмотра сетевых подключений на сервере.

netstat -ano | findstr 1540

Создание кластера и центрального сервера

Управление кластером выполняется через консоль «Администрирование серверов 1С:Предприятия» (оснастка запускается с любого компьютера, где установлены компоненты администрирования). Откройте консоль, добавьте центральный сервер по имени или IP-адресу — консоль подключится к агенту по порту 1540. Если агент доступен, в дереве появится созданный по умолчанию локальный кластер с портом 1541.

Один агент может обслуживать несколько кластеров на разных портах, но на практике чаще используется один кластер на серверную группу. В свойствах кластера задаются ключевые параметры: уровень отказоустойчивости, режим распределения нагрузки, период перезапуска рабочих процессов и допустимый объём памяти на процесс. Эти параметры напрямую влияют на стабильность, поэтому их стоит менять осознанно, а не оставлять «как есть» без понимания последствий.

Сразу после создания кластера задайте администратора кластера в разделе «Администраторы». Без учётной записи администратора консоль и утилиты командной строки работают с кластером без аутентификации, что в продуктивной среде недопустимо: любой, кто имеет сетевой доступ к порту 1540, сможет управлять кластером.

1. 1
   Установите сервер 1С на все узлы и запустите службу агента
2. 2
   Откройте консоль администрирования и добавьте центральный сервер
3. 3
   Проверьте наличие локального кластера с портом 1541
4. 4
   Создайте администратора кластера с надёжным паролем
5. 5
   Задайте уровень отказоустойчивости и параметры рабочих процессов
6. 6
   Добавьте информационные базы и проверьте подключение клиентом

Добавление рабочих серверов и рабочих процессов

Рабочий сервер добавляется в кластер через контекстное меню узла «Рабочие серверы» — укажите имя сервера, на котором уже запущен агент той же версии платформы. После регистрации сервер появится в списке, и кластер сможет назначать на него нагрузку. Если сервер не добавляется, первым делом проверяйте доступность порта 1540 на добавляемом узле и совпадение версий платформы.

На каждом рабочем сервере кластер автоматически создаёт рабочие процессы rphost. Количество процессов и предельный объём памяти на процесс настраиваются в свойствах рабочего сервера и кластера. Один процесс rphost обслуживает несколько сеансов; если процесс превышает допустимый объём памяти, кластер может перезапустить его, завершив обслуживаемые сеансы. Поэтому параметры «Допустимый объём памяти» и «Интервал превышения допустимого объёма памяти» следует подбирать под реальную нагрузку, а не устанавливать заведомо большие значения.

Для серверов с большим объёмом оперативной памяти имеет смысл увеличить число рабочих процессов: это снижает риск того, что один аварийно завершённый процесс уронит сразу много сеансов. Ориентировочный подход — несколько процессов на сервер с распределением сеансов между ними, но точные значения зависят от профиля нагрузки и подбираются по данным мониторинга.

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

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

Типовой сценарий — выделить отдельный сервер под фоновые задания и регламентные операции, чтобы тяжёлые обработки не мешали интерактивной работе пользователей. Для этого на выделенном сервере создаётся требование, запрещающее клиентские соединения, а на остальных — требование, ограничивающее фоновые задания. Требования проверяются кластером сверху вниз по списку, поэтому порядок строк в списке имеет значение.

Настраивая ТНФ, всегда оставляйте в кластере хотя бы один сервер, способный принять каждый тип нагрузки. Если запретить фоновые задания на всех серверах, кроме одного, и этот сервер выйдет из строя, регламентные задания просто перестанут выполняться — кластер не сможет переназначить их.

Отказоустойчивость и резервирование

Уровень отказоустойчивости кластера определяет, сколько рабочих серверов может одновременно выйти из строя без потери работоспособности. Значение больше нуля заставляет кластер синхронизировать данные реестра между узлами, что создаёт дополнительную нагрузку на сеть, но позволяет пережить отказ сервера без полной остановки. Сеансы пользователей при этом, как правило, переподключаются, хотя несохранённые данные в открытых формах могут быть утеряны.

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

Реестр кластера следует включить в план резервного копирования. Копируйте каталог srvinfo при остановленном агенте или штатными средствами снапшотов файловой системы, чтобы копия была консистентной. Без резервной копии реестра при сбое диска придётся пересоздавать кластер и заново регистрировать информационные базы.

Проверка работоспособности и мониторинг

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

Для постоянного контроля используйте технологический журнал платформы и счётчики производительности операционной системы: память и процессор процессов rphost, длину очередей дисков, сетевые задержки между кластером и СУБД. Резкий рост памяти одного процесса или постоянные перезапуски процессов — сигнал пересмотреть лимиты и распределение нагрузки.

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

Часто задаваемые вопросы