Опыт тестирования ScaleIO

[@ximik13]

Интересный у вас случай.
По поводу:

Обе ноды Data Manager были в статусе Secondary. При этом нода Tie breaker была доступна по сети с обеих нод.

Посмотреть что происходило с MDM-ми (Meta Data Manager) можно на ноде Tie-Breaker в логе (для Windows скорее всего вместо "/opt/emc/scaleio/" будет директория установки ScaleIO):
/opt/emc/scaleio/mdm_failover/logs/mdm_failover.log

Я бы попробовал провернуть следующее:
1) Выключил один из secondary MDM (возможно вместе с Tie-Breaker)
2) Пробовал перевести временно кластер в режим «single mode».
Команда «scli --mdm_ip 192.168.1.200 --switch_to_single_mode».
3) Пробовал выполнить команду для смены роли mdm «scli --mdm_ip 192.168.1.200 --switch_mdm_ownership».
4) Если получилось, то вернуть кластер в «cluster mode» и загрузить/добавить в кластер secondary MDM и Tie-Breaker.

А еще если в кластере больше трех нод, то часть этих нод можно превратить в standby MDMs для большей отказоустойчивости управляющего кластера. В конфигурации поддерживается до 8 IP адресов для MDM нод и до 8 IP адресов для Tie-Breaker нод. Т.е. может быть конфигурация
1xPrimary MDM — 2 ip
1xSecondary MDM — 2 ip
2xStandby MDM — 2 ip
или
1xPrimary MDM — 1 ip
1xSecondary MDM — 1 ip
6xStandby MDM — 1 ip
и т.д.
Аналогично для Tie-Breaker

P.s. Я шапошно знаком со ScaleIO, но есть доступ к некоторой документации ;).

[@IlyamI]

1. В логах Tie Breaker ничего внятного кроме "… declaring socket 244 as closed due to Err 10054".
в логах же MDM "… declaring socket as closed due to Err 10057"
2. «Пробовал перевести временно кластер в режим single mode»
любая команда «cli — ...» выполняется на Primary ноде. А у меня нет ни одной.
3. «вернуть кластер в «cluster mode»»
по той же причине, что и п.2

[@ximik13]

1) Под логом Tie Breaker и MDM вы имеете в виду текстовый файл который я указал? Или стандартные журналы Windows?
2) Тут вы странно понимаете логику работы кластера MDM. При нормальной работе кластера все так и есть, как вы описываете. Команды выполняются на Primary MDM. Вот только вы действительно думаете, что производитель не предусмотрел ситуации, когда Primary 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.

Проверить мне к сожалению не на чем :).

[@IlyamI]

Во-первых, большое спасибо за ответ.
во-вторых,

Откопал документ очень близкий к вашей аварии

а ссылку можно?

Попробовал это сделать на стенде под локальным администратором (win2012): вижу сообщение в консоли «This command should be performed only by EMC support....» Конечно же соглашаюсь. в ответ: «error: mdm failed command. status: permission denied. please check… user name and password....»
еще замечено "… Create a text file called MDM_SERVICE_MODE....". если создать файл с расширением .txt, то его содержимое не меняется. Если же файл вообще без расширения, то текст внутри него меняется на "-----"

кстати, решить проблему подключения sds(device) не только мне не удалось (линк)

[@ximik13]

По документу, он доступен на сервисном портале вендора (нужен аккаунт на support.emc.com). Документ лежит тут. Фактически все его содержимое приведено в моем комментарии выше.

Создавать файл необходимо без расширения.
Еще в документе отдельно отмечено «You must have write privileges on the MDM to complete this task.» Я думаю что для выполнения данного условия необходимо в явном виде авторизоваться на MDM в scli.
Т.е. сначала как то так "scli --login --username admin", а потом уже "scli --rescue_mode
"

[@IlyamI]

повторяю: все команды cli доступны ТОЛЬКО на primary ноде. а на secondary ноду залогиниться нельзя, так как она не слушает управляющий порт 6611. А он слушается только на primary. А обе ноды сейчас secondary.

[@ximik13]

И тем не менее команда scli --rescue_mode выполняется у вас на этой ноде, но ругается на «permission denied». Не наводит на мысли?

[@gotch]

Что сказать. Вот и верь после этого людям рекламе.

[@ximik13]

А что не так с людьми? И как это относится к обсуждаемой теме?

[@gotch]

Что-то вроде habrahabr.ru/company/croc/blog/269289

В качестве развлечения я попытался «завалить» систему, выдергивая ноды в разной последовательности и через разные промежутки времени. Если ноды выдергивать по одной и давать ScaleIO достаточно времени для ребилда, то виртуальные машины будут работать, даже если останется одна нода. Если отключить 3 ноды за минуту, например, доступ к общему пространству остановится до той поры, пока эти ноды не будут включены обратно. Данные становятся доступны, а массив выполняет проверку целостности данных и ребилд (если необходимо) в фоновом режиме. Таким образом, решение получается достаточно надежным для того, чтобы использовать его на боевых задачах.

Нет так уж и сложно оказалось завалить систему до состояния, что без платной поддержки — никак.

[@ximik13]

Если бросаться смартфоном в стену, то не так уж и сложно его завалить.

Если посмотреть условия тестирования, то они в принципе равносильны утверждению выше:

Особенность подключения дисков по iSCSI заключалась в том, что источниками этих дисков являлись компьютеры в сети, которые включались/выключались бессистемно, непредсказуемо, что помогло в полной мере проверить такие заявленные отказоустойчивые технологии как: Rebuild, Rebalance.