Домен даних: Вступ до довгострокового зберігання/очищення хмарного рівня/збирання сміття на реставраторах доменів даних (DDR)

Операційна система Data Domain Operating System (DDOS) 6.0 представляє нову функцію, відому як хмарне зберігання або довгострокове зберігання (LTR). Ця функція дає змогу додавати другий рівень об'єктного сховища, наданого хмарним провайдером, до певних моделей Data Domain Restorer (DDR) із пов'язаною CLOUD_CAPACITY ліцензією.

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

Файли на рівні хмари можна видаляти як зазвичай, однак пов'язаний простір у хмарному/об'єктному сховищі не відразу використовується для використання. Щоб видалити зайві дані з хмари, рівень хмари повинен бути очищений.

Структура хмарного рівня:

Хмарний рівень поділяється на «хмарні одиниці». Зазначимо, що:

• Хмарний рівень може містити до двох хмарних блоків
• Розмір кожного хмарного блоку може дорівнювати максимальному підтримуваному розміру активного рівня для даної моделі DDR
• Кожен хмарний блок може бути виділений у різного постачальника об'єктного сховища

Наприклад:# список
хмарних блоків Ім'я Профіль Статус
----------------------- ------------ ------
B-одиниця LTR-ECS-Ben Активна <=== ECS провайдер
cloud-unit-virtustream1 virtustream1 Активний <=== Virtustream провайдер
----------------------- ------------ ------

Основні поняття хмарного очищення:

• Хмарне очищення працює тільки з одним хмарним блоком під час кожного запуску - щоб визначити хмарний блок, що очищається, в журналах DDFS (/ddr/var/log/debug/ddfs.info) можна знайти наступне повідомлення - в цьому випадку очищається хмарний блок cloud-unit-virtustream1:

• Якщо система має кілька хмарних блоків, налаштовано хмарне очищення за круговою системою очищення цих пристроїв, намагаючись очистити один блок щоразу, коли виконується хмарне очищення
• Cloud clean може бути запущений вручну або автоматично за розкладом - для запуску вручну використовується наступна команда:

• Чистий активний рівень і хмарне очищення не можуть працювати паралельно (через те, що обидва використовують однакові структури пам'яті в DDFS)
• Якщо виконується активне рівневе очищення (запускається вручну або за його розкладом) і робиться спроба запуску хмарного очищення, воно призведе до помилки, тобто:

• Якщо хмарне очищення було розпочато автоматично (тобто за його розкладом) і розпочато активне очищення рівня очищення, то очищення хмарного блоку буде перервано, щоб забезпечити запуск чистого активного рівня. На це вказує наступне в журналах DDFS:

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

• Хмарний блок повинен зазнати мінімум 1% «відтоку» даних (тобто >= 1% даних, які зараз знаходяться на хмарному блоці, повинні вважатися надзвичайними і, отже, видаляються), щоб хмарне очищення почалося. Якщо це не так, у командному рядку буде відображено наступне, якщо хмарне очищення запущено вручну:

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

Планування чистоти хмари:

У DDOS 6.0 і пізніших версіях спосіб, у який планується активне очищення рівня, не змінився - за замовчуванням активне очищення рівня планується виконувати раз на тиждень о 0600 у вівторок, тобто:

# файлис чисте шоу розклад
Очищення файлової системи заплановано на запуск "Вт" о "0600".

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

# Показ
частоти очищення хмари Частота очищення рівня хмари встановлена на запуск після кожних 4 активних циклів очищення рівня.

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

Щоб змінити частоту очищення хмари, можна використовувати наступну команду:

# набір частоти очищення хмари 2
Частота очищення рівня хмари встановлюється на запуск після кожних 2 активних циклів очищення рівня.

Щоб скинути хмарне очищення до стандартного розкладу після очищення кожних 4 активних рівнів, можна використовувати наступну команду:

# Cloud Clean frequency reset
Частота прибирання хмарного рівня скидається до стандарту (кожні 4 цикли очищення активного рівня).

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

Також можна повністю відключити заплановане хмарне очищення за допомогою наступної команди:

# частота очищення хмари ніколи не
встановлюється Частота очищення рівня хмари встановлена на «ніколи».

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

Щоб зупинити поточне хмарне очищення, можна використовувати наступну команду:

# cloud clean stop

Щоб визначити, коли cloud clean востаннє запускався, можна використовувати наступну команду:

# cloud clean status
Cloud tier cleaning finished at 2016/08/01 20:54:43.

Алгоритм хмарного очищення:

Cloud clean використовуватиме той самий алгоритм очищення, що й налаштований для активного рівня. У DDOS 6.0 (і пізніших версіях) це за замовчуванням ідеальний фізичний збір сміття (PPGC), однак це може бути змінено на фізичний збір сміття (PGC) за допомогою системних параметрів.

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

DDFS Алгоритм, який використовується для хмарного очищення, відображається в журналах DDFS при запуску очищення, тобто:
06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern
: Обраний алгоритм: Фізичне очищення <=== PPGC або PGC
27.07 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Обраний алгоритм: Повне очищення <=== Традиційний ГХ

Зауважте, що з наведеного вище виводу неможливо відрізнити PPGC або PGC - конкретний використовуваний алгоритм очевидний через кількість фаз, що виконуються clean - в загальному випадку:

Традиційний/повний GC: 10 фаз
ПГХ: 12 фаз
ППГК: 6 етапів Для отримання додаткової інформації про зміну алгоритму очищення, що використовується в системі, зверніться до постачальника послуг підтримки

, з яким укладено

контракт.Відмінності між фазами чистого активного рівня та чистого рівня хмари:

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

Активний рівень:

• Дані, записані на активний рівень DDR, містяться в контейнерах розміром 4,5 Мб
• За замовчуванням контейнер буде розглядатися як «копія» лише за допомогою clean, якщо він містить <= 92% 'живих' (тобто активно посилаються) даних
• Живі дані будуть витягнуті з контейнера та записані в новий контейнер (разом із живими даними з інших скопійованих контейнерів) наприкінці файлової системи
• На диску індекси оновлюються, щоб відображати новий контейнер, що містить живі дані
• Оригінальний контейнер (що містить як живі, так і мертві дані) видаляється, а нижній дисковий простір стає доступним для використання

Хмарний рівень:

• Дані, записані на хмарний рівень DDR, мають іншу структуру - замість розміщення в контейнерах 4,5 Мб окремі фрагменти даних (області стиснення 64 Кб) записуються в хмарний блок (ПРИМІТКА: для DDOS 6.1.2.0 і пізніших об'єктів, що зберігаються в блоці хмарного блоку, будуть більшими, див. Домен даних: Великий розмір об'єкта для хмарного рівня для деталей)
• Замість того, щоб витягувати реальні дані з існуючої області стиснення та копіювати їх, хмарне очищення розглядатиме лише області стиснення, які містять виключно мертві дані для видалення.

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

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

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