Введение
Управление аутентификацией и авторизацией пользователей требует обеспечение высокой доступности NAC-системы, т.к. в случае её отказа подключение пользователей и эндпоинтов станет невозможным.
Резервирование Eltex-NAICE выполняется по схеме Active-Active с использованием VRRP-адреса, что позволяет использовать один RADIUS-сервер в настройках сетевых устройств и зарезервировать подключение для сетевых устройств, настройки которых не поддерживают указание нескольких RADIUS-серверов. Для настройки схемы с резервирование требуется выделить 4 виртуальных (или физических) сервера: 2 для функционирования сервисов Eltex-NAICE, 2 для функционирования СУБД Postgresql, отвечающей за хранение данных.
Установка обновлением схемы с резервированием на хост, который ранее использовался для работы системы в однохостовом режиме не допускается!
Порядок действий при переходе с однохостовой схемы на схему с резервированием описан: v0.7_3.7.2 Обновление PostgreSQL при переходе со схемы с однохостовой установкой на схему с резервированием.
Общая схема резервирования
- Резервирование Eltex-NAICE выполняется по схеме Active-Active, возможно обращение к любому серверу Eltex-NAICE протоколу RADIUS со стороны сетевых устройств. Потребует настройки двух инстансов "radius-server host" на сетевом оборудовании.
- Между IP-адресами серверов с Eltex-NAICE используется дополнительно VIP, зарезервированный по протоколу VRRP с использованием сервиса keepalived. Данный адрес также может использоваться сетевым оборудованием для обмена RADIUS трафик и позволяет ограничиться настройкой только одного инстанса "radius-server host" на нём. Так же адрес используется для административного доступа.
- Для резервирования БД PostgreSQL используется replication manager. Резервирование выполняется на двух нодах, которые имеют роли "Primary" и "Standby".
- В настройках подключения к БД сервисов NAICE указываются оба адреса БД.
Системные требования к серверам
Минимальные
| Роль | CPU | RAM | HDD | Примечания |
|---|---|---|---|---|
| NAICE 1 | 4 | 8 Gb | 100 Gb | |
| NAICE 2 | 4 | 8 Gb | 100 Gb | |
| PostgreSQL 1 | 2 | 2 Gb | 500 Gb | |
| PostgreSQL 2 | 2 | 2 Gb | 500 Gb |
Рекомендуемые
| Роль | CPU | RAM | HDD | Примечания |
|---|---|---|---|---|
| NAICE 1 | 8 | 16 Gb | 100 Gb | |
| NAICE 2 | 8 | 16 Gb | 100 Gb | |
| PostgreSQL 1 | 4 | 4 Gb | 1000 Gb | |
| PostgreSQL 2 | 4 | 4 Gb | 1000 Gb |
Установка
Установка выполняется с помощью двух плейбуков ansible:
- Выполняется установка СУБД PostgrteSQL в кластере плейбуком "docker-postgres-cluster.yml".
- Выполняется установка сервисов NAICE и сервиса keepalived плейбуком "reservation-naice-services.yml".
Подготовка к установке
Адреса целевых хостов на которых будет выполнятся установка определяется в файле "hosts.yml".
Для СУБД PostgreSQL необходимо задать адреса в раздел "postgres-cluster":
#хосты для установки postgres-cluster (primary + standby)
postgres-cluster:
hosts:
node_primary:
forwarded_postgresql_port: 5432
forwarded_ssh_port: 15432
ansible_host: <IP-адрес хоста для node-1 PostgreSQL>
ansible_user: <логин пользователя>
ansible_ssh_pass: <пароль пользователя>
ansible_become_password: <пароль для повышения привилегий (sudo)>
ansible_port: 22
node_standby:
forwarded_postgresql_port: 5432
forwarded_ssh_port: 15432
ansible_host: <IP-адрес хоста для node-2 PostgreSQL>
ansible_user: <логин пользователя>
ansible_ssh_pass: <пароль пользователя>
ansible_become_password: <пароль для повышения привилегий (sudo)>
ansible_port: 22
Для установки сервисов NAICE с резервированием необходимо задать адреса в разделе "reservation":
reservation:
hosts:
master_host:
ansible_host: <IP-адрес хоста 1 для NAICE>
ansible_user: <логин пользователя>
ansible_ssh_pass: <пароль пользователя>
ansible_become_password: <пароль для повышения привилегий (sudo)>
ansible_port: 22
keepalived_interface: <наименование интерфейса, на котором будет настроен VIP-адрес, например eth0>
backup_host:
ansible_host: <IP-адрес хоста 2 для NAICE>
ansible_user: <логин пользователя>
ansible_ssh_pass: <пароль пользователя>
ansible_become_password: <пароль для повышения привилегий (sudo)>
ansible_port: 22
keepalived_interface: <наименование интерфейса, на котором будет настроен VIP-адрес, например eth0>
vars:
keepalived_vip: <VIP-адрес, без маски, например 192.168.0.11>
Установка кластера СУБД PostgreSQL
Выполнить плейбук:
ansible-playbook docker-postgres-cluster.yml
Результатом выполнения плейбука будет установка СУБД PostgreSQL в кластере на серверах, указанных в "node_primary" и "node_standby". Мастер-нода кластера будет находиться на хосте "node_primary".
Проверка состояния кластера PostgreSQL
Все команды необходимо выполнять из под непривилегированного пользователя через "sudo"!
Обращение к контейнерам на ноде "node_primary" и "node_standby" выполняется разными командами!
node_primary: sudo docker exec -it naice-postgres-1 <команда>
node_standby: sudo docker exec -it naice-postgres-2 <команда>
Проверка расположения ноды "Primary".
Зайти на первую ноду, указанную в "node_primary" и выполнить команду "sudo docker exec -it naice-postgres-1 repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf cluster show":
$ sudo docker exec -it naice-postgres-1 repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf cluster show ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string ------+------------+---------+-----------+------------+----------+----------+----------+--------------------------------------------------------------------------------------- 1001 | postgres-1 | primary | * running | | default | 100 | 1 | user=repmgr password=repmgr host=postgres-1 dbname=repmgr port=5432 connect_timeout=1 1002 | postgres-2 | standby | running | postgres-1 | default | 100 | 1 | user=repmgr password=repmgr host=postgres-2 dbname=repmgr port=5432 connect_timeout=1
Зайти на вторую ноду, указанную в "node_standby" и выполнить команду "sudo docker exec -it naice-postgres-2 repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf cluster show":
$ sudo docker exec -it naice-postgres-2 repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf cluster show ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string ------+------------+---------+-----------+------------+----------+----------+----------+--------------------------------------------------------------------------------------- 1001 | postgres-1 | primary | * running | | default | 100 | 1 | user=repmgr password=repmgr host=postgres-1 dbname=repmgr port=5432 connect_timeout=1 1002 | postgres-2 | standby | running | postgres-1 | default | 100 | 1 | user=repmgr password=repmgr host=postgres-2 dbname=repmgr port=5432 connect_timeout=1
Проверка работоспособности кластера
Зайти на первую ноду, указанную в и выполнить команду:
sudo docker exec -it naice-postgres-1 repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf cluster crosscheck
Зайти на вторую ноду, указанную в и выполнить команду:
sudo docker exec -it naice-postgres-2 repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf cluster crosscheck
Результатом выполнения команд будет проверка состояния кластера, которая сопровождается выводом лога, в конце которого ожидается вывод:
debug1: Exit status 0 Name | ID | 1001 | 1002 ------------+------+------+------ postgres-1 | 1001 | * | * postgres-2 | 1002 | * | *
Смена роли ноды на "Primary"
В кластере PostgreSQL можно выполнить смену роли ноды "Standby" на "Primary".
Перед сменой роли необходимо убедиться в том, что окружение подготовлено и смена роли возможна. Для этого надо выполнить команду:
repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf standby switchover --dry-run
В случае успеха команда должна завершиться выводом:
debug1: Exit status 0 INFO: following shutdown command would be run on node "postgres-2": "/opt/bitnami/postgresql/bin/pg_ctl -o "--config-file="/opt/bitnami/postgresql/conf/postgresql.conf" --external_pid_file="/opt/bitnami/postgresql/tmp/postgresql.pid" --hba_file="/opt/bitnami/postgresql/conf/pg_hba.conf"" -w -D "/bitnami/postgresql/data" stop" INFO: parameter "shutdown_check_timeout" is set to 60 seconds INFO: prerequisites for executing STANDBY SWITCHOVER are met
Команда: repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf standby switchover --dry-run только проверяет готовность к выполнению! Смена роли при этом не выполняется!
Для смены роли необходимо выполнить команду на ноде имеющей роль "Statndby":
repmgr -f /opt/bitnami/repmgr/conf/repmgr.conf standby switchover
В случае успешной смены роли ноды в конце лога появиться сообщение:
debug1: Exit status 0 NOTICE: current primary has been cleanly shut down at location 0/7000028 NOTICE: promoting standby to primary DETAIL: promoting server "postgres-2" (ID: 1002) using pg_promote() NOTICE: waiting up to 60 seconds (parameter "promote_check_timeout") for promotion to complete NOTICE: STANDBY PROMOTE successful DETAIL: server "postgres-2" (ID: 1002) was successfully promoted to primary [REPMGR EVENT] Node id: 1002; Event type: standby_promote; Success [1|0]: 1; Time: 2024-12-09 08:19:24.617459+00; Details: server "postgres-2" (ID: 1002) was successfully promoted to primary Looking for the script: /opt/bitnami/repmgr/events/execs/standby_promote.sh [REPMGR EVENT] will execute script '/opt/bitnami/repmgr/events/execs/standby_promote.sh' for the event [REPMGR EVENT::standby_promote] Node id: 1002; Event type: standby_promote; Success [1|0]: 1; Time: 2024-12-09 08:19:24.617459+00; Details: server "postgres-2" (ID: 1002) was successfully promoted to primary [REPMGR EVENT::standby_promote] Locking primary... [REPMGR EVENT::standby_promote] Unlocking standby... NOTICE: node "postgres-2" (ID: 1002) promoted to primary, node "postgres-1" (ID: 1001) demoted to standby [REPMGR EVENT] Node id: 1002; Event type: standby_switchover; Success [1|0]: 1; Time: 2024-12-09 08:19:27.392716+00; Details: node "postgres-2" (ID: 1002) promoted to primary, node "postgres-1" (ID: 1001) demoted to standby Looking for the script: /opt/bitnami/repmgr/events/execs/standby_switchover.sh [REPMGR EVENT] no script '/opt/bitnami/repmgr/events/execs/standby_switchover.sh' found. Skipping... NOTICE: switchover was successful DETAIL: node "postgres-2" is now primary and node "postgres-1" is attached as standby NOTICE: STANDBY SWITCHOVER has completed successfully
При этом роль ноды ранее бывшей "Primary" будет понижена до "Standby".
Установка кластера NAICE
Перед установкой необходимо убедиться, что роль "Primary" принадлежит ноде PostgreSQL указанной в переменной "node_primary" "ansible_host"! При необходимости выполнить переключение роли "Primary". В противном случае установка не сможет быть завершена!
В настройках подключения к БД сервисов NAICE указываются оба адреса БД, а запись в БД возможна только через Primary сервер, обязательным условием является использование в URL параметра targetServerType.
Пример:
URSUS_POSTGRES_JDBC_URL:jdbc:postgresql://192.168.0.101:5432,192.168.0.102:5432/ursus?targetServerType=preferPrimary
Адреса взаимодействия с БД берутся из значения "ansible_host" из раздела "postgres-cluster" файла "hosts.yml".
Для установки необходимо выполнить плейбук:
ansible-playbook reservation-naice-services.yml
Проверка состояния кластера NAICE
После завершения установки на одной из будет поднят VIP адрес. Для того, что бы узнать на какой ноде он находиться необходимо выполнить команду на каждой ноде:
ip address show dev <имя интерфейса указанное в переменной keepalived_interface>
VIP адрес должен быть только на одной ноде кластера! Если адрес отображается на обоих нодах - это как правило означает отсутствие связности между ними!
Для работы протокола VRRP требуется наличие L2 связности и возможность передавать мультикаст-трафик на адреса VRRP 00:00:5E:00:01:XX (используемые для рассылки анонсов MAC-адреса определенные в RFC3768).
На хосте зайти в папку установки и убедиться, что контейнеры запущены.
Сервис, отвечающий за работу с лицензией naice-gulo должен быть запущен только на хосте который находиться в состоянии VRRP MASTER!
Что бы проверить состояние сервиса naice-gulo необходимо выполнить команду "sudo docker compose ps -a | grep naice-gulo".
Пример состояния на хосте VRRP MASTER:
$sudo docker compose ps -a | grep naice-gulo WARN[0000] /etc/docker-naice/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion naice-gulo nexus.eltex.loc:9015/naice-gulo:0.7 "java -cp @/app/jib-…" naice-gulo 4 minutes ago Up 4 minutes (healthy) 0.0.0.0:8089-8090->8089-8090/tcp, :::8089-8090->8089-8090/tcp
Пример состояния на хосте VRRP BACKUP:
$ sudo docker compose ps -a | grep naice-gulo WARN[0000] /etc/docker-naice/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion naice-gulo nexus.eltex.loc:9015/naice-gulo:0.7 "java -cp @/app/jib-…" naice-gulo 10 minutes ago Exited (143) 8 minutes ago
На хосте VRRP BACKUP состояние сервиса naice-gulo может не отображаться, если он ни разу не запускался. Это является нормальным.
Описание схемы работы
Нормальное состояние системы
В нормальном состоянии системы функционируют все 4 хоста.
- Обработка RADIUS-запросов возможна на всех 3-адресах кластера.
- Сервис "naice-gulo" запущен только на хосте, который находится в состоянии VRRP MASTER.
- Взаимодействие сервисов с БД выполняется по 2-м реальным адресам нод кластера PostgrteSQL. Нода доступная для записи в состоянии "Primary" определяется автоматически.
Отказ хоста NAICE 1
При отказе хоста NAICE 1 будут автоматически выполнены следующие действия:
- Хост "NAICE 2" автоматически перехватит VRRP мастерство.
- Будет автоматически выполнен запуск сервиса "naice-gulo" на хосте "NAICE 2".
- Обработка RADIUS-запросов будет выполняться адресами VIP и реальным адресом хоста "NAICE 2".
Отказ хоста БД 1
При отказе хоста БД 1 будут автоматически выполнены следующие действия:
- Хост БД 2 автоматически перейдет в состояние "Primary"
- Сервисами NAICE будет определен факт недоступности БД 1 и дальнейшие действия по работе с БД будут выполняться с хостом БД 2.
- Обработка RADIUS-запросов возможна на всех 3-адресах кластера.
Восстановление после отказа
- После возвращения в работу хоста NAICE более высокоприоритетный VRRP инстанс не выполняет перехват мастерства и будет работать в состоянии VRRP BACKUP.
- После возвращения в работу хоста БД PostgreSQL он будет работать в режиме "Standbay". Роль "Primary" останется у текущей ноды кластера.
Восстановление хоста
В случае полной утраты одного из хостов требуется предварительно восстановить стартовое состояние: развернуть ОС, настроить IP-адресацию и пользователей как было ранее и выполнить процедуру восстановления.
Восстановление хоста кластера БД PostgreSQL
На оставшейся в работе ноде выполнить резервное копирование данных в соответствии с инструкцией: v0.7_3.8 Создание резервной копии данных БД.
Повторно развернуть хост для вышедшей из строя ноды кластера, с прежней ОС, адресацией и пользователем.
Выполнить плейбук:
ansible-playbook docker-postgres-cluster.yml
После завершения плейбука проверить состояние кластера БД PostgreSQL, убедиться в его работоспособности и проверить работу авторизации и корректности настроек в GUI.
Восстановление хоста сервисов NAICE
Повторно развернуть хост для вышедшей из строя ноды кластера, с прежней ОС, адресацией и пользователем.
Выполнить плейбук:
ansible-playbook reservation-naice-services.yml
При повторном выполнении установки будет выполнен перезапуск всех сервисов NAICE, что приведет к кратковременному (до 5 мин) перерыву в работе комплекса. Необходимо это учитывать при проведении работ по восстановлению!
Так же будет выполнен перезапуск сервиса keepalived что приведет к переходу VRRP-мастерства на более высокоприоритетный инстанс.
В случае, если выполнялось восстановление первого хоста NAICE - будет выпущен новый самоподписный сертификат HTTPS!
После восстановления убедиться в работе авторизации и корректной работе всех сервисов.