Olá, recentemente me deparei com um problema interessante: configurar o armazenamento para fazer backup de um grande número de dispositivos de bloco.
Todas as semanas fazemos backup de todas as máquinas virtuais em nossa nuvem, por isso precisamos ser capazes de manter milhares de backups e fazê-lo da maneira mais rápida e eficiente possível.
Infelizmente, configurações padrão RAID5, RAID6 neste caso, não seremos autorizados a fazê-lo, uma vez que o processo de recuperação em discos tão grandes como o nosso será dolorosamente longo e provavelmente nunca terminará.
Vejamos quais alternativas existem:
— Semelhante ao RAID5, RAID6, mas com nível de paridade configurável. Neste caso, a reserva não é realizada bloco a bloco, mas para cada objeto separadamente. A maneira mais fácil de tentar a codificação de eliminação é expandir .
é um recurso ZFS atualmente não lançado. Ao contrário do RAIDZ, o DRAID possui um bloco de paridade distribuído e, durante a recuperação, usa todos os discos do array de uma só vez, o que o torna mais capaz de sobreviver a falhas de disco e se recuperar mais rapidamente após uma falha.
Servidor disponível Fujitsu Primergy RX300 S7 com processador Processador Intel Xeon E5-2650L 0 a 1.80 GHz, nove unidades de RAM Samsung DDR3-1333 8 Gb PC3L-10600R ECC registrado (M393B1K70DH0-YH9), prateleira de disco Supermicro SuperChassis 847E26-RJBOD1, conectado através Expansor LSI SAS2X36 duplo e 45 discos Seagage ST6000NM0115-1YZ110 em 6TB todo mundo.
Antes de decidirmos qualquer coisa, primeiro precisamos testar tudo adequadamente.
Para fazer isso, preparei e testei diversas configurações. Para fazer isso, usei o minio, que atuou como backend S3 e o lançou em diferentes modos com diferentes números de alvos.
Basicamente, o case minio foi testado em codificação de eliminação vs ataque de software com o mesmo número de discos e paridade de discos, e são eles: RAID6, RAIDZ2 e DRAID2.
Para referência: quando você inicia o minio com apenas um destino, o minio funciona no modo gateway S3, entregando seu sistema de arquivos local na forma de armazenamento S3. Se você iniciar o minio especificando vários alvos, o modo Erasure Coding será ativado automaticamente, o que espalhará os dados entre seus alvos enquanto fornece tolerância a falhas.
Por padrão, o minio divide os alvos em grupos de 16 discos, com 2 paridades por grupo. Aqueles. Dois discos podem falhar ao mesmo tempo sem perder dados.
Para testar o desempenho, usei 16 discos de 6 TB cada e gravei neles pequenos objetos de 1 MB, isso descreveu com mais precisão nossa carga futura, já que todas as ferramentas modernas de backup dividem os dados em blocos de vários megabytes e os gravam dessa forma.
Para realizar o benchmark, usamos o utilitário s3bench, lançado em um servidor remoto e enviando dezenas de milhares desses objetos para o minio em centenas de threads. Depois disso, tentei solicitá-los de volta da mesma maneira.
Os resultados do benchmark são mostrados na tabela a seguir:
Como podemos ver, o minio em seu próprio modo de codificação de eliminação tem um desempenho significativamente pior na gravação do que o minio executado no software RAID6, RAIDZ2 e DRAID2 na mesma configuração.
Separadamente eu teste minio em ext4 vs XFS. Surpreendentemente, para o meu tipo de carga de trabalho, o XFS acabou sendo significativamente mais lento que o ext4.
No primeiro lote de testes, o Mdadm mostrou superioridade sobre o ZFS, mas depois que você pode melhorar o desempenho do ZFS definindo as seguintes opções:
xattr=sa atime=off recordsize=1Me depois disso os testes com ZFS ficaram muito melhores.
Você também pode notar que o DRAID não oferece muito ganho de desempenho em relação ao RAIDZ, mas em teoria deveria ser muito mais seguro.
Nos dois últimos testes, também tentei transferir metadados (especiais) e ZIL (log) para o espelho do SSD. Mas a remoção de metadados não deu muito ganho na velocidade de gravação, e ao remover o ZIL, meu atingiu o teto com 100% de aproveitamento, então considero esse teste um fracasso. Não excluo que se eu tivesse drives SSD mais rápidos, talvez isso pudesse melhorar muito meus resultados, mas, infelizmente, não os tive.
No final, decidi usar DRAID e apesar do seu estado beta, é a solução de armazenamento mais rápida e eficiente no nosso caso.
Criei um DRAID2 simples em uma configuração com três grupos e dois sobressalentes distribuídos:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsOk, resolvemos o armazenamento, agora vamos falar sobre o que faremos backup. Aqui gostaria de falar imediatamente sobre três soluções que consegui experimentar, e são elas:
- garfo , uma solução especializada para backup de dispositivos de bloco, tem forte integração com o Ceph. Pode fazer diferenças entre instantâneos e formar um backup incremental a partir deles. Suporta um grande número de back-ends de armazenamento, incluindo locais e S3. Requer um banco de dados separado para armazenar a tabela hash de desduplicação. Desvantagens: escrito em python, possui um cli um pouco sem resposta.
- garfo , uma ferramenta de backup conhecida e comprovada, pode fazer backup de dados e desduplicá-los bem. Capaz de salvar backups localmente e em um servidor remoto via scp. O backup pode bloquear dispositivos se iniciado com o sinalizador --special, uma das desvantagens: ao criar um backup, o repositório fica completamente bloqueado, por isso é recomendável criar um repositório separado para cada máquina virtual, a princípio isso não é problema, felizmente eles são criados com muita facilidade.
é um projeto em desenvolvimento ativo, escrito em go, bastante rápido e suporta um grande número de back-ends de armazenamento, incluindo armazenamento local, scp, S3 e muito mais. Separadamente, gostaria de observar que existe um especialmente criado para restic, que permite exportar rapidamente o armazenamento para uso remoto. De todos os itens acima, eu gostei mais. Pode fazer backup do stdin. Quase não tem desvantagens perceptíveis, mas existem vários recursos:
-
Primeiramente tentei utilizá-lo no modo repositório geral para todas as máquinas virtuais (como Benji) e até funcionou muito bem, mas as operações de restauração demoraram muito, porque... Sempre antes da restauração, o restic tenta ler os metadados de todos os backups. Este problema foi facilmente resolvido, como aconteceu com o borg, criando um repositório separado para cada máquina virtual. Essa abordagem também provou ser muito eficaz para gerenciar backups. Repositórios separados podem ter uma senha separada para acessar os dados, e também não precisamos ter medo de que o repositório global possa quebrar de alguma forma. Você pode gerar novos repositórios tão facilmente quanto no backup do borg.
Em qualquer caso, a desduplicação é realizada apenas em relação à versão anterior do backup; o backup anterior é determinado pelo caminho do backup especificado, portanto, se você fizer backup de objetos diferentes do stdin para um repositório comum, não se esqueça de especificar o opção
--stdin-filenameou especifique explicitamente a opção sempre--parent.
-
Em segundo lugar, a recuperação para stdout leva muito mais tempo do que a recuperação para o sistema de arquivos devido à sua natureza paralela. No futuro, planejamos adicionar suporte mais próximo para backups de dispositivos de bloco.
-
Terceiro, atualmente é recomendado usar , porque a versão 0.9.6 possui um bug com recuperação demorada de arquivos grandes.
Para testar a eficácia do backup e a velocidade de gravação/restauração de um backup, criei um repositório separado e tentei fazer backup de uma pequena imagem de uma máquina virtual (21 GB). Dois backups foram realizados sem alterar o original, usando cada uma das soluções listadas para verificar o quão rápido/lento os dados desduplicados foram copiados.
Como podemos ver, o Borg Backup tem o melhor índice de eficiência de backup inicial, mas é inferior em termos de velocidade de gravação e restauração.
O Restic acabou sendo mais rápido que o Benji Backup, mas leva mais tempo para restaurar o stdout e, infelizmente, ainda não sabe como gravar diretamente em um dispositivo de bloco.
Depois de pesar todos os prós e contras, decidi descanso с servidor de descanso como a solução de backup mais conveniente e promissora.
Neste screencast você pode ver como um canal de 10 gigabits é completamente utilizado durante várias operações de backup executadas simultaneamente. Vale ressaltar que a reciclagem do disco não passa de 30%.
Fiquei mais do que satisfeito com a solução que recebi!
Fonte: habr.com