FAILOVER-процедуры » История » Версия 28
« Предыдущее -
Версия 28/39
(Разница(diff)) -
Следующее » -
Текущая версия
Николай Алексеев, 18.12.2017 16:59
FAILOVER-процедуры¶
- FAILOVER-процедуры
- FAILOVER-процедуры
- Запуск на одном действующем мастер-узле
- Штатное переключение master-узла
- Перевод виртуалки слейва дрбд на другую ноду
- Выход из строя master-узла
- Возврат основного узла в строй
- Плановый вывод узла из эксплуатации
- Замена узла на новый
- Замена жесткого диска
- Восстановление при split-brain:
- Восстановление outdated диска
OVERVIEW | INSTALL | SETUP | OPERATIONS | LICENSE
ОБЗОР | УСТАНОВКА | НАСТРОЙКА | ОПЕРАЦИИ | ЛИЦЕНЗИЯ
FAILOVER-процедуры¶
Обозначения:
gnt# - запуск команды на мастер-узле gntX# - запуск команды на обычном узле gntY# - запуск команды на другом узле # - запуск команды на любом узле
Запуск на одном действующем мастер-узле¶
При запуске на одном узле, управление кластером ganeti-masterd не стартует автоматически, даже на master-узле.
Это связано с тем, что невозможно отличить крах второго узла от потери связи, когда на втором узле продолжают работать запущенные виртуалки.
Запуск управляющего демона:¶
gnt# ganeti-masterd --no-voting
для ganeti 2.10:
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
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
для ganeti 2.10:
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
Восстановление при 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