Як влаштована пам'ять NetApp FAS: NVRAM, Кеш і Тетріс

У цій статті я хочу розглянути внутрішню будову роботи пам'яті СГД NetApp FAS і як вона вміє збирати тетріс.


System Memory

Пам'ять СГД будь-якого контролера NetApp FAS складається з модулів оперативної пам'яті, які використовуються для кешування читання і запису, і запитані батарейкою, звідси приставка «NV» — Non Volatile MEMory / RAM / LOG. ОЗП ділиться на наступні функціональні частини: NVRAM, буфер MBUF (або системний кеш), про які докладніше.

* Скидання даних на диски відбувається MBUF, події заповнювання NVRAM, а не з самого NVRAM'а.


NVRAM & NVLOG

В NVRAM послідовно, на зразок LOG-записів у БД, збирається NVLOG-записи, в їх початковій формі, як вони були надіслані хостами. Як тільки дані від хоста потрапляють в NVRAM, хост одержує підтвердження запису. Після того, як відбудеться CP подія, яка генерує скидання даних з MBUF на диски з подальшим підтвердженням, NVRAM очищається. Таким чином у нормально працюючій СГД вміст NVRAM ніколи не читається, а тільки пишеться, а коли місце в ній закінчується, відбувається CP і NVRAM очищається. Читання NVRAM відбувається тільки після збою.

NVRAM в HA
В High Availability (HA) парі, з двох контролерів NetApp FAS, пам'ять NVRAM завжди зазеркалирована, кожен контролер має копію свого сусіда. Це дозволяє в разі відмови одного контролера переключити і далі обслуговувати всі хости на що залишився в живих контролер. Після того, як відбудеться CP подія (скидання даних на диск з підтвердженням), NVRAM очищається.
Якщо бути більш точним, то кожна з цих двох частин ділиться ще на дві частини, разом 4 для HA пари (тобто 2 локальні). Зроблено це для того, щоб по заповненні половини локального NVRAM, скидання даних не гальмував нові надходять команди. Тобто поки що відбувається скидання даних з однієї частини локального NVRAM, нові вже надходять у другу половину локального NVRAM.


NVRAM в MCC
Для того, щоб забезпечити захист даних від Split-Brain MCC, дані, які надходять на запис, будуть підтверджені хосту тільки після того, як вони потраплять в NVRAM одного локального контролера, його сусіда і одного віддаленого сусіда (якщо MCC складається з 4 нод). Синхронізація між локальними контролерами виконується через Cluster Interconnect (це зовнішнє підключення), а синхронізація на віддалену ноду виконується через FC-IV адаптери (це теж зовнішнє підключення). Ця схема дозволяє виконувати перемикання в рамках сайту, якщо другий контролер HA пари уцілів, або переключатися на другий сайт, якщо всі локальні ноди сховища вийшли з ладу. Перемикання на другий сайті відбувається за секунди.


NVRAM & Pass-Through

Важливо зазначити, що NVRAM з одного боку технологія яка є не тільки на озброєнні NetApp, але з іншого боку використовується NetApp, для зберігання логів (апаратна реалізація журналируемой файлової системи), в той час, як більшість інших виробників СГД використовують NVRAM на «блочному рівні» (Disk Driver level або Disk Cache) для кешування даних в NVRAM — в цьому велика різниця.
Наявність NVLOG дозволяє NetApp FAS не переводити в HA-парі, що залишився в живих один єдиний контролер у режим Pass-Through (запис, без кеша, прямо на диски) якщо один із них помер. Давайте трохи на цьому зупинимося і почнемо з того, навіщо взагалі потрібен кеш запису? Кеш потрібний, щоб обманювати хости і прискорювати запис, він підтверджує запис даних до того, як дані, насправді, потрапляють на диски. Навіщо взагалі переводити контролер у режим Pass-Through, якщо у кешу є батарейка, при тому що у всіх А-брендів СГД, є ще і віддзеркалення кеша в HA парі? Відповідь не зовсім просто побачити з першого погляду, по-перше, механізм HA піклується про те, щоб дані були не пошкоджені та скидалися на диски при виході з ладу одного з двох контролерів в HA-парі, а клієнти прозоро переключалися на партнера, по-друге, найважливіше, в даному випадку, щоб дані не були пошкоджені на рівні структури даних самої СГД, на цьому варто зупинитися детальніше. Перерахунок чек-сум для RAID, в пам'яті, давно не новинка, так як це прискорює роботу дискової підсистеми, багато, якщо не всі А-бренди освоїли цей трюк, але саме скидання даних з кеша у вже обробленому на рівні RAID вигляді залишає ймовірність пошкодження даних, яке не можна буде відстежити і відновити після перезапуску двох контролерів. Так ось, при виході з ладу першого, а потім ще й другого контролера, може виявитися так, що відстежити цілісність спочатку даних, що надійшли в слідстві обробки, тобто дані можуть бути пошкоджені, в інших ситуаціях відстежити і відновити ушкодження можливо, але для цього необхідно запускати перевірку структури даних СГД. Так як кеш запису стає наріжним каменем і потенційної великою проблемою, при виході з ладу одного контролера НА парі, більшість СГД потрібно переходити в режим PassThrough з прямим записом на диски, вимкнувши кеш запису, щоб усунути імовірність пошкодження своєї файлової структури. З іншого боку, більшість цих СГД дозволяє вручну адміністратору перевести залишився в живих контролер вручну, режим кешування записів, але це не безпечно, так як при виході з ладу другого контролера, дані на рівні файлової структури СГД можуть бути пошкоджені та їх доведеться відновлювати, іноді це може призводити до трагічних наслідків. Завдяки тому, що у FAS систем дані зберігаються у вигляді логів, а не в обробленому вигляді після WAFL або RAID вигляді, а скидання вже опрацьованих даних відбувається у вигляді накочування системного снепшота CP, єдиної транзакцією, це дозволяє повністю обійти ймовірність пошкодження даних. Таким чином, у багатьох сучасних конкуруючих системах зберігання, коли вмирає один контролер в HA парі, мало того, що на другий падає навантаження від померлого контролера, так він ще і відключає свій кеш для оптимізації записів, що сильно погіршує швидкість роботи в таких ситуаціях. Робиться це для того, щоб записати дані таки точно були записані у не пошкодженому вигляді на диски, а найважливіше — файлова структура СГД залишилася не пошкодженою. Деякі зовсім не переймаються цим питанням і просто чесно пишуть про це «нюанс» у своїй документації. А деякі намагаються обійти цю проблему за допомогою «милиці», пропонуючи купувати не 2-нодовую, а відразу 4-нодовую систему. Так, наприклад, влаштована система HP 3PAR, де в разі виходу з ладу одного контролера, в 4-х нодовой системі, решту 3 контролера будуть працювати в нормальному режимі запису, але в разі виходу з ладу 50% нод система таки перейде у режим Pass-Through. Іноді бувають кумедні ситуації, коли краще, щоб вже вся СГД померла, аніж щоб вона працювала з такими моторошними гальмами. Це контрастує з системами FAS, які навіть в однонодовых конфігураціях ніколи не відключають кеш, так як архітектурно захищені від подібних проблем.

Memory Buffer: Запис


Запис, насправді, завжди відбувається в MBUF (Memory Buffer). А з нього за допомогою запиту Direct Memory Access-DMA), NVRAM виконує копію цих даних до себе, що дозволяє економити ресурси CPU. Після чого модуль WAFL виділяє діапазони блоків, куди будуть записані дані з MBUF, цей процес називається Write Allocation. Модуль WAFL не просто виділяє бездумно блоки, а спочатку збирає тетріс (о так, Тетріс! Ви про нього не чули?, тоді дивіться на 28-й хвилині), і виділяє порожні блоки, так, щоб могти записати весь тетріс на диски одним нерозривним шматком. WAFL також виконує інші оптимізації для запису даних. Після того як в модуль WAFL приходить підтвердження запису з NVRAM, дані з MBUF, згідно виділеним блокам, обробляються модулем RAID, де обчислюється контрольна сума для парити дисків і обчислюється контрольна сума, яка зберігатися разом з кожним блоком (Block/Zone checksum). Важливо також відзначити, що дані з MBUF передаючись у модуль RAID «розпаковуються», наприклад деякі команди можуть запитувати запис повторюваного патерна блоків інформації або запит на переміщення блоків, такі команди самі по собі займають не багато місця в NVRAM, але при розпакуванні» генерують велику кількість нових даних.

Write Allocation

Це частина WAFL, яка зазнала значні зміни від своєї початкової архітектури пристрої, особливо у плані роботи новими носіями інформації і паралелізації (нова архітектура почала поставлятися в 2011 році) і підготувала плацдарм для використання нових технологій зберігання, які можуть з'явитися в найближчому майбутньому. Write Allocation завдяки інтелектуальності свого пристрою дозволяє гранулярно писати дані різними способами і в різні місця дискової підсистеми. Кожен окремий потік записуваної інформації обробляється окремо та може бути оброблений, в залежності від того, як дані пишуться, читаються, від розміру блоку і характеру запису (та ін). Грунтуючись на характері записуемых даних WAFL, може приймати рішення на який тип носія варто його писати і яким саме способом. Прикладом тому може послужити Flash накопичувачі, де має сенс писати з гранулярностью і за межами блоку, за якими відбувається очищення клітинок (erase block size). В доповнення мета інформація, яка займає, зазвичай, на багато менше місця в порівнянні з самими даними може розміщуватися окремо від великих блоків з корисними даними, в деяких випадках це має більшу вигоду, що було встановлену експериментальним способом. Насправді опис внутрішнього устрою Write Allocation це окрема, дуже велика тема.

RAID

З модуля WAFL дані передаються в модуль RAID, який обробляє і записує їх однією транзакцією, страйпами на диски, в тому числі і на диски парності. А так як дані пишуться завжди страйпами і завжди в нове місце, дані для дисків парності не потрібно перераховувати, вони вже заздалегідь були підготовлені для запису RAID модулем. Завдяки чому в системах FAS на практиці, парити диски завжди набагато менше навантажені ніж інші диски, що дуже контрастує із звичайною реалізацією RAID 4/6. Також варто відзначити, що прорахунок чек-суми виконується відразу для всього страйпа записуваних даних, ніколи не переписуючи дані (запис відбувається на нове місце), змінюється тільки метаінформація для (посилання на нові блоки з даними). Це призводить до того, що немає необхідності в разі перезапису на одному з дисків зчитувати кожен раз інформацію з інших дисків в пам'ять і перераховувати чек-суму, завдяки чому системна пам'ять, що використовується більш раціонально. Детальніше про пристрій RAID-DP.


Тетріс виконує IO-reduction

Тетріс — це механізм оптимізації запису і читання, який збирає дані, у проміжку між CP (CP Time Frame), в ланцюжки послідовностей блоків від одного хоста, перетворюючи дрібні блоки в більш великі послідовні записи (IO-reduction). З іншого боку, це дозволяє без складної логіки включати попереджуюче читання даних. Так, наприклад, немає різниці — прочитати 5KB, або 8KB, 13KB або 16KB і т. д. Ця логіка використовується для попереднього читання. Попереджуюче читання — це форма кешування даних, які потенційно можуть бути запитані в майбутньому, слідом за тими даними, які були тільки що запитані. І коли стає питання, які саме «зайві» блоки варто завчасно читати для перенесення в кеш, з тетрісом, ви автоматично отримуєте відповідь на це питання: ті, які записувалися разом із запитуваними даними.


Кеш для читання


Системний кеш (MBUF) використовується як для операцій запису, так і для операцій читання. В кеш потрапляють усі без винятку операції читання, а також з нього читаються тільки що записані дані. Коли CPU СГД не може знайти дані в системному кеші, він звертається на диски, і перше, що він робить — поміщає їх в кеш для читання, а потім віддає хосту. Далі ці дані можуть бути або просто видалені (це ж кеш читання, все і так є на дисках) або переміщені на рівень нижче (II рівень кешу), якщо такий є: FlashPool (SSD диски, кеш на читання-запис) або FlashCache (PCIe Flash карта, тільки кеш на читання). По-перше, системний кеш, як першого, так і другого рівня, витісняється дуже гранулярно: тобто може витіснятися 4 KB блок інформації. По-друге, системний кеш другого рівня, він deduplication-aware, тобто якщо такий блок продедуплицирован або клонований, він не буде знову копіюватися і займати в пам'яті простір. Це істотно покращує продуктивність за рахунок збільшення попадання в кеш. Так відбувається тоді, коли набір лежать на СГД даних може бути добре продедуплицирован або безліч разів клоновано, наприклад, в середовищі VDI.

Consistency Point


Як і багато сучасні файлові системи, WAFL є журналируемой файловою системою. Як і будь-яка журналируемая файлова система, журнал з лог-записами використовується для того, щоб забезпечити консистентним і її неповрежадемость на рівні СГД. У той час як всі інші реалізації журналируемых файлових систем влаштовані таким чином, щоб при пошкодженні могти відкотитися до консистентному станом (необхідно виконати перевірку та відновлення) і спробувати відновитися, WAFL влаштована таким чином, щоб при раптовій відмові контролерів не допустити самого пошкодження. Це досягається завдяки, по-перше, атомарности запису Consistency Point, по-друге завдяки застосуванню системних снепшотов при операціях запису.
Технологія снепшотирования NetApp виявилася настільки вдалою, що вона використовується в ONTAP буквально всюди, як базис, для багатьох інших властивостей і функцій. Нагадаю, що в CP — містяться дані, вже оброблені WAFL і RAID. CP — це теж снепшот, який перед тим, як відбувається скидання вмісту з системної пам'яті (після обробки модулями WAFL і RAID), СГД знімає системний снепшот з агрегату, і дописує нові дані на диски, далі СГД ставить позначку, що дані успішно записалися, після чого очищає NVLOG запису в NVRAM. Перед тим як відбувається скидання нових даних на диски (завжди в нове місце), знімається системний снепшот, після чого дані або записуються цілком однією транзакцією або (в разі аварії) використовується раніше створений снепшот (на рівні агрегату) як остання робоча версія файлової системи, у разі раптового перезапуску СГД в середині транзакції. Якщо сталася аварія і обидва контролери перезавантажити або втратили харчування, дані з NVRAM відновить усю інформацію і скинуть дані на диски, як тільки контролери знову включаться. Якщо вимкнеться або перезавантажиться тільки один контролер, то другий контролер з копії NVLOG в NVRAM відразу ж відновить дані і до запише їх, це навіть відбудеться прозоро для додатків. Коли дані таки успішно скидаються на диски, останній блок CP на основі старого кореневого иноді (снепшота) створює новий, включаючи посилання на старі і нові, тільки що записані дані.
Події генеруючі CP
CP — це подія, яка автоматично генерується при одному з декількох умов:
  • Минуло 10 секунд
  • Заповнилася системна пам'ять
  • Запущена команда зупинки контролера (Halt)
  • Інші.
До речі, стан скидання CP, дуже часто, може побічно вказувати на те, які є проблеми в роботі СГД, приміром коли у вас не вистачає шпинделів або вони пошкоджені.

Чому розмір NVRAM не завжди важливий?

Як вже було сказано раніше, NVRAM FAS використовується в системах як сховище лог записів, а не кешу запису, тому його розмір, HDD і гібридних FAS системах, не такий великий як у конкурентів. Просто в збільшенні NVRAM немає необхідності. Кожна система спроектована так, щоб їй вистачало ресурсів, для обслуговування максимального підтримуваного числа шпинделів.

Батарейка і Flash-диск

Як було вже сказано, батарея живить системну пам'ять. Але вона також живить і системний Flash-диск, встановлений у контролері. У разі пропажі електроживлення, вже після цього, вміст пам'яті буде злито на системний Flash-диск, так СГД може прожити дуже довго у вимкненому стані. Відновлення вмісту в пам'ять відбувається автоматично при запуску СГД. Батарея витримує до 72 годин, у зв'язку з чим, якщо харчування буде відновлено протягом цього часу, вміст залишиться в кеші і відновлення з системного Флеш-диска не відбудеться.

SSD і WAFL

Як було сказано раніше, WAFL завжди пише в нове місце, так зроблено архітектурно по безлічі причин, і одна з них — це робота скидання вмісту MBUF у вигляді снепшота. Адже інакше, в разі фізичної перезапису блоків — нових, поверх старих, при незавершеною транзакції скидання кешу, це могло б призводити до пошкодження даних. Виявилося, що підхід «записи в нове місце» дуже вдалим не тільки для обертових дисків, і механізму снепшотов, але і для Flash технологій, за необхідності рівномірно утилізувати всі комірки SSD дисків.

Висновки

ОЗП NetApp FAS виконує не просто прискорення операцій читання і операцій запису, але і архітектурно влаштована так, щоб забезпечувати високу надійність, швидкість і оптимізацію для таких операцій. Багатий функціонал, множинна ступінь захисту і швидкість роботи системного кеша якісно відрізняють системи A-класу, для високих продуктивних навантажень і критично важливих, завдань.

Тут можуть міститися посилання на Habra-статті, які будуть опубліковані пізніше.
Повідомлення щодо помилок у тексті прошу направляти в ЛС.
Зауваження, доповнення і запитання за статтею навпаки, прошу в коментарі.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.