Третьего дня закончился наш двухнедельный период тестирования EMC XtremIO.
КРОК уже делился своими впечатлениями от подобного опыта, но преимущественно в виде результатов синтетических тестов и восторженных высказываний, что применительно к любой СХД, выглядит эффектно, но малоинформативно. Я в данный момент работаю в заказчике, а не в интеграторе, нам важнее прикладной аспект, так что тестирование было организовано в соответствующем ключе. Но по порядку.
Общая информация
XtremIO — новый (относительно) продукт компании EMC, точнее компании XtremIO, купленной компанией EMC. Представляет собой All-Flash array, состоящий из пяти модулей — два одноюнитовых сервера Intel в качестве контроллеров, два ИБП Eaton и одна дисковая полка на 25 дисков. Всё перечисленное объединяется в брик (brick) — единицу расширения XtremIO.
Киллер-фичей решения является дедупликация «на лету». Нам этот факт был особенно интересен, поскольку пользуем VDI с полными клонами и их у нас много. Маркетинг обещал, что все влезут в один брик (ёмкость брика — 7,4 ТБ). В данный момент на обычном массиве они занимают почти 70+ ТБ.
Сфотографировать предмет повествования я забыл, но в посте КРОКа можно увидеть всё в деталях. Я уверен даже, что это тот же самый массив.
Монтаж и настройка
Девайс пришёл смонтированным в мини-рэк. Необдуманно мы пошли принимать его вдвоём и чуть не надорвались, просто перетаскивая из машины в тележку. Разобрав на составляющие, однако, я его перевёз в ЦОД и смонтировал в одиночку без особых трудностей. Монтаж салазок предполагает вкручивание большого количества винтов, так что пришлось много времени провести с отвёрткой в позе буквы «Г», зато коммутация порадовала — все кабели необходимой и достаточной длины, вставляются и вынимаются легко, но имеют защиту от случайного выдирания. (Этот факт отметил положительно после тестирования другой flash СХД — Violin — у которой кабель, объединяющий два соседних гнезда зачем-то сделали длиной полтора метра, а один из ethernet патч-кордов, вставив, невозможно впоследствии вытащить без дополнительного плоского инструмента, например отвёртки).
Настраивать сабж приехал специально обученный инженер. Весьма интересно было узнать, что на данный момент обновление управляющего ПО происходит с потерей данных. Добавление нового брика в систему — тоже. Вылет двух дисков сразу тоже приводит к потере данных (без потерь второй диск можно терять после ребилда), но это обещают исправить в ближайшем обновлении. Как по мне, так лучше бы первые два пункта сделали по-нормальному.
Для полноценной настройки и управления массивом системе требуется (XMS — XtremeIO Management Server). Его можно заказать в качестве физического дополнения к комплекту (полагаю, увеличив стоимость решения на цену весового эквивалента этого сервера в золоте), а можно просто развернуть виртуалку (linux) из шаблона. После чего в неё нужно поместить архив с ПО и установить его. А потом настроить, используя пол десятка дефолтных учёток. В общем, процесс первичной настройки отличается от привычной настройки СХД и не сказать, что в сторону облегчения. Надеюсь, его ещё доработают.
Эксплуатация, дедупликация и проблемная ситуация
Не мудрствуя лукаво, в качестве теста решили перенести часть боевых VDI на тестируемый девайс и посмотреть, что из этого получится. Особенно интересовала эффективность дедупа. В коэффициент 10:1 я не верил, поскольку хоть у нас и полные клоны, профили и какие-то данные пользователей лежат внутри ВМ (хотя их объём чаще всего невелик относительно ОС), да и просто скептически отношусь к заявленным чудесам.
Первые перенесённые 36 ВМ заняли на датасторе 1,95 ТБ, а на дисках — 0,64 ТБ. Коэффициент дедупликации — 2,7:1. Правда, первую партию составили виртуальные десктопы представителей ИТ департамента, которые особенно любят держать всё внутри своего ПК, не важно физический он или виртуальный. Многие даже дополнительные диски имеют. По мере наполнения системы всё новыми машинами, коэффициент рос, но не значительно, без рывков. Вот например скриншот системы с сотней виртуалок:
А вот 450:
Средний размер vmdk — 43 ГБ. Внутри — Windows 7 EE.
На этом количестве я решил остановиться и провернуть новый тест — создать новый датастор и забить его «чистыми» клонами, свежеразвёрнутыми из шаблона, проверив и время развёртывания и дедуп. Результаты впечатляющие:
создано 100 клонов;
заполнен датастор в 4 ТБ;
объём занятого места на дисках увеличился на 10 ГБ.
Скриншот (сравните с предыдущим):
Вот полная табличка с результатами:
Была ещё мысль включить эти 100 клонов и посмотреть а) как ведёт себя система в бутшторм, б) как изменится коэффициент дедупа после включения и некоторого времени работы чистой системы. Однако эти мероприятия пришлось отложить, так как случилось то, что можно назвать unpleasant behavior. Один из пяти LUN заблокировался и поставил колом весь кластер.
Стоит признать, что причина лежит в особенностях конфигурации хостов. Из-за использования IBM SVC в качестве агрегатора хранения (будь он неладен) на хостах пришлось отключить Hardware Assist Lock — важнейший элемент VAAI, позволяющий блокировать не весь датастор при изменении метаданных, а небольшой его сектор. Так что почему LUN заблокировался — понятно. Почему он не разблокировался — не очень. И совсем непонятно, почему он не разблокировался даже после того, как был отключен от всех хостов (пришлось, поскольку пока мы этого не сделали, ни одна ВМ не могла ни включиться ни смигрировать, а как назло, именно в этот момент кому-то из Очень Важных Людей компании потребовалось ребутать свои машины) и прошли все мыслимые и немыслимые таймауты. По словам «старожилов», подобное поведение наблюдалось на старых IBM DSxxxx, но они имели специальную кнопку разлочки LUN для таких случаев.
Здесь такой кнопки не предусмотрено, в итоге 89 человек оказались без доступа к своим десктопам на три часа, а мы уже подумывали о перезапуске массива и искали наиболее безопасный и надёжный путь к этому (поочерёдный перезапуск контроллеров не помогал).
Помог саппорт EMC, который сначала долго доставал из своих недр нужного инженера, который потом долго перепроверял и просматривал все вкладки и консоли, а само решение было простым и элегантным:
vmkfstools --lock lunreset /vmfs/devices/disks/vml.02000000006001c230d8abfe000ff76c198ddbc13e504552432035
то есть команда на разблокировку от любого хоста.
Век живи — век учись.
Всю следующую неделю я лихорадочно переносил десктопы обратно на HDD-хранилище, отложив все тесты на потом-если-останется-время. Времени не осталось, поскольку массив у нас забрали на два дня раньше обещанного срока, так как следующий тестер оказался не в Москве, а Уфе (внезапность и организованность в процедуре возврата стоит отдельных не полностью нормативных высказываний).
Резюме
Идеологически решение мне понравилось. Если чуть допилить нашу инфраструктуру VDI, вынеся пользовательские данные на файл-сервера, то можно разместить все наши 70 ТБ если не на одном, то на двух-трёх бриках. То есть 12-18 юнитов против целой стойки. Не могли, конечно, не понравиться скорость svMotion и развёртывание клона (менее минуты). Однако пока сыро. Потери данных при обновлении и масштабировании нельзя считать приемлемыми в энтерпрайзе. И момент с reservation lock тоже ввёл в смущение.
С другой стороны, как-то смахивает на недоделанный Nutanix. Последний правда могу оценивать лишь по презентациям, а они всегда красивые.
И о цене. КРОК в своих постах писал о какой-то непостижимой цифре в 28 миллионов. Я же слышал о шести с половиной, и это ещё не было минимумом. Хотя к ценовым переговорам у меня ни доступа ни интереса нынче нет, так что утверждать точно не возьмусь.
Автор: kabal375
