NetWorker: Optimieren von Speicherplatz-Recovery-Vorgängen für Data Domain

• NetWorker-Savesets, die als abgelaufen markiert, aber nicht entfernt wurden
• Meldungen zur Speicherplatzwiederherstellung werden mehr als einmal pro Tag in Protokollen angezeigt
• Data Domain-Geschwindigkeit und -Lastauswirkungen
• Allgemeine Auswirkungen auf die Serverleistung

• Volumes, die für die Speicherplatzwiederherstellung berechtigt sind, werden während der Ablaufaktion (Staging, Cloning oder Wiederherstellung) gelesen.
• Die Speicherplatzwiederherstellung wird standardmäßig nach jedem Staging-Vorgang auf einem bestimmten Volume ausgeführt
• Bei der Speicherplatz-Recovery wird jede Datei in einer Volume-Verzeichnisstruktur überprüft, wenn eine Speicherplatz-Recovery ausgeführt wird
• Servervorgänge und -reaktionsgeschwindigkeit können sich während der Speicherplatzwiederherstellungsphase verlangsamen

Die Speicherplatzwiederherstellungsphase von NetWorker wird einmal täglich als eine der letzten Phasen der Ablaufaktion im Serverbackupworkflow ausgeführt. Es ist beabsichtigt, Saveset-Dateiobjekte innerhalb eines Volumes nach der Bewertung, dem Ablauf und dem Löschen von Saveset-Datensätzen durch den Server zu löschen, nachdem die Objekte berechnet wurden, die gemäß ihrer Konfiguration sicher entfernt werden können.

Es gibt mehrere Faktoren, die sich negativ auf die Reaktionsgeschwindigkeit des Data Domain- oder NetWorker-Servers auswirken können. Aktivieren Sie eine der folgenden Optionen, die den Anforderungen der betreffenden Datenzone zu entsprechen scheinen. Bevor Sie den Test mit den folgenden Debug-Keyfiles in Betracht ziehen: Deaktivieren Sie die tägliche Serverschutzserver-Backupablaufaktion >>, um alle Berechnungen der Speicherplatzwiederherstellung und der Mediendatenbank für einen oder mehrere Tage zu deaktivieren und zu bestätigen, dass die aufgetretenen Performanceprobleme im Zusammenhang mit Speicherplatzwiederherstellungs- und/oder Ablaufaktivitäten stehen.

Wenn durch das Deaktivieren von Expiration das Problem im Zusammenhang mit der täglichen Wartung bestätigt wird, können die folgenden Funktionen für das Troubleshooting deaktiviert werden, indem eine leere Datei mit demselben Namen (ohne Erweiterung) auf dem NetWorker-Server oder Node im Unterverzeichnis debug des nsr-Hauptverzeichnisseserstellt wird. Keine dieser Flag-Dateien erfordert einen Neustart und wird mit Jobs zur Speicherplatzwiederherstellung wirksam, die gestartet werden, während sie vorhanden sind.

Linux-Speicherort: /nsr/debug
Windows-Speicherort: C:\Program Files\EMC NetWorker\nsr\debug (oder entsprechender NSR-Installationspfad)
 

Die Dateinamen und ihre Funktionen sind im Folgenden aufgeführt:

skip_recover_space_for_stage

• Speicher-Nodes. Diese Markierung bewirkt, dass NetWorker die Phase der Speicherplatzwiederherstellung eines Staging-Vorgangs (Klonen gefolgt von Löschen der Quelle) überspringt. Wenn in Ihrer Umgebung Staging verwendet wird, insbesondere Staging von denselben Quell-Volumes wiederholt, wird dies empfohlen, da dadurch die Möglichkeit des Erzeugens mehrerer Speicherplatzwiederherstellungsvorgänge für dieselben Volumes aufgehoben wird. Wenn diese Markierung vorhanden ist, wird der Vorgang zur Speicherplatzwiederherstellung vollständig zurückgestellt, sodass das System die Dateien löschen kann, wenn die tägliche Ablaufaktion ausgeführt oder der Befehl nsrimmanuell ausgeführt wird. 

recover_space_anytime

• Nur Server. Auf diese Weise kann Speicherplatz wiederhergestellt und Savesets auf Volumes entfernt werden, die aktiv lesen, was standardmäßig zurückgestellt ist. Das bedeutet, dass bei Volumes mit lang andauernden Clone-Jobs der Ablauf und die Speicherplatz-Recovery wiederholt verschoben werden können, wenn die Ablaufaktion, nsrim oder ein Staging-Job (siehe vorherige) ausgeführt wird. Dies wiederum kann zu großen Speicherplatzrückständen, einer allmählichen Erschöpfung des freien Speicherplatzes und einem größeren Speicherplatzwiederherstellungsjob führen, wenn er ausgeführt werden darf. 

skip_disk_usage

• Speicher-Nodes. Im Rahmen der Speicherplatzwiederherstellung und der Überprüfung des Festplatten-Volume-Dateisystems werden einzelne Dateien standardmäßig rekursiv geprüft und gezählt, um ein präzises Aggregat von Daten für das Volume zu erzeugen. Einige mögen diese Genauigkeit als unerlässlich erachten, aber die Verschiebung dieses Schritts hängt von den Datensätzen der NetWorker-Mediendatenbank für die Datei- und Bytesummen ab, von denen in der Regel erwartet werden kann, dass sie für die meisten Verwendungszwecke genau genug sind. In einer stark belasteten Data Domain, insbesondere in einer Domain, in der viele Speicherplatzwiederherstellungsvorgänge für Volumes wiederholt ausgeführt werden, kann dies als unnötiger Aufwand betrachtet und sicher deaktiviert werden.

skip_consistency_check_in_recover_space

• Speicher-Nodes. Während der Speicherplatzwiederherstellung für ein Volume wird das Volume-Dateisystem Datei für Datei geprüft, um die Konsistenz zwischen der Mediendatenbank sicherzustellen. Dies kann auch zu Latenz führen. Das Hinzufügen dieser Schlüsseldatei zu jedem Node verhindert, dass dieser Node Saveset-Dateien löscht, wenn ein entsprechender Datensatz in der Mediendatenbank nicht vorhanden ist, oder Mediendatenbankdatensätze, bei denen keine Datei gefunden wird, als "verdächtig" markiert. Beachten Sie, dass dies die normalen Bereinigungsvorgänge verhindert und verwendet werden sollte, um die Latenz im Zusammenhang mit Speicherplatzwiederherstellungsvorgängen zu qualifizieren, und nicht längerfristig deaktiviert werden sollte. 

Standardmäßig wurde eine ausführlichere Protokollierung eingeführt, wodurch die gesamten Saveset-Pfade in den data_audit Protokollen auf dem NetWorker-Server protokolliert werden. Bei bereits hoher Auslastung und vielen/großen Speicherplatz-Recovery-Jobs kann dies zu einer Nichtreaktion führen, insbesondere bei Storage Nodes, die die Informationen remote an NetWorker zurückgeben. Um dies zu deaktivieren, erhöhen Sie den Protokollierungsschwellenwert für diese Protokolle auf dem NetWorker-Server:

# nsradmin
# nsradmin> show name; auditlog severity
# print type: nsr auditlog

Schränken Sie diese Änderung bei Bedarf so ein, dass sie sich nur auf das Datenaudit auswirkt, indem Sie die Abfrage auf die spezifische Instanz eingrenzen, indem Sie ihren Namen angeben. Überspringen Sie diesen Schritt, um die Einstellung auf jeden erneut anzuwenden:

# print type: nsr auditlog; name: servername_data_audit.raw

Ändern Sie den Schwellenwert auf eins oder beide auf "Fehler", um die Protokollierung der einzelnen Löschvorgänge einzustellen – Löschvorgänge werden weiterhin im daemon.raw des Servers protokolliert.

# update auditlog severity: Error