OpenShift on Google Cloud: estratégias de recuperação de desastres para configurações ativas-passivas e ativas-inativas

Este documento descreve como planear e implementar a recuperação de desastres ativa-passiva e ativa-inativa para implementações do OpenShift no Google Cloud , de modo a ajudar a alcançar um tempo de inatividade mínimo e uma recuperação rápida em caso de desastre. Fornece práticas recomendadas para fazer cópias de segurança de dados, gerir a configuração como código e processar segredos para ajudar a garantir que pode recuperar rapidamente as suas aplicações 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 numa 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. Parte do princípio de que leu o artigo 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 secção descreve as arquiteturas para cenários de recuperação de desastres ativo-passivo e ativo-inativo.

Produtos usados

Implementações ativas-passivas

O diagrama seguinte mostra um cenário de implementação ativo-passivo para o OpenShift on Google Cloud.

Implementação ativa-passiva, explicada no texto seguinte.

Conforme mostrado no diagrama anterior, numa implementação ativa-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 numa região diferente é mantido pronto para assumir o controlo se o cluster principal falhar. Esta configuração garante um tempo de inatividade mínimo, uma vez que o cluster secundário está pré-aprovisionado e num estado ativo, o que significa que está configurado com a infraestrutura e os componentes da aplicação necessários, mas não está a publicar ativamente tráfego até ser necessário. Os dados da aplicação são replicados para o cluster passivo para minimizar a perda de dados, alinhando-se com o RPO.

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

Descrição dos componentes num cenário de recuperação de desastres ativo-passivo

A arquitetura tem a seguinte configuração:

  • Cluster do OpenShift principal (ativo): localizado na regiãoGoogle Cloud principal, este cluster executa a carga de trabalho de produção e serve ativamente todo o tráfego de utilizadores em condições normais de funcionamento.
  • Cluster do OpenShift secundário (passivo): localizado numa Google Cloud região separada para isolamento de falhas, este cluster funciona como o cluster de reserva em modo de espera. Está parcialmente configurado e em funcionamento, e está pronto para assumir o controlo se o sistema principal falhar. Tem a infraestrutura necessária, a configuração do OpenShift e os componentes da aplicação implementados, mas não processa o tráfego de produção em direto até ser acionado um evento de comutação por falha.
  • Google Cloud Regiões: localizações geograficamente isoladas que fornecem a base para a recuperação de desastres. A utilização de regiões separadas garante que um evento de grande escala que afete uma região não afeta o cluster de espera.
  • Balanceador de carga HTTPS externo global: funciona como o único ponto de entrada global para o tráfego de aplicações. Em condições normais, está configurado para encaminhar todo o tráfego para o cluster principal (ativo). As verificações de funcionamento monitorizam a disponibilidade do cluster principal.
  • Mecanismo de replicação de dados: processo ou ferramentas contínuos responsáveis por copiar dados essenciais da aplicação do cluster principal para o cluster secundário (por exemplo, bases de dados ou estado dos volumes persistentes). Esta abordagem garante a consistência dos dados e minimiza a perda de dados durante uma comutação por falha, o que ajuda a cumprir o seu RPO.
  • Monitorização e verificações de funcionamento: sistemas que avaliam continuamente o estado e a disponibilidade do cluster principal e das respetivas aplicações, por exemplo, o Cloud Monitoring, as verificações de funcionamento do equilibrador de carga e a monitorização interna do cluster. Estes sistemas são importantes para a deteção rápida de falhas.
  • Mecanismo de comutação por falha: 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 deteção de uma falha irrecuperável no principal. Normalmente, este processo envolve a atualização da configuração de back-end do equilibrador de carga global para segmentar o cluster secundário, tornando-o o novo site ativo.
  • Rede VPC: a infraestrutura de rede Google Cloud subjacente que cria a conetividade necessária entre regiões para a replicação e a gestão de dados.

Implementações ativas/inativas

A DR ativa-inativa envolve a manutenção de uma região secundária como reserva, que é ativada apenas durante desastres. Ao contrário das configurações ativo-passivo, em que os dados são replicados continuamente, esta estratégia baseia-se em cópias de segurança periódicas armazenadas no Cloud Storage, com a infraestrutura aprovisionada e os dados restaurados durante a comutação por falha. Pode usar ferramentas como o Velero, integrado com a API OpenShift para proteção de dados (OADP), para fazer cópias de segurança periódicas. Esta abordagem minimiza os custos, o que a torna ideal para aplicações que podem tolerar tempos de recuperação mais longos. Também pode ajudar as organizações a alinharem-se com objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO) alargados.

Num cenário de DR ativo-inativo, é feita regularmente uma cópia de segurança dos dados para a região de espera, mas não são replicados ativamente. A infraestrutura é aprovisionada como parte do processo de ativação pós-falha e os dados são restaurados a partir da cópia de segurança mais recente. Pode usar a API OpenShift para proteção de dados (OADP), que se baseia no projeto de código aberto Velero, para fazer cópias de segurança regulares. Recomendamos que armazene estas cópias de segurança em contentores do Cloud Storage com o controlo de versões ativado. Em caso de desastre, pode usar o OADP para restaurar o conteúdo do cluster. Esta abordagem minimiza os custos contínuos, mas resulta num OTR mais longo e num OPR potencialmente mais elevado em comparação com a abordagem ativo-passivo. Esta configuração é adequada para aplicações com objetivos de tempo de recuperação mais longos.

O diagrama seguinte mostra uma implementação ativa-inativa e o processo de comutação por falha.

Processo de comutação por falha.

O processo de comutação por falha é o seguinte:

  1. Um evento de DR é acionado quando um serviço monitorizado fica indisponível.
  2. Um pipeline aprovisiona automaticamente a infraestrutura na região de DR.
  3. É aprovisionado um novo cluster do OpenShift.
  4. Os dados, os segredos e os objetos da aplicação são restaurados a partir da cópia de segurança mais recente através do OADP.
  5. O registo de DNS da nuvem é atualizado para apontar para os balanceadores de carga regionais na região de RFC.

Conforme mostrado no diagrama anterior, são implementados dois clusters regionais do OpenShift separados, cada um numa Google Cloud região diferente, como us-central1 e europe-west1. Cada cluster tem de estar altamente disponível na respetiva região e usar várias zonas para permitir a redundância.

Descrição dos componentes num 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 serve tráfego de produção.
  • Região secundária (região B): contém inicialmente recursos mínimos (VPC e sub-redes). A infraestrutura (instâncias do Compute Engine e OCP) é aprovisionada durante a comutação por falha.
  • Armazenamento de cópias de segurança: os contentores do Google Cloud Storage armazenam cópias de segurança periódicas (OADP ou Velero para objetos de aplicações, bem como PVs e cópias de segurança de bases de dados). Recomendamos que use o controlo de versões e a replicação entre regiões para o contentor.
  • Gestão da configuração: o repositório Git armazena a infraestrutura como código (IaC, por exemplo, Terraform) e os manifestos do Kubernetes ou OpenShift (para GitOps).
  • Ferramentas de cópia de segurança: OADP (Velero) configurado no cluster principal para fazer cópias de segurança agendadas para o Cloud Storage.
  • Orquestração: os scripts ou as ferramentas de automatização acionam o aprovisionamento da infraestrutura e os processos de restauro durante a comutação por falha.

Exemplos de utilização

Esta secção apresenta exemplos dos diferentes exemplos de utilização para implementações ativas-passivas e ativas-inativas.

Exemplos de utilização de DR ativo-passivo

A DR ativa-passiva é recomendada para os seguintes exemplos de utilização:

  • Aplicações que requerem um RTO inferior (por exemplo, de minutos a horas) ao que seria alcançável com restauros a frio, em que os dados são restaurados a partir de uma cópia de segurança que não está imediatamente acessível.
  • Sistemas em que a replicação de dados contínua é viável e o OPR tem de ser minimizado (por exemplo, de minutos para segundos).
  • Indústrias regulamentadas com limites de inatividade rigorosos e aplicações empresariais críticas em que o custo de manutenção de um cluster de standby a quente é justificado pelo impacto empresarial da inatividade.

Exemplos de utilização de DR ativo-inativo

A DR ativa-inativa é recomendada para os seguintes exemplos de utilização:

  • Aplicações que podem tolerar RTOs mais longos (por exemplo, vários minutos a horas).
  • Ambientes onde a otimização de custos é importante e a despesa de um cluster em espera em execução contínua é proibitiva. O custo contínuo principal é para o armazenamento de objetos e não para a execução de instâncias de computação.
  • Desenvolvimento, testes ou cargas de trabalho de produção menos críticas.
  • Sistemas de processamento em lote ou de arquivo em que o tempo de recuperação é menos crítico.

Considerações de design

Esta secção descreve os fatores de design, as práticas recomendadas e as recomendações de design que deve considerar quando usa esta arquitetura de referência para desenvolver uma topologia que cumpra os seus requisitos específicos de segurança, fiabilidade, custo e desempenho.

Considerações de design ativo-passivo

Esta secção descreve as considerações de design para um cenário de recuperação de desastres ativo-passivo.

Salvaguardar o estado e a configuração da aplicação

A OpenShift Container Platform fornece a OADP e oferece uma proteção abrangente de recuperação de desastres para aplicações em execução em clusters. Pode usá-lo para fazer uma cópia de segurança dos objetos do Kubernetes e do OpenShift que são usados por aplicações em contentores e máquinas virtuais (por exemplo, implementações, serviços, rotas, PVCs, ConfigMaps, segredos e CRDs). No entanto, o OADP não suporta a cópia de segurança e o restauro completos do cluster. Para saber como configurar e agendar cópias de segurança, e como restaurar operações, consulte a documentação do Red Hat.

O OADP fornece processos de cópia de segurança e restauro para volumes persistentes que dependem do armazenamento de blocos e dos armazenamentos NFS usados pelas aplicações. Pode realizar estas ações usando as ferramentas Restic ou Kopia para criar instantâneos ou fazer uma cópia de segurança ao nível do ficheiro.

O OADP é útil para fazer cópias de segurança das definições de objetos, garantir a consistência da configuração e, potencialmente, restaurar aplicações ou espaços de nomes específicos, se necessário, complementando a replicação de dados.

Para reduzir ainda mais o RPO e o RTO numa configuração ativa-passiva, recomendamos que configure a replicação de dados entre as regiões principal e secundária.

A replicação de dados é importante para garantir que o cluster secundário pode assumir o controlo sem problemas. Conforme descrito na secção seguinte, a implementação da replicação de dados dos clusters primários para os secundários depende do tipo de armazenamento que a aplicação usa.

Armazenamento em bloco (volumes persistentes)

Use a replicação assíncrona do disco persistente do Google para copiar dados da região principal para a região secundária. Nesta abordagem, cria um disco principal na região principal, um disco secundário na região secundária e configura a replicação entre eles. A utilização de grupos consistentes garante que ambos os discos contêm dados de replicação de um ponto comum no tempo, que é usado para a recuperação de desastres. Para saber mais, consulte o artigo Configurar a replicação assíncrona do disco persistente.

Objetos PersistentVolumes

No OpenShift, crie objetos PersistentVolumes em ambos os clusters que estabeleçam uma ligação a estes discos e certifique-se de que as aplicações usam as mesmas Persistent Volume Claims (PVCs) em ambos os clusters.

Replicação ao nível da aplicação

Algumas aplicações (por exemplo, bases de dados e filas de mensagens) têm funcionalidades de replicação incorporadas que pode configurar em vários clusters. Também pode usar um serviço gerido como o Pub/Sub para facilitar a replicação de tipos específicos de dados ou eventos de aplicações. (por exemplo, bases de dados e filas de mensagens).

Cópias de segurança de bases de dados

As aplicações podem depender de diferentes tipos de produtos de base de dados. Para ajudar a descrever as considerações de design para cópias de segurança de bases de dados, este documento usa o PostgreSQL como uma base de dados de exemplo.

Cópias de segurança autoalojadas através de um operador de base de dados no cluster

Os operadores de bases de dados, como o operador CloudNative PostgreSQL, podem facilitar as cópias de segurança agendadas e a recuperação de desastres para clusters do PostgreSQL. O operador CloudNative PostgreSQL integra-se nativamente com ferramentas como pg_basebackup e suporta cópias de segurança de replicação de streaming. Pode armazenar cópias de segurança em serviços de armazenamento na nuvem, como o Google Cloud Storage (Cloud Storage), para garantir a durabilidade e a recuperação.

Pode configurar a replicação de streaming entre clusters regionais primários e secundários para garantir que, mesmo em caso de indisponibilidade na região primária, os dados estão disponíveis. Normalmente, esta replicação de streaming é síncrona numa região e assíncrona entre regiões. Para ver passos de configuração detalhados, consulte a documentação do CloudNativePG.

Em caso de desastre, pode restaurar as cópias de segurança para um novo cluster do PostgreSQL, garantindo um tempo de inatividade e uma perda de dados mínimos. Segue-se um exemplo de um fragmento de configuração para ativar as cópias de segurança agendadas através do operador do PostgreSQL nativo da nuvem:

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

Serviços geridos

As bases de dados geridas, como o Cloud SQL, têm funcionalidades de cópia de segurança e replicação incorporadas. Recomendamos que configure a replicação assíncrona da instância da base de dados principal para uma réplica na região secundária. Para saber mais, consulte o artigo Acerca da replicação no Cloud SQL. No OpenShift, configure segredos ou mapas de configuração para apontar para as strings de ligação à base de dados corretas para cada cluster.

Uma vez que a replicação assíncrona resulta num RPO diferente de zero, existe um potencial de perda das gravações de dados mais recentes. Tem de conceber a sua aplicação para mitigar a perda de dados. Em alternativa, considere usar outro método de replicação.

Também recomendamos que ative as cópias de segurança automáticas do Cloud SQL. Para saber mais, consulte o artigo Crie e faça a gestão de cópias de segurança automáticas e a pedido.

Processo de comutação por falha

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 estado e nas políticas de comutação por falha.

Quando o cluster secundário é promovido de uma réplica de leitura para um cluster principal, assume o controlo como um site ativo e publica tráfego de produção. Esta promoção é necessária para poder aceitar gravações na base de dados.

Para configurar a recuperação de desastres para o Cloud SQL, siga os passos descritos na documentação de recuperação de desastres do Google Cloud SQL. A utilização da replicação assíncrona de bases de dados ou armazenamento provoca um RPO diferente de zero para ajudar a garantir que a sua aplicação consegue tolerar a perda das escritas mais recentes. Em alternativa, considere usar outro método de replicação.

Gestão segura de segredos

Os segredos, como palavras-passe de bases de dados, chaves de API e certificados TLS, são aspetos importantes da recuperação de desastres. Tem de conseguir restaurar estes segredos de forma segura e fiável num novo cluster.

Seguem-se abordagens comuns à gestão de segredos:

  • Use segredos externos: use uma ferramenta como o operador de segredos externos para extrair segredos do Google Secret Manager.
  • Faça uma cópia de segurança dos segredos com o operador OADP: se não usar um armazenamento externo, certifique-se de que os segredos estão incluídos nas suas cópias de segurança.
  • Rotação regular: rode os segredos regularmente e certifique-se de que a sua estratégia de gestão de segredos tem em conta cenários de recuperação de desastres.
  • Testes: teste o restauro de segredos num ambiente preparado para confirmar que todos os serviços podem ser iniciados com as credenciais fornecidas.
  • Validação: valide se o cluster de recuperação de desastres tem as funções do IAM ou os métodos de autenticação necessários para obter segredos de armazenamentos externos.

Redes e gestão de tráfego

Use o balanceador de carga HTTPS externo global da Google como o ponto de entrada principal para distribuir o tráfego entre vários clusters do OpenShift (por exemplo, clusters primários e secundários). Google CloudEste serviço global encaminha os pedidos dos utilizadores para o cluster de back-end adequado com base na proximidade, no estado e na disponibilidade.

Para ligar o balanceador de carga global aos seus clusters do OpenShift, pode usar uma das seguintes abordagens:

  • Use balanceadores de carga regionais (NEGs de Internet): configure Google Cloud grupos de pontos finais da rede (NEGs) de Internet para apontarem para os endereços IP externos dos balanceadores de carga regionais que expõem cada um dos serviços de entrada dos seus clusters do OpenShift (routers do OCP). Em seguida, o balanceador de carga global encaminha o tráfego para estes IPs do balanceador de carga regional. Esta abordagem fornece uma camada de abstração, mas envolve um salto para uma rede adicional.
  • Encaminhamento 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 pontos finais de rede (NEGs) do tipo Compute Engine_VM_IP_PORT. Esta abordagem permite que o balanceador de carga global segmente os pods do controlador de entrada do OpenShift (router) diretamente através do respetivo PodIP:TargetPort interno. Este método ignora o encaminhamento adicional e o proxying de nós adicionais. Normalmente, resulta numa latência mais baixa e permite uma verificação de funcionamento mais direta a partir do balanceador de carga global.

Ambas as configurações permitem que o balanceador de carga global faça a gestão da distribuição de tráfego de forma eficaz em clusters em diferentes regiões. Para saber mais, consulte o artigo Configure um Application Load Balancer externo global com um back-end externo.

VPCs

Recomendamos as seguintes abordagens para a gestão da VPC:

  • VPC partilhada: use uma VPC partilhada para centralizar a gestão de rede para clusters primários e secundários. Esta abordagem simplifica a administração e garante políticas de rede consistentes em todas as regiões.
  • Encaminhamento dinâmico global: ative o encaminhamento dinâmico global nas suas VPCs para propagar automaticamente as rotas entre regiões, garantindo uma conetividade perfeita entre clusters.
  • VPCs no modo personalizado: use VPCs no modo personalizado e crie sub-redes específicas nas regiões onde os seus clusters são executados. Isto é frequentemente necessário para a rede de pods nativa da VPC exigida por métodos como o encaminhamento Compute Engine_VM_IP_PORT.
  • Interligação de redes VPC: se for necessário usar redes VPC separadas para cada região e cluster, use a interligação de redes VPC para ligar 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.

Certifique-se de que existem intervalos de IP não sobrepostos entre regiões para evitar problemas de encaminhamento.

Tráfego entre clusters com a malha de serviços do Red Hat

O OpenShift suporta a federação de malhas de serviços, o que permite a comunicação entre serviços implementados em vários clusters do OpenShift. Esta função é particularmente útil para cenários de recuperação de desastres em que os serviços podem ter de comunicar entre clusters durante a comutação por falha ou a replicação de dados.

Para saber como configurar a federação da malha de serviços entre clusters primários e secundários, consulte a documentação da Red Hat.

Considerações de design ativo-inativo

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

Configuração da aplicação como código (GitOps)

Recomendamos que adote uma abordagem GitOps para armazenar todas as configurações de clusters e aplicações num repositório Git. Esta abordagem permite uma restauração rápida num cenário de recuperação de desastres, ativando a sincronização para um estado que se sabe estar a ser executado de forma fiável noutro cluster. As cópias de segurança garantem que tem instantâneos do estado de tempo de execução. No entanto, também precisa de uma forma fiável de reimplementar rapidamente a lógica da aplicação, os manifestos e as definições de infraestrutura após um desastre.

Use o operador GitOps do OpenShift

O operador GitOps do OpenShift, baseado no Argo CD, oferece uma forma suportada pela Red Hat de implementar padrões GitOps diretamente num ambiente OpenShift. Automatiza o processo de conciliação contínua do estado do cluster com a configuração escolhida e armazena-o num repositório Git.

O controlador do operador do OpenShift GitOps garante continuamente que o estado do cluster corresponde à configuração definida neste repositório. Se os recursos divergem ou estão em falta, o sistema reconcilia-os automaticamente. Para saber mais, consulte o artigo Acerca do Red Hat OpenShift GitOps.

Execução do cenário de RD

Em caso de desastre, faça o seguinte:

  • Configurar um novo cluster do OpenShift noutra região.
  • Instale o operador do OpenShift GitOps.
  • Aplique o mesmo manifesto da aplicação que faz referência ao seu repositório Git.

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

Para ajudar a evitar problemas durante a recuperação de desastres, recomendamos que faça o seguinte:

  • Mantenha estratégias de ramificação e etiquetagem rigorosas no seu repositório Git para poder identificar configurações estáveis adequadas para RD.
  • Verifique se o cluster de recuperação de desastres tem conetividade de rede e as autorizações adequadas para aceder ao repositório Git.
  • Inclua todos os tipos de recursos como código para evitar a intervenção manual durante a comutação por falha (por exemplo, componentes de infraestrutura, cargas de trabalho de aplicações e configurações).

Regras de firewall

Defina políticas de firewall unificadas e aplique-as de forma consistente em ambos os clusters para controlar o fluxo de tráfego e melhorar a segurança.

Siga o princípio do menor privilégio, o que significa que restringe o tráfego de entrada e saída apenas ao que é necessário para a funcionalidade da aplicação.

Implementação

Para saber como implementar uma topologia baseada nesta arquitetura de referência, consulte a documentação da Red Hat.

O que se segue?