Кластер серверов 1С:Предприятие 8.3: полное руководство по архитектуре, созданию и настройке

Подходит: системным администраторам, IT-директорам и архитекторам, которые разворачивают или уже эксплуатируют кластер 1С 8.3 — от первой установки до troubleshooting в продуктиве.

Что закрывает: архитектура кластера, пошаговое развёртывание, тонкая настройка rphost, ТНФ, отказоустойчивость платформы 1С и СУБД раздельно, диагностика и устранение типовых ошибок, безопасность соединений, RAS/CLI-администрирование.

Кому не нужна: если вы работаете в файловом режиме (менее 5 пользователей) или только выбираете конфигурацию 1С — начните с более общего материала.

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

Принципиальное отличие от одиночного сервера — исключение единой точки отказа (SPOF). Одиночный сервер при сбое означает полную недоступность 1С до восстановления. Кластер с синхронной репликой переходит на резервный узел: по данным архитектурной документации платформы, failover занимает порядка десятков секунд и зависит от типа клиента, конфигурации сети, DNS, настроек таймаутов и типа СУБД (Selectel, docs.selectel.ru, 2023). Достижимый SLA определяется совокупностью всех слоёв: платформы 1С, СУБД и сетевой инфраструктуры.

Кластер решает три класса задач, которые одиночный сервер закрыть не способен.

Отказоустойчивость (High Availability). При падении узла платформа автоматически перераспределяет активные сеансы на работающие серверы. Ключевое правило платформы: количество работающих центральных серверов в кластере должно быть на единицу больше, чем настроенный уровень отказоустойчивости (Infosoft, is1c.ru, 2018). При уровне 0 с двумя центральными серверами: если один падает, пользователи получают ошибку и перезапускают 1С, подключаясь ко второму. При уровне 1 с тремя центральными серверами: переброс сеанса происходит автоматически, пользователь видит лишь кратковременное замедление (itspectr.ru, 2023).

Балансировка нагрузки. Центральный сервер анализирует загруженность каждого rphost по метрикам CPU, памяти и дискового ввода-вывода, после чего направляет новое соединение к наименее загруженному процессу. Балансировка работает с погрешностью 25%: если разница в производительности двух серверов меньше этого порога, выбор может пасть на менее производительный (v8.1c.ru/platforma/masshtabiruemost-klastera, 2023).

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

Архитектура кластера строится на строгом разделении ролей между тремя типами процессов. Каждый из них выполняет свою функцию, и понимание этого разделения — основа грамотного администрирования 1С.

Расшифровка компонентов:

• ragent — агент сервера
• rmngr — менеджер кластера
• rphost — рабочий процесс

ragent.exe (агент сервера) — главная служба операционной системы. Она запускается первой, ведёт реестр кластеров на данном рабочем сервере и управляет запуском остальных процессов. Без работающего ragent ни rmngr, ни rphost не стартуют.

Типовая строка запуска службы (пример для версии 8.3.25.1445 на Windows):

Если служба не стартует, проверьте прежде всего правильность пути к srvinfo и права учётной записи на эту папку — это наиболее частые причины (EFSOL, efsol.ru, 2025).

rmngr.exe (менеджер кластера) — управляет функционированием всего кластера: ведёт реестр баз данных, управляет лицензиями, блокировками транзакций и полнотекстовым поиском (официальная документация 1С:Предприятие 8.3, v8.1c.ru). В кластере всегда один главный менеджер; остальные экземпляры rmngr — дополнительные, они подхватывают управление при сбое главного. Именно этот процесс принимает входящее соединение от клиента, анализирует загрузку и перенаправляет приложение к конкретному rphost.

rphost.exe (рабочий процесс) — непосредственно обслуживает клиентские сеансы: исполняет серверные модули конфигурации, взаимодействует с СУБД, формирует ответы клиентам. На одном рабочем сервере может быть запущено несколько rphost — это позволяет изолировать нагрузку и задействовать несколько ядер процессора.

Важный нюанс по версионности: параметр «Временно допустимый объём памяти процессов» корректно работает в версиях 8.3.15 (начиная с 8.3.15.1700), 8.3.17 и 8.3.18, но игнорируется платформой в версии 8.3.16 — это стоит учитывать при выборе версии для продуктивной среды. Для подтверждения рекомендуется сверяться с официальными релиз-нотами конкретного релиза на v8.1c.ru.

Выбор схемы определяется требованиями к доступности и бюджетом.

Централизованная схема. Все компоненты — ragent, rmngr, rphost — работают на одном физическом сервере. Это базовый уровень: кластер технически существует, но SPOF не устранена. Подходит для разработки, тестирования или небольших команд до 20–30 пользователей.

Распределённая схема (Active/Active). Несколько рабочих серверов одновременно принимают клиентские соединения. Нагрузка делится пропорционально загрузке узлов. При отказе одного узла его сеансы перераспределяются между остальными. Это основная схема для нагруженных инсталляций.

Кластер с резервированием (Active/Passive). Один центральный сервер активен, второй — в горячем резерве. При сбое основного управление переходит к резервному. Время переключения зависит от конфигурации и составляет от нескольких десятков секунд до нескольких минут — зависит от настроек таймаутов, DNS и типа клиентского подключения. Схема проще в настройке, чем Active/Active, и применяется там, где требуется строгая консистентность данных.

Перед установкой кластера убедитесь, что выполнены все пункты:

• Создана доменная учётная запись службы (например, svc_1cv8) с минимальными правами
• NTP настроен на всех узлах (расхождение не более 1–2 секунд)
• DNS разрешает имена всех узлов кластера в обе стороны
• Открыты порты: 1540 (ragent), 1541 (rmngr), 1560–1591 (rphost), 1545 (RAS)
• Каталог srvinfo размещён на быстром диске (SSD/NVMe)
• srvinfo и каталоги БД добавлены в исключения антивируса
• Сжатие дисков для разделов с srvinfo и БД отключено
• Схема электропитания «Высокая производительность» установлена в ОС и BIOS/UEFI
• C-States отключены в BIOS (снижает задержки при пиковых обращениях к процессору)
• IPv4 и IPv6 не используются одновременно на рабочих серверах кластера
• На каждом узле достаточно лицензий для работы всех пользователей при отсутствии одного ЦС
• Настроены бэкапы каталога srvinfo (без exec-backup на активные каталоги сеансовых данных)

Каталог srvinfo — рабочий каталог центрального сервера, содержащий служебные файлы кластера: 1CV8Clst.lst, srvribrg.lst, журналы регистрации в подкаталогах reg_<порт>\<UUID базы>\1Cv8Log. Путь к каталогу задаётся ключом -d в реестре службы ragent.exe; после обновления сервера 1С путь может сбрасываться на значение по умолчанию — проверяйте его после каждого апдейта (efsol.ru, 2023). Этот каталог необходимо добавить в исключения антивируса: сканирование в реальном времени создаёт дополнительную задержку при каждой операции с журналом регистрации. Сжатие дисков для разделов с srvinfo и базами данных следует отключить.

Для работы кластера должны быть открыты следующие TCP-порты (официальная документация 1С, v8.1c.ru):

Важно: не используйте IPv4 и IPv6 одновременно на рабочих серверах кластера — это приводит к непредсказуемым ошибкам соединений (Инструкция по настройке рабочих серверов 1С, its.1c.ru, 2016).

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

Все серверы кластера должны работать под одной учётной записью Windows — это требование платформы для корректного взаимодействия между узлами (официальная документация 1С, v8.1c.ru). Рекомендуется создать отдельную доменную учётную запись (например, svc_1cv8) с минимально необходимыми правами, не используя локальную систему или администратора.

После установки убедитесь, что каталог srvinfo находится на быстром диске (NVMe или SSD), а его путь в реестре службы ragent.exe указывает именно туда.

Запустите службу «Агент сервера 1С:Предприятия» (ragent.exe) на всех узлах. Проверьте статус через диспетчер служб или командой:

На брандмауэре каждого сервера откройте входящие TCP-порты: 1540, 1541, 1560–1591, 1545. Проверьте доступность с соседних узлов. Вместо telnet (который часто отключён) используйте PowerShell:

Команда вернёт TcpTestSucceeded : True при успешном соединении. Если порты заблокированы, служба запустится, но узлы не увидят друг друга. Дополнительные инструменты отладки сервера 1С — в отдельном материале.

Запустите утилиту «Администрирование серверов 1С:Предприятие». В дереве слева добавьте центральный сервер: укажите его имя или IP-адрес, порт агента (1540 по умолчанию). После подключения создайте кластер: правый клик по узлу → «Создать кластер» → задайте имя кластера и порт (1541). На этом шаге формируется реестр кластера — главный rmngr инициализируется автоматически.

Настройте свойства кластера:

• Имя кластера: удобное для идентификации имя.
• Уровень отказоустойчивости: 0 для базовой конфигурации (2 ЦС), 1 при 3 ЦС.
• Режим распределения нагрузки: «Приоритет по производительности» — платформа сама распределяет сеансы по внутреннему механизму анализа производительности.
• Интервал перезапуска rphost: рекомендуется оставить 0 (не перезапускать по таймеру), вместо этого настраивайте перезапуск по лимиту памяти.

Проверьте, что в ветке кластера появились разделы «Рабочие серверы», «Рабочие процессы» и «Информационные базы».

Для каждого дополнительного рабочего сервера: правый клик по разделу «Рабочие серверы» → «Добавить рабочий сервер» → укажите сетевой адрес и порт агента. Сервер 1С:Предприятие должен быть заранее установлен на целевой машине, а служба ragent — запущена.

После добавления платформа автоматически инициирует рабочие процессы (rphost) на новом сервере. Убедитесь, что все добавленные серверы отображаются в дереве со статусом «Работает».

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

Рабочие процессы rphost склонны накапливать память из-за особенностей платформы и неоптимизированного кода конфигураций. Управляются тремя параметрами.

Допустимый объём памяти — лимит, при превышении которого процесс помечается как неактивный и перестаёт получать новые соединения. Формула расчёта:

Пример: сервер с 12 ГБ RAM, 2 ГБ под ОС, один rphost — допустимый объём составит 10 ГБ; два rphost — по 5 ГБ каждому (ИТС 1С, its.1c.ru).

Интервал превышения — время в секундах с момента запуска процесса, по истечении которого rphost, превысивший лимит, принудительно перезапускается. Значение 86400 секунд (24 часа) — стандартный ориентир для режима экономии памяти; для нагруженных систем с утечками памяти уменьшите до 21600–43200 секунд (efsol.ru, руководство по 1С 8.3.27).

Выключенные процессы останавливать через — таймаут для корректного завершения сеансов перед остановкой процесса. Слишком маленькое значение (менее 15 секунд) приводит к принудительному обрыву активных соединений. Как рассчитать это значение: запустите конфигурацию, засеките время от первого входа до появления окна логина и пароля, умножьте на два и укажите в настройках. Для «УТ 11» это обычно около 30 секунд, для «ERP» может быть до 5–6 минут (Infosoft, is1c.ru, 2018).

Обязательно: включите галочку «Принудительно завершать проблемные процессы», иначе завершённый по лимиту памяти rphost останется в памяти до перезагрузки сервера.

Мониторинг после настройки: наблюдайте за потреблением памяти rphost через вкладку «Рабочие процессы» в консоли, а также через системный монитор ОС. Если rphost перезапускается чаще ожидаемого — проверьте утечки памяти в конфигурации (инструмент: технологический журнал 1С).

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

Как платформа выбирает сервер при равных приоритетах (алгоритм):

1. Строит список серверов по алфавиту (как указано в консоли кластера).
2. Исключает серверы, у которых данный сервис стоит в «Не назначать».
3. Оставляет серверы с типом «Назначать».
4. Если их несколько — выбирает с наибольшим приоритетом.
5. Если приоритеты равны — выбирает с наибольшей производительностью.
6. Производительность определяется с погрешностью 25%: при разнице менее 25% выбор непредсказуем (Infosoft, is1c.ru, 2018).

Типовые схемы назначения:
Схема 1 (базовая, 2 сервера):

• SRV01: сеансовые данные (приоритет 10), журнал регистрации (приоритет 10), пользовательские сеансы.
• SRV02: сеансовые данные (приоритет 5, резерв), журнал регистрации (приоритет 5, резерв), фоновые задания (приоритет 10, «Не назначать» для пользовательских сеансов).

Схема 2 (выделенный сервер лицензирования):

• LIC01: только сервис лицензирования; все остальные сервисы — «Не назначать». Это предотвращает попытку платформы направить на него пользовательский сеанс без лицензии.

Типичные ошибки при настройке ТНФ:

• Не настроен журнал регистрации — он пишется то на одном, то на другом сервере; при необходимости собрать историю данные разрознены.
• Не настроен полнотекстовый поиск — индекс обновляется на разных серверах попеременно, создавая лишнюю нагрузку.
• Не настроены сеансовые данные — при переключении ЦС сеансы теряются.

Сервисы кластера и примеры практических схем назначения — в отдельном материале по администрированию.

Какие сервисы критично изолировать:

• Лицензирование — выносится на выделенный сервер (например, LIC01) с запретом всех остальных сервисов. Исключает ситуацию, когда перегруженный рабочий сервер «теряет» лицензии.
• Журнал регистрации — отдельный сервер снижает дисковую нагрузку на узлы с пользовательскими сеансами.
• Фоновые и регламентные задания — назначаются исключительно на выделенный сервер (TS01) с запретом на остальных.
• Взаимодействие с внешними базами данных — рекомендуется вынести на отдельный узел при активной интеграции (Инструкция по настройке рабочих серверов 1С, п. 7.5; efsol.ru, 2024).

Полная настройка ТНФ, включая изоляцию фоновых заданий и гибкое управление распределением нагрузки по серверам, доступна только при наличии лицензии сервера уровня КОРП.

Правильно настроенное логирование — основа быстрого расследования инцидентов. Без него при сбое у вас будет только симптом, но не причина.

Технологический журнал (ТЖ) настраивается через файл logcfg.xml в каталоге установки платформы (conf). Это основной инструмент диагностики медленных запросов, долгих блокировок и ошибок rphost.

Минимальная конфигурация для сбора дампов и критических ошибок:

Где хранить дампы: на отдельном диске от srvinfo и БД. При сбое rphost дамп может быть значительным по размеру; недостаток места на диске srvinfo в момент сбоя приведёт к потере диагностической информации. Настройте ротацию и очистку по возрасту.

Укажите номер телефона — мы перезвоним в течение рабочего дня и ответим на ваши вопросы по кластеру 1С.