Глава 54. Отказоустойчивый кластер (High Availability) на основе Pacemaker
Pacemaker — менеджер ресурсов кластера (Cluster Resource Manager), задачей которого является достижение максимальной доступности управляемых им ресурсов и защита их от сбоев как на уровне самих ресурсов, так и на уровне целых узлов кластера. Ключевые особенности Pacemaker:
обнаружение и восстановление сбоев на уровне узлов и сервисов;
возможность гарантировать целостность данных путем ограждения неисправных узлов;
поддержка одного или нескольких узлов на кластер;
поддержка нескольких стандартов интерфейса ресурсов (все, что может быть написано сценарием, может быть кластеризовано);
независимость от подсистемы хранения — общий диск не требуется;
поддержка и кворумных и ресурсозависимых кластеров;
автоматически реплицируемая конфигурация, которую можно обновлять с любого узла;
возможность задания порядка запуска ресурсов, а также их совместимости на одном узле;
поддерживает расширенные типы ресурсов: клоны (когда ресурс запущен на множестве узлов) и дополнительные состояния (master/slave и подобное);
единые инструменты управления кластером с поддержкой сценариев.
Архитектура Pacemaker представляет собой три уровня:
кластеронезависимый уровень — на этом уровне располагаются ресурсы и их скрипты, которыми они управляются и локальный демон, который скрывает от других уровней различия в стандартах, использованных в скриптах;
менеджер ресурсов (Pacemaker) — реагирует на события, происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. Pacemaker, исходя из сложившейся ситуации, делает расчет наиболее оптимального состояния кластера и дает команды на выполнение действий для достижения этого состояния (остановка/перенос ресурсов или узлов);
информационный уровень (Corosync) — на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд (запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера (quorum) и т.д.
Узел (node) кластера представляет собой физический сервер или виртуальную машину с установленным Pacemaker. Узлы, предназначенные для предоставления одинаковых сервисов, должны иметь одинаковую конфигурацию.
Ресурсы, с точки зрения кластера, это все используемые сущности — сервисы, службы, точки монтирования, тома и разделы. При создании ресурса потребуется задать его класс, тип, провайдера и собственно имя с дополнительными параметрами. Ресурсы поддерживают множество дополнительных параметров: привязку к узлу (resource-stickiness), роли по умолчанию (started, stoped, master) и т.д. Есть возможности по созданию групп ресурсов, клонов (работающих на нескольких узлах) и т.п.
Связи определяют привязку ресурсов к узлу (location), порядок запуска ресурсов (ordering) и совместное их проживание на узле (colocation).
Ниже приведена инструкция по установке и настройке кластера в Альт Сервер.
54.1. Настройка узлов кластера
Для функционирования отказоустойчивого кластера необходимо, чтобы выполнялись следующие требования:
дата и время между узлами в кластере должны быть синхронизированы;
должно быть обеспечено разрешение имён узлов в кластере;
сетевые подключения должны быть стабильными;
у узлов кластера для организации изоляции узла (fencing) должны присутствовать функции управления питанием/перезагрузкой с помощью IPMI(ILO);
следующие порты могут использоваться различными компонентами кластеризации: TCP-порты 2224, 3121 и 21064 и UDP-порт 5405 и должны быть открыты/доступны.
В примере используется следующая конфигурация:
node01 — первый узел кластера (IP 192.168.0.113/24);
node02 — второй узел кластера (IP 192.168.0.145/24);
node03 — третий узел кластера (IP 192.168.0.132/24);
192.168.0.251 — виртуальный IP по которому будет отвечать один из узлов.
Дальнейшие действия следует выполнить на всех узлах кластера.
Рекомендуется использовать короткие имена узлов. Для изменения имени хоста без перезагрузки, можно воспользоваться утилитой
hostnamctl:
# hostnamectl set-hostname node01
54.1.1. Настройка разрешений имён узлов
Следует обеспечить взаимно-однозначное прямое и обратное преобразование имён для всех узлов кластера. Желательно использовать DNS, в крайнем случае, можно обойтись соответствующими записями в локальных файлах
/etc/hosts на каждом узле:
# echo "192.168.0.113 node01" >> /etc/hosts
# echo "192.168.0.145 node02" >> /etc/hosts
# echo "192.168.0.132 node03" >> /etc/hosts
Проверка правильности разрешения имён:
# ping node01
PING node01 (192.168.0.113) 56(84) bytes of data.
64 bytes from node01 (192.168.0.113): icmp_seq=1 ttl=64 time=0.352 ms
# ping node02
PING node02 (192.168.0.145) 56(84) bytes of data.
64 bytes from node02 (192.168.0.145): icmp_seq=1 ttl=64 time=0.635 ms
54.1.2. Настройка ssh-подключения между узлами
При настройке ssh-подключения для root по ключу необходимо убрать комментарии в файле
/etc/openssh/sshd_config для строк:
PermitRootLogin without-password
PubkeyAuthentication yes
AuthorizedKeysFile /etc/openssh/authorized_keys/%u /etc/openssh/authorized_keys2/%u .ssh/authorized_keys .ssh/authorized_keys2
PasswordAuthentication yes
Кроме того, полезно добавить в
/etc/openssh/sshd_config директиву:
AllowGroups sshusers
создать группу sshusers:
# groupadd sshusers
и добавить туда пользователей, которым разрешено подключаться по ssh:
# gpasswd -a <username> sshusers
Создать новый ключ SSH без пароля (параметр
-N):
# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
Незащищенные ключи SSH (без пароля) не рекомендуются для серверов, открытых для внешнего мира.
Скопировать публичную часть SSH-ключа на другие узелы кластера:
# ssh-copy-id -i ~/.ssh/id_ed25519.pub user@node02
# ssh-copy-id -i ~/.ssh/id_ed25519.pub user@node03
В результате получаем возможность работы с домашними каталогами пользователя user удалённого узла — копировать к себе и от себя, удалять, редактировать и т.д.
Скопировать публичную часть SSH-ключа на все узлы кластера для администратора. Для этого подключиться к каждому узлу и под root скопировать публичную часть ключа:
# ssh user@node02
user@node02 $ su -
node02 # cat /home/user/.ssh/authorized_keys >> /root/.ssh/authorized_keys
node02 # exit
user@node02 $ exit
Каталог /root/.ssh при этом должен существовать.
Убедиться, что теперь можно запускать команды удалённо, без пароля:
# ssh node02 -- uname -n
node02
