Um backup protege os dados. No entanto, quando uma infraestrutura inteira fica indisponível, a recuperação precisa ir além de restaurar arquivos: é preciso conseguir recuperar as cargas em outro ambiente. É nesse cenário que o Disaster Recovery no Apache CloudStack ganha uma nova possibilidade com a versão 4.22: criar uma nova instância a partir de um backup em outra Zone.

Assim, uma falha na infraestrutura de origem não precisa interromper a operação. O backup passa a funcionar como ponto de partida para reconstruir a instância em uma infraestrutura disponível.

Backup não é Disaster Recovery

Primeiramente, vale separar os dois conceitos. O backup mantém uma cópia dos dados para recuperação posterior. Já o Disaster Recovery reúne estratégias e processos para recuperar uma operação depois de uma falha que comprometa sua infraestrutura.

Por isso, ter um backup disponível não garante, sozinho, uma estratégia de recuperação. É preciso saber onde a carga será reconstruída, quais recursos estarão disponíveis e como o processo de retomada vai funcionar.

No CloudStack 4.22, a restauração cross-zone amplia essa possibilidade. O recurso permite usar um backup existente para criar uma nova instância em uma Zone diferente daquela em que o backup foi criado. A própria documentação do Apache CloudStack indica essa capacidade como uma forma de implementar recursos de Disaster Recovery com Instance Backups.

O que muda no Apache CloudStack 4.22?

A partir da versão 4.22, o CloudStack permite selecionar uma Zone de destino ao criar uma nova instância a partir de um backup. Na documentação do CloudStack 4.22, essa capacidade é suportada pelo NAS Backup & Recovery Plugin.

Na prática, o fluxo fica assim:

Instância na Zone A → Backup → Backup Repository → Nova instância na Zone B

Além disso, o sistema pode aproveitar configurações registradas no backup quando os mesmos recursos estão disponíveis no ambiente de destino. Quando algum recurso não está disponível na outra Zone, o usuário precisa reconfigurá-lo antes de criar a nova instância, como pode ocorrer com redes específicas de uma Zone.

Portanto, o processo não transfere simplesmente a VM original. Em vez disso, o CloudStack usa o backup para criar uma nova instância na Zone escolhida, com configurações herdadas do backup ou ajustadas pelo usuário.

Como funciona a restauração cross-zone na prática?

Primeiramente, o administrador precisa habilitar a opção Cross-Zone Instance Creation no Backup Repository. Depois disso, o repositório pode ser usado para criar instâncias em outras Zones do ambiente CloudStack.

Para isso, os hosts das outras Zones precisam conseguir acessar e montar o Backup Repository. Essa conectividade é necessária para realizar a recuperação.

Durante o processo, o CloudStack monta o repositório por meio de NFS, CIFS ou CephFS, conforme a configuração adotada. Em seguida, os arquivos do backup são copiados para o Primary Storage da Zone de destino, onde a nova instância será criada.

Assim, a arquitetura precisa considerar não apenas a existência do backup, mas também a conectividade entre o repositório e a Zone que receberá a nova instância.

O que a infraestrutura precisa para recuperar a carga?

Para que a recuperação cross-zone funcione, alguns elementos precisam trabalhar em conjunto:

Elemento	Papel na recuperação
Instance Backup	Fornece os dados e as informações de configuração usadas na criação da nova instância
Backup Repository	Armazena os backups utilizados no processo de recuperação
Cross-Zone Instance Creation	Permite criar a nova instância em outra Zone
Conectividade	Permite que os hosts da Zone de destino acessem e montem o Backup Repository
Primary Storage	Recebe os arquivos do backup durante o processo de recuperação
Zone de destino	É a Zone na qual a nova instância será criada

Dessa forma, a recuperação depende da integração entre o backup, o repositório, a conectividade com os hosts da Zone de destino e os recursos disponíveis para criar a nova instância.

Duas formas de estruturar o Disaster Recovery

Além disso, o próprio Apache CloudStack apresenta duas abordagens para estender o mecanismo de recuperação cross-zone a arquiteturas de DRaaS.

Uma opção utiliza repositórios locais por Zone. Nesse modelo, o Backup Repository fica associado à Zone de origem, enquanto servidores NAS são configurados nas outras Zones para sincronizar os arquivos de backup em segundo plano. Com o uso de DNS, a URL do repositório pode ser direcionada para o NAS local de cada Zone, permitindo que a criação da instância utilize a cópia mais próxima da infraestrutura de destino.

Outra alternativa utiliza um repositório global acessível por diferentes Zones. Nesse cenário, um único repositório fica disponível para todas as Zones. A documentação alerta que o desempenho do NFS sobre WAN pode se tornar um gargalo durante a criação cross-zone. Para esse cenário, o CloudStack recomenda opções específicas de montagem do NFS para melhorar o desempenho.

Assim, a arquitetura pode ser estruturada de acordo com a distribuição das Zones e as características de conectividade entre os ambientes.

Disaster Recovery: RPO, RTO e o tempo de recuperação 

Nesse ponto, entra uma questão que ultrapassa a configuração do CloudStack: qual nível de recuperação a operação realmente precisa?

O RPO (Recovery Point Objective) define o ponto no tempo até o qual os dados precisam estar disponíveis após uma recuperação. Por exemplo, se o último backup disponível ocorreu uma hora antes da falha, as alterações realizadas nesse intervalo podem ficar fora da recuperação.

Já o RTO (Recovery Time Objective) determina quanto tempo a operação pode permanecer indisponível até a recuperação. Nesse cálculo, a infraestrutura precisa considerar o tempo necessário para acessar o backup, recuperar os dados, criar a nova instância e restabelecer os serviços necessários para a operação.

Assim, uma arquitetura de Disaster Recovery não deve avaliar apenas se consegue restaurar uma instância. Também precisa considerar qual é o ponto de recuperação disponível e quanto tempo é necessário para voltar a operar.

Cross-zone não significa DR completo

Apesar do avanço, a restauração entre Zones representa uma capacidade dentro de uma estratégia maior. O próprio CloudStack indica que administradores podem estender esse recurso com configurações e mecanismos complementares para implementar uma solução de Disaster Recovery as a Service (DRaaS).

Por isso, uma implementação de DR também precisa considerar a sincronização dos backups, os recursos disponíveis na Zone de destino, a conectividade e as configurações de rede. Além disso, é importante avaliar as dependências da aplicação que precisam estar disponíveis para a retomada dos serviços.

A recuperação também precisa ser testada. Afinal, ter um backup disponível no repositório não comprova, por si só, que a aplicação conseguirá voltar a funcionar após uma falha na infraestrutura original.

Recuperação começa antes da falha

A restauração cross-zone amplia as possibilidades de recuperação no Apache CloudStack, mas a equipe de infraestrutura precisa integrar essa capacidade à arquitetura de Disaster Recovery para aproveitar todo o seu potencial. Logo, repositórios, conectividade, recursos da Zone de destino, configuração de rede e testes de recuperação precisam fazer parte do planejamento.

Para transformar esse mecanismo em uma estratégia de DR alinhada à operação, também é necessário entender os requisitos da infraestrutura e os objetivos de recuperação de cada ambiente.

A SC Clouds pode ajudar a avaliar esse cenário e definir a arquitetura mais adequada para sua infraestrutura CloudStack.

Fale com a SC Clouds e veja como estruturar sua estratégia de Disaster Recovery.