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

Цель¶

Обеспечение непрерывной работы сервера 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'

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

rude restart

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

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

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

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

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

Конфигурация компонентов¶

Redis используется несколькими компонентами RuDesktop, поэтому его адрес должен быть прописан в двух местах:

Для relay/rz: В файле /etc/rudesktop-relay.toml укажите параметр:

redis_server = "redis://<address>:<port>"
# или с аутентификацией
redis_server = "redis://:<password>@<address>:<port>"

Для web/backend: В файле /etc/default/rudesktop задайте переменную:
```
REDIS_URL="redis://<address>:<port>"
# или с аутентификацией
REDIS_URL="redis://:<password>@<address>:<port>"
```
REDIS_URL должен указывать на тот же инстанс Redis, что и redis_server

Активация конфигурации Relay¶

Чтобы компонент relay использовал файл конфигурации, в /etc/default/rudesktop на каждом узле должна быть задана переменная:

RELAY_ARGS='-C /etc/rudesktop-relay.toml'

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

rude restart

Безопасность Redis¶

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

Настроить привязку (bind) только к необходимым интерфейсам
Обязательно установить пароль (requirepass в конфигурации Redis)
Ограничить доступ правилами межсетевого экрана, разрешающими соединения только с IP-адресов узлов RuDesktop

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

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

PostgreSQL: Проверьте подключение с узла RuDesktop (например, с помощью psql или nc)
Redis: Убедитесь, что компоненты видят общий кэш. Проверить можно командой redis-cli -h <host> -p <port> -a <password> PING
Внутренняя синхронизация: Убедитесь, что сессии пользователей, созданные на одном узле, видны на другом (через общий 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_*
При необходимости настройте 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 — устройства должны автоматически переподключиться к другим узлам
Имитируйте отказ кластера PostgreSQL (переключение Primary) — RuDesktop должен продолжить работу после кратковременного перерыва в соединении
Имитируйте отказ Redis — в этом случае работа будет нарушена, что подтверждает его критичность