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

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

Este artículo se aplica a Este artículo no se aplica a Este artículo no está vinculado a ningún producto específico. No se identifican todas las versiones del producto en este artículo.

Síntomas

  • Швидкість клонування 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

Causa

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

Resolución

Оскільки існує багато потенційних причин, перегляньте конфігурації домену даних і 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 та швидкості клонування свідчать про те, що проблеми з продуктивністю залишаються.

Productos afectados

NetWorker Family, Data Domain Replicator

Productos

NetWorker Family, NetWorker
Propiedades del artículo
Número del artículo: 000205098
Tipo de artículo: Solution
Última modificación: 06 abr 2026
Versión:  7
Encuentre respuestas a sus preguntas de otros usuarios de Dell
Servicios de soporte
Compruebe si el dispositivo está cubierto por los servicios de soporte.