Администрирование · 12 мин
Как работает кластер серверов 1С: устройство и практика администрирования
Как устроен кластер серверов 1С:Предприятие: роли агентов и рабочих процессов, менеджер кластера, сеансы, отказоустойчивость, настройка требований назначения функциональности.
Кластер серверов 1С — это связка из одного или нескольких физических серверов, которые совместно обслуживают информационные базы предприятия. Кластер принимает соединения от клиентских приложений, распределяет нагрузку между рабочими процессами, хранит служебную информацию о сеансах и обеспечивает взаимодействие с СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2). Без кластера сервер 1С не работает: даже в минимальной конфигурации на одной машине разворачивается кластер из одного сервера.
Главная задача кластера — масштабируемость и отказоустойчивость. Когда пользователей становится больше, чем выдерживает один рабочий процесс, администратор добавляет рабочие процессы или целые серверы, и кластер сам распределяет между ними сеансы и фоновые задания. Если один из серверов выходит из строя, сеансы переназначаются на уцелевшие узлы — при правильной настройке пользователи этого почти не замечают.
Важно понимать: кластер 1С не дублирует данные. Все информационные базы хранятся в СУБД, и отказоустойчивость данных обеспечивается средствами самой СУБД (репликация, Always On, резервное копирование). Кластер отвечает только за прикладной уровень — выполнение кода конфигурации, управление сеансами и фоновыми заданиями.
Из чего состоит кластер: агент, менеджер, рабочие процессы
На каждом сервере, входящем в кластер, работает служба «Агент сервера 1С:Предприятия» (ragent). Агент принимает подключения от клиентов и консоли администрирования, знает состав кластера и перенаправляет запросы нужным процессам. По умолчанию агент слушает порт 1540, менеджер кластера — 1541, а рабочие процессы занимают диапазон портов 1560–1591.
Менеджер кластера (rmngr) — центральный процесс, который ведёт реестр кластера: список информационных баз, сеансов, соединений, блокировок и требований назначения функциональности. Эти данные хранятся в каталоге srvinfo (файлы реестра, например 1CV8Clst.lst). Потеря каталога srvinfo при отсутствии резервной копии означает, что список баз придётся регистрировать в кластере заново, хотя сами данные в СУБД не пострадают.
Рабочие процессы (rphost) выполняют код конфигурации: обрабатывают запросы клиентов, проводят документы, формируют отчёты, исполняют фоновые задания. Именно rphost потребляет основную память и процессорное время. На одном сервере обычно запускают несколько rphost, чтобы изолировать сбои и эффективнее использовать ресурсы.
Как клиент подключается через кластер
Когда пользователь запускает тонкий или толстый клиент, тот обращается к агенту сервера по имени сервера и порту. Агент передаёт запрос менеджеру кластера, тот находит нужную информационную базу в реестре и выбирает рабочий процесс с учётом требований назначения функциональности и текущей нагрузки. Дальше клиент работает уже напрямую с выбранным rphost.
Сеанс — это логическое представление подключения пользователя в кластере. Даже если сетевое соединение разорвалось, сеанс какое-то время живёт: клиент может переподключиться и продолжить работу, при этом кластер может назначить ему другой рабочий процесс. Время жизни разорванного сеанса и период проверки задаются в свойствах кластера и влияют на то, как быстро освобождаются лицензии и блокировки.
Инфраструктурно схема выглядит так: клиенты → агент сервера → менеджер кластера → рабочий процесс → СУБД. Веб-клиент добавляет в цепочку веб-сервер (IIS или Apache), который публикует базу и проксирует запросы к кластеру.
- 1Клиент обращается к агенту сервера (порт 1540) по имени сервера
- 2Агент передаёт запрос менеджеру кластера (порт 1541)
- 3Менеджер находит базу в реестре и выбирает рабочий процесс по требованиям функциональности и нагрузке
- 4Клиент получает адрес rphost и устанавливает с ним прямое соединение
- 5Рабочий процесс обращается к СУБД от имени службы сервера 1С
Отказоустойчивость: уровни резервирования и переключение
Кластер считается отказоустойчивым, если в нём минимум два рабочих сервера и настроено резервирование менеджера кластера. Уровень отказоустойчивости задаётся в свойствах кластера и определяет, сколько резервных менеджеров поддерживается. При отказе основного менеджера один из резервных берёт его функции на себя, используя синхронизированную копию реестра.
Рабочие процессы резервируются естественным образом: если один rphost аварийно завершился, сеансы, которые он обслуживал, при следующем обращении клиента переназначаются на живые процессы. Пользователь увидит паузу или сообщение о разрыве соединения, после чего продолжит работу. Незавершённые транзакции при этом откатываются — данные в СУБД остаются целостными.
Есть и ограничения. Если в кластере один сервер, отказоустойчивости нет: падение службы остановит работу всех пользователей. Кроме того, кластер не спасает от отказа сервера СУБД — для базы данных нужны собственные механизмы резервирования. Поэтому отказоустойчивость строится комплексно: несколько серверов 1С плюс кластер СУБД или репликация.
Распределение нагрузки и требования назначения функциональности
Кластер распределяет нагрузку не только по количеству сеансов, но и по типам сервисов. Каждый рабочий сервер может обслуживать разные функции: клиентские соединения, фоновые задания, сервисы сеансовых данных, сервисы блокировок. Какой сервер что выполняет, определяется требованиями назначения функциональности (ТНФ) — правилами вида «объект требования», «тип требования» (авто, назначать, не назначать) и приоритетом.
Типовой сценарий: выделить отдельный сервер под фоновые задания, чтобы регламентные операции (обмены, расчёты, полнотекстовое индексирование) не конкурировали за ресурсы с интерактивной работой пользователей. Для этого на нужном сервере создают требование «Клиентское соединение с ИБ — не назначать», а фоновые задания оставляют в режиме «авто» или «назначать».
Другой практический приём — ограничение памяти. В свойствах рабочего процесса задают максимальный объём памяти, после которого rphost перезапускается, а также интервал перезапуска. Это защищает сервер от утечек памяти в прикладном коде, но слишком жёсткие лимиты приводят к частым перезапускам и видимым пользователям паузам.
Безопасность и лицензии в кластере
Доступ к администрированию кластера разграничивается отдельно от прав в информационных базах. В консоли администрирования заводят администраторов кластера и администраторов агента — это самостоятельные учётные записи, не связанные с пользователями 1С. Если список администраторов пуст, управлять кластером может любой, кто имеет сетевой доступ к портам, поэтому в продуктивной среде учётные записи администраторов создают обязательно.
Клиентские лицензии 1С могут раздаваться сервером 1С:Предприятия — тогда многопользовательские программные лицензии активируются на сервере кластера, и кластер выдаёт их сеансам автоматически. Серверные лицензии привязываются к аппаратным параметрам машины, поэтому при переносе кластера на другое оборудование или изменении конфигурации виртуальной машины лицензию может потребоваться активировать заново.
Сетевую безопасность обеспечивают ограничением доступа к портам 1540–1591: они должны быть открыты только между клиентами, серверами кластера и веб-серверами. Порт СУБД кластеру не нужен извне — соединение с базой инициируют только рабочие процессы с серверов 1С.
Мониторинг и типичные проблемы
Основные источники диагностики — консоль администрирования кластеров (список сеансов, соединений, блокировок), технологический журнал (ТЖ) и счётчики производительности ОС. Технологический журнал включается файлом logcfg.xml и позволяет фиксировать длительные запросы, взаимоблокировки, ошибки СУБД и события кластера. Включайте ТЖ точечно и на ограниченное время: полная запись всех событий сильно нагружает дисковую подсистему.
Характерные симптомы неполадок: рост числа сеансов при стабильном количестве пользователей (утечка сеансов или зависшие соединения), разрастание памяти отдельного rphost (тяжёлая операция или утечка в коде), очередь ожидания на блокировках (конкурентная запись в одни таблицы). Каждый из этих признаков требует своего расследования, а не автоматического перезапуска служб.
Как проверить состояние кластера
Соответствует реальному числу работающих пользователей с небольшим запасом
Сеансов в разы больше, чем пользователей — вероятны зависшие соединения
Распределена равномерно, нет процесса, стабильно растущего до лимита
Один rphost съедает память и перезапускается по лимиту
На каждом отказоустойчивом узле есть активный или резервный rmngr
Менеджер только один — отказ узла остановит кластер
Запас места есть, реестр кластера доступен
Диск заполнен — кластер и СУБД могут остановиться
Когда нужен кластер из нескольких серверов и как его развернуть
Один сервер с одним кластером справляется с небольшими внедрениями. Многосерверный кластер оправдан, когда: число одновременных пользователей исчисляется сотнями, требуется непрерывность работы при обслуживании оборудования, фоновые задания мешают интерактивной работе, либо нужно разнести нагрузку по нескольким машинам из-за лицензионных или аппаратных ограничений.
Добавление сервера в кластер выполняется через консоль администрирования: на новой машине устанавливают компоненты сервера 1С той же версии платформы, запускают агент, затем в консоли в свойствах кластера добавляют рабочий сервер и задают для него требования функциональности. После этого кластер начинает назначать новому узлу сеансы и задания автоматически.
Варианты организации сервера 1С
Подходит для небольших внедрений. Простое администрирование, но нет отказоустойчивости: остановка сервера прекращает работу всех.
Обеспечивает переживание отказа узла и распределение нагрузки. Требует настройки уровня отказоустойчивости и требований функциональности.
Для крупных внедрений с тяжёлыми регламентными операциями. Сложнее в настройке, но изолирует пользователей от фоновой нагрузки.
Что важно запомнить
Кластер 1С управляет сеансами и фоновыми заданиями через агента, менеджер и рабочие процессы. Отказоустойчивость требует минимум двух серверов и настроенного резервирования менеджера. Нагрузку разводят требованиями назначения функциональности, а данные защищают средствами СУБД и резервным копированием — кластер этого не делает.
Частые вопросы о кластере серверов 1С
Можно ли развернуть кластер 1С на одном физическом сервере?
Да, это стандартная минимальная конфигурация: агент, менеджер и рабочие процессы работают на одной машине. Такой кластер полнофункционален, но не отказоустойчив — отказ сервера остановит работу всех пользователей.
Что произойдёт с данными, если рабочий процесс rphost аварийно завершится?
Незавершённые транзакции будут откачены СУБД, данные останутся целостными. Сеансы пользователей при повторном обращении переназначатся на другие рабочие процессы; несохранённые на клиенте данные (например, незаписанный документ) могут быть утеряны.
Нужен ли отдельный кластер для тестовых баз?
Рекомендуется разделять продуктивный и тестовый контуры хотя бы разными рабочими серверами и требованиями функциональности, а лучше — отдельным кластером или сервером. Иначе тяжёлые тестовые операции будут влиять на работу пользователей.
Как перенести кластер на другой сервер?
Установите платформу той же версии на новой машине, остановите службу на старом сервере, скопируйте каталог srvinfo и перенастройте строки подключения клиентов. Учтите, что серверные лицензии привязаны к оборудованию и, скорее всего, потребуют повторной активации.
Заменяет ли кластер резервное копирование баз?
Нет. Кластер обеспечивает только непрерывность работы прикладного уровня. Резервное копирование информационных баз выполняется средствами СУБД, а конфигураций — выгрузкой в файл dt. Эти механизмы дополняют, но не заменяют друг друга.
Сколько рабочих процессов rphost запускать на сервере?
Универсального числа нет: ориентируйтесь на объём оперативной памяти и характер нагрузки. Практический подход — несколько процессов вместо одного, чтобы локализовать сбои, с лимитом памяти на процесс и контролем через консоль кластера и технологический журнал.