Como compactar até 90% de armazenamento de backups no armazenamento de objetos

Nossos clientes turcos nos pediram para configurar o backup do data center corretamente. Estamos fazendo projetos semelhantes na Rússia, mas foi aqui que a história foi mais sobre a pesquisa da melhor maneira de fazê-lo.

Dado: existe um armazenamento S3 local, existe o Veritas NetBackup, que adquiriu nova funcionalidade avançada para mover dados para armazenamentos de objetos agora com suporte à desduplicação e há um problema com espaço livre nesse armazenamento local.

Objetivo: fazer tudo para que o processo de armazenamento de backup seja rápido e barato.

Na verdade, antes disso, no S3, tudo era apenas arquivos, e essas eram moldes completas de máquinas críticas de data center. Isso não é muito otimizado, mas tudo funcionou no início. Agora é hora de descobrir e fazer o que é certo.

Na figura, chegamos ao seguinte:



Como você pode ver, o primeiro backup foi feito lentamente (70 Mb / s) e os backups subsequentes dos mesmos sistemas foram muito mais rápidos.

Na verdade, mais alguns detalhes sobre quais recursos existem.

Qual é o problema

Os clientes desejam fazer backup o mais rápido possível e armazenar o mais barato possível. É barato armazená-los melhor no armazenamento de objetos do tipo S3, porque eles são os mais baratos ao preço de manutenção por megabyte, de onde você pode fazer o rollback em um período de tempo razoável. Quando há muitos backups, não fica muito barato, porque a maior parte do armazenamento é ocupada por cópias dos mesmos dados. No caso de HaaS de colegas turcos, o armazenamento pode ser densificado em cerca de 80-90%. É claro que isso se aplica especificamente a suas especificidades, mas eu definitivamente contaria com pelo menos 50% da dedução.

Para resolver o problema, os principais fornecedores criaram gateways no Amazon S3. Todos os seus métodos são compatíveis com o S3 local se eles suportarem a API da Amazon. No data center turco, o backup é feito em nosso S3, bem como no "Compressor" T-III na Rússia, pois esse esquema de trabalho se mostrou bom conosco.

E o nosso S3 é totalmente compatível com os métodos de backup no Amazon S3. Ou seja, todas as ferramentas de backup que oferecem suporte a esses métodos permitem copiar tudo para esse armazenamento "pronto para uso".

O Veritas NetBackup criou um recurso do CloudCatalyst:



Ou seja, entre as máquinas que precisam de backup e o gateway, existe um servidor Linux intermediário, através do qual o tráfego de backup dos agentes do CPC passa e a desduplicação é feita em tempo real antes de transferi-los para o S3. Se antes havia 30 backups de 20 GB cada um com compactação, agora (devido à semelhança das máquinas) eles se tornaram 90% menores em volume. O mecanismo de deduplicação é usado da mesma maneira que quando armazenado em discos regulares usando o Netbackup.

Aqui está o que acontece antes do servidor intermediário:



Testamos e chegamos à conclusão de que, quando implementado em nossos data centers, isso economiza espaço nos armazenamentos S3 para nós e para os clientes. Como proprietário de data centers comerciais, é claro, cobramos pelo volume ocupado, mas ainda assim é muito lucrativo para nós - porque começamos a ganhar em lugares mais escaláveis ​​em software, e não no aluguel de ferro. Bem, isso é uma redução nos custos internos.


O acelerador permite reduzir o tráfego de agentes, porque somente as alterações de dados são transmitidas, ou seja, até os backups completos não são totalmente gerados, uma vez que o servidor de mídia coleta backups completos subsequentes de backups incrementais.

O servidor intermediário possui seu próprio repositório, onde grava um "cache" de dados e mantém a base para deduplicação.

Na arquitetura completa, fica assim:

1. O servidor mestre gerencia configurações, atualizações e muito mais, e está na nuvem.
2. O servidor de mídia (máquina intermediária * nix) deve estar localizado mais próximo dos sistemas redundantes em termos de disponibilidade da rede. Aqui, os backups são deduplicados de todas as máquinas redundantes.
3. Existem agentes nas máquinas redundantes que geralmente enviam para o servidor de mídia apenas o que não está em seu armazenamento.

Tudo começa com uma verificação completa - este é um backup completo completo. Nesse ponto, o servidor de mídia pega tudo, desduplica e transfere para o S3. A velocidade para o servidor de mídia é baixa, a partir dela - maior. A principal limitação é o poder de processamento do servidor.

Os backups a seguir são concluídos do ponto de vista de todos os sistemas, mas, na realidade, são algo como backups sintéticos completos. Ou seja, a transferência e a gravação reais no servidor de mídia são apenas os blocos de dados que ainda não foram vistos nos backups da VM antes. E a transferência e a gravação para o S3 são apenas os blocos de dados cujo hash não está no banco de dados de deduplicação do servidor de mídia. Se em palavras mais simples - que não havia VMs em nenhum backup antes.

Ao restaurar, o servidor de mídia solicita os objetos deduplicados necessários do S3, os reidrata e os passa para os agentes do CPC, ou seja, é necessário levar em consideração o volume de tráfego durante a restauração, que será igual ao volume real de dados que estão sendo restaurados.

Aqui está o que parece:




A integridade dos dados é garantida pela proteção do próprio S3 - existe uma boa redundância para proteger contra falhas de hardware, como um eixo de disco rígido morto.

O servidor de mídia precisa de 4 terabytes de cache - esta é a recomendação da Veritas para o tamanho mínimo. Melhor ainda, mas fizemos exatamente isso.

Sumário

Quando um parceiro lançou 20 GB no nosso S3, armazenamos 60 GB, porque fornecemos três vezes a reserva geográfica de dados. Agora, o tráfego é muito menor, o que é bom tanto para o canal quanto para o carregamento do armazenamento.

Nesse caso, as rotas são fechadas após a "grande Internet", mas você pode direcionar o tráfego através da VPN L2 pela Internet, mas é melhor definir o servidor de mídia para a entrada do provedor.

Se você estiver interessado em aprender sobre esses recursos em nossos data centers russos ou se tiver dúvidas sobre como implementá-lo, pergunte nos comentários ou no e-mail ekorotkikh@croc.ru.