Configurar a recuperação de desastre para Omnissa Access

O Omnissa Access oferece suporte à recuperação de desastre usando um modelo de backup e restauração com uma montagem do NFS compartilhada. Nesse modelo, um cluster secundário tem acesso aos dados de backup produzidos pelo cluster primário. Após um evento de DR declarado, o cluster secundário é promovido manualmente para primário e gerencia o tráfego de leitura/gravação. O failback para o site original é uma operação manual planejada; ele não acontece automaticamente. Quando o cluster primário original ficar disponível, ele permanecerá na função secundária até que o failback planejado seja executado.

Este tópico descreve como configurar o armazenamento de backup do NFS, gerenciar agendamentos de backup, fazer backup dos dados necessários do nó de bootstrap e restaurar o Omnissa Access do backup durante um failover.

---

Pré-requisitos

Antes de configurar a recuperação de desastre, certifique-se de que as seguintes condições sejam atendidas:

• Um compartilhamento replicado do NFS está configurado e fica acessível pela rede tanto para os nós primários do cluster quanto para os nós secundários do cluster.
• O cluster secundário será implantado usando a mesma versão do pacote de ativos que o cluster de origem.
• Você tem acesso administrativo ao nó de bootstrap do cluster primário para fazer backup de segredos e arquivos de configuração.

---

Configurar as exportações de NFS no servidor NFS

Como os serviços de backup são executados como raiz, a exportação do NFS deve incluir a opção no_root_squash. No servidor NFS, verifique a configuração de exportação no /etc/exports:

cat /etc/exports

A saída deve incluir uma entrada no seguinte formato:

<NFS-MOUNT-POINT> <NFS-CLIENT-IP>(rw,sync,no_subtree_check,no_root_squash)

<NFS-CLIENT-IP> é o intervalo de IPs ou o conjunto de IPs que abrange todos os nós do cluster com permissão para acessar a montagem. Por exemplo, se os nós do cluster de origem usarem endereços no intervalo 10.48.34.100–10.48.34.105, defina <NFS-CLIENT-IP> como 10.48.34.0/24 para cobrir a sub-rede completa. Quando o cluster secundário é promovido a primário durante um failover, seus endereços de nó também devem se enquadrar no intervalo de IPs permitido.

---

Configurar o profile.yml para backup do NFS

O cluster de origem deve ser configurado para gravar backups em uma montagem do NFS compartilhada antes que os serviços sejam implantados. Esses backups são usados para restaurar o cluster secundário durante um failover.

1. No nó de bootstrap do cluster de origem, abra /root/<cluster_name>/profile.yml.

2. Localize as seguintes linhas, preencha-as com os detalhes do servidor do NFS e remova os comentários delas:

   nfs_host: <NFS-HOST-IP>
   nfs_path: <NFS-MOUNT-POINT>
   nfs_version: 4
   

3. Salve o arquivo e, em seguida, prossiga com a implantação do serviço conforme descrito na Fase 4 e na Fase 5 deste guia.

   Nota: se os detalhes do NFS não tiverem sido incluídos no profile.yml antes da implantação inicial do serviço, adicione-os depois e reimplante os serviços dependentes de backup:

     > ```bash
     > wso services deploy -s postgres
     > wso services deploy -s control-plane-backup
     > wso services deploy -s opensearch
     > ```
   

4. Para confirmar que a montagem do NFS pode ser acessada de outra máquina no cluster secundário, execute os seguintes comandos de uma máquina virtual separada:

   # Mount the NFS share manually to test connectivity
   mount -t nfs <NFS-IP>:<NFS-MOUNT-POINT> /mnt
   
   # List the NFS exports visible to the client
   showmount -e <NFS-IP>
   

   A saída de showmount -e deve incluir uma entrada para o ponto de montagem configurado:

   <NFS-MOUNT-POINT> <NFS-IP>
   

---

Fazer backup dos dados do nó de bootstrap

Os itens a seguir do nó de bootstrap primário devem estar disponíveis no nó de bootstrap secundário antes que uma restauração possa continuar. Faça backup desses itens em um local seguro antes que um evento de DR ocorra.

A Omnissa recomenda armazenar esses dados no mesmo servidor do NFS usado para backups de serviço, mas em uma montagem do NFS separada, para evitar qualquer interferência em operações de backup automatizadas.

---

Configurar a frequência e a retenção de backup

Você pode controlar a frequência com que os backups são obtidos e por quanto tempo eles são retidos, definindo variáveis de ambiente no arquivo additional_env_vars.env no nó de bootstrap. Essas configurações determinam seu objetivo de ponto de recuperação (RPO): a quantidade máxima de dados que podem ser perdidos em caso de falha.

---

Tipos de backup de base de dados

O Omnissa Access usa dois tipos de backup complementares para a base de dados PostgreSQL.

Backup completo

Um backup completo captura um snapshot completo de todo o diretório de dados PostgreSQL em um determinado point-in-time. Os backups completos são independentes e podem ser restaurados sem arquivos de backup adicionais. Por padrão, um backup completo da base de dados é executado uma vez por dia às 5h UTC e serve como a linha de base para backups delta.

Backup delta

Um backup delta captura apenas as páginas de dados que mudaram desde o backup completo mais recente. Os backups delta são menores e mais rápidos de serem concluídos do que os backups completos, mas não são independentes. A restauração de um backup delta requer tanto o backup completo mais recente quanto o backup delta. Por padrão, um backup delta é executado uma vez por dia às 17h UTC.

Juntos, os trabalhos de backup completo e delta fornecem cobertura diária completa. Em uma falha que ocorre entre backups agendados, a restauração utiliza o backup completo mais recente, com o delta mais recente aplicado sobre ele, limitando a possível perda de dados a um período de aproximadamente 12 horas.

Profundidade da cadeia de backup delta

O número máximo de camadas de backup delta que podem ser encadeadas sobre um único backup completo foi corrigido em 2. Esse limite é imposto internamente por WALG_DELTA_MAX_STEPS e não é configurável.

Full Backup (base)
└── Delta 1 (changes since Full Backup)
    └── Delta 2 (changes since Delta 1)  ← maximum chain depth

Quando a cadeia atinge o máximo configurado, WAL-G promove automaticamente o próximo backup delta agendado para um novo backup completo.

Você pode ajustar a agenda de backups completos e delta, mas deve garantir que não mais do que dois backups delta sejam executados entre backups completos sucessivos. Não há suporte para exceder esse limite.

---

Requisitos de rede e de FQDN

Para oferecer suporte a um failover sem exigir alterações na configuração do usuário final ou do conector, o cluster secundário deve atender aos seguintes requisitos antes de ocorrer um evento de DR:

• Os certificados TLS em endpoints de cluster secundário devem ser válidos para o mesmo nome de domínio completo (FQDN) que o cluster primário. Os processos de rotação de certificado devem abranger os sites primário e secundário de forma consistente.
• As regras de firewall devem permitir o tráfego de saída para endpoints de cluster primário e secundário. Os intervalos de endereços IP publicados devem ser mantidos ativamente para ambos os sites.
• O estado da sessão do conector deve ser totalmente recompilável no gateway secundário, sem dependência rígida no armazenamento de sessão que existe apenas no cluster primário.

---

Restaurar Omnissa Access por meio do backup

Este procedimento descreve como ativar o cluster secundário como o novo primário durante um failover. Quando a restauração estiver concluída, o cluster secundário lidará com todo o tráfego de leitura e gravação. O cluster primário original, quando ele estiver disponível novamente, será tratado como o novo secundário até que um failback planejado seja executado.

Importante: antes de iniciar esse procedimento, certifique-se de que o cluster primário original não esteja acessível pelo cluster secundário. Se o cluster original ainda estiver acessível durante a restauração, o OpenSearch e o PostgreSQL poderão tentar adicionar nós do cluster original ao cluster restaurado.

Nota: a Omnissa recomenda a realização de simulados de restauração programados em um ambiente que não seja de produção antes de implementar a recuperação de desastre em produção. Isso estabelece estimativas realistas de objetivo de tempo de recuperação (RTO) com base em seus volumes de dados reais.

Pré-requisitos

Antes de iniciar o procedimento de restauração, confirme:

• O cluster secundário será implantado utilizando a mesma versão do pacote de ativos do cluster de origem, para garantir que todas as imagens do serviço do Omnissa Access sejam compatíveis.
• Os dados do nó de bootstrap listados em Realizar backup dos dados do nó de bootstrap são acessíveis no nó de bootstrap secundário.

Procedimento

Etapa 1: implantar o cluster secundário

Provisione novas máquinas virtuais e implante o pacote de ativos do Control Plane nelas, usando a mesma versão do pacote de ativos que o cluster de origem. O cluster secundário deve ter a mesma configuração que o cluster de origem.

Importante: nesta etapa, implante apenas os serviços da plataforma CP: Vault, Consul e Nomad. Não implante serviços do Omnissa Access nesta fase. Os serviços de acesso serão restaurados mais tarde no procedimento.

Antes de continuar, faça backup do diretório /root/<cluster_name>/cp-cluster/secrets/cp-cluster no nó de bootstrap secundário.

Tempo estimado: 30 minutos

---

Etapa 2: tirar snapshot dos nós do cluster secundário

Depois que o Control Plane for implantado com êxito, tire snapshots da máquina virtual de todos os nós de cluster secundários. Esses snapshots fornecem um ponto de restauração comprovadamente válido, caso seja necessário reiniciar o procedimento de recuperação de desastre.

Nota: se você reverter para esses snapshots em qualquer momento durante o procedimento de restauração, confirme se o Vault não está selado no cluster secundário antes de continuar. Faça login na UI do Vault usando as credenciais apropriadas para confirmar se o status do Vault está desbloqueado.

---

Etapa 3: copiar segredos no cluster secundário

Copie as pastas tls e vault do seu local de backup para o diretório backup_secrets do cluster secundário:

• Copie a pasta de backup tls → /root/<cluster_name>/cp-cluster/backup_secrets/tls
• Copie a pasta de backup vault → /root/<cluster_name>/cp-cluster/backup_secrets/vault

Depois de copiar, verifique se o diretório backup_secrets no nó de bootstrap secundário contém as duas pastas:

ls -lrt backup_secrets/
total 0
drwxr-x---. 2 root root 64 May  7 07:46 tls
drwxr-x---. 4 root root 30 May  7 07:46 vault

---

Etapa 4: planejar a restauração do backup

No diretório do cluster secundário, execute o seguinte comando para revisar o backup e confirmar o ponto de restauração:

wso cp plan-restore-backup

Para restaurar de um point-in-time específico, use o sinalizador de -a com uma duração de tempo. Por exemplo:

Esse sinalizador define o RPO para a operação de restauração.

---

Etapa 5: restaurar componentes do Control Plane

Esta etapa restaura os dados de chave-valor do Consul e os segredos do Vault no cluster secundário.

1. Certifique-se de que o Vault esteja desbloqueado no cluster secundário.

2. Antes de executar o comando de restauração, confirme se as pastas tls e vault estão presentes em backup_secrets no nó de bootstrap secundário:

   ls -lrt /root/<cluster_name>/cp-cluster/backup_secrets/
   

   A saída deve mostrar os diretórios tls e vault:

   drwxr-x---. 2 root root 64 <date> tls
   drwxr-x---. 4 root root 30 <date> vault
   

3. No diretório do cluster, execute:

   wso cp restore-backup
   

   O comando restaura os dados de chave-valor do Consul e os segredos do Vault no cluster secundário. Saída esperada:

   Imports KV in case of disaster recovery
   Backing up control plane credentials
   Restoring vault
   Restoring control plane credentials
   Resetting vault integration tokens
   Resetting vault integration token in nomad
   Resetting vault PKI integration token
   Updated vault with secrets after restore during Disaster recovery
   Adding PKI root and intermediate CA to truststore
   Deploying vault
   Restarting vault servers
   Unsealing Vault
   Enabling consul and nomad integration with vault
   Deploying consul
   Configuring consul connect CA provider
   Restarting the consul leader
   Restarting nomad scheduler agent
   Cleaning up
   Generating environment file with cluster details and secret tokens
   

   Nota: se ocorrer um erro durante esta etapa, reverta todas as máquinas virtuais do cluster secundário para os snapshots criados na Etapa 2, confirme se o Vault está desbloqueado no cluster secundário e reinicie o procedimento na Etapa 3.

   Tempo estimado: 15 minutos

---

Etapa 6: restaurar serviços

Esta etapa restaura a base de dados e todos os serviços. Não são realizados backups durante esta etapa.

1. Copie o arquivo de variáveis de ambiente do local de backup para o nó de bootstrap secundário:

   /root/<cluster_name>/additional_env_vars.env
   

2. Copie o perfil de serviço do Access para o nó de bootstrap secundário:

   /root/<cluster_name>/access/access-profile.yml
   

3. No arquivo access-profile.yml, execute o seguinte:

   • Atualize os campos ip_ignore_list_for_xff_header e fqdn.ip para refletir os endereços IP e a configuração do cluster secundário.
   • Adicione a sub-rede do Nomad à lista ip_ignore_list_for_xff_header.
     • Nota: o valor-padrão é 172.26.64.0/20. Se você optou por fazer a implantação com uma sub-rede personalizada, atualize o valor da sub-rede no campo ip_ignore_list_for_xff_header de acordo com isso.

4. Atualize o servidor DNS para direcionar o FQDN para o cluster secundário.

5. Confirme se o cluster primário original está offline ou não acessível.

6. Execute o seguinte comando para restaurar todos os serviços:

   wso services restore --cps_image <cps-image>
   

   Nota: se algum trabalho falhar durante esta etapa, elimine-o e execute novamente o mesmo comando.

   Para restaurar apenas um serviço específico, inclua o sinalizador -s:

   wso services restore -s <service-name> --cps_image <cps-image>
   

   Em que <cps-image> é a tag de imagem de serviços do Control Plane que corresponde à implantação do cluster de origem.

   Nota: se ocorrer um erro durante esta etapa, reverta todas as máquinas virtuais do cluster secundário para os snapshots criados na Etapa 2, confirme se o Vault está desbloqueado no cluster secundário e reinicie o procedimento na Etapa 3.

   Tempo estimado: no mínimo, 75 minutos. O tempo real varia linearmente com o volume de dados no PostgreSQL e no OpenSearch.

---

Etapa 7: concluir as operações de restauração e retomada de backup

Execute o seguinte comando para verificar os dados restaurados e ativar as operações de backup no cluster primário recém-promovido:

wso services restore-complete --cps_image <cps-image>

Tempo estimado: 10 minutos

---

Objetivo de tempo de recuperação

O objetivo de tempo de recuperação (RTO) total depende do volume de dados no PostgreSQL e no OpenSearch. O RTO mínimo esperado é de aproximadamente duas horas, com o tempo real aumentando proporcionalmente com o volume de dados. A Omnissa recomenda a realização de simulados de restauração cronometrados para estabelecer valores de RTO específicos para sua implantação antes de confiar neste procedimento em uma failover de produção.