Кластер серверов 1С: когда одного сервера мало и что даёт кластер
Содержание
Частое заблуждение: кластер серверов 1С — это «два сервера, и если один упал, второй подхватит». Нет. Кластер 1С — это логическая единица серверной части платформы: набор процессов, которые обслуживают информационные базы. Он может целиком жить на одной машине. Отказоустойчивость появляется, когда вы осознанно добавляете второй сервер и настраиваете резервирование.
Зачем он нужен: чтобы клиент-серверная база выдерживала десятки и сотни одновременных пользователей, тяжёлые регламентные задания и закрытие месяца , не упираясь в один процесс и один сервер. Кластер распределяет сеансы и вызовы между рабочими процессами, а при нескольких серверах — между машинами.
Из чего состоит кластер и как он работает
В клиент-серверном варианте работают три типа процессов. Они запускаются службой «Агент сервера 1С:Предприятия 8.3» (ragent).
| Процесс | Что делает |
|---|---|
ragent | Агент сервера. Запускает остальные процессы, хранит список кластеров на машине. Порт по умолчанию 1540 |
rmngr | Менеджер кластера. Ведёт реестр сеансов, раздаёт клиентов по рабочим процессам, управляет блокировками. Порт по умолчанию 1541 |
rphost | Рабочий процесс. Выполняет серверный код, обращается к СУБД. Порты по умолчанию из диапазона 1560–1591 |
Клиент подключается к менеджеру кластера, тот назначает ему рабочий процесс. Дальше клиент общается именно с ним. Рабочий процесс ходит в СУБД (PostgreSQL, Microsoft SQL Server и другие) и возвращает результат.
Что важно знать:
- 🧱 Кластер — это не база и не СУБД. Данные лежат в СУБД, кластер её не заменяет и не реплицирует.
- 🧩 Один кластер обслуживает много информационных баз.
- 🖥 Один сервер может держать несколько кластеров, но обычно на машине их один.
- ⚙️ На разных рабочих серверах кластера работают свои
rphost, а менеджер кластера один главный (плюс резервные, если настроено).
Если порты по умолчанию заняты или закрыты межсетевым экраном, клиент не подключится, даже когда служба запущена. Проверяйте не только службу, но и доступность портов 1540, 1541 и диапазона рабочих процессов с клиентских машин.
Что даёт кластер: производительность и масштаб
Главный выигрыш — параллелизм. Файловая база обслуживается тем клиентом, который к ней обратился, а в клиент-серверной серверный код исполняют рабочие процессы. Их можно нарастить.
На практике это даёт:
- 🚀 Тяжёлые операции (проведение пакета документов, закрытие месяца, обмены) не блокируют интерфейс остальных пользователей: они идут в других процессах.
- 📦 Нагрузка делится по процессам. Один «зависший» вызов не останавливает работу остальных сеансов.
- 💾 Память делится между процессами. Лимит на адресное пространство одного процесса перестаёт быть узким местом.
- 🧮 Фоновые и регламентные задания можно выделить на отдельный сервер, чтобы они не мешали людям днём.
Кластер не ускорит запрос, который тормозит из-за плохого плана в СУБД или блокировок на уровне данных. Если база «думает» по 40 секунд на одном отчёте, добавление рабочих серверов ничего не изменит. Сначала смотрят СУБД, индексы, обслуживание и транзакции.
Балансировка: как кластер распределяет нагрузку
Распределение идёт на двух уровнях.
Сеансы между рабочими процессами. Менеджер кластера выбирает процесс по критерию, который задан в свойствах кластера. Два режима:
- Приоритет по производительности. Выбирается процесс на сервере с лучшей оценкой производительности.
- Приоритет по памяти. Выбирается процесс на сервере, где больше свободной памяти.
Режим задают в свойствах кластера в консоли администрирования серверов. Там же есть параметр допустимого отклонения производительности: пока разница между серверами меньше этого значения, они считаются равными.
Серверные вызовы между серверами. Каждый вызов клиента — это отдельная операция. Платформа может отправить следующий вызов того же сеанса на другой рабочий процесс. Поэтому нельзя хранить в серверной глобальной переменной данные «на потом»: следующий вызов может прийти на другой процесс, где их нет.
Назначение функциональности
Вручную направлять нагрузку помогают требования назначения функциональности. Их задают в свойствах рабочего сервера: Кластер → Рабочие серверы → нужный сервер → «Требования назначения функциональности». Там указывают, какой сервер за что отвечает. Типичные варианты:
- интерактивные сеансы клиентов на одних серверах, фоновые задания на других;
- веб-сервисы и HTTP-сервисы на отдельном сервере;
- сервис блокировок (в новых версиях — сервис сеансов и блокировок) на самом быстром сервере.
Так вы изолируете тяжёлые регламентные задания от пользователей, не покупая «умный» балансировщик.
Отказоустойчивость: что кластер переживёт, а что нет
Здесь больше всего недоразумений. Разберём по слоям.
| Что вышло из строя | Что будет при одном сервере | Что будет при кластере из нескольких серверов |
|---|---|---|
Рабочий процесс rphost | Сеансы на нём прерываются, менеджер запускает новый | То же: прерываются только сеансы этого процесса |
| Рабочий сервер целиком | База недоступна | Работают другие рабочие серверы, сеансы с упавшего прерываются |
| Главный менеджер кластера | База недоступна | Недоступна, если нет резервирования менеджера |
| СУБД | База недоступна | База недоступна, кластер её не защищает |
Выходит, что кластер сам по себе защищает от выхода из строя рабочего сервера и «упавшего» процесса. Но менеджер кластера и СУБД остаются единой точкой отказа, пока вы не закроете их отдельно.
Уровень отказоустойчивости кластера
В свойствах кластера есть параметр «Уровень отказоустойчивости». Он задаёт, сколько рабочих серверов может отказать одновременно без прерывания работы кластера. Резервирование сервисов кластера работает между серверами, у которых включён флаг «Центральный сервер». Данные сеансов реплицируются на резервные центральные серверы, поэтому при отказе главного сервера сеансы на остальных серверах продолжают работу.
Условия:
- серверы кластера в одной быстрой сети;
- на каждом рабочем сервере запущен агент сервера;
- версии платформы на всех серверах совпадают до последней цифры.
Резервирование кластера не заменяет резервирование СУБД. Для защиты данных нужны отдельные механизмы СУБД: репликация, зеркалирование или групповые решения. Они настраиваются на стороне СУБД и платформа 1С в них не участвует.
Масштабирование: вертикальное и горизонтальное
Есть два пути, и начинать почти всегда стоит с первого.
Вертикальный рост. Больше ядер, памяти и быстрее диски на одном сервере. Просто, не требует перестройки архитектуры. Подходит, пока вы не упёрлись в потолок железа.
Горизонтальный рост. Добавляете рабочий сервер в кластер. Платформа сама начнёт отправлять на него новые сеансы по выбранной политике балансировки.
Ориентиры для первой оценки (грубые, зависят от конфигурации и нагрузки):
- до нескольких десятков пользователей — один сервер, один кластер, достаточно памяти и быстрого диска под СУБД;
- сотня и более активных пользователей, тяжёлые отчёты, обмены — стоит разнести на два сервера: СУБД отдельно, сервер приложений отдельно;
- несколько сотен пользователей и требования к простою — кластер из нескольких рабочих серверов, резервирование менеджера и отказоустойчивая СУБД.
СУБД и сервер приложений на одной машине быстро начинают конкурировать за память. Разделение их по разным серверам обычно даёт больше, чем второй рабочий сервер кластера.
Типовые схемы развёртывания
Самая распространённая рабочая схема в средней компании выглядит так:
- Сервер СУБД: много оперативной памяти, быстрые SSD, отдельные диски под данные и журнал транзакций.
- Один или два сервера приложений 1С с кластером.
- Веб-сервер (Apache или IIS) для публикации веб-клиента и сервисов, часто на отдельной машине.
- Отдельный сервер лицензий или аппаратные ключи, доступные с серверов кластера.
Сложности администрирования и мониторинг
Кластер даёт гибкость и требует дисциплины. Чем больше серверов, тем больше то, что надо синхронизировать.
С чем сталкиваются чаще всего:
- 🔧 Одинаковые версии платформы на всех серверах кластера. Разные номера — повод получить непредсказуемое поведение.
- 🔐 Учётные записи служб: пользователь, под которым работает агент сервера, должен иметь права на каталоги кластера и на нужные ресурсы.
- 🧾 Лицензии. Серверные лицензии привязаны к ключам; при добавлении сервера проверьте, откуда он берёт лицензию.
- 🧹 Рост кэшей и журналов: каталоги кластера и технологический журнал забивают диск, если не настроить хранение.
- 📊 Утечки памяти рабочих процессов: в свойствах кластера задают интервал перезапуска и допустимый объём памяти, чтобы процесс периодически пересоздавался.
Что смотреть в консоли
Консоль администрирования серверов показывает:
- рабочие серверы и их процессы: сколько памяти занимает каждый, сколько соединений и сеансов;
- список сеансов и соединений: кто и на каком процессе работает;
- блокировки: какая транзакция кого ждёт;
- свойства кластера: политика балансировки, перезапуск процессов, лимиты памяти.
Из командной строки можно использовать утилиту администрирования кластера rac. Утилита работает только через сервер администрирования ras: сначала запустите его (ras cluster --daemon) или установите как службу. Затем выполните rac cluster list, возьмите UUID кластера и передайте его в следующие команды: rac session list --cluster=<uuid>. Остальные команды смотрите в справке rac help.
Перед тем как останавливать службу, завершать рабочий процесс или перезагружать сервер, предупредите пользователей: все их сеансы на этом процессе оборвутся, несохранённые данные пропадут. Делайте это вне рабочего времени.
Технологический журнал
Для разбора «тормозов» в кластере удобнее всего технологический журнал: он показывает долгие вызовы, взаимоблокировки и ожидания на блокировках. Включать его надо точечно, с фильтром по событиям: подробный журнал сам создаёт нагрузку и быстро занимает диск.
Частые ошибки и как их избежать
Что чаще всего идёт не так при построении кластера.
- Ждут «кластер из двух серверов = отказоустойчивость». Отказ рабочего сервера без центральных сервисов работу не остановит. Но отказ центрального сервера без резервирования (второго центрального сервера и уровня отказоустойчивости больше нуля) останавливает кластер, а отказ СУБД — всегда.
- СУБД на одной машине с сервером приложений при нескольких сотнях пользователей. Память делится не в вашу пользу; сначала разнесите роли.
- Разные версии платформы на узлах. Обновляйте все серверы кластера одним окном обслуживания.
- Слишком много рабочих процессов на сервер. Каждый процесс держит свою память. Количество процессов подбирают под объём ОЗУ, а не «чем больше, тем лучше».
- Слишком много информационных баз на один рабочий процесс. Один тяжёлый запрос в одной базе задевает остальные базы на этом процессе.
- Не проверили сеть. Между серверами кластера и между приложением и СУБД нужна быстрая и стабильная связь. Задержки в сети дают медленные вызовы, которые выглядят как «тормоза 1С».