Erasure Code — більше простір зберігання на Nutanix



Ця запис у нас в блозі вже з'являлася пару місяців тому. На жаль нам строго погрозили з-за океану, щоб ми не рассказзывали про ще не зарелизенных фичах, тому текст довелося прибрати. І ось тепер, у NOS 4.1.3, Erasure Code доступний для використання public beta статус (експериментуйте, але поки стривайте з продакшном, ми ще оптимізуємо код), а значить вже можна розповідати публічно.

Якщо ви вже читали мій розповідь раніше про те, як влаштована NDFS, Nutanix Distributed File System, основа того, як воно все зроблено в Nutanix, то напевно відзначили, що витрата дискового простору в NDFS, він, загалом, досить «щедрий».

Нагадаю, що ми не використовуємо RAID, в його класичному розумінні, коли, наприклад, для диска тримається його дзеркальна копія (RAID-1), або коли для групи дисків розрахований додатковий код надмірності (RAID-5 або 6). Замість цього, ми зберігаємо блок записаних на дисках даних в двох (або навіть трьох) місцях на різних дисках, і навіть різних ноди. Ця схема називається у нас RAIN (Redundant Array of Independent Nodes, в піку RAID, який те ж саме, але ...Disks). Але, з точки зору ємності дисків системи, RF=2, то є варіант, коли для кожного блоку зберігається його копія, витрата місця еквівалентний RAID-1, тобто під дані нам доступні 50% raw-ємності (мінус ще якийсь, змінний, відсоток на службові структури та інформацію, але це опустимо тут).

Так, відмовостійкість, надійність, швидке (хвилини) відновлення при збоях, все це так. Але все одно витрата досить великий. Особливо для людей, які все ще звично мислячих про диски в величинах ємності raw або RAID-5. І можна скільки завгодно говорити, що RAID-5 — поганий і ненадійний, що він повільний на запис, що, нарешті, при нинішніх цінах на HDD, плата за підвищену надійність і продуктивність гігабайтами, отдаваемыми на відмовостійкість, невелика, в порівнянні з тим, що нам дається натомість за них. Все одно. «У нас стоїть в системі чотири терабайтних диска. Чому ж у нас залишається навіть менше двох терабайт під наші дані?»

Ось тому у Nutanix з'явилася ідея, яка зараз активно втілюється. Займається їй в Nutanix, до речі, «наш», російськомовний програміст.
Це те, що називається «erasure code» (ми назвали його EC-X, Erasure Code-X). Як це часто буває у інженерів, назва «несамоописывающее», і прижилося вже ніхто не знає чому. По-російськи це буде, правильніше — «код надмірності».
Ось як це працює.

Якщо у нас є дані, які нас жаба давить тримати на «RAID-1», тобто в режимі Replication Factor (RF) = 2, то ми можемо переключити для цих даних режим зберігання з RF=2(і =3) на erasure code. При цьому, у нас починає працювати спеціальний фоновий процес, схожий на те, як у нас здійснюється дедупликация в кластері, і, через якийсь час, замість блоку-та-копії у нас на дисках починає зберігатися на дисках кластера нодів блок-блок-блок-...-и_избыточная_информация_для_них, яка дозволяє однозначно відновити вміст блоку в цьому ланцюжку, якщо він буде загублений, наприклад, в результаті відмови диска однією з нсд.
І коли цей процес закінчує обробку в фоні, замість блоку та його копії в кластері, у нас починає зберігатися безліч блоків, об'єднаних в групу, плюс окремий блок і кодом надмірності. І в тому контейнері даних, де ми включили erasure code замість RF, ми одержуємо той же обсяг інформації, що зберігається, і при цьому більше вільного місця для нової.
Знову ж таки, це трохи схоже на postponed deduplication.

Напевно ви вже готові відразу сказати: «Ну, ви просто „винайшли“ велосипед RAID-5!», не зовсім так на математичному рівні, але віддалено схожий принцип, так.

«Розплата» тут (нічого без розплати не буває, як ми пам'ятаємо) полягає в тому, що за більше місця на дисках для даних ми платимо більш високою завантаженням CPU, в разі необхідності відновлення даних. Зрозуміло те, що, замість простого копіювання, тут нам доведеться відновлювати вміст блоку з вмісту інших блоків даних і надлишкового коду, і це істотно більш дешева процедура.

Важливо також те, що, з допомогою Erasure Code, надмірності достатньо, щоб відновитися при відмові двох дисків, нод, або інших компонентів кластера, тобто це, з точки зору рівня відмовостійкості, еквівалент RF=3, для якого на дисках обсяг usable дорівнює близько 33% від raw.
А в разі erasure code?
Це залежить від розмірів кластера. Чим він більший за кількістю нод — тим вигідніше, тим більше величина різниці.



Для 4-нодового кластера на 80TB raw виходить приблизно 40TB usable при RF=2. При перемиканні контейнера в erasure coding простір usable складе — 53TB.
На 5 ноди— 100 — 50 — 75 на 6 ноди— 120 — 60 — 96 на 7 — 140 — 70 — 116. Як бачите, зі збільшенням розмірів кластера, «ефективність зберігання» для erasure code також зростає і може досягти 80% від raw capacity.

Що за кодування використовується? Ні, це не Reed-Solomon Code, добре знайомий індустрії, і часто використовуваний для подібних завдань. У нас довелося придумати свій алгоритм, що забезпечує більш високу швидкість обробки і розрахунку. І зрозуміло, ми використовуємо розподілені можливості кластера Nutanix, алгоритм розподілений, подібно map-reduce, і виконується на всіх ноди кластера, що забезпечує надійність і продуктивність його роботи. Також важливо зазначити, що використання EC-X не порушує наш принцип Data Locality. Якщо віртуальна машина знаходиться на цьому хості віртуалізації (ноде кластера), то і її дані на SSD (performance tier нашого сховища) також будуть лежати локально для неї, на цій ноде, як при RF, так і при EC-X варіанті зберігання, що забезпечує низьку latency і високу дискову продуктивність.

Для чого і куди це можна застосувати?

Насамперед, це дозволяє знизити вартість зберігання ($/GB), що особливо актуально для «cold storage»і capacity nodes, особливо на великих кластерах, в тому випадку, якщо ви зберігаєте на Nutanix інформацію, нехай і цінний, але не дуже «гарячу», активну. І готові за більшу вільний простір заплатити підвищеної завантаження CPU і більш тривалим часом відновлення.
При цьому, зверніть увагу, в штатному режимі, при звичайній роботі з даними під erasure code, завантаження CPU при зверненні до даних суттєво не підвищується, тільки при відновленні.
Ви також вільні вибирати, як саме захищати надлишковістю ваші дані. Ви можете на одному кластері тримати різні контейнери для даних, одні — з RF=2, інші — RF=3, а якісь-з erasure code. Для даних, досить гарячих і критичних, ви можете обрати якийсь з RF, а для не таких «гарячих», і що лежить на ноди, де підвищена навантаження CPU при відновленні не критична для нас — Erasure Code.
Знову ж таки: вибір режиму для зберігання даних — за вами, та залежить від вашого вибору і від ваших пріоритетів.

Erasure Code з'явився в черговому релізі Nutanix OS, яка приїде на ваші системи Nutanix зі штатним оновленням. Оновлення Nutanix, до речі, не призводить до зупинки роботи віртуальних машин і недоступності даних, і система оновлюється Over-The-Air, «як айфон», але про це — в наступному пості.

Джерело: Хабрахабр

0 коментарів

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