NetWorker: Performanceprobleme bei vProxy-Clone-Jobs im Kapazitätsmodus zwischen Data Domains

• Die vProxy-Klongeschwindigkeit ist von GB/s auf konventionellere und realistischere Geschwindigkeiten gesunken.
• Die Netzwerkbandbreite wurde als Ursache für Engpässe ausgeschlossen und bleibt während des Klonens weit unter dem Schwellenwert.
• Meldungen finden Sie in den ddfs.Infoprotokolle, die sich auf eine oder mehrere *-flat.vmdk-Dateien für die Festplatten der betroffenen VM beziehen, die Folgendes enthalten:
  • synthesized_vbytes 0 und endet mit recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr für basisdatei und endet mit Fehler Datei-Handle ist veraltet.
• Meldungen, die in den Klonaktionsprotokollen gefunden werden (wenn das Klon-Debug-Level 3 oder höher ist), die sich auf eine oder mehrere *-flat.vmdk-Dateien für die Festplatten der betroffenen VM beziehen, die Folgendes enthalten:
  • Synthetische Replikation kann nicht für die Datei verwendet werden ... Pfad.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy nutzt virtuelle synthetische Backups, um die geänderte Blocknachverfolgungs-API von VMware zu nutzen, die enorme Vorteile für Backup- und Klonvorgänge bietet. Dies erfordert die aktive Wartung interner Zuordnungen der VM-Dateisatz heredity auf jeder beteiligten Data Domain. Wenn bei der Vorbereitung des Klons mithilfe virtueller synthetischer Backups Probleme auftreten, führen NetWorker und Data Domain stattdessen ein Failback mithilfe des Standardreplikationsworkflows durch. Dies erfordert die Verarbeitung der gesamten virtuellen Laufwerksdateien und nicht nur der geänderten Blöcke, im Gegensatz zu nur den geänderten Blöcken, die von der VMware API bereitgestellt werden. Selbst wenn letztendlich aufgrund der Deduplizierung nur wenige Daten gesendet werden, kann die Dauer des Klonjobs um mehrere Blöcke zunehmen.
 
Zu den Ursachen, die zum Fehlschlagen der virtuellen synthetischen Nachverfolgung führen können, gehören:

• Verschiedene IP-Adressen, die von NetWorker für die Data Domain-Quell- oder Zielgeräte zwischen Jobs aufgelöst werden – diese müssen für die interne Nachverfolgung virtueller synthetischer Backups konsistent bleiben.
• Ändern von Quell- oder Ziel-Data Domain für vProxy-Backups oder -Clones
• Mehrere Quell- oder Ziel-Volumes für die vProxy-Backups oder -Clones, was zum gleichzeitigen Klonen mehrerer Savesets in der Kette führen kann
• Mehr als ein vProxy-Saveset, das ein Klonen für eine bestimmte VM erfordert, was zu einem isolierten Klonen von Savesets in der Kette führen kann
• VM-Festplatten, die über lange Zeiträume ohne Änderungen laufen (insbesondere Zeiträume, die die Saveset-Aufbewahrungsfristen überschreiten, z. B. 35 Tage ohne Änderung, wobei die Aufbewahrung 30 Tage beträgt)
• Fehler bei Verwendung der Eigenschaft "Chronologische Anordnungsaktion" bei Verwendung von NetWorker 19.6 und höher

Da es zahlreiche potenzielle Ursachen gibt, überprüfen Sie die Data Domain- und NetWorker-Konfigurationen und stellen Sie Folgendes sicher:

• ifgroups sind korrekt für Quell- (Backup) und Zieldatendomänen (Klonziel) eingerichtet.
• NetWorker-Server, Speicher-Nodes und Data Domains verfügen alle über Hostdateieinträge mit den entsprechenden ifgroup-IPs pro Data Domain und zuverlässigem DNS für Clients (bei Bedarf mit NetWorker-Clienthostdateien).
• Einzelne Data Domain für jeden Backup- und Clone-Pool.

Bei Verwendung von NetWorker 19.5 oder niedriger:

• Stellen Sie sicher, dass Clone-Jobs seriell und in der Reihenfolge der Backups durchgeführt werden. Beachten Sie, dass dies nicht gesteuert werden kann, wenn sich mehrere Clones für eine bestimmte VM in derselben Jobliste befinden (Klonaktion oder nsrclone Saveset-Dateiliste).
• Stellen Sie ein einziges Backup- und Clone-Volume pro Pool sicher, um gleichzeitiges Klonen zu vermeiden, wenn mehrere Volumes für die Quelle verfügbar sind.

Ab NetWorker 19.6 sollten Sie immer die Chronologische Reihenfolge-Funktion für vProxy-Saveset-Clone-Aktionen aktivieren, die in der Benutzeroberfläche ausgeblendet werden können:

• Wenn Sie den Befehl nsrclone verwenden, verwenden Sie den Switch -O, um diese neue Funktion durchzusetzen, wenn Sie eine Saveset-Liste mit mehreren Savesets in der Kette eines bestimmten Clients verwenden.
• Um in policy zu aktivieren, verwenden Sie einen der folgenden beiden Befehle:

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

  • Gehen Sie in der Eingabeaufforderung nsradmin wie folgt vor:

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

    • update Chronological order: Yes

      
       
• Sobald dies abgeschlossen ist, werden die zuvor erwähnten Einschränkungen für Einzelne-Source- und Ziel-Volumes sowie inkrementelle Multiinstanzen pro VM-Client aufgehoben und können ordnungsgemäß verarbeitet werden.

WICHTIG: Einige Bedingungen können für NetWorker und Data Domain wiederhergestellt werden, bei denen Savesets außerhalb der Bestellung geklont werden. Dies führt dazu, dass einige NICHT in der Lage sind, VSR für die Replikation zu verwenden, aber sobald die gesamte Kette wiederhergestellt ist, kann das VSR-Klonen ohne Probleme fortgesetzt werden. In der Regel können Klonen außerhalb der Bestellung, Klonen mit mehreren Volumes und Multi-Savesets aufholen und in den regulären Betrieb zurückkehren.
 
Wenn jedoch mehrere Data Domain-IP-Adressen bereits verwendet wurden oder die Data Domain-Quelle oder das Data Domain-Ziel vollständig geändert wurden, besteht die einzige Möglichkeit, zu einer regulären und konsistenten VSR-Optimierung zurückzukehren, darin, ein neues komplettes Backup der betroffenen VMs zu erzwingen, um die Changed Block Tracking- und VSR-Optimierung zurückzusetzen. Dies sollte berücksichtigt werden, wenn die vorherigen Schritte abgeschlossen wurden, aber die Data Domain- und/oder NetWorker-Protokollierung sowie die Klongeschwindigkeiten weisen darauf hin, dass Performanceprobleme bestehen bleiben.