Planejamento e criação de um plano que não está pronto para a produção

A capacidade da infraestrutura de DR deve ser capaz de gerenciar as cargas de trabalho de produção, a menos que seu plano determine o contrário. A implementação da DR com recursos que não correspondem ao seu ambiente de produção pode parecer atraente do ponto de vista do custo, mas pode tornar os efeitos de um desastre muito mais graves.

Ao planejar e implementar seu ambiente de recuperação de desastres, considere seus próprios requisitos de resiliência. Não tente cortar custos reduzindo os requisitos de alta disponibilidade da implementação de DR. Se ocorrer um desastre, as cargas de trabalho de produção precisam de um ambiente resiliente. Os serviços na nuvem são dimensionáveis, portanto, você pode adicionar capacidade posteriormente, mas o aumento da demanda regional causado pelo desastre pode resultar em escassez de capacidade em curto prazo.

Esquecer os pontos únicos de falha não técnicos

Os pontos únicos de falha (SPOF) podem estar em qualquer lugar em uma solução, não apenas na tecnologia. Sua solução pode depender de pessoas, fornecedores, provedores e outras dependências externas. Identifique claramente seus SPOFs e reduza suas dependências. Esteja preparado para descobrir os SPOFs durante as primeiras sessões de seu teste de recuperação de desastre.

Entre os SPOFs, o risco do provedor é uma condição a considerar em seu plano DR. Quando você tem a produção e o DR no mesmo provedor, sua condição de risco é aumentada e deve ser cuidadosamente considerada.

Tendo apenas um plano A

Os desastres podem assumir várias formas, portanto, o planejamento para um cenário específico de desastre o deixa vulnerável a outros. Ao conceber o plano de DR, considere vários cenários de desastres diferentes e demonstre como o plano é flexível.

Testar mal seu plano

Uma solução de DR não testada aumenta as chances de você encontrar um obstáculo quando o sucesso é o mais importante. Os testes são essenciais para validar se você tem uma solução funcional. As condições que você testa também são importantes e exigem a criação de vários cenários de teste.

A realização de um teste de DR por meio de um encerramento planejado da operação em um local e uma reinicialização bem organizada no outro ajuda a garantir que o teste de DR funcione. No entanto, um simples desligamento total nem sempre acontece em uma emergência real.

Projete seus testes para imitar as possíveis condições de emergência o mais próximo possível, simulando uma "condição de desastre contínuo", em que sua carga de trabalho é progressivamente afetada como resultado da emergência. O impacto progressivo testa a resiliência da sua solução e fornece informações sobre a sua capacidade de resistir às condições de estresse.

Alta disponibilidade

A alta disponibilidade não equivale à recuperação de desastres. O site IBM Cloud recomenda que os clientes verifiquem se suas implantações estão altamente disponíveis, aproveitando as regiões multizonas (MZRs) do site IBM Cloud. Cada MZR tem um mínimo de três zonas, que são data centers altamente interconectados, mas operacionalmente separados. Muitas vezes, os problemas e as interrupções afetam apenas uma única zona, não toda a região. A implementação de cargas de trabalho por padrão em todas as zonas em um MZR pode diminuir o tempo de inatividade e a necessidade de chamar um desastre. O failover para uma segunda região pode ser um processo importante, assim como o failover de volta, portanto, tome o máximo de medidas possíveis para evitar a necessidade de fazer isso. No entanto, os MZRs não evitam desastres, como corrupção de dados ou danos maliciosos.

Regulamentação e conformidade

Algumas cargas de trabalho e dados estão sujeitos a normas rígidas de conformidade e regulamentação do setor, o que pode afetar o local físico em que podem ser executados ou armazenados. Quando você escolher um local para um site de recuperação de desastres, verifique se a região escolhida atende a todas as regulamentações e conformidade necessárias. Os locais onde você escolhe replicar os dados também devem ser verificados.

Os compartimentos inter-regionais Object Storage oferecem uma maneira de replicar dados para diferentes regiões, mas use com cuidado se seus dados estiverem sujeitos a restrições territoriais. Verifique se seus dados não são transferidos para uma região em um país ou território que viole as regras de conformidade organizacionais ou do setor.

Capacidade na região de recuperação de desastres

Os desastres podem afetar muitos clientes, que, por sua vez, adotam seus planos de recuperação de desastres. A demanda adicional pode colocar uma pressão severa na capacidade de uma ou mais regiões mais próximas da região que falhou. Isso pode resultar em uma escassez de recursos disponíveis. Por exemplo, se o site us-south falhar, é provável que muitos clientes optem primeiro pela recuperação na região us-east. Se o site eu-gb falhar, espera-se que mais demanda recaia sobre o site eu-de.

Em caso de alta demanda causada por um desastre, sua primeira opção de infraestrutura pode não estar disponível para provisionamento em sua região de recuperação. Isso inclui perfis populares de VSI de VPC. Não se esqueça de levar em consideração várias arquiteturas para o seu aplicativo que podem ser responsáveis por situações em que um perfil VSI alternativo é necessário. Se o seu aplicativo não tolerar o uso de uma infraestrutura alternativa, considere a possibilidade de criar ou reservar a capacidade necessária na região de recuperação de desastres de sua escolha, antecipando-se a um desastre, ou considere outros locais mais distantes para evitar problemas de capacidade.

Verifique se seus backups podem ser restaurados na região escolhida. Por exemplo, os bancos de dados não podem ser restaurados em regiões que ultrapassam os limites de conformidade. Como prática recomendada, certifique-se de testar o tempo de restauração dos dados e de levar em conta que o tempo pode ser estendido no caso de um grande desastre que afete toda uma região, pois muitos clientes tentarão restaurar os dados ao mesmo tempo.

Conectividade

Os serviços de rede podem levar algum tempo para serem provisionados e configurados, pois podem exigir atividade de terceiros ou instalação adicional de infraestrutura física. Ao criar um plano de DR, considere os tempos de espera para esses serviços. É ideal provisionar esses serviços com antecedência:

• Direct Link, Transit Gateway Local e Transit Gateway Global
• VPC Edge
• Gateway VPN e conexões
• DNS privado com configuração de VPC de Hub e Spoke de DNS
• VPE para serviços compartilhados
• Regras de restrição baseadas em contexto
• Balanceador de carga global no DNS privado
• CIS com o público LBaaS, Caminho privado do VPE e PPNLB

Aproveite a VPC landing zone arquitetura implementável e a arquitetura de referência do FS Cloud para preparar sua conectividade com antecedência ou durante uma recuperação de desastres.

Failover parcial ou total

A nuvem é composta de diferentes serviços, e os aplicativos podem depender de vários componentes que funcionam juntos. Normalmente, os planos de recuperação de desastres se preparam para falhas catastróficas em nível regional e presumem que todos os serviços da região serão perdidos. No entanto, podem ocorrer interrupções isoladas de serviço sem afetar outros serviços na região.

Nesses casos, é fundamental avaliar se é necessário um failover completo para outra região ou se apenas o componente com falha precisa ser resolvido.

Por exemplo, se um serviço de banco de dados sofrer uma falha catastrófica, você precisará fazer o failover de toda a carga de trabalho, incluindo os serviços da Web? Ou os outros componentes podem mudar facilmente para um banco de dados de réplica de leitura em espera em outra região?

A facilidade de lidar com esses cenários depende de como sua carga de trabalho foi projetada e configurada. Evite codificar nomes de serviços e garanta que sua arquitetura considere fatores como a latência da rede para permitir transições suaves durante interrupções parciais.

Failback

Outra consideração é a posição de failback depois que a poeira baixar em um desastre. O procedimento de failback está documentado no plano de DR. As considerações sobre o failback incluem:

• Você tem uma falha de retorno ou continua funcionando normalmente no local de recuperação?
• Se o failback for obrigatório, quando você tentará fazê-lo?
• Como o failback funciona para criar o mínimo possível de interrupções adicionais?

O failback pode ser tão complicado e perturbador quanto um desastre, portanto, considere se o failback é mesmo necessário. Em vez disso, os serviços podem continuar a ser executados no segundo local? O momento do failback também é importante. Você precisa garantir que as circunstâncias que causaram o desastre sejam resolvidas e que o failback não cause uma interrupção prolongada.

Independentemente de você aplicar um failback ou não, a provisão de DR precisa ser recriada ou redefinida.