.

• FAILOVER-процедуры
  • Запуск на одном действующем мастер-узле
    • Запуск управляющего демона:
    • Перенос виртуальных машин с аварийного узла
    • Запуск всех виртуальных машин
  • Штатное переключение master-узла
  • Выход из строя master-узла
  • Возврат основного узла в строй
  • Плановый вывод узла из эксплуатации
    • Возврат узла в кластер
  • Замена узла на новый
  • Замена жесткого диска

FAILOVER-процедуры¶

Обозначения:

gnt# - запуск команды на мастер-узле
gntX# - запуск команды на обычном узле
gntY# - запуск команды на другом узле
# - запуск команды на любом узле

Запуск на одном действующем мастер-узле¶

При запуске на одном узле, управление кластером ganeti-masterd не стартует автоматически, даже на master-узле.
Это связано с тем, что невозможно отличить крах второго узла от потери связи, когда на втором узле продолжают работать запущенные виртуалки.

Запуск управляющего демона:¶

gnt# ganeti-masterd --no-voting

Перенос виртуальных машин с аварийного узла¶

Эта операция выполняется один раз. Она поменяет узел запуска для виртуальной машины.
Перенесенные машины автоматически запустятся, если таково их состояние по-умолчанию.

Лучше мигрировать или перезапустить виртуальные машины в штатном режиме, до того, как их узел будет отключен.
Однако, если это случилось внезапно, тогда необходимо дать команду:

gnt# gnt-node failover --ignore-consistency gntX

Запуск всех виртуальных машин¶

gnt# gnt-instance startup --force --all

Штатное переключение master-узла¶

Оба узла запущены, смена master-узла производится в штатном режиме.
На master-candidate (gntX):

gntX# gnt-cluster master-failover

Выход из строя master-узла¶

Основной узел (в примере - gnt1) оказывается выключен в результате аппаратной аварии.

Запустить управляющий демон на узле master-candidate (gntX):

gntX# ganeti-masterd --no-voting

Активировать новый master-узел:

gntX# gnt-cluster master-failover --no-voting

Пометить отключенный узел offline, чтобы master в него не долбился
-С = master-candidate
-O = offline

gnt# gnt-node modify -C no -O yes gntY

Запустить все виртуалки отключенного узла на резервном:

gnt# gnt-node failover --ignore-consistency gnt1

Возврат основного узла в строй¶

Старый основной узел не будет автоматически запускать управляющего демона.

• если не найдет парного узла,
• если найдет парный узел и узнает, что он стал новым master-ом.

Если при отключении узла он помечался как offline (см. выше), то надо вернуть его в строй:

gnt# gnt-node modify -C yes -O no gntX

Если на узле сохранились данные, то для включения его обратно в кластер:

Скопировать на него свежую конфигурацию с нового master-а

gnt# gnt-cluster redist-conf

Запустить на нем ganeti-демоны

gntX# /etc/init.d/ganeti restart

Плановый вывод узла из эксплуатации¶

Мигрируем виртуальные машины:

gnt# gnt-instance migrate имя_машины

Если выводимый узел - мастер, то нужно назначить нового мастера(см. выше Штатное переключение master узла).

Вывести узел из списка кандидатов на мастера и перевести его в режим offline (это предотвратит появление сообщений об "аварии"):

gnt# gnt-node modify -C no -O yes УЗЕЛ

Далее узел можно просто выключить.

Возврат узла в кластер¶

После включения узла нужно сообщить кластеру, что узел вернулся в строй:

gnt# gnt-node modify -C yes -O no УЗЕЛ

Однако, если у вас имеются сомнения в том, что узел остался в рабочем состоянии, то лучше выполнить:

gnt# gnt-node add --readd УЗЕЛ

В любом случае, после этого нужно подождать около 5 минут, чтобы демон watcher поднял drbd, либо инициировать процесс вручную:

gnt# gnt-cluster verify-disks

Замена узла на новый¶

Удалить старый узел из /root/.ssh/known_hosts

Добавить узел в кластер

gnt# gnt-node add --readd gntX

Для всех виртуалок, которые имеют secondary на подключенном узле:

gnt# gnt-instance replace-disks --auto [--submit] INSTANCE

Перерегистрировать узел в puppet

gnt# gnt-instance console sci
sci# puppetca --clean gntX.fqdn

gntX# rm -r /var/lib/puppet/ssl/*
gntX# /etc/init.d/puppet restart

Замена жесткого диска¶

Скопировать разметку с существующего (только для дисков одной модели!)

# sfdisk -d /dev/sda|sfdisk /dev/sdX

Проверить

# fdisk -l

Добавить в RAID

# mdadm --manage /dev/md0 --add /dev/sdX1
# mdadm --manage /dev/md1 --add /dev/sdX2
# mdadm --manage /dev/md2 --add /dev/sdX3

Проверить

cat /proc/mdstat

ПРИМЕЧАНИЕ: Мы настоятельно рекомендуем освбождать узел, на котором происходит воссоздание RAID-массива
от выполняющихся виртуальных машин и переносить их (предварительно) на парный узел.

В период воссоздания RAID-массива отдельные системные процессы, связанные с виртуализацией могут вызвать нестабильность
системы и привести к зависанию виртуальных машин.