Data Domain: Best practice per la replica di directory e pool

Best practice per la replica di directory

SCOPO

Questo articolo definisce le best practice per la configurazione della replica di directory.

SI APPLICA A

• Tutti i sistemi Data Domain
• Tutte le release del software

CONSIGLI

1. Distribuire il carico di lavoro su quanti più contesti possibili.
   Il throughput precompresso ideale per contesto singolo è compreso tra 200 e 300 MB/s. Nelle configurazioni in cui è disponibile il multistreaming, le prestazioni ideali in un singolo contesto sono simili alle prestazioni ideali in multicontesto. Tuttavia, ci sono diverse variabili che limitano l'efficacia del multistreaming:

   • Se il DDR di origine presenta molti contesti di replica, la logica di suddivisione dei flussi multi-streaming tra i contesti limita il numero disponibile di flussi.
   • Il multi-streaming non è attivo durante l'inizializzazione/il ripristino basato su snapshot. Per impostazione predefinita, un'inizializzazione basata su snapshot è attiva se il contesto di origine ha più di 1 milione voci.
   • Dalla versione 5.0 in poi è stato introdotto il multi-streaming per replicare i dati CIFS.

   Il throughput precompresso multicontesto ideale in base al modello varia da circa 200 MB/sec a 500 MB/s o più.

2. Progettare il carico di lavoro con file di dimensioni moderate.
   Le dimensioni dei file possono avere un impatto significativo sulle prestazioni complessive di qualsiasi contesto di replica. In generale, i file di dimensioni inferiori a 10 MB non possono essere replicati in modo efficiente.

   Inoltre, quando una coppia di replica si riconnette dopo una disconnessione imprevista, l'origine deve riavviarsi dall'inizio del file replicato durante la disconnessione. Se il file è di grandi dimensioni e si verificano frequenti disconnessioni (ad esempio, a causa di una rete inaffidabile), la replica può effettivamente rimanere bloccata. tentativo di replicare lo stesso file più e più volte. Questo problema si verifica più comunemente con i file di dimensioni superiori a 100 GB. Non vi è alcuna implicazione sulle prestazioni a causa delle dimensioni del file stesso.

3. Progettare il carico di lavoro in modo da sfruttare la pianificazione della replica.
   I file vengono accodati per la replica quando vengono chiusi internamente. I tempi di chiusura del file sono i seguenti:

   Quando un file modificato viene chiuso, viene generato un record di "chiusura" del registro di replica per il file. La replica accoda i nuovi dati nel file per l'invio. Se non sono presenti altre operazioni di replica nella coda (record di registro non elaborati), i nuovi dati vengono inviati immediatamente. In caso contrario, il file verrà replicato dopo l'elaborazione dei record di registro precedenti.

   • 10 minuti dopo l'ultimo accesso, NFS chiuderà il file.
   • Tutti i file vengono chiusi ogni ora, indipendentemente dall'ultima data in cui sono stati scritti.
   • Se si accede o si scrive molti file, è possibile che la chiusura avvenga prima di quanto previsto dalle regole di cui sopra. Il software di backup che scrive i file in frammenti più piccoli (ad esempio, 1 MB) può comportare un avvio più precoce della replica a causa del numero di file generati.

4. Se possibile, utilizzare una rete dedicata.
   Tassi di perdita di pacchetti fino allo 0,1% possono compromettere gravemente il throughput di rete, in particolare per le reti con ritardo di larghezza di banda elevato. Per le reti con larghezza <di banda = T2, RTT (Round-Trip Time) fino a un secondo forniscono un buon throughput. Per le reti di = T3, si verifica una significativa riduzione del >throughput a partire da un RTT di 300-500 ms.

   Più in generale, il throughput in caso di perdita di pacchetti è approssimativamente
   Throughput = MSS /(RTT * sqrt(p)) dove MSS := dimensione minima del segmento (tipicamente 1460 byte) RTT := tempo di andata e ritorno p := probabilità di perdita di pacchetti

5. Valutare la replica delta (ottimizzazione a bassa larghezza di banda).
   In DD OS 4.8 e versioni successive, la replica delta, detta anche "ottimizzazione a bassa larghezza di banda", può aumentare il throughput virtuale della replica di directory o pool su link con meno di 6 mega bit al secondo (Mbps) di larghezza di banda disponibile. La replica delta comporta un notevole overhead aggiuntivo della CPU e di I/O sui sistemi Data Domain di origine e di destinazione. Se l'ottimizzazione a bassa larghezza di banda è abilitata su collegamenti con più di 6 Mbps di larghezza di banda, è improbabile che si realizzi un guadagno in termini di throughput virtuale. In generale, se:

   • I dati da replicare sono identici per meno del 96% ai dati già esistenti nel sistema di destinazione
   • La larghezza di banda disponibile è inferiore a 6 Mbps
   • Entrambi i sistemi dispongono di CPU e capacità I/O di riserva

     È necessario abilitare l'ottimizzazione a bassa larghezza di banda. Monitorare l'output di "replication show history" per diverse settimane. Il rapporto "Low-bw-optim" deve essere in media pari o superiore a 2,00 e il throughput di rete (byte di rete divisi per intervallo di tempo) non deve essere molto inferiore alla larghezza di banda disponibile. Se il rapporto "Low-bw-optim" non è in media pari o superiore a 2,00, è probabile che la compressione delta non sia efficace sul dataset e deve essere disabilitata. Se il throughput di rete è molto inferiore alla larghezza di banda disponibile, è molto probabile che uno o entrambi i sistemi Data Domain non dispongano di CPU o capacità I/O di riserva sufficienti per supportare la replica delta e devono essere disabilitati.

6. Seguire le best practice per altri componenti e applicazioni di backup di terze parti.
   Le nostre guide alle best practice sono state scritte pensando alle prestazioni complessive. Le deviazioni dalle best practice suggerite da Data Domain possono avere implicazioni significative sulle prestazioni in diverse aree, anche se potrebbero non essere immediatamente evidenti.

RIFERIMENTO

Risoluzione dei problemi di ritardo di replica (in inglese) 180482