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

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

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

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

Из чего состоит кластер серверов 1С

Базовый элемент кластера — рабочий сервер: физическая или виртуальная машина, где установлен сервер 1С:Предприятия. Один из серверов назначается центральным: на нём хранится реестр кластера (файлы в каталоге srvinfo) — список информационных баз, сеансов, рабочих процессов и настроек. Потеря центрального сервера без резервирования означает остановку всего кластера.

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

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

Как кластер распределяет нагрузку

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

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

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

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

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

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

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

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

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

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

Для диагностики полезно знать порты по умолчанию: агент сервера — 1540, кластер — 1541, диапазон рабочих процессов — 1560–1591. Эти порты должны быть открыты между клиентами, серверами кластера и (при необходимости) консолью администрирования. Типичная причина «кластер не виден» — закрытый файрвол, а не неисправность платформы.

# Проверка, что агент сервера 1С слушает порт 1540 (Linux)
netstat -tlnp | grep 1540
# Или через systemctl
systemctl status srv1cv83

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

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

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

Типичные ошибки и ограничения

Частая ошибка — установка разных версий платформы на сервер и клиенты. Сервер 1С требует точного совпадения версии (вплоть до номера релиза) между клиентом и сервером, иначе подключение отклоняется. Вторая распространённая проблема — недостаток памяти: администратор добавляет рабочие процессы, не посчитав, что каждый rphost под нагрузкой потребляет гигабайты ОЗУ, и сервер начинает активно использовать подкачку.

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

Частые вопросы о кластере серверов 1С