OCI FSDR + OKE · Blog Lab Interativo

🎯 Objetivo do laboratório

blog lab

O que será construído?

Um cenário de Disaster Recovery para uma aplicação em Kubernetes na OCI. A aplicação Ghost Blog roda no cluster OKE primário, usa Persistent Volume baseado em Block Volume para persistência, é publicada por Ingress NGINX com Load Balancer e depois é validada no cluster standby após o Switchover.

Componentes principais

OCI Full Stack Disaster Recovery.
OKE primário e OKE standby.
Object Storage buckets para logs do FSDR.
Volume Group com replicação cross-region.
Ghost Blog com PVC e Ingress NGINX.
Plano de Switchover planejado.

🧭 Arquitetura desenhada

primary ↔ standby

Região Primária · SA-SAO PAULO-1

VCN · subnet-api · subnet-node · subnet-lb

OKE: primary-cluster

Ghost Blog + SQLite + PVC

Block Volume → Volume Group

Ingress NGINX + OCI Load Balancer

Object Storage: primary-bucket

DRPG: primary-oke

Tráfego inicial → ghost.example.com

FSDR
Engine
⇄

Região Standby · SA-VINHEDO-1

VCN · subnet-api · subnet-node · subnet-lb

OKE: standby-cluster

Ghost Blog restaurado

Volume Group replicado

Novo Load Balancer externo

Object Storage: standby-bucket

DRPG: standby-oke

Após switchover → novo EXTERNAL-IP

A ideia central é que o FSDR orquestre a movimentação ordenada dos componentes da aplicação: cluster OKE, Volume Group, dados persistentes, planos de DR e validação do serviço publicado.

📊 Dashboard de Ambiente

status dinâmico

PRIMARY REGION

OKE ClusterPENDING

Load BalancerPENDING

Ghost BlogPENDING

PVC / Block VolumePENDING

STANDBY REGION

OKE ClusterPENDING

Volume GroupPENDING

Ghost BlogWAITING

Load BalancerWAITING

DR STATUS

ReplicationPENDING

DRPG PrimaryPENDING

DRPG StandbyPENDING

Active RegionPRIMARY

Este painel muda conforme os comandos são executados no terminal. Após execute switchover-plan, a região standby passa a ficar ativa.

🔄 Timeline Visual do Switchover

orquestração FSDR

01Stop Primary

Encerrar aplicação de forma ordenada na região primária.

02Sync Volume Group

Garantir consistência dos dados persistidos.

03Promote Standby

Promover recursos replicados para região standby.

04Start Ghost

Inicializar Ghost Blog no cluster standby.

05Update LB

Validar novo EXTERNAL-IP do Load Balancer.

06Validation

Testar site, admin e post pelo browser.

🖥️ OCI Console Simulator

navegação guiada

📌 Pré-requisitos e permissões

antes de começar

Acesso OCI

Permissão para gerenciar IAM Policies no tenancy.
Permissão para gerenciar VCN, OKE, FSDR e Storage no compartment.
Cloud Shell habilitado.
Duas regiões OCI para simular primário e standby.

Convenções usadas no lab

primary-cluster e standby-cluster.
primary-bucket e standby-bucket.
ghost-ns como namespace da aplicação.
ghost.example.com como hostname do teste.

🧪 Runbook completo de configuração

passo a passo

0/0 etapas executadas

🧾 Comandos e blocos de configuração do laboratório

organizado do PDF

Esta seção reúne os comandos e blocos usados no fluxo do laboratório: acesso ao OKE, instalação do Ingress NGINX, ajuste do Load Balancer flexible, deploy do Ghost Blog, validações Kubernetes, hosts local, Volume Group, DRPG e validações pós-Switchover.

Cloud Shell / kubeconfig

oci -v
mkdir -p $HOME/.kube
oci ce cluster create-kubeconfig \
  --cluster-id <cluster_ocid> \
  --file $HOME/.kube/config \
  --region <region> \
  --token-version 2.0.0 \
  --kube-endpoint PRIVATE_ENDPOINT
export KUBECONFIG=$HOME/.kube/config
kubectl get nodes

Ingress NGINX

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.3/deploy/static/provider/cloud/deploy.yaml
kubectl get svc -n ingress-nginx

Load Balancer flexible

annotations:
  service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
  service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
  service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "1000"

Arquivo hosts

# Linux/macOS
/etc/hosts

# Windows
C:\Windows\System32\drivers\etc\hosts

<EXTERNAL-IP> ghost.example.com
163.176.210.135 ghost.example.com

Ghost Blog

kubectl apply -f https://raw.githubusercontent.com/euoraf4/blog-ghost/refs/heads/main/deploy.yaml
kubectl get all,pvc -n ghost-ns
open http://ghost.example.com
open http://ghost.example.com/ghost/

Storage / PVC / Volume Group

kubectl get pvc -n ghost-ns
# Console OCI:
Storage > Volume Groups > Create Volume Group
Nome: volume-group-pv
Cross region replication: Enable

FSDR / DRPG

DRPG Primário: primary-oke
Bucket: primary-bucket
Members: volume-group-pv + primary-cluster

DRPG Standby: standby-oke
Bucket: standby-bucket
Role: Standby
Peer DRPG: primary-oke

Pós-Switchover

kubectl get all,pvc -n ghost-ns --context standby-cluster
kubectl get all -n ingress-nginx
<NOVO-EXTERNAL-IP> ghost.example.com
open http://ghost.example.com

✅ Validação final esperada

resultado do lab

Antes do Switchover

ghost.example.com aponta para o Load Balancer da região primária.
kubectl get all,pvc -n ghost-ns mostra pod, service, deployment e PVC.
O Ghost Blog e o painel administrativo estão acessíveis.

Depois do Switchover

O FSDR ativa os recursos na região standby.
O Volume Group passa a operar na nova região ativa.
O Ghost Blog volta a responder por um novo EXTERNAL-IP.
O navegador de teste valida / e /ghost/.

Observação importante: no PDF, a etapa Terminate do Volume Group pode não ser executada por segurança. Essa remoção definitiva deve ser habilitada apenas quando o processo de DR estiver maduro e validado.

🛠️ Troubleshooting

falhas comuns

PVC não fica Bound

Verifique se o StorageClass da OCI está disponível e se o volume foi criado corretamente.

kubectl get pvc -n ghost-ns
kubectl describe pvc ghost-pv-claim -n ghost-ns
kubectl get storageclass

Pod em CrashLoopBackOff

Analise logs, eventos e variáveis do deployment do Ghost.

kubectl get pods -n ghost-ns
kubectl logs deployment/ghost -n ghost-ns
kubectl get events -n ghost-ns

Load Balancer sem EXTERNAL-IP

Confirme o serviço do Ingress NGINX e as subnets públicas configuradas para o Load Balancer.

kubectl get svc -n ingress-nginx
kubectl describe svc ingress-nginx-controller -n ingress-nginx

Cluster inacessível

Recrie o kubeconfig, valide KUBECONFIG e confirme conectividade privada do Cloud Shell.

oci ce cluster create-kubeconfig --cluster-id <cluster_ocid> --file $HOME/.kube/config --region <region> --token-version 2.0.0 --kube-endpoint PRIVATE_ENDPOINT
export KUBECONFIG=$HOME/.kube/config
kubectl get nodes

Ghost não abre no browser

Valide hosts local, Ingress, Service e se o browser está usando o hostname correto.

configure hosts ghost.example.com
open http://ghost.example.com
curl http://ghost.example.com

Switchover incompleto

Revise o plano, DRPGs, replicação do Volume Group e status das etapas do FSDR.

show fsdr plan
show drpg status
show replication status
execute switchover-plan

🎙️ Interview Mode

perguntas técnicas

O que é um DR Protection Group?

É o agrupamento lógico do FSDR que representa os recursos protegidos de uma região, como OKE Cluster, Volume Group e configurações associadas ao plano de DR.

Qual a diferença entre Switchover e Failover?

Switchover é uma troca planejada e ordenada entre primário e standby. Failover é usado em desastre real, quando a região primária pode estar indisponível.

Por que usar Volume Group neste laboratório?

Porque o Ghost usa PVC baseado em Block Volume. O Volume Group permite tratar o volume persistente como recurso replicável e gerenciável pelo FSDR.

Por que existem dois buckets?

Cada DR Protection Group usa um bucket dedicado para logs operacionais na sua região, mantendo separação entre primário e standby.

Qual função do Ingress NGINX?

Ele atua como controlador de entrada e publica o Ghost Blog por meio de um OCI Load Balancer externo.

Por que configurar ghost.example.com no arquivo hosts?

O hostname facilita o teste da aplicação antes e depois do Switchover, permitindo trocar apenas o EXTERNAL-IP do Load Balancer.

O que validar antes de executar o Switchover?

Cluster primário acessível, Ghost respondendo, PVC Bound, Ingress com EXTERNAL-IP, DRPGs configurados e Volume Group replicando.

O que validar depois do Switchover?

Ghost ativo na região standby, novo Load Balancer respondendo, post de teste preservado e status do plano concluído com sucesso.

🏁 Conclusão

fechamento do hands-on

Com este hands-on, demonstramos como configurar e executar um plano de Switchover utilizando o OCI Full Stack Disaster Recovery (FSDR) integrado ao Oracle Kubernetes Engine (OKE).

Durante o processo, provisionamos os clusters primário e standby, configuramos buckets e volume groups, implantamos o aplicativo de demonstração Ghost Blog e validamos seu funcionamento antes e depois do switchover. Após a execução do plano, confirmamos que o tráfego passou a ser roteado para a região standby, incluindo o post de teste, o que comprova a replicação bem-sucedida dos dados e a continuidade da aplicação.

Essa abordagem mostra, na prática, como o FSDR possibilita uma recuperação de desastres orquestrada, confiável e alinhada às necessidades de alta disponibilidade e resiliência em ambientes críticos.

🧠 Quiz final do laboratório

0/5

Identificação do aluno

Informe nome e sobrenome para liberar as perguntas do quiz e usar o mesmo nome no certificado.

🔒 Quiz bloqueado. Exemplo válido: Renato Barros.

🏆 Certificado de conclusão

OCI FSDR + OKE

OCI
DR

OCI Cloud Experts Academy

Certificado corporativo de conclusão

OCI Full Stack Disaster Recovery with Oracle Kubernetes Engine

Issued to

Nome do aluno

Concluiu o treinamento interativo contemplando OKE, Ingress NGINX, Persistent Volume, Volume Group, DR Protection Groups, Switchover, validação do Ghost Blog, troubleshooting e entrevista técnica.

Date
-Score
Quiz pendenteHours
8 horasLevel
Enterprise Lab

OCI FSDR + OKE Training Center

Instructor / Technical Review