Из чего состоит кластер 1С:Предприятия и как он распределяет нагрузку

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

Всё, что относится к архитектуре кластера 1С:Предприятия 8.3, одинаково для любых конфигураций: Бухгалтерии, ЗУП, ERP. Разница только в нагрузке, которую они создают. Ниже про устройство изнутри, про то, как кластер выбирает процесс для сеанса, какие параметры на это влияют и где у этой схемы потолок.

Состав кластера: роли процессов и портов

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

Кто за что отвечает:

• 🛡️ ragent — агент сервера. Один на компьютер (на одну установку службы). Запускает и останавливает остальные процессы, принимает подключения консоли администрирования, хранит список администраторов центрального сервера.
• 🧭 rmngr — менеджер кластера. Ведёт реестр кластера: список баз, рабочих серверов, администраторов, сеансов. Распределяет соединения между рабочими процессами. Внутри менеджера работают сервисы кластера: блокировок, сеансовых данных, журналов регистрации, лицензирования, полнотекстового поиска и другие.
• ⚙️ rphost — рабочий процесс. Выполняет серверный код конфигурации, запросы к СУБД, фоновые и регламентные задания. Их может быть сколько угодно, кластер поднимает и гасит их сам.

Как выглядят порты при установке по умолчанию:

Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера, а не кластера. Если между клиентами и сервером стоит межсетевой экран, открывать нужно весь диапазон, а не только 1540–1541. Иначе подключение проходит до менеджера и обрывается на этапе передачи клиента рабочему процессу.

Строка запуска службы показывает эти параметры явно:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug

Ключ -d указывает каталог srvinfo, где хранится всё состояние кластера. Второй кластер на той же машине поднимают отдельной службой с другими портами, например 2540, 2541 и диапазоном 2560:2591.

Центральный сервер и менеджер кластера

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

На практике путь клиента такой:

1. Клиент читает строку подключения вида Srvr="srv1c";Ref="buh". Если менеджер работает не на 1541, порт указывают через двоеточие: Srvr="srv1c:2541".
2. Менеджер кластера проверяет, что база с таким именем зарегистрирована, и выбирает рабочий процесс.
3. Клиент получает адрес и порт выбранного rphost и дальше работает с ним напрямую.
4. Сеанс регистрируется в реестре, в консоли появляется строка в списке сеансов.

Менеджер не выполняет код конфигурации. Если на центральном сервере «тормозит 1С», почти всегда виноваты рабочие процессы или СУБД, а не rmngr.

Несколько менеджеров на одном сервере

Сервисы кластера по умолчанию живут в одном процессе rmngr. В свойствах рабочего сервера есть флажок «Менеджер под каждый сервис». Если его включить, кластер разнесёт сервисы по отдельным процессам rmngr. Это помогает на больших установках: сбой или зависание одного сервиса, например полнотекстового поиска, не тянет за собой остальные.

Рабочие процессы rphost: что внутри и как ими управлять

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

• 📚 «Количество ИБ на процесс» — сколько разных баз может обслуживать один процесс. По умолчанию 8.
• 🔌 «Количество соединений на процесс» — сколько соединений один процесс принимает до того, как кластер запустит новый. По умолчанию 128.

Когда лимиты исчерпаны, кластер стартует следующий rphost. Поэтому в диспетчере задач можно видеть пять–десять таких процессов при сотне пользователей, и это норма.

Если выставить «Количество ИБ на процесс» = 1, каждая база получит собственные процессы. Плюс: ошибка или утечка памяти в одной базе не роняет соседние. Минус: память расходуется сильнее, потому что метаданные каждой конфигурации загружаются в каждый процесс отдельно.

Состояние процесса

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

Как кластер распределяет нагрузку между процессами

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

На выбор влияют две настройки:

1. Режим распределения нагрузки в свойствах кластера. Вариант «Приоритет по производительности» отдаёт соединения самому быстрому процессу. Вариант «Приоритет по памяти» старается уплотнить соединения в меньшее число процессов, чтобы сэкономить память.
2. Требования назначения функциональности — правила в свойствах рабочего сервера. Они говорят, какие объекты на каком сервере разрешено или запрещено размещать: клиентские соединения, фоновые задания, сервис журналов, полнотекстовый поиск. Через них, например, фоновые задания выносят на отдельный сервер, чтобы ночная загрузка банка не мешала дневным пользователям.

Перебалансировка

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

Балансировка распределяет только вызовы сервера 1С. Она не ускоряет СУБД. Если упирается SQL Server или PostgreSQL, добавление рабочих серверов в кластер ничего не даст.

Параметры кластера и реестр: где что хранится

Параметры живут в двух местах: в свойствах кластера и в свойствах каждого рабочего сервера. Их легко перепутать.

Плановый перезапуск процессов

«Интервал перезапуска» задаётся в секундах. Например, 86400 — раз в сутки. По истечении интервала кластер запускает новый процесс, а старый выключает и даёт ему доработать. Это самый мягкий способ гасить постепенный рост памяти rphost. Значение 0 отключает перезапуск.

Лимиты памяти на рабочем сервере

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

Отдельные лимиты задают общий объём памяти рабочих процессов на сервере: до какого объёма сервер считается производительным и после какого кластер начинает принимать меры.

Реестр кластера

Всё состояние хранится в каталоге srvinfo (путь из ключа -d в строке службы):

• srvinfo\1CV8WSrv.lst — список кластеров этого агента и администраторы центрального сервера;
• srvinfo\reg_1541\1CV8Clst.lst — реестр кластера: базы, рабочие серверы, параметры, администраторы кластера;
• srvinfo\reg_1541\<GUID базы>\ — каталоги баз с журналом регистрации и служебными файлами;
• srvinfo\reg_1541\snccntx… — данные сервиса сеансовых данных.

Перед любыми работами с кластером копируйте файл 1CV8Clst.lst. Если реестр повреждён или потерян пароль администратора кластера, правильный путь — остановить службу и вернуть файл из копии. Пересоздавать кластер и заново регистрировать базы ради этого не нужно.

Мониторинг кластера: консоль, rac и технологический журнал

Смотреть за кластером можно тремя способами.

Консоль администрирования серверов

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

regsvr32 "C:\Program Files\1cv8\8.3.xx.xxxx\bin\radmin.dll"

Команду запускают от имени администратора. Версия radmin.dll должна совпадать с версией службы агента.

В консоли полезно держать открытыми три списка:

• 👥 Сеансы — кто подключён, к какой базе, на каком процессе, сколько времени идёт текущий вызов;
• 🔒 Блокировки — кто держит управляемые блокировки, когда пользователи жалуются на ожидание;
• 📈 Рабочие процессы — память, доступная производительность, число соединений.

Утилита rac

Для скриптов и удалённого доступа без MMC запускают сервер администрирования ras и утилиту rac:

ras cluster --port=1545 srv1c:1540
rac srv1c:1545 cluster list
rac srv1c:1545 process list --cluster=<UUID кластера>
rac srv1c:1545 session list --cluster=<UUID кластера>

Если на кластере заданы администраторы, добавьте к командам --cluster-user и --cluster-pwd. Полный список команд и параметров выводит rac help.

Технологический журнал

Когда консоль показывает «медленно», но не объясняет почему, включают технологический журнал. Его настраивают файлом logcfg.xml в каталоге conf платформы. Пример, который пишет исключения, взаимоблокировки и долгие запросы к СУБД:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="10000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Параметр history — сколько часов хранить файлы. Журнал растёт быстро, поэтому держите его на отдельном диске и выключайте, когда собрали картину.

Где у кластера 1С предел масштабирования

Добавить рабочий сервер в кластер несложно, но рост мощности не линеен. Ограничения стоит знать заранее.

• 🗄️ СУБД одна на базу. Все рабочие серверы ходят в один экземпляр SQL Server или PostgreSQL. Если упирается диск или процессор сервера СУБД, расширение кластера не поможет.
• 🔐 Управляемые блокировки централизованы. Сервис блокировок работает в менеджере кластера. При высокой конкуренции за одни и те же данные очередь ожидания растёт независимо от числа серверов.
• 🌐 Сеть между серверами. Рабочие процессы обмениваются данными с менеджером постоянно. Задержка в несколько миллисекунд между узлами уже заметна на массовых операциях.
• 💾 Сеансовые данные. Каталоги snccntx разрастаются, а при их повреждении появляются ошибки сеансов. Очистка требует остановки службы.
• 🧾 Лицензии. Для работы рабочего сервера нужна серверная лицензия, а для пользователей — клиентские. Программная лицензия привязана к параметрам оборудования, и замена железа или переезд виртуальной машины может её сбить.
• 🧠 Память rphost. Утечки в коде конфигурации или тяжёлые отчёты раздувают процессы. Кластер лечит это перезапуском, но не устраняет причину.

Когда нужен второй кластер, а не второй сервер

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

Частые вопросы