Менеджер кластера 1С: за что отвечает rmngr и как его настроить

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

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

Из чего состоит сервер 1С и где в нём менеджер кластера

Клиент-серверный вариант 1С работает на связке из трёх процессов. Каждый отвечает за своё.

Порядок такой. Клиент обращается к агенту на порт 1540 и получает адрес менеджера нужного кластера. Менеджер сверяется с реестром, выбирает рабочий процесс и сообщает клиенту его адрес. Дальше клиент общается напрямую с rphost.

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

Что хранится в реестре кластера

Реестр лежит в каталоге данных сервера, который задаётся ключом -d при запуске агента (часто это srvinfo). Внутри подкаталог вида reg_1541, где число — порт менеджера. Там список информационных баз кластера, администраторы, настройки рабочих серверов и назначение функциональности.

Каталог нельзя править руками и сохранять только «на всякий случай» поверх запущенного сервера. Резервную копию делайте при остановленной службе — это один из случаев, когда остановка оправдана (см. ниже про окно обслуживания).

Установка и первое подключение к серверу

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

Что делает установщик в итоге:

1. Копирует ragent, rmngr, rphost и вспомогательные утилиты.
2. Регистрирует службу «Агент сервера 1С:Предприятия 8.3».
3. Прописывает в строке запуска порты и каталог данных.

Типовая строка запуска агента на Windows выглядит так:

ragent.exe -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "D:\srvinfo"

Здесь -regport — порт менеджера кластера, -port — порт агента, -range — диапазон портов для рабочих процессов, -d — каталог данных. Диапазон должен быть шире, чем число процессов, которые вы собираетесь запускать: на каждый rphost уходит порт, а при перезапусках они тоже занимаются.

На брандмауэре откройте порты 1540, 1541 и диапазон рабочих процессов. Если порты закрыты, клиент достучится до агента, а дальше соединение оборвётся — типичная картина «сервер виден, база не открывается».

Подключение консоли администрирования

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

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

Как создать кластер и настроить его свойства

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

Откройте свойства кластера. Здесь живут настройки, которые определяют поведение менеджера.

Рабочие серверы и распределение нагрузки

Рабочий сервер — это машина, которая в кластере запускает rphost. Откройте его свойства и посмотрите три параметра:

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

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

Назначение функциональности

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

Управление кластером: консоль, rac и ras

Консоль — удобный вариант для разовых операций. Для регулярных проверок и скриптов используют утилиту rac и сервер администрирования ras.

Схема простая. Сервер ras запускается как служба и общается с агентом, а rac обращается к ras. Пример запуска для локального сервера:

ras cluster --port=1545 localhost:1540

После этого команды rac отправляются на порт 1545:

rac localhost:1545 cluster list
rac localhost:1545 session list --cluster=<идентификатор кластера>

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

Типовые задачи, которые решают через консоль или rac:

• 🔹 просмотр сеансов и соединений, завершение «зависших» сеансов;
• 🔹 установка блокировки начала сеансов с кодом доступа на время обновления;
• 🔹 проверка занятых лицензий;
• 🔹 управление блокировками, если база завалена ожиданием.

Администраторы кластера

Права есть на двух уровнях. Администратор центрального сервера управляет всем сервером. Администратор кластера управляет только своим кластером и его базами. Для каждого можно выбрать способ аутентификации: пароль или вход под пользователем ОС.

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

Балансировка нагрузки: как менеджер выбирает рабочий процесс

Алгоритм сводится к двум режимам, которые вы выбираете в свойствах кластера.

1. Приоритет по производительности. Менеджер смотрит на отклик процессов и выбирает наименее загруженный. Хорошо подходит для кластера из нескольких серверов разной мощности.
2. Приоритет по объёму доступной памяти. Выбирается процесс с наибольшим свободным запасом. Защищает от ситуации, когда один процесс разрастается до отказа.

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

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

Когда кластера из одного сервера хватает

Если пользователей меньше 50–70, а база одна, второй сервер не нужен. Достаточно правильно настроить лимиты памяти и перезапуск процессов. Многосерверный кластер усложняет эксплуатацию, а при слабой сети между узлами ещё и тормозит.

Диагностика: что смотреть, когда кластер ведёт себя странно

Начните с простого и безопасного, и только потом переходите к радикальным мерам.

1. Проверьте, что служба агента запущена и слушает порты 1540 и 1541. Если порты не отвечают, остальное неважно.
2. В консоли посмотрите, сколько рабочих процессов запущено и сколько памяти они занимают. Один раздутый процесс и пустые остальные — признак неверной балансировки или слишком больших лимитов.
3. Найдите в списке сеансов «длинные» по времени и по ожиданию блокировок.
4. Откройте журнал регистрации самой базы: ошибки приложения видны там.
5. Включите технологический журнал, если нужен разбор падений процессов: настройка идёт файлом logcfg.xml в каталоге conf платформы.

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

Типовые симптомы

Безопасность и обновление

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

• 🔒 Не открывайте порты 1540, 1541 и диапазон рабочих процессов в интернет. Доступ нужен только из внутренней сети или по VPN.
• 🔒 Создайте администраторов кластера и центрального сервера с паролями, не оставляйте вход без аутентификации.
• 🔒 Запускайте службу от отдельной учётной записи с минимальными правами и доступом только к каталогам сервера.
• 🔒 Сервер администрирования ras тоже закрывайте на брандмауэре: через него управляется весь кластер.

Обновление платформы на сервере

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

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

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

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