Хочется пролить свет на интересную линейку систем хранения данных HPE Nimble Storage Adaptive Flash и попытаться раскрыть вопрос почему маркетологи решили его назвать «Adaptive Flash», а не более традиционно - «Hybrid Flash». Судя по поиску, существует не так много обзоров и статей, посвященных Nimble, поэтому надеюсь, что этот материал будет полезен интересующимся данной темой.
В мое распоряжение попал массив с флагманскими контроллерами - HF60. Это СХД 5-го поколения (Nimble Gen5), но уже по состоянию на 04.05.2021 компания HPE анонсировала (пока только AllFlash) 6-е поколение (Nimble Gen6), которое будет называться Allerta 6000. Adaptive Flash 6-го поколения - анонс ожидается летом 2021. Так что пока наш подопытный последнего (актуального) поколения.
Итак, чем же интересен HPE Nimble Adaptive Flash?
Давайте начнем издалека. Компания Nimble Storage берет свое начало в 2008 году и уже в 2014 наделала много шуму, объявив о революционном достижении (на тот момент) – доступность систем хранения данных превысила 99,999%. В 2016 году этот показатель уже составлял 99,999928%. Традиционно, столь успешные стартапы поглощаются более крупными компаниями. Так и случилось с Nimble - в 2017 году компания влилась в ряды Hewlett Packard Enterprise. За счет чего им удалось получить такие цифры доступности (причем это не лабораторные, а реальные данные)? Если совсем коротко: архитектура и «надстройка» в виде аналитической платформы InfoSight. Давайте остановимся на каждом пункте чуть подробнее.
Архитектура
Если Вам лень читать, можете посмотреть видео (на англ.):
СХД Nimble в своей основе использует архитектуру CASL (Cache Accelerated Sequential Layout). В основу архитектуры заложено:
Active/Standby контроллеры. Большинство других систем с двумя контроллерами Active/Active демонстрируют производительность с нулевым запасом мощности, поэтому, если один из контроллеров недоступен - вы уведёте половину скорости...
Функционал редупликации/компрессии/шифрования в режиме онлайн (на лету). Подробнее как это работает ниже в описании операций чтения и записи.
RAID Tripple Parity+ с фиксированным стартовым набором дисков 21шт HDD + 6шт SSD. Массив выдерживает выход из строя 3 любых дисков из одной RAID группы. Но лучшее качество Triple+ RAID не в том, что он защищает от потери любых 3 дисков. Крутая часть — это «+». Это позволяет системе не иметь проблем с целостностью данных, даже если на каждом отдельном диске в системе возникают ошибки параллельного чтения секторов и три диска были потеряны. Это уровень устойчивости к коррелированным по времени ошибкам, который ни один другой массив в мире даже близко не может предложить.
Защита данных через каскадные многоступенчатые контрольные суммы.
Память с защитой по питанию – NVRAM.
SSD кэш на чтение (в случае с Adaptive Flash). Важно отметить, что RAID для SSD не используется, т. к. задача кэша дать максимальную скорость. Насчет надежности можно не беспокоиться, поскольку данные в кэш копируются с защищенных RAID-ом TripleParity+ HDD (об этом ниже).
Рассмотрим алгоритмы чтения и записи
Распишем процесс записи:
Запись от разных приложений разными блоками;
NimbleOS принимает запись на NVDIMM активного контроллера;
NimbleOS зеркалирует NVDIMM активного контроллера в NVDIMM Standby контроллера;
NimbleOS подтверждает запись хосту;
Блоки копируются в DRAM, где и происходит «магия» архитектуры CASL, а именно:
a. Дедупликация с переменным блоком;
b. Сжатие с переменным блоком;
c. Блоки собираются в страйпы размером 10 Мбайт;
d. Страйпы последовательно пишутся на HDD;
Достойные кэша блоки или блоки из «Pinned» томов копируются на SSD кэш + блоки индексируются (индекс пишется на SSD и HDD в фоне). Есть 3 настройки кеширования которые можно выставить на каждый том:
«Default» – данные кэшируются в автоматическом режиме по выбору NimbleOS;
«Pinned» – настройка, которая по умолчанию копирует все данные тома на SSD диски и мы получаем All Flash на чтение;
«OFF» - выключенное кеширование, т. е. SSD диски не задействованы вообще. Полезно для томов, где нет необходимости ускорять чтение;
Какие преимущества имеет такая запись?
Во-первых: количество операций Random write в бэкенде системы минимизировано. По сути, большинство операций происходит в оперативной памяти кэша контроллеров, компрессия выполняется после дедупликации, таким образом число операций ввода-вывода на дисках SSD/HDD сведено к минимуму.
Во-вторых: последовательная запись помогает избежать задержек на механических дисках. Иными словами, благодаря такой архитектуре используется максимум выгоды от обычных HDD дисков.
Рассмотрим, что происходит при чтении:
Запрашиваем блок в NVDIMM. Если данные там – отдаем хосту;
Если блока нет, читаем из DRAM;
Если блока нет, читаем с SSD:
a. Если блок есть, проверяем контрольную сумму, разжимаем;
b. Регидрируем и отдаем хосту;
Если блока нет, читаем с HDD, блок ищем через индекс;
a. Если блок есть, проверяем контрольную сумму, разжимаем;
b. Регидрируем и отдаем хосту;
Если блок достоин кэша, копируем на SSD;
Какие преимущества дает такой алгоритм чтения?
Во-первых: скорость ограничена не производительностью дисков, а скоростью памяти NVDIMM (которая существенно быстрее SSD дисков) т. е. контроллерами.
Во-вторых: согласно живой статистике, массив больше 95% «попадает в кэш». Иными словами, имея в запасе всего 10…20% SSD дисков, массив будет обеспечивать скорость «All Flash» больше 95% времени. Важно отметить, что это не означает что оставшиеся 5% времени данные будут читаться медленно с механических дисков. Дисков в стартовом наборе - 21 шт., при чтении их скорость суммируется. Будет иметь место то, что при чтении с HDD дисков задержка будет немного больше чем 1мс. Но не забываем, что этого легко избежать настройкой кэширования индивидуально для каждого тома.
Резюмируя по архитектуре:
Данные защищены от выхода из строя 3-х любых накопителей;
Данные дедуплицируются и сжимаются в памяти до записи на диски без существенного падения производительности;
Данные пишутся быстро: благодаря алгоритму архитектуры CASL;
Данные читаются быстро: кэшируются на SSD диски для ускорения чтения и здесь нет никакого тирринга данных как в традиционных гибридах;
Данные можно дополнительно защищать шифрованием;
Гибкие настройки. Можно вкл/выкл индивидуально для каждого тома: дедуп; компрессия; шифрование; кеширование; ограничение по IOPS или пропускной способности (или того и другого) и прочее;
Гибкие возможности масштабирования емкости/производительности:
возможность масштабировать емкость (добавлять дисковые полки);
емкость и производительность (добавлять еще один массив в кластер, до 4 шт);
производительность (заменить контроллеры на более производительные).
InfoSight
Тезисы:
HPE InfoSight — это передовая в отрасли платформа облачной аналитики InfoSight. Передовая - поскольку начала работать гораздо раньше, чем у других вендоров. А здесь важна наработка системы по времени. Чем дольше она работает, тем больше данных собирает, тем больше проблем может предотвратить. Об этом ниже.
Доступность СХД HPE Nimble 99,9999%, достигается благодаря применению InfoSight.
Миссия HPE InfoSight: сохранять маниакальный фокус на предоставлении заказчику такой поддержки, чтобы все завидовали!
Данная технология позволяет СХД непрерывно в автоматическом режиме собирать большое количество данных как о собственном состоянии, так и об окружающей виртуальной инфраструктуре (подключенные сети, серверы, платформы виртуализации), это важно, поскольку более половины сервисных инцидентов, как правило, не связаны с СХД. Затем эти показатели отправляются в облачную систему, где с помощью сложных аналитических алгоритмов выявляются текущие проблемы и делаются прогнозы о будущем состоянии инфраструктуры. На основе данных выводов предоставляются автоматические исправления и рекомендации для администратора СХД.
Например, при обнаружении у одного из заказчиков проблемы в совместимости микропрограммы контроллеров СХД с приложениями гипервизора, система автоматически заблокирует возможность установки данной версии прошивки на СХД у других заказчиков, а тем у кого уже установлена схожая конфигурация - будет предложен апдейт системы. Такой подход помогает предотвращать сбои до их возникновения, причем во многих случаях без вмешательства человека.
По данным HPE, при использовании InfoSight 86% проблем разрешаются без участия ИТ-службы. Сюда входят инциденты как с самой СХД, так и с окружающей инфраструктурой.
InfoSight позволяет значительно сократить время на поиск проблемных узлов инфраструктуры в случае деградации производительности. Система в удобном графическом виде показывает текущее время отклика и статистику задержек за определенный период по проблемной ВМ не только относительно самой СХД, но и сети передачи данных SAN, а также приложений гипервизора. Отклонение каких-либо показателей в кратчайшие сроки позволит определить «узкое место» инфраструктуры. Не нужно переключаться между несколькими системами мониторинга, все показатели доступны в едином портале, так как InfoSight интегрируется с VMware VCenter. В процессе диагностики собирается только служебная информация, собственные данные заказчика не затрагиваются. Информация передается по защищенному SSL каналу.
Некоторые примеры передаваемых данных:
Серийный номер массива.
Базовая информация о работоспособности (health check).
Системные журналы событий.
Параметры настроек системы.
Статистика работы системы.
Самое вкусное на десерт - тестирование
Тестовая конфигурация:
СХД Nimble HPE Nimble Storage Adaptive Flash HF60 / 21x2TB HDD / 5.76TB (6x960GB) SSD Cache / 4x16GB FC на каждый контроллер;
Хост 1: Сервер HPE DL160 Gen10 / 1x Xeon 4210R / 6x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;
Хост 2: Сервер HPE DL325 Gen10 / 1x EPYC 7551P / 8x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;
Подключение серверов напрямую к СХД, т. к. под рукой не было коммутаторов Fibre Channel. Поэтому в серверах по 2шт двухпортовых карточки, чтоб загрузить все 4 порта на каждом контроллере СХД;
VMware vSphere 7;
Тестирование с помощью HCIbench 2.5.3;
Для начала нам было интересно сравнить наш Adaptive Flash HF60 с протестированным All Flash AF40:
Нагружаем наш массив аналогичными параметрами и в конце сводим результаты.
Первый тест: 384 потока/100%, получаем результаты:
Второй тест: 192 потока/100% чтение, получаем результаты:
Третий тест: 192 потока/100% запись, получаем результаты:
Сравниваем результаты Adaptive Flash HF60 vs All Flash AF40:
Пару слов о полученных результатах
Получаем то, что СХД с медленными 7,2k дисками дает большую производительность и меньшое время отклика чем All Flash массив. Как так? Все дело в контроллерах и архитектуре. В нашем случает стоят более производительные контроллеры и за счет «магии» архитектуры CASL «гибриды» Adaptive Flash показывают производительности сопоставимую с All Flash (контролеры используются одинаковые HF20=AF20, HF40=AF40, HF60=AF60, разница HF и AF только в конфигурации дисках). Причем скорость и задержки HF60 выигрывает при записи, где в Adaptive Flash никак не задействованы SSD.
За то время что у нас был массив мы смогли сравнить еще с одной конфигурацией All Flash XS5226D СХД QSAN. К нам попал такой результат тестирования:
Единственное, что мы не смогли повторить 464 потока при 32-х виртуалках. Поэтому сделали 448 и 480.
448/480 одновременных потоков серьезная нагрузка. Можно отметить, что здесь массив вполне играет наравне с «дешевым All Flash». У QSAN очень много непонятных пиков и провалов по задержке. Поэтому Nimble существенно выигрывает по 95-му перцентилю.
Эксперименты с дудепликацией и компрессией
При 100% записи производительность проседает некритично ~ 20%. При 100% чтении почти ничего не меняется, что вполне логично. Гораздо интереснее 70/30. При наличии нулевых блоков операции чтения ускоряются при включенной компрессии.
Итого: почему его назвали «Adaptive Flash» а не «Hybrid Flash»?
Чтобы не путать их с традиционными гибридными массивами в основе которых в основном лежит тирринг данных. Тирринг в свое время был хорошей технологией, но сейчас… он требует внимания администратора, правильную настройку и многое другое, что отнимает время. А здесь просто нужно выбрать емкость, проставить политики для томов и «погнали». Остальное массив сделает сам: подскажет, где что не так, где «шумные» виртуалки, где в сети большие задержки, откроет и закроет сервисный кейс и многое другое из того, что экономит время.
Могу еще добавить, что наши инженеры скептически относились к данному массиву до тестирования. После первых предварительных результатов (~94k IOPS и задержки 5мс) на 100% чтение… Возник спор, т. к. 94k полученных и 300k «теоретических» сильно отличались. Инженеры стояли на том, что невозможно получить больше на дисках 7200. После проверки конфигурации оказалось, что для тестовых машин было выключено кеширования и чтение не ускорялось вообще. После правильной настройки все «взлетело». И как только они не пытались «убить» скорость массива – не получалось (в рамках разумного естественно). В итоге лишь в условиях личного опыта у них поменялось мнение. К чему это? К тому что очень полезно брать «железяку» на тест, когда ее предлагают (да еще и бесплатно).
amarao
Хотите я вам расскажу про ночной кошмар любой системы, у которой 95% кешировано?
Допустим, в ДЦ пропало питание без предупреждения. Допустим, у нас хранилка на 100Тб, утилизация около 30%. Там лежат виртуалки. Допустим, компрессия и дедупликация даёт нам 50% экономии (это означает, что при полной дедупликации у нас получается 60% утилизации, всё ещё хорошо). Допустим, средний том 30Гб. Это означает, что на СХД 2000 виртуальных машин.
И вот у нас старт. СХД прогревается, гипервизоры прогреваются и начинают стартовать. Благодаря дедупликации данные ОС в горячем кеше и всё идёт отлично. Запускается ~1500 виртуальных машин, и вот они доходят до этапа монтирования файловой системы. А там:
а) Не было проверок уже больше полугода.
б) Unclean shutdown
И вот у вас 1500 fsck шуршат по диску. В режиме random read, который гарантировано уникальный для каждой виртуалки. Ice cold random read. От 1500 виртуалок. И ещё 500 на подходе.
Диски в полном ауте, кеши пусты, пока… пока не случается 300с таймаут и первая виртуалка решает, что если ей блочное устройство не ответило за 300с, значит оно не ответит никогда, и не переводит файловую систему в RO режим из-за ошибки.… Если бы не опция паник, после чего виртуалка перезагружается. И снова видит unclean shutdown...
1500 виртуалок запаниковало и ушло в ребут. 500 на подходе.
95% кеширования означает, что оставшиеся 5% система жидко обсирается. Если это единичные всплески, с этим можно жить. Но кроме correlated errors ещё бывает и correlated load, и вот тут-то и наступает отрицательный рост стабильности, сопровождающийся хлопком аптайма.
Amazi
Правильные алгоритмы кэширования подразумевают всяческие префетчи, прочие механизмы предсказания дальнейшего чтения, оптимизацию очередей, что зачастую превращает random read в банальное потоковое чтение широким страйпом и прогревает кэш побыстрее.
amarao
Вы не можете сделать prefetch для серверов, которые первый раз в жизни задумались про fsck. Плюс, "оптимизация очередей" работает в очень узкой ситуации (например, 10 конкурентных последовательных чтений).
Каждый fsck — это прыжки по диску (по всему диску!), а у вас 30% утилизация, т.е. у вас 1500 очередей, каждая из которых прыгает по десяткам гигабайт, а вместе они прыгают по всему provisioned space, причём (подло) только по записанным данным.
Если вы научитесь предсказывать неожиданное чтение (ice reads), то можно завязывать с СХД и смело идти на фондовые рынки.
Amazi
Не знаток fsck, но он разве не inodam-и идёт в том порядке, как были записаны данные?
Нимбл, да и все, LFS-based массивы физически записывают пришедшие данные подряд, а не на место, соответствующее физическому LBA (оперируя логическим LBA), поэтому вероятность поднять префетчем нужные данные, на мой взгляд, достаточно высока. Да и у просто thin provisioned, даже без LFS, новые данные будут физически записываться подряд.
Но да, надо будет как-то попробовать такой тест.
amarao
Я просто видел, что становится с оптимистично прогретыми СХД после перезагрузок такого характера. Ничего хорошего. После 2-3 циклов приходят админы, ставят все виртуалки в shutdown, и начинают запускать их пачками. Начинается всякая консольная магия, типа "взять список всех не запущенных, и группами по 30 штук", а потом охота за теми, которые remount RO сделали вместо паники.
Главное, при наличии кешей всегда знать ответ на то, что будет при ice reads. Рассказы вендоров про то, что у них суперкеширование и "такого не будет" рассеиваются очень просто. Если у них 95% кешированных чтений, то есть 5% не кешированных. Это в average. Дальше вопрос: может ли случиться коррелированный сценария обращения к некешированным данным? Ответ, да, может. На любой кеш может быть атака (человеческая или стихийная) и любой кеш по очевидным причинам может быть пропущен (потому что если кеш 10% от медленного слоя, то где-то там (при 50% утилизации) есть 80% данных, чтение которых идёт мимо кеша).
И вопрос в том, как к этому готовиться, а не в том, что какой-то магический вендор может кешом в 10Тб обслужить 100Тб данных.
V_serg68 Автор
Вопрос интересный но…
во первых: про систему «midrange» уровня. 2000 виртуалок многовато для одной такой системы. Пару сотен – в самый раз. Как Вы видели, мы тестили 480 потока с профилем 60/40, результат отклика был ~ 4 мс. Nimble может объединится в кластер (причем модели СХД не обязательно могут быть одинаковы) с суммированием производительности, т.е. 4 таких системы с нагрузкой в 4*480=1920 потоков при 60/40 уложатся в отклик до ~4 мс.
во вторых: как я писал, первые тесты по ошибке были сделаны без кеширования (без участия SSD кеша на чтения, на голых HDD дисках). При 384 потоках получилось 94k IOPS 4k и отклик в ~5мс при 100% чтении. Что будет если увеличить это до 1500 потоков (без кеширования) – вопрос пока открытый. Если доберутся руки ради эксперимента попробую сделать. Делаю ставку что отклик будет в районе 10…20мс.