В данной публикации хочу поделиться своим опытом по тестированию распределенного хранилища, основанного на EMC ScaleIO 1.32.2.
Решил испробовать ее после прочтения статьи «Как можно сделать отказоустойчивую систему хранения данных из отечественных серверов» и «Не спешите выкидывать старые серверы, из них можно собрать быструю Ethernet-СХД за час».
Вначале поставлю под сомнение одну картинку из второй статьи. По документации кластер может состоять только из двух нод, а там показаны три (голубым цветом).
Написано с целью обсудить возникшие проблемы, так как со стороны EMC ответа так и не поступило. Да, система разворачивалась на тестовом стенде, ни о какой технического поддержки со стороны производителя нет по условиям лицензирования. Но и поиск во всемирной паутине не принес желаемого результата.
Первая непонятка случилась после инсталляции Meta Data Manager на первую ноду. Чтобы ее можно было настраивать, пришлось перезагружать ОС, так как при попытке выполнить команду --add_primary_mdm непосредственно после окончания процесса инсталляции, упорно выводилась ошибка коннекта, хотя все необходимые порты были в состоянии LISTENING и все необходимые службы были запущены.
Затем процесс присоединения второй ноды и настройки кластера, установка ролей Data Server прошли без проблем.
На каждую ноду Data Server были успешно подключены по два устройства хранения в виде RAW-разделов на дисках, подключенных по iSCSI, и одному файлу большого размера на локальном диске.
Особенность подключения дисков по iSCSI заключалась в том, что источниками этих дисков являлись компьютеры в сети, которые включались/выключались бессистемно, непредсказуемо, что помогло в полной мере проверить такие заявленные отказоустойчивые технологии как: Rebuild, Rebalance. В ходе наблюдения за системой в течении двух недель к данным аспектам работы претензий не было. Все сработало на «ура».
Проблемы начались при попытке увеличить количество подключенных device на каждую из нод Data Server. Так и не смог выяснить, по какой причине новые устройства не присоединялись ни при помощи команды --add_sds_device, ни через GUI. Все операции заканчивались ошибкой «Comminication error». И так для каждой ноды. При этом каждое из подключенных устройств доступно в ОС как блочное устройство, не противится форматированию, созданию на нем файловых объектов, работе с ним по протоколу SMB.
Однако, самая критичная ошибка всплыла только через пару недель.
В один из дней я обратил внимание на то, что кластер находится в статусе degraded. Ночью были проблемы с электричеством и сеть частично не работала. Обе ноды Data Manager были в статусе Secondary. При этом нода Tie breaker была доступна по сети с обеих нод.
Принудительный перевод ноды в Primary невозможен, административный порт не прослушивается, выгрузить настройки кластера в файл невозможно.
То есть, все ноды Data Server, Data Client работают, перекидываются друг с другом информацией на сетевом уровне, дисковый раздел, предоставленный клиенту, доступен, целостность информации не нарушена.
Но ситуация тупиковая: ни изменить конфигурацию, ни добавить новые ноды.
Попробовал поднять новый Primary Data Manger, создать новый кластер и подключить к нему существующую Secondary ноду. Призрачная надежда умерла так и не родившись — новый кластер был чист ( в принципе, оно и так понятно было с самого начала).
Еще одним небольшим минусом можно назвать невозможность подстроить размер GUI под размер текущего разрешения монитора — размеры GUI фиксированы и рассчитаны на разрешение не менее 1280х1024.
Потратил много времени на общение с Google, ничего адекватного найти не удалось.
Решил зайти на сайт EMC, а там окно онлайн консультанта. Я попросил контакт кого-нибудь из техподдержки и написал ему письмо с описанием выявленных проблем.
В ответном письме (на русском языке) мне задали уточняющие вопросы. Я на них ответил и мне пообещали ответить через некоторое время. Не дождавшись ответа в течении недели, я напомнил о себе письмом, но так до сих пор ничего в ответ не получил.
Итогом тестирования, описанного в статье по второй ссылке в начале статьи, сказано, что
Не могу с этим согласиться. Это первое протестированное мною программно-определяемое распределенное хранилище. Постепенно буду тестировать и другие. По результатам буду отписываться.
Решил испробовать ее после прочтения статьи «Как можно сделать отказоустойчивую систему хранения данных из отечественных серверов» и «Не спешите выкидывать старые серверы, из них можно собрать быструю Ethernet-СХД за час».
Вначале поставлю под сомнение одну картинку из второй статьи. По документации кластер может состоять только из двух нод, а там показаны три (голубым цветом).
Написано с целью обсудить возникшие проблемы, так как со стороны EMC ответа так и не поступило. Да, система разворачивалась на тестовом стенде, ни о какой технического поддержки со стороны производителя нет по условиям лицензирования. Но и поиск во всемирной паутине не принес желаемого результата.
Собственно, характеристики тестового стенда
- две ноды с ролью MDM (primary and secondary)
- одна нода с ролью Tie Breaker. На ней же развернут GUI для мониторинга и администрирования.
- три ноды с ролью Data Server. На каждой из них устройства хранения (device) были организованы следующим образом: два устройства — raw-разделы на дисках, подключенных по протоколу iSCSI. Одно устройство было представлено файлом большого размера.
- в качестве операционной системы на каждой ноде выступала Windows 2012 standard. Объем RAM 4 Гб. Сеть — 1 Гб
Первая непонятка случилась после инсталляции Meta Data Manager на первую ноду. Чтобы ее можно было настраивать, пришлось перезагружать ОС, так как при попытке выполнить команду --add_primary_mdm непосредственно после окончания процесса инсталляции, упорно выводилась ошибка коннекта, хотя все необходимые порты были в состоянии LISTENING и все необходимые службы были запущены.
Затем процесс присоединения второй ноды и настройки кластера, установка ролей Data Server прошли без проблем.
На каждую ноду Data Server были успешно подключены по два устройства хранения в виде RAW-разделов на дисках, подключенных по iSCSI, и одному файлу большого размера на локальном диске.
Особенность подключения дисков по iSCSI заключалась в том, что источниками этих дисков являлись компьютеры в сети, которые включались/выключались бессистемно, непредсказуемо, что помогло в полной мере проверить такие заявленные отказоустойчивые технологии как: Rebuild, Rebalance. В ходе наблюдения за системой в течении двух недель к данным аспектам работы претензий не было. Все сработало на «ура».
Проблемы начались при попытке увеличить количество подключенных device на каждую из нод Data Server. Так и не смог выяснить, по какой причине новые устройства не присоединялись ни при помощи команды --add_sds_device, ни через GUI. Все операции заканчивались ошибкой «Comminication error». И так для каждой ноды. При этом каждое из подключенных устройств доступно в ОС как блочное устройство, не противится форматированию, созданию на нем файловых объектов, работе с ним по протоколу SMB.
Однако, самая критичная ошибка всплыла только через пару недель.
В один из дней я обратил внимание на то, что кластер находится в статусе degraded. Ночью были проблемы с электричеством и сеть частично не работала. Обе ноды Data Manager были в статусе Secondary. При этом нода Tie breaker была доступна по сети с обеих нод.
Принудительный перевод ноды в Primary невозможен, административный порт не прослушивается, выгрузить настройки кластера в файл невозможно.
То есть, все ноды Data Server, Data Client работают, перекидываются друг с другом информацией на сетевом уровне, дисковый раздел, предоставленный клиенту, доступен, целостность информации не нарушена.
Но ситуация тупиковая: ни изменить конфигурацию, ни добавить новые ноды.
Попробовал поднять новый Primary Data Manger, создать новый кластер и подключить к нему существующую Secondary ноду. Призрачная надежда умерла так и не родившись — новый кластер был чист ( в принципе, оно и так понятно было с самого начала).
Еще одним небольшим минусом можно назвать невозможность подстроить размер GUI под размер текущего разрешения монитора — размеры GUI фиксированы и рассчитаны на разрешение не менее 1280х1024.
Потратил много времени на общение с Google, ничего адекватного найти не удалось.
Решил зайти на сайт EMC, а там окно онлайн консультанта. Я попросил контакт кого-нибудь из техподдержки и написал ему письмо с описанием выявленных проблем.
В ответном письме (на русском языке) мне задали уточняющие вопросы. Я на них ответил и мне пообещали ответить через некоторое время. Не дождавшись ответа в течении недели, я напомнил о себе письмом, но так до сих пор ничего в ответ не получил.
Мои выводы
Итогом тестирования, описанного в статье по второй ссылке в начале статьи, сказано, что
Тесты на отказоустойчивость прошли успешно
Не могу с этим согласиться. Это первое протестированное мною программно-определяемое распределенное хранилище. Постепенно буду тестировать и другие. По результатам буду отписываться.
Комментарии (11)
gotch
17.12.2015 20:28Что сказать. Вот и верь после этого
людямрекламе.
ximik13
18.12.2015 08:30А что не так с людьми? И как это относится к обсуждаемой теме?
gotch
18.12.2015 18:53Что-то вроде habrahabr.ru/company/croc/blog/269289
В качестве развлечения я попытался «завалить» систему, выдергивая ноды в разной последовательности и через разные промежутки времени. Если ноды выдергивать по одной и давать ScaleIO достаточно времени для ребилда, то виртуальные машины будут работать, даже если останется одна нода. Если отключить 3 ноды за минуту, например, доступ к общему пространству остановится до той поры, пока эти ноды не будут включены обратно. Данные становятся доступны, а массив выполняет проверку целостности данных и ребилд (если необходимо) в фоновом режиме. Таким образом, решение получается достаточно надежным для того, чтобы использовать его на боевых задачах.
Нет так уж и сложно оказалось завалить систему до состояния, что без платной поддержки — никак.ximik13
19.12.2015 21:17Если бросаться смартфоном в стену, то не так уж и сложно его завалить.
Если посмотреть условия тестирования, то они в принципе равносильны утверждению выше:
Особенность подключения дисков по iSCSI заключалась в том, что источниками этих дисков являлись компьютеры в сети, которые включались/выключались бессистемно, непредсказуемо, что помогло в полной мере проверить такие заявленные отказоустойчивые технологии как: Rebuild, Rebalance.
ximik13
Интересный у вас случай.
По поводу:
Посмотреть что происходило с 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». Не наводит на мысли?