Домен даних: Огляд етапів очищення файлової системи домену даних/збору сміття

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

Прибирання (іноді відоме як збір сміття або GC) — це процес, за допомогою якого DDR:

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

Clean/GC зазвичай запускається через регулярні проміжки часу (за замовчуванням він починається о 6 ранку щовівторка) і може бути таким:

• Тривалий біг
• Обчислювально дорогий

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

У цій статті клін/ГК описується більш детально, пояснюючи:

• Фази, які зазвичай проходять
• Різні алгоритми очищення використовуються в різних версіях DDOS

Ніхто

Кожен раз, коли запускається clean/GC, він має дві основні мети - спочатку він повинен знайти зайві дані про DDR - короткий огляд того, як це робиться наступним чином:

• Clean/GC нумерує вміст файлової системи DDFS, шукаючи такі об'єкти, як файли, знімки та журнали реплікації, які наразі існують у системі
• Потім він визначає всі фізичні дані на диску, на які активно посилаються ці об'єкти
• Дані, на які посилаються активно, називаються «живими» і не можуть бути видалені з DDR, інакше об'єкти, що посилаються на ці дані, будуть пошкоджені (їх більше не можна буде читати, оскільки базові дані, від яких вони залежали, більше не існуватимуть на диску)
• Дані, на які не посилається активно жоден об'єкт, називаються «мертвими» і зайвими - ці дані можна сміливо видаляти з системи
• Усі дані на DDR упаковуються в об'єкти розміром 4,5 Мб, відомі як контейнери
• За допомогою перерахування clean/GC може визначити, які контейнери розміром 4,5 Мб містять мертві дані та кількість мертвих даних у кожному
• За замовчуванням clean/GC вибере контейнери розміром 4,5 МБ, що містять > 8% мертвих даних для «обробки»

По-друге, він повинен видаляти мертві дані на DDR - коротке пояснення того, як це робиться, виглядає наступним чином:

• Контейнери, вибрані для обробки, знову перевіряються, щоб підтвердити, що вони містять достатню кількість мертвих даних
• Живі дані витягуються з цих контейнерів і записуються в нові контейнери по 4,5 Мб в кінці файлової системи
• Як тільки це буде завершено, вибрані контейнери (включаючи мертві дані, які вони містять) видаляються з диска, фізично звільняючи місце на диску

Процес очищення поділяється на кілька «фаз», загальна кількість фаз яких залежить від:

• Версія DDOS, яка використовується на DDR (звідси і чистий алгоритм, який використовується, за замовчуванням, цією версією DDOS)
• Конфігурація або вміст системи

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

1. Попереднє перерахування - перерахування вмісту файлової системи DDFS
2. Попереднє злиття – виконайте злиття індексів DDFS, щоб переконатися, що остання копія інформації індексу скинута на диск
3. Попередній фільтр - визначте, чи є дублікати даних у файловій системі DDFS, і якщо так, то де це знаходиться
4. Попередньо вибираємо - визначаємо, які контейнери об'ємом 4,5 Мб слід "обробити" шляхом очищення
5. Копіювати - фізично витягувати живі дані з вибраних контейнерів, записувати це в нові контейнери, потім видаляти вибрані контейнери
6. Summary - перебудова векторів резюме (які використовуються як оптимізація під час прийому нових даних)

У наведеному вище прикладі фази 1-4 використовуються для визначення того, де існують «мертві» дані на DDR. У решті цього документа це називається «етапами перерахування». Фаза 5 (копія) використовується для фізичного видалення цих даних.

Фізично не звільниться місце в системі, поки clean/GC не досягне фази копіювання. Як наслідок, може виникнути значна затримка між початком прибирання та початком звільнення простору (через те, що процес перерахування спочатку потрібно запускати до завершення). З цієї причини не можна допускати, щоб системи заповнювалися на 100% до початку clean/GC.

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

• Загальна тривалість етапів перерахування залежить від обсягу даних на НДР, які необхідно пронумерувати
• Загальна тривалість фази копіювання залежить від кількості мертвих даних на DDR, які необхідно видалити, і від того, наскільки «фрагментовані» ці дані на диску (про це йдеться нижче)

Кількість/функціональність фаз перерахування залежить від випуску DDOS, що використовується на DDR.

DDOS 5.4 (і раніше) - алгоритм повного очищення: Проходить 6 або 10 фаз (як показано вище):

• Вміст файлової системи DDFS перераховується зверху вниз (тобто вона орієнтована на файли)
• DDFS виявляє всі файли, що існують у DDR, а потім сканує кожен файл по черзі, щоб визначити, на які дані посилається цей файл
• Це дозволяє clean/GC визначити, які дані на диску є «живими»

DDOS 5.5 (і пізніші версії) - алгоритм фізичного очищення (PGC): Проходить 7 або 12 етапів:

• Вміст DDFS перераховується знизу вгору (тобто в ній більше не скануються окремі файли)
• DDFS виявляє метадані файлової системи, які посилаються на фізичні дані на диску, і сканує ці метадані, щоб визначити, на які дані посилаються
• Це дозволяє clean/GC визначити, які дані на диску є «живими»
• Це досягається додаванням фази «аналізу» (звідси і збільшення кількості фаз за алгоритмом повного очищення)
• Зазвичай очікується, що загальна тривалість фізичного очищення буде коротшою, ніж повна чистка для тієї ж системи (незважаючи на те, що вона складається з більшої кількості окремих етапів)

DDOS 6.0 (і пізніші версії) - ідеальний алгоритм фізичного очищення (PPGC):

• Це просто оптимізація алгоритму фізичного очищення і обговорюється нижче

DDOS перейшов від алгоритму повного очищення до алгоритму фізичного очищення, щоб покращити масштабованість/продуктивність процесу перерахування - через характер повного очищення зверху вниз він погано масштабувався на DDR з одним із таких варіантів:

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

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

Аналогічно, DDR автоматично перемикаються з фізичних на ідеальні алгоритми фізичного очищення при оновленні з DDOS 5.x до 6.0 (або пізніше). Однак зауважте, що ідеальний алгоритм фізичного очищення вимагає, щоб індекси були у форматі 'index 2.0', перш ніж його можна буде використовувати. Зазначимо, що:

• Формат 'index 2.0' був введений з DDOS 5.5 (тому всі файлові системи, створені на 5.5 або пізніше, вже використовують індекс 2.0)
• Файлова система, створена на версії 5.4 або ранішої версії, спочатку мала індекси у форматі index 1.0. Після оновлення до DDOS 5.5 (або пізніше) індекси будуть перетворені у формат індексу 2.0 - конвертація відбувається кожного разу, коли виконується чистий запуск, однак лише ~1% індексів конвертуються під час кожного очищення, тому може знадобитися до 2 років (за умови чистих прогонів щотижня) для повного перетворення індексів у формат 2.0

DDR, які спочатку працюють під керуванням DDOS 5.4 (або ранішої версії), але згодом були оновлені до DDOS 5.5 (або пізніше), можуть бути примусово перетворені індекси у формат індексу 2.0 шляхом одноразової «перебудови індексу». Однак зауважте, що перебудова індексу вимагає певного періоду простою, поки індекси фізично перебудовуються - ця операція зазвичай займає 2-8 годин залежно від розміру/обсягу даних на DDR. Щоб обговорити виконання перебудови індексу, зверніться до постачальника послуг підтримки, з яким укладено контракт.

Незалежно від використовуваного алгоритму очищення, він може вимагати змінної кількості фаз - наприклад, алгоритм повного очищення може вимагати 6 або 10 фаз. Причиною цього є те, що:

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

Коли відбір проб використовується в чистому вигляді/ГК:

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

Відбір проб автоматично вмикається під час clean/GC, якщо це необхідно, однак спричинить:

• Збільшення числа фаз, які повинні бути виконані ГК
• Відповідне збільшення загальної тривалості ГХ

До DDOS 6.0 більшість DDR виконують вибірку під час GC (якщо вони не містять відносно невеликий набір даних). Ідеальний алгоритм фізичного очищення, однак, включає різні оптимізації для зменшення обсягу пам'яті, необхідного GC при нумерації даних у файловій системі. Це означає, що багато систем, які виконували дискретизацію під час GC на DDOS 5.x, більше не потребуватимуть дискретизації на DDOS 6.0 - це, таким чином, зменшує кількість фаз, що виконуються чистим способом, і викликає відповідне зменшення загального часу чистого виконання (тобто покращення чистих характеристик).

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

• Коли система працювала фізично чисто на DDOS 5.5 - 5.7, вона виконувала 12 фаз під час чистки
• Після оновлення системи до DDOS 6.0 (або пізнішої версії) вона виконує лише сім фаз під час очищення

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

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

• Кількість «мертвих» даних, які потрібно видалити
• «Фрагментація» цих мертвих даних (саме так вони розподіляються по диску)

Як описано вище, копія працює шляхом вибору контейнерів розміром 4,5 Мб, які містять мертві дані, вилучення будь-яких живих даних з цих контейнерів і запису цих живих даних у нові контейнери, а потім видалення початково вибраних контейнерів. Нижче наведено приклади, чому фрагментація мертвих даних є важливою:

Приклад 1:

• Для копіювання вибирається десять контейнерів (загальні дані 45 Мб)
• Все якщо ці контейнери не містять живих даних (тобто дані, які вони зберігають, абсолютно не мають посилань)
• В результаті копія повинна позначити ці контейнери як видалені, щоб звільнити 45 Мб фізичного простору на диску

Приклад 2:

• Для копіювання вибирається 100 контейнерів (всього 450 Мб)
• Кожен із цих контейнерів містить 90% живих даних і 10% мертвих даних
• Для обробки цих контейнерів copy повинен:

Для виконання копіювання, описаного в прикладі 2, потрібно більше вводу-виводу та процесора, ніж у прикладі 1, отже, потрібно більше часу, щоб звільнити 45 Мб фізичного простору на диску в цьому прикладі.

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

Відсоток живих даних у копіюванні:              3,6% 4,3%

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

Відсоток живих даних у копії:             70,9% 71,5%

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

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

• Використання шифрування: Дані можуть потребувати розшифровки/повторного шифрування під час копіювання, що значно збільшує необхідний обсяг процесора
• Використання оптимізації низької пропускної здатності: Контейнерам може знадобитися «ескізнена» інформація для генерації під час копіювання, що також спричиняє значне збільшення необхідного обсягу процесора

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

Додаткові примітки щодо перевірки/зміни чистого графіка та дросельної заслінки доступні в наступній статті KB: Домен даних - Планування очищення на DDR

Однак зауважте, що:

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

• За замовчуванням чиста дросельна заслінка встановлена на 50 - користувач несе відповідальність за перевірку роботи чистої заслінки з різними налаштуваннями дросельної заслінки, поки DDR відчуває звичайне робоче навантаження, щоб визначити налаштування дросельної заслінки, що дозволяє:

• Тривале прибирання не обов'язково є проблемою, якщо:

• Система, що використовує функціонал розширеного утримання, повинна бути налаштована таким чином, щоб:

• Повна інформація про останню чисту операцію включена в автопідтримку та деталі: