Виправлення неполадок дедуплікації та ступеня стиснення файлів у реставраторах доменів даних (DDR)

Реставратори доменів даних (DDR) призначені для зберігання великих обсягів логічних (попередньо стиснених) даних, використовуючи мінімальний фізичний (постстиснений) дисковий простір. Це досягається за допомогою:

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

Загальний ступінь стиснення даних, які може отримати DDR, залежить від кількох факторів, таких як:

• Приклад використання
• Типи даних, що передаються всередину
• Конфігурація програми резервного копіювання

При оптимальному налаштуванні DDR зазвичай досягають 10-20-кратного загального ступеня стиснення (а іноді можуть показувати вищі коефіцієнти). І навпаки, в деяких середовищах загальний ступінь стиснення може бути нижчим за цей, що може спричинити:

• DDR швидко вичерпує свою корисну ємність
• Вплив на продуктивність резервного копіювання, відновлення або реплікації
• Нездатність DDR виправдати очікування клієнтів

У цій статті ми розглянемо:

• Короткий огляд дедуплікації та стиснення даних на DDR
• Як визначити загальний ступінь стиснення для системи та окремих файлів
• Фактори, які можуть спричинити погіршення загального ступеня стиснення

Як реставратор доменів даних отримує нові дані?

• Програма резервного копіювання надсилає дані (тобто файли) до DDR.
• DDR розбиває ці файли на фрагменти розміром від 4 до 12 Кбайт, кожен фрагмент розглядається як «сегмент».
• DDR генерує унікальний «відбиток» (схожий на контрольну суму) для кожного сегмента залежно від даних, що містяться в сегменті.
• Відбитки пальців новоприбулих сегментів звіряються з індексами дисків на DDR, щоб визначити, чи DDR уже містить сегмент із тим самим відбитком пальця.
• Якщо DDR вже містить сегмент з таким же відбитком, то відповідний сегмент у щойно отриманих даних є дублікатом і може бути відкинутий (тобто дедуплікований).
• Після вилучення всіх повторюваних сегментів із щойно отриманих даних залишаються лише унікальні або нові сегменти.
• Ці унікальні або нові сегменти групуються в «області стиснення» розміром 128 Кб, а потім стискаються (за замовчуванням використовується алгоритм lz ).
• Стиснені області стиснення упаковуються в 4,5 Мб пам'яті, відомої як «контейнери», які потім записуються на жорсткий диск.

Як DDR відстежує, які сегменти складають певний файл?

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

• Визначте розташування дерева сегментів файлів.
• Прочитайте дерево сегментів, щоб отримати список усіх відбитків сегментів, що складають область файлу, що зчитується.
• Використовуйте індекси на диску для визначення фізичного розташування (тобто контейнера) даних на диску.
• Зчитування даних фізичних сегментів з базових контейнерів на диску.
• Використовуйте дані фізичного сегмента, щоб відновити файл.

Дерева сегментів файлів також зберігаються в контейнерах розміром 4,5 Мб на диску і представляють більшу частину метаданих кожного файлу (обговорюються далі в цій статті).

Як можна визначити загальний ступінь стиснення на DDR?

Загальне використання DDR (і коефіцієнта стиснення) можна побачити за допомогою команди 'fileys show space'. Наприклад:Активний рівень:Розмір ресурсу ГіБ, що використовується ГіБ Використання ГіБ, Використання% Очищений ГіБ*---------------- -------- -------- --------- ---- --------------/дані: пре-комп - 115367,8 - - -/дані:


пост-комп
6794,2 6242,4 551,8 92% 202,5
/ддвар 49,2 9,1 37,6 20% -


---------------- -------- -------- --------- ---- --------------

У цьому випадку ми бачимо, що:

• Попередньо стиснені або логічні дані, що зберігаються в DDR: 115367.8 Гб
• Постстиснений або фізичний простір, який використовується в DDR: 6242.4 Гб
• Загальний ступінь стиснення становить 115367,8 / 6242,4 = 18,48x

Вихідні дані команди 'fileys show compression' підтверджують дані, які зберігаються, простір, який використовується, і коефіцієнт стискання. Наприклад:

                   Pre-comp Post-comp Global-comp Local-Comp Total-Comp
(GiB) (GiB) Факторний фактор
(зниження %)
---------------- -------- --------- ----------- ---------- -------------
Використовується в даний час:*   115367.8 6242.4 - - 18.5x (94.6) <=== ПРИМІТКА
Написано:                                                                          
  Останні 7 днів 42214.7 1863.2 11.0x 2.1x 22.7x (95.6)
  За останні 24 години 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Загальні показники використання DDR розраховуються наступним чином:

• Загальна кількість попередньо стиснених даних: Сума попередньо стисненого (логічного) розміру всіх файлів, що зберігаються в DDR.
• Загальна кількість постстиснених даних: Кількість використовуваних «контейнерів» на диску помножена на 4,5 Мб (розмір одного контейнера).
• Загальний розмір після стиснення: Максимальна кількість створених «контейнерів» за наявності вільного місця на диску в системі.

Статистика щодо максимальних контейнерів, що використовуються, доступна в автопідтримках. Наприклад:Контейнерний набір 73fcacadea763b48:b66f6a65133e6c73:
...


    attrs.psize = 4718592 <=== Розмір контейнера в байтах
...
    attrs.max_containers = 1546057 <=== Максимально можливі контейнери attrs.free_containers = 125562 <=== На даний момент вільні контейнери attrs.used_containers = 1420495 <=== Контейнери


, що використовуються в даний час...

Дивіться, що:
 
Як можна визначити коефіцієнти дедуплікації та стиснення для окремого файлу, каталогу або дерева каталогів?

Коли файл передається всередину, DDR записує статистичні дані про нього, зокрема:

• Попередньо стислі (логічні) байти
• Розмір унікальних сегментів після дедуплікації
• Розмір унікальних сегментів після дедуплікації та стиснення
• Розмір метаданих файлу (тобто дерева сегментів тощо)

Деяку з цих статистичних даних можна скинути за допомогою команди 'fileys show compression [path]' - наприклад, щоб повідомити статистику для одного файлу:SE@DDVE60_JF## filesys показати стиснення /data/col1/backup/testfile
Всього файлів:

1;  байтів/storage_used: 2.9
Оригінальні байти:        3 242 460 364
Глобально стиснені:        1 113 584 070
локально стиснутих:        1 130 871 915
Метадані:            4 772 672

Щоб повідомити статистику для всього дерева каталогів:SE@DDVE60_JF## filesys показати стиснення /data/col1/backup
Всього файлів:

3;  байтів/storage_used: 1.4
Оригінальні байти:        7 554 284 280
у всьому світі:        5 425 407 986
Локально стиснуті:        5,510,685,100
Метадані:           23 263 692

Однак зауважте, що є кілька застережень щодо використання цієї статистики:

• Статистика генерується під час отримання файлу або даних, і після цього не оновлюється. У зв'язку з тим, як працює DDR, прийом нових файлів або видалення файлів, що посилаються на ті самі дані, тощо може з часом змінити спосіб дедуплікації файлу, що призведе до того, що ця статистика стане застарілою.
• Крім того, деякі випадки використання DDR (наприклад, швидка копія файлу, а потім видалення оригінального файлу) можуть призвести до того, що ця статистика може ввести в оману або стати неправильною.

Тому ці цифри слід розглядати лише як приблизні.

Попередньо стиснуті байти не обов'язково є попередньо стиснутим/логічним розміром файлу. Натомість, це загальна кількість байтів, записаних у файл за час його життя. В результаті, в деяких середовищах існуючі файли зазвичай перезаписуються (наприклад, ті, що використовують функціональність бібліотеки віртуальної стрічки), ця цифра може бути більшою за логічний розмір відповідних файлів.

Чи може проковтування даних «низької якості» призвести до погіршення загального ступеня стиснення?

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



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

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

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

Зауважте також, що замість попередньо стиснутих файлів алгоритм lz навряд чи зможе додатково стиснути дані складових сегментів, тому дані не можуть бути стиснуті перед записом на диск.

Як правило, попереднє стиснення/попереднє шифрування призводить до наступного:

• Попередньо зашифровані дані: Поганий коефіцієнт дедуплікації, але прийнятний ступінь стиснення
• Попередньо стиснені дані: Поганий коефіцієнт дедуплікації та поганий ступінь стиснення

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

Там, де це можливо, дані, надіслані на DDR, не повинні шифруватися або стискатися – це може вимагати вимкнення шифрування або стиснення на кінцевому клієнті або у відповідній програмі резервного копіювання.

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

Мультимедійні файли:

Деякі типи файлів містять попередньо стиснуті або попередньо зашифровані дані. Наприклад:

• PDF-файли
• Певні аудіофайли (mp3, wma, ogg тощо)
• Відеофайли (avi, mkv і так далі)
• Файли зображень (png, bmp, jpeg тощо)
• Специфічні для програми файли (Microsoft Office, Open Office, Libre Office тощо)

Дані у файлах стискаються або шифруються кодеком файлу і, як наслідок, спричиняють ті самі проблеми під час потрапляння в DDR, як описано вище для попередньо стиснутих або попередньо зашифрованих даних.

Файли з високою «унікальністю»:

Досягнення хорошого коефіцієнта дедуплікації залежить від того, чи DDR бачить один і той же набір сегментів (і сегментних відбитків) кілька разів. Однак деякі типи даних містять лише унікальні транзакційні дані, які за задумом містять «унікальні» дані.

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

Прикладами таких файлів є:

• Журнали транзакцій баз даних (наприклад, журнали архівів Oracle).
• Журнали транзакцій Microsoft Exchange

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

Невеликі файли:

Невеликі файли спричиняють різні проблеми під час запису в DDR. До них відносяться:

• Роздуття метаданих – DDR починає містити більший, ніж очікувалося, обсяг метаданих файлу порівняно з фізичними даними.
• Погане використання контейнера - За задумом (через Data Domain Stream Informed Segment Layout або архітектуру SISL - поза рамками цього документа) контейнер розміром 4,5 Мб на диску містить дані лише з одного файлу. У результаті, наприклад, резервне копіювання одного файлу розміром 10 КБ призводить до того, що для цього файлу буде записано принаймні один повний контейнер розміром 4,5 МБ. Це може означати, що для таких файлів DDR використовує значно більше постстисненого (фізичного) простору, ніж відповідний обсяг попередньо стиснених (логічних) даних, що резервується, що, у свою чергу, спричиняє від'ємний загальний коефіцієнт стиснення.
• Поганий коефіцієнт дедуплікації – файли, розмір яких менший за 4 КБ (мінімальний підтримуваний розмір сегмента в DDR), складаються з одного сегмента, який розширюється до 4 КБ. Такі сегменти не дедуплюються, а записуються безпосередньо на диск. Це може призвести до того, що DDR міститиме кілька копій одного сегмента (які розглядаються як повторювані сегменти).
• Погане резервне копіювання, відновлення або чиста продуктивність - Існують великі накладні витрати під час резервного копіювання, відновлення або очищення при переході з одного файлу в інший (оскільки контекст метаданих, що використовуються, повинен бути змінений).

Дивіться, що:

• Вплив на продуктивність очищення при використанні невеликих файлів було певною мірою пом'якшено впровадженням фізичного очищення або збирання сміття в DDOS 5.5 і пізніших версіях.
• Очищення намагається «скасувати» погане використання контейнера шляхом агрегування даних з контейнерів з низьким рівнем використання в більш щільно упаковані контейнери на етапі його копіювання.
• Очищення намагається видалити зайві повторювані сегменти на етапі копіювання.

Незважаючи на вищесказане, слід уникати використання великої кількості дрібних файлів або робочих навантажень, що складаються в основному з невеликих файлів. Краще об'єднати велику кількість дрібних файлів в один нестиснений/незашифрований архів перед резервним копіюванням, ніж відправляти невеликі файли в DDR в їх рідному стані. Наприклад, набагато краще створити резервну копію одного файлу розміром 10 ГБ, що містить 1048576 окремих файлів розміром 10 КБ, ніж усіх файлів 1048576 окремо.

Надмірне мультиплексування програмами резервного копіювання:

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

• Фізичний стрічковий пристрій може підтримувати лише один вхідний потік запису.
• Програма резервного копіювання повинна підтримувати достатню пропускну здатність стрічкового пристрою, щоб запобігти запуску, зупинці або перемотуванню стрічки (також відоме як сяйво взуття) - Це простіше, якщо потік, що надходить на стрічковий пристрій, містить дані, які зчитуються з кількох клієнтів.

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

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

Програми резервного копіювання не повинні використовувати мультиплексування під час запису в DDR, оскільки DDR підтримують більшу кількість вхідних потоків, ніж фізичні стрічкові пристрої, при цьому кожен потік може записувати зі змінною швидкістю. У зв'язку з цим мультиплексування додатками резервного копіювання слід відключити. Якщо після вимкнення мультиплексування це вплине на продуктивність резервного копіювання, то:

• У програмах резервного копіювання, що використовують CIFS, NFS або OST (DDBoost), слід збільшити кількість потоків запису (щоб на DDR можна було паралельно записувати більше файлів).
• Середовища, що використовують VTL, повинні додавати додаткові диски до DDR, оскільки кожен диск дозволяє підтримувати додатковий паралельний потік запису.

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

Резервні програми, які вставляють зайву кількість маркерів стрічки:

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

За деяких обставин включення маркерів у резервний потік може погіршити коефіцієнт дедуплікації, наприклад:

• У першому поколінні резервної копії було 12 Кбайт даних, які були суміжними - це було визнано DDR як єдиний сегмент.
• Однак у другому поколінні резервної копії ті самі 12 Кбайт даних розділяються за рахунок включення резервного маркера, який може бути представлений 6 Кбайт даних, маркером резервного копіювання, 6 Кбайт даних.
• Як наслідок, сегменти, створені під час другого покоління резервної копії, не збігаються з сегментами, створеними під час першого покоління резервної копії, отже, вони не дедуплікуються належним чином.

Чим ближче розташовані маркери, тим гірше співвідношення впливу на дедуплікацію (наприклад, резервна програма, яка вставляє маркери кожні 32 Кб, спричиняє більше проблем, ніж резервна програма, яка вставляє маркери кожні 1 Мб).

Щоб уникнути цієї проблеми, DDR використовує технологію розпізнавання маркерів, яка дозволяє:

• Маркери резервного копіювання, які будуть прозоро видалені з резервного потоку під час завантаження резервної копії.
• Маркери резервного копіювання, які будуть повторно вставлені в резервний потік під час відновлення резервної копії

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

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

SE@DDVE60_JF## fileys option show
Option Value
-------------------------------- --------
...
Авто
маркерного типу ...
-------------------------------- --------

Зазвичай, для цього параметра слід залишити значення 'auto', оскільки це дозволяє DDR автоматично встановлювати відповідність найпоширенішим типам маркерів. Якщо система приймає дані лише з однієї програми резервного копіювання, яка вставляє маркери, то може бути перевага в продуктивності від визначення певного типу маркера, а саме:# fileys параметр set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Дивіться, що:

• Будь-яка вигода для продуктивності від вибору конкретного типу маркера, швидше за все, буде мінімальною.
• Вибір неправильного типу маркера може призвести до значного додаткового погіршення продуктивності резервного копіювання або відновлення та коефіцієнта дедуплікації.

У зв'язку з цим, Data Domain зазвичай рекомендує залишати тип маркера встановленим на 'auto'. Щоб отримати подальшу консультацію щодо зміни типу маркера, зверніться до свого постачальника послуг підтримки.

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

Ознаки того, що дані «низької якості» надходять до DDR:

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

Глобальне стиснення	Локальне стиснення	Ймовірна причина
Низький (1x - 4x)	Низький (1x - 1,5x)	Попередньо стиснуті або зашифровані дані
Низький (1x - 2x)	Високий (>2x)	Унікальні, але доступні для стиснення дані, такі як журнали архівів баз даних
Низький (2x - 5x)	Високий (>1,5x)	Маркери, які не виявляються, або висока швидкість зміни даних, або мультиплексування потоку.
Високий (>10x)	Низький (<1,5x)	Резервні копії тих самих стислих або зашифрованих даних. Таке трапляється рідко.

Чи є певні фактори на DDR, які можуть вплинути на загальний коефіцієнт дедуплікації?

Так - Існує декілька факторів, які можуть спричинити збереження старих/зайвих даних на диску DDR, що спричиняє збільшення постстисненого (фізичного) дискового простору та падіння загального коефіцієнта стиснення. Такі фактори розглянуті нижче.

Неможливість регулярного запуску очищення файлової системи:

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

Data Domain рекомендує запланувати чистий запуск через регулярні проміжки часу наступним чином:

• Нормальний DDR: Раз на тиждень
• DDR з використанням розширеного утримання: Раз на два тижні

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

Надлишок старих знімків у системі:

DDR можуть створювати знімки mtree, які представляють вміст mtree на момент створення знімка. Однак зауважте, що залишення старих знімків у системі може спричинити збільшення постстисненого/фізичного використання, що спричинить падіння загального ступеня стиснення. Наприклад:

• Існує mtree, що містить багато файлів (тому використання попередньо стисненого файлу є високим).
• Створюється знімок mtree.
• Багато файлів видаляються (що призводить до припинення використання попередньо стисненого стиснення).
• Запускається очищення файлової системи - зауважте, однак, що мінімальне місце на жорсткому диску звільняється, оскільки копія видалених файлів залишається на знімку mtree, що означає, що дані, на які посилаються ці файли, не можуть бути видалені з диска.
• Як наслідок, посткомпресована/фізична завантаженість залишається високою

Data Domain рекомендує, щоб у разі використання знімків mtree (наприклад, для відновлення після випадкового видалення даних) ними керували за допомогою автоматичних розкладів знімків, таким чином, щоб знімки створювалися через рівні проміжки часу з визначеним періодом дії (проміжок часу до автоматичного видалення знімка). Крім того, термін дії повинен бути якомога коротшим (однак, очевидно, це може залежати від випадку використання знімків або рівня захисту, який ці знімки забезпечують). Це запобігає накопиченню старих знімків з тривалим терміном дії.

Додаткову інформацію про роботу зі знімками та розкладами знімків можна знайти в наступній статті: Домен даних - Керування розкладами

знімківНадмірна затримка реплікації:

Власна реплікація домену даних використовує або журнал реплікації, або знімки mtree (залежно від типу реплікації), щоб відстежувати, які файли або дані очікують реплікації на віддалену DDR. Затримка реплікації - це концепція репліки, що відстає від змін вихідної DDR. Це може статися через різні фактори, включаючи:

• Контексти реплікації вимкнено
• Недостатня пропускна здатність мережі між DDR
• Часті відключення мережі.

Велика затримка реплікації може призвести до того, що журнал реплікації продовжуватиме містити посилання на файли, які були видалені у вихідній DDR, або старі чи застарілі знімки mtree у вихідних та цільових DDR. Як описано вище, дані, на які посилаються ці знімки (або журнал реплікації), не можуть бути фізично видалені з диска на DDR, навіть якщо відповідні файли були видалені з системи. Це може призвести до збільшення постстисненого або фізичного використання DDR, що потім спричиняє погіршення співвідношення до дедуплікації.

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

Чи є зміни конфігурації або певні фактори на DDR, які можуть збільшити загальний ступінь стиснення?

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

• Зменшення обсягу місця на жорсткому диску, що використовується файлами на DDR (наприклад, підвищення агресивності алгоритму стиснення, що використовується DDR)
• Раптове збільшення обсягу попередньо стиснених (логічних) даних на DDR без відповідного збільшення постстисненого/фізичного використання

Модифікація алгоритму стиснення:

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

Можливе підвищення агресивності алгоритму стиснення, щоб забезпечити подальшу економію при постстисненні або використанні жорсткого диска (і, як наслідок, підвищити загальний коефіцієнт стиснення). Підтримувані алгоритми стиснення, в порядку ефективності (від низького до високого), такі:

• ЛЗ
• gzfast
• Г.З.

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

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

Також можна повністю вимкнути стиснення (вказати алгоритм none), однак це не підтримується для використання у системах замовника і призначене лише для внутрішнього тестування.

Згідно з наведеною вище таблицею, чим агресивніший алгоритм стиснення, тим більше процесора потрібно під час стиснення або розпакування даних. У зв'язку з цим, зміни до більш агресивного алгоритму слід вносити лише в системах, які незначно навантажені при звичайному робочому навантаженні. Зміна алгоритму на сильно навантажених системах може призвести до значного погіршення продуктивності резервного копіювання або відновлення, а також до можливої паніки або перезавантаження файлової системи (що призведе до збою в роботі DDR).

Для отримання додаткової інформації про зміну типу стиснення дивіться наступну статтю: Система доменів даних і продуктивність очищення Вплив перетворення на стиснення

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

Використання файлової системи fastcopy:

DDR дозволяють використовувати команду 'file system fastcopy' для швидкого копіювання файлу (або дерева каталогів). Ця функція створює файл шляхом клонування метаданих наявного файлу (або групи файлів) таким чином, що, хоча нові файли фізично не пов'язані з оригінальним файлом, вони посилаються на ті самі дані на диску, що й вихідний файл. Це означає, що незалежно від розміру вихідного файлу, новий файл займає мало місця на диску (оскільки він ідеально дедуплікує наявні дані).

Результатом такої поведінки є те, що при використанні fastcopy файлової системи попередньо стиснений (логічний) розмір даних на DDR швидко збільшується, але постстиснене/фізичне використання DDR залишається статичним.

Наприклад, наступний DDR має таке використання (що вказує на загальний ступінь стиснення ~1,8x):Активний рівень:Розмір ресурсу GiB Використаний GiB Avail GiB Використання% Чистий GiB*---------------- -------- -------- --------- ---- --------------/дані: pre-comp - 12.0 - - -/data:


post-comp 71.5 6.8 64.7 10% 0.0



/ddvar 49.2 1.1 45.6 2% -/ddvar/core 158.5 0.2 150.2 0% -

---------------- -------- -------- --------- ---- --------------

Містить великий файл (/data/col1/backup/testfile):
!!!
DDVE60_JF ВАШІ ДАНІ В НЕБЕЗПЕЦІ !!! # ls -al /data/col1/backup/testfile-rw-r--r-- 1 кореневий корінь 3221225472 29 липня 04:20 /data/col1/backup/testfile


Файл швидко копіюється кілька разів:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1 sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup
/testfile_copy3

Це призводить до того, що попередньо стиснене використання збільшується при незначних змінах у використанні після стиснення:Активний рівень:Розмір ресурсу Використаний ГіБ Використання ГіБ% Використання% Очищений ГіБ*---------------- -------- -------- --------- ---- --------------/дані: пре-комп - 21,0 - - -/дані:


пост-комп
71,5 6,8 64,7 10% 0,0


/ddvar 49.2 1.1 45.6 2% -/ddvar/core 158.5 0.2 150.2 0% -

---------------- -------- -------- --------- ---- --------------

В результаті DDR тепер показує загальний коефіцієнт стиснення ~3,1x.

Як згадувалося вище, статистика стиснення копій показує, що вони дедуплікуються ідеально:sysadmin@DDVE60_JF# filesys показує стиснення /data/col1/backup/testfile_copy1
Всього файлів:

1;  байтів/storage_used: 21331976.1
Оригінальні байти:        3 242 460 364
Глобально стиснені:                   
0 Локально стиснутий:                   
0 Метадані:                  152

Функціональні можливості fastcopy не можуть бути використані для покращення загального коефіцієнта стискання шляхом зменшення фізичного використання DDR, однак це може бути причиною високого загального коефіцієнта стискання (особливо у середовищах, де широко використовується fastcopy, зокрема Avamar 6.x).