Главная / Документация / НаблюдениеКластер: схема, узлы и предупрежденияЭкран «Кластер» в volrix.pm: схема серверов и связей, роли PostgreSQL, кворум etcd, предупреждения с действиями и как добавить узел в кластер.Обновлено 16.10.2026Экран «Кластер» показывает, из чего состоит установка и в каком она состоянии: серверы, балансировщики, узлы приложения, серверы PostgreSQL и etcd, кто держит общий адрес, какой сервер базы основной и что требует внимания администратора. Экран только наблюдает: ничего не меняет и не перезапускает.«Администрирование» → «Наблюдение» → «Кластер».Пункт меню и экран открываются с правом dashboard.read («Дашборд системы» → «Просмотр дашборда») - тем же, что у «Состояния системы». По умолчанию оно есть только у администратора системы.Установка на одном сервереЕсли система установлена на один сервер, экран показывает синюю врезку «Установка на одном сервере»: отказоустойчивости нет, и при остановке сервера система недоступна до его возвращения. Ниже - карточка сервера: сколько процессов backend работает, их версия и время работы. Число процессов задает настройка WEB_WORKERS - см. Эксплуатация нескольких процессов и серверов.Кластер - минимум три сервера, на каждом приложение, PostgreSQL с синхронной репликацией и балансировщик с общим адресом. Разворачивается мастером установки, вариант «Отказоустойчивый кластер» - см. Установка. Готовую установку на один сервер сменой архитектуры в мастере в кластер не перевести: нужен перенос данных.Из чего состоит кластер

Слой

Что это

Порт

Балансировка

HAProxy и keepalived на серверах с ролью балансировщика. Принимают запросы пользователей по HTTPS и распределяют их по узлам приложения. Общий виртуальный адрес держит один балансировщик, остальные в резерве.

443, с 80 перенаправление на 443

Приложение

Веб-интерфейс и backend. Состояние общее для всех узлов, поэтому пользователь может попасть на любой.

8080

Прокси к БД

Локальный HAProxy на каждом узле приложения. Раз в секунду спрашивает Patroni, какой сервер БД основной, и ведет соединения туда; при смене основного обрывает старые соединения.

127.0.0.1:6432

PostgreSQL

Серверы базы под управлением Patroni: основной, синхронная и асинхронная реплики.

5432

etcd

Хранит, какой сервер БД сейчас основной. Решение принимает большинство узлов, поэтому серверов БД нечетное число.

2379

Данные для экрана раз в 20 секунд собирает ведущий планировщик: опрашивает балансировщики, узлы приложения (проверка /api/v1/ready), Patroni и etcd. Экран перечитывает снимок тоже раз в 20 секунд и по кнопке «Обновить». Рядом с адресом системы написано, насколько данные свежие, например «Данные 12 с назад».Сводка и общий статусВверху - значок общего состояния: «Все в порядке», «Есть предупреждения» или «Нужны действия» (есть хотя бы одно красное предупреждение), имя кластера и адрес системы. Под ним плитки сводки. Плитка, требующая внимания, выделена красным.

Плитка

Что показывает

«Серверов»

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

«Адрес держит»

Какой балансировщик сейчас держит виртуальный адрес; «внешний» - если перед кластером ваш балансировщик

«Узлов приложения»

Сколько узлов готово из общего числа, например «3 из 3»

«Процессов»

Сколько процессов backend прислали отметку о работе (отметка обновляется раз в 15 секунд)

«Основной сервер БД»

Сервер PostgreSQL, который принимает запись; «нет» - запись невозможна; «внешний» - база вне кластера

«Реплики»

Число синхронных и асинхронных реплик, например «1 синхр., 1 асинхр.»

«Кворум etcd»

Сколько узлов etcd отвечает из общего числа

Вид «Схема»Переключатель «Схема» / «Узлы» - справа над сводкой. «Схема» рисует архитектуру: колонки - серверы, строки - слои «Балансировка», «Приложение», «Прокси к БД», «PostgreSQL», «etcd»; сверху «Пользователи» и виртуальный адрес. Провода показывают реальные пути, легенда под схемой:

«рабочий путь запроса» - от балансировщика, который держит адрес, к узлам приложения и через прокси к основному серверу БД;

«резерв, вступает при отказе» - резервные балансировщики, пунктиром;

«синхронная репликация» и «асинхронная репликация» - дуги между серверами PostgreSQL;

«кворум etcd» и «Patroni и etcd» - служебные связи серверов БД;

«нет связи» - все, что не отвечает, рисуется красным.

Наведение на элемент подсвечивает его связи, щелчок открывает подробности под схемой:

Элемент

Что в подробностях

Виртуальный адрес

«Адрес», «Держит», «Ответ», «Протокол» (VRRP, keepalived). Если балансировщик пропадает, keepalived за несколько секунд переносит адрес на следующий

Балансировщик

Адрес, состояние, время ответа и роль: держит виртуальный адрес или в резерве

Узел приложения

Адрес, состояние, время ответа, число процессов и таблица процессов: «PID», «Версия», «Образ», «Работает», «Роль» - «планировщик» у ведущего, «запросы» у остальных

PostgreSQL

«Роль» (основной, синхронная или асинхронная реплика), «Состояние», «Версия», «Линия времени», «Отставание», «Перезапуск»

etcd

Состояние и «Кворум», например «2 из 3 (нужно 2)»

Вид «Узлы»Те же элементы карточками по слоям - удобно прочитать адреса подряд: «Точка входа» (виртуальный адрес, порт 443, кто держит и время ответа), «Балансировщики» (отметка «держит адрес»), «Приложение» (число процессов, версия, время работы; узел с ведущим планировщиком отмечен значком «планировщик»), «PostgreSQL» (роль, отставание в байтах, «ждет перезапуска»), «etcd». Цветная полоса слева - состояние: зеленая - в порядке, желтая - требует внимания (например, узел отвечает, но живых процессов нет), красная - не отвечает.Предупреждения и что делатьПредупреждения выводятся над схемой. Красные мешают работе пользователей или грозят потерей данных, желтые снижают запас прочности, синие - для сведения.

Предупреждение

Что значит и что сделать

«Узлов N: отказоустойчивому кластеру нужно минимум три.»

Кластер из одного-двух серверов не переживет отказ. Добавьте серверы - раздел ниже.

«Виртуальный адрес ... не отвечает - пользователи не могут войти.»

Ни один балансировщик не держит адрес или HAProxy не отвечает. Проверьте, что серверы-балансировщики включены и на них работают контейнеры volrix-haproxy и volrix-keepalived: docker ps.

«Балансировщик ... не отвечает»

Сервер выключен или остановлен volrix-haproxy. Адрес держит другой балансировщик, но резерва меньше. Верните сервер.

«Узел приложения ... не готов»

Узел не проходит проверку готовности: выключен, остановлен volrix-backend или volrix-web, либо backend не видит базу. Балансировщики сами выводят такой узел из ротации. На узле смотрите docker logs volrix-backend.

«Ни один узел приложения не готов.»

Система недоступна. Чаще всего причина в базе: посмотрите плитку «Основной сервер БД» и предупреждения про etcd.

«Нет основного сервера PostgreSQL - запись невозможна.»

Patroni не может выбрать основной сервер: недоступны серверы БД или нет кворума etcd. Верните серверы БД - выбор основного произойдет сам.

«Нет синхронной реплики: ...»

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

«PostgreSQL на ...: состояние «...»»

Сервер БД не в рабочем состоянии, например запускается или догоняет основной. Если не проходит за несколько минут, смотрите docker logs volrix-patroni на этом сервере.

«Реплика ... отстает на N МБ.»

Отставание больше 16 МБ: реплика не успевает за основным сервером, обычно из-за сети или диска.

«PostgreSQL на ... ждет перезапуска для применения настроек.»

Синее, работа не нарушена: изменены параметры, которые вступают в силу после перезапуска. Перезапускайте серверы БД только по одному.

«etcd без кворума (1 из 3): переключение основного сервера БД невозможно.»

Отвечает половина узлов etcd или меньше. Верните серверы БД или контейнер volrix-etcd на них.

«etcd: работает 2 из 3 - еще один отказ остановит переключения.»

Один узел etcd выпал. Верните его, пока не случился второй отказ.

«Узлов etcd четное число (4): ...»

Четвертый узел не добавляет надежности. Держите нечетное число серверов БД.

«Разные версии приложения на узлах: ...»

Обновление прошло не на всех узлах. Если обновление сейчас не идет, повторите его - Обновление.

«Разные образы приложения на узлах (идет обновление?): ...»

Синее. Нормально во время обновления: узлы обновляются по одному.

«На узле ... нет живых процессов приложения.»

Процессы backend на узле не присылают отметку о работе. На узле: docker ps и docker logs volrix-backend.

«Нет ведущего планировщика: фоновые задачи не выполняются.»

Ночные копии, почта и напоминания стоят. Ведущий обычно находится за секунды после запуска; если предупреждение держится, смотрите в журналах volrix-backend строки «Планировщик: ...» - см. Эксплуатация нескольких процессов и серверов.

Добавить узелВ кластере в шапке экрана есть кнопка «Добавить узел». Она открывает окно «Добавить узел в кластер» с инструкцией и готовым фрагментом volrix-cluster.yml: список текущих узлов и строка нового узла node-N с ролью app. Кнопка «Копировать фрагмент» копирует его.

Подготовьте сервер Astra Linux 1.8, РЕД ОС 8 или Ubuntu 24.04; от 2 vCPU и 4 ГБ памяти (для Astra - диск от 50 ГБ); та же сеть, что у остальных узлов; синхронизация времени. Подробнее - Подготовка сервера.

Решите, какие роли нужны Роль app - еще один узел приложения: после развертывания он сразу войдет в ротацию балансировщиков. Узлы с ролью db добавляйте так, чтобы серверов БД оставалось нечетное число.

Разверните через мастер Если кластер ставили мастером: на новом сервере выполните команду присоединения с шага «Узлы», проверьте узел и нажмите «Развернуть». Мастер ставит на каждый сервер все роли - балансировщик, приложение и БД, поэтому через мастер добавляйте серверы по два.

Или по файлу Узел только с приложением добавляется в volrix-cluster.yml (у мастера файл лежит в /opt/volrix-installer/work/) строкой из окна, затем volrix-cluster apply volrix-cluster.yml. Работающие узлы не перезапускаются, новый проходит проверки и подключается.

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

Если не получается

Что видно

Причина и что сделать

Нет пункта «Кластер» в меню

У роли нет права dashboard.read. Выдайте его в Роли и права.

«Не удалось получить состояние кластера»

Backend не ответил на запрос. Нажмите «Обновить»; если ошибка повторяется, проверьте /api/v1/ready - см. Мониторинг.

Серверов три, а экран показывает «Установка на одном сервере»

Узел приложения не получил описание кластера - оно записывается при развертывании. Повторите развертывание из мастера.

«Данные N мин назад» и цифры не меняются

Снимок собирает ведущий планировщик. Проверьте предупреждение «Нет ведущего планировщика» и журналы volrix-backend на узлах приложения.

Сервер на схеме красный, а пользователи работают

Опрос идет с узла ведущего планировщика, а не с вашего компьютера: проверьте сеть и межсетевой экран между ним и этим сервером (порты 8080, 443, 2379 и 8008).

Нет кнопки «Добавить узел»

Кнопка есть только в кластере. Установку на один сервер так не расширить.

Несколько процессов и серверов

Установка volrix.pm

Мониторинг

Ведущий планировщик, лицензия в базе, переключение БД и копии в кластереМастер установки: один сервер или отказоустойчивый кластерСамодиагностика, проверки health и ready, метрики и журналы

Администрирование: обзор области