FAILOVER-процедуры » История » Версия 13
« Предыдущее -
Версия 13/39
(Разница(diff)) -
Следующее » -
Текущая версия
Dmitry Chernyak, 13.11.2012 09:31
.
- FAILOVER-процедуры
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-ом.
Если на узле сохранились данные, то для включения его обратно в кластер:
Скопировать на него свежую конфигурацию с нового 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
Замена узла на новый¶
Добавить узел в кластер
gnt# gnt-node add --readd gntX
Для всех виртуалок, которые имеют secondary на подключенном узле:
gnt# gnt-instance replace-disks --submit -s INSTANCE
Перерегистрировать узел в puppet
gnt# gnt-instance console sci sci# puppetca --clean gnt1.fqdn
gntX# /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