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


27

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.


11
Você deve adicionar rsync às suas tags. Você verificou o horário da parte da listagem do rsync? A baixa taxa de transferência pode ser devido a arquivos pequenos. Você pode postar seu comando rsync para verificar as opções?
precisa saber é o seguinte

@kranteg consulte editar
dyasny

2
Verifique a conectividade com iperf.
precisa saber é o seguinte

yup, iperf mostra 991mbits / s, eu acho que é te conjunto de dados que foi tão lento
dyasny

Você não pode ter uma boa saída de dados com o rsync e um conjunto de dados com arquivos pequenos. Você definitivamente deveria tentar alcatrão.
precisa saber é o seguinte

Respostas:


24

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.)

Eu joguei o SSH para o NFS, vendo praticamente os mesmos resultados. Transferências baseadas em bloco é o que estou planejando, alterne para backups baseados em instantâneo LVM e faça o backup dos backups no segundo servidor, onde executarei o ZFS para desduplicação. atime está desativado nos dois lados. Nenhuma compactação é usada. Como otimizar os subsistemas de armazenamento para esse tipo de transferência? A fonte possui duas unidades RAID10 sobre 12x 10k SAS, uma nas unidades locais e a outra um MD1220. O servidor de backup tem a mesma contagem de discos, mas com unidades SATA grandes, e usa RAID5. Controladores de cache completo H800 e H700 em ambos os lados. 2MBps (from iftop) ~
dyasny

~ me faz pensar que a rede é o gargalo aqui, no entanto.
dyasny

@dyasny Teste sua rede iperfpara ter certeza.
precisa saber é o seguinte


11
Verifique se a estrutura do diretório de destino foi criada por rsynce não por cp. Já vi rsynclevar muito mais tempo para atualizar uma árvore de diretórios remotos criada originalmente por cp: 88GB atualizada com soma de verificação em 1h26m em vez de 3h! Como você cria o layout de disco inicial é fundamental para obter um bom desempenho de atualização. O tempo da CPU é o mesmo; o tempo real pode dobrar. (A mesma atualização sem verificação é executada em 13 minutos de um SSD para um Seagate de 200 GB).
Ian D. Allen

3

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.


Eu mudei para NFS em vez de SSH, para remover a sobrecarga de criptografia, nenhuma alegria
dyasny

Você já tentou usar o alcatrão? Pode ser o primeiro passo, tente criar um tarbal local no servidor principal e depois transfira-o pelo cabo. (ou testar a sua rede com iperf como @ewwhite suggeted)
alxgomz

Eu teria, se eu tivesse espaço local de sobra. Este é muito grande, mesmo com um DAS totalmente povoadas caixa
dyasny

tente tubulação-lo sobre netcat ou ssh (não é como se eficiente)
alxgomz

Eu vou ser a mudança para bloquear backups baseados mais tarde, e tenho a intenção de tubo ddatravés de ncentão. mas agora, eu estou preso com duas enormes backups em seguida, precisam ser movidos para fora do hospedeiro principal, para que eu possa criar um sistema LVM lá
dyasny

1

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


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.