Nossos clientes turcos nos pediram para configurar corretamente o backup para seu data center. Estamos realizando projetos semelhantes na Rússia, mas aqui a história foi mais sobre pesquisar a melhor forma de fazê-lo.
Dado: existe um armazenamento S3 local, existe o Veritas NetBackup, que adquiriu nova funcionalidade expandida para movimentação de dados para armazenamento de objetos, agora com suporte para desduplicação, e há um problema de espaço livre neste armazenamento local.
Tarefa: fazer de tudo para que o processo de armazenamento de cópias de segurança seja rápido e barato.
Na verdade, antes disso, tudo no S3 eram simplesmente arquivos, e estes eram moldes completos das máquinas críticas do data center. Ou seja, não está muito otimizado, mas tudo funcionou no início. Agora é hora de descobrir e fazer certo.
A imagem mostra aonde chegamos:
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 adiante há um pouco mais de detalhes sobre quais recursos existem.
Logs de backup para quem está pronto para ler meia página de dumpCompleto com nova digitalização
18 de dezembro de 2018 12h09min43s - O acelerador Info bpbkar (pid = 4452) enviou 14883996160 bytes de 14883994624 bytes para o servidor, otimização 0.0%
18 de dezembro de 2018 12h10min07s - Informações NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO (fluxo multithread usado) para (NBCC): verificado: 14570817 KB, CR enviado: 1760761 KB, CR enviado por FC: 0 KB, desduplicação: 87.9%, cache desabilitado
completo
18 de dezembro de 2018 12h13min18s - O acelerador Info bpbkar (pid = 2864) enviou 181675008 bytes de 14884060160 bytes para o servidor, otimização 98.8%
18 de dezembro de 2018 12h13h40 - Informações NBCC (pid = 23527) StorageServer = PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO para (NBCC): verificado: 14569706 KB, CR enviado: 45145 KB, CR enviado por FC: 0 KB, desduplicação: 99.7%, cache desabilitado
Incremental
18 de dezembro de 2018 12h15min32s - O acelerador Info bpbkar (pid = 792) enviou 9970688 bytes de 14726108160 bytes para o servidor, otimização 99.9%
18 de dezembro de 2018 12h15h53 - Informações NBCC (pid = 23656) StorageServer = PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO para (NBCC): verificado: 14383788 KB, CR enviado: 15700 KB, CR enviado por FC: 0 KB, desduplicação: 99.9%, cache desabilitado
completo
18 de dezembro de 2018 12h18min02s - O acelerador Info bpbkar (pid = 3496) enviou 171746816 bytes de 14884093952 bytes para o servidor, otimização 98.8%
18 de dezembro de 2018 12h18h24 - Informações NBCC (pid = 23878) StorageServer = PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO para (NBCC): verificado: 14569739 KB, CR enviado: 34120 KB, CR enviado por FC: 0 KB, desduplicação: 99.8%, cache desabilitado
Qual é o problema
Os clientes desejam fazer backups com a maior frequência possível e armazená-los o mais barato possível. É melhor armazená-los de forma barata em armazenamentos de objetos como o S3, porque eles são os mais baratos em termos de custo de serviço por Megabyte, de onde você pode reverter um backup em um tempo razoável. Quando há muito backup, ele não fica muito barato, pois a maior parte do armazenamento é ocupada por cópias dos mesmos dados. No caso do HaaS dos colegas turcos, o armazenamento pode ser densificado em aproximadamente 80-90%. É claro que isso se refere especificamente às especificidades deles, mas eu definitivamente contaria com pelo menos 50% do avô.
Para resolver o problema, os principais fornecedores já criaram gateways para o Amazon S3. Todos os seus métodos são compatíveis com S3 local, desde que suportem a API Amazon. No data center turco, o backup é feito no nosso S3, bem como no “Compressor” T-III na Rússia, já que esse esquema de trabalho funcionou bem para nós.
E nosso S3 é totalmente compatível com os métodos de backup do Amazon S3. Ou seja, todas as ferramentas de backup que suportam esses métodos permitem copiar tudo para esse armazenamento “pronto para usar”.
O Veritas NetBackup adicionou o recurso CloudCatalyst:
Ou seja, entre as máquinas que precisam de backup e o gateway, existe um servidor Linux intermediário por onde passa o tráfego de backup dos agentes SRK e é desduplicado em tempo real antes de ser transferido para o S3. Se antes eram 30 backups de 20 GB com compactação, agora (devido à semelhança das máquinas) seu volume ficou 90% menor. O mecanismo de desduplicação é usado da mesma forma que no armazenamento em discos normais usando o Netbackup.
Aqui está o que acontece antes do servidor intermediário:
Testamos e concluímos que quando implementado em nossos data centers, isso economiza espaço no armazenamento S3 para nós e para os clientes. Como proprietários de data centers comerciais, é claro que cobramos de acordo com o volume ocupado, mas ainda assim é muito lucrativo para nós também - porque começamos a ganhar dinheiro em locais mais escaláveis em software, e não no aluguel de hardware. Bem, e isso é uma redução de custos internos.
Logs228 trabalhos (0 em fila 0 ativos 0 aguardando nova tentativa 0 suspensos 0 incompletos 228 concluídos — 13 selecionados)
(Filtro aplicado [13])
Tipo de ID do trabalho Estado Estado Detalhes Status Política do trabalho Agendamento do trabalho Cliente Servidor de mídia Hora de início Tempo decorrido Hora de término Unidade de armazenamento Tentativa de operação Kilobytes Arquivos Nome do caminho % concluído (estimado) Proprietário do PID do trabalho Copiar ID do trabalho pai KB/seg Início ativo Ativo decorrido Sessão de perfil do Vault do robô Mídia de identificação para ejetar movimentação de dados fora do host Tipo Prioridade mestre Taxa de desduplicação Instância de otimização do acelerador de transporte ou host de compartilhamento de banco de dados
- 1358 Snapshot concluído 0 VMware - NGNCloudADC NBCC 18 de dezembro de 2018 12h16:19 00:02:18 18 de dezembro de 2018 12h18:37 STU_DP_S3_****backup 1 100% root 1358 18 de dezembro de 2018 12 :16:27 PM 00:02:10 Disco de recuperação instantânea padrão WIN-************* 0
1360 Backup concluído 0 VMware completo NGNCloudADC NBCC 18 de dezembro de 2018 12h16:48 00:01:39 18 de dezembro de 2018 12h18:27 STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098, 18 2018 de dezembro , 12 16h48:00 01:39:0 Disco de recuperação instantânea padrão WIN-************* 99.8 99% XNUMX%
1352 Snapshot concluído 0 VMware - NGNCloudADC NBCC 18 de dezembro de 2018 12h14:04 00:02:01 18 de dezembro de 2018 12h16:05 STU_DP_S3_****backup 1 100% root 1352 18 de dezembro de 2018 12: 14:14 00:01:51 Disco de recuperação instantânea padrão WIN-************* 0
1354 Backup concluído 0 VMware incremental NGNCloudADC NBCC 18 de dezembro de 2018 12h14:34 00:01:21 18 de dezembro de 2018 12h15:55 STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 de dezembro 2018 , 12 14:34:00 01:21:0 Disco de recuperação instantânea padrão WIN-************* 99.9 100% XNUMX%
1347 Snapshot concluído 0 VMware - NGNCloudADC NBCC 18 de dezembro de 2018 12h11:45 00:02:08 18 de dezembro de 2018 12h13:53 STU_DP_S3_****backup 1 100% root 1347 18 de dezembro de 2018 12: 11:45 00:02:08 Disco de recuperação instantânea padrão WIN-************* 0
1349 Backup concluído 0 VMware completo NGNCloudADC NBCC 18 de dezembro de 2018 12h12:02 00:01:41 18 de dezembro de 2018 12h13:43 STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319, 18 2018 de dezembro , 12 12h02:00 01:41:0 Disco de recuperação instantânea padrão WIN-************* 99.7 99% XNUMX%
1341 Snapshot concluído 0 VMware - NGNCloudADC NBCC 18 de dezembro de 2018 12h05:28 00:04:53 18 de dezembro de 2018 12h10:21 STU_DP_S3_****backup 1 100% root 1341 18 de dezembro de 2018 12: 05:28 00:04:53 Disco de recuperação instantânea padrão WIN-************* 0
1342 Backup concluído 0 VMware Full_Rescan NGNCloudADC NBCC 18 de dezembro de 2018 12h05:47 00:04:24 18 de dezembro de 2018 12h10:11 STU_DP_S3__****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 dezembro 2018 de outubro de 12 05h47:00 04:24:0 Disco de recuperação instantânea padrão WIN-************* 87.9 0% XNUMX%
1339 Snapshot concluído 150 VMware - NGNCloudADC NBCC 18 de dezembro de 2018 11:05:46 00:00:53 18 de dezembro de 2018 11:06:39 STU_DP_S3__****backup 1 100% root 1339 18 de dezembro de 2018 11: 05:46 00:00:53 Disco de recuperação instantânea padrão WIN-************* 0
1327 Snapshot concluído 0 VMware - *******.********.cloud NBCC 17 de dezembro de 2018 12h54:42 05h51:38 17 de dezembro de 2018 6h46:20 STU_DP_S3_****backup 1 100% root 1327 17 de dezembro de 2018 12:54:42 PM 05:51:38 Disco de recuperação instantânea padrão WIN-************* 0
1328 Backup concluído 0 VMware completo *******.********.cloud NBCC 17 de dezembro de 2018 12h55:10 05h29:21 17 de dezembro de 2018 6h24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 de dezembro de 2018 12h55:10 05:29:21 Disco de recuperação instantânea Padrão WIN-************* 0 87.9% 0%
1136 Snapshot concluído 0 VMware - *******.********.cloud NBCC 14 de dezembro de 2018 4h48:22 04h05:16 14 de dezembro de 2018 8h53:38 STU_DP_S3_****backup 1 100% root 1136 14 de dezembro de 2018 4:48:22 PM 04:05:16 Disco de recuperação instantânea padrão WIN-************* 0
1140 Backup concluído 0 VMware Full_Scan *******.**********.cloud NBCC 14 de dezembro de 2018 4:49:14 03:49:58 14 de dezembro de 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 de dezembro de 2018 4:49:14 03:49:58 Disco de recuperação instantânea padrão WIN-************* 0 45.2% 0%
O acelerador permite reduzir o tráfego dos agentes, pois Apenas as alterações de dados são transmitidas, ou seja, mesmo os backups completos não são carregados inteiramente, uma vez que o servidor de mídia coleta backups completos subsequentes a partir de backups incrementais.
O servidor intermediário possui armazenamento próprio, onde grava um “cache” de dados e mantém um banco de dados para desduplicação.
A arquitetura completa fica assim:
- O servidor mestre gerencia configurações, atualizações, etc. e está localizado na nuvem.
- O servidor de mídia (máquina *nix intermediária) deve estar localizado mais próximo dos sistemas redundantes em termos de acessibilidade à rede. Aqui, é feita a desduplicação de backups de todas as máquinas reservadas.
- Nas máquinas de backup existem agentes que geralmente enviam ao 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 e 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, mas é maior. A principal limitação é o poder de computação do servidor.
Os backups a seguir são completos do ponto de vista de todos os sistemas, mas na realidade são algo como backups completos sintéticos. Ou seja, a transferência e gravação reais para o servidor de mídia ocorrem apenas daqueles blocos de dados que ainda não foram encontrados em backups de VM antes. E apenas os blocos de dados cujo hash não está no banco de dados de desduplicação do servidor de mídia são transferidos e registrados no S3. Em palavras mais simples, isso é algo que nunca foi visto antes em nenhum backup de uma única VM.
Durante a restauração, o servidor de mídia solicita os objetos desduplicados necessários do S3, reidrata-os e transfere-os para os agentes IRB, 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 a serem restaurados.
Aqui está o que parece:
E aqui está outro pedaço de registro169 trabalhos (0 em fila 0 ativos 0 aguardando nova tentativa 0 suspensos 0 incompletos 169 concluídos — 1 selecionados)
Tipo de ID do trabalho Estado Estado Detalhes Status Política do trabalho Agendamento do trabalho Cliente Servidor de mídia Hora de início Tempo decorrido Hora de término Unidade de armazenamento Tentativa de operação Kilobytes Arquivos Nome do caminho % concluído (estimado) Proprietário do PID do trabalho Copiar ID do trabalho pai KB/seg Início ativo Ativo decorrido Sessão de perfil do Vault do robô Mídia de identificação para ejetar movimentação de dados fora do host Tipo Prioridade mestre Taxa de desduplicação Instância de otimização do acelerador de transporte ou host de compartilhamento de banco de dados
- 1372 Restauração concluída 0 NBPR01 NBCC 19 de dezembro de 2018 1h05:58 00:04:32 19 de dezembro de 2018 1h10:30 1 14,380,577 1 100% 8548 ROOT 1372 70,567 19 de dezembro de 2018 1:06 :00 PM 00:04:30 WIN - *********** 90000
A integridade dos dados é garantida pela proteção do próprio S3 - há uma boa redundância para proteger contra falhas de hardware, como eixo morto do disco rígido.
O servidor de mídia precisa de 4 TB de cache – esta é a recomendação de tamanho mínimo da Veritas. Mais é melhor, mas foi o que fizemos.
Total
Quando um parceiro colocou 3 GB em nosso S20, armazenamos 60 GB, porque fornecemos tripla reserva geográfica de dados. Agora há muito menos tráfego, o que é bom tanto para o canal quanto para as tarifas de armazenamento.
Nesse caso, as rotas são fechadas além da “grande Internet”, mas é possível direcionar o tráfego através da VPN L2 pela Internet, mas é melhor instalar o servidor de mídia antes da entrada do provedor.
Se você estiver interessado em aprender sobre esses recursos em nossos data centers russos ou tiver dúvidas sobre a implementação em casa, pergunte nos comentários ou por e-mail [email protegido].
Fonte: habr.com