Massimizzare le prestazioni e la velocità di trasmissione di rsync: server gigabit direttamente collegati

Ho due server Dell R515 che eseguono CentOS 6.5, con uno dei NIC Broadcom in ciascuno collegato direttamente all'altro. Uso il collegamento diretto per inviare i backup dal server principale nella coppia al secondario ogni notte usando rsync su ssh. Monitorando il traffico, vedo un throughput di ~ 2 Mbps, che è molto meno di quanto mi aspetterei da una porta gigabit. Ho impostato l'MTU su 9000 su entrambi i lati, ma questo non sembra aver cambiato nulla.

Esiste una serie consigliata di impostazioni e ottimizzazioni che mi porterebbe alla massima velocità disponibile? Inoltre, poiché sto usando rsync su ssh (o potenzialmente solo NFS) per copiare milioni di file (~ 6 TB di piccoli file - un enorme archivio di Zimbra), le ottimizzazioni che sto cercando potrebbero dover essere più specifiche per il mio particolare caso d'uso .

Sto usando ext4 su entrambi i lati, se è importante

Grazie

EDIT: ho usato le seguenti rsyncopzioni con risultati molto simili:

rsync -rtvu --delete source_folder/ destination_folder/

rsync -avHK --delete --backup --backup-dir=$BACKUPDIR source_folder/ destination_folder/

Attualmente, sto osservando lo stesso livello di cattive prestazioni quando si utilizza cpper un'esportazione NFS, sullo stesso collegamento diretto via cavo.

EDIT2: dopo aver terminato la sincronizzazione, ho potuto eseguire iperfe ho scoperto che le prestazioni erano di circa 990Mbit / sec, la lentezza era dovuta al set di dati effettivo in uso.

Il conteggio dei file e l'overhead di crittografia SSH sono probabilmente le maggiori barriere. Non vedrai la velocità del filo su un trasferimento come questo.

Le opzioni per migliorare includono:

• Utilizzo di rsync + SSH con un algoritmo di crittografia meno costoso (ad es -e "ssh -c arcfour" )
• Eliminare la crittografia interamente sul trasporto SSH con qualcosa del genere HPN-SSH .
• Trasferimenti basati su blocchi. Istantanee, dd, ZFS snapshot di invio / ricezione , etc.
• Se si tratta di un trasferimento una tantum o raro, usando tarnetcat ( nc), mbuffer o una combinazione.
• Controlla le tue tuned-admimpostazioni CentOS .
• Rimozione dell'atime dai supporti del filesystem. Esame di altre opzioni di montaggio del filesystem.
• Buffer di invio / ricezione NIC.
• Ottimizza il tuo rsynccomando. L' -Wopzione di interi file avrebbe senso qui? La compressione è abilitata?
• Ottimizza il sottosistema di archiviazione per il tipo di trasferimenti (SSD, conteggio mandrino, cache controller RAID.)

Come probabilmente sapete, copiare molti piccoli file (ad es. Cassette postali utilizzando il formato MailDir o simili) non è sicuramente l'opzione migliore per sfruttare le interfacce con banda alta. SSH non è probabilmente il miglior protocollo di trasporto neanche per quello. Proverei a usare tar per creare un tarball sull'host di origine prima di inviarlo al tuo host secondario.

tar c /var/mail | ssh root@secondary-host 'tar x -C /var/backups'

Se hai bisogno di un backup incrementale, potresti provare le -gopzioni di tar. Se hai ancora bisogno di massimizzare throuput, prova a usare netcat invece di ssh.

Prova a prendere in giro i fattori che contribuiscono:

• CPU (ad es. Dd di / dev / zero convogliato tramite loopback)
• I / O del disco (ad es. dd di un file di grandi dimensioni inviato a cat> / dev / null [convogliato per evitare cortocircuiti])
• I / O di rete fisica (ad es. dd collegato all'altra macchina)
• eccetera.

e testarli in modo indipendente.

Ho avuto alcune brutte esperienze con i driver Broadcom, quindi il mio primo suggerimento è di testare la larghezza di banda di rete utilizzabile con: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null