Observação:
- Este tutorial requer acesso ao Oracle Cloud. Para se inscrever em uma conta gratuita, consulte Conceitos Básicos do Oracle Cloud Infrastructure Free Tier.
- Ele usa valores de exemplo para credenciais, tenancy e compartimentos do Oracle Cloud Infrastructure. Ao concluir seu laboratório, substitua esses valores por valores específicos do seu ambiente de nuvem.
Automatize um Plano de Switchover e Failover para um Aplicativo de Demonstração Implantado no OCI Kubernetes Engine com o OCI Full Stack Disaster Recovery
Introdução
Este tutorial demonstra um caso de uso do Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) com um aplicativo de e-commerce de demonstração implantado em um cluster do Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE).
No momento em que este tutorial foi escrito, o OCI Full Stack DR anunciou disponibilidade limitada para o OKE. Em versão limitada, experimentamos o OCI Full Stack DR em aplicativos baseados no OKE, como MuShop, um aplicativo de demonstração baseado em microsserviços que usa vários outros serviços da Oracle Cloud Infrastructure (OCI) como um único aplicativo.
Usaremos uma abordagem stand-by quente: um modelo de recuperação de desastre (DR) em que alguns ou todos os componentes da aplicação são pré-implantados em uma região stand-by para permitir uma transição de DR mais rápida. Embora esse modelo envolva custos operacionais mais altos, ele fornece um RTO (Recovery Time Objective) menor.
O OCI Full Stack DR orquestra a transição de cálculos, bancos de dados e aplicações entre regiões da OCI de todo o mundo com um único clique. Os clientes podem automatizar as etapas necessárias para recuperar um ou mais sistemas de negócios sem reprojetar ou rearquitetar a infraestrutura, os bancos de dados ou as aplicações existentes sem precisar de servidores especializados de gerenciamento ou conversão.
Arquitetura da Implantação
Observação: A região principal é Sydney e a região de DR é Melbourne.
Objetivos
-
De acordo com a arquitetura, criaremos um grupo de proteção de DR (DRPG) chamado
Mushop-Syd
na região principal de Sydney. -
O DRPG principal contém uma coleção de diferentes recursos do OCI que compõem um aplicativo e que devem ser tratados como um grupo combinado ao executar operações de DR. Adicionamos o OKE e o Oracle Autonomous Database Serverless (Autonomous Database Serverless) ao DRPG principal. Este tutorial também fornece etapas para implantar o aplicativo MuShop e todos os outros recursos necessários para a implantação.
-
Um DRPG semelhante é criado na região de Melbourne em espera. O OKE e o Autonomous Database Serverless (no modo stand-by) são adicionados ao DRPG. Os balanceadores de carga não fazem parte do DRPG, mas serão executados de forma independente nos dois sites, conforme destacado na Arquitetura de Implantação.
-
Uma associação é formada entre os dois DRPGs.
-
No DRPG stand-by (Melbourne), um plano de DR é criado. Este plano representa um workflow de DR (uma sequência de etapas).
-
Execute um plano de DR. Um switchover é executado, o que planeja uma transição de serviços do DRPG principal para o DRPG stand-by. Os planos de switchover executam uma transição ordenada, fazendo shutdown da pilha de aplicativos na região principal e depois colocando-a na região stand-by. Portanto, um plano de switchover requer que os componentes da pilha de aplicativos e outros serviços do OCI necessários estejam disponíveis nas duas regiões.
Pré-requisitos
-
Privilégios de administrador ou configurar as políticas necessárias do OCI IAM (Oracle Cloud Infrastructure Identity and Access Management) para o OCI Full Stack DR. Para obter mais informações, consulte Configurando políticas de IAM (Identity and Access Management) para usar o OCI Full Stack DR e Políticas do OCI Full Stack DR.
-
Configuração do ambiente:
export COMPARTMENT_ID=ocid1.compartment.oc1.. export DB_NAME=fsdrdemoadb export DB_DISPLAY_NAME=fsdrdemoadb export DB_PASSWORD=<Your DB Password> export WALLET_PW=<Your DB Password> export DB_SERVICE_NAME=${DB_NAME}_tp export WALLET_ZIP=/tmp/Wallet_${DB_NAME}.zip export STANDBY_WALLET_ZIP=/tmp/Wallet_${DB_NAME}_Standby.zip export PRIMARY_REGION=ap-sydney-1 export STANDBY_REGION=ap-melbourne-1 export STANDBY_DB_NAME=${DB_NAME}_remote
Adicione as linhas a seguir a um arquivo chamado
env
e origine-o.source env
Observação:
- Para obter mais informações sobre os critérios de senha do Autonomous Database Serverless, consulte Sobre Senhas de Usuário no Autonomous Database.
- O nome sem Servidor do Autonomous Database só pode conter caracteres alfanuméricos.
- Substitua
DB_PASSWORD
eWALLET_PW
nas variáveis de ambiente acima.
Tarefa 1: Instalar e Configurar o Oracle Autonomous Database
-
Crie o Oracle Autonomous Database principal.
oci db autonomous-database create --compartment-id ${COMPARTMENT_ID} \ --db-name ${DB_NAME} --admin-password ${DB_PASSWORD} --db-version 19c \ --cpu-core-count 1 --data-storage-size-in-tbs 1 \ --display-name ${DB_DISPLAY_NAME} --region ${PRIMARY_REGION}
-
Extraia o OCID do Oracle Autonomous Database principal.
DB_ID=$(oci db autonomous-database list -c ${COMPARTMENT_ID} \ --region ${PRIMARY_REGION} --display-name $DB_NAME \ --query "data[?\"db-name\"=='${DB_NAME}'].id | [0]" --raw-output)
-
Crie o DR stand-by e ative o Oracle Data Guard entre regiões.
oci db autonomous-database create-adb-cross-region-data-guard-details \ --compartment-id ${COMPARTMENT_ID} --db-name ${DB_NAME} --source-id ${DB_ID} \ --cpu-core-count 1 --data-storage-size-in-tbs 1 \ --region ${FAILOVER_REGION} --db-version 19c
-
Faça download da wallet do banco de dados autônomo e extraia-a do Oracle Autonomous Database principal.
oci db autonomous-database generate-wallet --autonomous-database-id ${DB_ID}\ --password ${WALLET_PW} --file ${WALLET_ZIP} --region $PRIMARY_REGION
-
Descompacte a wallet no principal.
unzip ${WALLET_ZIP} -d /tmp/wallet_primary
Observação:
- Mantenha essa wallet acessível, pois precisaremos adicioná-la como segredo do OKE mais tarde.
- A wallet deve ser baixada separadamente para as regiões principal e stand-by porque as entradas de DNS
tnsnames.ora
são diferentes.
-
Extraia o OCID do Oracle Autonomous Database stand-by.
STANDBY_DB_ID=$(oci db autonomous-database list -c ${COMPARTMENT_ID} \ --region ${STANDBY_REGION} --display-name $STANDBY_DB_NAME \ --query "data[?\"db-name\"=='${DB_NAME}'].id | [0]" --raw-output)
-
Faça download da wallet do banco de dados autônomo e extraia-a do Oracle Autonomous Database stand-by.
oci db autonomous-database generate-wallet --autonomous-database-id \ ${STANDBY_DB_ID} --password ${WALLET_PW} \ --file ${STANDBY_WALLET_ZIP} --region $STANDBY_REGION
-
Descompacte a wallet stand-by.
unzip ${STANDBY_WALLET_ZIP} -d /tmp/wallet_standby
Tarefa 2: Criar um Cluster do OKE
Crie um cluster do OKE nos sites principal e de DR. Para obter mais informações, consulte Criar um Cluster com o Oracle Cloud Infrastructure Container Engine for Kubernetes.
Usamos a opção Criação Rápida para criar clusters com as seguintes informações:
- Nome do Cluster: Digite
primary-syd-oke-demo-cluster
(Sydney) estandby-mel-oke-demo-cluster
(Melbourne). - Ponto final da API do Kubernetes: Selecione Público.
- Tipo de Nó: Selecione Gerenciado.
- Selecione Trabalhadores Privados.
- Shape: Selecione VM Standard E3 Flex (4 OCPU, 64 GB de Memória).
- Selecione Oracle Linux 8.
Para acessar seu cluster, vá para a Console do OCI, navegue até Developer Service, Container & Artifacts e clique em Kubernetes Clusters (OKE).
Ou
Execute o comando a seguir para acessar seu cluster.
oci ce cluster create-kubeconfig --cluster-id <cluster-id> --file $HOME/.kube/config --region ap-sydney-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT
Tarefa 3: Configurar Segredos do Kubernetes no Site Principal
-
Crie um namespace.
kubectl create ns mushop
-
Adicione o segredo de senha de administrador do Oracle Autonomous Database.
kubectl create secret generic oadb-admin \ --namespace mushop \ --from-literal=oadb_admin_pw=${DB_PASSWORD}
-
Adicione o segredo de conexão do Oracle Autonomous Database.
kubectl create secret generic oadb-connection \ --namespace mushop \ --from-literal=oadb_wallet_pw=${WALLET_PW} \ --from-literal=oadb_service=${DB_SERVICE_NAME}
-
Adicione o segredo da wallet principal.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_primary
Tarefa 4: Configurar o Aplicativo MuShop
Observação: O aplicativo só é implantado na região principal (
ap-sydney-1
).
-
Clone o repositório.
git clone git@github.com:naikvenu/fsdr-demo.git
-
Vá para a pasta do gráfico.
cd fsdr-demo/helm-chart/
-
Atualize as dependências do gráfico.
helm dependency update ./setup
-
Instalar e configurar o gráfico.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Localize o endereço do controlador de entrada
EXTERNAL-IP
.PRIMARY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Instale o aplicativo no cluster do OKE.
helm upgrade --install -f ./mushop/values-dr.yaml \ fsdrmushop mushop -n mushop
-
Acesse o aplicativo MuShop principal usando o IP de entrada.
kubectl get svc mushop-utils-ingress-nginx-controller \ --namespace mushop-utilities
-
Para verificar o aplicativo, acesse
http://<primary-site-ingress-ip-address>
e certifique-se de ver todos os produtos do catálogo MuShop listados sem erros.
Tarefa 5: Configurar um Cluster do OKE no Site Stand-by
Observação: Como estamos usando uma abordagem em espera quente, precisamos criar um cluster do OKE e executar algumas coisas básicas, como o controlador de entrada. As etapas a seguir ajudarão você a fazer isso.
-
Para acessar seu cluster no site stand-by, vá para a Console do OCI, navegue até Developer Service, Container & Artifacts e clique em Kubernetes Clusters (OKE).
Ou
Execute o comando a seguir para acessar seu cluster no site stand-by.
oci ce cluster create-kubeconfig --cluster-id <cluster-id> --file $HOME/.kube/config --region ap-sydney-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT
-
Clone o repositório.
git clone git@github.com:naikvenu/fsdr-demo.git
Ou
git clone https://github.com/naikvenu/fsdr-demo
-
Vá para a pasta de gráficos.
cd fsdr-demo/helm-chart/
-
Atualize as dependências do gráfico.
helm dependency update ./setup
-
Instalar e configurar os gráficos. Isso é necessário para implantar um controlador de entrada (Balanceador de Carga do OCI) para acessar o aplicativo.
Observação: Esta etapa só implantará um controlador de entrada (OCI Load Balancer) e não o aplicativo completo.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Localize o endereço do controlador de entrada
EXTERNAL-IP
.STANDBY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Crie um namespace MuShop.
kubectl create namespace mushop
-
Crie um segredo para a wallet.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_standby
Observação: Estamos usando uma wallet stand-by.
Tarefa 6: Configurar Zonas do DNS (Opcional)
Na região principal, vá para a Console do OCI, navegue até Rede, Gerenciamento de DNS, Zonas e clique em Criar Zona.
Configuration:
The Zone type : Primary
‘A’ record: “mushop”
O nome da zona deve corresponder ao Nome do Domínio Comprado. Insira os servidores de nome a serem adicionados ao seu domínio.
O aplicativo estará acessível em https://mushop.<your-domain>.com
.
Tarefa 7: Criar Verificações de Integridade (Opcional)
São necessárias verificações de integridade para configurar políticas de orientação de tráfego de DNS do OCI.
Execute o comando a seguir para criar verificações de integridade.
oci health-checks http-monitor create --compartment-id ${COMPARTMENT_ID} --display-name fsdr-test --interval-in-seconds 30 --targets '[“${PRIMARY_EXTERNAL_IP}”]' --protocol http --path "/" --port 80
Ou
Vá para a Console do OCI, navegue até Observabilidade e Gerenciamento, Monitoramento, Verificações de Integridade, clique em Criar Verificação de Integridade e digite as informações a seguir.
- Nome: Informe
FSDR-APP-HEALTHCHECK
. - Destinos: Informe os IPs dos balanceadores de carga principal e stand-by.
- Protocolo: Selecione http.
- Porta: Digite 80.
- Caminho de Destino: Digite
/
. - Método: Selecione GET.
- Timeout: Digite 30.
- Intervalo: Informe 30 segundos.
Tarefa 8: Configurar a Política de Orientação de Gerenciamento de Tráfego (Opcional)
Vá para a Console do OCI, navegue até Rede, Gerenciamento de DNS, Políticas de Orientação de Gerenciamento de Tráfego, clique em Criar Política de Orientação de Gerenciamento de Tráfego e digite as informações a seguir.
- Nome: Digite
FSDR-POLICY
. - TTL: Digite 60 segundos.
- Pool 1:
- Nome: Digite
Primary
. - Tipo: Selecione A.
- Rdata: Informe o IP do balanceador de carga principal.
- Nome: Digite
- Pool 2:
- Nome: Digite
Standby
. - Tipo: Selecione A.
- Rdata: Informe o IP do balanceador de carga stand-by.
- Nome: Digite
- Selecionar Prioridade do Pool:
- Pool1
- Pool2
- Anexe a verificação de integridade criada na Tarefa 7.
Tarefa 9: Configurar o OCI Full Stack DR
-
Crie um DRPG em ambas as regiões. Vá para a Console do OCI, navegue até Migração e Recuperação de Desastres e clique em grupos de proteção de DR. Por exemplo,
primary-drpg-sydney
estandby-drpg-melbourne
. -
Associe os DRPGs. Vá para a Console do OCI, navegue até Migração e Recuperação de Desastres, grupos de proteção de DR e clique em Associar.
-
Adicione recursos ao DRPG (região Sydney). Vá para a Console do OCI, navegue até Migração e Recuperação de Desastres, grupos de proteção de DR, Membros e clique em Adicionar Membro.
-
Adicione o cluster do OKE e o Oracle Autonomous Database.
-
Adicione recursos ao DRPG (região de Melbourne) - cluster do OKE e ao Oracle Autonomous Database.
-
Crie um plano de DR na região stand-by (Melbourne). Vá para a Console do OCI, navegue até Migração e Recuperação de Desastres, grupos de proteção de DR, Planos e clique em Criar Plano.
A imagem a seguir mostra um plano de DR que orquestra a recuperação de toda uma pilha de aplicativos, que pode incluir outros serviços junto com o OKE.
Como você pode ver na imagem, temos etapas incorporadas para o OKE. O serviço OCI Full Stack DR executa uma ferramenta de backup desenvolvida internamente. Essa ferramenta usará periodicamente os backups do cluster de Implantações, Conjuntos de Réplicas, Pods, CronJobs, Conjuntos de Daemon etc.
Os backups serão armazenados no bucket do OCI Object Storage que especificamos na propriedade do membro.
-
OKE - Interromper Backup e Limpeza (Principal): Isso interrompe os backups e encerra todos os recursos mencionados no cluster do OKE.
-
OKE - Restaurar (Stand-by): Usando o backup, ele restaura o backup mais recente no cluster do DR OKE, para que você tenha todos os recursos criados no cluster do OKE.
-
OKE - Programar Backup Reverso (Stand-by): Defina o backup reverso para o plano de switchback.
Se você estiver usando PersistentVolume (PV) e PersistentVolumeClaim (PVC), será necessário configurar grupos de volumes entre regiões (armazenamento em blocos) e replicação FSS entre regiões (armazenamento de arquivos) e adicioná-los como membros no DRPG. Isso criará grupos de planos adicionais, como o que vimos para o OKE e o Oracle Autonomous Database.
-
-
Executar um switchover. Esta etapa deve ser executada no site stand-by (Melbourne).
Vá para a Console do OCI, navegue até Migração e Recuperação de Desastres, grupos de proteção de DR e clique em Executar Plano de DR.
Tarefa 10: Testar e Validar o Aplicativo
Acesse o aplicativo na região stand-by e garanta que tudo funcione. O aplicativo deve estar acessível em https://mushop.domain.com
ou usar o endereço http://standbyloadbalancerIP.com
.
Verifique se você pode acessar os itens do catálogo, indicando que o banco de dados stand-by está totalmente operacional.
Observação: Neste tutorial, excluímos etapas para incluir certificados SSL no OCI Load Balancer e usar o OCI Web Application Firewall. Esses dois componentes podem ser adicionados aos ambientes de produção.
Próximas Etapas
Você viu como um aplicativo de comércio eletrônico baseado em microsserviços, implantado no OCI Kubernetes Engine, pode ser configurado com o serviço OCI Full Stack DR para permitir a recuperação de desastres em um modo de espera quente. Mostramos como esse aplicativo pode falhar perfeitamente sem qualquer intervenção manual. Para obter mais informações, consulte a documentação do OCI Full Stack DR na seção Links Relacionados.
Links Relacionados
Confirmações
-
Autor - Venugopal Naik (Arquiteto de Nuvem Principal)
-
Contribuintes - Raphael Teixeira (Membro Principal da Equipe Técnica do FSDR), Suraj Ramesh (Gerente de Produtos Principal do MAA)
Mais Recursos de Aprendizagem
Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal Oracle Learning YouTube. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.
Para obter a documentação do produto, visite o Oracle Help Center.
Automate a Switchover and Failover Plan for a Demo Application Deployed on OCI Kubernetes Engine with OCI Full Stack Disaster Recovery
G23618-01
December 2024