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

в 9:30, , рубрики: EMC, scaleio, Серверное администрирование, система хранения данных, системное администрирование, СХД, хранение данных

В данной публикации хочу поделиться своим опытом по тестированию распределенного хранилища, основанного на EMC ScaleIO 1.32.2.

Решил испробовать ее после прочтения статьи «Как можно сделать отказоустойчивую систему хранения данных из отечественных серверов» и «Не спешите выкидывать старые серверы, из них можно собрать быструю Ethernet-СХД за час».

Вначале поставлю под сомнение одну картинку из второй статьи. По документации кластер может состоять только из двух нод, а там показаны три (голубым цветом).

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

Написано с целью обсудить возникшие проблемы, так как со стороны 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, а там окно онлайн консультанта. Я попросил контакт кого-нибудь из техподдержки и написал ему письмо с описанием выявленных проблем.

В ответном письме (на русском языке) мне задали уточняющие вопросы. Я на них ответил и мне пообещали ответить через некоторое время. Не дождавшись ответа в течении недели, я напомнил о себе письмом, но так до сих пор ничего в ответ не получил.

Мои выводы

Итогом тестирования, описанного в статье по второй ссылке в начале статьи, сказано, что

Тесты на отказоустойчивость прошли успешно

Не могу с этим согласиться. Это первое протестированное мною программно-определяемое распределенное хранилище. Постепенно буду тестировать и другие. По результатам буду отписываться.

Автор: IlyamI

Источник

Поделиться новостью

* - обязательные к заполнению поля