Домен даних: Як вирішити проблеми з великим використанням простору або нестачею доступних потужностей у реставраторах доменів даних (DDR)

 

• Це область диска, де знаходяться щойно прийняті файли/дані, і в більшості DDR файли залишаються тут, доки термін їх дії не закінчиться/не буде видалений клієнтською програмою резервного копіювання
• На DDR, налаштованих на розширене зберігання (ER) або довгострокове зберігання (LTR), процес переміщення даних може періодично запускатися для міграції старих файлів з активного рівня на рівні архіву або хмари
• Єдиний спосіб звільнити місце на активному рівні, який використовувався видаленими/перенесеними файлами, — це запустити процес збирання/очищення сміття (GC)

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

• Якщо активний рівень заповниться на 100%, нові дані не зможуть бути записані в DDR, що може спричинити збій резервного копіювання/реплікації — у цьому сценарії можуть відображатися попередження/повідомлення, такі як такі:

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

• Поясніть, чому активний рівень може стати повним
• Опишіть простий набір перевірок, які можна виконати для визначення причини високого використання активного рівня та відповідних заходів щодо виправлення

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

  Активний рівень DDR може використовуватися вище, ніж очікувалося, з ряду причин:

• Файли резервних копій/набори збережень неправильно завершуються/видаляються клієнтськими програмами резервного копіювання через неправильну політику збереження або конфігурацію програми резервного копіювання
• Затримка реплікації, що призводить до того, що велика кількість старих даних зберігається на активному рівні в очікуванні реплікації в репліки
• Дані, що записуються на активний рівень, мають нижчий, ніж очікувалося, загальний коефіцієнт стиснення
• Розмір системи неправильний, тобто вона просто замала для обсягу даних, які намагаються на ній зберігати
• Резервні копії складаються з великої кількості дуже маленьких файлів - ці файли займають набагато більше місця, ніж очікується при початковому записі, однак цей простір повинен бути звільнений під час очищення/збирання сміття
• Переміщення даних не виконується регулярно в системах, налаштованих за допомогою ER/LTR, через що старі файли, які слід перенести на рівні архіву/хмари, залишаються на активному рівні
• Прибирання/вивезення сміття не виконується регулярно
• Надмірні або старі знімки mtree, що існують на DDR, що перешкоджають очищенню місця від видалених файлів/даних

Крок 1 – Визначте, чи потрібно запускати

активне очищення рівняОпераційна система Data Domain Operating System (DDOS) намагається підтримувати лічильник під назвою «Cleanable GiB» для активного рівня. Це оцінка того, скільки фізичного (пост-комп) простору потенційно може бути звільнено на активному рівні, запустивши чистоту/збір сміття. Цей лічильник відображається командами 'fileys show space'/'df':
 
Якщо:

• Значення для параметра "ГіБ, який можна очистити" є великим
• DDFS заповнилася на 100% (і тому доступна лише для читання)

Слід виконати очищення та дати йому добігти до кінця, перш ніж продовжувати будь-які подальші кроки в цьому документі. Для початку очищення слід використовувати команду 'fileys clean start', тобто:
 
Щоб підтвердити, що очищення розпочалося належним чином, можна скористатися командою 'fileys status', тобто:
 
Зазначимо, що:

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

• Жодне місце на активному рівні не буде звільнено/відновлено, доки чистий не досягне фази копіювання (за замовчуванням фаза 9 у DDOS 5.4.x і раніші, фаза 11 у DDOS 5.5.x і пізніші). Для отримання додаткової інформації про фази, що використовуються clean, див.: https://support.emc.com/kb/446734
• Clean може не повернути обсяг простору, зазначений «GiB, що очищається», оскільки це значення, по суті, є оцінкою. Для отримання додаткової інформації про це див.: https://support.emc.com/kb/485637
• Clean не може звільнити весь потенційний простір за один прогін — це пов'язано з тим, що на DDR, що містять дуже великі набори даних, clean працюватиме проти частини файлової системи, що містить найбільше зайвих даних (тобто для забезпечення найкращої віддачі вільного простору за час, витрачений на чистоту). У деяких сценаріях очищення може знадобитися запустити кілька разів, перш ніж буде звільнено весь потенційний простір
• Якщо значення для параметра «ГіБ, що очищається» було дуже великим, це може означати, що очищення не виконується через регулярні проміжки часу - перевірте, чи встановлено розклад очищення:

Після завершення очищення використовуйте команди 'fileys show space'/'df', щоб визначити, чи вирішено проблеми з використанням. Якщо використання все ще високе, перейдіть до решти кроків у цій статті.

Крок 2 - Перевірте наявність великої затримки реплікації в контексті

реплікації джерелаРеплікація домену нативних даних розроблена навколо концепції «контекстів реплікації». Наприклад, коли дані потрібно реплікувати між системами:

• Контексти реплікації створюються на вихідних і цільових DDR
• Контексти ініціалізуються
• Після завершення ініціалізації реплікація періодично надсилатиме оновлення/дельти від джерела до місця призначення, щоб синхронізувати дані в системах

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

• Контексти реплікації каталогів (використовуються при реплікації одного дерева каталогів у /data/col1/backup між системами):

•  Контексти реплікації Mtree (використовуються при реплікації будь-якого mtree, відмінного від /data/col1/backup між системами):

• Контексти реплікації колекції (використовуються при реплікації всього вмісту однієї DDR в іншу систему):

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

• Визначте ім'я хоста поточної системи:

• Визначте дату/час у поточній системі:

• Список контекстів реплікації, налаштованих у системі, разом із їхніми «синхронізованими на час». Зауважте, що контексти, що становлять інтерес, — це ті, де «призначення» НЕ містить назви вузла поточної системи (що вказує на те, що джерелом є поточна система), а «синхронізовано станом на час» є значно старішим:

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

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

Крок 3 – Перевірте наявність mtrees, які більше не потрібні

Вміст DDFS логічно поділено на mtree. Зазвичай окремі програми резервного копіювання/клієнти пишуть до окремого mtrees. Якщо програма резервного копіювання буде введена в експлуатацію, вона більше не зможе записувати дані/видаляти дані з DDR, що може залишити старі/зайві mtree у системі. Дані в цих mtree продовжуватимуть існувати нескінченно довго, використовуючи місце на диску в DDR. Як наслідок, будь-які такі зайві дерева повинні бути видалені. Наприклад:

• Отримати список mtrees у системі:

• Будь-які mtree, які більше не потрібні, слід вилучити за допомогою команди 'mtree delete', тобто:

• Місце, зайняте на диску видаленим mtree, буде зайнято при наступному запуску активного рівня очищення/збирання сміття.

Зазначимо, що:

• Mtree, які є адресатами для реплікації mtree (тобто мають статус RO/RD у виводі списку mtree), повинні мати відповідний контекст реплікації, перш ніж mtree буде видалено
• Mtree, які використовуються як логічні модулі зберігання DDBoost (LSU) або як пули віртуальної стрічкової бібліотеки (VTL), можуть бути не можуть бути видалені за допомогою команди 'mtree delete' - зверніться до Посібника з адміністрування домену даних для отримання додаткової інформації про видалення таких mtree
• Mtree, які налаштовані на блокування збереження (тобто мають статус RLCE або RLGE), не можуть бути видалені — натомість окремі файли в mtree повинні бути скасовані та видалені окремо — зверніться до Посібника з адміністрування домену даних для отримання додаткової інформації

Крок 4 – Перевірте наявність старих/зайвих знімків

mtreeЗнімок домену даних являє собою моментальний знімок відповідного mtree. В результаті:

• Будь-які файли, які існують у mtree на момент створення знімка, будуть посилатися на знімок
• Незважаючи на те, що знімок продовжує існувати, навіть якщо ці файли видалені/видалені, чисті не зможуть зайняти будь-який фізичний простір, який вони використовують на диску, це пов'язано з тим, що дані повинні залишатися в системі на випадок, якщо пізніше буде отримано доступ до копії файлу на знімку

Щоб визначити, чи є у mtrees старі/зайві знімки, слід виконати наступні кроки:

• Отримайте список mtrees у системі за допомогою команди 'mtree list', як показано на кроці 3
• Виведіть список знімків, які існують для кожного mtree, за допомогою команди 'snapshot list':

• Там, де існують знімки, використовуйте вихідні дані зі списку знімків mtree [назва mtree]», щоб визначити знімки, які:

• Якщо команду snapshot list буде запущено знову, ці знімки тепер відображатимуться як застарілі:

Зазначимо, що:

• Неможливо визначити, скільки фізичних даних вміщує окремий знімок або набір знімків на диску — єдиним значенням «простору», пов'язаного зі знімком, є вказівка на попередньо стиснутий (логічний) розмір mtree на момент створення знімка (як показано у наведеному вище виведенні)
• Знімки, які мають назву «REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS», керуються реплікацією mtree, і за звичайних обставин їх не потрібно видаляти вручну (реплікація автоматично завершить термін дії цих знімків, коли вони більше не потрібні). Якщо такі знімки дуже старі, це вказує на те, що відповідний контекст реплікації, ймовірно, демонструє значну затримку (як описано на кроці 2)
• Знімки з назвою «REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS» створюються за допомогою реплікації mtree, коли контекст реплікації mtree порушено. Їх призначення полягає в тому, що вони можуть бути використані для уникнення повної повторної синхронізації даних реплікації, якщо пошкоджений контекст буде пізніше відтворено (наприклад, якщо контекст був пошкоджений помилково). Якщо реплікацію не буде відновлено, ці контексти можна буде завершити вручну, як описано вище
• Прострочені знімки продовжуватимуть існувати в системі до наступного запуску clean/garbage collection — на цьому етапі вони будуть фізично видалені та видалені з виводу 'snapshot list mtree [mtree name]' - clean може звільнити будь-який простір, який ці знімки використовували на диску

Крок 5 – Перевірте наявність неочікуваної кількості старих файлів у системі

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

Зазначимо, що:

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

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

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

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

Для цього:

• Збирайте докази, як описано в параграфі «Збір sfs_dump» розділу приміток цього документа
• Відкрийте запит на обслуговування у свого постачальника послуг за контрактом

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

Крок 6 - Перевірте наявність резервних копій, які містять велику кількість дрібних файлів

Через конструкцію DDFS невеликі файли (по суті, будь-який файл, розмір якого менше приблизно 10 Мб) можуть займати надмірне місце при початковому записі в DDR. Це пов'язано з архітектурою 'SISL' (Stream Informed Segment Layout), яка змушує невеликі файли займати кілька окремих блоків простору по 4,5 Мб на диску. Наприклад, файл розміром 4 Кб може займати до 9 МБ фізичного дискового простору під час початкового запису.

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

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

Крок 7 – Перевірте, чи є нижчий, ніж очікувалося, коефіцієнт

видалення дублікатівОсновним призначенням DDR є видалення дублікатів і стиснення даних, що приймаються пристроєм. Співвідношення видалення дублювання/стиснення дуже сильно залежить від випадку використання системи та типу даних, які вона зберігає, однак у багатьох випадках буде «очікуваний» загальний коефіцієнт стиснення, заснований на результатах, отриманих за допомогою тестування доказу концепції або подібного. Щоб визначити поточний загальний коефіцієнт стиснення системи (і, отже, чи відповідає вона очікуванням), можна скористатися командою 'fileys show compression'. Наприклад:
 
У наведеному вище прикладі система досягає загального ступеня стиснення 65,3x для активного рівня (що надзвичайно добре). Якщо, однак, це значення показує, що загальний ступінь стиснення не відповідає очікуванням, то, ймовірно, будуть потрібні подальші дослідження. Зауважте, що дослідження нижчого, ніж очікувалося, ступеня стиснення є складною темою, яка може мати багато першопричин. Для отримання додаткової інформації про подальше розслідування, будь ласка, перегляньте наступну статтю: 

https://support.emc.com/kb/487055Крок 8 - Перевірте, чи є система джерелом для реплікації

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

• За допомогою команд з кроку 2 перевірте, чи є система джерелом для реплікації колекції. Для цього запустіть ''replication status' і визначте, чи є якісь контексти реплікації, починаючи з 'col://' (що вказує на реплікацію колекції), які НЕ містять імені хоста локальної системи в адресаті (вказуючи на те, що ця система повинна бути джерелом для контексту реплікації)
• Якщо система є джерелом для реплікації колекції, перевірте розмір кожного активного рівня системи, увійшовши в обидва та виконавши команду 'fileys show space' - порівняйте розмір активних рівнів 'post-comp' на кожному
• Якщо джерело значно більше за ціль, то його активний розмір рівня буде штучно обмежений
• Щоб увесь простір у джерелі можна було використовувати для даних, слід виконати такі дії:

Крок 9 - Перевірте, чи регулярно виконується

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

• Спочатку перевірте, чи налаштована система для ER або LTR, запустивши 'fileys show space' і перевіривши наявність архіву або хмарного рівня - зауважте, що для зручності використання ці альтернативні рівні сховища повинні мати пост-комп'ютерний розмір > 0Gb:

• Якщо система налаштована на ER/LTR, перевірте політики переміщення даних за mtrees, щоб переконатися, що вони відповідають очікуванням, і встановіть їх таким чином, щоб старі дані були витіснені на альтернативний рівень сховища:

• Якщо система налаштована на ER/LTR, переконайтеся, що переміщення даних заплановано на регулярні проміжки часу, щоб фізично перенести файли/дані з активного рівня до альтернативного сховища:

• Якщо система налаштована на ER/LTR, перевірте, коли востаннє виконувався рух даних:

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

Крок 10 – Додайте додаткове сховище до активного рівня

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

• Зменшіть навантаження, що б'є по системі - наприклад:

• Додайте додаткове сховище до активного рівня системи та розширте його розміри:

Підтримка Data Domain може генерувати ряд звітів, які відображають таку інформацію, як:

• Список усіх файлів певного рівня (наприклад, активних/архівних/хмарних), упорядкованих за віком
• Приблизний розмір і коефіцієнт стиснення за mtree/основним деревом каталогів
• Список усіх файлів у певному mtree, упорядкований за віком
• і так далі

Для цього необхідно зібрати наступну інформацію:

• Свіжий пакет підтримки від DDR - додаткову інформацію дивіться нижче: https://support.emc.com/kb/323283
• Виведення 'sfs_dump' або 'sfs_dump -c':

• Звіт про місцезнаходження файлу (необхідний, якщо система налаштована на ER або LTR):

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