top of page

Configuração e Orquestração do OCI Full Stack Disaster Recovery (FSDR)

Atualizado: há 3 horas

Por Andrey Schulz– Especialista em Arquiteturas de Missão Crítica e Cloud


Manter a continuidade de negócios frente a interrupções de datacenters sempre exigiu o desenvolvimento de scripts complexos e orquestração manual. O resultado? Risco altíssimo de erro humano no momento do caos. 

Para resolver este problema, a Oracle introduziu o OCI Full Stack Disaster Recovery (FSDR), um serviço de orquestração que provê capacidades de recuperação de desastres abrangentes para todas as camadas de uma aplicação (infraestrutura, banco de dados, storage e rede). 

Neste artigo técnico definitivo, vamos explorar desde a preparação absoluta do ambiente (pré-requisitos) até o gerenciamento ativo dos grupos e planos de recuperação no console da Oracle Cloud Infrastructure (OCI). 


Parte 1: Fundamentos e Pré-requisitos de Arquitetura


O FSDR é um orquestrador brilhante, mas ele pressupõe que a infraestrutura subjacente, o armazenamento e a segurança já estejam devidamente alinhados para a transição. O FSDR não cria a replicação de dados; ele a gerencia.


1.1 Políticas de IAM (Identity and Access Management)


O FSDR é um serviço autônomo que executa ações críticas (desligar instâncias, fazer failover de bancos, alterar rotas). Você deve configurar políticas dinâmicas no Tenant permitindo que o serviço atue em ambas as regiões (Primária e Standby).

As políticas obrigatórias no OCI IAM incluem:


codeText 

Allow service full-stack-dr to manage instance-families in tenancy

Allow service full-stack-dr to manage databases in tenancy

Allow service full-stack-dr to manage autonomous-databases in tenancy

Allow service full-stack-dr to manage volume-groups in tenancy

Allow service full-stack-dr to manage load-balancers in tenancy

Allow service full-stack-dr to manage file-family in tenancy

Allow service full-stack-dr to use keys in tenancy

Allow service full-stack-dr to read secrets in tenancy


1.2 - OCI Vault e Secrets (Para Bancos de Dados Oracle)


O FSDR precisa se conectar ao seu Oracle Database para invocar o Data Guard. A Oracle proíbe que senhas sejam inseridas em texto puro. 


  • Ação: Crie um OCI Vault na Região Primária e outro na Região Standby. Crie um Secret em cada Vault contendo a senha do usuário SYS (sysdba). 

  • Nota: O OCID deste Secret será exigido no momento em que você adicionar o banco de dados como membro do Grupo de DR. 


1.3 - Armazenamento e Logs (Object Storage & Block Volumes)


  • Log Location (Object Storage): Crie um Bucket na Região Standby para armazenar os logs de auditoria do FSDR. Habilite o Object Versioning para evitar deleções acidentais. 

  • Block Volumes: Se sua aplicação depende de discos adicionais acoplados às VMs, habilite o Cross-Region Replication (Replicação entre Regiões) nativo. Agrupe esses discos em um Volume Group, pois o FSDR gerencia grupos para garantir consistência de crash (Crash-consistent backup). 


1.4 Bancos de Dados Oracle (Base DB, ExaCS) 


  • Configure um Data Guard Group para o banco de dados primário. 

  • Garanta que o banco Standby esteja provisionado e sincronizando na Região Standby exata que será utilizada. O FSDR suporta a associação de apenas um banco standby por plano de proteção. 


1.5 Instâncias de Computação (Movable vs. Non-Movable) 


  • Movable Instances: A VM só existe na região primária. O Boot Volume da VM primária deve ter a replicação cross-region ativada. O FSDR desligará a VM na origem, pegará a réplica no destino e recriará a máquina. 

  • Non-Movable Instances: Você já provisionou uma VM espelho na região Standby (ex: um cluster ativo-passivo). O FSDR apenas orquestrará o comando de Start/Stop. 


1.6 OCI Run Command e Scripts Customizados


Se a topologia contém aplicações customizadas, o plugin Compute Instance Run Command deve estar habilitado no Oracle Cloud Agent em todas as VMs. Isso permitirá que o FSDR injete scripts locais (ex: clear_cache.sh) com os privilégios corretos no S.O. durante o failover. 


PARTE 2: Manage Disaster Recovery Protection Groups (DRPGs)


Com os pré-requisitos prontos, entramos na orquestração. O DR Protection Group (DRPG) é o contêiner lógico que agrupa todos os recursos da nuvem em uma região.


2.1 Criando e Pareando os Grupos de Proteção


A topologia de DR exige sempre dois grupos pareados.


  1. Navegue até Migration & Disaster Recovery > Disaster Recovery > DR Protection Groups.

  2. Na Região Primária (ex: São Paulo), clique em Create DR Protection Group. Nomeie como DRPG-App_Prod_SP e defina a Role como Primary.


  1. Mude para a Região Standby (ex: Vinhedo), crie outro grupo. Nomeie como DRPG-App_Stby_VIN e defina a Role como Standby.

  2. Associação (Peering): Acesse o grupo Primário (DRPG-App_Prod_SP), clique em Associate, aponte para a Região Peer (Vinhedo) e selecione o grupo Standby. O status mudará para Associated.


2.2 Gerenciando Membros (Adding Members)


Todo recurso deve ser adicionado ao DRPG Primário. O FSDR mapeia automaticamente o destino através das replicações já configuradas. Dentro do DRPG Primário, clique em Members > Add Member: 


  • Databases: Selecione o banco de dados (forneça o OCID do Vault Secret criado no passo 1.2). 

  • Compute Instances: Selecione as VMs da aplicação (classificando-as como Movable ou Non-Movable, conforme definido no passo 1.5). 

  • Volume Groups: Adicione os grupos de discos de dados replicados. 

  • Load Balancers: Adicione os balanceadores de carga primários. O FSDR pedirá para mapear qual é o Load Balancer correspondente na região Standby. 


PARTE 3: Manage Disaster Recovery Plans (DR Plans)


O Plano de DR converte a lista de membros em uma árvore de execução lógica. 


⚠️ Atenção: Os Planos de DR para recuperar uma aplicação devem ser criados sempre no DRPG Standby. 


3.1 Criando o Plano de Recuperação


  1. Acesse o grupo Standby (DRPG-App_Stby_VIN). 

  2. Vá em Disaster Recovery Plans e clique em Create DR Plan. 

  3. Selecione o Tipo de Plano: 

  4. Switchover: Operação planejada sem perda de dados (RPO Zero). 

  5. Failover: Operação de desastre real. 

  6. Start Drill / Stop Drill: Criação de simulação de DR em rede isolada. 

  7. Clique em criar. O mecanismo inteligente do FSDR construirá a árvore de dependências (Parar Origem -> Virar DB -> Subir Destino).


3.2 Customizando Passos (User-Defined Plan Groups)


  1. Abra o DR Plan recém-criado e clique em Edit Plan. 

  2. Clique em Add Group (ou selecione um grupo existente e clique em Add Step). 

  3. Integre com o OCI Run Command: Diga em qual VM o script vai rodar, informe o User ID (ex: opc) e defina um Timeout. Você pode arrastar este passo para a ordem exata desejada na execução. 


3.3 Pré-Checagens (Prechecks)


  1. Na tela do plano, clique em Execute DR Plan e selecione Run Precheck. 

  2. O FSDR testará conectividade do IAM, Vault, status do Data Guard e limites (Quotas) na região de destino. 

  3. O plano só estará apto para execução real se todos os logs de pré-checagem retornarem Passed. 


3.4 Executando o Plano e Monitoramento


  1. Com o Precheck validado, clique em Execute DR Plan (agora desmarcando a opção Precheck). 

  2. O painel de Plan Execution abrirá, mostrando o status de cada passo em tempo real.

  3. Se um script falhar, o FSDR entrará em Paused. Você pode corrigir a falha no S.O. e clicar em Resume ou Ignore Step diretamente no console, permitindo que a orquestração retome de onde parou. 




Comentários

bottom of page