Домен даних - Поширені запитання про стиснення

ВІДНОСИТЬСЯ ДО

• Всі DDR
• Всі релізи

Стискання: Часто задавані питання:

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

• Метадані займають близько 0,5% від логічного розміру резервної копії. Припустимо, логічний розмір повного становить 100 ГБ, а додаткового – 2 ГБ. Припустимо, що крок стиснення становить 1 ГБ. Тоді на повний піде не менше 1,5 Гб.
• Механізм стиснення DD перепише деякі повторювані сегменти даних для продуктивності. Чим бідніша локальність даних змін, тим більше записуються дублікати. Пізніше дублікати виправляються за допомогою «очищення файлів». Я бачив, як близько 2% логічного розміру було переписано як дублікат. Припускаючи такий рівень дублікатів, повний може зайняти 1 ГБ (стиснений) + 0,5 ГБ (метадані) + 2 ГБ (дублікати) = 3,5 ГБ. Кількість записаних дублікатів можна контролювати через системний параметр, але ми зазвичай не налаштовуємо цей параметр в польових умовах.
• Сегментація даних може дещо відрізнятися від резервної копії до резервної копії залежно від порядку, в якому клієнт NFS надсилає дані. Цей порядок не є детермінованим. В цілому алгоритм сегментації терпить зрушення і переупорядкування. Однак це також створює деякі «форсовані» сегменти, які схильні до зсувів і переупорядкування. Як правило, близько 0,2% сегментів є форсованими, тому можна очікувати, що використовується набагато більше місця.

"Fileys show space" забезпечує коефіцієнт стиснення на основі логічного розміру даних, що зберігаються, і дискового простору, використаного під час виконання команди.

«Файли показують стиснення» надає коефіцієнт стиснення на основі того, як кожен файл було стиснуто під час його створення.

"filesys show compression" використовується в основному для підтримки та налагодження. При наявності видалення файлів, "fileys show compression" завищує ступінь стиснення.

Наприклад, припущення полягає в тому, що перша повна резервна копія отримує 2-кратне стиснення. Подальша повна резервна копія без будь-яких змін даних отримує 200-кратне стиснення. Перша повна резервна копія видаляється. "fileys show space" покаже коефіцієнт стиснення 2x. "Fileys show compression" тепер показуватиме коефіцієнт стиснення 200x, оскільки єдиний існуючий файл тепер отримав стиснення у 200x під час його створення.

У наведеному вище прикладі, після другого резервного копіювання, "fileys show space" покаже кумулятивний коефіцієнт приблизно 4x. Кумулятивний коефіцієнт асимптотично покращиться до 200x, якщо продовжувати робити більше резервних копій без видалення.

Є й інші незначні відмінності:

•  "Fileys show compression" не враховує втрати на рівні контейнера, таким чином ще більше переоцінюючи коефіцієнт стиснення
•  "Fileys show compression" не враховує видалення дублікатів шляхом глобального стиснення, тим самим недооцінюючи коефіцієнт стиснення
•  "Fileys show compression" може надавати інформацію для кожного файлу або каталогу, тоді як "fileys show space" обмежений усією системою
•  "fileys show compression" забезпечує розбивку між глобальним та локальним стисненням, тоді як "fileys show space" не забезпечує

ПОСИЛАННЯ

• Чому коефіцієнти стиснення відрізняються для "fileys show space" та "vtl tape show summary"?

Коефіцієнт стиснення, показаний у "vtl tape show summary", має відповідати "fileys show compression /backup/vtc".

У більш загальному стилі, цій команді VTL може бути надано необов'язковий фільтр для вибору підмножини стрічкових картриджів, і компресія повинна відповідати "fileys show compression" на цій підмножині картриджів.

Однак через помилку в коді інтерфейсу користувача VTL стиснення, показане в "vtl tape show summary", є помилковим. Це відома проблема, яку вирішено у випуску 4.5.0.0.
 

• Чому "fileys показує стиснення триває 24 години" не збігається з очікуваннями для VTL?

Для VTL виведення команд на кшталт "fileys show compression last 24 hours" часто не відповідає очікуванням, заснованим на інших джерелах, таких як "system show performance".

Проблема виникає через особливість у "файлис показати стиснення" (fsc). Загалом, "fileys show compression" показує кумулятивну статистику у вибраних файлах. Класифікатор "останні 24 години" вибирає файли, які були оновлені протягом останніх 24 годин. Статистика все ще накопичується з моменту створення файлу або останнього обрізання до нульового розміру. Таким чином, якщо файл було додано протягом останніх 24 годин, "filesys show compression last 24 hours" покаже його сукупну статистику до останніх 24 годин.

У середовищах, відмінних від VTL, файли резервних копій записуються лише один раз, тому немає великої розбіжності між оновленими файлами та створеними файлами. За допомогою VTL резервні копії можуть бути додані до існуючих стрічкових файлів. Наприклад, розглянемо стрічку ємністю 100 Гб, яка заповнюється до 50 Гб. Якщо до цієї стрічки додано 10 ГБ даних за останні 24 години, «fileys show compression last 24 hours» покаже «Оригінальні байти» файлу розміром 60 ГБ.
 

• Як розраховується кумулятивний ступінь стиснення?

Окремі ступені стиснення не складаються лінійно.

Припустимо, що стиснення на першій повній резервній копії становить 2x, а на другій повній резервній копії – 20x. Кумулятивне стиснення не становить (2+20)/2 або 11x, а 2/(1/2+1/20) або 3,64x.

Загалом, нижчі ступені стиснення мають більший вплив, ніж вищі, на кумулятивний ступінь стиснення.

Припустимо, що i-а резервна копія має логічний розмір si і ступінь стиснення ci. Тоді кумулятивний коефіцієнт стиснення для k резервних копій можна обчислити таким чином:

C = (загальний логічний розмір)/(загальний використаний простір)
загальний логічний розмір = s1 + s2 + .. + СК
Загальний використаний простір = S1/C1 + S2/C2 + ... + СК/СК

Часто логічні розміри приблизно однакові. У такому випадку наведений вище розрахунок спрощується до наступного:

Наприклад, якщо перша повна резервна копія стиснена в 3 рази, а кожна наступна повна — у 30 разів, а період зберігання становить 30 днів, то користувач бачить сукупне стиснення 30/(1/3+29/30) або 23x.
 

• Як працює стиснення домену даних?

На це питання докладно дається детальна відповідь в окремій статті КБ "Розуміння стиснення домену даних" Data Domain: Розуміння стиснення домену даних
 

• Чи підтримує домен даних мультиплексування? ​​​​​​​

Мультиплексування даних із програми резервного копіювання призведе до дуже поганої глобальної дедуплікації. Для отримання додаткової інформації перегляньте відповідну статтю Мультиплексування в програмному забезпеченні для резервного копіювання не підтримується доменом даних: Мультиплексування в програмному забезпеченні резервного копіювання. 
 

• Чому при реплікації каталогів 1-to-1 репліка показує краще глобальне стиснення?​​​​​​​

Зазвичай це пов'язано з варіаціями рівня дублювання сегментів, записаних в системі:

• Дані, що зберігаються в джерелі, були дедупліковані один раз - проти попередніх даних, що зберігаються в джерелі.
• Дані, надіслані по дроту, були дедупліковані один раз - проти даних, що зберігаються в репліці.
• Дані, що зберігаються в репліці, були дедупліковані двічі, один раз, коли дані були відправлені по дроту, і повторно, коли отримані дані записані на репліці.

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

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

• Яка зміна стиснення при використанні налаштувань локального стиснення lz, gzfast і gz?

Параметр fileys встановити стиснення {none | lz | gzfast | gz}
 

Попередження: Перш ніж змінити тип локального стиснення, файлову систему необхідно вимкнути. Після цього його можна перезапустити відразу після встановлення параметра стиснення.

В цілому порядок стиснення виглядає наступним чином:

Приблизна різниця полягає в наступному:

• Від lz до gzfast дає ~15% краще стиснення і споживає 2x процесор
• від lz до gz забезпечує на ~30% краще стиснення та споживає 5x процесор
• gzfast до gz дає ~10-15% краще стиснення

Зауважте, що зміна локального стиснення спочатку впливає на нові дані, записані до DataDomain Restorer після внесення змін. Старі дані зберігають свій попередній формат стиснення до наступного циклу очищення. Наступний цикл очищення скопіює всі старі дані в новий формат стиснення. Це призводить до того, що очищення триває набагато довше і займає більше процесора.

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

Посилання на знання:

• Вирішення проблем з міграцією
• Домен даних: Розуміння стиснення домену даних