Отказоустойчивость в Termit
Схема развертывания
Команда Orion soft разработала архитектуру с взаимодействием со смежными системами:
Рис. 1 - Схема развертывания.
В таблице 1 приведен перечень сетевых компонентов и соответствующих им атрибутов, используемых в статье для развертывания и тестирования отказоустойчивости системы Termit.
Таблица 1. Компоненты, их FQDN и адреса.
Обзор тестирования отказоустойчивости
Мы провели комплексное тестирование отказоустойчивости различных компонентов системы Termit:
- Брокеры: Мы установили несколько брокеров (1.2.1 Установка первого брокера, 1.2.3 Установка второго брокера), сконфигурировали балансировщик нагрузки HAProxy, настроили страницу статистики для балансировщика (1.2 Брокеры. Балансировщик.), и убедились в стабильной работе брокеров даже при отключении одного из них (Отказоустойчивость - Брокеры). Результаты тестирования подтвердили, что балансировщик успешно маршрутизирует трафик на доступные брокеры, обеспечивая непрерывную работу системы.
- База данных: Мы настроили кластер PostgreSQL (1.1 База данных. Установка кластера PostgreSQL) и проверили его поведение при отключении одной из нод (Отказоустойчивость - База данных). Система успешно продолжала обрабатывать запросы, демонстрируя высокую отказоустойчивость и способность поддерживать работоспособность при частичных сбоях.
- Терминальные серверы: Мы настроили терминальные серверы и создали группу серверов (1.3 Установка на терминальные серверы, 2.3 Создание группы серверов). Мы проверили отказоустойчивость терминальных сессий двумя способами: аварийно отключив все брокеры (3.3 Терминальные серверы при отказе всех брокеров) и один из терминальных серверов (Отказоустойчивость - Терминальные серверы), мы убедились, что сессии продолжают создаваться и обслуживаться на оставшихся серверах. Это подтвердило надежность и отказоустойчивость механизма управления терминальными сессиями.
- Шлюзы: Мы настроили шлюзы удаленного доступа (1.4 Установка шлюзов удаленного доступа) и HAProxy для балансировки нагрузки на шлюзы (1.5 Установка балансировщика нагрузки для шлюзов удаленного доступа). Мы проверили отказоустойчивость шлюзов, выключив один из них, и убедились, что балансировщик автоматически перенаправляет трафик на работающий шлюз, обеспечивая непрерывную работу системы (Отказоустойчивость - Шлюзы).
- LDAP: Установив несколько контроллеров домена и настроив их для синхронизации (2.1 Подключение каталога + назначение ролей), мы проверили работоспособность Termit при отключении одного из них (Отказоустойчивость - LDAP). Результаты тестирования показали, что система успешно переключается на работающий контроллер, обеспечивая непрерывный доступ к данным и функционалу.
Проведенное тестирование подтверждает способность Termit успешно справляться с отключением отдельных узлов, таких как брокеры, база данных, терминальные серверы, шлюзы и LDAP. Termit демонстрирует способность поддерживать непрерывную работу даже при частичных сбоях и обеспечивать стабильный доступ к данным и функциям для пользователей.
1. Подготовка стенда
1.1 База данных. Установка кластера PostgreSQL
1.1 База данных. Установка кластера PostgreSQL
- машина администратора, с которой будет запускаться плейбук Ansible;
- три сервера с Debian 12, которые будут нодами нашего кластера;
- для подключения к БД – имя orion-db.termit.corp, которое будет соответствовать виртуальному ip 10.250.107.125, размещенному на текущем мастер-узле кластера БД.
1.1.1 Ноды кластера
Подключаемся на первую машину с ролью базы данных (FQDN машины – orion-db01.termit.corp).
1. Получаем полноценный доступ к учетной записи root командой:
su -
2. Проверяем информацию о текущей конфигурации кластера PostgreSQL, управляемого Patroni, с помощью команды:
patronictl list
В этой конфигурации мастер-нода (orion-db01) выполняет роль лидера и принимает записи, а ноды 2 (orion-db02) и 3 (orion-db03) являются репликами данных, поддерживая актуальное состояние базы данных в соответствии с мастером.
Таким образом, мы настроили высокодоступный кластер PostgreSQL, где мастер-нода обеспечивает запись данных, а реплики гарантируют доступность и надежность системы.
Переходим к подготовке нод кластера для использования Termit.
3. Запускаем сессию служебного пользователя postgres и командную оболочку postgres, последовательно выполнив команды:
sudo su - postgres
psql
4. При установке брокера будет выбрана опция "создать новую базу данных", поэтому создаем нового пользователя с паролем и правами на создание новых баз данных с помощью команды
CREATE USER orion WITH PASSWORD 'Termit21' CREATEDB;
1.2 Брокеры. Балансировщик.
1. Устанавливаем ПО HAProxy с помощью команды:
sudo dnf install haproxy
2. Включаем службу haproxy и добавляем автозагрузку с помощью команды:
sudo systemctl enable haproxy --now
3. Открываем файл конфигурации /etc/haproxy/haproxy.cfg для редактирования командой:
sudo nano /etc/haproxy/haproxy.cfg
4. Добавляем в конец файла конфигурации /etc/haproxy/haproxy.cfg настройку серверов для балансировки:
frontend termit
mode tcp
bind :80
default_backend termit_servers
backend termit_servers
option httpchk
http-check connect port 8080
http-check send meth GET uri /
mode tcp
balance source
hash-type consistent
server orion-br01.termit.corp 10.250.107.111:80 check
server orion-br02.termit.corp 10.250.107.112:80 check
frontend termit_https
mode tcp
bind :443
default_backend termit_servers_https
backend termit_servers_https
option httpchk
http-check connect port 8080
http-check send meth GET uri /
mode tcp
balance source
hash-type consistent
server orion-br01.termit.corp 10.250.107.111:443 check
server orion-br02.termit.corp 10.250.107.112:443 check
frontend termit_8443_https
mode tcp
bind :8443
default_backend termit_servers_8443_https
backend termit_servers_8443_https
option httpchk
http-check connect port 8080
http-check send meth GET uri /
mode tcp
balance source
hash-type consistent
server orion-br01.termit.corp 10.250.107.111:8443 check
server orion-br02.termit.corp 10.250.107.112:8443 check
где orion-br01.termit.corp – FQDN первого шлюза, 10.250.107.111 – адрес машины с FQDN orion-br01.termit.corp, orion-br02.termit.corp – FQDN второго шлюза, 10.250.107.112 – адрес машины с FQDN orion-br02.termit.corp.
5. Для настройки страницы статистики HAProxy редактируем файл конфигурации /etc/haproxy/haproxy.cfg, добавляя новые строки в раздел # main frontend which proxys to the backends. Изменения выделены:
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend main
bind *:5000
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js
acl url_haproxy path_beg -i /haproxy_stats
use_backend static if url_static
use_backend haproxy_stats if url_haproxy
default_backend app
6. Добавляем в конец файла конфигурации /etc/haproxy/haproxy.cfg настройку для отображения страницы статистики:
# Добавление настроек для страницы статистики
listen stats
bind :8080
mode http
stats enable
stats uri /haproxy_stats
stats realm HAProxy\ Statistics
stats auth admin:yourpassword
# Добавление нового backend для обработки запросов к странице статистики
backend haproxy_stats
mode http
stats enable
stats uri /haproxy_stats
stats realm HAProxy\ Statistics
stats auth admin:yourpassword
server stats 127.0.0.1:8080
Примечание**
В этой конфигурации страница статистики балансировщика доступна по HTTP, что не является безопасным методом доступа к важной информации о состоянии системы. Это сделано исключительно для демонстрации настроек отказоустойчивости и функциональности HAProxy. Рекомендуется использовать HTTPS для защиты данных и обеспечения безопасного доступа к странице статистики.
7. Проверяем созданный файл конфигурации с помощью команды ниже. Вывод команды не должен содержать ошибок. Предупреждения (warnings) не являются ошибками.
sudo haproxy -f /etc/haproxy/haproxy.cfg -c
8. Перезапускаем службу с помощью команды:
sudo systemctl restart haproxy
1.2.1 Установка первого брокера
Подключаемся на машину с ролью брокера (FQDN машины – orion-br01.termit.corp). Для установки брокера выполняем следующие шаги:
1. Копируем дистрибутив на сервер и проверяем права на выполнение установочного скрипта с помощью команды ls -la. Должно быть назначено право на исполнение.
2. При необходимости выдаем права на запуск скрипта с помощью команды:
sudo chmod +x ./install.sh
3. Запускаем установочный скрипт с помощью команды:
sudo ./install.sh install
4. Указываем имя узла брокера (имя может быть любым).
5. Для первого брокера указываем «1».
6. В качестве адреса брокера вводим FQDN балансировщика. Портал будет доступен по этому адресу.
7. Для выбора опции «Создать новую базу данных» указываем «2».
8. Последовательно указываем имя хоста базы данных, порт «5432», имя новой БД, имя пользователя БД, пароль пользователя БД.
Во время запуска отображается ключ шифрования БД, который необходимо сохранить. Этот ключ нужен для установки дополнительных брокеров.
После завершения инсталляции для подтверждения успешной операции в браузере в адресной строке вводим адрес балансировщика: https://orion-bln01.termit.corp. В появившемся окне аутентификации указываем логин «admin» и пароль «admin» от учетной записи по умолчанию.
Вид портала после аутентификации под admin/admin:
1.2.2 Мониторинг состояния серверов с помощью страницы статистики HAProxy
Чтобы получить доступ к интерфейсу статистики HAProxy, зайдем на веб-адрес http://10.250.107.110:8080/haproxy_stats в браузере и введем указанные ранее в /etc/haproxy/haproxy.cfg учетные данные администратора (логин: admin, пароль: yourpassword).
1.2.3 Установка второго брокера
sudo chmod +x ./install.sh
sudo ./install.sh install
1.2.4 Мониторинг состояния серверов с помощью страницы статистики HAProxy
1.3 Установка на терминальные серверы
Подключаемся на первую машину с ролью терминального сервера (FQDN машины – orion-nd01.termit.corp). Для установки на терминальный сервер выполним следующие шаги:
1. Устанавливаем Java 11 с помощью команды:
sudo dnf install java-11-openjdk
2. Изменяем версию Java, используемую по умолчанию, с помощью команды
sudo alternatives --config java.Так как нам требуется версия 11, указываем номер 2:
3. Устанавливаем компоненты X2GO server на терминальный сервер с помощью команды:
sudo dnf install x2goserver-xsession x2goserver-fmbindings x2goserver-common x2goserver x2goagent -y
4. Вводим терминальный сервер в домен командой:
sudo join-to-domain.sh -d termit.corp -n orion-nd01 -u admin -p Ori0n --ou "OU=TermitComputers,DC=termit,DC=corp" -y
Аналогично приведенным шагам проводим настройку второй машины с ролью терминального сервера (FQDN машины – orion-nd2 .termit.corp).
1.4 Установка шлюзов удаленного доступа
sudo dnf install openssh-server
2. Вводим терминальный сервер в домен, для этого выполняем последовательно команды:
sudo dnf install join-to-domain
sudo join-to-domain.sh -d termit.corp -n orion-gw01 -u admin -p Ori0n --ou "OU=TermitComputers" -y
<...>
Аналогично этим шагам настраиваем второй машины с ролью шлюза удаленного доступа (FQDN машины – orion-gw02.termit.corp).
1.5 Установка балансировщика нагрузки для шлюзов удаленного доступа
sudo dnf install haproxy
sudo systemctl enable haproxy --now
sudo nano /etc/ssh/sshd_config
sudo systemctl restart sshd
sudo dnf install policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 1022
Примечание**
После изменения порта SSH в конфигурационном файле /etc/ssh/sshd_config и перезапуска службы SSH, все новые SSH-соединения
должны использовать новый порт. Теперь, чтобы подключиться к серверу с использованием SSH, указываем новый порт в команде SSH.sudo setsebool -P haproxy_connect_any on
frontend termit mode tcp bind :22 default_backend termit_servers backend termit_servers mode tcp balance source hash-type consistent server orion-gw01.termit.corp 10.250.107.118:22 check server orion-gw02.termit.corp 10.250.107.119:22 check
listen stats bind :8080 mode http stats enable stats uri /haproxy_stats stats realm HAProxy\ Statistics stats auth admin:yourpassword
backend haproxy_stats mode http stats enable stats uri /haproxy_stats stats realm HAProxy\ Statistics stats auth admin:yourpassword server stats 127.0.0.1:8080
sudo haproxy -f /etc/haproxy/haproxy.cfg -c
sudo systemctl restart haproxy
2. Настройка Termit
2.1 Подключение каталога + назначение ролей
2.1.1 Настройка ролей
2.2 Создание серверов
Для создания сервера выполняем следующие действия:
1. На портале администрирования в левом меню выбираем раздел «Серверы».
2. В правом верхнем углу нажимаем «Новый сервер».
3. На вкладке «Новый терминальный сервер»:
● Адрес — указываем DNS-адрес терминального сервера
● Тип — выбираем операционную систему Linux
4. Нажимаем «Далее».
5. На вкладке «Группа терминальных серверов» группу выбирать не нужно, так как она еще не создана. Нажимаем «Далее».
6. На вкладке «Подтверждение информации» проверяем информацию о сервере и нажимаем «Создать».
7. Чтобы установить агент на терминальный сервер, подключаемся на машину с адресом 10.250.107.115 и выполняем указанный скрипт в консоли терминального сервера. Агент будет установлен и зарегистрирован на терминальном сервере.
В этом скрипте содержится секрет, используемый для аутентификации агента на сервере только во время установки. В случае потери скрипта необходимо удалить сервер и заново развернуть его.
Созданный сервер появился в списке, статус агента изменился на «Онлайн».
Далее создадим группу серверов.
2.3 Создание группы серверов
2.4 Публикация приложения
2.5 Установка клиента
3. Проверка отказоустойчивости
3.1 Брокеры
1. Начальное состояние: оба брокера включены, и балансировщик работает нормально. Аутентифицируемся на портале, тем самым убеждаемся, что пользователи могут успешно подключаться к ресурсу через балансировщик.
2. Отключение одного брокера:
● На машине с ролью брокера (FQDN - orion-br01.termit.corp) выполняем команду sudo shutdown now. При этом балансировщик должен продолжать перенаправлять запросы к другому брокеру, который остается включенным.
● Для подтверждения успешной операции обращаемся к странице статистики HAProxy (расположенной по адресу https://10.250.107.110:8080/haproxy_stats). В разделе termit_servers можем увидеть, что сервер с именем orion-br01.termit.corp получил статус «DOWN», что указывает на его недоступность, в то время как сервер с именем orion-br02.termit.corp остается в статусе «UP».
3. Проверка доступности ресурса: страница с порталом администрирования активна, пользователи все еще имеют возможность успешно подключаться к ресурсу через балансировщик, поскольку он перенаправляет запросы на доступный брокер.
В разделе "Брокеры" также можем отследить статусы брокер-нод:
4. Восстановление отказавшего брокера: после восстановления отказавшего брокера он снова становится доступным для балансировщика. При этом балансировщик должен начать равномерно распределять запросы между обоими брокерами.
5. Проверка восстановления: пользователи должны снова успешно подключаться к ресурсу через балансировщик, который теперь перенаправляет запросы на оба брокера, восстановив нормальное равновесие нагрузки.
Произведенные действия позволяют убедиться в том, что СТД Termit обеспечивает отказоустойчивость брокеров и может эффективно обрабатывать ситуации с отказавшими узлами.
3.2 База данных
1. Начальное состояние: включены три ноды базы данных, одна из них (FQDN машины – orion-db01.termit.lab) выступает в роли мастер-ноды кластера. Администратор может свободно создавать группы серверов и назначать на них приложения, полагаясь на стабильность кластера.
2. Проверка отказоустойчивости: отключаем мастер-ноду базы данных (FQDN машины – orion-db01.termit.lab), пробуем создать группу терминальных серверов на портале администрирования СТД Termit, что свидетельствует о надежности нашего кластера и его способности к бесперебойной работе в случае сбоя одной из нод.
Проверяем состояние кластера, выполняя на второй ноде базы данных (FQDN машины – orion-db02.termit.lab, соответствует IP-адресу 10.250.107.127) команду
patronictl list
После выключения мастер-ноды (orion-db01) роль мастера была успешно переназначена на ноду orion-db02, которая стала новым мастером, а нода orion-db03 перешла в режим синхронного резерва. Таким образом, кластер остается работоспособным и продолжает обеспечивать отказоустойчивость, несмотря на выход из строя одной из нод.
3. Проверяем работу портала администрирования после выключения мастер-ноды (orion-db01) кластера, для этого пробуем создать группу терминальных серверов на портале администрирования СТД Termit.
4. Восстанавливаем работу ноды базы данных, ранее выступающей в качестве мастер-ноды (FQDN машины – orion-db01.termit.lab). Проверяем состояние кластера, выполняя на второй ноде базы данных (FQDN машины – orion-db02.termit.lab, соответствует IP-адресу 10.250.107.127) команду
patronictl list
Когда мастер-нода orion-db01 была восстановлена, она снова стала доступной, однако теперь в роли реплики, так как роль мастера уже была присвоена ноде orion-db02. Таким образом, кластер вернулся к нормальному состоянию с одной мастер-нодой и двумя репликами, и процесс репликации продолжается.
3.3 Терминальные серверы при отказе всех брокеров
1. Начальное состояние: оба брокера включены, балансировщик работает нормально. Аутентифицируемся в Termit-клиенте, запускаем сессию с google chrome и с рабочим столом.
2. Последовательно отключаем оба брокера, выполняя sudo shutdown now на машинах с FQDN orion-br01.termit.corp и orion-br02.termit.corp. Оба брокера теперь недоступны, и балансировщик не может направлять новые запросы к брокерам.
На странице статистики HAProxy оба брокера отображаются в статусе «DOWN».
3. Проверка состояния активных терминальных сессий: терминальные серверы orion-nd01.termit.corp и orion-nd02.termit.corp остаются онлайн и обрабатывают текущие сессии. Переключаемся на клиентскую машину и проверяем состояние открытой ранее сессии.
Сессия с google chrome, бывшая активной до отказа всех брокеров, продолжает функционировать нормально, несмотря на отказ обоих брокеров.
В этом сценарии мы проверили отказоустойчивость системы в случае отказа обоих брокеров. Несмотря на то, что балансировщик не мог направлять новые запросы к брокерам из-за их недоступности, активные терминальные сессии продолжали работать без перебоев. Терминальные серверы оставались онлайн и обрабатывали текущие сессии, что позволило пользователям продолжать работу с открытыми приложениями.
3.4 Терминальные серверы
1. Начальное состояние: оба сервера в статусе онлайн. На клиентской машине запущены две сессии, по одной на каждый из терминальных серверов.
2. Проверка отказоустойчивости: подключаемся на терминальный сервер c FQDN orion-nd01.termit.corp (10.250.107.115), принудительно завершаем работу терминального сервера командой:
sudo shutdown now
Проверяем, что на клиентской машине только одна из сессий завершается из-за отключения сервера (сессия с google chrome, открытая на терминальном сервере с адресом 10.250.107.115), в то время как другая (сессия с рабочим столом, открытая на терминальном сервере с адресом 10.250.107.116) остается активной.
Действительно, на портале администрирования агент на сервере с адресом 10.250.107.115 (FQDN - orion-nd01.termit.corp) получил статус «Недоступен», что означает недоступность сервера для обработки запросов.
В разделе «Сессии» портала администрирования сессия на вышедшем из строя терминальном сервере отображается в том же статусе, в каком находилась на момент аварийного отключения терминального сервера (особенность релиза Termit 2.1, см. Особенности и ограничения).
`
3. Восстановление работы: после отключения терминального сервера, система остается в работоспособном состоянии. Пытаемся запустить новую сессию с приложением Chrome 2 на клиентской машине
Новая сессия автоматически направляется на доступный терминальный сервер (FQDN машины - orion-nd02.termit.corp, адрес 10.250.107.116), который продолжает обслуживать активные сессии.
Раздел «Сессии» портала администрирования подтверждает вышеописанное:
Таким образом, Termit продемонстрировал отказоустойчивость и способность к восстановлению работы в случае аварийного отказа одного из терминальных серверов.
3.5 Шлюзы
1. Начальное состояние: оба шлюза находятся в статусе онлайн, балансировщик нагрузки настроен на маршрутизацию трафика между ними. Запускаем сессию с Google Chrome через Termit клиент.
Можем убедиться, что сессия идет через балансировщик, выполнив на клиентской машине команду:
netstat -t -ano | grep ":22" | grep "ESTABLISHED"
Видим соединение до балансировщика для шлюзов.
2. Проверка отказоустойчивости: отключим используемый шлюз, выполнив на машине с FQDN orion-gw01.termit.corp команду:
sudo shutdown now
Видим, что на клиентской машине сессия с браузером аварийно завершилась.
На портале администрирования сессия перешла в статус «Отключенная».
На странице статистики HAProxy видим, что статус «UP» присвоен только одному из двух шлюзов, шлюзу с FQDN orion-gw0.termit.lab, а значит, все сессии попадают через балансировщик нагрузки на него.
3. Восстановление работы: пробуем запустить новую сессию с рабочим столом через балансировщик. Балансировщик маршрутизирует соединение через работающий шлюз. Сессия успешно запущена, на портале администрирования имеет статус «Активная».
3.6 LDAP
1. Начальное состояние: Оба контроллера домена: orion-dc01.termit.corp (адрес машины 10.250.107.20) и orion-dc02.termit.corp (адрес машины 10.250.107.30) функционируют нормально, обеспечивая доступ к порталу администрирования и обработку запросов клиентов. На портале администрирования указаны оба LDAP-сервера для синхронизации.
На портале администрирования нажимаем «Проверка соединения», получаем всплывающее окно с сообщением «Проверка соединения прошла успешна».
Аутентификация в десктоп-клиенте с помощью доменной учетной записи работает корректно:
2. Проверка отказоустойчивости: Выключаем машину с FQDN orion-dc02.termit.corp. Проверяем возможность синхронизации с LDAP на портале администрирования
Проверяем возможность аутентификации доменной учетной записью в Termit-клиенте:
Авторизация успешна. Поскольку второй контроллер домена (FQDN машины - orion-dc02.termit.corp) продолжает работать, вся функциональность остается доступна. Пользователи могут успешно обращаться к порталу администрирования и использовать десктопные клиенты, также происходит синхронизация LDAP с активным контроллером.
Таким образом, отказ одного из контроллеров домена не приводит к простою системы в целом благодаря наличию второго работающего контроллера, который обеспечивает непрерывную доступность и функциональность для пользователей и системных администраторов.