Администрирование · 14 мин
Кластер серверов 1С: устройство, задачи и настройка
Что такое кластер серверов 1С:Предприятие, из чего он состоит, как работает отказоустойчивость и балансировка нагрузки, когда кластер действительно нужен.
Кластер серверов 1С — это группа процессов платформы «1С:Предприятие», которые совместно обслуживают подключения пользователей к информационным базам в клиент-серверном режиме. Проще говоря, это промежуточный слой между пользователями и сервером СУБД: клиентское приложение подключается не напрямую к базе данных, а к кластеру, который выполняет код, управляет сеансами и передаёт запросы в SQL-сервер.
Минимальный кластер состоит из одного процесса «Агент сервера» (ragent) и одного рабочего процесса (rphost). Но даже в таком виде он уже выполняет ключевую функцию — изолирует пользователей от прямой работы с базой данных и позволяет централизованно управлять соединениями, лицензиями и сеансами. В крупных внедрениях кластер объединяет несколько физических серверов и десятки рабочих процессов.
Понимание устройства кластера критично для администраторов: именно через него проходят все запросы пользователей, именно здесь возникают узкие места производительности, и именно здесь настраивается отказоустойчивость. Ошибка в конфигурации кластера может остановить работу всей компании, поэтому любые изменения стоит делать с пониманием того, что происходит под капотом.
Из чего состоит кластер серверов 1С
Архитектура кластера строится вокруг нескольких типов процессов, каждый из которых решает свою задачу. Знать их назначение необходимо, чтобы понимать, какой процесс перегружен, когда система «тормозит», и что именно перезапускать при сбоях.
Агент сервера (ragent) — главный процесс кластера. Он хранит реестр кластера (список баз, рабочих серверов, требований назначения функциональности), принимает подключения клиентов и направляет их к рабочим процессам. По умолчанию агент слушает порт 1540. Без работающего агента кластер не существует.
Менеджер кластера (rmngr) — процесс, который управляет сервисами кластера: сервисом сеансовых данных, сервисом блокировок, сервисом нумерации и другими. Менеджеров может быть несколько, и один из них назначается главным. Рабочий процесс (rphost) — исполнительный процесс, который непосредственно выполняет код конфигурации, обращается к СУБД и обслуживает сеансы пользователей. Именно rphost потребляет основную часть памяти и процессорного времени.
Все эти процессы могут работать как на одном физическом сервере, так и на разных. Список рабочих процессов, их загрузку и распределение сеансов можно посмотреть в консоли администрирования серверов 1С или через утилиту rac в командной строке.
Как пользовательский запрос проходит через кластер
Когда пользователь запускает тонкий клиент или веб-клиент, приложение сначала обращается к агенту сервера по имени компьютера и порту. Агент находит нужную информационную базу в реестре кластера и возвращает клиенту адрес рабочего процесса, который будет обслуживать сеанс. Дальше клиент взаимодействует напрямую с назначенным rphost.
Рабочий процесс выполняет серверный код конфигурации: проводит документы, строит отчёты, выполняет запросы. Все обращения к данным он транслирует в SQL-запросы к серверу СУБД (MS SQL Server, PostgreSQL, Oracle или IBM DB2), получает результат и возвращает его клиенту. Таким образом, кластер — это посредник, который никогда не хранит данные сам: вся информация лежит в базе данных, а кластер держит только сеансовые данные и контекст выполнения.
Это важно понимать при диагностике проблем: если база «зависла», причина может быть как в самом кластере (перегруженный rphost, утечка памяти), так и в СУБД (блокировки, долгие запросы). Разделение ответственности между слоями помогает локализовать проблему быстрее.
Отказоустойчивость и балансировка нагрузки
Одна из главных причин развёртывания кластера из нескольких серверов — обеспечение непрерывной работы. Если в кластер входят два и более рабочих сервера, выход одного из них из строя не останавливает систему: сеансы перераспределяются на оставшиеся процессы. Пользователь при этом может потерять несохранённые данные в текущем сеансе, но сможет переподключиться и продолжить работу.
Уровень отказоустойчивости задаётся в свойствах кластера. Значение определяет, сколько рабочих серверов может одновременно выйти из строя без потери работоспособности. При этом важно понимать: отказоустойчивость кластера не заменяет резервное копирование базы данных и не защищает от сбоя самого сервера СУБД — для СУБД нужны собственные механизмы (кластеризация SQL Server, репликация, Always On).
Балансировка нагрузки регулируется через «требования назначения функциональности» — правила, которые определяют, какие сервисы и какие базы будут обслуживаться на конкретном рабочем сервере. Например, можно выделить отдельный сервер под фоновые задания, чтобы регламентные операции не мешали интерактивной работе пользователей, или закрепить тяжёлую базу за самым мощным сервером.
Когда кластер действительно нужен, а когда достаточно файлового режима
Не каждому внедрению нужен клиент-серверный режим. Файловый вариант работы, при котором база хранится в файле 1Cv8.1CD на общем сетевом ресурсе, вполне подходит для небольших компаний с ограниченным числом одновременно работающих пользователей и умеренным объёмом данных. Он проще в развёртывании, дешевле и не требует отдельного администрирования.
Переход на кластер серверов оправдан, когда: одновременно работают десятки пользователей; объём базы измеряется десятками гигабайт и растёт; требуются регламентные фоновые операции без остановки работы; нужна защита от сбоев оборудования; требуется разграничение доступа на уровне СУБД, когда пользователи не имеют прямого доступа к файлам базы.
Обратная ситуация — когда кластер разворачивают «на всякий случай» для пяти пользователей. Это приводит к лишним расходам на лицензии и железо, усложняет сопровождение и иногда даже снижает производительность из-за накладных расходов на клиент-серверное взаимодействие.
Файловый режим или кластер
Подходит для небольших команд и умеренных объёмов данных. Простое развёртывание, минимальные требования. Ограничение: слабая масштабируемость, риски при одновременной работе большого числа пользователей.
Переходный вариант: централизованное управление сеансами, фоновые задания, работа через СУБД. Ограничение: нет отказоустойчивости, сервер — единая точка отказа.
Для крупных внедрений с высокой нагрузкой и требованиями к доступности. Ограничение: стоимость лицензий, оборудования и квалифицированного администрирования.
Базовая настройка и проверка работоспособности
Установка кластера начинается с развёртывания компонента «Сервер 1С:Предприятия» из дистрибутива платформы. После установки служба агента сервера запускается автоматически, и создаётся кластер по умолчанию с именем «Локальный кластер». Дальнейшая работа ведётся через консоль администрирования серверов (оснастка «Администрирование серверов 1С Предприятия») или через утилиту командной строки rac.
Типовая последовательность создания информационной базы: зарегистрировать консолью центральный сервер, создать новую информационную базу, указав имя базы на сервере СУБД и параметры подключения, затем проверить подключение клиентским приложением. Для тонкой настройки полезно освоить rac — она позволяет автоматизировать операции скриптами, что незаменимо при обслуживании нескольких кластеров.
rac cluster list --cluster=localhost:1545После настройки обязательно проверьте ключевые контрольные точки: служба агента работает и переживает перезагрузку сервера; клиент подключается к базе по имени сервера; в консоли видны активные сеансы и рабочие процессы; фоновые задания выполняются без ошибок. Если что-то из этого не выполняется — проблему нужно решить до запуска пользователей.
Как проверить результат
Служба запущена, тип запуска — автоматический, порт 1540 отвечает
Служба остановлена или падает после старта — смотрите журналы
Тонкий клиент открывает базу по имени сервера без ошибок
Ошибка соединения — проверяйте DNS, брандмауэр и реестр кластера
В консоли видны rphost, нагрузка распределена между ними
Один процесс забит под 100% памяти, остальные простаивают
Регламентные операции выполняются по расписанию
Задания висят в состоянии «Выполняется» или завершаются ошибкой
Типичные проблемы и ошибки администрирования
Самая частая жалоба — «1С тормозит». При работе с кластером диагностику стоит начинать с мониторинга процессов rphost: если один процесс потребляет всю доступную память или процессор, а остальные простаивают, проблема в распределении нагрузки или в «проблемном» сеансе, который выполняет тяжёлый запрос. Полезно ограничить максимальный объём памяти рабочих процессов в свойствах кластера, чтобы один сбойный сеанс не «утянул» за собой весь сервер.
Вторая группа проблем — разрывы соединений. Пользователей «выкидывает» из базы при перезапуске рабочих процессов, при сетевых сбоях или при превышении лимитов. Настройка параметров «Интервал перезапуска» и «Допустимый объём памяти» для рабочих процессов помогает планово обновлять процессы без массовых отключений, если выставить безопасный режим перезапуска.
Третья группа — ошибки при изменении конфигурации под нагрузкой. Обновление конфигурации базы данных требует монопольного доступа: пока пользователи работают, обновление невозможно. Правильный порядок — заблокировать новые сеансы через консоль, дождаться завершения активных (или завершить их принудительно с предупреждением), выполнить обновление, снять блокировку.
Полезные инструменты администратора кластера
Штатный минимум — консоль администрирования серверов и утилита rac. Консоль удобна для разовых операций: просмотр сеансов, завершение зависших соединений, блокировка базы на время обновления. Утилита rac незаменима для автоматизации: скрипты блокировки базы перед ночным бэкапом, массовое завершение сеансов, сбор статистики.
Для глубокой диагностики производительности используется технологический журнал — механизм платформы, который логирует события кластера: длительные запросы, блокировки, ошибки, вызовы. Его включение требует создания конфигурационного файла logcfg.xml, а анализ больших логов удобнее вести специализированными средствами вроде Центра администрирования или сторонних парсеров.
Журнал регистрации самой информационной базы дополняет картину на прикладном уровне: какие пользователи что делали, какие ошибки возникали в коде. Комбинация этих трёх источников — консоль, технологический журнал, журнал регистрации — покрывает большинство задач диагностики.
- 1Создайте резервную копию базы данных средствами СУБД
- 2В консоли кластера установите блокировку начала сеансов с сообщением пользователям
- 3Дождитесь завершения активных сеансов или завершите их принудительно
- 4Выполните обновление конфигурации базы данных в конфигураторе
- 5Проверьте запуск базы тестовым сеансом, затем снимите блокировку
Что важно запомнить
Кластер серверов 1С — это связующий слой между пользователями и СУБД: агент принимает подключения, рабочие процессы выполняют код, менеджеры управляют сервисами. Он даёт балансировку нагрузки и отказоустойчивость, но требует грамотного администрирования: ограничения памяти процессов, контроля сеансов, регламентного обслуживания и резервного копирования как базы, так и реестра кластера.
Частые вопросы о кластере серверов 1С
Чем кластер серверов 1С отличается от сервера СУБД?
Это разные слои. Сервер СУБД (MS SQL, PostgreSQL и др.) хранит данные и выполняет SQL-запросы. Кластер 1С не хранит данные — он выполняет код конфигурации, управляет сеансами пользователей и формирует запросы к СУБД. Для работы клиент-серверной 1С нужны оба компонента, и размещать их можно как на одной машине, так и на разных.
Можно ли перенести кластер на другой сервер без потери данных?
Да. Сами данные находятся в базе СУБД, поэтому перенос сводится к установке сервера 1С на новую машину, переносу базы данных средствами СУБД и созданию в новом кластере информационной базы с теми же параметрами подключения. Либо можно перенести каталог реестра кластера (srvinfo) со старого сервера — тогда список баз сохранится. После переноса обязательно проверьте подключение тестовым клиентом.
Сколько рабочих процессов rphost должно быть в кластере?
Универсального числа нет: оно зависит от количества пользователей, характера нагрузки и объёма памяти сервера. Практический подход — следить, чтобы ни один процесс не упирался в лимит памяти и чтобы нагрузка распределялась равномерно. Слишком мало процессов — риск взаимного влияния сеансов, слишком много — лишний расход памяти на сами процессы.
Что делать, если пользователей постоянно «выкидывает» из базы?
Сначала определите характер разрывов: всех одновременно или отдельных пользователей. Массовые разрывы обычно связаны с перезапуском рабочих процессов по лимитам памяти, падением rphost или сетевыми проблемами — смотрите технологический журнал и журнал событий Windows. Единичные разрывы чаще указывают на нестабильную сеть конкретного клиента или ошибки в сеансе.
Нужен ли отдельный сервер под кластер 1С?
Для малой нагрузки кластер и СУБД могут работать на одном физическом сервере — это упрощает инфраструктуру. При росте числа пользователей и объёма базы разнесение на разные машины даёт выигрыш: каждый компонент получает выделенные ресурсы, а администратору проще находить узкое место. Решение стоит принимать по фактическим замерам загрузки, а не «про запас».
Как узнать, какой процесс rphost обслуживает конкретного пользователя?
В консоли администрирования откройте список сеансов информационной базы — для каждого сеанса отображается рабочий процесс и соединение. Ту же информацию можно получить через rac с помощью команд вывода сеансов и соединений. Это полезно при диагностике: зависший сеанс можно завершить точечно, не перезапуская весь кластер.