Глава 31. Настройка отказоустойчивого кластера
В данном разделе рассмотрена настройка отказоустойчивого кластера (High Available, HA) для основных служб OpenNebula: core (oned), scheduler (mm_sched).
OpenNebula использует распределенный консенсусный протокол Raft, для обеспечения отказоустойчивости и согласованности состояний между службами. Алгоритм консенсуса построен на основе двух концепций:
Состояние системы — данные, хранящиеся в таблицах базы данных (пользователи, списки управления доступом или виртуальные машины в системе).
Журнал (Log) — последовательность операторов SQL, которые последовательно применяются к базе данных OpenNebula на всех серверах для изменения состояния системы.
Чтобы сохранить согласованное представление о системе на всех серверах, изменения состояния системы выполняются через специальный узел, лидер или ведущий (Leader). Leader периодически посылает запросы (heartbeats) другим серверам, ведомым (Follower), чтобы сохранить свое лидерство. Если Leader не может послать запрос, Follower-серверы продвигаются к кандидатам и начинают новые выборы.
Каждый раз, когда система изменяется (например, в систему добавляется новая ВМ), Leader обновляет журнал и реплицирует запись у большинства Follower, прежде чем записывать её в базу данных. Таким образом, увеличивается задержка операций с БД, но состояние системы безопасно реплицируется, и кластер может продолжить свою работу в случае отказа узла.
Для настройки High Available требуется:
нечетное количество серверов (рекомендуемый размер развертывания — 3 или 5 серверов, что обеспечивает отказоустойчивость при отказе 1 или 2 серверов соответственно);
рекомендуется идентичная конфигурация серверов;
идентичная программная конфигурация серверов (единственное отличие — это поле SERVER_ID в /etc/one/oned.conf);
рекомендуется использовать подключение к базе данных одного типа (MySQL);
серверы должны иметь беспарольный доступ для связи друг с другом;
плавающий IP, который будет назначен лидеру;
общая файловая система.
Добавлять дополнительные серверы или удалять старые можно после запуска кластера.
В данном примере показана настройка HA кластера из трех серверов:
31.1. Первоначальная конфигурация Leader
Запустить сервис OpenNebula и добавить локальный сервер в существующую или новую зону (в примере зона с ID 0):
$ onezone list
C ID NAME ENDPOINT FED_INDEX
* 0 OpenNebula http://localhost:2633/RPC2 -1
$ onezone server-add 0 --name opennebula --rpc http://192.168.0.186:2633/RPC2
$ onezone show 0
ZONE 0 INFORMATION
ID : 0
NAME : OpenNebula
ZONE SERVERS
ID NAME ENDPOINT
0 opennebula http://192.168.0.186:2633/RPC2
HA & FEDERATION SYNC STATUS
ID NAME STATE TERM INDEX COMMIT VOTE FED_INDEX
0 opennebula solo 0 -1 0 -1 -1
ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Остановить сервис opennebula и обновить конфигурацию SERVER_ID в файле
/etc/one/oned.conf:
FEDERATION = [
MODE = "STANDALONE",
ZONE_ID = 0,
SERVER_ID = 0, # изменить с -1 на 0 (0 — это ID сервера)
MASTER_ONED = ""
]
Включить Raft-обработчики, чтобы добавить плавающий IP-адрес в кластер (файл
/etc/one/oned.conf):
RAFT_LEADER_HOOK = [
COMMAND = "raft/vip.sh",
ARGUMENTS = "leader enp0s3 192.168.0.200/24"
]
# Executed when a server transits from leader->follower
RAFT_FOLLOWER_HOOK = [
COMMAND = "raft/vip.sh",
ARGUMENTS = "follower enp0s3 192.168.0.200/24"
]
Запустить сервис OpenNebula и проверить зону:
$ onezone show 0
ZONE 0 INFORMATION
ID : 0
NAME : OpenNebula
ZONE SERVERS
ID NAME ENDPOINT
0 opennebula http://192.168.0.186:2633/RPC2
HA & FEDERATION SYNC STATUS
ID NAME STATE TERM INDEX COMMIT VOTE FED_INDEX
0 opennebula leader 1 5 5 0 -1
ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC
Сервер opennebula стал Leader-сервером, так же ему был присвоен плавающий адрес (Floating IP):
$ ip -o a sh enp0s3
2: enp0s3 inet 192.168.0.186/24 brd 192.168.0.255 scope global enp0s3\ valid_lft forever preferred_lft forever
2: enp0s3 inet 192.168.0.200/24 scope global secondary enp0s3\ valid_lft forever preferred_lft forever
2: enp0s3 inet6 fe80::a00:27ff:fec7:38e6/64 scope link \ valid_lft forever preferred_lft forever
