Проект

Общее

Профиль

История

FAILOVER-процедуры » История » Версия 37

« Предыдущее - Версия 37/39 (Разница(diff)) - Следующее » - Текущая версия
Олег Пеньков, 12.11.2019 17:36

FAILOVER-процедуры

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

FAILOVER-процедуры

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

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

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

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

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

service ganeti restart

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

gnt# ganeti-masterd --no-voting

для SCI версии 2 и выше
gnt-cluster master-failover --no-voting


su - gnt-masterd -s /bin/bash -c "/usr/sbin/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

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

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

 gnt-instance replace-disks --new-secondary gntX instance_name

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

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

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

gntX# ganeti-masterd --no-voting

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

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


для SCI версии 2 и новее:
su - gnt-masterd -s /bin/bash -c "/usr/sbin/ganeti-masterd --no-voting" 


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


gnt# gnt-cluster redist-conf

Для всех виртуалок, которые имеют secondary на подключенном узле:
gnt# gnt-instance replace-disks --auto 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

Поставить загрузчик
dpkg-reconfigure grub-pc

или
grub-install /dev/sdX

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

Если при activate-disks или при команде запуска/фейловера drbd ругается следующим образом в dmesg:

[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 )

Здесь мы видим:
[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!

то, во-первых, нужно установить, где находятся актуальные данные.
Когда когда точно установлено, где актуальные данные, мы идем на ноду, где данные битые, и там даем команду:

drbdsetup /dev/drbd23 invalidate

Затем на мастере дать activate-disks для этого инстанса, и проследить, что все drbd ресурсы отсинкались.

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

Ситуация: primary узел умер, диск на secondary узле считает себя outdated.
Watcher пишет письма, содержащие в логе такую строку:

Error while assembling disk: drbd7: can't make drbd device primary:
 /dev/drbd7: State change failed: (-2) Need access to UpToDate data\n

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

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)


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

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

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

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

root@gnt2:~# drbdsetup /dev/drbd8 down