OpenShift no Google Cloud: estratégias de recuperação de desastres para configurações ativo-passivo e ativo-inativo

Neste documento, descrevemos como planejar e implementar a recuperação de desastres ativo-passivo e ativo-inativo para implantações do OpenShift no Google Cloud , ajudando você a minimizar o tempo de inatividade e a se recuperar rapidamente em caso de desastre. Ele oferece práticas recomendadas para fazer backup de dados, gerenciar a configuração como código e processar secrets para ajudar a garantir que você possa recuperar rapidamente seus aplicativos em caso de desastre.

Este documento é destinado a administradores de sistema, arquitetos de nuvem e desenvolvedores de aplicativos responsáveis por manter a disponibilidade e a resiliência de aplicativos em uma 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. Ele pressupõe que você leu as Práticas recomendadas para recuperação de desastres com o OpenShift. Os documentos desta série são os seguintes:

Arquiteturas para recuperação de desastres

Esta seção descreve arquiteturas para cenários de recuperação de desastres ativo-passivo e ativo-inativo.

Produtos usados

Implantações ativas-passivas

O diagrama a seguir mostra um cenário de implantação ativo-passivo para o OpenShift no Google Cloud.

Implantação ativa-passiva, explicada no texto a seguir.

Como mostrado no diagrama anterior, em uma implantação ativo-passiva para recuperação de desastres, um cluster do OpenShift na região principal processa todo o tráfego de produção. Um cluster secundário em uma região diferente fica pronto para assumir o controle se o principal falhar. Essa configuração garante um tempo de inatividade mínimo, já que o cluster secundário é pré-provisionado e está em um estado ativo. Isso significa que ele é configurado com a infraestrutura e os componentes de aplicativo necessários, mas não atende ao tráfego ativamente até que seja necessário. Os dados do aplicativo são replicados para o cluster passivo para minimizar a perda de dados, alinhando-se ao RPO.

Um dos clusters regionais atua como o site principal (ativo) e processa todo o tráfego de produção. Um cluster secundário, em uma região diferente, é o standby para recuperação de desastres. O cluster secundário é mantido em um estado ativo e pronto para assumir o controle com atraso mínimo em caso de falha do cluster principal.

Descrição dos componentes em um cenário de DR ativo-passivo

A arquitetura tem a seguinte configuração:

  • Cluster principal do OpenShift (ativo): localizado na região principalGoogle Cloud , esse cluster executa a carga de trabalho de produção e atende ativamente a todo o tráfego de usuários em condições normais de operação.
  • Cluster secundário do OpenShift (passivo): localizado em uma regiãoGoogle Cloud separada para isolamento de falhas, esse cluster atua como o cluster de espera ativa. Ele está parcialmente configurado e em execução e pronto para assumir o controle se o sistema principal falhar. Ele tem a infraestrutura, a configuração do OpenShift e os componentes de aplicativo necessários implantados, mas não atende ao tráfego de produção ativo até que um evento de failover seja acionado.
  • Google Cloud regiões: locais geograficamente isolados que fornecem a base para recuperação de desastres. Usar regiões separadas garante que um evento de grande escala que afete uma região não afete o cluster em espera.
  • Balanceador de carga HTTPS externo global: atua como o único ponto de entrada global para o tráfego de aplicativos. Em condições normais, ele é configurado para rotear todo o tráfego para o cluster principal (ativo). As verificações de integridade monitoram a disponibilidade do cluster primário.
  • Mecanismo de replicação de dados: processo ou ferramentas contínuas responsáveis por copiar dados essenciais do aplicativo do cluster principal para o secundário (por exemplo, estado de bancos de dados ou volumes permanentes). Essa abordagem garante a consistência dos dados e minimiza a perda de dados durante um failover, ajudando você a atender ao seu RPO.
  • Monitoramento e verificações de integridade:sistemas que avaliam continuamente a integridade e a disponibilidade do cluster principal e dos aplicativos dele, por exemplo, Cloud Monitoring, verificações de integridade do balanceador de carga, monitoramento interno do cluster. Esses sistemas são importantes para a detecção rápida de falhas.
  • Mecanismo de failover:um processo predefinido (manual, semiautomático ou totalmente automático) para redirecionar o tráfego do cluster principal para o secundário após a detecção de uma falha irrecuperável no principal. Normalmente, esse processo envolve atualizar a configuração de back-end do balanceador de carga global para direcionar o cluster secundário, tornando-o o novo site ativo.
  • Rede VPC: a infraestrutura de rede Google Cloud subjacente que cria a conectividade necessária entre regiões para replicação e gerenciamento de dados.

Implantações ativas/inativas

A DR ativa-inativa envolve a manutenção de uma região secundária como standby, 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 fazer backups periódicos. Essa abordagem minimiza os custos, o que a torna ideal para aplicativos que podem tolerar tempos de recuperação mais longos. Ele também pode ajudar as organizações a se alinharem com objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) estendidos.

Em um cenário de DR ativo-inativo, os dados são regularmente armazenados em backup na região em 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 fazer backups regulares. Recomendamos armazenar esses backups em buckets do Cloud Storage com o controle de versões ativado. Em caso de desastre, use o OADP para restaurar o conteúdo do cluster. Essa abordagem minimiza os custos contínuos, mas resulta em um RTO mais longo e um RPO potencialmente maior 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-inativa e o processo de failover.

Processo de failover.

O processo de failover é o seguinte:

  1. Um evento de DR é acionado quando um serviço monitorado fica indisponível.
  2. Um pipeline provisiona automaticamente a infraestrutura na região de DR.
  3. Um novo cluster do OpenShift é provisionado.
  4. Os dados, secrets e objetos do aplicativo são restaurados do backup mais recente pelo OADP.
  5. O registro 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 Google Cloud diferente, como us-central1 e europe-west1. Cada cluster precisa ter alta disponibilidade na região e usar várias zonas para permitir redundância.

Descrição dos componentes em um cenário de DR 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, além de PVs e backups de banco 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 do 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.

Casos de uso

Nesta seção, apresentamos exemplos dos diferentes casos de uso para implantações ativo-passivo e ativo-inativo.

Casos de uso de DR ativo-passivo

A DR ativa-passiva é recomendada para os seguintes casos de uso:

  • Aplicativos que exigem um RTO menor (por exemplo, de minutos a horas) do que seria possível com restaurações frias, em que os dados são restaurados de um backup que não está imediatamente acessível.
  • Sistemas em que a replicação contínua de dados é viável e o RPO precisa ser minimizado (por exemplo, de minutos para segundos).
  • Setores regulamentados com limites rígidos de inatividade e aplicativos de negócios essenciais em que o custo de manter um cluster de espera ativa é justificado pelo impacto comercial da inatividade.

Casos de uso de DR ativo-inativo

A DR ativa-inativa é 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 o gasto de um cluster de espera em execução contínua é proibitivo. O principal custo contínuo é para armazenamento de objetos, e não para execução de instâncias de computação.
  • Cargas de trabalho de desenvolvimento, teste ou produção menos críticas.
  • Sistemas de arquivamento ou de processamento em lote em que o tempo de recuperação é menos crítico.

Considerações sobre o design

Esta seção descreve fatores de design, práticas recomendadas e 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.

Considerações sobre o design ativo-passivo

Nesta seção, descrevemos as considerações de design para um cenário de DR ativo-passivo.

Proteção do estado e da configuração do aplicativo

O OpenShift Container Platform oferece o OADP e proteção abrangente de recuperação de desastres para aplicativos executados em clusters. É possível usar o Velero para fazer backup dos objetos do Kubernetes e do OpenShift usados por aplicativos em contêineres e máquinas virtuais (por exemplo, implantações, serviços, rotas, PVCs, ConfigMaps, secrets e CRDs). No entanto, a OADP não oferece suporte a backup e restauração completos do cluster. Para saber como configurar e programar backups e como restaurar operações, consulte a documentação do Red Hat.

O OADP oferece processos de backup e restauração para volumes permanentes que dependem do armazenamento em blocos e das lojas NFS usadas pelos aplicativos. É possível realizar essas ações usando as ferramentas Restic ou Kopia para criar snapshots ou fazer backup no nível do arquivo.

O OADP é útil para fazer backup de definições de objetos, garantir a consistência da configuração e, possivelmente, restaurar aplicativos ou namespaces específicos, se necessário, complementando a replicação de dados.

Para reduzir ainda mais o RPO e o RTO em uma configuração ativa-passiva, recomendamos configurar a replicação de dados entre as regiões primária e secundária.

A replicação de dados é importante para garantir que o cluster secundário possa assumir sem problemas. Conforme descrito na seção a seguir, a implementação da replicação de dados dos clusters principal e secundário depende do tipo de armazenamento usado pelo aplicativo.

Armazenamento em blocos (volumes permanentes)

Use a replicação assíncrona do disco permanente do Google para copiar dados da região principal para a secundária. Nessa abordagem, você cria um disco principal na região principal, um disco secundário na região secundária e configura a replicação entre eles. O uso de grupos consistentes garante que ambos os discos contenham dados de replicação de um ponto comum no tempo, que é usado para DR. Para saber mais, consulte Configurar a replicação assíncrona de disco permanente.

Objetos PersistentVolumes

No OpenShift, crie objetos PersistentVolumes nos dois clusters que se vinculam a esses discos e verifique se os aplicativos usam as mesmas Persistent Volume Claims (PVCs) nos dois clusters.

Replicação no nível do aplicativo

Alguns aplicativos (por exemplo, bancos de dados e filas de mensagens) têm recursos de replicação integrados que podem ser configurados em clusters. Você também pode usar um serviço gerenciado, como o Pub/Sub, para facilitar a replicação de tipos específicos de dados ou eventos de aplicativos. (por exemplo, bancos de dados e filas de mensagens).

Backups de banco de dados

Os aplicativos podem depender de diferentes tipos de produtos de banco de dados. Para ajudar a descrever as considerações de design para backups de banco de dados, este documento usa o PostgreSQL como um exemplo.

Backups autohospedados usando um operador de banco de dados no cluster

Operadores de banco de dados, como o CloudNative PostgreSQL Operator, podem facilitar backups programados e recuperação de desastres para clusters do PostgreSQL. O operador do PostgreSQL nativo da nuvem se integra de forma nativa a ferramentas como pg_basebackup e oferece suporte a backups de replicação de streaming. É possível armazenar backups em serviços de armazenamento em nuvem, como o Google Cloud Storage (Cloud Storage), para durabilidade e recuperação.

É possível configurar a replicação de streaming entre clusters regionais primários e secundários para garantir que, mesmo em caso de interrupção na região primária, os dados estejam disponíveis. Essa replicação de streaming normalmente é síncrona em uma região e assíncrona entre regiões. Para etapas detalhadas de configuração, consulte a documentação do CloudNativePG.

Em caso de desastre, é possível restaurar backups para um novo cluster do PostgreSQL, garantindo tempo de inatividade e perda de dados mínimos. Confira a seguir um exemplo de snippet de configuração para ativar backups programados usando o operador CloudNative PostgreSQL:

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

Serviços gerenciados

Bancos de dados gerenciados, como o Cloud SQL, têm recursos integrados de backup e replicação. Recomendamos que você configure a replicação assíncrona da instância de banco de dados principal para uma réplica na região secundária. Para saber mais, consulte Sobre a replicação no Cloud SQL. No OpenShift, configure secrets ou configmaps para apontar para as strings de conexão de banco de dados corretas de cada cluster.

Como a replicação assíncrona resulta em um RPO diferente de zero, há uma possibilidade de perda das gravações de dados mais recentes. Você precisa projetar seu aplicativo para evitar a perda de dados. Se preferir, use outro método de replicação.

Também recomendamos que você ative os backups automatizados do Cloud SQL. Para saber mais, consulte Criar e gerenciar backups automáticos e sob demanda.

Processo de failover

Em caso de falha do cluster principal, o Cloud DNS redireciona automaticamente o tráfego para o cluster regional secundário com base nas verificações de integridade e nas políticas de failover.

Quando o cluster secundário é promovido de uma réplica de leitura para um cluster principal, ele assume o controle como um site ativo e atende ao tráfego de produção. Essa promoção é necessária para aceitar gravações no banco de dados.

Para configurar a recuperação de desastres no Cloud SQL, siga as etapas descritas na documentação de recuperação de desastres do Google Cloud SQL (em inglês). Usar a replicação assíncrona de banco de dados ou armazenamento causa um RPO diferente de zero para ajudar a garantir que seu aplicativo possa tolerar a perda das gravações mais recentes. Se preferir, use outro método de replicação.

Gerenciamento seguro de secrets

Secrets, como senhas de banco de dados, chaves de API e certificados TLS, são aspectos importantes da DR. É preciso restaurar esses secrets de forma segura e confiável em um novo cluster.

Confira algumas abordagens comuns para o gerenciamento de secrets:

  • Usar secrets externos: use uma ferramenta como o operador de secrets externos para extrair secrets do Secret Manager do Google.
  • Fazer backup de secrets com o operador OADP: se você não usar um armazenamento externo, verifique se os secrets estão incluídos nos backups.
  • Rotação regular: alterne as chaves secretas regularmente e garanta que sua estratégia de gerenciamento de chaves secretas acomode cenários de DR.
  • Teste: teste a restauração de secrets em um ambiente de staging para confirmar que todos os serviços podem ser iniciados com as credenciais fornecidas.
  • Validação: valide se o cluster de DR tem os papéis do IAM ou métodos de autenticação necessários para recuperar secrets de repositórios externos.

Rede e gerenciamento de tráfego

Use o balanceador de carga HTTPS externo global do Google Cloudcomo o ponto de entrada principal para distribuir o tráfego entre vários clusters do OpenShift (por exemplo, clusters primários e secundários). Esse serviço global direciona as solicitações do usuário para o cluster de back-end apropriado com base na proximidade, integridade e disponibilidade.

Para conectar o balanceador de carga global aos clusters do OpenShift, use uma das seguintes abordagens:

  • Use balanceadores de carga regionais (NEGs da Internet): configure Google Cloud grupos de endpoints de rede (NEGs) da Internet para apontar para os endereços IP externos dos balanceadores de carga regionais que expõem cada um dos serviços de entrada dos clusters do OpenShift (roteadores do OCP). Em seguida, o balanceador de carga global encaminha o tráfego para esses IPs de balanceadores de carga regionais. Essa abordagem fornece uma camada de abstração, mas envolve um salto para uma rede adicional.
  • Roteamento direto de pods (Compute Engine_VM_IP_PORT NEGs): configure a integração do controlador de entrada do OpenShift para usar Google Cloud grupos de endpoints de rede (NEGs) do tipo Compute Engine_VM_IP_PORT. Essa abordagem permite que o balanceador de carga global direcione os pods do controlador de entrada (roteador) do OpenShift diretamente usando o PodIP:TargetPort interno. Esse método ignora o salto extra e o proxy de nó adicional. Isso geralmente resulta em menor latência e permite uma verificação de integridade mais direta do balanceador de carga global.

As duas configurações permitem que o balanceador de carga global gerencie a distribuição de tráfego de maneira eficaz entre clusters em diferentes regiões. Para saber mais, consulte Configurar um balanceador de carga de aplicativo externo global com um back-end externo.

VPCs

Recomendamos as seguintes abordagens para o gerenciamento de VPC:

  • VPC compartilhada: use uma VPC compartilhada para centralizar o gerenciamento de rede dos clusters principal e secundário. Essa abordagem simplifica a administração e garante políticas de rede consistentes em todas as regiões.
  • Roteamento dinâmico global: ative o roteamento dinâmico global nas suas VPCs para propagar automaticamente as rotas entre regiões, garantindo uma conectividade perfeita entre os clusters.
  • VPCs de modo personalizado: use VPCs de modo personalizado e crie sub-redes específicas nas regiões em que seus clusters são executados. Isso geralmente é necessário para a rede de pods nativa da VPC exigida por métodos como o roteamento Compute Engine_VM_IP_PORT.
  • Peering de rede VPC: se for necessário usar redes VPC separadas para cada região e cluster, use o peering de rede VPC para conectar as regiões e os clusters.

Sub-redes e endereços IP

Crie sub-redes regionais em cada região para manter a segmentação da rede e evitar conflitos de endereços IP.

Verifique se não há intervalos de IP sobrepostos entre regiões para evitar problemas de roteamento.

Tráfego entre clusters com o Red Hat Service Mesh

O OpenShift é compatível com a federação de malha de serviço, que permite a comunicação entre serviços implantados em vários clusters do OpenShift. Essa função é especialmente útil para cenários de DR em que os serviços podem precisar se comunicar entre clusters durante o failover ou a replicação de dados.

Para saber como configurar a federação do Service Mesh entre clusters primários e secundários, consulte a documentação do Red Hat.

Considerações sobre o design ativo-inativo

Esta seção descreve as considerações de design para uma solução de DR ativa-inativa.

Configuração de aplicativos como código (GitOps)

Recomendamos adotar uma abordagem de GitOps para armazenar todas as configurações de cluster e aplicativo em um repositório Git. Essa abordagem permite uma restauração rápida em um cenário de DR, ativando a sincronização com um estado conhecido por estar funcionando de forma 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 do OpenShift GitOps, baseado no Argo CD, oferece uma maneira compatível com a 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 o armazena em um repositório Git.

O controlador do operador GitOps do OpenShift garante continuamente que o estado do cluster corresponda à configuração definida neste repositório. Se os recursos mudarem ou estiverem faltando, ele os reconciliará automaticamente. Para saber mais, consulte Sobre o Red Hat OpenShift GitOps.

Execução de cenários de DR

Em caso de desastre, faça o seguinte:

  • Configure um novo cluster do OpenShift em outra região.
  • Instale o operador do OpenShift GitOps.
  • Aplique o mesmo manifesto do aplicativo referenciando seu repositório Git.

O operador sincroniza o estado do cluster para corresponder ao seu repositório, reimplantando rapidamente implantações, serviços, rotas, operadores e outros recursos definidos no seu código.

Para evitar problemas durante a DR, recomendamos o seguinte:

  • Mantenha estratégias rigorosas de ramificação e inclusão de tags no seu repositório Git para identificar configurações estáveis adequadas para DR.
  • Verifique se o cluster de DR tem conectividade de rede e as 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 aumentar a segurança.

Siga o princípio de privilégio mínimo, restringindo 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 baseada nessa arquitetura de referência, consulte a documentação da Red Hat.

A seguir