NetWorker: Проблеми продуктивності завдань клонів Capacity Mode vProxy між доменами даних

Résumé: Використовуйте цю статтю, щоб допомогти ізолювати та усунути проблеми з продуктивністю клонування vProxy між двома доменами даних.

Cet article concerne Cet article ne concerne pas Cet article n’est associé à aucun produit spécifique. Toutes les versions du produit ne sont pas identifiées dans cet article.

Symptômes

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

Cause

vProxy використовує віртуальні синтетичні елементи для використання зміненого API блочного відстеження VMware, що забезпечує величезні переваги як для резервного, так і для клонування. Це вимагає активного підтримки внутрішніх асоціацій спадковості набору файлів VM у кожному задіяному домені даних. Якщо виникають проблеми під час підготовки до клонування за допомогою віртуальних синтетичних матеріалів, NetWorker і Data Domain натомість повертаються до використання стандартного робочого процесу реплікації. Це вимагає обробки всіх файлів віртуального диска, а не лише змінених блоків, на відміну від лише змінених блоків, які надає VMware API. Навіть якщо через дедуплікацію надсилається мало даних, тривалість завдання клонування може збільшуватися в кілька разів.
 
Причини, які можуть призвести до збоїв віртуального синтетичного відстеження, включають:
  • Різні IP-адреси, які розв'язуються в NetWorker для пристроїв домену даних між завданнями. Вони мають залишатися послідовними для внутрішнього відстеження віртуальних синтетичних пристроїв
  • Зміна домену даних джерела або призначення для резервних копій або клонів vProxy
  • Декілька джерел або цільових томів для резервних копій або клонів vProxy, що може призвести до одночасного клонування кількох наборів збережень у ланцюжку
  • Більше ніж один vProxy saveset, який вимагає клонування для певної віртуальної машини, що може призвести до безладного клонування наборів збережень у ланцюгу
  • VM-диски, які зберігаються протягом тривалих періодів без змін (особливо періоди, що перевищують період збереження, наприклад, 35 днів без змін, де збереження становить 30 днів)
  • Невикористання властивості ChronologicalOrder Action

Résolution

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

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

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

  • Якщо використовуєте nsrclone Використати команду -O Switch для забезпечення цієї нової функції при використанні списку наборів збережень із кількома наборами збережень у ланцюжку клієнта
  • Щоб увімкнути політику, використовуйте одну з наступних двох команд:
nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] <yes|no>
  • У запиті nsradmin:
. type nsr protection policy action; policy name: policy; workflow: workflow: name: action
update Chronological order: Yes
  • Після цього вже згадані обмеження щодо окремих джерел і цільових томів, а також багатоекземплярних інкрементів для кожного VM-клієнта, знімаються і можуть бути належно оброблені.

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

Produits concernés

NetWorker Family, Data Domain Replicator

Produits

NetWorker Family, NetWorker
Propriétés de l’article
Numéro d’article: 000205098
Type d’article: Solution
Dernière modification: 06 Apr 2026
Version:  7
Trouvez des réponses à vos questions auprès d’autres utilisateurs Dell
Services de support
Vérifiez si votre appareil est couvert par les services de support.