Data Domain: Was ist Multi Stream Restore (MSR) wie in DDOS 6.2 und höher verfügbar?

MSR ist standardmäßig auf anwendbaren DDOS-Versionen und DD/DDVE-Geräten aktiviert, wie oben aufgelistet. Es funktioniert ohne Konfigurations- oder Tuninganforderungen und funktioniert transparent (weder der Administrator noch die Backupanwendung müssen etwas außerhalb des DDOS ändern, damit MSR funktioniert).
  Wenn sich herausstellt, dass MSR für DD unterstützt, aber standardmäßig deaktiviert ist und der jeweilige Workload davon profitieren würde, wenden Sie sich an den Dell Data Domain-Support, um Unterstützung zu erhalten.

MSR funktioniert nur für sequenzielle Lesevorgänge für Dateien, die größer als 8 GiB sind, und erst, nachdem mindestens 500 MiB der Datei zu Beginn gelesen wurden. Dies ist die Menge der Daten, die die internen Heuristics verarbeiten müssen, um festzustellen, ob MSR auf den laufenden Lesevorgang anwendbar ist oder nicht. Die Anzahl der parallelen Lesethreads, in die ein einzelner externer Dateilesevorgang umgewandelt wird, hängt von der DD/DDVE-Hardware ab, wobei die Werte von 4 und 8 Threads typisch sind.

Diese und andere Werte können in gewissem Umfang konfiguriert werden, jedoch nur durch vorherige Beratung und Analyse durch den Data Domain-Support von Fall zu Fall.

Multi Stream Restore (MSR) ist eine Funktion, die physischen DDs ab DDOS 6.2, zu lokalen DDVEs ab DDOS 7.0 und zu externen DDVEs (Active Tier on Object Store, ATOS) ab DDOS 7.2 hinzugefügt wurde.

Der Zweck dieser Funktion besteht darin, Leselasten (beide Lesevorgänge aus dem aktiven Tier, z. B. Wiederherstellungen und Cloud-Tier, für Dateirückrufe) für größere Dateien zu beschleunigen, sodass DD intern die Datei liest, indem mehrere Threads parallel verwendet werden. dadurch die Daten schneller an die Backupanwendung zurücksenden, als wenn die Datei durch einen einzigen sequenziellen Prozess gelesen wurde.

N. z.

Wenn ein Single-Stream-Lesevorgang für eine Datei im DD FS-Prozess eintrifft, treten die Heuristics für MSR ein und warten, bis der Lesevorgang fortgesetzt wird, um festzustellen, ob:     

• Die Datei ist größer als das Minimum (standardmäßig 8 GiB).
• Wenn mindestens 500 MiB der Datei sequenziell gelesen wurden (nicht sequenzielle Lese-/Wiederherstellungsvorgänge sind nicht für MSR qualifiziert)
• Wenn das System nicht genug geladen ist, damit MSR zusätzliche Subthreads erzeugt, die die Performance nicht gefährden

Wenn dies der Fall ist, erstellt der FS-Prozess intern eine Reihe von Streams (in der Regel 4 oder 8) für nicht überlappende Datei-Offsets, die parallel aus der Datei lesen, sodass der externe Stream (der von der Backupanwendung verwendet wird, um den Dateilesevorgang vom DD anzufordern) sequenziell mit Daten gespeist wird, theoretisch mit einer viel schnelleren Geschwindigkeit als wenn der Lesevorgang mit einem einzigen internen Stream erfolgt wäre.

Während der Lebensdauer des externen Lesevorgangs können interne Threads das Lesen von ihren vorab zugewiesenen Offsets abschließen und weiter zu denen in der zu lesenden Datei wechseln. Darüber hinaus überwacht MSR kontinuierlich die Systemlast und Leseaktivität in der Datei, sodass, wenn entweder die Dateilesevorgänge anhalten oder die Systemlast höher ist, die internen Threads heruntergefahren werden können und die Datei mit dem einzelnen externen Thread gelesen bleibt, den sie auf einem Nicht-MSR-System hatte.

Es gibt keine CLI-Abschnitte in der GUI oder Statistiken, die in täglichen ASUPs für MSR gedruckt werden, da diese pro Dateilesevorgang und kurzlebig sind. Ein Benutzer kann den Inhalt der Protokolldatei "ddfs.info" ("log view debug/ddfs.info" von der CLI) auf Übereinstimmungen für "MSR" und "_msr" überprüfen, um einige Chatter über MSR anzuzeigen, die für einzelne Dateien verwendet werden. Es kann etwas ähnliches wie unten (und viele zusätzliche Chatter) angezeigt werden, wenn MSR für eine Datei startet, die gelesen wird:     
 
Schließlich wird MSR nicht mehr verwendet (Datei wird nicht mehr gelesen, Datei geschlossen), kann aber auch aufgrund von nicht sequenziellen Lesevorgängen oder sogar aufgrund der Systemlast auftreten. In diesem Fall wird in den Protokollen möglicherweise etwas ähnliches wie das folgende angezeigt: