8 міфів про дедуплікаціі

Настав час розглянути всі міфи і дізнатися де правда в питаннях дедуплікаціі для масивів даних.



Незважаючи на те, що технологія дедуплікаціі відома вже досить давно, але тільки зараз технології, що застосовуються в сучасних масивах даних, дозволили їй пережити друге народження. У всіх сучасних масивах даних на поточний момент використовується дедупликация, але наявність цієї функції в масиві ще не означає, що це дасть вагомі переваги саме під ваші дані.
На жаль, велика кількість адміністраторів приймають «на віру» і вважають, що дедупликация володіє безмежними можливостями.

Не важливо, чи є ви адміністратором системи зберігання рівня tier-1, архівного сховища або all-flash гібридних систем зберігання, вам буде цікаво пройтися по міфам і легендам дедуплікаціі, щоб уникнути прикрих помилок при проектуванні або роботі з вашими системами зберігання.

Коефіцієнт скорочення даних: чудес не буває
У той час як дедупликация стала доступна як для масивів, що зберігають ваші продуктивні дані, так і для масивів, що зберігають резервні копії даних, коефіцієнт дедуплікаціі на цих масивах може бути абсолютно різним. Архітектори дуже часто вважають, що коефіцієнт, досягнутий на архівному масиві, можна застосувати і до продуктивного сховища.
Дедупликация — це автоматичний процес, існуючий на багатьох масивах відомих виробників, але потенційний коефіцієнт, який ви можете отримати, відрізняється у масивів різного типу. В результаті, наприклад, якщо вам буде потрібен масив на 100ТБ, а ви будете вважати коефіцієнт 10:1, то і придбаєте сховище під 10ТБ, або, скажімо, якщо ви будете оцінювати коефіцієнт як 2:1, отже, придбаєте сховище на 50ТБ – у підсумку, ці зовсім різні підходи, призводять до абсолютно різної вартості покупки! Ви повинні на практиці зрозуміти який коефіцієнт ви можете отримати на ваших продуктивних даних, перш ніж зробити вибір на користь певної моделі з певним обсягом.

Ладу конфігурації масивів даних під різні завдання оперативного зберігання і резервного зберігання, часто доводиться стикатися з труднощами в правильному визначенні коефіцієнта дедуплікаціі. Якщо вам цікаві тонкощі архітектурного дизайну масивів під дедупликацию, ця дискусія для вас.

Як мінімум, розуміння на базовому рівні 8 міфів, наведених далі, дозволить вам усвідомлено зрозуміти дедупликацию і оцінити її коефіцієнт для ваших даних.

Миф1. Більший коефіцієнт дедуплікаціі дає більше переваг для зберігання даних
Чи вірно твердження, що якщо один виробник пропонує коефіцієнт дедуплікаціі 50:1 це в п'ять разів краще альтернативного пропозиції 10:1? Потрібно перевіряти і порівнювати сукупну вартість влдения! Дедупликация дозволяє скоротити вимоги до ресурсів, але яка потенційна економія обсягу? 10:1 дозволяє зменшити розмір збережених даних (reduction ratio) на 90%, у той час як коефіцієнт 50:1 збільшує цей показник на 8% і дає 98% reduction ratio (див. графік нижче). Але це тільки 8% різниці…
У цілому, чим вище коефіцієнт дедуплікаціі, тим менше переваг зменшення обсягу даних, відповідно до закону спадної дохідності (https://en.wikipedia.org/wiki/Diminishing_returns).
Пояснення сенсу закону спадної дохідності може бути таким: додатково застосовуються витрати одного фактора (наприклад, коефіцієнта дедуплікаціі) поєднуються з незмінною кількістю іншого чинника (наприклад, обсягу даних). Отже, нові додаткові витрати на поточному обсязі дають меншу економію ресурсів.
Приміром, у вас є офіс, в якому працюють клерки. З часом, якщо збільшувати кількість клерків, не збільшуючи розмір приміщення, вони будуть мішатися під ногами один у одного і можливо витрати будуть перевищувати доходи.


Рис. 1 Зростання коефіцієнта дедуплікаціі і скорочення обсягів зберігання

Миф2. Є чітке визначення терміну «дедупликация»
Дедупликация дозволяє скоротити обсяг збережених даних, видаляючи повторювані послідовності даних з пулу. Дедупликация може бути на файловому рівні, блочному рівні або на рівні додатка або контенту. Більша частина продуктів поєднують дедупликацию з компресією, щоб ще сильніше скоротити обсяг збережених даних. В той час, як деякі виробники не поділяють ці терміни, деякі поділяють їх і вводять такі терміни, як «ущільнення» (compaction), що, по суті, є просто іншою назвою «дедуплікаціі плюс стиснення». На жаль, не існує єдиного визначення дедуплікаціі. В обивательському рівні вам буде важливо, як ви зможете заощадити на дискових ресурси вашої системи зберігання і резервного копіювання, застосовуючи дедупликацию. Нижче ми розкриємо цю тему.

Говорячи про лінійку систем зберігання і резервного копіювання HPE важливо відзначити, що і системи зберігання, та системи резервного копіювання володіють цікавим функціоналом, що дозволяє замовникам економити на дискових ресурсах.
Для систем зберігання оперативних даних в масиві 3PAR розроблено цілий комплекс утиліт і механізмів, що дозволяє скоротити обсяг даних на продуктивному масиві.
Цей комплекс має назву HPE 3PAR Thin Technologies і складається з декількох механізмів:
  • Thin Provisioning – найбільш ефективно реалізована в системах зберігання 3PAR, т. к. застосовується віртуалізація дискового простору і масив використовують свою внутрішню карту збережених блоків, при высвоюождении ресурсів масиву не потрібно проводити ревізію (garbage collection), вивільнені блоки відразу готові до подальшого використання… Дозволяє виділяти логічного того рівно стільки обсягу, скільки він вимагає, але на масиві зайняти всього лише стільки, скільки на цей том фізично записано.
  • Thin Conversion — технологія, що дозволяє переводити в реальному часі тома зі старих масивів даних HPE (3PAR, EVA), EMC, Hitachi та інших виробників у «тонкі томи» (які використовують Thin Provisioning) на масиві 3PAR з скороченням обсягу томи на цільовому пристрої.
  • Thin Persistence і Thin Copy Reclamation — технологія, що дозволяє масиву 3PAR на дуже низькому гранулярном рівні розуміти роботу всіх популярних файлових систем і гіпервізора і у випадку видалення файлів (звільнення фізичного обсягу) переводити відповідні блоки в пул вільних ресурсів.
  • Thin Deduplication — технологія дозволяє використовувати дедупликацию на продуктивному масиві в реальному часі, без істотної осідання продуктивності.
Всі три технології доступні безкоштовно і без обмежень за часом або обсягом для будь-якої системи зберігання 3PAR, в тому числі, встановлених у наших замовників, докладніше про цих технологіях: www.hpe.com/h20195/v2/GetPDF.aspx/4AA3-8987ENW.pdf


Рис. 2 Технології Thin в масивах 3PAR

Миф3. Коефіцієнти дедуплікаціі на основному масиві такі ж, як і на масиві з резервними копіями.
Розробники систем зберігання даних використовують різні алгоритми дедуплікаціі. Деякі з них вимагають великих ресурсів CPU і складніше, ніж інші, отже, не повинен дивувати той факт, що коефіцієнт дедуплікаціі варіюється досить сильно.
Однак, найбільший чинник, що впливає на те, який коефіцієнт дедуплікаціі ви отримаєте — як багато у вас повторюваних даних. З цієї причини системи резервного копіювання, що містять кілька копій одних і тих же даних (денні, тижневі, місячні, квартальні, річні) мають такий високий коефіцієнт дедуплікаціі. У той час як оперативні системи зберігання мають практично унікальний набір даних, що практично завжди дає невисокий коефіцієнт дедуплікаціі. У разі, якщо ви зберігаєте кілька копій оперативних даних на продуктивному масиві (наприклад, у вигляді клонів) — це збільшує коефіцієнт дедуплікаціі, т. к. застосовуються механізми скорочення місця зберігання.
Тому для оперативних масивів зберігання даних мати коефіцієнт 5:1 також чудово, як мати коефіцієнт 30:1 або 40:1 для систем резервного копіювання, оскільки цей коефіцієнт залежить від того, скільки копій продуктивних даних зберігається на таких масивах.
Якщо розглядати продукти компанії HPE, то в масивах для оперативного зберігання HPE 3PAR пошук повторюваних послідовностей (наприклад, при ініціалізації віртуальних машин або створення снэпшотов) проходить «на льоту» на спеціальній мікросхемі ASIC, встановленої в кожному контролері масиву. Цей підхід дозволяє розвантажити центральні процесори масиву для інших, більш важливих, завдань і дає можливість включити дедупликацию для всіх типів даних, не боячись, що масив «просяде» під навантаженням. Детальніше про дедупликацию на масиві 3PAR можна прочитати: www.hpe.com/h20195/v2/getpdf.aspx/4AA4-9573ENW.pdf


Рис.3 Дедупликация в масивах 3PAR виконується на окремій мікросхемі ASIC

У портфелі HPE також є апаратні комплекси для резервного копіювання даних з онлайн дедупликацией на рівні блоків змінної довжини — HPE StoreOnce. Варіанти систем охоплюють повний спектр замовників від початкового до корпоративного рівня:


Рис. 4 Портфель систем резервного копіювання HPE StoreOnce

Про переваги систем резервного копіювання StoreOnce можна почитати в інших статтях.
Для замовників може бути цікаво, що зв'язка HPE 3PAR і StoreOnce дозволяє спростити і прискорити процес переносу даних з продуктивного масиву на систему резервного копіювання без використання резервного копіювання або виділеного сервера бекапа. Така зв'язка отримала назву HPE StoreOnce RMC детальніше про неї можна почитати в нашої статті.

Миф4. Всі дані однакові
Тут не повинно бути ніяких сумнівів — усі дані різні. Навіть дані одного і того ж додатка в різних умовах будуть мати різні коефіцієнти дедуплікаціі на одному і тому ж масиві. Коефіцієнт дедуплікаціі для конкретних даних залежить від різних факторів:
  • Тип даних — дані, що пройшли програмне стиснення, метадані, медіа-потоки і зашифровані дані завжди мають дуже невисокий коефіцієнт дедуплікаціі або не стискаються зовсім.
  • Ступінь змінності даних — чим вище обсяг денних змін даних на блочному або файловому рівні, тим нижче коефіцієнт дедуплікаціі. Це особливо актуально для систем резервного копіювання.
  • Термін зберігання — чим більше копій даних, ви маєте, тим вище коефіцієнт дедуплікаціі.
  • Політика резервного копіювання — політика створення денних повних копій, в противагу політиці з інкрементний або диференціальних бэкапами, дасть більший коефіцієнт дедуплікаціі (див. дослідження нижче).


Таблиця нижче дає поверхневу оцінку коефіцієнта дедуплікаціі, в залежності від типу даних. Необхідно пам'ятати, що коефіцієнт дедуплікаціі на основному масиві даних буде завжди нижче коефіцієнта дедуплікаціі на резервному масиві.


Рис. 5 Оцінка коефіцієнта дедуплікаціі в залежності від типів даних і політики резервного копіювання

Миф5. Групування незв'язних типів даних підвищує рівень дедуплікаціі
В теорії, ви можете змішувати різні типи даних в загальному пулі зберігання для дедуплікаціі є відчуття, що ви маєте дуже великий набір унікальних даних і, отже, ймовірність знаходження в цьому пулі записаних раніше блоків або об'єктів буде велика. На практиці ж цей підхід не працює між непов'язаними типами даних, наприклад, між БД і Exchange, оскільки різні формати даних, навіть якщо зберігається один і той же набір даних. Такий, весь час зростаючий пул, стає більш складним і вимагає більше часу для пошуку повторюваних послідовностей. Кращою практикою є поділ пулів по типу даних.

Наприклад, якщо виконати дедупликацию однієї віртуальної машини, ви отримаєте деякий коефіцієнт, якщо створити кілька копій цієї віртуальної машини і виконати дедупликацию на цьому пулі, ваш коефіцієнт дедуплікаціі зросте, а якщо згрупувати кілька віртуальних машин за типом програми і створити кілька копій цих віртуальних машин — коефіцієнт збільшиться ще більше.


Рис.6 Залежність коефіцієнта дедуплікаціі від кількості віртуальних машин в пулі і розмірів блоку даних.

Миф6. Ваше перше резервне копіювання покаже вам очікуваний коефіцієнт дедуплікаціі.
Це помилкова думка з'являється при порівнянні коефіцієнтів на основному масиві та системи резервного копіювання. Якщо ви зберігаєте тільки одну копію даних – можливо, ви побачите деякий коефіцієнт дедуплікаціі, більший одиниці. Цей коефіцієнт зможе зрости в тому випадку, якщо ви збільшите кількість копій дуже схожих даних, таких як резервні копії поточної БД.
Графік нижче показує дуже типову криву коефіцієнта дедуплікаціі. Додаток, в цьому графіку — БД SAP HANA, але більшість додатків показує схожу криву. Ваше перше резервне копіювання показує певну дедупликацию, але більша економія досягається завдяки стисненню даних. Як тільки ви починаєте тримати в пулі більше копій даних — коефіцієнт дедуплікаціі пулу починає зростати (блакитна лінія). Коефіцієнт індивідуального бекапа злітає вгору вже після створення другої копії (орнжевая лінія), т. к. на блочному рівні перший і другий бекап дуже схожі.


Рис. 7 Графік зростання коефіцієнта дедуплікаціі при збільшенні кількості резервних копій (детальніше на сторінці www.hpe.com/h20195/v2/GetPDF.aspx/4AA6-4641ENW.pdf).

Миф7. Ви не можете збільшити рівень дедуплікаціі
Наївно вважають, що немає можливості штучно збільшити рівень дедуплікаціі. Інше питання — навіщо? Якщо показати маркетингові цифри — це одне, якщо необхідно створити ефективну схему резервного копіювання — це інше. Якщо мета — мати синтетичний найвищий коефіцієнт дедуплікаціі, то необхідно просто зберігати більше як можна більше копій одних і тих же даних. Звичайно, це збільшить обсяг збережених даних, але ваш коефіцієнт дедуплікаціі взмоет до небес.
Зміна політики резервного копіювання, виразно також впливає на коефіцієнт дедуплікаціі, як можна побачити в прикладі нижче для реального типу даних, де порівнюються політики створення повних копій і комбінації повних копій з інкрементальнимі і дифферентальными бэкапами. У прикладі нижче кращий коефіцієнт виходить при використанні тільки денних повних резервних копій. Тим не менш, на одних і тих же даних обсяг зберігання є досить різним для всіх трьох підходів. Тому необхідно розуміти, що зміна у вашому підході до резервного копіювання може досить сильно вплинути на коефіцієнт дедуплікаціі і на фізичний обсяг збережених даних.

Миф8. Немає можливості заздалегідь спрогнозувати коефіцієнт дедуплікаціі
Всяка навколишнє середовище унікальна і дуже складно акуратно спрогнозувати реальний коефіцієнт дедуплікаціі. Але тим не менш, виробники систем резервного копіювання випускають набори невеликих утиліт для основних систем зберігання і систем резервного копіювання, що дозволяють отримати уявлення про тип даних, політики резервного копіювання, термін зберігання. Ці утиліти дозволяють в якійсь мірі отримати уявлення про очікуваний коефіцієнт дедуплікаціі.
Також виробники мають уявлення про коефіцієнти, одержуваних у інших замовників на приблизно схожою середовищі і галузевому сегменті і можуть використовувати цю інформацію для побудови прогнозу. В той час як це не дає гарантії, що на ваших даних ви отримаєте схожий коефіцієнт, до цих цифр, як мінімум, варто придивитися.
Але найбільш точний прогноз по коефіцієнту дедуплікаціі виходить в ході проведення випробувань на реальних даних.


Рис. 8 Зміна коефіцієнта дедуплікаціі і обсягу займаних даних залежно від політики резервного копіювання даних конкретного замовника

У компанії HPE є набір утиліт і сайзеров, що дозволяє спрогнозувати (з певним допущенням) той обсяг систем зберігання, який необхідний замовникам.
  1. Для оперативного сховища даних є безкоштовна програма оцінки поточної утилізації масиву та оцінки економії місця, у разі переходу на 3PAR: www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA3-4015ENW
  2. Для оцінки утилізації ресурсів на оперативному масиві і побудови прогнозу по зростанню обсягу даних на вже встановлених системах, за умови дозволу відправки масивом інформації про його стан в службу технічної підтримки HPE: www.storefrontremote.com
  3. Аналогічна програма по оцінці утилізації систем резервного копіювання: www.hpe.com/h20195/V2/GetDocument.aspx?docname=4AA4-0953ENW&cc=us&lc=en
Також є можливість оцінити передбачуваний обсяг, який ми отримаємо після включення на системі 3PAR дедуплікаціі в режимі симулятора, для цього необхідно на 3PAR запустити команду оцінки, виконувану в онлайн режимі, прозоро для хоста:

checkvv -dedup_dryrun {Імена віртуальних томів}


І отримати попередню оцінку:


Отже, немає ніякої магії за поняттям дедуплікаціі, а розвінчання міфів, наведене вище, дозволить вам краще зрозуміти, на що здатні ваші дані і дозволить вам спрогнозувати утилізацію ваших масивів.
Слід зазначити, що сучасний зростання обсягів SSD і зниження вартості зберігання на 1ГБ на флеш накопичувачах (а вартість вже відповідає $за 1.5 ГБ відсувають питання, пов'язані з ефективністю дедуплікаціі на другий план для оперативного сховища, але стають все більш актуальними для систем резервного копіювання.

До речі, є альтернативне бачення майбутнього (без дедуплікаціі):
Викибон вважає, що усунення копій одних і тих же даних ефективніше, ніж зростання коэффициенотв дедуплікаціі і компресії (див. по посиланню в середині звіту — wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures)але такий підхід вимагає кардинального впровадження цілого комплексу технічних заходів, зміни всієї інфраструктури, правил одночасної роботи додатків (процесинг, аналітика) з даними так, щоб вони не знижували продуктивність (при впровадженні хороших засобів роботи з SLA) і надійність.
І, найголовніше, якщо це все впровадити у всій екосистемі — і розробникам, і вендорам, і CIO, то через кілька років економія від цього буде більше, ніж від дедуплікаціі.

Яка школа думки переможе – покаже час.

Використані матеріали community.hpe.com/t5/Around-the-Storage-Block/Myth-Busting-8-Common-Data-Deduplication-Misconceptions/ba-p/6901652?dysig_tid=1360ea31461c41288850c325abab37cf#.V-zGavl974Y
Джерело: Хабрахабр

0 коментарів

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