Maximización del rendimiento y rendimiento de rsync: servidores gigabit conectados directamente

Tengo dos servidores Dell R515 que ejecutan CentOS 6.5, con uno de los NIC de Broadcom en cada uno directamente conectado al otro. Utilizo el enlace directo para enviar copias de seguridad del servidor principal en el par al secundario todas las noches usando rsync a través de ssh. Al monitorear el tráfico, veo un rendimiento de ~ 2 MBps, que es mucho menos de lo que esperaría de un puerto gigabit. He configurado el MTU en 9000 en ambos lados, pero eso no parece cambiar nada.

¿Existe un conjunto recomendado de configuraciones y optimizaciones que me llevarían al máximo rendimiento disponible? Además, dado que estoy usando rsync sobre ssh (o potencialmente solo NFS) para copiar millones de archivos (~ 6Tb de archivos pequeños, un enorme almacén de correo de Zimbra), las optimizaciones que estoy buscando podrían necesitar ser más específicas para mi caso de uso particular .

Estoy usando ext4 en ambos lados, si eso importa

Gracias

EDITAR: He usado las siguientes rsyncopciones con resultados bastante similares:

rsync -rtvu --delete source_folder/ destination_folder/

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

Actualmente, estoy viendo el mismo nivel de mal rendimiento cuando lo uso cppara una exportación NFS, a través del mismo enlace de cable directo.

EDIT2: después de finalizar la sincronización, pude ejecutar iperfy encontré que el rendimiento era de alrededor de 990Mbits / seg, la lentitud se debió al conjunto de datos real en uso.

El recuento de archivos y la sobrecarga de cifrado SSH son probablemente las mayores barreras. No vas a ver la velocidad del cable en una transferencia como esta.

Las opciones para mejorar incluyen:

• Uso de rsync + SSH con un algoritmo de cifrado menos costoso (p -e "ssh -c arcfour". Ej. )
• Eliminando completamente el cifrado sobre el transporte SSH con algo como HPN-SSH .
• Transferencias basadas en bloques. Las instantáneas, dd, instantánea ZFS envío / recepción , etc.
• Si se trata de una transferencia única o poco frecuente, utilice tarnetcat ( nc), mbuffer o alguna combinación.
• Verifique su tuned-admconfiguración de CentOS .
• Eliminando el atime de sus montajes de sistema de archivos. Examinando otras opciones de montaje del sistema de archivos.
• NIC enviar / recibir buffers.
• Afinando tu rsynccomando. ¿Tendría -Wsentido la opción de archivos completos aquí? ¿Está habilitada la compresión?
• Optimice su subsistema de almacenamiento para el tipo de transferencias (SSD, conteo de huso, caché de la controladora RAID).

Como probablemente sepa, copiar una gran cantidad de pequeños archivos (por ejemplo, buzones de correo con formato MailDir o similar) definitivamente no es la mejor opción para aprovechar las interfaces de alto ancho de banda. SSH probablemente tampoco sea el mejor protocolo de transporte para eso. Intentaría usar tar para crear un tarball en el host de origen antes de enviarlo a su host secundario.

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

Si necesita una copia de seguridad incremental, puede probar las -gopciones de tar. Si aún necesita maximizar throuput, intente usar netcat en lugar de ssh.

Intenta burlar los factores contribuyentes:

• CPU (por ejemplo, dd de / dev / zero canalizado a través de loopback)
• E / S de disco (por ejemplo, dd de un archivo grande canalizado a cat> / dev / null [canalizado para evitar cortocircuitos])
• E / S de red física (por ejemplo, dd canalizado a la otra máquina)
• etc.

y probándolos de forma independiente.

He tenido algunas malas experiencias con los controladores Broadcom, por lo que mi primera sugerencia es probar el ancho de banda de red utilizable con: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null