Разделы

Цифровизация Инфраструктура Техника

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

Системы хранения данных HPE Nimble достаточно популярны на российском рынке. Дмитрий Прочанов, руководитель отдела системной интеграции группы компаний «Паладин», разобрался, насколько заявленные свойства модели All-Flash HPE Nimble AF40 соответствуют заявленным характеристикам.

Эту модель HPE позиционирует среди своего же семейства All-Flash-массивов Nimble, как оптимальный выбор по соотношению цена/производительность. С точки зрения производительности система достаточно сильно отличается от младшей модели AF20 (превышает почти в 5 раз!), но при этом не столь сильно уступает более «возрастным» моделям — AF60 (не более чем в 2 раза) и AF80 (в среднем в 3 раза).

Массивы линейки 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 не была замечена в каких-либо махинациях с цифрами или ТТХ по продуктам. Поэтому мы, конечно же, отнеслись к заявленным цифрам с доверием… и сразу же решили их проверить.

Плавно переходя к тестированию, естественно, нельзя не упомянуть состав нашего тестового стенда: здесь, как говорится, 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 Гбит.

paladin01.jpg

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

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

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

Упаковка внушает доверие, все очень добротно: плотная картонная коробка, притянутая болтами к деревянному паллету, внутри массив защищен плотным полиэтиленовым пакетом и черной разновидностью пенопласта (упругий и не крошится). Все на своих местах — коробочки и пакетики с аксессуарами.

Сам массив представляет собой полку на 4U, очень увесист и габаритен, глубина полки этого «мастодонта» — целых 89 см, а вес — более 50 кг. Хотя, чему удивляться — сама коробка огромна по меркам среднестатистического массива и как бы намекает на сидящего в ней «монстра». Шутки шутками, а вес имеет значение, особенно при монтаже. Так и здесь — металла много, пластика минимум, очень монолитно и добротно. Можно при желании хоть раз 10 монтировать и демонтировать — ничего не погнется, не сломается, не треснет и не отлетит. На самом деле, это давно стало проблемой для современного оборудования, которое изобилует пластиком; детальки так и норовят треснуть или сломаться даже после монтажа.

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

paladin02.jpg

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

paladin03.jpg

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

paladin04.jpg

Суммарно подготовка массива к работе занимает 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:

paladin06.jpg

Шаг 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-процентное случайное чтение блоками (без использования дедупликации). Используем встроенный в HCIbench нагрузочный инструмент со следующими настройками:

paladin12.jpg

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

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

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

paladin14.jpg

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

paladin16.jpg

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

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

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

paladin21.jpg

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

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

paladin23.jpg

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

paladin25.jpg

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

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

Когда с синтетикой покончено, самое время переходить к расширенной аналитике и искусственному интеллекту HPE 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, который позволит сэмулировать добавление на массив какой-либо нагрузки и изучить, как она повлияет в целом на производительность массива. При этом есть тонкая настройка выбранной нагрузки.

paladin34.jpg

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

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

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

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

paladin36.jpg

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

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

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