Отказоустойчивый кластер Платформы НЕЙРОСС
В данном разделе приведена пошаговая инструкция по развёртыванию кластера «с нуля», обеспечивающего базовую функциональность горячего резервирования сервера Платформы НЕЙРОСС с нативным типом установки (в среде ОС).
Содержание:
Общие сведения
Отказоустойчивый кластер обеспечивает высокий уровень готовности резервного сервера для максимальной доступности сервисов системы. Самый простой кластер состоит из 2-х узлов (компьютеров, серверов), образующих его, настроенных на мониторинг друг друга и управление соответствующими ресурсами кластера.
Для настройки кластера и его ресурсов можно применять любую из двух утилит pcs или crm. При этом настройку можно осуществлять и той и другой в любом удобном порядке, поэтому некоторые действия описаны с использование одной утилиты, а некоторые – другой.
Действия на каждом сервере (NODE 1 и NODE2)
Актуализируйте и обновите версии пакетов:
sudo apt upgrade
Установите программные средства, необходимые для работы Платформы НЕЙРОСС (на момент написания страницы из репозитория инсталлировался PostgreSQL версии 12):
sudo apt install -y openjdk-8-jdk traceroute
Установите пакеты pacemaker и corosync, а также соответствующие необходимые утилиты. Рекомендуется выполнять установку из-под root для правильного создания пользователя hacluster и настройки пользовательского доступа.
apt install pacemaker pcs resource-agents fence-agents corosync ntp rsync
exit
Укажите в файле hosts IP-адреса всех узлов кластера в явном виде:
10.1.30.251 node1
10.1.30.252 node2
Настройте службу синхронизации времени на сервер точного времени, перезапустите службу, проверьте работу, выполнив последовательно команды ниже:
sudo systemctl restart ntp
sudo ntpq -p
Проверьте наличие пользователя hacluster (его создает pacemaker в процессе установки):
Вывод команды приведён в коде ниже:
Измените пароль пользователя hacluster (ниже код на примере пароля 123456)
123456
123456
Добавьте в автозагрузку и запустите службу конфигурации pacemaker:
sudo systemctl start pcsd.service
Действия на первом узле (NODE1)
Определите авторизацию на узлах (имена узлов node1 и node2) под пользователем hacluster:
Если команда не выполнилась (это может зависеть от версии pacemaker), то выполните:
Создайте кластер с именем HACLUSTER из двух узлов:
Если возникают ошибки с текстом "...the host seems to be in a cluster already...", то необходимо выполнить:
При необходимости проверить конфигурацию (на всех серверах должен быть файл с одинаковым содержимым) выполните:
totem {
version: 2
cluster_name: HACLUSTER
transport: knet
crypto_cipher: aes256
crypto_hash: sha256
}
nodelist {
node {
ring0_addr: 10.1.30.251
name: node1
nodeid: 1
}
node {
ring0_addr: 10.1.30.252
name: node2
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
two_node: 1
}
logging {
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
timestamp: on
}
Включите и запустите все кластеры на всех узлах:
sudo pcs cluster start --all
При использовании двух узлов включите stonith. Он нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы, игнорируйте кворум:
sudo pcs property set no-quorum-policy=ignore
Без сконфигурированного stonith кластер не начнёт управлять ресурсами. Поэтому, в этом месте для простоты старта работы кластера сначала можно выключить stonith:
Потом, когда будет сконфигурирован stonith, включить его обратно (описано ниже) для обеспечения фенсинга.
Запросите статус на обоих узлах:
В случае stonith-enabled=true вы увидите:
WARNINGS:
No stonith devices and stonith-enabled is not false
Cluster Summary:
* Stack: corosync
* Current DC: node1 (version 2.0.3-4b1f869f0f) - partition with quorum
* Last updated: Wed Oct 20 14:06:00 2021
* Last change: Wed Oct 20 14:05:17 2021 by root via cibadmin on node1
* 2 nodes configured
* 0 resource instances configured
Node List:
* Online: [ node1 node2 ]
Full List of Resources:
* No resources
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Добавьте виртуальный сетевой адрес как ресурс (помним про тайм-ауты) кластера с именем virtual_ip, который и будет основным адресом платформы НЕЙРОСС:
op monitor timeout="60s" interval="10s" on-fail="restart" \
op stop timeout="60s" interval="0s" on-fail="ignore" \
op start timeout="60s" interval="0s" on-fail="stop"
Отключите запуск postgresql.service при загрузке системы. Включать и отключать сервис при необходимости теперь будет pacemaker.
На узле (в нашем случае это node1), который первоначально будет являться Мастером, инициализируйте новую базу данных:
Если база уже запущена, то остановите процесс postgresql, очистите директорию /var/lib/postgresql/12/main
sudo su - postgres
rm -rf /var/lib/postgresql/12/main/*
и выполните команду инициализации новой базы ещё раз.
Запустите СУБД PostgreSQL:
Создайте пользователя для репликации базы:
Установите пароль, например, 12345.
Откройте на редактирование файл /var/lib/postgresql/12/main/pg_hba.conf:
Добавьте в него необходимые разрешения следующим образом:
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
host replication all 10.0.0.0/13 trust
host all all 10.0.0.0/13 trust
Сохраните изменения.
Откройте на редактирование файл /var/lib/postgresql/12/main/postgresql.conf:
Добавьте (или расскомментируйте) следующие строки:
wal_level = replica
logging_collector = on
hot_standby = on
wal_keep_segments = 10
Перезапустите СУБД PostgreSQL:
sudo -u postgres /usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/main start
Выполните установку Платформы НЕЙРОСС на этом узле и пройдите этапы первого запуска по адресу 10.1.30.250.
На втором узле (NODE2)
Отключите запуск postgresql.service при загрузке системы. Включать и отключать сервис при необходимости теперь будет pacemaker.
Остановите процесс postgresql, если он ещё запущен.
Очистите директорию /var/lib/postgresql/12/main/:
sudo su - postgres
rm -rf /var/lib/postgresql/12/main/*
Скопируйте базу данных с NODE1 при помощи команды:
exit
В результате в директории /var/lib/postgresql/12/main узла node2 появится содержимое директории /var/lib/postgresql/12/main узла NODE1.
Установите Платформу НЕЙРОСС на этом узле и не проходите этап первого запуска.
Отключите запуск ultima-vmc.service при загрузке системы на этом узле кластера. Включать и отключать сервис при необходимости теперь будет pacemaker.
sudo systemctl disable ultima-vmc.service
Продолжение на узле NODE1
Создайте ресурс с именем HA-pgsql типа pgsql для управления конфигурацией PostgreSQL:
psql="/usr/lib/postgresql/12/bin/psql" \
pgdata="/var/lib/postgresql/12/main" rep_mode="sync" \
node_list="node1 node2" master_ip="10.1.30.250" \
restart_on_promote="false" check_wal_receiver="true" pgport="5432" \
primary_conninfo_opt="password=12345" repuser="repl"
В некоторых описаниях настройки упоминается ещё параметр config="/etc/postgresql/12/main/postgresql.conf".
Для созданного выше ресурсаHA-pgsql укажите, что он может иметь одно из нескольких состояний и менять их в зависимости от типа узла (master и slave):
Создайте связь двух созданных выше ресурсов (HA-pgsql и virtual_ip), чтобы они запускались вместе на одном узле, и установите очерёдность запуска таким образом, чтобы ресурс virtual_ip запускался только после успешного запуска ресурса HA-pgsql. Для этого создайте группу ресурсов master-group и добавьте в неё ресурсы:
sudo pcs constraint colocation add master-group with Master HA-pgsql-clone
sudo pcs constraint order promote HA-pgsql-clone then start master-group symmetrical=false kind=Mandatory
sudo pcs constraint order demote HA-pgsql-clone then stop master-group symmetrical=false kind=Optional
Отключите запуск ultima-vmc.service при загрузке системы на этом узле кластера. Включать и отключать сервис при необходимости теперь будет pacemaker.
sudo systemctl disable ultima-vmc.service
Продолжение на узле NODE2
Скопируйте файл application.conf с узла NODE1 на узел NODE2, для этого на NODE2 выполните:
Скопируйте содержимое каталога /home/ultima-vmc/ с узла NODE1 на узел NODE2, для этого на NODE2 выполните:
Установите в явном виде владельца для скопированных файлов, для этого на NODE2 выполните:
sudo chown ultima-vmc:ultima-vmc /usr/share/ultima-vmc/conf/application.conf
На узле NODE1
Создайте ресурс с именем HA-neyross типа systemd для управления конфигурацией исполняемого сервиса и добавьте созданный ресурс в группу master-group, чтобы он запускался вместе на одном узле с другими ресурсами:
op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s" \
--group master-group
Иначе (менее подходящее решение), создайте ресурс с именем HA-neyross типа anything для управления конфигурацией исполняемой программы:
binfile=... cmdline_options=... user=... \
op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s" \
--group master-group
в параметрах binfile, cmdline_options и user укажите соответственно исполняемый файл с полным путём от корня, параметры запуска исполняемого файла, имя пользователя системы (от имени которого будет выполняться файл), всё указывается в кавычках
параметры cmdline_options и user не являются обязательными
Создание ресурса фенсинга
Для защиты разделяемых ресурсов и изоляции узла кластера при его неисправности существует механизм фенсинга (изоляции).
Чтобы вывести список доступных агентов изоляции fence-agents используйте команду:
Для тестовых целей можно использовать следующую конфигурацию с агентом external/ssh:
configure
primitive st-ssh stonith:external/ssh params hostlist="node1 node2"
clone fencing st-ssh
property stonith-enabled=true
commit
exit
Заключение
Финальный вывод команды мониторинга
выглядит следующим образом:
* Stack: corosync
* Current DC: node1 (version 2.0.3-4b1f869f0f) - partition with quorum
* Last updated: Mon Nov 1 17:02:05 2021
* Last change: Mon Nov 1 16:54:44 2021 by root via crm_attribute on node1
* 2 nodes configured
* 6 resource instances configured
Node List:
* Online: [ node1 node2 ]
Full List of Resources:
* Clone Set: HA-pgsql-clone [HA-pgsql] (promotable):
* Masters: [ node1 ]
* Slaves: [ node2 ]
* Resource Group: master-group:
* virtual_ip (ocf::heartbeat:IPaddr2): Started node1
* HA-neyross (systemd:ultima-vmc.service): Started node1
* Clone Set: fencing [st-ssh]:
* Started: [ node1 node2 ]
Node Attributes:
* Node: node1:
* HA-pgsql-data-status : LATEST
* HA-pgsql-master-baseline : 00000000077D6EF8
* HA-pgsql-receiver-status : normal (master)
* HA-pgsql-status : PRI
* master-HA-pgsql : 1000
* Node: node2:
* HA-pgsql-data-status : STREAMING|SYNC
* HA-pgsql-receiver-status : normal
* HA-pgsql-status : HS:sync
* master-HA-pgsql : 100
Migration Summary:
HA-pgsql-status
PRI – состояние мастера
HS:sync – синхронная реплика
HS:async – асинхронная реплика
HS:alone – реплика не может подключится к мастеру
STOP – PostgreSQL остановлен
HA-pgsql-data-status
LATEST – состояние, присущее мастеру. Данный узел является мастером.
STREAMING:SYNC/ASYNC – показывает состояние репликации и тип репликации (SYNC/ASYNC)
DISCONNECT – реплика не может подключиться к мастеру. Обычно такое бывает, когда нет соединения от реплики к мастеру.
HA-pgsql-master-baseline
Показывает линию времени. Линия времени меняется каждый раз после выполнения команды promote на узле-реплике. После этого СУБД начинает новый отсчет времени.
HA-pgsql-receiver-status
normal (master) – состояние, присущее мастеру. Данный узел является мастером.
normal – нормальное состояние, присущее узлу-реплике. На ведомом устройстве запущен и работает процесс приёмника WAL.
Error – на ведомом устройстве не работает процесс приёмника WAL или отсутствует коммуникация отправителя и приёмника WAL.
На этом базовая настройка отказоустойчивого кластера PostgreSQL и Платформы НЕЙРОСС окончена.
Дополнительно стоит обратить внимание, что сервис pcsd имеет встроенный пользовательский веб-интерфейс, который доступен по адресу любого узла на порту 2224. Работает очень медленно. На данном примере ссылка на него будет:
Браузеру «не понравится» самоподписанный сертификат, но с этим надо согласиться или подложить на узлы доверенные сертификаты. Веб-интерфейс также доступен и по общему виртуальному адресу и тому же порту 2224.
Для входа необходимо использовать учётные данные пользователя кластера — hacluster и его пароль.
При первом входе необходимо выполнить добавление существующего кластера командой + Add Existing и ввести имя одного из узлов кластера.
Через некоторое время запись о кластере появится в пользовательском интерфейсе. Выбрав кластер путём выбора соответствующего чекбокса справа отобразится обобщённая сводная информация о кластере, его узлах и ресурсах. Нажав левой клавишей мыши по имени кластера вы сможете перейти в управление кластером, узлами и ресурсами.
Полезные команды
Для мониторинга (отслеживания) состояния кластера в реальном времени можно использовать команду:
Перевод узла в standby
Возврат узла из standby
Если PostgreSQL (ресурс HA-pgsql) остаётся в состоянии "Stopped" на узле node2 и "Failed Resource Actions" листинг выводит "error", выполните для диагностики:
Если узел сообщит:
'My data may be inconsistent. You have to remove /var/lib/pgsql/tmp/PGSQL.lock file to force start.'
Необходимо удалить файл /var/lib/pgsql/tmp/PGSQL.lock для возможности старта
Для удаления и очистки счётчика сбоев выполните:
sudo pcs resource cleanup HA-pgsql
Проверка конфигурации:
При отсутствии ошибок:
Проверка сбоев у конкретного ресурса (например, HA-pgsql), которые препятствуют его старту:
Проверка сбоев у всех ресурсов, которые препятствуют их старту:
Очистка счётчика всех сбоев (применяется после устранения причин сбоя):
Очистка счётчика сбоев фенсинга узла NODE2 (применяется после устранения причин сбоя):
утилита crm_resource | утилита crm |
|---|---|
Вывод поддерживаемых стандартов (классов) ресурсов кластера | |
sudo crm_resource --list-standards | sudo crm ra classes |
Вывод поддерживаемых агентов ресурсов кластера для определенного стандарта | |
доступные systemd агенты sudo crm_resource --list-agents systemd доступные lsb агенты sudo crm_resource --list-agents lsb | sudo crm ra list systemd sudo crm ra list lsb |
доступные OCF провайдеры sudo crm_resource --list-ocf-providers | |
доступные OCF агенты из проекта linux-ha провайдер heartbeat sudo crm_resource --list-agents ocf:heartbeat | |
доступный OCF провайдер для агента pgsql sudo crm_resource --list-ocf-alternatives pgsql | |
метаданные для класс:провайдер:агент sudo crm_resource --show-metadata ocf:heartbeat:pgsql | |
Логи работы компонентов кластера
sudo tail /var/log/corosync/corosync.log
sudo cat /var/log/pacemaker/pacemaker.log
запуск с ключом -f позволит следить за ними в реальном времени.
Создание ресурсов фенсинга
Для защиты разделяемых ресурсов и изоляции узла кластера при его неисправности существует механизм фенсинга (изоляции).
Во избежание ситуации появления двух Мастеров (например, в следствии потери сетевой связанности между узлами) необходимо наличие устройств «фенсинга» на узлах с СУБД и сервисами. При возникновении сбоя такие устройства «фенсинга» изолируют «сбойнувший» узел – посылают команду на выключение питания или перезагрузку (poweroff или hard-reset).
Чтобы вывести список доступных агентов fence-agents используйте команду:
Для тестовых целей можно использовать следующую конфигурацию с агентом external/ssh:
configure
primitive st-ssh stonith:external/ssh params hostlist="node1 node2"
clone fencing st-ssh
property stonith-enabled=true
commit
exit
Пример 1. Использование двух механизмов фенсинга узлов на примере фенсинга виртуальных машинах
При использовании виртуальных машин в качестве узлов кластера можно использовать агент external/libvirt. Далее рассмотрим настройку конфигурации, в которой сервер с гипервизором имеет адрес 10.1.30.249, а узлы, как описано выше. В примере будут использоваться два фенсинг механизма – ssh и libvirt.
Чтобы вывести необходимые настройки для выбранного агента выполните команду:
Основным механизмом фенсинга виртуальных машин является агент libvirt (или vcenter, xen и т.д.), но в случае, если хост виртуальной машины (гипервизор) не работает, фенсинг через libvirt никогда не будет успешным.
Идея состоит в том, чтобы реализовать второй механизм фенсинга, например, IPMI, который сработает при выходе из строя первого механизма.
Для демонстрации идеи, в этом примере наоборот первым механизмом фенсинга будет агент ssh (фенсинг узла на виртуальной машине), а вторым механизмом будет агент libvirt (фенсинг виртуальной машины на хосте гипервизора). Таким образом, что если виртуальная машина (node1 или node2) зависла и не может управляться агентом ssh, то фенсинг будет осуществлён через libvirt и, соответственно, сервер с гипервизором, на котором эта машина работает.
Обменяемся ssh ключами между узлами кластера (виртуальными машинами).
Для этого на узле node1 сгенерируем ключ, передадим на узел node2 и проверим сессию
ssh-copy-id user@node2
ssh user@node2
exit
аналогично на узле node2
ssh-copy-id user@node1
ssh user@node1
exit
Сконфигурируем ресурсы фенсинга
confugure
primitive fence-node1-libvirt stonith:external/libvirt \
params hostlist=node1 hypervisor_uri="qemu+ssh://10.1.30.249/system" reset_method=power_cycle \
op monitor interval=180 timeout=30 \
meta target-role=Started
primitive fence-node1-ssh stonith:ssh \
params hostlist=node1 stonith-timeout=30 \
meta target-role=Started
primitive fence-node2-libvirt stonith:external/libvirt \
params hostlist=node2 hypervisor_uri="qemu+ssh://10.1.30.249/system" reset_method=power_cycle \
op monitor interval=180 timeout=30 \
meta target-role=Started
primitive fence-node2-ssh stonith:ssh \
params hostlist=node2 stonith-timeout=30 \
meta target-role=Started
location l-fence-node1-libvirt fence-node1-libvirt -inf: node1
location l-fence-node1-ssh fence-node1-ssh -inf: node1
location l-fence-node2-libvirt fence-node2-libvirt -inf: node2
location l-fence-node2-ssh fence-node2-ssh -inf: node2
fencing_topology \
node2: fence-node2-ssh fence-node2-libvirt \
node1: fence-node1-ssh fence-node1-libvirt
property cib-bootstrap-options: \
stonith-enabled=yes \
no-quorum-policy=ignore \
placement-strategy=balanced \
dc-version=1.1.12-ad083a8 \
cluster-infrastructure=corosync \
cluster-name=hacluster \
stonith-timeout=90 \
last-lrm-refresh=1420721144
rsc_defaults rsc-options: \
resource-stickiness=1 \
migration-threshold=3
op_defaults op-options: \
timeout=600 \
record-pending=true
commit
exit
Перезагружаем все виртуальные машины в кластере.
Пример 2. Фенсинг узлов адаптером удалённого супервизора (RSA)
Реальная конфигурация не сильно отличается от тестовой, хотя для некоторых фенсинг устройств может потребоваться больше атрибутов. Например, устройство отключения IBM RSA (например, с адресами 10.1.31.101 и 10.1.31.102) может быть настроено следующим образом:
configure
primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \
params nodename=node1 ipaddr=10.1.31.101 \
userid=USERID passwd=PASSW0RD
primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \
params nodename=node2 ipaddr=10.1.31.102 \
userid=USERID passwd=PASSW0RD
# st-ibmrsa-1 может работать где угодно, но не на узле node1
location l-st-node1 st-ibmrsa-1 -inf: node1
# st-ibmrsa-2 может работать где угодно, но не на узле node2
location l-st-node2 st-ibmrsa-2 -inf: node2
commit
Пример 3. Фенсинг узлов агентом источников бесперебойного питания APC PDU
Ниже приведен полный пример двухузлового кластера, в котором каждый сервер имеет один источник питания, подключенный к общему APC PDU на разные розетки:
ipaddr="10.1.31.11" \
login="apc" \
password="apc" \
pcmk_host_list="node1,node2" \
pcmk_host_check="static-list" \
pcmk_host_map="node1:7;node2:8"
ipaddr – это IP-адрес контроллера APC PDU. Внимание, это не IP-адрес узла, который будет изолирован.
login и password используются для предоставления учетных данных для входа в контроллер APC PDU.
pcmk_host_map – сопоставляет имя узла в pacemaker с номером порта на PDU, представляющем физическую розетку ИБП APC. Каждая запись в списке имеет формат <имя узла>:<номер порта PDU> (двоеточие отделяет узел от порта), а записи между собой разделяются точкой с запятой.
Пример 4. Фенсинг узлов с резервными источниками питания и несколькими источниками бесперебойного питания APC PDU
Когда серверы имеют резервные источники питания с несколькими подключениями к источникам бесперебойного питания, важно, чтобы кластер pacemaker мог отключать питание всех блоков питания в сервере при попытке изолировать узел.
Для этого должно быть определение фенсинг агента для каждого PDU, который подаёт питание на серверы узлов в кластере.
В следующем примере определены два фенсинг агента APC:
ipaddr="10.1.30.11" \
login="apc" \
password="apc" \
pcmk_host_list="node1,node2" \
pcmk_host_check="static-list" \
pcmk_host_map="node1:7;node2:8"
sudo pcs stonith create node1-node2-power-apc2 stonith:apcmaster \
ipaddr="10.1.30.12" \
login="apc" \
password="apc" \
pcmk_host_list="node1,node2" \
pcmk_host_check="static-list" \
pcmk_host_map="node1:7;node2:8"
В этом примере каждый сервер подключен к одному и тому же порту питания (физической розетке) на каждом из двух PDU. Это может быть не всегда, поэтому убедитесь, что pcmk_host_map отражает физическую конфигурацию каждого PDU.
Чтобы гарантировать, что все определенные порты питания (розетки) каждого PDU отключены одновременно, фенсинг агенты должны быть сгруппированы в уровень фенсинга. Уровень – это разделённый запятыми список фенсинг ресурсов, которые необходимо выполнить, чтобы изолировать (выключить сервер) узел кластера. Уровней может быть несколько, в зависимости от сложности кластера и количества доступных вариантов фенсинга. Каждый уровень является автономным, и выполнение фенсинга прекращается, когда все фенсинг агенты на данном уровне завершаются с успешным кодом выхода (завершения).
Если на уровне STONITH определено несколько агентов, все агенты должны успешно завершиться, хотя они не обязательно должны работать одновременно.
В продолжение этого примера, уровни STONITH можно определить следующим образом:
node1-node2-power-apc1,node1-node2-power-apc2
sudo pcs stonith level add 1 node2 \
node1-node2-power-apc1,node1-node2-power-apc2
Пример 5. Фенсинг узлов на виртуальных машинах
При использовании виртуальных машин в качестве узлов кластера можно использовать агент fence_virsh. Далее рассмотрим настройку конфигурации, в которой сервер с гипервизором имеет адрес 10.1.30.249, а узлы, как описано выше.
Чтобы вывести необходимые настройки для выбранного агента используйте команду:
Настройка доступа по ssh
Чтобы настроить доступ по ssh к серверу с гипервизором под пользователем root по ключу выполните следующие действия.
На сервере в файле /etc/ssh/sshd_config установите значение параметра PermitRootLogin равное yes.
Перезагрузите службу на сервере sshd:
На каждом узле сгенерируйте ключи при помощи команды:
На каждом узле отправьте публичный ключ на сервер с гипервизором (например, адрес сервера гипервизора 10.1.30.249):
На сервере в файле /etc/ssh/sshd_config закомментируйте параметр PermitRootLogin (чтобы он не применялся в конфигурации).
Перезагрузите на сервере службу sshd для применения настроек:
Для проверки работы fence_virsh перед настройкой можно использовать команду:
Параметры команды:
-a 10.1.30.249 - IP-адрес сервера, на котором запущен гипервизор KVM;
-l root - логин пользователя для подключения к серверу с гипервизором по ssh;
-n node1 — название виртуальной машины в гипервизоре;
-k /home/user/.ssh/id_rsa - путь к ключу, созданному при помощи команды ssh-keygen.
В результате выполнения команда выведет список всех виртуальных машин в гипервизоре.
Теперь следует создать и настроить ресурсы фенсинга для всех узлов кластера. Выполните следующие действия.
Создайте ресурс фенсинга fence_node1 для первого узла (node1) при помощи команды:
identity_file="/home/u/.ssh/id_rsa" pcmk_reboot_action="reboot" pcmk_monitor_timeout=60s plug=node1
Параметры команды:
pcmk_host_list - какими узлами кластера может управлять данный ресурс;
plug - название виртуальной машины в гипервизоре.
Аналогично создайте ресурс fence_node2 для узла node2.
identity_file="/home/u/.ssh/id_rsa" pcmk_reboot_action="reboot" pcmk_monitor_timeout=60s plug=node2
После создания ресурсов фенсинга для каждого узла, необходимо настроить их таким образом, чтобы они не запускались на тех узлах, для перезагрузки которых они созданы.
Для ресурса fence_node1 выполните команду:
Выполните аналогичную команду для других узлов:
Перезагрузите все виртуальные машины в кластере.
Синхронизация ресурсов из файловой системы
Таким образом, должны синхронизироваться файли и каталоги 2, 3, 4 и 6. Файлы и каталоги 1 и 5 должны синхронизироваться в случаях определённых конфигураций и состава.
Для синхронизации объектов файловой системы (файлы и директории) между узлами будем использовать демон rsyncd (утилита rsync) с соответствующей конфигурвацией rsyncd.conf. Проверить налличие утилиты в составе развёрнутой операционной системы можно выполнив запрос состояния сервиса rsync (или, в зависимости от версии операционной системы, rsyncd):
● rsync.service - fast remote file copy program daemon
Loaded: loaded (/lib/systemd/system/rsync.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Tue 2021-11-16 09:35:14 MSK; 5h 12min ago
Docs: man:rsync(1)
man:rsyncd.conf(5)
Nov 16 09:35:14 node1 systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.
Таким образом, на каждом из узлов node1 и node2 необходимо поменять владельца только для одной директории (остальные находятся в домашней директории пользователя ultima-vmc):
Для того, что текущий пользователь имел возможность исполнять удалённо утилиту rsync от имени другого пользователя (напомним, в нашем случае от имени пользователя ultima-vmc) необходимо предоставить ему эти разрешения и, так как узлы у нас симметричные, то выполнить это необходимо на каждом из узлов node1 и node2. (в примере таким пользователем является пользователь с именем user)
cat > /etc/sudoers.d/user << EOF
user ALL=(ALL) NOPASSWD:/usr/bin/rsync
EOF
exit
Если узлы не обменялись ключами сессий ssh пользователей как описано в настройках фенсинга Пример 1, то необходимо это выполнить и обменяться ssh ключами между узлами кластера.
Для этого на узле node1 сгенерируем ключ, передадим его на узел node2 и проверим сессию
ssh-copy-id user@node2
ssh user@node2
exit
аналогично на узле node2
ssh-copy-id user@node1
ssh user@node1
exit
Теперь можно выполнить синхронизацию объектов файловой системы. В нашем случае передать актуальные файлы с узла node1 на узел node2
rsync --rsync-path="sudo -u ultima-vmc rsync" -avz -e ssh /home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml user@10.1.30.252:/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml
rsync -avzr -e ssh --rsync-path="sudo -u ultima-vmc rsync" /home/ultima-vmc/Neyross/ultima-vmc/resources/ 10.1.30.252:/home/ultima-vmc/Neyross/ultima-vmc/resources/
На этом можно остановиться, т.к. в реальном времени файловые объекты не изменяются в процессе штатной работы прикладных программных средств. Изменения могут возникать при:
- обновлении прикладных программных средств
- расширении функций и/или изменении состава лицензий
- изменении конфигурации прикладных программных средств
Во всех этих случаях, а также при восстановлении узла после сбоя, синхронизацию можно выполнять вручную по завершению восстановительных работ или внесённых изменений.
Автоматическая синхронизация пока не видится целесообразной.
Unknown macro: expand. Click on this message for details.
Виды планового обслуживания отказоустойчивого кластера
Для проведения регламентных работ необходимо периодически выводить из состава кластера отдельные узлы:
- Выведение из эксплуатации Мастера или Реплики для плановых работ нужно в следующих случаях
- Замена вышедшего из строя оборудования (не приведшего к сбою);
- Обновление оборудования;
- Обновление программных средств;
- Смена ролей Мастера и Реплики. Это нужно в случае, когда, серверы Мастера и Реплики отличаются по ресурсам. Например, у нас в составе отказоустойчивого кластера есть мощный сервер, выполняющий роль Мастера СУБД PostgreSQL, и слабый сервер, выполняющий роль Реплики. После сбоя более мощного сервера Мастера его функции переходят к более слабой Реплике. Логично, что после устранения причин сбоя на бывшем Мастере администратор вернёт роль Мастера обратно на мощный сервер.
Типовая процедура восстановления кластера с возвратом ролей (исходно NODE1 роль Master и NODE2 роль Slave). Например, требуется проведение регламента на железе узла NODE1.
- Перевод узла node1 в standby
- Проверка в crm_mon -Afr состояние узла NODE1 STANDBY, роль Master перешла узлу NODE2, изменение состояния реплики (параметр HA-pgsql-data-status в значении DISCONNECT)
- Останов, проведение регламентных работ, в crm_mon -Afr состояние узла NODE1 OFFLINE
- Запуск узла NODE1 , в crm_mon -Afr состояние узла STANDBY
- Очистка директории СУБД и файла блокировки
sudo su - postgres
rm -rf /var/lib/postgresql/12/main/*
- Передача текущей копии БД с действующего узла в роли Master
exit
- Сброс ошибок ресурсов
- Выход узла NODE1 из standby, в crm_mon -Afr состояние узла Slave, изменение состояния реплики (параметр HA-pgsql-data-status в значении STREAMING|SYNC)
- Перевод узла NODE2 в standby
- Проверка в crm_mon -Afr состояние узла node2 STANDBY, роль Master перешла узлу node1, изменение состояния реплики (параметр HA-pgsql-data-status в значении DISCONNECT)
- Выход узла node2 из standby, в crm_mon -Afr состояние узла Slave, изменение состояния реплики (параметр HA-pgsql-data-status в значении STREAMING|SYNC)