Product SiteDocumentation Site

17.7. Отказоустойчивое решение

Компоненты OpenUDS можно настроить в режиме высокой доступности (HA).
Для обеспечения высокой доступности OpenUDS, кроме настройки нескольких OpenUDS Server и Tunnel, необходимо настроить репликацию базы данных. Также следует настроить балансировщик нагрузки, который будет распределять подключения к компонентам OpenUDS Server и Tunnel.
Основные компоненты отказоустойчивого решения OpenUDS:
  • Сервер MySQL — база данных (БД) является одним из наиболее существенных компонентов OpenUDS. Поэтому настоятельно рекомендуется иметь резервную копию этого компонента, либо посредством полной резервной копии машины, либо посредством конфигурации активной/пассивной реплики. В данном руководстве описана настройка двух серверов MySQL в режиме активной/пассивной репликации;
  • HAProxy-сервер — сервер, отвечающий за распределение подключений к OpenUDS Server и Tunnel. Через него осуществляется доступ пользователей к OpenUDS, и выполняются подключения к различным сервисам. На серверах HAProxy также следует настроить виртуальный IP-адрес, который будет активен только на основном сервере. В случае отказа основного сервера виртуальный IP-адрес будет автоматически активирован на другом сервере HAProxy;
  • OpenUDS Server — наличие нескольких машин OpenUDS Server обеспечит непрерывный доступ пользователей к OpenUDS, даже при отказе одного из OpenUDS Server;
  • OpenUDS Tunnel — наличие нескольких машин OpenUDS Tunnel позволит получить доступ к службам (рабочим столам или приложениям) через туннелированные соединения и HTML5, даже при отказе одного из OpenUDS Tunnel.

    Примечание

    Если пользователь подключается к сервису (рабочему столу или приложению) и сервер OpenUDS Tunnel, через который он подключен, падает, соединение будет потеряно. Но при повторном подключении доступ будет автоматически восстановлен через другой активный сервер OpenUDS Tunnel.
Основные элементы отказоустойчивого решения OpenUDS

Таблица 17.2. Системные требования

Компонент
Количество
ОЗУ
ЦП
Диск
SQL Server
2
1 ГБ
2 vCPUs
10 ГБ
HAProxy
2
1 ГБ
2 vCPUs
10 ГБ
OpenUDS Server
2
2 ГБ
2 vCPUs
8 ГБ
OpenUDS Tunnel
2
2 ГБ
2 vCPUs
13 ГБ

Примечание

Для HAProxy необходимо 3 IP-адреса, по одному для каждого сервера (Master-Slave) и общий виртуальный IP-адрес, который будет использоваться для балансировки.

17.7.1. Конфигурация серверов MySQL

На обоих серверах установить MySQL (MariaDB):
# apt-get install mariadb
Запустить сервер MySQL и добавить его в автозагрузку:
# systemctl enable --now mariadb.service
Задать пароль root и настройки безопасности для MySQL:
# mysql_secure_installation

17.7.1.1. Настройка репликации между серверами

17.7.1.1.1. Главный узел (Master)
В файле /etc/my.cnf.d/server.cnf:
  • закомментировать параметр skip-networking;
  • раскомментировать параметры server-id и log-bin;
  • убедиться, что для параметра server-id установлено значение 1;
  • раскомментировать параметр bind-address и указать IP-адрес сервера (главного):
    bind-address 192.168.0.128
    
Перезагрузить службу MySQL:
# systemctl restart mariadb
Создать нового пользователя, c правами которого будет производиться репликация:
  1. Войти в консоль MySQL с правами root:
    $ mysql -p
    
  2. Создать пользователя (в примере пользователь «replica» с паролем «uds»):
    MariaDB [(none)]> CREATE USER 'replica'@'%' IDENTIFIED BY 'uds';
    Query OK, 0 rows affected (0.009 sec)
    
  3. Предоставить права replication slave пользователю:
    MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%' IDENTIFIED BY 'uds';
    Query OK, 0 rows affected (0.002 sec)
    
  4. Получить информацию об имени двоичного файла и его позиции:
    MariaDB [(none)]> SHOW MASTER STATUS\G
    *************************** 1. row ***************************
                File: mysql-bin.000002
            Position: 328
        Binlog_Do_DB:
    Binlog_Ignore_DB:
    1 row in set (0.001 sec)
    
    В данном примере:
    • mysql-bin.000002 — имя файла;
    • 328 — позиция двоичного файла.
    Эти данные будут необходимы для настройки Slave-сервера.
17.7.1.1.2. Вторичный узел (Slave)
В файле /etc/my.cnf.d/server.cnf:
  • закомментировать параметр skip-networking;
  • раскомментировать параметры server-id и log-bin;
  • в параметре server-id установить значение 2;
  • раскомментировать параметр bind-address и указать IP-адрес сервера (вторичного):
    bind-address 192.168.0.129
    
Перезагрузить службу MySQL:
# systemctl restart mariadb
Настроить параметры, которые вторичный сервер (Slave) будет использовать для подключения к основному серверу (Master):
  1. Войти в консоль MySQL с правами root:
    $ mysql -p
    
  2. Остановить репликацию:
    MariaDB [(none)]> STOP SLAVE;
    Query OK, 0 rows affected, 1 warning (0.001 sec)
    
  3. Настроить репликацию между основным сервером и вторичным сервером:
    MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='192.168.0.128', MASTER_USER='replica', MASTER_PASSWORD='uds', MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=328;
    Query OK, 0 rows affected (0.020 sec)
    
    где:
    • 192.168.0.128 — IP-адрес основного сервера;
    • replica — пользователь, с правами которого будет производиться репликация;
    • uds — пароль пользователя replica;
    • mysql-bin.000002 — имя файла, полученного на предыдущем шаге;
    • 328 — позиция двоичного файла.
  4. Запустить репликацию:
    MariaDB [(none)]> START SLAVE;
    Query OK, 0 rows affected (0.001 sec)
    
  5. Убедиться, что конфигурация верна:
    MariaDB [(none)]> SHOW SLAVE STATUS\G
    *************************** 1. row ***************************
                    Slave_IO_State: Waiting for master to send event
                       Master_Host: 192.168.0.128
                       Master_User: replica
                       Master_Port: 3306
                     Connect_Retry: 60
                   Master_Log_File: mysql-bin.000004
               Read_Master_Log_Pos: 328
                    Relay_Log_File: mysqld-relay-bin.000006
                     Relay_Log_Pos: 555
             Relay_Master_Log_File: mysql-bin.000004
                  Slave_IO_Running: Yes
                 Slave_SQL_Running: Yes
    …
    
    IP-адрес основного сервера должен быть указан корректно, параметры Slave_IO_Running и Slave_SQL_Running должны быть установлены в значение «Yes».

17.7.1.2. Проверка репликации

Для проверки репликации можно создать БД на главном сервере и убедиться, что она автоматически реплицируется на вторичном сервере:
  1. Получить доступ к консоли MySQL главного сервера и создать новую тестовую БД «replicatest»:
    MariaDB [(none)]> CREATE DATABASE replicatest;
    Query OK, 1 row affected (0.001 sec)
    
  2. Убедиться, что БД создана:
    MariaDB [(none)]> SHOW DATABASES;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | mysql              |
    | performance_schema |
    | replicatest        |
    +--------------------+
    4 rows in set (0.001 sec)
    
  3. Получить доступ к консоли MySQL вторичного сервера и убедиться, что БД, созданная на основном сервере, успешно реплицировалась на этот сервер:
    MariaDB [(none)]> SHOW DATABASES;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | mysql              |
    | performance_schema |
    | replicatest        |
    +--------------------+
    4 rows in set (0.002 sec)
    
  4. После проверки работы репликации можно удалить БД «replicatest», выполнив команду на основном сервере:
    MariaDB [(none)]> DROP DATABASE replicatest;
    

17.7.1.3. Создание БД

Создать на основном сервере БД:
$ mysql -p
Enter password:

MariaDB [(none)]> CREATE DATABASE dbuds CHARACTER SET utf8 COLLATE utf8_general_ci;
MariaDB [(none)]> CREATE USER 'dbuds'@'%' IDENTIFIED BY 'password';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON dbuds.* TO 'dbuds'@'%';
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> exit;
Подключить серверы OpenUDS к БД основного сервера.

17.7.1.4. Отказ сервера

При недоступности одного из серверов БД необходимо выполнить ряд задач. Задачи, которые следует выполнить, зависят от того к какому серверу (Master или Slave) нет доступа.
17.7.1.4.1. Главный узел (Master)
Если недоступен основной сервер БД (Master), то будет потерян доступ к среде VDI. В этом случае необходимо вручную подключить OpenUDS Server к вторичной БД (Slave), в которой находится вся информация среды VDI до момента падения основной БД. Чтобы настроить новое подключение к БД на OpenUDS Server следует в конфигурационном файле /var/server/server/settings.py указать параметры новой БД (это необходимо сделать на всех серверах OpenUDS-Server).
После изменения IP-адреса БД необходимо перезапустить сервер OpenUDS (это необходимо сделать на всех серверах OpenUDS Server). После перезапуска сервера доступ к среде VDI будет восстановлен
Затем необходимо настроить новый сервер для репликации БД. Это можно сделать разными способами, например:
  1. Настроить текущий сервер БД как главный и создать новый сервер-реплику, который нужно настроить и восстановить БД из резервной копии с существующими данными (поскольку реплицируются только новые данные).
  2. Напрямую сделать резервную копию текущего сервера БД (предварительно остановив все машины OpenUDS Server). Создать новый сервер БД Master, восстановить туда резервную копию БД и перенастроить репликацию.

Примечание

Чтобы не потерять данные, перед применением любого метода перестроения репликации, рекомендуется сделать резервную копию БД. Для получения резервной копии можно использовать следующую команду:
# mysqldump -u dbuds -ppassword --databases dbuds > dbuds_dump.sql
При создании резервной копии все машины OpenUDS Server должны быть выключены. Таким образом, обеспечивается согласованность данных и отсутствие различий в данных между главным и подчиненным серверами перед настройкой реплики.
17.7.1.4.2. Вторичный узел (Slave)
Если недоступен вторичный сервер БД (Slave), доступ к среде VDI сохранится, но будет необходимо перенастроить вторичный сервер-реплику. Перед выполнением данной настройки необходимо восстановить резервную копию с текущим состоянием основной БД, так как будут синхронизированы только новые данные реплики (существующие данные не будут реплицированы в базе данных).
Важно, чтобы во время всего этого процесса машины OpenUDS Server были выключены, чтобы не возникало различий между БД Master и Slave серверов.