К статье
Практический материал

Администрирование · 11 мин

Кластер 1С:Предприятия: устройство, настройка и обслуживание

Что такое кластер серверов 1С:Предприятия, из каких процессов он состоит, как настроить отказоустойчивость и проверить работу. Практическое руководство для администратора.

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

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

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

Из чего состоит кластер: агент, менеджер и рабочие процессы

Кластер 1С устроен многоуровнево. На каждом компьютере, где установлен сервер 1С, работает агент сервера (процесс ragent). Он принимает управляющие команды, регистрирует компьютер в составе кластера и обеспечивает связь между узлами. На одном из узлов дополнительно работает менеджер кластера (rphost-роль, выделяемый процесс), который хранит реестр сеансов, соединений и распределяет клиентские подключения между рабочими процессами.

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

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

Когда кластер необходим, а когда достаточно файловой базы

Кластер используется только в клиент-серверном варианте работы 1С, когда данные хранятся в СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2). Файловый вариант не использует сервер 1С вовсе — клиенты работают с файлом базы напрямую, и понятие кластера там отсутствует.

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

Файловый вариант и кластер

Файловая база

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

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

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

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

Для высокой нагрузки и требований к непрерывности. Рабочие процессы распределены по узлам, при отказе узла сеансы переносятся. Требует продуманной настройки и лицензий.

Как настроить кластер: базовый порядок действий

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

Управление выполняется через консоль «Администрирование серверов 1С:Предприятия» (оснастка MMC) или через утилиту командной строки rac в связке с ras (сервер администрирования). Консоль удобнее для разовых операций, rac — для автоматизации и скриптов.

Порядок базовой настройки кластера
  1. 1
    Установите сервер 1С и убедитесь, что служба агента сервера запущена и работает под выделенной учётной записью с нужными правами.
  2. 2
    Откройте консоль администрирования, зарегистрируйте центральный сервер и проверьте, что кластер отображается в списке.
  3. 3
    Создайте информационную базу в кластере, указав параметры подключения к СУБД, или зарегистрируйте существующую.
  4. 4
    Настройте количество рабочих процессов и лимиты памяти на процесс в свойствах рабочего сервера.
  5. 5
    Проверьте подключение клиентом, посмотрите список сеансов и убедитесь, что соединения распределяются по рабочим процессам.

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

Отказоустойчивость и распределение нагрузки

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

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

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

Мониторинг и проверка работы кластера

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

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

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

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

Список сеансов в консоли
Норма

Сеансы распределены по рабочим процессам, нет аномально долгих вызовов

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

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

Память рабочих процессов
Норма

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

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

Память rphost растёт без остановки — признак утечки, процесс скоро будет перезапущен с разрывом сеансов

Фоновые задания
Норма

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

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

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

bash
rac session list --cluster=<ид_кластера> --cluster-user=<админ> --cluster-pwd=<пароль>

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

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

Типичные ошибки администрирования кластера
01
Один рабочий процесс на сервер — при его перезапуске или падении отключаются все пользователи сразу.
02
Принудительное завершение rphost через диспетчер задач вместо штатного разрыва сеанса в консоли — массовая потеря соединений и риск незавершённых транзакций.
03
Отсутствие лимитов памяти на процесс — утечка в прикладном коде съедает всю память сервера и приводит к свопингу.
04
Фоновые задания на том же процессе, что и пользователи, — ночной обмен данными парализует работу оставшихся сотрудников.
05
Игнорирование технологического журнала — длительные запросы и взаимоблокировки остаются незамеченными до жалоб пользователей.

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

Часто задаваемые вопросы

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

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

Чем отличается кластер 1С от кластера СУБД?

Это разные уровни. Кластер 1С управляет рабочими процессами сервера приложений и сеансами пользователей. Кластер СУБД (например, отказоустойчивый кластер MS SQL Server) обеспечивает доступность самих данных. Для высокой доступности системы целиком обычно требуются оба механизма, настроенные независимо.

Можно ли обслуживать кластер без остановки работы пользователей?

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

Что делать, если сеанс пользователя «завис»?

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

Нужна ли отдельная лицензия на кластер из нескольких серверов?

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

Как понять, что проблема в кластере, а не в СУБД или сети?

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

Итог

Что важно запомнить

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