Пинать такую коробку следует с особой осторожностью

В целом я просто хотел сказать, что если вы смотрите all-flash массив на замену тирингового с ценой за гигабайт чуть пониже, надёжный и от топового вендора — продолжайте читать. Минимальный американский street price, заявленный вендором, начинается с 19 тысяч долларов. Но понятно, что на проектах, где нужно такое железо, всегда находится скидка, программа или спецпредложение, которые могут уменьшить цену спецификации, порой значительно. Заглядывайте внутрь, чтобы понять, почему SSD может быть дешевле тирингового массива, в частности, для VDI.

Началась история этой железки с того, что в HP давно подозревали, что после примерно 2012 года всё больше и больше серверных мощностей будет требовать быстрых СХД. Поэтому они купили контору 3PAR, клепающую неплохие мидрейнджевые системы хранения, взяли напильник — и понеслось. Что получилось — сейчас покажу.

Архитектура

Когда ко мне в руки впервые попал HP 3PAR 7400, я отнёсся к нему скептически, как к младшему брату в семье Full Flash массивов. Но два дня, проведённых с массивом, сильно изменили моё мнение.

HP 3PAR 7400 расширяется до 4 контроллеров, может нести 240 SSD дисков, вмещает 96 Gb оперативной памяти в каждую контроллерную пару и просто очень красив. Железная часть массива мало отличается от привычных mid-rande массивов, но ПО приятно удивило своей архитектурой. Оно больше похоже на ПО high-end массивов, чем на то, к чему я привык в массивах среднего уровня.

Факты следующие:

Массив можно расширить до 4 контроллеров, то есть уровень отказоустойчивости HP 3PAR (при правильной конфигурации) сильно превосходит таковой большинства массивов среднего уровня.

Потом кэш. В большинстве mid-range массивов контроллерная пара имеет кэш, разделённый на чтение и запись. Кэш на запись зеркалируется между контроллерами, но только в качестве защиты, а головы используют свою память раздельно. Если СХД хочет получить заметную часть рынка, ей нужно научиться динамически изменять размеры памяти, выделенные для чтения и записи. HP 3PAR пошёл дальше. Инженеры сделали Cache-Centric массив с общей памятью для всех контроллеров. В результате команда из 4 контроллеров в HP 3PAR работает значительно лучше, чем 4 малосвязанных контроллера в большинстве mid-range СХД.

Дедупликация. Никто не любит делать одну и ту же работу дважды. С этим маркетинговым заявлением многие массивы ринулись на рынок, предлагая решения с дедупликацией. Если разобраться, то большинство этих массивов делают дедупликацию в постпроцессе. Записывают данные на диск, а потом, когда появится свободное время, считывают эти данные и пытаются дедуплицировать. Таким образом, работа сделана не дважды, а четырежды. В плюсе — некоторый выигрыш по месту при малом проценте записи. В остальных случаях — не применимо. 3PAR делает дедупликацию на лету, не записывая промежуточные данные. Таким образом, на хорошо дедуплицируемых наборах данных получается выигрыш в скорости работы массива (на диски нужно писать меньше данных, какая-то часть отсеивается как уже записанная), и место экономится.

Ещё система не пишет пустые (нулевые) блоки. Они отсеиваются на уровне ASIC-ов.

Среди нас есть левши и правши. Точно так же и с массивами. Есть массивы Active\Passive (это однорукие), есть Active\Active ALUA (это те самые среднестатистические левши и правши), а есть честные Active\Active. HP 3PAR именно такой. Контроллеры массива равноправны, никаких проблем с переездами лунов и неактивными путями.


Контроллер массива

Обновлять массивы лучше в онлайне. Среднестатистический массив при обновлении перезагружает контроллеры по одному, а значит, хост в какие-то моменты времени теряет половину путей. Обычно проходит без проблем, но иногда какой-нибудь хост может затупить и не восстановить пути вовремя. Обновление следующего контроллера положит вторую половину путей. Приложения такого обращения простить не могут и валятся с глухим стуком, порождая алерты в системах мониторинга и седые волосы на головах админов. В 3PAR постарались учесть проблемы простых людей и от них нас избавить. В случае обновления или поломки контроллера его WWN-ы временно переедут на соседний контроллер. В результате пути не теряются, приклад не падает, а я буду спать спокойнее (и больше).

Размещение данных. Обычно СХД нарезаются фиксированными RAID-группами. Недостатки такого подхода следующие:

• Луны располагаются только на одной RAID-группе.
• При поломке диска в ребилде задействована одна RAID-группа. Медленно и не надёжно.
• Нужен выделенный HotSpare диск. Понятное дело, что место нужно зарезервировать в любом случае, но диск-то простаивает. Хотелось бы его использовать, особенно если это SSD в FULL FLASH массиве.
• На одном наборе дисков могут лежать луны только с одинаковым уровнем защиты.

Здесь решение такое: все диски нарезаются на маленькие кусочки, из которых можно делать луны. Для каждого луна можно выбрать уровень защиты и количество кусочков, для которых будет считаться парити. На одном диске могут лежать луны с разным уровнем защиты, а каждый лун размазан по всем дискам. Получается:

• Каждый лун равномерно распределяется по дискам СХД.
• При поломке диска в ребилде задействованы все диски массива.
• Не нужен выделенный HotSpare диск.
• На одних и тех же дисках легко размещаются данные с разным уровнем защиты.

Ну и как вам функционал? По цене — mid-range. Сравните функционал с тем, что стоит в ваших серверных.

Теоретическая часть на этом закончена, пора переходить к тестированию. Хочу заметить, что тестирование производительности не претендует на «полный отчёт по производительности массива». Для этого нужна неделя и несколько вариантов конфигурации. Здесь собраны несколько базовых тестов, дающих общее понимание возможностей СХД. В тестовой железке всего 12 дисков.


Наш экземпляр

Для оценки производительности СХД с большим количеством дисков придётся использовать логику и калькулятор. Я же тестировал три вида нагрузки. Графики ниже. Слева — луны без дедупликации, справа — такие же луны с дедупликацией. Данные, которые я писал на диск, совершенно случайны и абсолютно не дедуплицируются — мне было интересно посмотреть на «оверхед» дедупликации.

Тест 1. 100% чтение, 100% Random, блоки 4k

На 12 SSD дисках массив делает около 300 000 IO с временем отклика меньше секунды. К сожалению, время отклика на лунах с дедупликацией начинает «заваливаться» после 250 000 IO, но результат все равно меньше миллисекунды.

Тест 2. 70% чтение, 30% запись, 100% Random, блоки 4k

Из графиков видно, что луны с дедупликацией заметно сдали в производительности на смешанной нагрузке. Но 90 000 IO на недедуплицированном луне с откликом меньше 1 мс в СХД с 12 дисками — хороший для midrange СХД результат. Для лунов с дедупликацией на этой конфигурации 45 000 — потолок, хотя время отклика нормальное.

Тест 3. 100% запись, 100% Random, блоки 4k

Вполне достойно для 100% случайной записи. Время отклика, конечно, немного завышено, но это легко решается добавлением дисков.

Тест 4. Классический тест с выдёргиванием диска на смешанной нагрузке

Видно, что производительность массива несколько упала, но так как в ребилде задействованы все диски одновременно, резкого падения производительности не случилось.

Самое важное

Массив станет отличной all-flash заменой тиринговому «старичку» для использования в смешанной или виртуальной среде. All-flash массив обычно дороже тирингового решения, но если учесть in-line дедупликацию, то всё может оказаться не таким очевидным. При коэффициенте дедупликации — 2, Flash массивы начинают становиться дешевле «тиринговых». Но нужно считать под конкретный кейс.

Оборудование ввозится в Россию через дистрибьютора. В среднем даже сейчас от размещения заказа до поставки проходит 8 недель. Счета за конфигураторы выставляются в долларах, при необходимости мы можем перевести спецификацию в рубли для договора. Кстати, данное оборудование можно заказать по программе Flexible Capacity Service.

Что вообще надо знать про это железо?

Максимально в массив можно забить 240 SSD дисков. Интерфейс — FC, 8 Гб/с, 8 портов, можно добавить ещё 16 портов FC или 10 GbE iSCSI. Минимум два контроллера, максимум 4 контроллера. RAID 1, RAID 5 и RAID 6. Кэш 64 ГБ на контроллерную пару.

Особенности

1. Железка очень классная. 3PAR хорош для смешанных и виртуальных сред, отлично подходит для всех хорошо дуплицируемых данных (всякого рода виртуализация, VDI). Можно использовать и как универсальную СХД. Работать будет, как автомат Калашникова, но цена за гигабайт в full Flash конфигурации будет несколько выше, чем у тиринговых массивов.
2. Есть и некоторые особенности. Если писать на хранилище много информации в течение долгого времени, производительность падает. На мой взгляд, это связано с используемой в дисках технологией FLASH памяти CMLC, позволяющей существенно выиграть в цене диска. Создаётся впечатление, что массив в определённые моменты искусственно ограничивает скорость записи, чтобы избежать преждевременного износа дисков, но документального подтверждения этому факту нет.
3. На борту бесплатная (у других вендоров эта опция часто идёт за дополнительные деньги) дедупликация, но не надейтесь сильно дедуплицировать ей базы данных. Она затачивалась под виртуальные среды. Блок дедупликации — 16 килобайт.
4. Вендор пишет цену за гигабайт 1,5 доллара. В нашем тесте она получилась выше, но всё равно очень вкусной.

Вот ссылка на описание разных технологических фишек массива.

Отличия моделей линейки

На этом тестирование завершено. На вопросы готов ответить, пишите в комментариях или прямо в почту rpokruchin@croc.ru.