SCI-CD

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

{{toc}}

[[OVERVIEW]] | [[INSTALL]] | [[SETUP]] | [[OPERATIONS]] | [[LICENSE]]
[[ОБЗОР]] | [[УСТАНОВКА]] | [[НАСТРОЙКА]] | [[ОПЕРАЦИИ]] | [[ЛИЦЕНЗИЯ]]

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

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

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

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

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

<pre>
service ganeti restart
</pre>

Если сервис не запускается по причине отсутствия второго узла в сети, то следует запустить его принудительно:
<pre>
gnt# ganeti-masterd --no-voting
</pre>
для SCI версии 2 и выше ganeti 2.10:
<pre>
gnt-cluster master-failover --no-voting
</pre>
<pre>
su - gnt-masterd -s /bin/bash -c "/usr/sbin/ganeti-masterd --no-voting"
</pre>


для sci-3.0:
&lt;pre&gt;
su - gnt-masterd -s /bin/bash -c &quot;/usr/sbin/ganeti-wconfd --no-voting --yes-do-it&quot;
su - gnt-masterd -s /bin/bash -c &quot;/usr/sbin/ganeti-luxid --no-voting --yes-do-it&quot;
&lt;/pre&gt;
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. Перевод виртуалки слейва дрбд на другую ноду

Переносим слейв дрбд виртуалки на другую ноду gntX

<pre>
gnt-instance replace-disks --new-secondary gntX instance_name
</pre>

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

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

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

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

</pre>
для ganeti 2.10:
<pre>
su - gnt-masterd -s /bin/bash -c "/usr/sbin/ganeti-masterd --no-voting"
</pre>
<pre>
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. Замена узла на новый

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

Добавить узел в кластер
<pre>
gnt# gnt-node add --readd gntX
</pre>
<pre>
gnt# gnt-cluster redist-conf
</pre>
Для всех виртуалок, которые имеют secondary на подключенном узле:
<pre>
gnt# gnt-instance replace-disks --auto INSTANCE
</pre>

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

<pre>
gntX# rm -r /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>

h2. Восстановление при split-brain:

Если при activate-disks или при команде запуска/фейловера drbd ругается следующим образом в dmesg:
<pre>
[10893282.055705] block drbd21: Handshake successful: Agreed network protocol version 96
[10893282.056003] block drbd21: Peer authenticated using 16 bytes of 'md5' HMAC
[10893282.056008] block drbd21: conn( WFConnection -> WFReportParams )
[10893282.056031] block drbd21: Starting asender thread (from drbd21_receiver [20355])
[10893282.056303] block drbd21: data-integrity-alg: <not-used>
[10893282.056319] block drbd21: drbd_sync_handshake:
[10893282.056322] block drbd21: self 5323ED521900E1F9:FCBCCB0FBF14BA04:480CD30FE2A601EA:480BD30FE2A601EB bits:46 flags:0
[10893282.056324] block drbd21: peer F3B949426796C7F8:FCBCCB0FBF14BA05:480CD30FE2A601EB:480BD30FE2A601EB bits:12288 flags:2
[10893282.056326] block drbd21: uuid_compare()=100 by rule 90
[10893282.056329] block drbd21: helper command: /bin/true initial-split-brain minor-21
[10893282.073918] block drbd21: meta connection shut down by peer.
[10893282.073976] block drbd21: conn( WFReportParams -> NetworkFailure )
[10893282.073981] block drbd21: asender terminated
[10893282.073983] block drbd21: Terminating drbd21_asender
[10893282.080752] block drbd21: helper command: /bin/true initial-split-brain minor-21 exit code 0 (0x0)
[10893282.080754] block drbd21: Split-Brain detected but unresolved, dropping connection!
[10893282.080844] block drbd21: helper command: /bin/true split-brain minor-21
[10893282.081481] block drbd21: helper command: /bin/true split-brain minor-21 exit code 0 (0x0)
[10893282.081484] block drbd21: conn( NetworkFailure -> Disconnecting )
[10893282.081487] block drbd21: error receiving ReportState, l: 4!
[10893282.081577] block drbd21: Connection closed
[10893282.081582] block drbd21: conn( Disconnecting -> StandAlone )
[10893282.081603] block drbd21: receiver terminated
[10893282.081604] block drbd21: Terminating drbd21_receiver
[10893282.711704] block drbd22: Handshake successful: Agreed network protocol version 96
[10893282.712019] block drbd22: Peer authenticated using 16 bytes of 'md5' HMAC
[10893282.712024] block drbd22: conn( WFConnection -> WFReportParams )
[10893282.712047] block drbd22: Starting asender thread (from drbd22_receiver [23709])
[10893282.712301] block drbd22: data-integrity-alg: <not-used>
[10893282.712332] block drbd22: drbd_sync_handshake:
[10893282.712334] block drbd22: self CD794FB0989E2B95:DD71B308E6D3FE88:AD335B3ED83CE576:AD325B3ED83CE577 bits:7 flags:0
[10893282.712336] block drbd22: peer 17B47E98FD204408:DD71B308E6D3FE89:AD335B3ED83CE577:AD325B3ED83CE577 bits:3072 flags:2
[10893282.712338] block drbd22: uuid_compare()=100 by rule 90
[10893282.712341] block drbd22: helper command: /bin/true initial-split-brain minor-22
[10893282.713155] block drbd22: helper command: /bin/true initial-split-brain minor-22 exit code 0 (0x0)
[10893282.713157] block drbd22: Split-Brain detected but unresolved, dropping connection!
[10893282.713251] block drbd22: helper command: /bin/true split-brain minor-22
[10893282.713820] block drbd22: meta connection shut down by peer.
[10893282.713889] block drbd22: conn( WFReportParams -> NetworkFailure )
[10893282.713895] block drbd22: asender terminated
[10893282.713897] block drbd22: Terminating drbd22_asender
[10893282.713945] block drbd22: helper command: /bin/true split-brain minor-22 exit code 0 (0x0)
[10893282.713948] block drbd22: conn( NetworkFailure -> Disconnecting )
[10893282.713952] block drbd22: error receiving ReportState, l: 4!
[10893282.714046] block drbd22: Connection closed
[10893282.714050] block drbd22: conn( Disconnecting -> StandAlone )
[10893282.714070] block drbd22: receiver terminated
[10893282.714072] block drbd22: Terminating drbd22_receiver
[10893283.140310] block drbd21: conn( StandAlone -> Unconnected )
[10893283.140323] block drbd21: Starting receiver thread (from drbd21_worker [23682])
[10893283.140363] block drbd21: receiver (re)started
[10893283.140366] block drbd21: conn( Unconnected -> WFConnection )
[10893283.498632] block drbd22: conn( StandAlone -> Unconnected )
[10893283.498646] block drbd22: Starting receiver thread (from drbd22_worker [23702])
[10893283.498705] block drbd22: receiver (re)started
[10893283.498710] block drbd22: conn( Unconnected -> WFConnection )
</pre>
Здесь мы видим:
<pre>
[10893282.713155] block drbd22: helper command: /bin/true initial-split-brain minor-22 exit code 0 (0x0)
[10893282.713157] block drbd22: Split-Brain detected but unresolved, dropping connection!
</pre>

то, во-первых, нужно установить, где находятся актуальные данные.
Когда когда точно установлено, где актуальные данные, мы идем на ноду, где данные *битые*, и там даем команду:
<pre>
drbdsetup /dev/drbd23 invalidate
</pre>
Затем на мастере дать activate-disks для этого инстанса, и проследить, что все drbd ресурсы отсинкались.

h2. Восстановление outdated диска

Ситуация: primary узел умер, диск на secondary узле считает себя outdated.
Watcher пишет письма, содержащие в логе такую строку:
<pre>
Error while assembling disk: drbd7: can't make drbd device primary:
/dev/drbd7: State change failed: (-2) Need access to UpToDate data\n
</pre>

Виртуалка не поднимается, диски не собираются (точнее собираются и отключаются обратно).
Требуется собрать диск вручную и сказать ему что он primary

<pre>
root@gnt1:~# gnt-instance info ИНСТАНС
[skip]
- disk/0: drbd8, size 117.2G
access mode: rw
nodeA: gnt2.XXXX.ru, minor=2
nodeB: gnt3.XXXX.ru, minor=0
port: 11012
auth key: 06ca8046f1323d0b154c500f41c0d625cbd796c3
on primary: /dev/drbd2 (147:2) in sync, status *DEGRADED*
child devices:
- child 0: lvm, size 117.2G
logical_id: xenvg/813feab3-f7a5-41bb-8a34-5b053ad1c8a6.disk0_data
on primary: /dev/xenvg/813feab3-f7a5-41bb-8a34-5b053ad1c8a6.disk0_data (253:11)
- child 1: lvm, size 128M
logical_id: xenvg/813feab3-f7a5-41bb-8a34-5b053ad1c8a6.disk0_meta
on primary: /dev/xenvg/813feab3-f7a5-41bb-8a34-5b053ad1c8a6.disk0_meta (253:12)

</pre>

<pre>
root@gnt2:~# drbdsetup /dev/drbd8 disk /dev/xenvg/813feab3-f7a5-41bb-8a34-5b053ad1c8a6.disk0_data \
/dev/xenvg/813feab3-f7a5-41bb-8a34-5b053ad1c8a6.disk0_meta 0
</pre>

<pre>
root@gnt2:~# drbd-overview
0:??not-found?? Connected Secondary/Primary UpToDate/UpToDate C r-----
8:??not-found?? StandAlone Secondary/Unknown Outdated/DUnknown r-----
</pre>

root@gnt2:~# drbdsetup /dev/drbd8 primary -f

<pre>
root@gnt2:~# drbd-overview
0:??not-found?? Connected Secondary/Primary UpToDate/UpToDate C r-----
8:??not-found?? StandAlone Primary/Unknown UpToDate/DUnknown r-----
</pre>

<pre>
root@gnt2:~# drbdsetup /dev/drbd8 down
</pre>