Memaksimalkan kinerja dan throughput rsync - server gigabit yang terhubung langsung

Saya memiliki dua server Dell R515 yang menjalankan CentOS 6.5, dengan salah satu NIC Broadcom di masing-masing terpasang langsung ke yang lain. Saya menggunakan tautan langsung untuk mendorong cadangan dari server utama di pasangan ke sekunder setiap malam menggunakan rsync over ssh. Memantau lalu lintas, saya melihat throughput ~ 2MBps, yang jauh lebih sedikit daripada yang saya harapkan dari port gigabit. Saya telah mengatur MTU ke 9000 di kedua sisi, tetapi itu tampaknya tidak mengubah apa pun.

Apakah ada satu set pengaturan dan optimisasi yang direkomendasikan yang akan membawa saya ke throughput maksimum yang tersedia? Selain itu, karena saya menggunakan rsync over ssh (atau berpotensi hanya NFS) untuk menyalin jutaan file (~ 6Tb file kecil - toko surat Zimbra yang besar), optimasi yang saya cari mungkin perlu lebih spesifik untuk kasus penggunaan khusus saya. .

Saya menggunakan ext4 di kedua sisi, jika itu penting

Terima kasih

EDIT: Saya telah menggunakan rsyncopsi berikut dengan hasil yang hampir mirip:

rsync -rtvu --delete source_folder/ destination_folder/

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

Saat ini, saya melihat tingkat kinerja buruk yang sama ketika menggunakan cpuntuk ekspor NFS, melalui tautan kabel langsung yang sama.

EDIT2: setelah menyelesaikan sinkronisasi, saya bisa menjalankan iperfdan menemukan kinerja sekitar 990Mbits / detik, kelambatan ini disebabkan oleh dataset aktual yang digunakan.

— dyasny
sumber

Anda harus menambahkan rsync ke tag Anda. Apakah Anda memeriksa waktu untuk bagian daftar rsync? Throughput rendah dapat disebabkan oleh file kecil. Bisakah Anda memposting perintah rsync Anda untuk memeriksa opsi?

— kranteg

@kranteg silakan lihat edit

— dyasny

Harap verifikasi konektivitas dengan iperf.

— ewwhite

ya, iperf menunjukkan 991mbits / s, saya kira itu set data yang sangat lambat

— dyasny

Anda tidak dapat memiliki grup yang bagus dengan rsync dan dataset dengan file kecil. Anda pasti harus mencoba tar.

— kranteg

Jawaban:

Jumlah file dan overhead enkripsi SSH kemungkinan merupakan hambatan terbesar. Anda tidak akan melihat kecepatan kawat pada transfer seperti ini.

Pilihan untuk meningkatkan termasuk:

Menggunakan rsync + SSH dengan algoritma enkripsi yang lebih murah (mis. -e "ssh -c arcfour")
Menghilangkan enkripsi sepenuhnya melalui transport SSH dengan sesuatu seperti HPN-SSH .
Transfer berbasis blok. Snapshots, dd, ZFS snapshot send / receive , dll
Jika ini adalah transfer satu kali atau jarang, gunakan tar, netcat ( nc), mbuffer atau kombinasi.
Periksa tuned-admpengaturan CentOS Anda .
Menghapus atime dari mount sistem file Anda. Meneliti opsi pemasangan sistem file lainnya.
NIC mengirim / menerima buffer.
Tuning rsyncperintah Anda . Apakah -Wopsi seluruh file masuk akal di sini? Apakah kompresi diaktifkan?
Optimalkan subsistem penyimpanan Anda untuk jenis transfer (SSD, hitungan spindle, cache pengontrol RAID.)

— putih
sumber

Saya telah membuang SSH untuk NFS, melihat hasil yang hampir sama. Transfer berbasis blok adalah apa yang saya rencanakan, beralih ke backup berbasis snapshot LVM dan dd backup ke server kedua, di mana saya akan menjalankan ZFS untuk dedupe. atime dinonaktifkan di kedua sisi. Tidak ada kompresi yang digunakan. Bagaimana cara mengoptimalkan subsistem penyimpanan untuk transfer semacam ini? Sumber memiliki dua RAID10 lebih dari 12x 10k SAS drive, satu di drive lokal, yang lain MD1220. Server cadangan memiliki jumlah disk yang sama, tetapi dengan drive SATA besar, dan menggunakan RAID5. Kendali cache H800 dan H700 di kedua sisi. 2MBps (dari iftop) ~

— dyasny

~ membuat saya berpikir bahwa jaringan adalah hambatan di sini.

— dyasny

@dyasny Uji jaringan Anda dengan iperfpasti.

— ewwhite

@dyasny Ya. Sebagian besar yang perlu Anda ketahui tentang ZFS ada di sini

— ewwhite

Pastikan struktur direktori tujuan dibuat oleh rsyncdan bukan oleh cp. Saya telah melihat rsyncmembutuhkan waktu lebih lama untuk memperbarui pohon direktori jauh yang awalnya dibuat oleh cp: 88GB diperbarui dengan checksumming dalam 1h26m, bukan 3j! Cara Anda membuat tata letak disk awal sangat penting untuk mendapatkan kinerja pembaruan yang baik. Waktu CPU adalah sama; waktu nyata dapat berlipat ganda. (Pembaruan yang sama tanpa pemeriksaan berjalan dalam 13 menit dari SSD ke 200GB Seagate).

— Ian D. Allen

Seperti yang Anda ketahui, menyalin banyak file kecil (mis. Kotak surat menggunakan format MailDir atau sejenisnya) jelas bukan pilihan terbaik untuk memanfaatkan antarmuka bandwidth tinggi. SSH mungkin juga bukan protokol transportasi terbaik untuk itu. Saya akan mencoba menggunakan tar untuk membuat tarball pada host sumber sebelum mengirimkannya kepada Anda host sekunder.

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

Jika Anda perlu cadangan tambahan, Anda mungkin ingin mencoba -gopsi tar. Jika Anda masih perlu memaksimalkan throuput, coba gunakan netcat daripada ssh.

— alxgomz
sumber

Saya telah beralih ke NFS alih-alih SSH, untuk menghapus overhead enkripsi, tidak ada sukacita

— dyasny

Sudahkah Anda mencoba menggunakan tar? Mungkin sebagai langkah pertama coba buat tarbal lokal di server utama dan kemudian transfer melalui kabel. (atau uji jaringan Anda dengan iperf seperti @ewwhite suggeted)

— alxgomz

Saya akan, jika saya punya ruang lokal untuk cadangan. Ini cukup besar, bahkan dengan kotak DAS yang terisi penuh

— dyasny

lalu coba memipisnya ke netcat atau ssh (bukankah ini seefisien)

— alxgomz

Saya akan beralih ke blok cadangan berdasarkan nanti, dan saya berniat untuk pipa ddmelalui ncitu. tapi sekarang, saya terjebak dengan dua cadangan besar maka harus dipindahkan dari host utama, jadi saya dapat membuat sistem LVM di sana

— dyasny

Coba pisahkan faktor-faktor yang berkontribusi:

CPU (mis. Hh dari / dev / nol disalurkan melalui loopback)
disk I / O (mis. dd dari file besar yang disalurkan ke cat> / dev / null [disalurkan untuk mencegah korsleting])
I / O jaringan fisik (mis. dd disalurkan ke mesin lain)
dll.

dan mengujinya secara mandiri.

Saya memiliki beberapa pengalaman buruk dengan driver Broadcom, jadi saran pertama saya adalah menguji bandwidth jaringan yang dapat digunakan dengan: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null

— Scott Leadley
sumber

Atau iperf ...

— ewwhite