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

• Die Geschwindigkeit des vProxy-Cloning ist von GB/s auf konventionellere und realistischere Geschwindigkeiten gesunken.
• Die Netzwerkbandbreite wird als Ursache des Engpasses ausgeschlossen und bleibt während des Klonens deutlich unter dem Schwellenwert.
• Meldungen befinden sich im DDFS.Info-Protokolle, die sich auf ein oder mehrere *-flat.vmdk Dateien für die betroffene VM-Festplatte (virtuelle Maschine), die Folgendes enthalten:
  • synthesized_vbytes 0 und endend mit recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr für die Basisdatei und endet mit dem Fehler Dateihandle ist veraltet.
• In den Klonaktionsprotokollen gefundene Meldungen (wenn das Clone-Debug-Level 3 oder höher ist) beziehen sich auf eine oder mehrere *-flat.vmdk-Dateien für die Festplatten der betroffenen VM, die Folgendes enthalten:
  • Synthetische Replikation kann nicht für die Datei verwendet werden ... Pfad.../VM-VM-Nummer-Festplatte-Schlüssel-Laufwerknummer-flach.vmdk

vProxy verwendet virtuelle synthetische Funktionen, um die geänderte Blockverfolgungs-API von VMware zu nutzen, was enorme Vorteile sowohl für Backup- als auch für Klonvorgänge bietet. Dies erfordert eine aktive Wartung der internen Zuordnungen der VM-Dateisatzvererbung auf jeder beteiligten Data Domain. Wenn bei der Vorbereitung auf das Klonen mit virtuellen synthetischen Backups Probleme auftreten, führen NetWorker und Data Domain stattdessen ein Failback auf den standardmäßigen Replikationsworkflow durch. Dies erfordert die Verarbeitung der gesamten Dateien des virtuellen Laufwerks 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 aufgrund der Deduplizierung letztlich nur wenige Daten gesendet werden, kann sich die Dauer des Cloningjobs um ein Vielfaches erhöhen.
 
Zu den Ursachen, die zum Ausfall des virtuellen synthetischen Trackings führen können, gehören:

• Unterschiedliche IP-Adressen, die in NetWorker für die Data Domain-Quell- oder -Zielgeräte zwischen Jobs aufgelöst werden. Diese müssen für die interne Nachverfolgung von virtuellen Kunststoffen konsistent bleiben.
• Ändern der 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 erfordert Cloning für eine bestimmte VM, was zu einem ungeordneten Cloning von Savesets in der Kette führen kann
• VM-Festplatten, die über lange Zeiträume ohne Änderungen genutzt werden (insbesondere Zeiträume, die die Saveset-Aufbewahrungsfristen überschreiten, z. B. 35 Tage ohne Änderung, bei denen die Aufbewahrung 30 Tage beträgt)
• Nichtverwendung der Eigenschaft "ChronologicalOrder Action"

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

• ifgroups sind sowohl für Quell- (Backup) als auch Ziel- (Clone-Ziel) Data Domains ordnungsgemäß eingerichtet.
• NetWorker-Server, Storage Nodes und Data Domains verfügen alle über Hostdateieinträge mit den entsprechenden ifgroup IPs pro Data Domain und zuverlässiges DNS für Clients (bei Bedarf werden Dateien vom NetWorker-Client gehostet).
• Einzelne Data Domain für jeden Backup- und Clone-Pool.

Aktivieren Sie die Funktion "ChronologicalOrder" für vProxy-Saveset-Klonaktionen, die möglicherweise in der Benutzeroberfläche ausgeblendet sind:

• Bei Verwendung von nsrclone verwenden Sie den Befehl -O Switch, um diese neue Funktion zu erzwingen, wenn eine Saveset-Liste mit mehreren Savesets in der Kette eines bestimmten Clients verwendet wird
• Verwenden Sie zum Aktivieren in der Richtlinie einen der beiden folgenden Befehle:

nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] <yes|no>

• In der Eingabeaufforderung von nsradmin:

. 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 Quell- und Ziel-Volumes sowie für inkrementelle Multi-Instanz-Volumes pro VM-Client aufgehoben und können ordnungsgemäß verarbeitet werden.

WICHTIG: Es kann einige Bedingungen geben, unter denen NetWorker und Data Domain wiederherstellen können, wenn Savesets nicht in der richtigen Reihenfolge 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-Cloning ohne Probleme fortgesetzt werden. Im Allgemeinen kann das Klonen in falscher Reihenfolge sowie das Klonen mehrerer Volumes und Savesets aufholen und zum regulären Betrieb zurückkehren.
 
Wenn bereits mehrere Data Domain-IP-Adressen verwendet wurden oder sich die Data Domain-Quelle oder das Data Domain-Ziel vollständig ändern, besteht die einzige Möglichkeit, zur regulären und konsistenten VSR-Optimierung zurückzukehren, darin, ein neues komplettes Backup der betroffenen VMs zu erzwingen, um die geänderte Blocknachverfolgung zurückzusetzen und die VSR-Optimierung wiederherzustellen. Dies sollte in Betracht gezogen werden, wenn die vorherigen Schritte abgeschlossen sind, aber die Data Domain- und/oder NetWorker-Protokollierung und die Cloning-Geschwindigkeiten darauf hindeuten, dass Performanceprobleme weiterhin bestehen.