Este documento é destinado a administradores de sistemas, arquitetos de nuvem e desenvolvedores de aplicativos responsáveis por manter a disponibilidade e a resiliência de aplicativos no OpenShift Container Platform implantado no Google Cloud.
Este documento faz parte de uma série que se concentra nas estratégias de nível de aplicativo que garantem que suas cargas de trabalho permaneçam altamente disponíveis e possam ser recuperadas rapidamente em caso de falhas. Os documentos desta série são os seguintes:
- Práticas recomendadas para recuperação de desastres (esta página)
- Práticas recomendadas para alta disponibilidade
- Estratégias de recuperação de desastres para configurações ativo-passivo
- Estratégias de recuperação de desastres para configurações ativo-inativo
Planejamento de DR
O planejamento de DR é um componente essencial para executar cargas de trabalho de produção na nuvem. Embora o OpenShift e Google Cloud ofereçam redundância robusta no nível da infraestrutura, você também precisa projetar e configurar seus aplicativos para se recuperar rapidamente de falhas catastróficas.
O planejamento de DR eficaz envolve uma abordagem em camadas. Comece definindo objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) claros para seu aplicativo e sistema para uma nova implantação rápida.
Seus secrets e credenciais também precisam ser recuperáveis e gerenciados com segurança. Ao considerar todos esses fatores, você pode alcançar uma postura de DR que permite criar rapidamente um novo cluster do OpenShift em uma região diferente ou fazer failover para um cluster secundário inativo. Esse cluster secundário permanece off-line até que ocorra uma falha. Nesse momento, ele é iniciado e colocado on-line para assumir as operações com tempo de inatividade mínimo.
Arquiteturas para DR
Há diferentes opções de arquiteturas de implantação que podem ser usadas para DR com o OpenShift no Google Cloud. Cada uma dessas opções tem implicações diferentes para custo, complexidade e disponibilidade. A tabela a seguir oferece uma visão geral dessas arquiteturas:
| Arquitetura | Descrição | Caso de uso | Vantagens | Desvantagens |
|---|---|---|---|---|
| Ativo-passivo | Um cluster está ativo, processando todo o tráfego, e o outro está passivo e pronto para assumir. Os dados são replicados para o cluster passivo. | Adequado para aplicativos com requisitos moderados de RTO e RPO. | Mais simples de implementar, menor custo para o cluster de espera. | RTO mais alto devido ao tempo de failover, possíveis atrasos na sincronização de dados. |
| Ativo-inativo | Semelhante ao ativo-passivo, mas o cluster inativo não é usado até um evento de DR. Os dados são copiados regularmente. | Ideal para ambientes sensíveis a custos que permitem RTO e RPO mais altos. | Menor custo operacional quando inativo, adequado para DR em que um sistema secundário não está em execução ativa (DR fria). | RTO mais alto devido ao tempo de ativação e sincronização, embora haja o potencial de os dados ficarem desatualizados. |
| Ativo-ativo | Os dois clusters estão ativos, processando o tráfego com balanceamento de carga e replicação de dados entre regiões. | Aplicativos críticos que exigem tempo de inatividade mínimo e alta disponibilidade. | RTO e RPO mais baixos, disponibilidade contínua. | Maior complexidade e custo, exige rede robusta e sincronizações de dados. |
A seguir
- Saiba como implementar o monitoramento e os alertas para integridade do cluster, status da replicação, sucesso do backup e desempenho do aplicativo em ambientes primários e secundários.
- Saiba como instalar o OpenShift no Google Cloud.
- Saiba mais sobre as soluções Red Hat no Google Cloud