Data Domain: Best practices voor directory- en poolreplicatie

Best practices voor directoryreplicatie

DOEL

Dit artikel definieert best practices voor het configureren van directoryreplicatie.

VAN TOEPASSING OP

• Alle Data Domain-systemen
• Alle softwarereleases

AANBEVELINGEN

1. Verdeel de werklast over zoveel mogelijk contexten.
   De ideale voorgecomprimeerde doorvoer met één context ligt tussen de 200 en 300 MB/sec. In configuraties waar multistreaming beschikbaar is, zijn ideale prestaties met één context vergelijkbaar met ideale prestaties met meerdere contexten; Er zijn echter verschillende variabelen die de effectiviteit van multistreaming beperken:

   • Als de bron-DDR veel replicatiecontexten heeft, beperkt de logica voor het verdelen van multistreaming-streams over contexten het beschikbare aantal streams.
   • Multistreaming is niet actief tijdens initialiseren/herstellen op basis van snapshots. Standaard is een initialisatie op basis van snapshots van kracht als de broncontext meer dan 1 miljoen vermeldingen heeft.
   • Vanaf 5.0 werd multistreaming geïntroduceerd voor het repliceren van CIFS-gegevens.

   De ideale multicontext voorgecomprimeerde doorvoer per model varieert van ongeveer 200 MB/sec tot 500 MB/sec of meer.

2. Ontwerp de workload met bestanden van gemiddelde grootte.
   De bestandsgrootte kan een aanzienlijke invloed hebben op de algehele prestaties van elke replicatiecontext. Over het algemeen kunnen bestanden kleiner dan 10 MB niet efficiënt worden gerepliceerd.

   Wanneer een replicatiepaar opnieuw verbinding maakt na een onverwachte verbroken verbinding, moet de bron opnieuw worden opgestart vanaf het begin van het bestand dat tijdens de verbroken verbinding werd gerepliceerd. Als het bestand erg groot is en de verbinding regelmatig wordt verbroken (bijvoorbeeld door een onbetrouwbaar netwerk), kan de replicatie effectief vast komen te zitten. Ik probeer steeds hetzelfde bestand te repliceren. Dit wordt het meest gezien bij bestanden die groter zijn dan 100 GB. Er is geen prestatie-implicatie vanwege de bestandsgrootte zelf.

3. Ontwerp de workload om te profiteren van replicatieplanning.
   Bestanden worden in de wachtrij geplaatst voor replicatie wanneer ze intern worden gesloten. De timing van het sluiten van het bestand is als volgt:

   Wanneer een gewijzigd bestand wordt gesloten, wordt een replicatielogboek "close"-record gegenereerd voor het bestand. Replicatie plaatst de nieuwe data in het bestand in de wachtrij voor verzending. Als er geen andere replicatiebewerkingen voor in de wachtrij staan (dat wil zeggen niet-verwerkte logboekrecords), worden de nieuwe gegevens onmiddellijk verzonden. Anders wordt het bestand gerepliceerd nadat eerdere logboekrecords zijn verwerkt.

   • 10 minuten na de laatste toegang sluit NFS het bestand.
   • Alle bestanden worden elk uur gesloten, ongeacht hoe recent ze zijn geschreven.
   • Als er veel bestanden worden geopend of geschreven, kunnen bestanden eerder worden gesloten dan de bovenstaande regels voorschrijven. Back-upsoftware die bestanden in kleinere fragmenten schrijft (bijvoorbeeld 1 MB) kan ertoe leiden dat de replicatie eerder wordt gestart vanwege het aantal bestanden dat wordt gegenereerd.

4. Gebruik indien mogelijk een speciaal netwerk.
   Pakketverliespercentages van slechts 0,1% kunnen de netwerkdoorvoer ernstig verminderen, met name voor netwerken met een hoge bandbreedtevertraging. Voor netwerken met bandbreedte <= T2 biedt RTT (Round-Trip Time) tot één seconde een goede doorvoer. Voor netwerken van >= T3 is er een aanzienlijke doorvoerverslechtering vanaf een RTT van 300-500 ms.

   Meer in het algemeen is de doorvoer bij pakketverlies ongeveer
   Doorvoer = MSS /(RTT * sqrt(p)) waarbij MSS := minimale segmentgrootte (meestal 1460 bytes) RTT := retourtijd p := waarschijnlijkheid van pakketverlies

5. Evalueer deltareplicatie (optimalisatie met lage bandbreedte).
   In DD OS 4.8 en hoger kan deltareplicatie, ook wel 'lage bandbreedteoptimalisatie' genoemd, de virtuele doorvoer van directory- of poolreplicatie verhogen over links met minder dan 6 megabits per seconde (Mbps) beschikbare bandbreedte. Delta-replicatie brengt aanzienlijke extra CPU- en I/O-overhead met zich mee op zowel de bron- als doeldatadomeinsystemen. Als optimalisatie voor lage bandbreedte is ingeschakeld voor koppelingen met een bandbreedte van meer dan 6 Mbps, is het onwaarschijnlijk dat er een winst in virtuele doorvoer wordt gerealiseerd. In het algemeen geldt dat:

   • De te repliceren data zijn voor minder dan 96% identiek aan de data die al op het doelsysteem aanwezig zijn
   • Er is minder dan 6 Mbps bandbreedte beschikbaar
   • Beide systemen hebben CPU- en I/O-reservecapaciteit

     Low-bandwidth optimization should be enabled. Controleer de uitvoer van "replication show history" gedurende meerdere weken. De verhouding "Low-bw-optim" moet gemiddeld 2,00 of meer zijn en de netwerkdoorvoer (netwerkbytes gedeeld door een tijdsinterval) mag niet veel kleiner zijn dan de beschikbare bandbreedte. Als de verhouding "Low-bw-optim" niet gemiddeld 2,00 of meer is, is deltacompressie waarschijnlijk niet effectief op de dataset en moet deze worden uitgeschakeld. Als de netwerkdoorvoer veel minder is dan de beschikbare bandbreedte, hebben een of beide Data Domain systemen hoogstwaarschijnlijk niet genoeg reserve-CPU- of I/O-capaciteit om deltareplicatie te ondersteunen en moet deze worden uitgeschakeld.

6. Volg de aanbevolen werkwijzen voor andere onderdelen en back-upapplicaties van derden.
   Onze handleidingen voor best practices zijn geschreven met het oog op de algehele prestaties. Afwijkingen van Data Domains suggereren dat best practices aanzienlijke gevolgen kunnen hebben voor de prestaties op verschillende gebieden, hoewel dit misschien niet meteen duidelijk is.

REFERENTIE

Problemen met replicatievertraging oplossen 180482