Привіт читачі Хабра. Цією статтею ми відкриваємо цикл, який розповідатиме про розроблену нами гіперконвергентну систему AERODISK vAIR. Спочатку ми хотіли першою ж статтею розповісти все про все, але система досить складна, тому будемо їсти слона частинами.
Почнемо розповідь з історії створення системи, заглибимося у файлову систему ARDFS, яка є основою vAIR, а також поміркуємо трохи про позиціонування цього рішення на російському ринку.
У подальших статтях ми детальніше розповідатимемо про різні архітектурні компоненти (кластер, гіпервізор, балансувальник навантаження, система моніторингу тощо), процес налаштування, порушимо питання ліцензування, окремо покажемо краш-тести і, звичайно ж, напишемо про навантажувальне тестування і сайзингу. Також окрему статтю ми присвятимо community-версії vAIR.
Аеродиск — це начебто історія про СГД? Чи навіщо ми взагалі почали займатися гіперконвергентом?
Спочатку ідея створити свій гіперконвергент прийшла нам десь у районі 2010 року. Тоді ще не було ні Аеродиску, ні подібних рішень (комерційних коробкових гіперконвергентних систем) на ринку. Завдання у нас було таке: з набору серверів з локальними дисками, об'єднаних інтерконнектом за протоколом Ethernet, треба було зробити розтягнуте сховище і там же запускати віртуальні машини та програмну мережу. Все це потрібно реалізувати без СГД (бо на СГД та її обв'язку просто не було грошей, а своєї СГД ми тоді ще не винайшли).
Ми перепробували багато open source-рішень і все-таки це завдання вирішили, але рішення було дуже складним, і його важко було повторити. Крім того, це рішення було із розряду «Працює? Не чіпай!». Тому, вирішивши це завдання, ми не стали далі розвивати ідею перетворення результату нашої роботи на повноцінний продукт.
Після того випадку ми відійшли від цієї ідеї, але нас все одно не залишало відчуття того, що це завдання цілком вирішуване, а користь від такого рішення більш ніж очевидна. Надалі HCI-продукти закордонних компаній, що вийшли, це відчуття тільки підтвердили.
Тому в середині 2016 року ми повернулися до цього завдання вже в рамках створення повноцінного продукту. Тоді в нас ще не було жодних взаємин із інвесторами, тому стенд розробки довелося купувати за свої невеликі гроші. Набравши на Авіто БУ-х серверів і комутаторів, ми взялися за справу.
Основним початковим завданням було створення своєї, нехай простої, але своєї файлової системи, яка змогла б автоматично і рівномірно розподіляти дані у вигляді віртуальних блоків на n-й кількості нод кластера, які об'єднані інтерконнектом по Ethernet-у. У цьому ФС має добре і легко масштабуватися і незалежної від суміжних систем, тобто. бути відчуженим від vAIR у вигляді «просто сховища».
Перша концепція vAIR
Ми навмисно відмовилися від використання готових open source-рішень для організації розтягнутого сховища (ceph, gluster, lustre та подібні до них) на користь своєї розробки, оскільки вже мали з ними багато проектного досвіду. Безумовно, самі собою ці рішення прекрасні, і ми до роботи над Аеродиском реалізували з ними не один інтеграційний проект. Але одна справа - реалізувати конкретне завдання одного замовника, навчити персонал і, можливо, купити підтримку великого вендора, і зовсім інша справа - створити продукт, що легко тиражується, який буде використовуватися під різні завдання, про які ми, як вендор, можливо навіть самі знати Не будемо. Для другої мети існуючі open source продукти нам не підходили, тому вирішили розподілену файлову систему пиляти самі.
Через два роки силами кількох розробників (які поєднували роботи над vAIR з роботою над класичною СГД Engine) досягли певного результату.
До 2018 року ми написали найпростішу файлову систему і доповнили її необхідною обв'язкою. Система об'єднувала за внутрішнім інтерконнектом фізичні (локальні) диски з різних серверів в один плоский пул і «різала» їх на віртуальні блоки, далі з віртуальних блоків створювалися блокові пристрої з тим чи іншим ступенем стійкості до відмов, на яких за допомогою гіпервізора KVM створювалися і виконувались вірту машини.
З назвою файлової системи ми особливо заморочуватись не стали і лаконічно назвали її ARDFS (здогадайтеся, як це розшифровується))
Цей прототип виглядав добре (не візуально, звичайно, візуального оформлення тоді ще не було) і показував хороші результати щодо продуктивності та масштабування. Після першого реального результату ми дали хід цьому проекту, організувавши вже повноцінне середовище розробки та окрему команду, яка займалася лише vAIR-ом.
Саме на той час дозріла загальна архітектура рішення, яка досі не зазнала серйозних змін.
Поринаємо у файлову систему ARDFS
ARDFS є основою vAIR, яка забезпечує розподілене відмовостійке зберігання даних всього кластера. Одна з (але не єдина) відмінних рис ARDFS полягає в тому, що вона не використовує ніяких додаткових виділених серверів під мету і управління. Так було задумано спочатку для спрощення зміни рішення та його надійності.
Структура зберігання
У межах всіх нод кластера ARDFS організовує логічний пул із усього доступного дискового простору. Важливо розуміти, що пул — це ще дані і форматований простір, а просто розмітка, тобто. будь-які ноди із встановленим vAIR-ом при додаванні до кластера автоматично додаються до загального пулу ARDFS і дискові ресурси автоматично стають спільними на весь кластер (і доступними для майбутнього зберігання даних). Такий підхід дозволяє на льоту додавати і видаляти ноди без будь-якого серйозного впливу на систему, що вже працює. Тобто. систему дуже легко масштабувати цеглою, додаючи або прибираючи ноди в кластері при необхідності.
Поверх пула ARDFS додаються віртуальні диски (об'єкти зберігання для віртуалок), які будуються із віртуальних блоків розміром 4 мегабайти. На віртуальних дисках безпосередньо зберігаються дані. На рівні віртуальних дисків також задається схема стійкості до відмови.
Як можна було вже здогадатися, для стійкості до відмови дискової підсистеми ми не використовуємо концепцію RAID (Redundant array of independent Disks), а використовуємо RAIN (Redundant array of independent Nodes). Тобто. відмовостійкість вимірюється, автоматизується і керується, виходячи з нід, а не дисків. Диски, безумовно, теж об'єкт сховища, вони, як і решта, моніторяться, з ними можна виконувати всі стандартні операції, в тому числі і збирати локальний апаратний RAID, але кластер оперує саме нодами.
У ситуації, коли дуже хочеться RAID (наприклад, сценарій, що підтримує множинні відмови на маленьких кластерах), ніщо не заважає використовувати локальні RAID-контролери, а поверх робити розтягнуте сховище та RAIN-архітектуру. Такий сценарій цілком живий і підтримується нами, тому ми розповімо про нього в статті про типові сценарії застосування vAIR.
Схеми відмовостійкості сховища
Схем відмовостійкості віртуальних дисків в vAIR може бути дві:
1) Replication factor або просто реплікація – цей метод стійкості до відмов простий «як палиця і мотузка». Виконується синхронна реплікація між нодами з фактором 2 (2 копії на кластер) або 3 (3 копії відповідно). RF-2 дозволяє віртуальному диску витримати відмову однієї ноди в кластері, але «з'їдає» половину корисного об'єму, а RF-3 витримає відмову 2-х нід у кластері, але зарезервує вже 2/3 корисного об'єму під свої потреби. Ця схема дуже нагадує RAID-1, тобто віртуальний диск, налаштований в RF-2, стійкий до відмови будь-якої однієї ноди кластера. В цьому випадку з даними буде все гаразд і навіть введення-виведення не зупиниться. Коли нода повернеться до ладу, почнеться автоматичне відновлення/синхронізація даних.
Нижче наведено приклади розподілу даних RF-2 та RF-3 у штатному режимі та у ситуації відмов.
Маємо віртуальну машину об'ємом 8МБ унікальних (корисних) даних, яка працює на 4 нодах vAIR. Зрозуміло, що насправді навряд чи буде такий малий обсяг, але для схеми, що відображає логіку роботи ARDFS, цей приклад найбільш зрозумілий. AB – це віртуальні блоки по 4МБ, що містять унікальні дані віртуальної машини. При RF-2 створюються дві копії цих блоків A1+A2 та B1+B2 відповідно. Ці блоки «розкладаються» по нодах, уникаючи перетину тих самих даних на одній ноді, тобто копія А1 не буде на одній ноді з копією A2. З B1 та B2 аналогічно.
У разі відмови однієї з нід (наприклад, ноди №3, де міститься копія B1), ця копія автоматично активується на ноді, де немає копії її копії (тобто копії B2).
Таким чином, віртуальний диск (і ВМ відповідно) легко переживуть відмову однієї ноди в схемі RF-2.
Схема з реплікацією при своїй простоті та надійності хворіє на ту ж болячку, що і RAID1 – мало корисного простору.
2) Erasure coding або видаляє кодування (також відомо під іменами «надлишкове кодування», «прання кодування» або «код надмірності») якраз існує для вирішення проблеми вище. EC – схема надмірності, що забезпечує високу доступність даних при менших накладних витратах на дисковий простір порівняно з реплікацією. Принцип роботи цього механізму нагадує RAID 5, 6, 6P.
При кодуванні процес EC ділить віртуальний блок (за замовчуванням 4МБ) на кілька менших «шматків даних» залежно від схеми EC (наприклад, схема 2+1 ділить кожен блок 4 МБ на 2 шматки по 2МБ). Далі цей процес генерує для "шматків даних" "шматки парності" розміром не більше однієї з раніше розділених частин. При декодуванні EC генерує відсутні шматки, зчитуючи дані, що «вижили», по всьому кластеру.
Наприклад, віртуальний диск із EC-схемою 2 + 1, реалізований на 4-х нодах кластера, спокійно витримає відмову однієї ноди в кластері так само, як і RF-2. При цьому накладні витрати будуть нижчими, зокрема коефіцієнт корисної ємності при RF-2 дорівнює 2, а при EC 2+1 він буде 1,5.
Якщо описати простіше, то суть полягає в тому, що віртуальний блок поділяється на 2-8 (чому від 2-х д 8-ми див. нижче) "шматків", а для цих шматків обчислюються "шматки" парності аналогічного обсягу.
Через війну дані і парність поступово розподіляються за всіма нодам кластера. При цьому, як і при реплікації, ARDFS в автоматичному режимі розподіляє дані по нодах таким чином, щоб не допустити зберігання однакових даних (копій даних та їх парності) на одній ноді, щоб виключити шанс втратити дані через те, що дані та їх парність раптово виявляться на одній ноді зберігання, що вийде з ладу.
Нижче приклад, з тією ж віртуалкою в 8 МБ і 4-ма нодами, але вже за схемою EC 2+1.
Блоки A і B поділяються на два шматки кожен по 2 МБ (на два тому що 2+1), тобто на A1+A2 та B1+B2. На відміну від репліки, A1 не є копією A2, це віртуальний блок A, розділений на дві частини, так само і з блоком B. Разом отримуємо два набори по 4МБ, у кожному з яких лежить по два двомегабайтні шматки. Далі, для кожного з цих наборів обчислюється парність обсягом не більше одного шматка (тобто 2-х МБ), отримуємо додатково + 2 шматки парності (AP та BP). Разом маємо 4×2 даних + 2×2 парність.
Далі шматки "розкладаються" по нодах так, щоб дані не перетиналися з їх парністю. Тобто. A1 та A2 не лежатимуть на одній ноді з AP.
У разі відмови однієї ноди (припустимо, теж третьої) блок B1, що впав, буде автоматично відновлений з парності BP, яка зберігається на ноді №2, і буде активований на ноді, де немає B-парності, тобто. шматка BP. У цьому прикладі – це нода №1
Впевнений, у читача виникає запитання:
"Все що ви описали, давно реалізовано і конкурентами, і в open source-рішеннях, в чому відмінність вашої реалізації EC в ARDFS?"
А далі підуть цікаві особливості роботи ARDFS.
Erasure coding з упором на гнучкість
Спочатку ми передбачили досить гнучку схему EC X+Y, де X дорівнює числу від 2-х до 8-ми, а Y дорівнює числу від 1-го до 8-ми, але завжди менше або дорівнює X. Така схема передбачена для гнучкості. Збільшення кількості шматків даних (X), куди ділиться віртуальний блок, дозволяє знижувати накладні витрати, тобто збільшувати корисний простір.
Збільшення числа шматків парності (Y) збільшує надійність віртуального диска. Чим більше значення Y, тим більше нід у кластері може вийти з ладу. Зрозуміло, збільшення обсягу парності знижує обсяг корисної ємності, але це плата за надійність.
Залежність продуктивності від схем EC майже пряма: чим більше «шматків», тим нижча продуктивність, тут, ясна річ, потрібен збалансований погляд.
Такий підхід дозволяє адміністраторам максимально гнучко конфігурувати розтягнуте сховище. В рамках пулу ARDFS можна використовувати будь-які схеми відмови та їх комбінації, що теж, на наш погляд, дуже корисно.
Нижче наведено таблицю порівняння кількох (не всіх можливих) схем RF та EC.
З таблиці видно, що навіть «махрова» комбінація EC 8+7, що допускає втрату одночасно до 7-ми нід в кластері, «з'їдає» менше корисного простору (1,875 проти 2), ніж стандартна реплікація, а захищає в 7 разів краще, що робить цей механізм захисту хоч і складнішим, але значно привабливішим у ситуаціях, коли необхідно забезпечити максимальну надійність за умов браку дискового простору. При цьому потрібно розуміти, що кожен плюс до X або Y буде додатковою накладною витратою на продуктивність, тому в трикутнику між надійністю, економією і продуктивністю потрібно вибирати дуже уважно. З цієї причини окрему статтю ми присвятимо сайзингу кодування, що видаляє.
Надійність та автономність файлової системи
ARDFS локально запускається всіх нодах кластера і синхронізує їх власними засобами через виділені Ethernet-интерфейсы. Важливим моментом і те, що ARDFS самостійно синхронізує як дані, а й метадані, які стосуються зберігання. У ході роботи над ARDFS ми паралельно вивчали ряд існуючих рішень і ми виявили, що багато хто робить синхронізацію мети файлової системи за допомогою зовнішньої розподіленої СУБД, яку ми теж використовуємо для синхронізації, але тільки конфігурацій, а не метаданих ФС (про це та інші суміжні підсистеми у наступній статті).
Синхронізація метаданих ФС за допомогою зовнішньої СУБД рішення, звичайно, робоче, але тоді б консистентність даних, що зберігаються на ARDFS, залежала б від зовнішньої СУБД та її поведінки (а вона, прямо скажемо - дама примхлива), що на наш погляд погано. Чому? Якщо метадані ФС пошкодяться, самим даними ФС теж можна буде сказати «до побачення», тому ми вирішили піти складнішим, але надійним шляхом.
Підсистему синхронізації метаданих для ARDFS ми зробили самостійно і живе вона абсолютно незалежно від суміжних підсистем. Тобто. жодна інша підсистема не може пошкодити дані ARDFS. На наш погляд, це найбільш надійний і правильний шлях, а чи так це насправді покаже час. Крім того, з таким підходом з'являється додаткова перевага. ARDFS можна використовувати незалежно від vAIR, просто як розтягнуту сховище, чим ми неодмінно користуватимемося у майбутніх продуктах.
У результаті, розробивши ARDFS, ми отримали гнучку і надійну файлову систему, що дає вибір, де можна заощадити на ємності або віддати все на продуктивності, або зробити сховище наднадійним за помірну плату, але знизивши вимоги до продуктивності.
Разом з простою політикою ліцензування і гнучкою моделлю поставки (забігаючи вперед, ліцензується vAIR по нодах, а поставляється або софтом, або як ПАК) це дозволяє дуже точно заточити рішення під різні вимоги замовників і надалі легко підтримувати цей баланс.
Кому це диво потрібне?
З одного боку, можна сказати, що на ринку вже є гравці, які мають серйозні рішення в галузі гіперконвергента, і куди ми, власне, ліземо. Здається, що це твердження вірне, АЛЕ…
З іншого боку, виходячи «у поля» та спілкуючись із замовниками, ми й наші партнери бачимо, що це зовсім не так. Завданням для гіперконвергента багато, десь люди просто не знали, що такі рішення є, десь це здавалося дорого, десь були невдалі тести альтернативних рішень, а десь взагалі купувати забороняють, бо санкції. У загальному полі виявилося неораним, тому ми пішли піднімати цілину))).
Коли СГД краще ніж кортикостероїд?
Під час роботи з ринком нас часто запитують, коли краще застосовувати класичну схему з СГД, а коли – гіперконвергент? Багато компаній — виробники кортикостероїдів (особливо ті, у яких в портфелі немає СГД) кажуть: «СХД відживає своє, гіперконвергент only!». Це смілива заява, але вона не зовсім відбиває дійсність.
Правду кажучи, ринок СГД справді перепливає у бік гіперконвергента та подібних рішень, але завжди є «але».
По-перше, побудовані ЦОД-и та ІТ-інфраструктури за класичною схемою із СГД ось так просто не перебудуєш, тому модернізація та добудова таких інфраструктур – це ще спадщина років на 5-7.
По-друге, ті інфраструктури, які будуються зараз у масі своїй (мається на увазі РФ) будують за класичною схемою із застосуванням СГД і не тому, що не знають люди про гіперконвергента, а тому, що ринок гіперконвергента новий, рішення та стандарти ще не встоялися , ІТ-шники ще не навчені, досвіду мало, а будувати ЦОД треба тут і зараз. І ця тенденція ще на 3-5 років (а потім ще спадщина, див. пункт 1).
По-третє, чисто технічне обмеження у додаткових невеликих затримках у 2 мілісекунди на запис (без урахування локального кешу, звичайно), які є платою за розподілене зберігання.
Ну і не забуватимемо про використання великих фізичних серверів, які люблять вертикальне масштабування дискової підсистеми.
Є багато потрібних і популярних завдань, де СГД поводиться краще, ніж кортикостероїдів. Тут з нами звичайно ж не погодяться ті виробники, які в продуктовому портфелі не мають СГД, але ми готові аргументовано сперечатися. Звісно ж, ми як розробники обох продуктів в одній з майбутніх публікацій обов'язково проведемо порівняння СГД та ГКС, де наочно продемонструємо, що в яких умовах краще.
А де гіперконвергентні рішення працюватимуть краще за СГД?
Виходячи з тез вище, можна зробити три очевидні висновки:
- Там, де додаткові 2 мілісекунди затримки на запис, які стійко виникають у будь-якій продуктивності (зараз не йдеться про синтетику, на синтетиці можна і наносекунди показати), є некритичними, гіперконвергент підійде.
- Там, де навантаження з великих фізичних серверів можна перетворити на багато маленьких віртуальних і розподілити по нодах, там гіперконвергент зайде добре.
- Там, де горизонтальне масштабування пріоритетніше, ніж вертикальне, там теж кортикостероїди зайдуть чудово.
Які це рішення?
- Усі стандартні інфраструктурні сервіси (служба каталогів, пошта, СЕД, файлові сервери, невеликі або середні ERP та BI системи тощо). Ми це називаємо "загальні обчислення".
- Інфраструктура хмарних провайдерів, де необхідно швидко та стандартизовано горизонтально розширюватись та легко «нарізати» велику кількість віртуальних машин для клієнтів.
- Інфраструктура віртуальних робочих столів (VDI), де багато маленьких віртуалок користувача запускаються і спокійно «плавають» усередині однакового кластера.
- Філіальні мережі, де в кожній філії потрібно отримати стандартну, стійку до відмови, але при цьому недорогу інфраструктуру з 15-20 віртуальних машин.
- Будь-які розподілені обчислення (big data-сервіси, наприклад). Там, де навантаження йде не «вглиб», а «вшир».
- Тестові середовища, де допустимі додаткові невеликі затримки, але бюджетні обмеження, бо це тести.
На даний момент саме для цих завдань ми зробили AERODISK vAIR і саме на них наголошуємо (поки успішно). Можливо, невдовзі це зміниться, т.к. світ не стоїть дома.
Отже ...
На цьому перша частина великого циклу статей завершена, в наступній статті ми розповімо про архітектуру рішення та компоненти, що використовуються.
Будемо раді питанням, пропозиціям та конструктивним суперечкам.
Джерело: habr.com