Recuperação de desastres do OpenShift no Google Cloud

A recuperação de desastres (DR) é essencial para manter a continuidade dos aplicativos implantados no OpenShift Container Platform em Google Cloud. Este documento oferece uma visão geral das opções arquitetônicas de DR com o OpenShift no Google Cloud, ajudando sua organização a alcançar tempo de inatividade mínimo e recuperação rápida em caso de desastre.

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 na plataforma de contêineres OpenShift implantada no Google Cloud.

Este documento faz parte de uma série que se concentra nas estratégias no nível do aplicativo para garantir 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:

Planejamento de DR

O planejamento de DR é um componente essencial para executar cargas de trabalho de produção na nuvem. Embora o OpenShift e o Google Cloud ofereçam redundância robusta no nível da infraestrutura, também é necessário projetar e configurar os aplicativos para se recuperar rapidamente de falhas catastróficas.

O planejamento eficaz de DR 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 rápida reimplementação.

Por fim, seus segredos 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 fica 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 fornece 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 e com custo menor para o cluster em espera. RTO mais alto devido ao tempo de failover e 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 armazenados em backup regularmente. Ideal para ambientes sensíveis a custos que permitem RTO e RPO mais altos. Custo operacional mais baixo 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 essenciais que exigem tempo de inatividade mínimo e alta disponibilidade. Menor RTO e RPO, disponibilidade contínua. Maior complexidade e custo, exige rede robusta e sincronizações de dados.

A seguir