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

Як і у випадку з багатьма масивами зберігання даних, ємність більшості моделей Data Domain Restorer (DDR) можна збільшити, додавши до системи зовнішні полиці для зберігання даних (ES30, DS60), а потім розширивши файлову систему Data Domain File System (DDFS) на ці полиці. Коли це виконується:

• Нові корпусні полиці фізично прикріплені (включено по кабелю)
• Операційна система Data Domain Operating System (DDOS) повторно сканує сховище, щоб виявити наявність нових полиць корпусів
• Потім ці нові полиці для шаф додаються до рівня зберігання в DDR (активний рівень або конкретний архівний блок)
• Потім цей рівень можна розширити в Інтернеті без необхідності відключення до DDFS
• Будь-які нові дані, записані на цей рівень зберігання, записуються на існуючі та нові полиці
• Однак дані про наявні полиці не перерозподіляються по нових полицях шаф

Щоб пояснити це далі:

• У DDOS одиницею зберігання даних є «контейнер» об'ємом 4,5 Мб
• У міру їх створення контейнери розміром 4,5 Мб записуються на всі полиці корпусів у відповідному архівному блоці рівня за круговою системою
• Коли до архівного блоку рівня додаються додаткові полиці корпусів, DDFS починає записувати нові контейнери розміром 4,5 Мб до цих корпусів на додаток до існуючих корпусів (нові корпуси включаються, коли записує контейнер за круговою системою)
• DDOS, однак, не робить жодних конкретних спроб (або не пропонує жодної конкретної функціональності) для міграції існуючих контейнерів на рівні з існуючих на нові корпуси полиць

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

• Спочатку DDR має один корпус на своєму активному рівні, який заповнений на 90%
• До активного рівня додається додатковий корпус, а DDFS розширюється на цей корпус
• Записи про новостворені контейнери об'ємом 4,5 Мб тепер проходять по колу в існуючих і нових корпусах
• Таким чином, у існуючому корпусі не вистачає вільного простору, тоді як нещодавно доданий корпус майже порожній

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

Ребалансування даних виконується двома операціями:

• Прибирання сміттєзбірника
• Ремонт на місцевості

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

Прибирання

сміттєзбірникаПрибирання збору сміття (GC) — це запланована діяльність, яка регулярно виконується на DDR (за замовчуванням раз на тиждень проти активного рівня та, за умови ввімкнення рекультивації простору, коли це потрібно проти архівних блоків). Коли він запускається:

• Визначає, які фізичні дані в архівній одиниці рівня є «живими» (використовуються одним або кількома файлами у файловій системі або об'єктами, такими як знімки) або «мертвими» (без посилань на жоден об'єкт, отже, зайвими для системи)
• Визначає контейнери розміром 4,5 МБ, які містять більшість «мертвих» даних у блоку архіву рівня
• Зчитує ці 4,5 Мб контейнери та витягує всі «живі» дані, які вони містять – вони потім «копіюються» до новостворених контейнерів 4,5 Мб, які записуються на всі полиці в архівному блоці рівня
• Видаляє старі контейнери об'ємом 4,5 Мб, отже, видаляє мертві дані, які вони містять, і звільняє місце на диску для повторного використання

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

Як простий приклад:

• Активний ярус DDR містить дві полиці - перша полиця містить 10000 контейнерів 4,5 Мб, а друга полиця містить 100 контейнерів по 4,5 Мб (на кожен контейнер на другій полиці припадає 100 контейнерів на першій полиці)
• GC запускає і копіює пересилає дані з 5000 контейнерів на першій полиці
• Реальні дані в цих 5000 контейнерах призводять до створення 1000 нових контейнерів по 4,5 Мб
• Ці 1000 нових контейнерів по 4,5 Мб написані на обох полицях
• Отже, як тільки GC завершує роботу, перша полиця вміщує 5500 контейнерів по 4,5 МБ, тоді як друга полиця вміщує 600 контейнерів (на кожен контейнер на другій полиці припадає приблизно дев'ять контейнерів на першій полиці)
• За один тираж GC дисбаланс контейнерів між першою та другою полицями зменшився в 10 разів - очікується, що він буде зменшуватися ще більше під час наступних прогонів GC, що означає, що дані перебалансовуються між полицями природним чином з часом

Ремонт на місцевості:

Коли файл записується в DDR, виконуються такі високорівневі операції:

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

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

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

• Перевірте дані, на які посилається файл, у пошуках розділів, де дані не є послідовними на диску (відображає погану локальність)
• Зчитуйте ці непослідовні дані з диска і знову послідовно записуйте їх (у вигляді дублікатів даних) в новостворені контейнери об'ємом 4,5 Мб

Тоді очікується, що стара (непослідовна) копія дублікатів даних буде ідентифікована як «мертва» під час наступного запуску GC і видалена з системи. В результаті:

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

Висновок

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

• Збільште швидкість, з якою дані «відтікають» на DDR
• Збільште обсяг даних, які локально відновлюються на DDR

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