SCI-CD

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

{{toc}}

[[OVERVIEW]] | [[INSTALL]] | [[SETUP]] | [[OPERATIONS]] | [[LICENSE]]

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

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

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

<pre>

gnt# - запуск команды на мастер-узле

gntX# - запуск команды на обычном узле

gntY# - запуск команды на другом узле

# - запуск команды на любом узле

</pre>

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

При запуске на одном узле, управление кластером ganeti-masterd не стартует автоматически, даже на master-узле.

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

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

<pre>

gnt# ganeti-masterd --no-voting

</pre>

для 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:

<pre>

su - gnt-masterd -s /bin/bash -c "/usr/sbin/ganeti-wconfd --no-voting --yes-do-it"

su - gnt-masterd -s /bin/bash -c "/usr/sbin/ganeti-luxid --no-voting --yes-do-it"

</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. Перевод виртуалки слейва дрбд на другую ноду

Переносим слейв дрбд виртуалки на другую ноду 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>