Практический опыт использования системы хранения данных HPE Nimble. Все ли так хорошо, как заявляет маркетинг?

Модель HPE Nimble AF40 позиционируется среди семейства All-Flash массивов Nimble, как оптимальный выбор по соотношению цена/производительность. С точки зрения производительности система достаточно сильно отличается от младшей модели AF20 (превышает почти в 5 раз!), но при этом не столь сильно уступает более старшим моделям – AF60 и AF80. Самой старшей модели наш экземпляр уступает по паспорту в среднем в 3 раза, по некоторым показателям и то меньше, а модели Nimble AF60 – не более, чем в 2 раза. Массивы всей линейки HPE Nimble имеют весь необходимый функционал, согласно своему статусу – массивам среднего ценового сегмента. Тут тебе и компрессия с дедупликацией, причем последняя с переменным блоком, и аппаратные снимки с согласованием на уровне приложения, и синхронная репликация, с возможностью реализации концепции Metro Storage Cluster, и поддержка технологии VVOL, QoS, возможность собирать Storage Pool из нескольких массивов – некое подобие федерации, и еще парочка козырей в рукаве в виде искусственного интеллекта и продвинутой аналитики.

Ну а теперь о цифрах. По паспорту система позволяет получить до 130К IOPS на блоках 4К в смешанной нагрузке 50/50 на случайных операциях ввода-вывода, 150K IOPS на все тех же блоках 4К при 100% случайном чтении и 150К IOPS при 100% случайной записи – все это без учета дедупликации. С ее же учетом итоговые показатели будут зависеть от ее общего коэффициента. К примеру, при общем коэффициенте дедупликации 10:1, немного просядут операции случайной записи – до 130К на блоках 4К, при этом количество IOPS на операциях чтения возрастет до 170К, а в смешенном режиме 50/50 заявлено 96К IOPS. По нынешним меркам более чем скромно для All-Flash массива. Тем более, что массив является представителем Mid-Range сегмента, и от них ожидаешь действительно приличных цифр, так как сегмент представляет из себя подобие гоночного трека, где каждая доля секунды на счету и производители выставляют лучшее, лишь бы поразить искушенную публику и завоевать их сердца (а заодно и кошельки).

Поражать тут с точки зрения цифр нечему, тем более что сейчас даже массивы Entry-Level, т.е. начального уровня, могут похвастаться и показателями 300+К IOPS, чем, к слову, могло бы и позавидовать приличное количество Hi-End систем хранения данных 8-10 летней давности. Ну, да, ну, да, прогресс, не стоит на месте – все так и есть. Другой вопрос, что критерии выбора у всех разные и не всем нужен самый быстрый автомобиль – кто-то больше склоняется к максимальному комфорту.

Но вернемся к нашему опытному образцу... С цифрами определились. Для нас не было по этому поводу никакого откровения, у вас теперь, надеюсь, тоже. Когда определились с ожидаемой производительностью массива, остался только один вопрос, насколько эти цифры будут честными, т.к. производители иногда завышают эти показатели и порой бывает тяжело добиться тех же показателей при тестировании аппарата.

К слову, в нашей практике компания HPE не была замечена в каких-либо манипуляциях с цифрами, в неполноте или в недостоверности ТТХ по продуктам, чего не скажешь о документации по работе с оборудованием (уж простите – наболело). Поэтому мы, конечно же, отнеслись к заявленным цифрам с доверием… и сразу же решили их проверить.TAdviser Security 100: Крупнейшие ИБ-компании в России 58.8 т

Плавно переходя к тестированию, естественно, нельзя не упомянуть состав нашего тестового стенда: здесь, как говорится, best practice не заглядывал. Если серьезно, то оборудование уже весьма подуставшее, процессоры на подключенных хостах не каноничные, гипервизоры – End of General Support. Что действительно радует, так это наличие SAN-сети на коммутаторах SN6000 (8 гигабитный Qloqic SANbox 5800 – привет из 2010 года). В общем не 4 гигабита и уже хорошо. Но те самые 16 гигабит FC на HPE Nimble AF40 раскрыть, к сожалению, не удастся. Да и конфигурация самого массива, тоже, скажем так, не best practice, т.к. официально рекомендуется использовать минимум 4 порта ввод-вывода на каждом контроллере, а в нашем случае мы имеем только 2 порта 16 гигабит FC в режиме 8 гигабит.

Рисунок 1: сервер DL385 Gen7, AMD Opteron 6180 SE, VMware ESXi 6.0.0

Из трёх серверов DL385 Gen7 собран кластер виртуализации на VMware ESXi 6.0.0. Управление через VMware vCenter в формате аплаинса на Linux. На каждом хосте по два процессора AMD Opteron 6180 SE и 192 гигабайт оперативной памяти DDR3 PC3-10600 ECC RDIMM (1300 MHz). Для подключения к SAN-сети используется две однопортовые FC HBA 8 гигабит (HPE 81Q) на каждом из хостов. Сам же HPE Nimble AF40 укомплектован 24 твердотельными накопителями объемом 480 гигабайт, двумя контроллерами и по одной двухпортовой 16 гигабитной FC HBA в каждом из них.

Относительно выбора программного обеспечения для нагрузочного тестирования изначально выбрали классику жанра – vdbench, но потом все-таки остановились на HCIbench в виду большей простоты и наглядности, и ориентированности на виртуальную среду VMware.

Пока, конечно, это все было хождение вокруг да около и относительно самой системы хранения HPE Nimble AF40 не было сказано ничего, кроме заявленных ТТХ. Делиться своими впечатлениями и результатами будем последовательно, начиная с настройки самой системы и далее переходя к тестам и кое-чему весьма интересному.

Впечатление №1: распаковка, монтаж и первичная настройка

Тут не станем сильно задерживаться – упаковка внушает доверие, все очень добротно: плотная картонная коробка, притянутая болтами к деревянному паллету, внутри массив защищен плотным полиэтиленовым пакетом и черной разновидностью пенопласта (упругий и не крошится). Все на своих местах - коробочки и пакетики с аксессуарами. Сам массив представляет из себя полку на 4U, очень увесист и габаритен, глубина полки этого мастодонта целых 89 см, а вес более 50 кг. Хотя, чему удивляться – сама коробка на самом деле огромна по меркам среднестатистического массива и как бы намекает на сидящего в ней монстра. Но шутки шутками, а вес имеет значение, особенно при монтаже. Так и здесь - металла много, пластика минимум, очень монолитно и добротно. Можно при желании хоть раз 10 монтировать и демонтировать и ничего не погнется, не сломается, не треснет и не отлетит, что на самом деле проблема для современного оборудования, которое изобилует пластиком, детальки из которого так и норовят треснуть или сломаться и после монтажа, лучше лишний раз такое оборудование не тревожить. Первоначальная настройка массива до безобразия проста и тут вам не сможет помешать даже неточности в документации по установке, да что там, даже полное отсутствие таковой – настолько все интуитивно понятно (хотя тут можете не переживать - вся документация на месте, и да, она без ошибок). А дополнительную веру в собственные силы поможет обрести Welcome Center для Nimble.

Производитель предлагает в помощь онлайн-портал с пошаговыми текстовыми и видео-инструкциями, что опять же будет не только полезно и удобно, но и, что самое главное, наглядно. Причем одним только Nimble дело не ограничилось, доступны материалы и по другой системе хранения – HPE Primera:

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

Ну и, конечно же, захватывающие видео сопровождения, а в качестве бонуса еще и ссылка на Installation Guide:

В итоге подготовка массива к работе занимает минут 15-30. За качество исполнения, упаковку, внешний вид и простоту первоначальной настройки – 5 из 5. Вес и габариты, конечно, дают о себе знать, но можно и потерпеть.

Впечатление №2: подключение HPE Nimble AF40 к кластеру VMware

И здесь наc ждал первый приятный сюрприз и плюс, который бесспорно ушел в копилку HPE Nimble, а именно, простая и понятная интеграция с VMware с использованием технологией VVOL. Тут, конечно, мы были впечатлены, отчасти еще и от того, что до этого не использовали технологию VVOL, но идеологически пытались ее воссоздать вручную использованием выделенных VMware VMFS Datastores под каждый виртуальный диск каждой виртуальной машины. Такой ручной подход был призван упростить использование аппаратных снимков, обезопасить от возможных проблем с очередями на уровне LUN (когда есть один жирный VMware VMFS Datastore и все виртуальные машины живут на нем, как в большой коммунальной квартире с общей кухней, на которой периодически могут устраивать поножовщину).

При наличии в системе хранения данных механизмов QoS это еще и позволяло настраивать для каждого отдельного взятого диска виртуальной машины свои ограничения по производительности или наоборот гарантировать заданный минимум.

Аппаратные снимки делались только на тех виртуальных томах системы хранения, которые принадлежали данной виртуальной машине, а не целиком всего общего VMware VMFS Datastore. Та же ситуация и с их восстановлением. Плюс исключалась проблема с нехваткой места на общем VMware VMFS Datastore и остановкой всех виртуальных машин из-за ошибки записи, если вдруг администратор проглядел. То есть по большей части все в угоду управляемости, контролю и исключению взаимовлияния. Но не смотря на такое весомое количество плюсов, минусов было так же предостаточно, особенно, что касается трудозатрат. А именно ручное создание всех необходимых виртуальных томов на уровне массива, презентация их кластеру, создание каждого из дисков виртуальной машины на своем выделенном VMware VMFS Datastore и так далее. Плюс такой вариант явно подошел бы не всем, так как существуют ограничения по их количеству - для ESXi 6.0.0 это значение равно 256. Но в нашем случае в лимит мы укладывались, а с неудобствами и трудозатратами мирились в угоду управляемости.

Технология VVOL вообще позволила уйти еще дальше, помимо указанных плюсов и отсутствии явных минусов, она позволила перенести и полностью автоматизировать операции по созданию виртуальных томов на системе хранения данных для виртуальных машин на VMware vCenter. То есть, настроив интеграцию единожды, теперь вообще нет какой-либо необходимости заходить на интерфейс управления HPE Nimble AF40, нет необходимости создавать новые презентации для новых томов, даже готовить тома заранее на системе хранения не обязательно в случае использования специфических настроек (тип диска – толстый или тонкий, включена ли компрессия, включена ли дедупликация, размер блока дедупликации), так как теперь это все делается с помощью vCenter и VM Storage Policies.

Для этого удовольствия всего лишь необходимо выполнить пять основных шагов (не считая стандартных требований по подключению системы хранения к серверам через SAN фабрики, например, зонирование):

Шаг 1. Выполнить интеграцию с vCenter:

Шаг 2. Создать на HPE Nimble структурный каталог – Folder с указанием типа управления VVOLs:

Шаг 3. Ознакомиться с Performance Policies на HPE Nimble для создания VM Storage Policies (можно так же создавать свои Performance Policies на HPE Nimble с указанием преднастроек – это по сути профиль создания виртуального тома):

Шаг 4. Создать необходимый набор VM Storage Policies в vCenter на основе Performance Policies:

Шаг 5. Подключить Folder к кластеру в vCenter:

Для искушенных так же есть возможность посмотреть разного рода информацию по VVOL через плагин HPE Nimble в vCenter, а также настроить график создания консистентных снапшотов на уровне VM Storage Policies:

Впечатление №3: нагрузочное тестирование синтетическими тестами

А теперь самое время проверить заявленные ТТХ массива. Самый простой паттерн нагрузки – 100% случайное чтение блоками 4К (без использования дедупликации). Используем встроенный в HCIbench нагрузочный инструмент со следующими настройками:

Общее количество виртуальных машин – 12, каждая с 8 дисками объемом 10 ГБ, разогрев 6 минут, время теста – 1 час, суммарное количество потоков – 384. И, ах да, чуть не забыл, один важный момент – предварительно перед тестом диски записываются абсолютно 100% случайными данными, таким образом, что полностью отсутствуют блоки с 0, поэтому компрессия на данных дисках показывает коэффициент 1:1. Это важно, т.к. при наличии нулевых блоков операции чтения могут значительно ускоряться при включенной компрессии.

По результатам получаем следующее. Аналитика со стороны интерфейса управления HPE Nimble AF40:

Результаты со стороны HCIbench (для самых внимательных: время отчета указано с учетом временной зоны GMT -07:00, что составляет разницу в 10 часов по сравнению с GMT +03:00):

Задержки на чтение высоковаты, хотелось бы уложиться в 2 мс, поэтому пробуем второй заход – настройки те же, но снижаем количество виртуальных машин до 6, тем самым снижая количество потоков до 192:

Уже значительно лучше.

Ну и, конечно же, было интересно, как отработает QoS, поэтому выставили ограничение для тестируемых VVOL в 20К IOPS и еще раз запустили первый тест на 384 потока, но в целях экономии время продолжительностью всего 10 минут.

Используя SSH-подключение к хостам ESXi и встроенную утилиту esxtop, видим, что с каждого хоста генерируется нагрузка в 125-128 потоков и при этом получаем очень высокие показатели задержки от FC HBA сервера до системы хранения. И тут ничего удивительного, система хранения отрабатывает политику QoS, понижая максимальное количество операций ввода-вывода в секунду до 20 000, что приводит к скапливанию очередей и задержкам в вводе-выводе.

Собственно, тут иначе никак. Функционал крайне полезный и поможет защитить продуктивную среду или критически важные сервисы от паразитной нагрузки со стороны тестовых лабораторий или других менее важных сервисов, которые не чувствительны к задержкам.

А как дела обстоят с записью? Прогоняем тест 100% случайная запись, размер блока 4К, остальные параметры те же, опять же для начала 384 потока.

По традиции прогоняем тест второй раз, но уже с 6 виртуальными машинами, а, следовательно, в 192 потока.

Тут тоже удалось уложиться в 2 мс. Результат весьма близок к аналогичным замерам по 100% случайному чтению. Это говорит о том, что соотношение показателей IOPS заявленных вендором являются релевантными. Напомню – по 150К IOPS для 100% случайного чтения блоками 4К и для 100% случайной записи блоками 4К. Хотя обычно по практике запись всегда проседает относительно чтения, вероятно, это чудесная магия запатентованной архитектуры HPE Nimble CASL с многоуровневым кэшированием как записи, так и чтения.

Вывод: достаточно неплохие результаты с учетом устаревшего оборудования, отсутствием 16 гигабитного FC, что, по нашему мнению, как раз-таки и помешало выйти на заявленные цифры.

Когда с синтетикой покончено, самое время переходить к расширенной аналитике и искусственному интеллекту Infosight, который призван упростить процессы мониторинга, управления и поддержки системы хранения на всем промежутке ее жизненного цикла.

Впечатление №4: ИИ HPE Infosight – в шахматы с ним не сыграешь, но вот проблемы найти и решить поможет

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

Тут и разнообразные дашборды: например, Operational, который позволяет оценить общее состояние массива или Recommendations, которые позволяют подробно ознакомится с рекомендациями (на рисунке ниже в правой части скриншота). Рекомендации, кстати, формируются на основании аналитики, которая производится искусственным интеллектом c использованием машинного обучения и телеметрии всей инсталляционной базы HPE Nimble по всему миру (в лабораториях HPE Nimble это Cross Stack Recommendations).

Ниже приведен пример рекомендаций по одной из проблем – Physical CPU Saturation с указанием масштаба бедствия. Так же доступны рекомендации и по оставшимся двум проблемам – Elevated Latency, Virtual CPU Overprovisioning – иногда щедрость тоже губит:

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

И, наконец, одно из самых полезных и интересных – это лаборатории HPE Infosight, где можно примерить на себя халат лаборанта и провести пару экспериментов или исследований.

Тут и вышеупомянутая Cross Stack Recommendations и Resource Planner, который позволит сэмулировать добавление на массив какой-либо нагрузки и как она повлияет в целом на производительность массива, причем есть тонкая настройка этой самой нагрузки.

Раньше, кстати, для этого всего требовались отдельные продукты, например, HP Virtualization Performance Viewer, которые, естественно, стоили денег, да и еще необходимо было их разворачивать и поддерживать.

Кажется, что есть проблемы в производительности системы хранения данных, нет проблем – просто запустите AI Performance Recommendations и получите анализ за выбранный период, если будут проблемы – будут и рекомендации, как их устранить.

Одним словом – здесь есть где разгуляться, а самое главное получить отчеты и конкретную информацию с минимальной затратой усилий (не надо ничего собирать, строить графики, вести эксель-таблицы и прочее), и предоставить руководству со словами – это не я так придумал, это ИИ на основе машинного обучения произвел анализ и интерпретацию входных данных, согласно чему, мы и имеем следующие рекомендации от вендора.

Опытный заводчик виртуальных машин может подумать: «вот еще тут была бы корреляция метрик производительности по виртуальной инфраструктуре с метриками системы хранения, а то как-то неудобно что-то искать в VMware vCenter, что-то в интерфейсе управления HPE Nimble в разделе Monitoring и затем прикидывать одно к другому излюбленным эмпирическим методом». И да, это тут тоже есть. В разделах Infrastructure -> Virtualization в зависимости от того, что вы используете (на текущий момент поддержка только для VMware и Hyper-V) можно получить информацию о своих датацентрах, кластерах, хостах, датасторах и виртуальных машинах (их загрузка, производительность, метрики).

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

Ну и напоследок это все решили заполировать самыми полезными ресурсами по HPE Nimble. Тут и документация, и прошивки, и дополнительное программное обеспечение, разного рода матрицы совместимости (куда же без них) и ссылка на портал поддержки, где можно вести работу по кейсам.

Наше резюме: с ИИ HPE Infosight все понятно, вещь полезная, удобная и нужная – это бесспорно. В 86% случаев система будет предотвращать или предлагать рабочее решение ваших проблем автоматически. Но вот в остальных случаях что? А если возникла жизненная необходимость пообщаться с «живым» человеком, а в ответ только бездушный голос машины или робота, который готов всячески тебе помочь, но в своей извращенной манере. Сразу вспоминается ситуация с дозвоном в банк или оператору связи, когда нужно еще очень сильно постараться, чтобы попасть на «живого» человека. Но тут, к счастью, обошлось. Есть выделенный телефон поддержки HPE Nimble, по которому отвечают люди и даже больше – инженеры (чувствуете разницу?). Но сейчас будет совсем хорошо – инженеры поддержки 3 уровня, в том числе и русскоязычные.

Впечатление №5: Поддержка, которая помогает

Как ни странно, в наше время — это большая редкость. При обращении в поддержку по какому-либо оборудованию, чаще всего приходится сталкиваться с поддержкой, которая меняет запчасти, иногда даже и не одну, иногда бывает даже замена «вкруг». Понятно, что это все в угоду простоты обслуживания, модульность систем к этому предрасполагает, но проблематика часто возникает не на уровне железа и замена запчастей не помогает ее решить, а время уходит, томное ожидание новых запчастей сменяется грустью за его бесполезную трату на очередной заход сбора логов и общение с поддержкой. В очередной раз поменялся инженер по кейсу, которому необходимо объяснять все с самого начала или, ознакомившись с историей кейса, он все равно продолжает задавать все те же вопросы.

В общем, согласитесь, всегда приятно, когда кто-то ломает шаблоны, а еще приятнее, когда из этого действительно выходит толк. Так вот, опишу нашу небольшую историю общения с L3 поддержкой HPE Nimble. Все началось с проблемы с одним из контроллеров, во время тестирования переключения контроллеров (HA Failover). После переключения нагрузки, контроллер ушел в перезагрузку и после этого не вернулся. Странная, конечно, ситуация, но даже сброс по питанию не помог. Естественно, открылся кейс с помощью ИИ HPE Infosight и был автоматически передан инженерам L3 технической поддержки HPE Nimble, так как тут сбой контроллера на лицо и требовалась расширенная диагностика. Далее следовали в большинстве своем стандартные процедуры общения с поддержкой, исключая разве что прохождение кругов ада для того, чтобы попасть, наконец, к толковому инженеру. Нашим кейсом, к слову, от начала и до конца занимался один и тот же инженер – Павел Тимургалеев. Мы уже были морально готовы к замене контроллера, согласитесь, достаточно ожидаемый исход. Но все получилось немного интереснее. Проблема оказалась в том, что контроллер был подключен по консольному кабелю к серверу, на котором был установлен СКУД (сервер использовался нами для доступа к консоли массива). Серверов стоечных у нас было всего два, поэтому раскидали один контроллер к одному, второй к другому, остальные же серверы были в форм-факторе блейд-сервер. СКУД каким-то образом держал на себе консольный порт контроллера HPE Nimble и не давал ему загрузиться. С заменой по итогу обошлось, проблема была решена, каким образом поддержка дошла до причины проблемы тоже остается загадкой. Но сам факт, что проблему удалось решить в кратчайшие сроки максимально эффективно, т.е. без 2-3 итерацией замены контроллера, после которых стало бы понятно, что дело не в контроллере, действительно, внушает уважение. Павлу и команде поддержки HPE Nimble однозначно хотелось бы выразить благодарность за проявленный профессионализм.

Странно, наверное, такое слышать, но больше не приходилось общаться с технической поддержкой HPE Nimble, т.к. за год эксплуатации массива не возникло абсолютно никаких поломок или проблем. Приятно, когда общение с поддержкой превращается в маленький праздник.

А где же минусы, минусы-то где? Ну не бывает такого, чтобы без минусов. Да, без минусов, конечно же, не обошлось. Один из основных минусов – это избыточная мощность. Честно говоря, под наши нагрузки хватило бы и гибридной модели в соотношении 20% SSD/80% MDL 7,2K, например, тех же HPE Nimble HF20 или HPE Nimble HF40, но был бюджет, а поэтому почему бы и нет. Но теперь приходится придумывать самим себе работу и вводить новые сервисы, т.к. видя, как система простаивает, сердце кровью обливается и хочется непременно ее нагрузить. Поэтому каждый раз, когда залезаешь в ИИ HPE Infosight, то получаешь мощный отклик от системы, она заставляет постоянно что-то оптимизировать, что-то настраивать, заставляет работать, одним словом, смотреть только вперед и не оглядываться назад, ведь за спиной надежный соратник. А может быть VDI? А почему бы и нет, черт возьми! Поэтому сейчас начали разворачивать и тестировать VMware Horizon с использованием концепции Just-in-Time (linked clones уже не торт). А тем временем аппетиты растут и уже где-то там на горизонте маячат новые сервера с NVIDIA Tesla T4 или серии RTX6000.

UPD: в рамках статьи упустил много чего интересного, а именно, первичную проблематику тестирования All-Flash массивов на гипервизорах VMware ESXi, с которой бились достаточно длительное время и грешили на HPE Nimble (мы и не говорили, что мы святые). Из коробки нагрузочное тестирование адекватно работать не будет, тут и проблемы с очередями на FC HBA (базовые значения драйвера) – DQLEN и No of outstanding IOs with competing worlds, а также ограничения со стороны виртуальных контроллеров виртуальных машин. Этого материала вполне хватит на отдельную статью.

Вы можете легко оценить все возможности и преимущества системы HPE Nimble для своей компании в демоцентре ГК «Паладин».