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 no nível do 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-passivas (esta página)
- Estratégias de recuperação de desastres para configurações ativo-inativas
Arquitetura para recuperação de desastres
O diagrama de arquitetura a seguir mostra um cenário de implantação ativo-passivo para o OpenShift no Google Cloud:
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 é mantido pronto para assumir o controle se o principal falhar. Essa configuração garante o mínimo de tempo de inatividade, já que o cluster secundário é provisionado previamente e está em um estado quente. Isso significa que ele está configurado com a infraestrutura e os componentes de aplicativo necessários, mas não está veiculando 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 modo de espera para recuperação de desastres. O cluster secundário é mantido em um estado quente e está pronto para assumir o controle com o mínimo de atraso em caso de falha do cluster principal.
Descrição dos componentes em um cenário de DR ativo-passivo
Essa arquitetura tem a seguinte configuração:
- Cluster principal do OpenShift (ativo): localizado na região principal Google Cloud , esse cluster executa a carga de trabalho de produção e veicula ativamente todo o tráfego do usuário em condições normais de operação.
- Cluster secundário do OpenShift (passivo): localizado em uma região separada Google Cloud para isolamento de falhas, esse cluster atua como o cluster de espera quente. Ele está parcialmente configurado e em execução e está pronto para assumir o controle se o sistema principal falhar. Ele tem a infraestrutura, a configuração do OpenShift e os componentes do aplicativo implantados nele, mas não veicula tráfego de produção ao vivo até que um evento de failover seja acionado.
- Google Cloud regiões: locais geograficamente isolados que fornecem a base para a recuperação de desastres. O uso de regiões separadas garante que um evento em grande escala que afete uma região não afete o cluster de espera.
- Balanceador de carga HTTPS externo global: atua como o ponto de entrada único e 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 principal.
- 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 cluster (por exemplo, bancos de dados ou estado de volumes permanentes). Essa abordagem garante a consistência dos dados e minimiza a perda de dados durante um failover, ajudando você a atender ao 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, o Cloud Monitoring, as verificações de integridade do balanceador de carga e o 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 automatizado) para redirecionar o tráfego do cluster principal para o secundário após a detecção de uma falha irrecuperável no principal. Esse processo normalmente envolve a atualização da configuração de back-end do balanceador de carga global para segmentar o cluster secundário, tornando-o o novo site ativo.
- Rede VPC: a infraestrutura de rede subjacente que Google Cloud cria a conectividade necessária entre regiões para replicação e gerenciamento de dados.
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 DR ativo-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 a frio, 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 a segundos).
- Setores regulamentados com limites de tempo de inatividade rigorosos e aplicativos de negócios críticos em que o custo de manutenção de um cluster de espera quente é justificado pelo impacto comercial do tempo de inatividade.
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.
Proteção do estado e da configuração do aplicativo
A plataforma de contêineres do OpenShift fornece o OADP e oferece proteção abrangente de recuperação de desastres para aplicativos em execução em clusters. É possível usá-lo para fazer backup dos objetos do Kubernetes e do OpenShift usados por aplicativos conteinerizados e máquinas virtuais (por exemplo, implantações, serviços, rotas, PVCs, ConfigMaps, secrets e CRDs). No entanto, o 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 fornece processos de backup e restauração para volumes permanentes que dependem do armazenamento em blocos e dos armazenamentos NFS usados pelos aplicativos. É possível realizar esses processos usando ferramentas como Restic ou Kopia para criar snapshots ou realizar backups no nível do arquivo.
O OADP é útil para fazer backup de definições de objetos, garantir a consistência da configuração e, potencialmente, 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 ativo-passiva, recomendamos configurar 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 possa assumir o controle sem problemas. Conforme descrito na seção a seguir, a implementação da replicação de dados dos clusters principal para o secundário depende do tipo de armazenamento usado pelo aplicativo.
Armazenamento em blocos (volumes permanentes)
Use a replicação assíncrona do Persistent Disk 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 os dois 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 do Persistent Disk.
Objetos PersistentVolumes
No OpenShift, crie objetos PersistentVolumes nos dois clusters que se vinculam a esses discos e verifique se os aplicativos usam as mesmas declarações de volume permanente (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. Também é possível usar um serviço gerenciado como o Pub/Sub para facilitar a replicação de tipos específicos de dados ou eventos de aplicativos.
Backups de bancos 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 bancos de dados, este documento usa o PostgreSQL como um banco de dados de exemplo.
Backups auto-hospedados usando um operador de banco de dados no cluster
Operadores de banco de dados, como o operador CloudNative PostgreSQL, podem facilitar backups programados e recuperação de desastres para clusters do PostgreSQL. O operador CloudNative PostgreSQL é integrado nativamente 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 principal e secundário para garantir que, mesmo em caso de interrupção na região principal, 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 de configuração detalhadas, consulte a documentação do CloudNativePG.
Em caso de desastre, é possível restaurar backups para um novo cluster do PostgreSQL, garantindo o mínimo de tempo de inatividade e perda de dados. 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 configurar a replicação assíncrona da instância do 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 mapas de configuração 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á um potencial de perda das gravações de dados mais recentes. Projete seu aplicativo para mitigar a perda de dados. Como alternativa, use outro método de replicação.
Também recomendamos ativar 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 veicula o tráfego de produção. Essa promoção é necessária para aceitar gravações de banco de dados.
Para configurar a DR do Cloud SQL, siga as etapas descritas na documentação de recuperação de desastres do Google Cloud SQL. O uso de replicação assíncrona de banco de dados ou armazenamento causa um RPO diferente de zero para ajudar a garantir que o aplicativo possa tolerar a perda das gravações mais recentes. Como alternativa, use outro método de replicação.
Gerenciamento de secrets seguros
Secrets como senhas de banco de dados, chaves de API e certificados TLS são aspectos importantes da DR. É necessário restaurar esses secrets de maneira segura e confiável em um novo cluster.
As abordagens comuns para o gerenciamento de secrets são as seguintes:
- Usar secrets externos: use uma ferramenta como o operador de secrets externos para extrair secrets do Google Secret Manager.
- 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: gire os secrets regularmente e garanta que sua estratégia de gerenciamento de secrets acomode cenários de DR.
- Teste: teste a restauração de secrets em um ambiente preparado para confirmar se 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 armazenamentos externos.
Rede e gerenciamento de tráfego
Use Google Cloud's Global External HTTPS Load Balancer como o ponto de entrada principal para distribuir o tráfego entre vários clusters do OpenShift (por exemplo, clusters principal e secundário). 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:
- Usar 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 externo dos balanceadores de carga regionais que expõem os serviços de entrada de cada um dos clusters do OpenShift (roteadores OCP). O balanceador de carga global roteia o tráfego para esses IPs de balanceador de carga regional. 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 segmente os pods do controlador de entrada do OpenShift (roteador) diretamente usando o PodIP:TargetPort interno. Esse método ignora o salto extra e o proxy de nó adicional. Normalmente, ele 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 em 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 para 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 a conectividade perfeita entre clusters.
- VPCs de modo personalizado: use VPCs de modo personalizado e crie sub-redes específicas nas regiões em que os 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 de rede e evitar conflitos de endereços IP.
Verifique se há intervalos de IP não sobrepostos entre as regiões para evitar problemas de roteamento.
Tráfego entre clusters com o Red Hat Service Mesh
O OpenShift oferece suporte à federação do Service Mesh, que permite a comunicação entre serviços implantados em vários clusters do OpenShift. Essa função é particularmente ú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 principal e secundário, consulte a documentação do Red Hat.
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 a performance do aplicativo nos ambientes principal e secundário.
- Saiba como instalar o OpenShift no Google Cloud.
- Saiba mais sobre as soluções do Red Hat no Google Cloud.