Хочеться пролити світло на цікаву лінійку систем зберігання даних 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-ом Tri^ Parity + HDD (про це нижче).
Розгляньмо алгоритми читання і запису
Процес запису на масиви Adaptive Flash
Розпишемо процес запису:
- Запис від різних програм різними блоками;
- 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 дисків.
Процес читання в масивах Adaptive Flash
Розглянемо, що відбувається при читанні:
- Запитуємо блок в 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 /1x Xeon / / 2p FC/ ;
- Хост 2: Сервер HPE /1x EPYC / / 2p FC/ ;
- З'єднання серверів безпосередньо до СГД, оскільки під рукою не було комутаторів Fibre Channel. Тому в серверах по 2шт двопортових картки, щоб завантажити всі 4 порти на кожному контролері СГД;
- VMware vSphere 7;
- Тестування за допомогою HCIbench 2.5.3;
Для початку нам було цікаво порівняти наш Adaptive Flash HF60 з протестованим All Flash AF40:
Огляд HPE Nimble або практичний досвід використання. Чи все так добре, як заявляє виробник?
Хотілося б поділитися з вами практичним досвідом тестування та використання системи збереження данн...
habr.com
Навантажуємо наш масив аналогічними параметрами і врешті зводимо результати.
Перший тест: 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. Після перевірки конфігурації виявилося, що для тестових машин було вимкнено кешування і читання не прискорювалося взагалі. Після правильного налаштування все «злетіло». І як тільки вони не намагалися «вбити» швидкість масиву - не виходило (в рамках розумного природно). У підсумку лише в умовах особистого досвіду у них змінилася думка. До чого це? До того що дуже корисно брати «залізяку» на тест, коли її пропонують (та ще й безкоштовно).