Maximizar o desempenho e o rendimento do rsync - servidores gigabit conectados diretamente

Question

Eu tenho dois servidores Dell R515 executando o CentOS 6.5, com uma das NICs broadcom em cada um diretamente conectado ao outro. Eu uso o link direto para enviar backups do servidor principal no par para o secundário todas as noites usando o rsync sobre o ssh. Monitorando o tráfego, vejo uma taxa de transferência de ~ 2MBps, que é muito menor do que eu esperaria de uma porta gigabit. Eu configurei o MTU para 9000 em ambos os lados, mas isso não parece mudar nada.

Existe um conjunto recomendado de configurações e otimizações que me levaria ao máximo de taxa de transferência disponível? Além disso, como estou usando rsync sobre ssh (ou potencialmente apenas NFS) para copiar milhões de arquivos (~ 6Tb de arquivos pequenos - uma enorme mala direta Zimbra), as otimizações que estou procurando podem precisar ser mais específicas para meu caso de uso específico .

Estou usando o ext4 em ambos os lados, se isso for importante

Obrigado

EDIT: usei as seguintes opções rsync com resultados muito semelhantes:

rsync -rtvu --delete source_folder/ destination_folder/

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

Atualmente, estou observando o mesmo nível de desempenho ruim ao usar cp em uma exportação NFS, usando o mesmo link de cabo direto.

EDIT2: depois de terminar a sincronização, eu pude rodar iperf e achei que o desempenho estava em torno de 990Mbits / segundo, a lentidão foi devido ao conjunto de dados real em uso.

    

Answer 1

A contagem de arquivos e a sobrecarga de criptografia SSH são provavelmente as maiores barreiras. Você não vai ver a velocidade do fio em uma transferência como essa.

As opções para melhorar incluem:

• Usando o rsync + SSH com um algoritmo de criptografia de menor custo (por exemplo, -e "ssh -c arcfour" )
• Eliminando a criptografia totalmente no transporte SSH com algo como HPN-SSH .
• Transferências baseadas em blocos. Instantâneos, dd , Envio / recebimento de snapshot do ZFS , etc.
• Se essa for uma transferência única ou pouco frequente, use tar , netcat ( nc ), mbuffer ou alguma combinação.
• Verifique se o CentOS tuned-adm settings .
• Removendo o atime das montagens do seu sistema de arquivos. Examinando outras opções de montagem do sistema de arquivos.
• Buffers de envio / recebimento de NIC.
• Ajustando seu comando rsync . Será que -W , a opção de arquivos inteiros faz sentido aqui? A compactação está ativada?
• Otimize seu subsistema de armazenamento para o tipo de transferência (SSDs, contagem de fusos, cache do controlador RAID).

Answer 2

Como você provavelmente sabe, copiar muitos arquivos pequenos (por exemplo, caixas de correio usando o formato MailDir ou similar) definitivamente não é a melhor opção para aproveitar as interfaces de alta largura de banda. O SSH provavelmente não é o melhor protocolo de transporte para isso. Eu tentaria usar tar para criar um tarball no host de origem antes de enviá-lo para você host secundário.

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

Se você precisar de backup incremental, tente as opções -g do tar. Se você ainda precisa maximizar o throuput, tente usar netcat em vez de ssh.

    

Answer 3

Tente separar os fatores que contribuem:

• CPU (por exemplo, dd de / dev / zero canalizado por loopback)
• disco I / O (por exemplo, dd de um arquivo grande canalizado para cat > / dev / null [direcionado para evitar curto-circuito])
• E / S da rede física (por exemplo, dd canalizado para a outra máquina)
• etc.

e testá-los de forma independente.

Eu tive algumas experiências ruins com os drivers da Broadcom, então minha primeira sugestão é testar a largura de banda de rede utilizável com: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null