Nossos clientes turcos nos pediram para configurar corretamente o backup para o data center. Realizamos projetos semelhantes na Rússia, mas aqui a história foi mais sobre explorar como realizar isso da melhor maneira.
Dado: há um armazenamento S3 local, há Veritas NetBackup, que adquiriu uma nova funcionalidade avançada para mover dados para armazenamentos de objetos, agora com suporte a deduplicação, e há um problema com o espaço livre nesse armazenamento local.
Tarefa: fazer com que o processo de armazenamento de backups seja rápido e barato.
Na verdade, antes disso, tudo no S3 era simplesmente armazenado como arquivos, e eram cópias completas de máquinas críticas do data center. Ou seja, não era exatamente otimizado, mas funcionava desde o início. Agora, chegou a hora de organizar tudo e fazer da maneira certa.
Na imagem, o que conseguimos:
Como pode ser visto, o primeiro backup foi realizado lentamente (70 MB/s), enquanto os backups subsequentes dos mesmos sistemas foram significativamente mais rápidos.
Na verdade, aqui estão mais detalhes sobre as particularidades.
Logs de backups para quem está disposto a ler páginas e páginas de dumpCompleto com re-scaneamento
18 de dezembro de 2018 12:09:43 PM — Info bpbkar (pid=4452) acelerador enviou 14883996160 bytes de 14883994624 bytes para o servidor, otimização 0,0%
18 de dezembro de 2018 12:10:07 PM — Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO (fluxo multi-threaded utilizado) para (NBCC): escaneado: 14570817 KB, CR enviado: 1760761 KB, CR enviado via FC: 0 KB, dedup: 87,9%, cache desativada
Completo
18 de dezembro de 2018 12:13:18 PM — Info bpbkar (pid=2864) acelerador enviou 181675008 bytes de 14884060160 bytes para o servidor, otimização 98,8%
18 de dezembro de 2018 12:13:40 PM — Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO para (NBCC): escaneado: 14569706 KB, CR enviado: 45145 KB, CR enviado via FC: 0 KB, dedup: 99,7%, cache desativada
Incremental
18 de dezembro de 2018 12:15:32 PM — Info bpbkar (pid=792) acelerador enviou 9970688 bytes de 14726108160 bytes para o servidor, otimização 99,9%
18 de dezembro de 2018 12:15:53 PM — Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO para (NBCC): escaneado: 14383788 KB, CR enviado: 15700 KB, CR enviado via FC: 0 KB, dedup: 99,9%, cache desativada
Completo
18 de dezembro de 2018 12:18:02 PM — Info bpbkar (pid=3496) acelerador enviou 171746816 bytes de 14884093952 bytes para o servidor, otimização 98,8%
18 de dezembro de 2018 12:18:24 PM — Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Relatório=Estatísticas PDDO para (NBCC): escaneado: 14569739 KB, CR enviado: 34120 KB, CR enviado via FC: 0 KB, dedup: 99,8%, cache desativada
Qual é o problema
Os clientes querem fazer backups com a maior frequência possível e armazená-los da forma mais barata. O armazenamento mais econômico é em repositórios de objetos como o S3, pois eles têm o menor custo operacional por megabyte, a partir do qual se pode restaurar o backup em prazos razoáveis. Quando há muitos backups, isso pode se tornar caro, pois a maior parte do armazenamento é ocupada por cópias dos mesmos dados. No caso do HaaS dos colegas turcos, o armazenamento pode ser compactado em cerca de 80-90%. Claro que isso se refere especificamente à sua situação, mas eu definitivamente esperaria um mínimo de 50% de deduplicação.
Para resolver o problema, os principais fornecedores há muito tempo implementaram gateways para o S3 da Amazon. Todos os seus métodos são compatíveis com S3 locais, se estes suportam a API da Amazon. No data center turco, o backup é realizado em nosso S3, assim como no T-III 'Compressor' na Rússia, uma vez que esse esquema de trabalho se mostrou eficaz para nós.
O nosso S3 é totalmente compatível com os métodos de backup do Amazon S3. Isso significa que todas as ferramentas de backup que suportam esses métodos permitem copiar tudo para um repositório semelhante 'pronto para uso'.
No Veritas NetBackup, foi criada a funcionalidade CloudCatalyst:
Ou seja, entre as máquinas que precisam ser feitas backup e o gateway, foi inserido um servidor Linux intermediário, pelo qual passa o tráfego de backup dos agentes do SRK, realizando a deduplicação 'em tempo real' antes de enviá-los para o S3. Se antes havia 30 backups de 20 GB com compressão, agora (devido à semelhança das máquinas) o volume foi reduzido em 90%. O mecanismo de deduplicação utilizado é o mesmo que é aplicado ao armazenamento em discos comuns com os recursos do NetBackup.
Aqui está o que acontece antes do servidor intermediário:
Nós testamos e concluímos que a implementação em nossos data centers gera economia de espaço nos repositórios S3 para nós e para os clientes. Como proprietário de data centers comerciais, claro que cobramos com base no volume ocupado, mas ainda assim isso nos beneficia muito — porque começamos a ganhar em locais mais escaláveis no software, e não na locação de hardware. Além disso, isso reduz os custos internos.
Logs228 Jobs (0 Em espera 0 Ativos 0 Aguardando Retentativa 0 Suspensos 0 Incompletos 228 Concluídos — 13 selecionados)
(Filtro Aplicado [13])
Identificação do Trabalho Tipo Estado Detalhes do Estado Status Política do Trabalho Programação do Trabalho Cliente Mídia Servidor Hora de Início Tempo Decorrido Hora de Fim Unidade de Armazenamento Tentativa Operação Kilobytes Arquivos Caminho % Completo (Estimativa) PID do Trabalho Proprietário Código do Trabalho Pai KB/Sec Ativo Início Ativo Decorrido Perfil do Robô Vault ID da Sessão Mídia para Ejetar Movimento de Dados Tipo Off-Host Prioridade Mestre Taxa de Deduplicação Otimização do Acelerador Instância ou Banco de Dados Compartilhado Hospedeiro
— 1358 Instantâneo Concluído 0 VMware — NGNCloudADC NBCC 18 de Dezembro de 2018 12:16:19 PM 00:02:18 18 de Dezembro de 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 de Dezembro de 2018 12:16:27 PM 00:02:10 Recuperação Instantânea Disco Padrão WIN-*********** 0
1360 Backup Concluído 0 VMware Completo NGNCloudADC NBCC 18 de Dezembro de 2018 12:16:48 PM 00:01:39 18 de Dezembro de 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18 de Dezembro de 2018 12:16:48 PM 00:01:39 Recuperação Instantânea Disco Padrão WIN-*********** 0 99,8% 99%
1352 Instantâneo Concluído 0 VMware — NGNCloudADC NBCC 18 de Dezembro de 2018 12:14:04 PM 00:02:01 18 de Dezembro de 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 de Dezembro de 2018 12:14:14 PM 00:01:51 Recuperação Instantânea Disco Padrão WIN-*********** 0
1354 Backup Concluído 0 VMware Incremental NGNCloudADC NBCC 18 de Dezembro de 2018 12:14:34 PM 00:01:21 18 de Dezembro de 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 de Dezembro de 2018 12:14:34 PM 00:01:21 Recuperação Instantânea Disco Padrão WIN-*********** 0 99,9% 100%
1347 Instantâneo Concluído 0 VMware — NGNCloudADC NBCC 18 de Dezembro de 2018 12:11:45 PM 00:02:08 18 de Dezembro de 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 de Dezembro de 2018 12:11:45 PM 00:02:08 Recuperação Instantânea Disco Padrão WIN-*********** 0
1349 Backup Concluído 0 VMware Completo NGNCloudADC NBCC 18 de Dezembro de 2018 12:12:02 PM 00:01:41 18 de Dezembro de 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18 de Dezembro de 2018 12:12:02 PM 00:01:41 Recuperação Instantânea Disco Padrão WIN-*********** 0 99,7% 99%
1341 Instantâneo Concluído 0 VMware — NGNCloudADC NBCC 18 de Dezembro de 2018 12:05:28 PM 00:04:53 18 de Dezembro de 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 de Dezembro de 2018 12:05:28 PM 00:04:53 Recuperação Instantânea Disco Padrão WIN-*********** 0
1342 Backup Concluído 0 VMware Reescaneamento Completo NGNCloudADC NBCC 18 de Dezembro de 2018 12:05:47 PM 00:04:24 18 de Dezembro de 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 de Dezembro de 2018 12:05:47 PM 00:04:24 Recuperação Instantânea Disco Padrão WIN-*********** 0 87,9% 0%
1339 Instantâneo Concluído 150 VMware — NGNCloudADC NBCC 18 de Dezembro de 2018 11:05:46 AM 00:00:53 18 de Dezembro de 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 18 de Dezembro de 2018 11:05:46 AM 00:00:53 Recuperação Instantânea Disco Padrão WIN-*********** 0
1327 Instantâneo Concluído 0 VMware — *******.********.cloud NBCC 17 de Dezembro de 2018 12:54:42 PM 05:51:38 17 de Dezembro de 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 17 de Dezembro de 2018 12:54:42 PM 05:51:38 Recuperação Instantânea Disco Padrão WIN-*********** 0
1328 Backup Concluído 0 VMware Completo *******.********.cloud NBCC 17 de Dezembro de 2018 12:55:10 PM 05:29:21 17 de Dezembro de 2018 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 de Dezembro de 2018 12:55:10 PM 05:29:21 Recuperação Instantânea Disco Padrão WIN-*********** 0 87,9% 0%
1136 Instantâneo Concluído 0 VMware — *******.********.cloud NBCC 14 de Dezembro de 2018 4:48:22 PM 04:05:16 14 de Dezembro de 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 14 de Dezembro de 2018 4:48:22 PM 04:05:16 Recuperação Instantânea Disco Padrão WIN-*********** 0
1140 Backup Concluído 0 VMware Completo_Scan *******.********.cloud NBCC 14 de Dezembro de 2018 4:49:14 PM 03:49:58 14 de Dezembro de 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 de Dezembro de 2018 4:49:14 PM 03:49:58 Recuperação Instantânea Disco Padrão WIN-*********** 0 45,2% 0%
O acelerador permite reduzir o tráfego dos agentes, pois só são transmitidas as alterações de dados, ou seja, mesmo os backups completos não são enviados integralmente, uma vez que o servidor de mídia coleta os backups completos subsequentes a partir dos backups incrementais.
O servidor intermediário possui seu próprio armazenamento, onde escreve o "cache" de dados e mantém um banco de dados para deduplicação.
Na arquitetura completa fica assim:
- O servidor mestre gerencia a configuração, atualizações e outros, encontrando-se na nuvem.
- O servidor de mídia (máquina intermediária *nix) deve estar o mais próximo possível dos sistemas a serem reservados em termos de acessibilidade de rede. Aqui é feita a deduplicação dos backups de todas as máquinas a serem reservadas.
- Nas máquinas a serem reservadas, existem agentes que, em geral, enviam ao servidor de mídia apenas o que não está em seu armazenamento.
Tudo começa com uma varredura completa — isso é um backup completo legítimo. Nesse momento, o servidor de mídia captura tudo, realiza a deduplicação e transmite para S3. A velocidade até o servidor de mídia é baixa, mas a partir dele — um pouco mais alta. A principal limitação é a capacidade computacional do servidor.
Os backups seguintes são realizados sob a perspectiva de todos os sistemas como completos, mas na prática, são algo como backups completos sintéticos. Ou seja, a transmissão e gravação real no servidor de mídia ocorre apenas para aqueles blocos de dados que ainda não foram encontrados em backups de VM anteriores. A transmissão e gravação no S3 ocorre apenas para aqueles blocos de dados cujo hash não está no banco de dados de deduplicação do servidor de mídia. Em termos mais simples — o que não foi encontrado em nenhum backup de nenhuma VM antes.
Durante a restauração, o servidor de mídia solicita os objetos deduplicados necessários do S3, reidrata-os e os envia aos agentes do SRK, ou seja, deve-se considerar o volume de tráfego durante a restauração, que será igual ao volume real de dados a serem recuperados.
Aqui está como isso se parece:
E aqui mais um trecho dos logs169 Jobs (0 Enfileirados 0 Ativos 0 Aguardando Retentativa 0 Suspensos 0 Incompletos 169 Concluídos — 1 selecionado)
Identificação do Trabalho Tipo Estado Detalhes do Estado Status Política do Trabalho Programação do Trabalho Cliente Mídia Servidor Hora de Início Tempo Decorrido Hora de Fim Unidade de Armazenamento Tentativa Operação Kilobytes Arquivos Caminho % Completo (Estimativa) PID do Trabalho Proprietário Código do Trabalho Pai KB/Sec Ativo Início Ativo Decorrido Perfil do Robô Vault ID da Sessão Mídia para Ejetar Movimento de Dados Tipo Off-Host Prioridade Mestre Taxa de Deduplicação Otimização do Acelerador Instância ou Banco de Dados Compartilhado Hospedeiro
— 1372 Restauração Concluída 0 nbpr01 NBCC 19 de Dez, 2018 13:05:58 00:04:32 19 de Dez, 2018 13:10:30 1 14.380.577 1 100% 8548 root 1372 70.567 19 de Dez, 2018 13:06:00 00:04:30 WIN-*********** 90000
A integridade dos dados é garantida pela proteção do próprio S3 — há uma boa redundância para proteção contra falhas de hardware como um disco rígido com problema.
Mídia-servidor são necessários 4 TB de cache — esta é a recomendação da Veritas para o volume mínimo. Melhor ter mais, mas fizemos exatamente assim.
Resultado
Quando o parceiro enviou 20 GB para o nosso S3, armazenamos 60 GB, pois garantimos um backup geográfico triplo dos dados. Agora, o tráfego é muito menor, o que é bom tanto para a largura de banda quanto para a cobrança de armazenamento.
Neste caso, as rotas estão fechadas fora da ‘grande Internet’, mas é possível direcionar o tráfego também através VPN do L2 pela Internet, mas é melhor colocar o servidor de mídia antes da entrada do provedor.
Se você estiver interessado em saber mais sobre esses recursos em nossos data centers na Rússia ou tiver dúvidas sobre a implementação em sua empresa — sinta-se à vontade para perguntar nos comentários ou pelo e-mail ekorotkikh@croc.ru.
Fonte: habr.com
