Maximizando o desempenho e a taxa de transferência de rsync - servidores gigabit conectados diretamente

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

Existe um conjunto recomendado de configurações e otimizações que me levem ao rendimento máximo disponível? Além disso, como estou usando o rsync over ssh (ou potencialmente apenas o NFS) para copiar milhões de arquivos (~ 6 TB de arquivos pequenos - uma enorme loja de correio Zimbra), as otimizações que estou procurando podem precisar ser mais específicas para o meu caso de uso específico .

Estou usando ext4 nos dois lados, se isso importa

obrigado

Edição: Eu usei as seguintes rsyncopções com resultados bastante semelhantes:

rsync -rtvu --delete source_folder/ destination_folder/

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

Atualmente, estou olhando para o mesmo nível de desempenho ruim ao usar cppara uma exportação NFS, pelo mesmo link direto por cabo.

EDIT2: depois de terminar a sincronização, eu pude executar iperfe constatou que o desempenho estava em torno de 990Mbits / s, a lentidão ocorreu devido ao conjunto de dados real em uso.

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

As opções para melhorar incluem:

• Usando rsync + SSH com um algoritmo de criptografia menos dispendioso (por exemplo -e "ssh -c arcfour")
• Eliminando completamente a criptografia no transporte SSH com algo como HPN-SSH .
• Transferências baseadas em bloco. Instantâneos, dd, ZFS instantâneo envio / recepção , etc.
• Se for uma transferência única ou infreqüente, use tarnetcat ( nc), mbuffer ou alguma combinação.
• Verifique suas tuned-admconfigurações do CentOS .
• 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 rsynccomando. A -Wopção de arquivos inteiros faria sentido aqui? A compactação está ativada?
• Otimize seu subsistema de armazenamento para o tipo de transferências (SSDs, contagem de eixos, cache do controlador RAID.)

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 também não é o melhor protocolo de transporte. Eu tentaria usar o tar para criar um tarball no host de origem antes de enviá-lo ao host secundário.

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

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

Tente separar os fatores contribuintes:

• CPU (por exemplo, dd de / dev / zero canalizado através de loopback)
• E / S de disco (por exemplo, dd de um arquivo grande canalizado para cat> / dev / null [canalizado para evitar curtos-circuitos])
• E / S de 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 Broadcom, então minha primeira sugestão é testar a largura de banda da rede utilizável com: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null