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 do Red Hat OpenShift implantada 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. Ele pressupõe que você tenha lido as Práticas recomendadas para recuperação de desastres. Os documentos desta série são os seguintes:
- Práticas recomendadas para recuperação de desastres
- 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 (esta página)
Arquitetura para recuperação de desastres
A recuperação de desastres ativo-inativo envolve a manutenção de uma região secundária como espera, que é ativada apenas durante desastres. Ao contrário das configurações ativo-passivo, em que os dados são replicados continuamente, essa estratégia depende de backups periódicos armazenados no Cloud Storage, com infraestrutura provisionada e dados restaurados durante o failover. É possível usar ferramentas como o Velero, integrado à API OpenShift para proteção de dados (OADP, na sigla em inglês), para realizar backups periódicos. Essa abordagem minimiza os custos, tornando-a ideal para aplicativos que podem tolerar tempos de recuperação mais longos. Ela também pode ajudar as organizações a se alinhar com objetivos de tempo de recuperação (RTO, na sigla em inglês) e objetivos de ponto de recuperação (RPO, na sigla em inglês) estendidos.
Em um cenário de recuperação de DR ativo-inativo, os dados são armazenados regularmente na região de espera, mas não são replicados ativamente. A infraestrutura é provisionada como parte do processo de failover, e os dados são restaurados do backup mais recente. É possível usar a API OpenShift para proteção de dados (OADP), que é baseada no projeto de código aberto Velero, para realizar backups regulares. Recomendamos armazenar esses backups em buckets do Cloud Storage com o controle de versões ativado. Em caso de desastre, é possível usar o OADP para restaurar o conteúdo do cluster. Essa abordagem minimiza os custos contínuos, mas resulta em RTO mais longos e RPO potencialmente mais altos em comparação com o ativo-passivo. Essa configuração é adequada para aplicativos com objetivos de tempo de recuperação mais longos.
O diagrama a seguir mostra uma implantação ativo-inativo e o processo de failover:
O processo de failover é o seguinte:
- Um evento de recuperação de DR é acionado quando um serviço monitorado fica indisponível.
- Um pipeline provisiona automaticamente a infraestrutura na região de recuperação de DR.
- Um novo cluster do OpenShift é provisionado.
- Os dados, secrets e objetos do aplicativo são restaurados do backup mais recente pelo OADP.
- O registro DNS do Cloud DNS é atualizado para apontar para os balanceadores de carga regionais na região de DR.
Conforme mostrado no diagrama anterior, dois clusters regionais separados do OpenShift
são implantados, cada um em uma região diferente, Google Cloud como
us-central1 e europe-west1. Cada cluster precisa estar altamente disponível na região e usar várias zonas para permitir a redundância.
Descrição dos componentes em um cenário de recuperação de desastres ativo-inativo
A arquitetura tem a seguinte configuração:
- Região principal (região A): contém o cluster do OpenShift totalmente operacional que atende ao tráfego de produção.
- Região secundária (região B): inicialmente contém recursos mínimos (VPC e sub-redes). A infraestrutura (instâncias do Compute Engine e OCP) é provisionada durante o failover.
- Armazenamento de backup: os buckets do Google Cloud Storage armazenam backups periódicos (OADP ou Velero para objetos de aplicativos, bem como PVs e backups de bancos de dados). Recomendamos usar o controle de versões e a replicação entre regiões para o bucket.
- Gerenciamento de configuração: o repositório Git armazena a infraestrutura como código (IaC, por exemplo, Terraform) e manifestos do Kubernetes ou OpenShift (para GitOps).
- Ferramentas de backup: OADP (Velero) configurado no cluster principal para realizar backups programados no Cloud Storage.
- Orquestração: scripts ou ferramentas de automação acionam o provisionamento de infraestrutura e restauram processos durante o failover.
Produtos usados
- Google Compute Engine
- Google Cloud Balanceador de carga HTTPS externo global
- Google Cloud Balanceadores de carga de rede de passagem
- Cloud DNS
- Grupos de endpoints de rede
- Cloud Storage
- Cloud SQL
- Persistent Disk
- Secret Manager
- Cloud Monitoring
- Rede VPC
Casos de uso
A recuperação de desastres ativo-inativo é recomendada para os seguintes casos de uso:
- Aplicativos que podem tolerar RTOs mais longos (por exemplo, de vários minutos a horas).
- Ambientes em que a otimização de custos é importante e a despesa de um cluster de espera em execução contínua é proibitiva. O principal custo contínuo é para o armazenamento de objetos, e não para a execução de instâncias de computação.
- Cargas de trabalho de desenvolvimento, teste ou produção menos críticas.
- Sistemas de arquivamento ou processamento em lote em que o tempo de recuperação é menos crítico.
Considerações sobre o design
Esta seção descreve os fatores de design, as práticas recomendadas e as recomendações de design que você precisa considerar ao usar essa arquitetura de referência para desenvolver uma topologia que atenda aos seus requisitos específicos de segurança, confiabilidade, custo e desempenho.
Configuração do aplicativo como código (GitOps)
Recomendamos adotar uma abordagem GitOps para armazenar todas as configurações de cluster e aplicativo em um repositório Git. Essa abordagem permite a restauração rápida em um cenário de DR, ativando a sincronização com um estado conhecido por ser executado de maneira confiável em outro cluster. Os backups garantem que você tenha snapshots do estado de execução. No entanto, também é necessário ter uma maneira confiável de reimplantar a lógica do aplicativo, os manifestos e as definições de infraestrutura rapidamente após um desastre.
Usar o operador GitOps do OpenShift
O operador GitOps do OpenShift, baseado no Argo CD, oferece uma maneira com suporte do Red Hat de implementar padrões do GitOps diretamente em um ambiente do OpenShift. Ele automatiza o processo de reconciliação contínua do estado do cluster com a configuração escolhida e a armazena em um repositório Git.
O controlador do operador GitOps do OpenShift garante continuamente que o estado do cluster corresponda à configuração definida nesse repositório. Se os recursos forem desviados ou estiverem ausentes, eles serão reconciliados automaticamente. Para saber mais, consulte Sobre o Red Hat OpenShift GitOps.
Execução do cenário de recuperação de desastres
Em caso de desastre, faça o seguinte:
- Configure um novo cluster do OpenShift em outra região.
- Instale o operador GitOps do OpenShift.
- Aplique o mesmo manifesto do aplicativo que faz referência ao seu repositório Git.
O operador sincroniza o estado do cluster para corresponder ao repositório, reimplantando rapidamente implantações, serviços, rotas, operadores e outros recursos definidos no código.
Para evitar problemas durante a DR, recomendamos que você faça o seguinte:
- Mantenha estratégias rigorosas de ramificação e marcação no repositório Git para identificar configurações estáveis adequadas para DR.
- Verifique se o cluster de recuperação de DR tem conectividade de rede e permissões adequadas para acessar o repositório Git.
- Inclua todos os tipos de recursos como código para evitar intervenção manual durante o failover (por exemplo, componentes de infraestrutura, cargas de trabalho de aplicativos e configurações).
Regras de firewall
Defina políticas de firewall unificadas e aplique-as de maneira consistente nos dois clusters para controlar o fluxo de tráfego e melhorar a segurança.
Siga o princípio de privilégio mínimo, o que significa restringir o tráfego de entrada e saída apenas ao que é necessário para a funcionalidade do aplicativo.
Implantação
Para saber como implantar uma topologia com base nessa arquitetura de referência, consulte a documentação do Red Hat.
A seguir
- Saiba como implementar o monitoramento e os alertas para a integridade do cluster, o status da replicação, o sucesso do backup e o desempenho do aplicativo nos ambientes principal e secundário.
- Saiba como instalar o OpenShift no Google Cloud Google Cloud.
- Saiba mais sobre as soluções do Red Hat no Google CloudGoogle Cloud.