1 заметка с тегом

СХД

ScaleIO и отвал обоих MDM

13 апреля 2016, 17:08

Проблема

Я в конторе развернул ScaleIO на тестовом кластере. 4 гипервизора esxi, по 4 жёстких диска в каждом. И сегодня случился какой-то внезапный отвал двух нод последовательно. Машина с Primary MDM по сети отвечает, но находится в несознанке — по SSH зайти нельзя, локальная консоль тоже мёртвая. А secondary MDM выпал вместе с гипервизором. При этом непосредственно в момента вылета я внимательно втыкал в GUI ScaleIO, и, как говорится, ничто не предвещало.

Ребутнул сбойнувший гипервизор, виртуалка с secondary MDM поднялась и на вид даже как живая. Зашёл в консоль, говорю там:

scli −-login −-user admin
Enter password: Error: Failed to connect to MDM 127.0.0.1:6611

Беглый осмотр слушаемых на машины портов показал, что реально, на порту 6611 никого нет:

# ss -l
Recv-Q Send-Q           Local Address:Port               Peer Address:Port
0      128                          *:9099                          *:*
0      128                          *:6611                          *:*
0      128                          *:9011                          *:*
0      128                          *:25620                         *:*
0      128                         :::ssh                          :::*
0      128                          *:ssh                           *:*
0      100                  127.0.0.1:smtp                          *:*
0      128                          *:25660                         *:*
0      128                          *:7072                          *:*
0      128                          *:25640                         *:*

А это нам намекает, что MDM на не стартовал. Не делает он этого в двух случаях — либо когда primary MDM в кластере поднят и работает, либо если что-то сломалось. Ситуация довольно идиотская, и напоминает пресловутую шутку про /pkunzip.zip/. Чтобы починить MDM, нужно сначала залогиниться в MDM, так как все команды scli выполняются через активный MDM. А чтобы залогиниться, нужен рабочий MDM.

Но хвала небесам, за то что они придумали коллективный разум. И белых людей, делящихся знаниями с другими людьми. Внезапно был обнаружен топик на хабре, где в комментариях один товарищ поделился тайными и скрытыми знаниями, почерпнутыми из секретной сервисной, не-доступной публично документации EMC. И вот эта цитата помогла разобраться с проблемой подключения при отсутствии работающего MDM:

MDM rescue mode capability

In MDM cluster mode, if a Primary MDM fails after the Secondary MDM has already failed, concern for lack of repository synchronization will cause the Secondary MDM not to automatically take over the Primary MDM role. This leaves the system non-operational.

The MDM rescue mode feature enables you to force a Secondary MDM to take on the role of Primary MDM, thus enabling the system to continue to function, albeit in a not-fully-synchronized state.

Implementing MDM rescue mode

This section describes how to run the MDM rescue mode feature. Any user can run rescue mode, using a combination of a file written to the MDM, and the rescue_mode command. You must have write privileges on the MDM to complete this task.
Command
rescue_mode Syntax
scli —rescue_mode
To run rescue mode, perform the following steps:

  1. Create a text file called MDM_SERVICE_MODE on the Secondary MDM, in the location corresponding to your operating system:
    • Windows: C:\Program Files\emc\scaleio\MDM\logs
    • Linux: /opt/emc/scaleio/mdm/logs/
  2. In the body of the file, type the text Rescue Mode, and save the file.
  3. In the CLI, type the command scli —rescue_mode.

The Secondary MDM is forced to take over the Primary MDM role. You can verify this
using the query_cluster command.

Я проделал описанное и реально, это помогло — смог подключиться к MDM и проверить, что кластер хоть в каком-то виде жив. После этого удалось подключиться с помощью GUI, и увидеть, что не всё так плохо, как могло бы быть на самом деле:

Похоже, потерь данных не будет, но пока дальше разбираться с причинами проблем и пытаться ребутать машину, где работал primary MDM, лучше не торопиться. Дождёмся сначала полного ребилда томов.

Но радость была преждевременной

Тома ребилдились, и я решил разобраться с бывшим primary MDM. Ребутнул зависший хост, соответственно, виртуалка тоже ребутнулась, и все настроенные пулы выпали в состояние Failed. В общем, долго ли, коротко ли, но мораль сей басни такова — мало войти в rescue mode для MDM, нужно грамотно из него ещё и выйти. В моём случае нужно было бы делать так: оставить работать только secondary MDM в rescue mode, дождаться ребилда томов и эвакуировать все виртуалки оттуда. После этого попытаться переключить ScaleIO из cluster mode в single mode, снести на бывшем первом MDM пакет с MDM и переустановить его заново. Затем добавить его как secondary MDM и попытаться включить обратно cluster mode.

Мой дисковый пул рассыпался, так как после введения в rescue mode того MDM, который был secondary, он в авторитарном режиме стал primary. И пока он был один — всё работало. А как только я ребутнул зависший primary MDM, он отказался становиться secondary после ребута, и в итоге получилась ситуация split brain — два MDM в кластере, и оба primary, и с разной версией БД с метаданными. Ну в итоге они там и наребилдили выпавшие дисковые пулы, перемешав все блоки в кучу. Из-за этого всё рассыпалось.

ScaleIO   Troubleshooting   СХД