NetWorker: Режим ємності vProxy клон проблеми продуктивності між доменами даних

• Швидкість клонування vProxy впала з ГБ/с до більш звичайних і реалістичних швидкостей.
• Пропускна здатність мережі виключена як причина вузького місця, залишаючись значно нижче порогового значення під час клонування.
• Повідомлення знаходяться в ddfs.інформаційні журнали, що посилаються на один або декілька файлів *-flat.vmdk для відповідних дисків віртуальної машини, що містять:
  • synthesized_vbytes 0 і закінчується recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr для базового файлу і закінчується помилкою Дескриптор файлу застарілий.
• Повідомлення, знайдені в журналах дій клонування (коли рівень налагодження клонів 3 або вище), що посилаються на один або кілька файлів *-flat.vmdk для дисків відповідної віртуальної машини, що містять:
  • Синтетична реплікація не може бути використана для файлу ... шлях.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy використовує віртуальну синтетику для використання зміненого API відстеження блоків VMware, забезпечуючи величезні переваги як для операцій резервного копіювання, так і для клонування. Це вимагає активного підтримання внутрішніх асоціацій спадковості набору файлів віртуальних машин на кожному задіяному домені даних. Якщо під час підготовки до клонування за допомогою віртуальної синтетики виникають проблеми, NetWorker і Data Domain замість цього не повертаються до використання робочого процесу реплікації за замовчуванням. Це вимагає обробки всіх файлів віртуального диска, а не тільки змінених блоків, а не тільки змінених блоків, наданих API VMware - і навіть якщо в кінцевому підсумку через дедуплікації надсилається мало даних, тривалість завдання клонування може збільшитися в рази.
 
Причини, які можуть призвести до збою віртуального синтетичного відстеження, включають:

• Різні IP-адреси, які розпізнаються NetWorker для пристроїв вихідного або кінцевого домену даних між завданнями - вони повинні залишатися узгодженими для внутрішнього відстеження віртуальної синтетики
• Зміна домену вихідних або кінцевих даних для резервного копіювання або клонів vProxy
• Кілька вихідних або цільових томів для резервних копій або клонів vProxy, що може призвести до одночасного клонування декількох наборів збережень у ланцюжку
• Більше одного набору збереження vProxy, що вимагає клонування для даної віртуальної машини, що може призвести до невпорядкованого клонування наборів збережень у ланцюжку
• Диски віртуальних машин, які йдуть протягом тривалого періоду без будь-яких змін (зокрема, періоди, які перевищують встановлені терміни зберігання, наприклад, 35 днів без змін, коли зберігання становить 30 днів)
• Неможливість використання властивості ChronologicalOrder Action (Дія хронологічного порядку) у разі використання програми NetWorker 19.6 або новішої версії

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

• ifgroups правильно налаштовано як для вихідного (резервного), так і для цільового (цільового клонування) доменів даних
• Сервер NetWorker, вузли зберігання та домени даних мають записи файлів хостів, використовуючи відповідні IP-адреси ifgroup для кожного домену даних, і надійний DNS для клієнтів (використовуючи файли хостів клієнта NetWorker за потреби).
• Єдиний домен даних для кожного резервного копіювання та пулу клонування.

У разі використання NetWorker 19.5 або старішої версії:

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

Починаючи з NetWorker 19.6, ви завжди повинні вмикати функцію ChronologicalOrder для дій клонів vProxy saveset, які можуть бути приховані в інтерфейсі користувача:

• Якщо використовується команда nsrclone, використовуйте перемикач -O, щоб застосувати цю нову функцію під час використання списку збереження з кількома наборами збережень у певному ланцюжку клієнта
• Щоб увімкнути політику, скористайтеся однією з наступних двох команд:

  • nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] 

  • У nsradmin підказують:

    • . type nsr protection policy action; policy name: policy; workflow: workflow: name: action

    • update Chronological order: Yes

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

ВАЖЛИВИЙ: Деякі умови можуть бути можливими для відновлення NetWorker і Data Domain, де набори збереження клонуються не в порядку. Це призводить до того, що деякі не можуть використовувати VSR для реплікації, але як тільки весь ланцюжок буде відновлений, клонування VSR може продовжитися без проблем. Як правило, позачергове клонування, багатотомне та багатозбережене клонування може наздогнати та повернутися до звичайної роботи.
 
Однак, у випадку, якщо кілька IP-адрес домену даних вже були використані або повністю змінили джерело або призначення домену даних, єдиний спосіб повернутися до регулярної та послідовної оптимізації VSR - це примусово створити нову повну резервну копію постраждалих віртуальних машин, щоб скинути змінене відстеження блоків та відновити оптимізацію VSR. Це слід враховувати, коли попередні кроки були виконані, але журналювання Data Domain і / або NetWorker, а також швидкість клонування вказують на те, що проблеми з продуктивністю залишаються.