Домен даних: Практичні поради щодо міграції даних у системах домену даних PowerProtect за допомогою реплікації mtree
Summary: У цій статті обговорюється підготовка до міграції даних за допомогою реплікації Mtree (MRepl) із застарілих систем домену даних PowerProtect (PPDD) без підтримки внутрішніх карток QAT. Наприклад, DD9500 і DD9800. Важливо враховувати поточне робоче навантаження на роботу системи, щоб уникнути несподіваних побічних ефектів, які можуть негативно вплинути на результати міграції даних. Ця стаття допомагає спланувати операції міграції, які потребують нової конфігурації контексту реплікації Mtree Replication (MRepl) з використанням застарілих систем PPDD як джерела. ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
З впровадженням платформ 16G міграція конкретних MTrees із застарілого PPDD на новішу систему стала звичайною вимогою.
Процес міграції створює нові контексти реплікації Mtree. Враховуйте наступне, щоб забезпечити мінімальні збої.
- Поточне навантаження системи від операцій резервного копіювання
- Відмінності в можливостях стиснення (наприклад, підтримка карт QAT)
- Раптове включення нових контекстних конфігурацій Mrepl
- Помилки апаратного забезпечення, що впливають на процес збирання сміття (GC)
Щоб зберегти цілісність даних і відповідати угодам про рівень обслуговування, система може панікувати через певні експлуатаційні пороги.
Механізм паніки запускає дії самокорекції, щоб система завжди працювала надійно.
У цій статті обговорюються ці міркування та інструкції щодо запобігання несподіваним простоям, які можуть перешкодити планам міграції.
Поточне навантаження системи від операцій резервного копіювання:
Спочатку зосередьтеся на поточних операціях системи. Перед міграцією слідкуйте за ключовими показниками. До них відносяться поточні робочі навантаження, завантаження процесора, використання пам'яті, стан мережі та оповіщення про обладнання.
Мета полягає в збереженні роботи системи в межах нормальних параметрів.
Відмінності в можливостях стиснення:
Під час підготовки до міграції за допомогою реплікації Mtree (Mrepl) враховуйте різницю в можливостях стиснення між системами.
У деяких застарілих системах відсутня вбудована плата стиснення, яка б допомагала виконувати операції, пов'язані зі стисненням.
Системи DD9900, DD9400 або DD6900 дозволяють підключати зовнішню карту QAT для прискорення операцій стиснення.
Коли карта QAT відсутня (наприклад, DD9800, DD9500), вона покладається на ресурси процесора та пам'яті для завдань стиснення та декомпресії.
При налаштуванні нових контекстів реплікації без підтримки QAT, дані спочатку повинні бути розпаковані.
Це може призвести до різкого зростання використання ЦП на етапі ініціалізації реплікації.
Джерело перевіряє місце призначення, щоб визначити тип доступної компресійної карти.
Якщо місцем призначення є система 16G (DD9910, DD9410 або DD6410), джерело має розпаковувати дані із застарілого формату 'gzfast'. Потім він повинен стиснути його до формату LZ.
Поступово впроваджуйте нову конфігурацію контексту mrepl:
Під час аварійного відновлення (DR) під час реплікації даних з одного домену даних до іншого завдання реплікації зазвичай починаються після завершення прийому даних.
Це гарантує, що цільовий сайт отримує всі репліковані дані.
Коли для міграції визначаються нові контексти реплікації, джерело має обробляти значну кількість даних під час ініціалізації реплікації.
Це пов'язано з тим, що в пункті призначення відсутні дедупліковані дані, а оптимізація поки що неможлива. Це призводить до підвищеного навантаження на систему джерела.
Щоб пом'якшити це, коли система продовжує обробляти робочі навантаження резервного копіювання (I/O), поступово включайте контексти реплікації, пов'язані з міграцією.
Визначте низьку пропускну здатність реплікації, щоб обмежити ресурси, виділені для цих контекстів реплікації, пов'язаних з міграцією.
Як тільки реплікація почне будувати оптимізацію на місці призначення та робочі параметри будуть перевірені, додайте більше контекстів реплікації (міграції). Або змінити пропускну здатність реплікації на існуючих.
Мета полягає в тому, щоб уникнути спрацьовування захисних механізмів системи. Це призводить до системної паніки, що може вплинути на міграції.
Пам'ятайте, що посилання на продуктивність системи розраховуються на основі робочих навантажень у роботі, а не для нових робочих навантажень.
Поступово налаштовуйте троттлінг під час сценаріїв міграції.
Команду "replication throttle add" можна використовувати для планування конкретного моменту часу та виділення визначеної пропускної здатності (у Мбіт/с) для регулювання.
Ініціюйте нові завдання реплікації з обмеженою доступною пропускною здатністю (нижня дросельна заслінка). Потім оцініть вплив на роботу системи.
Після виконання роботи з реплікації дросельну заслінку можна збільшити, щоб забезпечити додаткову пропускну здатність.
Також рекомендується контролювати аналітику системи, включаючи споживання процесора, пам'яті та мережі, доступну на DDSM.
Помилки апаратного забезпечення, що впливають на процес збору сміття (GC):
Ще один фактор, який потенційно може спричинити зниження продуктивності резервного копіювання або реплікації, пов'язаний з апаратними збоями, особливо під час операцій зі збору сміття за замовчуванням. За нормальних умов експлуатації механізм збору сміття в системах PPDD завершує діяльність з переробки простору, не впливаючи на операції з поглинання, відновлення або реплікації. У певних ситуаціях система пропонує опції для визначення регулювання збору сміття, надаючи системним адміністраторам додатковий контроль над тим, коли відбуваються процеси очищення системи.
Конфігурація дросельної заслінки за замовчуванням для збору сміття не впливає на резервне копіювання та відновлення. Більшість випадків, коли спостерігається зіткнення, пов'язані з апаратними збоями. Наприклад, коли певні диски потребують заміни, поточні вимоги системи до вводу/виводу можуть уповільнити зберігання резервних копій і відновлень, що отже, вплине на загальні операції GC.
Операційна система Data Domain надає комплексні механізми оповіщення про такі проблеми з обладнанням, завчасно викликаючи сповіщення при виявленні цих станів. Це допомагає операторам резервного копіювання оперативно вирішувати проблеми, пов'язані з обладнанням.
Ще одним важливим фактором, який слід враховувати, є те, що дії реплікації не менш важливі, ніж резервне копіювання та відновлення. За своєю конструкцією, кожна платформа надає фіксовану кількість потоків для кожного завдання та може обробляти паралельні операції у визначених межах, щоб відповідати угодам про рівень обслуговування (SLA).
Висновок:
Успішна міграція даних за допомогою реплікації Mtree вимагає ретельного розгляду наступного;
- Моніторинг поточного навантаження системи від операцій резервного копіювання
- Розуміння застарілих платформ, таких як DD9800 або DD9500
- Використовуйте інший алгоритм стиснення (gzfast).
- Коли на працюючій системі створюються нові контексти реплікації MTree (MRepl), поступово включайте нові конфігурації контексту Mrepl
- Уважно стежте за впливом нових робочих навантажень на систему.
- Слідкуйте за потенційними апаратними помилками (які впливають на операції процесу збирання сміття).
Дотримуючись цих найкращих практик, можна мінімізувати збої та підтримувати стабільність системи.
Впровадження цих рекомендацій допомагає уникнути несподіваних простоїв і полегшує міграцію даних.
Additional Information
Affected Products
Data DomainArticle Properties
Article Number: 000317549
Article Type: How To
Last Modified: 08 May 2025
Version: 1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.