Doğrudan bağlı gigabit sunucular

CentOS 6.5 çalıştıran iki Dell R515 sunucum var, bunlardan her biri diğerine doğrudan bağlı olan geniş NIC'lerden biri. Her gece ss üzerinde rsync kullanarak yedekleri ana sunucudan ikincisine göndermek için doğrudan bağlantıyı kullanıyorum. Trafiği izlerken, bir gigabit bağlantı noktasından beklediğimden çok daha az olan ~ 2 MBps veri hacmi görüyorum. MTU’yu her iki tarafta 9000’e ayarladım, ancak bu hiçbir şeyi değiştirmedi.

Beni maksimum kullanılabilir kapasiteye götürecek önerilen bir dizi ayar ve optimizasyon var mı? Dahası, milyonlarca dosyayı kopyalamak için ssh (veya potansiyel olarak sadece NFS) üzerinden rsync kullandığımdan (~ 6Tb küçük dosyalar - büyük bir Zimbra posta deposu) aradığım optimizasyonların, özel kullanım durumum için daha spesifik olması gerekebilir .

Her iki tarafta da ext4 kullanıyorum, eğer önemliyse

Teşekkürler

EDIT: Aşağıdaki rsyncseçenekleri hemen hemen benzer sonuçlarla kullandım:

rsync -rtvu --delete source_folder/ destination_folder/

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

Şu anda, cpaynı doğrudan kablo bağlantısı üzerinden bir NFS dışa aktarımı için kullanıldığında aynı düzeyde kötü performansa bakıyorum .

EDIT2: senkronizasyonu bitirdikten sonra çalıştırabilir iperfve performansın 990Mbits / sn civarında olduğunu fark ettim, yavaşlık kullanımdaki gerçek veri setinden kaynaklanıyordu.

Dosya sayımı ve SSH şifreleme yükü büyük olasılıkla en büyük engeldir. Böyle bir transferde kablo hızını görmeyeceksiniz.

İyileştirme seçenekleri şunları içerir:

• Daha az maliyetli bir şifreleme algoritmasıyla rsync + SSH kullanmak (örn. -e "ssh -c arcfour")
• HPN-SSH gibi bir şeyle tamamen SSH üzerinden şifrelemeyi ortadan kaldırmak .
• Blok bazlı transferler. Anlık görüntülerdd , ZFS anlık görüntüsü gönderme / alma vb.
• Bu bir kerelik veya nadiren yapılan bir transferse tar, netcat ( nc), mbuffer veya bazı kombinasyonları kullanın.
• CentOS tuned-admayarlarınızı kontrol edin .
• Atime'i dosya sisteminizden kaldırmak. Diğer dosya sistemi bağlama seçeneklerini incelemek.
• NIC arabellekleri gönderir / alır.
• rsyncKomutunu ayarlamak . Misiniz -W, burada bütün dosyaları seçeneği mantıklı? Sıkıştırma etkin mi?
• Depolama alt sisteminizi aktarma türleri için optimize edin (SSD'ler, iş mili sayısı, RAID denetleyici önbelleği.)

Muhtemelen bildiğiniz gibi çok sayıda küçük dosyayı kopyalamak (örneğin MailDir formatı veya benzerini kullanan posta kutuları) kesinlikle yüksek bant genişliğine sahip arayüzlerden yararlanmak için en iyi seçenek değildir. SSH muhtemelen bunun için de en iyi nakil protokolü değildir. İkincil ana makinenize göndermeden önce kaynak ana bilgisayarda bir tarball oluşturmak için tar kullanmaya çalışacağım.

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

Artımlı yedeklemeye ihtiyacınız varsa -gtar seçeneklerini denemek isteyebilirsiniz . Yine de throuput'u en üst düzeye çıkarmanız gerekiyorsa, ssh yerine netcat kullanmayı deneyin.

Katkıda bulunan faktörleri ayırmaya çalışın:

• CPU (örneğin, geridöngü aracılığıyla bağlanmış / dev / sıfır dd)
• disk G / Ç (örneğin , cat> / dev / null [kısa devreyi önlemek için piped] olarak adlandırılmış büyük bir dosyanın dd'si)
• fiziksel ağ G / Ç (örneğin, diğer makineye bağlanmış dd)
• vb.

ve onları bağımsız olarak test etmek.

Broadcom sürücüleri ile ilgili bazı kötü deneyimlerim oldu, bu yüzden ilk önerim kullanılabilir ağ bant genişliğini aşağıdakilerle test etmektir: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null