Что входит в кластер серверов 1С и как устроена его работа

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

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

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

Агент сервера 1С — точка входа в кластер

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

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

Один агент может обслуживать несколько кластеров на одном сервере, если они созданы с разными портами. По умолчанию агент использует порт 1540, менеджер кластера — 1541, а диапазон рабочих портов начинается с 1560.

Менеджер кластера и его роль в распределении нагрузки

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

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

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

Рабочие процессы rphost — исполнители прикладного кода

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

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

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

Системные сервисы кластера

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

• Сервис сеансов — ведёт список активных сеансов пользователей, контролирует их идентификаторы и время жизни. Именно через него проходит проверка подлинности сеанса при обращениях клиента.
• Сервис соединений с информационными базами — управляет подключениями рабочих процессов к базам данных, ведёт пул соединений с СУБД.
• Сервис блокировок — обеспечивает управляемые транзакционные блокировки данных, согласуя конкурентный доступ пользователей к одним и тем же объектам.
• Сервис фоновых заданий — отвечает за планирование и запуск регламентных и фоновых заданий в кластере.
• Сервис журнала регистрации и сервис внешнего управления сеансами — обслуживают запись журнала регистрации и интеграцию с системами ограничения числа сеансов (например, для ограниченных лицензий в сервисных моделях).

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

Резервные кластеры и отказоустойчивость

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

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

Резервирование кластера не заменяет резервное копирование баз данных — это защита от отказа сервера приложений, а не от потери данных. Резервные копии СУБД должны настраиваться отдельно и независимо.

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

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

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

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

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

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

Кластер серверов 1С не включает в себя сервер СУБД (MS SQL, PostgreSQL, Oracle, IBM Db2) — это отдельная система, с которой рабочие процессы устанавливают соединения. Также в кластер не входят веб-сервер (IIS или Apache), который публикует информационные базы для тонкого и веб-клиента, и сервер лицензирования в части программных лицензий, хотя выдача лицензий может выполняться самим кластером.

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

Что за что отвечает

Кластер серверов 1С

Исполнение прикладного кода, сеансы, блокировки, фоновые задания, распределение нагрузки. Не хранит данные.

СУБД (MS SQL, PostgreSQL и др.)

Хранение данных информационных баз, выполнение запросов, транзакционная целостность. Не знает о логике конфигурации.

Веб-сервер (IIS, Apache)

Публикация баз для веб-клиента и веб-сервисов, проксирование запросов в кластер. Не исполняет прикладной код самостоятельно.

Как проверить состав и состояние кластера

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

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

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

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

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

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

Норма

Все rphost в состоянии «работает», сеансы распределены между процессами

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

Процессы аварийно перезапускаются или все сеансы сосредоточены на одном процессе

Назначение системных сервисов

Норма

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

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

Сервис без назначения или назначен процессу с высокой нагрузкой

Свободная память и диск на сервере

Норма

Есть запас памяти под рост rphost и место под технологический журнал

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

Память исчерпана, диск заполнен — риск аварийного останова процессов

Частые ошибки при работе с кластером

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

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

Сколько рабочих процессов rphost должно быть на сервере?

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

Можно ли перенести кластер 1С на другой сервер без потери баз?

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

Что делать, если в консоли кластера пропали информационные базы?

Чаще всего причина — повреждение или замена файлов реестра кластера (каталог reg_1541). Проверьте, не очищался ли каталог данных сервера и не восстанавливалась ли машина из старого образа. Базы в СУБД при этом целы: достаточно заново зарегистрировать их в консоли с прежними параметрами подключения.

Нужен ли резервный кластер в небольшой организации?

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

Почему пользователей выбрасывает из программы с ошибкой разрыва соединения?

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