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

⁠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 правами которого будет производиться репликация:

Войти в консоль MySQL с правами root:
```
$ mysql -p
```
Создать пользователя (в примере пользователь «replica» с паролем «uds»):
```
MariaDB [(none)]> CREATE USER 'replica'@'%' IDENTIFIED BY 'uds';
Query OK, 0 rows affected (0.009 sec)
```

Предоставить права replication slave пользователю:

MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%' IDENTIFIED BY 'uds';
Query OK, 0 rows affected (0.002 sec)

Получить информацию об имени двоичного файла и его позиции:
```
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):

Войти в консоль MySQL с правами root:
```
$ mysql -p
```

Остановить репликацию:

MariaDB [(none)]> STOP SLAVE;
Query OK, 0 rows affected, 1 warning (0.001 sec)

Настроить репликацию между основным сервером и вторичным сервером:
```
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 — позиция двоичного файла.

Запустить репликацию:

MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.001 sec)

Убедиться, что конфигурация верна:

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. Проверка репликации

Для проверки репликации можно создать БД на главном сервере и убедиться, что она автоматически реплицируется на вторичном сервере:

Получить доступ к консоли MySQL главного сервера и создать новую тестовую БД «replicatest»:
```
MariaDB [(none)]> CREATE DATABASE replicatest;
Query OK, 1 row affected (0.001 sec)
```

Убедиться, что БД создана:

MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| replicatest        |
+--------------------+
4 rows in set (0.001 sec)

Получить доступ к консоли MySQL вторичного сервера и убедиться, что БД, созданная на основном сервере, успешно реплицировалась на этот сервер:
```
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| replicatest        |
+--------------------+
4 rows in set (0.002 sec)
```
После проверки работы репликации можно удалить БД «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 будет восстановлен

Затем необходимо настроить новый сервер для репликации БД. Это можно сделать разными способами, например:

Настроить текущий сервер БД как главный и создать новый сервер-реплику, который нужно настроить и восстановить БД из резервной копии с существующими данными (поскольку реплицируются только новые данные).
Напрямую сделать резервную копию текущего сервера БД (предварительно остановив все машины 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 серверов.