Projetar para a recuperação
 A carga de trabalho deve ser capaz de prever e se recuperar da maioria das falhas, de todas as magnitudes, com o mínimo de interrupção da experiência do usuário e dos objetivos de negócios da organização. |
|---|
Mesmo os sistemas altamente resilientes precisam de abordagens de preparação para desastres, tanto no projeto da arquitetura quanto nas operações de carga de trabalho. Na camada de dados, você deve ter estratégias que possam reparar o estado da carga de trabalho se houver corrupção.
Cenário de exemplo
A Contoso atualmente hospeda uma grande quantidade de dados em um banco de dados do SQL Server local e recentemente modernizou sua solução de análise de dados com os serviços do Azure.
A nova solução de análise utiliza o Azure Analysis Services, o Azure Data Factory, o Azure Synapse Analytics, o Power BI e as Máquinas Virtuais do Azure. Todos os usuários da solução são internos. Após considerar os requisitos de disponibilidade da solução, a equipe decide implementar a solução em uma única região.
Os dados são ingeridos utilizando o Azure Data Factory e processados antes de serem salvos no armazenamento do Analysis Services. Parte do processo requer um processo herdado do Windows, implantado em uma VM na nuvem.
Esteja preparado para desastres
Tenha planos de recuperação estruturados, testados e documentados que estejam alinhados com as metas de recuperação negociadas. Os planos devem abranger todos os componentes, além do sistema como um todo.
Um processo bem definido leva a uma recuperação rápida que pode evitar o impacto negativo sobre as finanças e a reputação do sua negócio. A realização de simulações de recuperação regulares testa o processo de recuperação de componentes do sistema, dados e etapas de failover e failback para evitar confusão quando o tempo e a integridade dos dados são as principais medidas de êxito.
Desafio da Contoso
- A solução é utilizada apenas internamente e não é considerada de crítica. Portanto, a equipe de carga de trabalho e os stakeholders do negócio concordam que recompilar a solução em uma região secundária é um modelo de recuperação suficiente no caso improvável de a região do Azure em que ela está implantada ser perdida ou de a solução inteira ficar indisponível por algum outro motivo.
- A equipe de carga de trabalho descreve como criar a solução em outra região em seu plano de DR, mas ainda não teve a oportunidade de realizar um detalhamento completo de recuperação de desastres.
Aplicando a abordagem e os resultados
- Após passar por uma interrupção regional, a equipe de resposta de DR consegue seguir as instruções do plano de DR para reimplantar a solução de análise em outra região.
- A equipe descobre lacunas nos planos de DR para algumas das operações necessárias para implantar a solução, e o plano é atualizado para tornar a recuperação mais eficiente no futuro.
- A equipe de carga de trabalho e os stakeholders concordam em acelerar o teste de DR planejado para garantir que o plano atualizado permita uma recuperação mais eficiente.
Endereçar dados com estado
Certifique-se de que você possa reparar os dados de todos os componentes com estado em seus destinos de recuperação.
Os backups são essenciais para fazer com que o sistema volte a funcionar usando um ponto de recuperação de confiança, como o último estado em bom estado conhecido.
Os backups imutáveis e transacionalmente consistentes garantem que os dados não possam ser alterados e que os dados restaurados não estejam corrompidos.
Desafio da Contoso
- A equipe de carga de trabalho decide mover os bancos de dados SQL para o Azure para reduzir os tempos de processamento de análise. Um dos bancos de dados é muito usado durante o processo de análise pelas VMs, portanto, a equipe precisa garantir que o estado do banco de dados possa ser recuperado com o menor RPO possível.
Aplicando a abordagem e os resultados
- Como os bancos de dados são grandes, com mais de 4 TB cada, a migração para o banco de dados SQL do Azure não é viável no curto prazo. Portanto, a equipe migra para VMs do Azure que executam o SQL Server 2022.
- A equipe decide usar a função de Backup Automatizado para todos os bancos de dados, inclusive os críticos, como o usado pelas VMs.
- Para os bancos de dados críticos, a equipe planeja usar a função de backup automatizado junto com a função de link da Instância Gerenciada para replicar ativamente os bancos de dados para uma Instância Gerenciada de SQL do Azure.
Implementar recursos automatizados de autocorreção no projeto
Os recursos de autocorreção são mecanismos que permitem que os componentes da carga de trabalho resolvam problemas automaticamente, recuperando os componentes afetados e, se necessário, fazendo a transição para uma infraestrutura redundante. Use padrões de projeto para adicionar resiliência à sua carga de trabalho por meio de mecanismos de autocorreção.
A automação da autocorreção ajuda a reduzir os riscos de fatores externos, como a intervenção humana, e encurta o ciclo de correção de falhas.
Desafio da Contoso
- O processo do Windows invocado pelo Azure Data Factory ao ingerir dados foi inicialmente implantado em várias VMs para aumentar a disponibilidade.
- Houve alguns casos em que o processo herdado do Windows travou, exigindo a reinicialização da VM. Embora o tempo de processamento geral tenha sido minimamente afetado (devido ao nível de redundância), a equipe gostaria de implementar uma solução que automatize a detecção da falha e a recuperação.
Aplicando a abordagem e os resultados
- A equipe decide implementar uma solução de Conjunto de dimensionamento de Máquinas Virtuais do Azure, que está configurada para implantar a Extensão de Integridade do Aplicativo para monitorar continuamente a integridade do processo da VM.
- Com o Reparo Automático de Instância habilitado, o conjunto de dimensionamento agora pode reparar o componente reiniciando a VM ou criando uma instância com base na mesma imagem.