Testando o Disaster Recovery do Veeam Kasten – Parte 2
Recentemente escrevi alguns artigos sobre o Veeam Kasten onde o objetivo é mostrar como testar algumas funcionalidades. A ideia geral consiste em construir um ambiente bem simples (o mais simples possível) e este artigo mantém a mesma ideia. Aqui podemos seguir os artigos anteriores para construir o ambiente kubernetes com K3s, Longhorn, NFS e Kasten. A unica diferença seria repetirmos isso duas vezes, uma para o ambiente produtivo e outro para o ambiente de DR, assim, será possível simular a recuperação de desastres com o Kasten. Requisito: construa os ambientes de produção e DR seguindo os artigos anteriores: três partes aqui.
O artigo ficou um pouco extenso, então dividi em duas partes:
Parte 1 – Testando o DR do Veeam Kasten – Configuração do DR
Parte 2 – Testando o DR do Veeam Kasten – Recuperação no ambiente de DR (você está aqui)
No Veeam Kasten do ambiente de DR é necessário garantir que o repositório onde habilitamos o DR está configurado e acessível, ele é fundamental para todo o processo funcionar. Então basta navegar até Settings > Restore Kasten. Selecionamos o repositório (location profile) e inserimos o Cluster ID e a frase de segurança (as duas informações fundamentais que falei para guardar em segurança, lembra?!).
Aqui é só selecionar o ponto de restauração. Lembrando que o Kasten DR irá sobrescrever os recursos existentes no Kasten do seu DR. Importante garantir que não existam dados importantes.
E aqui temos um resumo. Reforçando a importancia de seguir com atenção, visto que os dados atuais do Kasten de DR serão substituidos pelos dados que estão sendo restaurados agora. Sabendo que está tudo certo, basta clicar em Start Restore e depois em Confirm para o processo iniciar.
O tempo pode variar dependendo da quantidade de itens que serão restaurados. Aqui no laboratório levou menos de um minuto.
Uma vez que a restauração estiver concluida, é importante navegar até os pontos de restauração e validar se está tudo certo. Agora é necessário iniciar a restauração das aplicações. Perceba que agora o Type está como Imported. Se você navegar até as politicas, verá que elas também foram importadas. Dependendo do desastre que você está se recuperando, o tempo de permanência no ambiente de DR pode variar e por isso é fundamental continuar protegendo os aplicações.
A restauração basicamente consiste em criar o namespace e começar a restaurar os itens que vão garantir o completo funcionamento da aplicação: configmaps, deployments, ingress, serviceaccounts, services, storageclasses, PVCs etc.
As minhas duas super aplicações foram restauradas com sucesso.
Não tive nenhum um erro no processo, tudo foi restaurado perfeitamente, mas as aplicações não estão funcionando. Esse é um ponto interessante, pois não é incomum que as aplicações tenham dependências externas que estão além da proteção do Kasten. No nosso caso, a questão é o endereço de acesso, pois as aplicações apache-test-01 e 02 estavam configuradas como test1.caverna.local e teste2.caverna.local, respectivamente. Basicamente apontavam para o endereço do kubernetes de produção e agora é necessário alterar a entrada DNS para apontar para o kubernetes do ambiente de DR. Se a minha aplicação estivesse configurada com um balanceador de carga externo, eu não precisaria realizar esse processo manual. Enfim, esse é um pequeno alerta para lembrar que o planejamento do ambiente de recuperação de desastres deve ser pensado de forma abrangente, garantindo que todas as etapas sejam cobertas e validadas.
Para facilitar a compreensão segue abaixo um resumo de tudo o que fizemos aqui.
- Produção
- Proteção das aplicações
- Configuração do Kasten DR
- DR
- Restauração das configurações do ambiente produtivo
- Restauração das aplicações
- Ajustes (itens externos: entradas DNS, regra firewall etc)
É isso aí, pessoal Até a próxima!