Estratégia de Recuperação de Desastres e Backup entre Regiões

Esta é a nossa estratégia abrangente de recuperação de desastres (DR) e backup entre regiões para a aplicação SaaS da Quadrical. Seu frontend é implantado em Kubernetes (k8s), com um pod de InfluxDB que utiliza EFS para armazenamento, e o backend é gerenciado com um banco de dados PostgreSQL na AWS. Nosso objetivo é garantir a continuidade dos negócios, minimizar a perda de dados e reduzir o tempo de inatividade em caso de desastre, atendendo ao Objetivo de Ponto de Recuperação (RPO) e ao Objetivo de Tempo de Recuperação (RTO) definidos para cada componente da aplicação.

Estratégia de Recuperação de Desastres

Elaboramos uma estratégia de DR adaptada a cada componente da aplicação, com foco em atingir os valores desejados de RPO e RTO.

Aplicação Frontend

RPO

Não aplicável (stateless, ou seja, sem estado).

RTO

Minimizado com o uso de deployments do Kubernetes, grupos de Auto Scaling da AWS e Elastic Load Balancing (ELB).

InfluxDB

RPO

Minimizado por meio do agendamento de backups regulares e do seu armazenamento em um serviço de armazenamento durável, como o Amazon S3, com replicação entre regiões.

RTO

Minimizado com o uso de implantação Multi-AZ da AWS, criação de instâncias de standby e implementação de failover automático usando services e selectors do Kubernetes.

Backend (PostgreSQL gerenciado)

RPO

Minimizado com a ativação de backups automatizados do AWS RDS, recuperação pontual (PITR) e snapshots manuais.

RTO

Minimizado com o uso de implantação Multi-AZ do AWS RDS e pré-aquecimento de réplicas de leitura em outra região.

Visão Geral da Arquitetura da Aplicação

Três componentes principais:

  • Aplicação Frontend: um frontend sem estado (stateless) implantado no Kubernetes.
  • InfluxDB: um banco de dados de séries temporais executado como um pod do Kubernetes, com EFS para armazenamento.
  • Backend: um backend com estado (stateful) que utiliza um banco de dados PostgreSQL gerenciado da AWS.
Arquitetura da Aplicação
Arquitetura da Aplicação

Estratégia de Backup entre Regiões

InfluxDB

  • Backups semanais automatizados usando um script de backup e a ferramenta de backup nativa do InfluxDB.
  • Armazenamento entre regiões dos arquivos de backup no Amazon S3, com replicação ativada.
  • Procedimento de restauração detalhado, passo a passo, regularmente testado e documentado.

PostgreSQL

  • Backups semanais automatizados, usando um script de backup e uma ferramenta como o pg_dump.
  • Armazenamento entre regiões dos arquivos de backup no Amazon S3, com replicação ativada.
  • Procedimento de restauração detalhado, passo a passo, regularmente testado e documentado.

Testes e Validação

Realizar exercícios regulares de DR e testes de backup/restauração para garantir a eficácia das estratégias.

Atualizar o plano de DR e os procedimentos de backup e restauração com base nos resultados dos testes e nas mudanças na arquitetura da aplicação.

Comunicação com o Cliente

Em caso de desastre, iremos:

  • Notificar prontamente os clientes sobre o incidente e fornecer atualizações regulares.
  • Comunicar o tempo estimado de recuperação e qualquer possível perda de dados.
  • Compartilhar uma análise pós-incidente (post-mortem) e as lições aprendidas, para aprimorar nossas estratégias de Recuperação de Desastres (DR) e de backup e buscar evitar incidentes futuros.

Restauração do Cluster EKS, InfluxDB, PostgreSQL e Servidor VPN em Outra Região para Recuperação de Desastres

Esta seção da documentação de Recuperação de Desastres (DR) descreve as etapas necessárias para restaurar um cluster Amazon EKS, o InfluxDB, o PostgreSQL e um servidor VPN em outra região da AWS, caso um desastre afete a região principal. O procedimento inclui a criação do cluster EKS, a configuração do EFS na VPC do cluster EKS, a restauração dos dados a partir dos backups do InfluxDB e do PostgreSQL e a implantação dos pods de backend, frontend e servidor VPN no novo cluster EKS. Esse processo abrangente de restauração garante a continuidade dos negócios e minimiza o tempo de inatividade e a perda de dados.

  1. 1

    Definir as variáveis necessárias:

    • REGION (ex.: 'us-west-e')
    • CLUSTER_NAME (ex.: 'my-eks-cluster')
    • VPC_ID
    • SUBNET_IDS
    • EFS_SECURITY_GROUP
    • INFLUX_BACKUP_S3_URI
    • POSTGRES_BACKUP_S3_URI
  2. 2

    Criar o cluster EKS na região especificada:

    • Configurar a AWS CLI para a nova região
    • Criar o cluster EKS com CLUSTER_NAME, VPC_ID e SUBNET_IDS informados
  3. 3

    Configurar o kubectl para usar o novo cluster EKS:

    • Atualizar a configuração do Kubernetes
    • Verificar a conectividade listando os nós
  4. 4

    Criar o EFS na VPC do cluster EKS:

    • Criar o sistema de arquivos EFS
    • Criar os pontos de montagem (mount targets) do EFS na VPC, especificando SUBNET_IDS e EFS_SECURITY_GROUP
  5. 5

    Restaurar os dados do InfluxDB a partir do backup:

    • Criar um deployment do InfluxDB no Kubernetes com o ponto de montagem do EFS
    • Copiar os dados de backup do InfluxDB de INFLUX_BACKUP_S3_URI para o ponto de montagem do EFS
    • Executar o comando de restauração do InfluxDB para restaurar os dados a partir do backup
  6. 6

    Criar o banco de dados RDS PostgreSQL na região especificada:

    • Criar a instância RDS PostgreSQL com a configuração necessária
    • Aguardar até que a instância RDS esteja disponível
  7. 7

    Restaurar o banco de dados PostgreSQL a partir do backup:

    • Copiar os dados de backup do PostgreSQL de POSTGRES_BACKUP_S3_URI para um local temporário
    • Executar o comando pg_restore para restaurar os dados do backup na nova instância RDS
  8. 8

    Iniciar os pods de backend e frontend no EKS:

    • Atualizar os manifestos do Kubernetes com os novos dados de conexão do InfluxDB e do PostgreSQL
    • Aplicar os manifestos atualizados do Kubernetes para criar os deployments de backend e frontend
    • Verificar se os pods de backend e frontend estão em execução e conectados aos bancos de dados restaurados
  9. 9

    Restaurar os dados do servidor VPN a partir do backup:

    • Definir as variáveis necessárias:
    • VPN_BACKUP_S3_URI
    • VPN_CONFIGMAP_NAME (ex.: 'my-vpn-configmap')
    • VPN_SECRET_NAME (ex.: 'my-vpn-secret')
    • Criar um namespace dedicado do Kubernetes para o servidor VPN (opcional)
    • Copiar os dados de backup do servidor VPN (arquivos de configuração, certificados, chaves etc.) de VPN_BACKUP_S3_URI para um local temporário
    • Criar um ConfigMap do Kubernetes com os arquivos de configuração da VPN:
    • Usar o VPN_CONFIGMAP_NAME
    • Incluir os arquivos de configuração do servidor VPN copiados do backup
    • Criar um Secret do Kubernetes com os certificados e as chaves da VPN:
    • Usar o VPN_SECRET_NAME
    • Incluir os certificados e as chaves do servidor VPN copiados do backup
  10. 10

    Iniciar o pod do servidor VPN no EKS:

    • Atualizar o manifesto do servidor VPN no Kubernetes com as novas referências VPN_CONFIGMAP_NAME e VPN_SECRET_NAME
    • Aplicar o manifesto atualizado do servidor VPN no Kubernetes para criar o deployment do servidor VPN
    • Verificar se o pod do servidor VPN está em execução e conectado à configuração e aos certificados restaurados

Conclusão

Nossa estratégia abrangente de recuperação de desastres e backup entre regiões foi concebida para garantir a continuidade e a resiliência da aplicação SaaS com bancos de dados InfluxDB e PostgreSQL na AWS.

Ao atender aos valores desejados de RPO e RTO, automatizar os backups semanais e armazená-los em uma região separada da AWS, minimizaremos o tempo de inatividade e a perda de dados, mantendo um alto nível de serviço para nossos clientes. Testes, monitoramento e comunicação regulares ajudarão a manter a eficácia das estratégias e a garantir seu sucesso em caso de desastre.

Canadá
connect@quadrical.aikitty@quadrical.aiquadrical.ai
QR
Implantado em 2600MW Solar + 595MW / 2380 MWh de Armazenamento