SCI-CD

.

{{>toc}}

h1. FAILOVER-процедуры

Обозначения:
<pre>
gnt# - запуск команды на мастер-узле
gntX# - запуск команды на обычном узле
gntY# - запуск команды на другом узле
# - запуск команды на любом узле
</pre>

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

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

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

<pre>
gnt# ganeti-masterd --no-voting
</pre>

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

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

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

<pre>
gnt# gnt-node failover --ignore-consistency gntX
</pre>

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

<pre>
gnt# gnt-instance startup --force --all
</pre>

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

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

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

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

Запустить управляющий демон на узле master-candidate (gntX):
<pre>
gntX# ganeti-masterd --no-voting
</pre>

Активировать новый master-узел:
<pre>
gntX# gnt-cluster master-failover --no-voting
</pre>

Пометить отключенный узел offline, чтобы master в него не долбился
-С = master-candidate
-O = offline
<pre>
gnt# gnt-node modify -C no -O yes gntY
</pre>

Запустить все виртуалки отключенного узла на резервном:
<pre>
gnt# gnt-node failover --ignore-consistency gnt1
</pre>

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

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

Если при отключении узла он помечался как offline (см. выше), то надо вернуть его в строй:
<pre>
gnt# gnt-node modify -C yes -O no gntX
</pre>

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

Скопировать на него свежую конфигурацию с нового master-а
<pre>
gnt# gnt-cluster redist-conf
</pre>

Запустить на нем ganeti-демоны
<pre>
gntX# /etc/init.d/ganeti restart
</pre>

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

Мигрируем виртуальные машины:
<pre>
gnt# gnt-instance migrate имя_машины
</pre>

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

Вывести узел из списка кандидатов на мастера и перевести его в режим offline (это предотвратит появление сообщений об "аварии"):
<pre>
gnt# gnt-node modify -C no -O yes УЗЕЛ
</pre>

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

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

После включения узла нужно сообщить кластеру, что узел вернулся в строй:
<pre>
gnt# gnt-node modify -C yes -O no УЗЕЛ
</pre>

Однако, если у вас имеются сомнения в том, что узел остался в рабочем состоянии, то лучше выполнить:
<pre>
gnt# gnt-node add --readd УЗЕЛ
</pre>

В любом случае, после этого нужно подождать около 5 минут, чтобы демон watcher поднял drbd, либо инициировать процесс вручную:
<pre>
gnt# gnt-cluster verify-disks
</pre>

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

Добавить узел в кластер
<pre>
gnt# gnt-node add --readd gntX
</pre>

Для всех виртуалок, которые имеют secondary на подключенном узле:
<pre>
gnt# gnt-instance replace-disks --submit -s INSTANCE
</pre>

Перерегистрировать узел в puppet
<pre>
gnt# gnt-instance console sci
sci# puppetca --clean gnt1.fqdn
</pre>

<pre>
gntX# /var/lib/puppet/ssl/*
gntX# /etc/init.d/puppet restart
</pre>

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

Скопировать разметку с существующего (только для дисков одной модели!)
<pre>
# sfdisk -d /dev/sda|sfdisk /dev/sdX
</pre>
Проверить
<pre>
# fdisk -l
</pre>
Добавить в RAID
<pre>
# mdadm --manage /dev/md0 --add /dev/sdX1
# mdadm --manage /dev/md1 --add /dev/sdX2
# mdadm --manage /dev/md2 --add /dev/sdX3
</pre>
Проверить
<pre>
cat /proc/mdstat
</pre>

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

В период воссоздания RAID-массива отдельные системные процессы, связанные связи с виртуализацией могут вызвать нестабильность этим настоятельно рекомендуется ребилдить массивы на ноде в режиме оффлайн, лишенной всякой дисковой нагрузки.
системы и Как привести к зависанию виртуальных машин. ноду в это состояние, описано выше.
Здесь можно подробнее прочитать про технические подробности проблемы: (здесь ссылка на баг)