Data Domain: Best Practices für die Verzeichnis- und Poolreplikation

Best Practices für die Verzeichnisreplikation

Zweck

In diesem Artikel werden Best Practices für die Konfiguration der Verzeichnisreplikation definiert.

GILT FÜR

• Alle Data Domain-Systeme
• Alle Softwareversionen

EMPFEHLUNGEN

1. Verteilen Sie die Workload auf so viele Kontexte wie möglich.
   Der ideale Durchsatz für vorkomprimierte Einzelkontexte liegt im Bereich von 200 bis 300 MB/s. In Konfigurationen, in denen Multistreaming verfügbar ist, ähnelt die ideale Einzelkontextleistung der idealen Multikontextleistung. Es gibt jedoch mehrere Variablen, die die Effektivität von Multistreaming einschränken:

   • Wenn der Quell-DDR über viele Replikationskontexte verfügt, begrenzt die Logik zum Aufteilen von Multistreamstreams auf Kontexte die verfügbare Anzahl von Streams.
   • Multistreaming ist während der Snapshot-basierten Initialisierung/Wiederherstellung nicht aktiv. Standardmäßig ist eine Snapshot-basierte Initialisierung wirksam, wenn der Quellkontext mehr als 1 Million Einträge aufweist.
   • Ab Version 5.0 wurde Multistreaming für die Replikation von CIFS-Daten eingeführt.

   Der ideale multikontextbezogene vorkomprimierte Durchsatz nach Modell variiert zwischen etwa 200 MB/s und 500 MB/s oder mehr.

2. Entwerfen Sie die Workload mit Dateien mittlerer Größe.
   Die Dateigröße kann erhebliche Auswirkungen auf die Gesamtperformance eines Replikationskontexts haben. Im Allgemeinen können Dateien mit einer Größe von weniger als 10 MB nicht effizient repliziert werden.

   Wenn ein Replikationspaar nach einer unerwarteten Trennung erneut eine Verbindung herstellt, muss die Quelle außerdem vom Anfang der Datei neu gestartet werden, die während der Trennung repliziert wurde. Wenn die Datei sehr groß ist und es häufig zu Trennungen kommt (z. B. aufgrund eines unzuverlässigen Netzwerks), kann die Replikation effektiv hängen bleiben. Es wird versucht, dieselbe Datei immer wieder zu replizieren. Dies tritt am häufigsten bei Dateien mit einer Größe von mehr als 100 GB auf. Die Dateigröße selbst hat keine Auswirkungen auf die Performance.

3. Entwerfen Sie die Workload so, dass Sie die Vorteile der Replikationsplanung nutzen.
   Dateien werden zur Replikation in die Warteschlange eingereiht, wenn sie intern geschlossen werden. Der Zeitpunkt für das Schließen der Datei ist wie folgt:

   Wenn eine geänderte Datei geschlossen wird, wird ein "Schließen"-Datensatz für das Replikationsprotokoll für die Datei erzeugt. Die Replikation reiht die neuen Daten in der Datei zum Senden in eine Warteschlange. Wenn sich vor ihm keine anderen Replikationsvorgänge in der Warteschlange befinden (d. h. nicht verarbeitete Protokolldatensätze), werden die neuen Daten sofort gesendet. Andernfalls wird die Datei repliziert, nachdem vorherige Protokolldatensätze verarbeitet wurden.

   • 10 Minuten nach dem letzten Zugriff schließt NFS die Datei.
   • Alle Dateien werden stündlich geschlossen, unabhängig davon, wie lange sie geschrieben wurden.
   • Wenn auf viele Dateien zugegriffen wird oder diese geschrieben werden, werden Dateien möglicherweise früher geschlossen, als es die obigen Regeln vorschreiben. Backupsoftware, die Dateien in kleineren Fragmenten (z. B. 1 MB) schreibt, kann dazu führen, dass die Replikation aufgrund der Anzahl der erzeugten Dateien früher initiiert wird.

4. Verwenden Sie nach Möglichkeit ein dediziertes Netzwerk.
   Paketverlustraten von nur 0,1 % können den Netzwerkdurchsatz erheblich beeinträchtigen, insbesondere bei Netzwerken mit hoher Bandbreite. Für Netzwerke mit Bandbreite <= T2 bietet RTT (Round Trip Time) bis zu einer Sekunde einen guten Durchsatz. Bei Netzwerken von >= T3 kommt es ab einer RTT von 300–500 ms zu einer signifikanten Durchsatzverschlechterung.

   Allgemeiner ausgedrückt beträgt der Durchsatz bei Paketverlust ungefähr
   Throughput = MSS /(RTT * sqrt(p)) wobei MSS := minimale Segmentgröße (in der Regel 1460 Byte) RTT := Umlaufzeit p := Wahrscheinlichkeit des Paketverlusts

5. Bewerten Sie die Delta-Replikation (Optimierung bei niedriger Bandbreite).
   In DD OS 4.8 und höher kann die Delta-Replikation, auch "Optimierung bei niedriger Bandbreite" genannt, den virtuellen Durchsatz der Verzeichnis- oder Poolreplikation über Links mit weniger als 6 Megabit pro Sekunde (Mbit/s) verfügbarer Bandbreite erhöhen. Die Delta-Replikation verursacht einen erheblichen zusätzlichen CPU- und I/O-Overhead sowohl auf den Data Domain-Quell- als auch auf den Data Domain-Zielsystemen. Wenn die Optimierung bei niedriger Bandbreite für Verbindungen mit einer Bandbreite von mehr als 6 Mbit/s aktiviert ist, ist es unwahrscheinlich, dass ein Gewinn beim virtuellen Durchsatz erzielt wird. Allgemein gesagt, wenn:

   • Die zu replizierenden Daten sind zu weniger als 96 % identisch mit den Daten, die bereits auf dem Zielsystem vorhanden sind.
   • Die verfügbare Bandbreite beträgt weniger als 6 Mbit/s
   • Beide Systeme verfügen über freie CPU- und I/O-Kapazitäten

     Die Optimierung bei niedriger Bandbreite sollte aktiviert sein. Überwachen Sie die Ausgabe von "replication show history" über mehrere Wochen. Das "Low-bw-optim"-Verhältnis sollte durchschnittlich 2,00 oder mehr betragen und der Netzwerkdurchsatz (Netzwerkbyte geteilt durch Zeitintervall) sollte nicht viel kleiner als die verfügbare Bandbreite sein. Wenn das "Low-bw-optim"-Verhältnis durchschnittlich nicht 2,00 oder mehr beträgt, ist die Delta-Komprimierung für das Datenvolumen wahrscheinlich nicht effektiv und sollte deaktiviert werden. Wenn der Netzwerkdurchsatz viel geringer als die verfügbare Bandbreite ist, verfügen höchstwahrscheinlich eines oder beide Data Domain-Systeme nicht über genügend Reserve-CPU- oder I/O-Kapazität, um die Delta-Replikation zu unterstützen, und sie sollte deaktiviert werden.

6. Befolgen Sie die Best Practices für andere Komponenten und Backupanwendungen von Drittanbietern.
   Unsere Best-Practices-Leitfäden sind mit Blick auf die Gesamtperformance geschrieben. Abweichungen von Data Domains, die auf Best Practices hindeuten, können erhebliche Auswirkungen auf die Performance in verschiedenen Bereichen haben, auch wenn dies möglicherweise nicht sofort ersichtlich ist.

Referenz

Troubleshooting einer Replikationsverzögerung 180482