Solution 1 :
Le nombre de fichiers et la surcharge de chiffrement SSH sont probablement les plus grands obstacles. Vous n'allez pas voir la vitesse filaire sur un transfert comme celui-ci.
Les options à améliorer incluent :
- Utilisation de rsync+SSH avec un algorithme de chiffrement moins coûteux (par exemple,
-e "ssh -c arcfour") - Éliminer entièrement le chiffrement sur le transport SSH avec quelque chose comme HPN-SSH.
- Transferts en bloc. Instantanés,
dd, envoi/réception d'instantanés ZFS, etc. - S'il s'agit d'un transfert ponctuel ou peu fréquent, utilisez
tar, netcat (nc), mbuffer ou une combinaison. - Vérifiez votre CentOS
tuned-admparamètres. - Suppression de l'atime de vos montages de système de fichiers. Examen d'autres options de montage de système de fichiers.
- Tampons d'envoi/de réception NIC.
- Réglage de votre
rsynccommande. Est-ce que-W, l'option des fichiers entiers a-t-elle un 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 du contrôleur RAID.)
Solution 2 :
Comme vous le savez probablement, copier beaucoup 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 non plus le meilleur protocole de transport pour cela. 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 [email protected] 'tar x -C /var/backups'
Si vous avez besoin d'une sauvegarde incrémentielle, vous pouvez essayer le -g options de tar. Si vous avez encore besoin de maximiser le débit, essayez d'utiliser netcat au lieu de ssh.