Проблема

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

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

Беглый осмотр слушаемых на машины портов показал, что реально, на порту 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 и проверить, что кластер хоть в каком-то виде жив. После этого удалось подключиться с помощью 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, и с разной версией БД с метаданными. Ну в итоге они там и наребилдили выпавшие дисковые пулы, перемешав все блоки в кучу. Из-за этого всё рассыпалось.