Preciso realizar backups locais de centenas de gigabytes de algumas VMs Xen para algum armazenamento disponível em um servidor dedicado na mesma rede, com conexão Gigabit. Os dados são principalmente dados MySQL - eu uso o Percona XtraDB Cluster - com backup local nos servidores com Xtrabackup, então acho que esses dados devem ser altamente compactáveis.
No momento estou usando duplicidade 0.6.08b com criptografia com senha (não estou usando chaves), pois também sincronizo novamente os volumes de backup criados com duplicidade para algum armazenamento externo. O nível de compactação é atualmente 6 e o volsize é 250. Os backups demoram mais de um dia, e é por isso que estou procurando configurações de duplicidade recomendadas que resultariam em backups rápidos para o armazenamento compartilhado na rede local sem ocupar muito espaço.
Qualquer ideia?
Responder1
Você diz em um comentário que está vendo uma taxa de transferência de cerca de 50 MB/s nesses backups.
50 MB/s épor ordem deo que você pode esperar da taxa de transferência de disco semi-aleatória com discos giratórios únicos (ou seja, RAID não espelhado ou distribuído para permitir que as leituras sejam espalhadas pelos discos para aumentar a taxa de transferência). Observe que algumas configurações RAID limitam efetivamente até mesmo o rendimento do melhor caso ao da unidade mais lenta. Sim, muitos HDDs são avaliados em até ~200 MB/s, mas lembre-se de que esses números são números de acesso sequencial no melhor caso. 50 MB/s também é cerca de 400 Mbit/s, o que, com algumas falsificações para sobrecarga de IP, etc., chega a 500-600 Mbit/s no fio da rede, portanto, embora você não esteja saturando o link de gigabit apenas com isso, você estão chegando bastante perto do território provável de colisões.
Você não fornece números para a utilização da CPU enquanto os backups estão em execução, exceto dizer que "tem três hipervisores com várias VMs em cada um, mais ou menos ocupados". Mas copiar dados e compactá-los não exige muito da CPU e, se durante a execução dos backups você tiver algum tempo de CPU sobrando, você não estará limitado pela CPU.A única maneira de realmente responder a esta pergunta é descobrir qual fator está limitando o rendimentoe então concentre seus esforços nisso.
Meu palpiteseria que você está vinculado à E/S, seja em leituras ou gravações, e que vocêpoderestar vinculado à rede. Você fala sobre um servidor de armazenamento de backup dedicado com conexão Ethernet gigabit, mas não diz nada sobre a natureza dessa conexão. A conexão de rede para backups entre os hosts físicos é compartilhada ou dedicada? (Uma rede física separada conectando cada um dos HVs ao servidor de backup seria aceitável, se apenas uma VM ou HV enviasse dados de backup por push a qualquer momento.)
Se a conexão de rede física com o servidor de backup for compartilhada com outro tráfego de rede, você poderá migrar para uma arquitetura de conexão dedicada. O benefício que você obtém com isso depende muito de onde os dados são compactados e de quantas colisões você realmente está vendo atualmente, mas se você fizer isso e nada mais, vocêpoderser capaz de dobrar o rendimento da rede e, assim, se você estiver vinculado à rede, reduzir o tempo de backup pela metade.
Se você estiver vinculado à E/S nas leituras e/ou gravações, mudar para uma configuração espelhada ou distribuída que permita que a E/S do disco seja espalhada por vários discos pode ajudar a aumentar o rendimento; isso aumentaria o rendimento total do barramento do disco. Claro, isso traz suas próprias desvantagens. Dependendo da quantidade de dados que você envia ao mesmo tempo, adicionar maisrápidocache de disco para o servidor de armazenamento de backuppodertambém ajuda, mas minha suspeita seria que, se você estiver vinculado à E/S, estará no lado da leitura, porque as gravações provavelmente serão mais ou menos sequenciais; nesse caso, adicionar cache não ajudará muito.
Você também pode considerar migrar para um sistema de arquivos nas VMs ou HVs e/ou no servidor de armazenamento de backup, que faz compactação dinâmica dos dados gravados no disco ou ativar tal compactação, se for suportada. . Custará tempo de CPU, mas aumentará oeficaztaxa de transferência de dados do disco porque menos dados precisam ser movidos de e para os pratos físicos para a mesma quantidade de dados de espaço do usuário armazenados. Se isso seria ou não um ganho líquido em qualquer situação é basicamente uma questão de cara ou coroa e precisa ser avaliado caso a caso, mas é certamente umpossibilidadepara a situação em que você está limitado por E/S, especialmente se os dados forem altamente compactáveis, para começar. Mesmo que os dados só possam ser compactados em 20% (equivalente a uma taxa de compactação de 1,25:1, e definitivamente alcançável com, por exemplo, texto em linguagem natural; para comparação, o ZFS com compactação gzip-9 me fornece compactação de 1,20:1 em uma amostragem de Sites da Internet,incluindo imagens), essas mesmas taxas de transferência de prato de 50 MB/s repentinamente fornecem mais de 60 MB/s de dados úteis transferidos, assumindo que a CPU do host possa acompanhar a compactação e a descompactação.Observe que os dados criptografados sãosupostocomprimir extremamente mal, pois deve se assemelhar a ruído aleatório; você geralmente compactaria antes da criptografia, se planeja criptografar os dados; nesse caso, a compactação no nível do sistema de arquivos no lado criptografado não fará nenhum bem.