Recuperação de desastres para o OpenShift no Google Cloud

A recuperação de desastres (RD) é essencial para manter a continuidade das suas aplicações implementadas na OpenShift Container Platform naGoogle Cloud. Este documento oferece uma vista geral das opções de arquitetura para a recuperação de desastres com o OpenShift no Google Cloud, ajudando a sua organização a alcançar um tempo de inatividade mínimo e uma recuperação rápida em caso de desastre.

Este documento destina-se a administradores de sistemas, arquitetos da nuvem e programadores de aplicações responsáveis por manter a disponibilidade e a resiliência das aplicações na OpenShift Container Platform implementada noGoogle Cloud.

Este documento faz parte de uma série que se foca nas estratégias ao nível da aplicação que garantem que as suas cargas de trabalho permanecem altamente disponíveis e rapidamente recuperáveis em caso de falhas. Os documentos desta série são os seguintes:

Planeamento de RD

O planeamento da recuperação de desastres é um componente crítico da execução de cargas de trabalho de produção na nuvem. Embora o OpenShift ofereça uma redundância robusta ao nível da infraestrutura, também tem de criar e configurar as suas aplicações para recuperar rapidamente de falhas catastróficas. Google Cloud

O planeamento de recuperação de desastres eficaz envolve uma abordagem em camadas. Comece por definir objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) claros para a sua aplicação e sistema para uma reimplementação rápida.

Por último, as suas informações secretas e credenciais também têm de ser recuperáveis e geridas de forma segura. Ao considerar todos estes fatores, pode alcançar uma postura de DR que lhe permita criar rapidamente um novo cluster do OpenShift numa região diferente ou fazer failover para um cluster secundário inativo. Este cluster secundário permanece offline até ocorrer uma falha, altura em que é iniciado e colocado online para assumir as operações com um tempo de inatividade mínimo.

Arquiteturas para DR

Existem diferentes opções de arquiteturas de implementação que pode usar para a recuperação de desastres com o OpenShift no Google Cloud. Cada uma destas opções tem diferentes implicações para o custo, a complexidade e a disponibilidade. A tabela seguinte oferece uma vista geral destas arquiteturas:

Arquitetura Descrição Exemplo de utilização Vantagens Desvantagens
Ativo-passivo Um cluster está ativo, a processar todo o tráfego, e o outro está passivo e pronto a assumir o controlo. Os dados são replicados para o cluster passivo. Adequado para aplicações com requisitos de RTO e RPO moderados. Mais simples de implementar, custo mais baixo para o cluster de espera. RTO mais elevado devido ao tempo de comutação por falha e a potenciais atrasos na sincronização de dados.
Ativo-inativo Semelhante à configuração ativo-passivo, mas o cluster inativo não é usado até ocorrer um evento de recuperação de desastres. É feita regularmente uma cópia de segurança dos dados. Ideal para ambientes sensíveis aos custos que permitem um OTR e um OPR mais elevados. Custo operacional mais baixo quando está inativo, adequado para recuperação de desastres quando um sistema secundário não está em execução ativa (recuperação de desastres a frio) . RTO mais elevado devido ao tempo de ativação e sincronização, embora exista o potencial de os dados ficarem desatualizados.
Ativo-ativo Ambos os clusters estão ativos, processando o tráfego com o balanceamento de carga e a replicação de dados entre regiões. Aplicações críticas que requerem um tempo de inatividade mínimo e uma elevada disponibilidade. RTO e RPO mais baixos, disponibilidade contínua. Complexidade e custo mais elevados, requer sincronizações robustas de rede e dados.

O que se segue?