Optimisation des performances et du débit rsync - serveurs Gigabit directement connectés


27

J'ai deux serveurs Dell R515 exécutant CentOS 6.5, avec l'un des NIC Broadcom dans chacun directement connecté à l'autre. J'utilise le lien direct pour pousser les sauvegardes du serveur principal de la paire vers le secondaire tous les soirs en utilisant rsync sur ssh. En surveillant le trafic, je vois un débit de ~ 2 Mo / s, ce qui est beaucoup moins que ce à quoi je m'attendais d'un port gigabit. J'ai réglé le MTU sur 9000 des deux côtés, mais cela ne semble rien changer.

Existe-t-il un ensemble de paramètres et d'optimisations recommandé qui me conduirait au débit maximal disponible? De plus, puisque j'utilise rsync sur ssh (ou potentiellement juste NFS) pour copier des millions de fichiers (~ 6 To de petits fichiers - une énorme librairie Zimbra), les optimisations que je recherche devront peut-être être plus spécifiques pour mon cas d'utilisation particulier .

J'utilise ext4 des deux côtés, si cela est important

Merci

EDIT: J'ai utilisé les rsyncoptions suivantes avec des résultats à peu près similaires:

rsync -rtvu --delete source_folder/ destination_folder/

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

Actuellement, je regarde le même niveau de mauvaises performances lors de l'utilisation cpvers une exportation NFS, sur la même liaison câblée directe.

EDIT2: après avoir terminé la synchronisation, j'ai pu exécuter iperfet j'ai trouvé que les performances étaient d'environ 990 Mbits / s, la lenteur était due à l'ensemble de données réellement utilisé.


1
Vous devez ajouter rsync à vos balises. Avez-vous vérifié l'heure de la partie liste de rsync? Le faible débit peut être dû à de petits fichiers. Pouvez-vous publier votre commande rsync pour vérifier les options?
kranteg

@kranteg s'il vous plaît voir modifier
dyasny

2
Veuillez vérifier la connectivité avec iperf.
ewwhite

yup, iperf affiche 991mbits / s, je suppose que c'est le jeu de données qui était si lent
dyasny

Vous ne pouvez pas avoir un bon débit avec rsync et un ensemble de données avec de petits fichiers. Vous devriez certainement essayer le goudron.
kranteg

Réponses:


24

Le nombre de fichiers et la surcharge de chiffrement SSH sont probablement les plus grands obstacles. Vous n'allez pas voir la vitesse du fil sur un transfert comme celui-ci.

Les options à améliorer comprennent:

  • Utilisation de rsync + SSH avec un algorithme de chiffrement moins coûteux (par exemple -e "ssh -c arcfour")
  • Élimination du chiffrement entièrement sur le transport SSH avec quelque chose comme HPN-SSH .
  • Transferts basés sur des blocs. Instantanés, dd, instantané ZFS envoi / réception , etc.
  • S'il s'agit d'un transfert ponctuel ou peu fréquent, utilisez tarnetcat ( nc), mbuffer ou une combinaison.
  • Vérifiez vos tuned-admparamètres CentOS .
  • Suppression de l'atime de vos supports de système de fichiers. Examen d'autres options de montage du système de fichiers.
  • NIC envoyer / recevoir des tampons.
  • Ajuster votre rsynccommande. Est -W-ce que l'option fichiers entiers aurait du sens ici? La compression est-elle activée?
  • Optimisez votre sous-système de stockage pour le type de transferts (SSD, nombre de broches, cache de contrôleur RAID.)

J'ai vidé SSH pour NFS, voyant à peu près les mêmes résultats. Je prévois des transferts basés sur des blocs, je passe aux sauvegardes basées sur des instantanés LVM et je sauvegarde les sauvegardes sur le deuxième serveur, où j'exécuterai ZFS pour la déduplication. atime est désactivé des deux côtés. Aucune compression n'est utilisée. Comment optimiser les sous-systèmes de stockage pour ce type de transfert? La source possède deux disques RAID10 sur 12x 10k SAS, l'un sur les disques locaux, l'autre un MD1220. Le serveur de sauvegarde a le même nombre de disques, mais avec de grands disques SATA, et utilise RAID5. Cache complet des contrôleurs H800 et H700 des deux côtés. 2MBps (depuis iftop) ~
dyasny

~ me fait penser que le réseautage est néanmoins le goulot d'étranglement ici.
dyasny

@dyasny Testez votre réseau avec iperfpour être sûr.
ewwhite


1
Assurez-vous que la structure du répertoire de destination a été créée par rsyncet non par cp. J'ai vu rsyncprendre beaucoup plus de temps pour mettre à jour une arborescence de répertoires distants créée à l'origine par cp: 88 Go mis à jour avec une somme de contrôle en 1h26m au lieu de 3h! La façon dont vous créez la disposition de disque initiale est essentielle pour obtenir de bonnes performances de mise à jour. Le temps CPU est le même; le temps réel peut doubler. (La même mise à jour sans vérification s'exécute en 13 minutes d'un SSD à un Seagate de 200 Go).
Ian D. Allen

3

Comme vous le savez probablement, la copie d'un grand nombre de petits fichiers (par exemple, des boîtes aux lettres utilisant le format MailDir ou similaire) n'est certainement pas la meilleure option pour tirer parti des interfaces à bande passante élevée. SSH n'est probablement pas le meilleur protocole de transport pour cela non plus. J'essaierais d'utiliser tar pour créer une archive tar sur l'hôte source avant de l'envoyer à votre hôte secondaire.

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

Si vous avez besoin d'une sauvegarde incrémentielle, vous voudrez peut-être essayer les -goptions de tar. Si vous avez encore besoin de maximiser le throuput, essayez d'utiliser netcat au lieu de ssh.


Je suis passé à NFS au lieu de SSH, pour supprimer la surcharge de chiffrement, pas de joie
dyasny

Avez-vous essayé d'utiliser du goudron? Peut être une première étape, essayez de créer un tarbal local sur le serveur principal, puis transférez-le sur le câble. (ou testez votre réseau avec iperf comme @ewwhite suggeted)
alxgomz

Je le ferais, si j'avais de l'espace local à revendre. C'est assez énorme, même avec une boîte DAS entièrement remplie
dyasny

puis essayez de le passer sur netcat ou ssh (ce n'est pas aussi efficace cependant)
alxgomz

Je passerai plus tard à des sauvegardes basées sur des blocs et j'ai l'intention de ddpasser par nclà. mais en ce moment, je suis coincé avec deux énormes sauvegardes, puis je dois être déplacé de l'hôte principal, donc je peux y créer un système LVM
dyasny

1

Essayez de démêler les facteurs contributifs:

  • CPU (par exemple dd de / dev / zero canalisé via le bouclage)
  • E / S de disque (par exemple, dd d'un gros fichier redirigé vers cat> / dev / null [redirigé pour éviter les courts-circuits])
  • E / S réseau physique (par exemple, dd canalisé vers l'autre machine)
  • etc.

et les tester indépendamment.

J'ai eu de mauvaises expériences avec les pilotes Broadcom, donc ma première suggestion est de tester la bande passante réseau utilisable avec: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.