Менеджер под каждый сервис 1С 8.3: зачем это нужно

В кластере серверов 1С:Предприятие 8.3 за выполнение фоновых заданий, регламентных операций и сервисных функций отвечают сервисы кластера — сервис фоновых заданий, сервис журнала регистрации, сервис внешнего управления сеансами и другие. Каждый такой сервис исполняется внутри процесса менеджера кластера (rmngr), и администратор решает, как сервисы распределяются между менеджерами. Схема «один менеджер — один сервис» означает, что для каждого сервиса выделяется отдельный процесс rmngr, а не все сервисы теснятся в одном.

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

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

Как устроены сервисы и менеджеры в кластере 1С

Кластер серверов 1С состоит из агентов (ragent), менеджеров кластера (rmngr) и рабочих процессов (rphost). Рабочие процессы обслуживают пользовательские сеансы и вызовы. Менеджеры кластера — это служебные процессы, внутри которых исполняются сервисы кластера: фоновые задания, журнал регистрации, управление блокировками, сессионные данные, внешнее управление сеансами и другие.

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

Управлять размещением можно через требования назначения функциональности в консоли кластера. Требование задаётся для рабочего сервера и определяет, какие объекты требования (сервисы, соединения, фоновые задания) могут на нём исполняться и в каком объёме.

Зачем выделять отдельный менеджер под каждый сервис

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

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

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

Какие сервисы имеет смысл разносить в первую очередь

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

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

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

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

Настройка выполняется в консоли управления кластером (оснастка «Серверы 1С:Предприятия») на уровне рабочего сервера. Логика такая: для сервера создаются требования, которые явно разрешают размещение конкретного сервиса и запрещают всё остальное, либо наоборот — запрещают конкретный сервис, оставляя остальное.

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

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

Отказоустойчивость и ограничения схемы

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

Второе ограничение — расход памяти. Каждый менеджер кластера — отдельный процесс со своим резервом памяти. На сервере с ограниченным объёмом ОЗУ десяток выделенных менеджеров может навредить больше, чем помочь. Перед разделением оцените суммарное потребление процессов в текущей конфигурации.

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

Сравнение вариантов

Один менеджер на все сервисы

Просто и экономно по памяти; подходит малым базам. Минус — общая точка отказа

Отдельный менеджер под тяжёлые сервисы

Баланс изоляции и расхода ресурсов; рекомендуемый вариант для средних нагрузок

Менеджер под каждый сервис

Максимальная изоляция и диагностика; оправдано на больших кластерах с запасом памяти

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

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

Как проверить, что схема работает правильно

Контрольные точки

Как проверить результат

Количество процессов rmngr на сервере

Норма

Число менеджеров соответствует задуманной схеме

Тревожный признак

Менеджеров больше или меньше, чем планировалось

Выполнение фоновых заданий

Норма

Регламентные операции выполняются по расписанию

Тревожный признак

Задания висят в очереди или падают с ошибками

Потребление памяти

Норма

Суммарная нагрузка процессов в пределах доступной ОЗУ

Тревожный признак

Рост свопа, нехватка памяти

Журнал кластера

Норма

Нет повторяющихся ошибок назначения сервисов

Тревожный признак

Циклические перезапуски сервисов

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

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

FAQ

Обязательно ли выделять менеджер под каждый сервис?

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

Сколько памяти потребляет каждый менеджер кластера?

Точного фиксированного значения нет — потребление зависит от нагрузки и состава сервисов. Практичный подход: замерить фактическое потребление процессов rmngr в вашем кластере под нагрузкой и закладывать запас при планировании разделения.

Что будет, если запретить все сервисы на сервере?

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

Даёт ли разделение менеджеров отказоустойчивость?

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

Как понять, что пора разносить сервисы?

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

Можно ли привязать сервис к конкретному серверу?

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