Развертывание отказоустойчивого кластера¶

Развертывание отказоустойчивого кластера — инструкция по установке нескольких серверов RuDesktop в режиме высокой доступности (HA) с общими PostgreSQL и Redis, балансировкой нагрузки и автоматическим переключением при отказе узла или целой площадки

Цель¶

Обеспечение непрерывной работы сервера RuDesktop при отказе одного узла или целой площадки (ЦОД)

Количество узлов RuDesktop может быть 2, 3 или более (N)
Данные (состояние, конфигурация, сессии) должны быть общими для всех узлов

Под общими данными понимаются:

PostgreSQL — основное хранилище постоянных данных (пользователи, группы, устройства, настройки)
Redis — общий кэш, хранилище состояний и механизм внутренней синхронизации компонентов

Термины¶

Failover — процесс автоматического или регламентного переключения нагрузки с отказавшего узла/площадки на работоспособный
Active-Active — схема, при которой все узлы одновременно обрабатывают пользовательский трафик
Active-Passive — схема, при которой один узел (активный) обрабатывает трафик, а другие (пассивные) находятся в режиме горячего или холодного резерва
Требования к RPO/RTO — выбор архитектуры зависит от допустимого времени восстановления (RTO) и потери данных (RPO)

Референс-архитектура¶

Внешний вход (WAN)¶

Пользователи подключаются к единой точке входа по TLS 443 (HTTPS/WSS). Реализация может быть одной из двух:

Через интеллектуальный балансировщик (гео-балансировщик), который на основе health-чеков направляет трафик только на доступные узлы (предпочтительно для схемы Active-Active)
Через регламентный failover (Active-Passive) — переключение маршрута, DNS-записи или правил балансировщика вручную по инструкции

Важно

Стандартный DNS Round-Robin не является отказоустойчивым решением, так как не проверяет доступность узлов

Узлы RuDesktop¶

На каждой физической или виртуальной площадке развёртывается полный набор компонентов RuDesktop:

RuDesktop server (web-интерфейс, административная панель, backend-логика)
Nginx (обработка TLS/SSL, проксирование WebSocket-соединений)
relay/rz (компоненты для установки и поддержания пользовательских соединений)

Примечание

В стандартной сборке RuDesktop Server уже включены встроенные инстансы PostgreSQL, Redis и nginx. Однако в отказоустойчивой схеме эти компоненты выносятся и становятся общими для всех узлов кластера

Общие данные (Shared Storage)¶

В отказоустойчивой конфигурации компоненты, которые обычно работают локально, становятся общими:

PostgreSQL — единый кластер БД, доступный всем узлам RuDesktop (вместо встроенной локальной БД)
Redis — единый кластер или инстанс Redis, доступный всем узлам RuDesktop (вместо встроенного локального Redis)

Сетевые требования¶

Канал между узлами RuDesktop и общими сервисами (PostgreSQL/Redis):
- Пропускная способность: не менее 1 Gbit/s
- Задержка (latency): должна быть минимально возможной (практический ориентир — менее 1 мс). Redis критически чувствителен к задержкам
Безопасность доступа:
- Доступ к портам PostgreSQL и Redis должен быть разрешён только с IP-адресов узлов RuDesktop (или их подсетей)
- Использование межсетевых экранов (firewall) и механизмов контроля доступа (например, pg_hba.conf в PostgreSQL, bind и requirepass в Redis) обязательно

Подключение внешней PostgreSQL¶

Принцип работы с кластером БД¶

RuDesktop не управляет репликацией и отказоустойчивостью PostgreSQL. Администрирование кластера (Patroni, streaming replication, managed cloud database) — зона ответственности администраторов СУБД

RuDesktop подключается к единой точке входа (endpoint), которая всегда указывает на текущий первичный узел (Primary) БД

Это может быть:

Виртуальный IP-адрес (VIP)
DNS-имя (FQDN), переключаемое при смене Primary
Специализированный прокси (HAProxy, PgBouncer) перед кластером

Конфигурация подключения на узле RuDesktop¶

Подключение настраивается в файле /etc/default/rudesktop на каждом узле с помощью переменных окружения:

POSTGRES_HOST='hostname_or_ip'
POSTGRES_PORT='port'
POSTGRES_DB='database_name'
POSTGRES_USER='username'
POSTGRES_PASSWORD='password'

Важно

В шаблоне /etc/default/rudesktop, формируемом при установке сервера, переменная POSTGRES_USER отсутствует — её нужно добавить вручную при подключении к внешней БД. Для встроенного PostgreSQL по умолчанию используется пользователь rudesktop

Примечание

Если POSTGRES_PORT не указан — используется стандартный порт PostgreSQL 5432

После внесения изменений необходимо перезапустить сервер:

rude restart

Подключение с использованием SSL/TLS¶

Для безопасного подключения добавьте в /etc/default/rudesktop следующие параметры:

POSTGRES_SSL_MODE=verify-ca  # или require
POSTGRES_CA_FILE=/path/to/ca.crt

Разместите CA-сертификат по указанному пути на каждом узле
После внесения изменений необходимо перезапустить сервер:
rude restart

Подсказка

Допустимые значения POSTGRES_SSL_MODE: disable, allow, prefer, require, verify-ca

Подключение внешнего Redis¶

Подключение настраивается так же, как для одиночного сервера — см. Настройка Redis. Параметры redis_server (в /etc/rudesktop-relay.toml) и REDIS_URL (в /etc/default/rudesktop) должны указывать на один и тот же общий инстанс Redis на каждом узле кластера

Важно

Специфика кластера:

Параметры redis_server, REDIS_URL и RELAY_ARGS должны быть идентичными на всех узлах RuDesktop — иначе компоненты будут работать с разными хранилищами кеша и сессий
Общий инстанс Redis становится единой точкой отказа: рекомендуется развернуть его в отказоустойчивой конфигурации (Sentinel/Cluster) или с горячим резервом
Доступ к Redis должен быть закрыт правилами файрвола и защищён requirepass (см. раздел «Безопасность» на странице Настройка Redis)

Проверка связности и состояния¶

После настройки убедитесь в корректности работы:

PostgreSQL: Проверьте подключение с узла RuDesktop (например, с помощью psql или nc)
PGPASSWORD=<password> psql -h <host> -p <port> -U <user> -d <db> -c "SELECT 1"
Redis: Убедитесь, что компоненты видят общий кэш. Проверить можно командой:
redis-cli -h <host> -p <port> -a <password> PING
Ожидаемый ответ — PONG
Внутренняя синхронизация: Убедитесь, что сессии пользователей, созданные на одном узле, видны на другом (через общий Redis)

Единые параметры на всех узлах RuDesktop¶

Для работы в едином контуре все узлы должны иметь идентичные ключевые параметры:

В файле ``/etc/default/rudesktop``:
- SECRET_KEY — должен быть одинаковым на всех узлах
- REDIS_URL — должен указывать на один и тот же инстанс Redis
- RELAY_ARGS — должен быть идентичным
В файле ``/etc/rudesktop-relay.toml``:
- redis_server — должен указывать на один и тот же инстанс Redis

Назначение конфигурационных файлов¶

/etc/default/rudesktop — переменные окружения и общие параметры запуска для web/backend компонентов (включая строки подключения к PostgreSQL и Redis, RELAY_ARGS)
/etc/rudesktop-relay.toml (и другие .toml файлы в /etc/rudesktop/) — конфигурация низкоуровневых компонентов (relay, rz и др.)

Пошаговый план внедрения¶

Шаг 1. Определение архитектуры¶

Выбор схемы: Active-Active или Active-Passive
Определение места размещения и архитектуры кластеров PostgreSQL и Redis

Шаг 2. Подготовка сетевой инфраструктуры¶

Обеспечьте сетевое взаимодействие:

RuDesktop узлы ↔ Кластер PostgreSQL
RuDesktop узлы ↔ Кластер Redis
Пользователи ↔ Точка входа (балансировщик) на 443/TLS порт

Шаг 3. Подключение внешней PostgreSQL¶

На каждом узле RuDesktop:

Создайте резервную копию текущей базы данных перед изменениями (см. Резервное копирование)
Отредактируйте /etc/default/rudesktop, задав параметры POSTGRES_* (включая POSTGRES_USER)
При необходимости настройте SSL
Выполните rude restart

Шаг 4. Подключение внешнего Redis¶

На каждом узле RuDesktop:

Отредактируйте /etc/rudesktop-relay.toml, задав redis_server
Отредактируйте /etc/default/rudesktop, задав REDIS_URL и RELAY_ARGS
Выполните rude restart

Шаг 5. Унификация секретов и параметров¶

Убедитесь, что на всех узлах идентичны:

SECRET_KEY
REDIS_URL
redis_server
RELAY_ARGS

Шаг 6. Настройка внешнего входа (WAN)¶

Для Active-Active: Настройте балансировщик с health-чеками на доступность узлов
Для Active-Passive: Подготовьте процедуру регламентного переключения (DNS, правила балансировщика)

Шаг 7. Защита сервисов данных¶

Настройте правила файрвола для PostgreSQL и Redis, разрешающие доступ только с подсетей узлов RuDesktop
Для Redis обязательно установите стойкий пароль

Шаг 8. Тестирование отказоустойчивости¶

Проведите плановые тесты:

Отказ узла RuDesktop. Остановите один узел и убедитесь, что устройства автоматически переподключаются к другим узлам, а пользовательские сессии не прерываются
Переключение Primary в PostgreSQL. Имитируйте отказ кластера БД (переключение Primary) и убедитесь, что RuDesktop возобновляет работу после кратковременного перерыва в соединении — без ручных действий
Отказ Redis. Имитируйте недоступность общего инстанса Redis и зафиксируйте время восстановления после возврата сервиса. Redis является единой точкой отказа кластера — на основании результатов теста спланируйте его развёртывание в отказоустойчивой конфигурации (Sentinel, Cluster) или с горячим резервом