Tutorial: Migrar o Oracle WebLogic Server para o Serviço Kubernetes do Azure (AKS) com redundância geográfica

Artigo
04/29/2024

Este tutorial mostra uma maneira direta e eficaz de implementar uma estratégia de continuidade de negócios e recuperação de desastres (DR) para Java usando o Oracle WebLogic Server (WLS) no Serviço Kubernetes do Azure (AKS). A solução ilustra como fazer backup e restaurar uma carga de trabalho WLS usando um aplicativo Jakarta EE simples orientado por banco de dados em execução no AKS. A redundância geográfica é um tema complexo, com muitas soluções possíveis. A melhor solução depende dos seus requisitos exclusivos. Para outras maneiras de implementar redundância geográfica, consulte os recursos no final deste artigo.

Neste tutorial, irá aprender a:

Use as práticas recomendadas otimizadas do Azure para obter alta disponibilidade e recuperação de desastres (HA/DR).
Configure um grupo de failover do Banco de Dados SQL do Microsoft Azure em regiões emparelhadas.
Instale e configure clusters WLS primários no AKS.
Configure a redundância geográfica usando o Backup do Azure.
Restaure um cluster WLS em uma região secundária.
Configure um Gerenciador de Tráfego do Azure.
Failover de teste.

O diagrama a seguir ilustra a arquitetura que você cria:

O Azure Traffic Manager verifica a integridade de suas regiões e roteia o tráfego de acordo com a camada de aplicativo. A região primária tem uma implantação completa do cluster WLS. Somente a região primária está atendendo ativamente às solicitações de rede dos usuários. A região secundária restaura o cluster WLS a partir de backups da região primária se houver um desastre ou evento de DR declarado. A região secundária é ativada para receber tráfego somente quando a região primária sofre uma interrupção do serviço.

O Azure Traffic Manager usa o recurso de verificação de integridade do Gateway de Aplicativo do Azure e o Operador WebLogic Kubernetes (WKO) para implementar esse roteamento condicional. O WKO integra-se profundamente com as verificações de integridade do AKS, permitindo que o Azure Traffic Manager tenha um alto nível de conhecimento da integridade da sua carga de trabalho Java. O cluster WLS primário está em execução e o cluster secundário é desligado.

O RTO (objetivo de tempo de recuperação de failover geográfico) da camada de aplicativo depende do tempo para iniciar o AKS e executar o cluster WLS secundário, que normalmente é inferior a uma hora. Os dados do aplicativo são persistentes e replicados no grupo de failover do Banco de Dados SQL do Azure, com um RTO de minutos ou horas e um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de minutos ou horas. Nessa arquitetura, o backup do Azure tem apenas um backup padrão do Vault para a configuração WLS todos os dias. Para obter mais informações, consulte O que é o backup do Serviço Kubernetes do Azure (AKS)?

A camada de banco de dados consiste em um grupo de failover do Banco de Dados SQL do Azure com um servidor primário e um servidor secundário. O servidor primário está no modo de leitura/gravação ativo e conectado ao cluster WLS primário. O servidor secundário está no modo pronto passivo e conectado ao cluster WLS secundário. Um failover geográfico alterna todos os bancos de dados secundários do grupo para a função principal. Para RPO e RTO de failover geográfico do Banco de Dados SQL do Azure, consulte Visão geral da continuidade de negócios.

Este artigo foi escrito com o serviço Banco de Dados SQL do Azure porque o artigo depende dos recursos de alta disponibilidade (HA) desse serviço. Outras opções de banco de dados são possíveis, mas você deve considerar os recursos de HA de qualquer banco de dados escolhido. Para obter mais informações, incluindo informações sobre como otimizar a configuração de fontes de dados para replicação, consulte Configurando fontes de dados para implantação ativa-passiva do Oracle Fusion Middleware.

Este artigo usa o Backup do Azure para proteger o AKS. Para obter informações sobre disponibilidade de região, cenários com suporte e limitações, consulte Matriz de suporte de backup do Serviço Kubernetes do Azure. Atualmente, o Backup do Azure dá suporte a backups e restaurações de camada do Vault entre regiões, que estão disponíveis em visualização pública. Para obter mais informações, consulte Habilitar backups de camada do Vault para AKS e restaurar entre regiões usando o Backup do Azure.

Nota

Neste artigo, você deve criar frequentemente identificadores exclusivos para vários recursos. Este artigo usa a convenção de <initials><sequence-number> como um prefixo. Por exemplo, se o seu nome for Emily Juanita Bernal, um identificador exclusivo será ejb01. Para maior desambiguidade, você pode acrescentar a data de hoje no MMDD formato, como ejb010307.

Pré-requisitos

Uma subscrição do Azure. Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar.
Verifique se você tem a Owner função ou as Contributor funções e User Access Administrator na assinatura. Você pode verificar a atribuição seguindo as etapas em Listar atribuições de função do Azure usando o portal do Azure.
Prepare uma máquina local com Windows, Linux ou macOS instalado.
Para executar comandos da CLI do Azure, instale a CLI do Azure, versão 2.54.0 ou posterior.
Instale e configure o kubectl.
Instale e configure o Git.
Instale uma implementação Java SE, versão 17 ou posterior - por exemplo, a compilação da Microsoft do OpenJDK.
Instale o Maven, versão 3.9.3 ou posterior.
Ter as credenciais para uma conta de logon único (SSO) Oracle. Para criar uma, consulte Criar sua conta Oracle.
Use as seguintes etapas para aceitar os termos de licença para WLS:
1. Visite o Oracle Container Registry e faça login.
2. Se você tiver um direito de suporte, selecione Middleware e, em seguida, pesquise e selecione weblogic_cpu.
3. Se você não tiver um direito de suporte da Oracle, selecione Middleware e, em seguida, pesquise e selecione weblogic.
4. Aceite o contrato de licença.
Executar WLS no AKS requer uma compreensão dos domínios WLS. Para obter mais informações sobre domínios WLS, consulte a seção Decidir se deseja usar a oferta pré-criada do Azure Marketplace de Migrar aplicativos do Servidor WebLogic para o Serviço Kubernetes do Azure. Este artigo pressupõe que você esteja executando WLS no AKS usando o modelo no tipo de origem inicial do domínio da imagem , com logs de transações e armazenamentos em um banco de dados externo e sem armazenamento externo.

Configurar um grupo de failover do Banco de Dados SQL do Azure em regiões emparelhadas

Nesta seção, você cria um grupo de failover do Banco de Dados SQL do Azure em regiões emparelhadas para uso com seus clusters WLS e aplicativo. Em uma seção posterior, você configura o WLS para armazenar seus dados de sessão e dados de log de transações (TLOG) para esse banco de dados. Essa prática é consistente com a Maximum Availability Architecture (MAA) da Oracle. Esta orientação fornece uma adaptação do Azure para MAA. Para obter mais informações sobre MAA, consulte Oracle Maximum Availability Architecture.

Primeiro, crie o Banco de Dados SQL do Azure primário seguindo as etapas do portal do Azure em Guia de início rápido: criar um único banco de dados - Banco de Dados SQL do Azure. Siga as etapas até, mas não incluindo, a seção "Limpar recursos". Use as seguintes instruções ao percorrer o artigo e, em seguida, retorne a este artigo depois de criar e configurar o Banco de Dados SQL do Azure:

Quando chegar à seção Criar um único banco de dados, use as seguintes etapas:
1. Na etapa 4 para criar um novo grupo de recursos, salve de lado o valor do nome do grupo de recursos - por exemplo, myResourceGroup.
2. Na etapa 5 para nome do banco de dados, salve de lado o valor Nome do banco de dados - por exemplo, mySampleDatabase.
3. Na etapa 6 para criar o servidor, use as seguintes etapas:
  1. Salve de lado o nome exclusivo do servidor - por exemplo, sqlserverprimary-ejb120623.
  2. Em Local, selecione (EUA) Leste dos EUA.
  3. Em Método de autenticação, selecione Usar autenticação SQL.
  4. Salve de lado o valor de login do administrador do servidor - por exemplo, azureuser.
  5. Salve de lado o valor da senha .
4. Na etapa 8, para Ambiente de carga de trabalho, selecione Desenvolvimento. Observe a descrição e considere outras opções para sua carga de trabalho.
5. Na etapa 11, para Redundância de armazenamento de backup, selecione Armazenamento de backup com redundância local. Considere outras opções para seus backups. Para obter mais informações, consulte a seção Redundância de armazenamento de backup de Backups automatizados no Banco de Dados SQL do Azure.
6. Na etapa 14, na configuração de regras de firewall, para Permitir que os serviços e recursos do Azure acessem este servidor, selecione Sim.
Quando chegar à seção Consultar o banco de dados, use as seguintes etapas:
1. Na etapa 3, insira as informações de entrada do administrador do servidor de autenticação SQL para entrar.
  
  Nota
  
  Se o início de sessão falhar com uma mensagem de erro semelhante a Cliente com endereço IP 'xx.xx.xx.xx' não tem permissão para aceder ao servidor, selecione Allowlist IP xx.xx.xx.xx no servidor <your-sqlserver-name> no final da mensagem de erro. Aguarde até que as regras de firewall do servidor concluam a atualização e selecione OK novamente.
2. Depois de executar a consulta de exemplo na etapa 5, limpe o editor e crie tabelas.

Para criar o esquema, insira as seguintes consultas:

Para criar o esquema para o TLOG, insira a seguinte consulta:

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp4_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp5_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

Após uma execução bem-sucedida, você verá a mensagem Query succeeded: Affected rows: 0.

Essas tabelas de banco de dados são usadas para armazenar log de transações (TLOG) e dados de sessão para seus clusters WLS e aplicativo. Para obter mais informações, consulte Usando um armazenamento TLOG JDBC e Usando um banco de dados para armazenamento persistente (persistência JDBC).

Para criar o esquema para o aplicativo de exemplo, insira a seguinte consulta:

CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));

Após uma execução bem-sucedida, você verá a mensagem Query succeeded: Affected rows: 0.

Agora você terminou o artigo "Guia de início rápido: criar um único banco de dados - Banco de dados SQL do Azure".

Em seguida, crie um grupo de failover do Banco de Dados SQL do Azure seguindo as etapas do portal do Azure em Configurar um grupo de failover para o Banco de Dados SQL do Azure. Você só precisa das seguintes seções: Criar grupo de failover e Testar failover planejado. Use as etapas a seguir ao longo do artigo e retorne a este artigo depois de criar e configurar o grupo de failover do Banco de Dados SQL do Azure:

Quando chegar à seção Criar grupo de failover, use as seguintes etapas:
1. Na etapa 5 para criar o grupo de failover, selecione a opção para criar um novo servidor secundário e use as seguintes etapas:
  1. Insira e salve de lado o nome do grupo de failover - por exemplo, failovergroupname-ejb120623.
  2. Digite e salve de lado o nome exclusivo do servidor - por exemplo, sqlserversecondary-ejb120623.
  3. Introduza o mesmo administrador do servidor e palavra-passe que o servidor principal.
  4. Em Local, selecione uma região diferente daquela usada para o banco de dados primário.
  5. Certifique-se de que a opção Permitir que os serviços do Azure acedam ao servidor está selecionada.
2. Na etapa 5 para configurar os bancos de dados dentro do grupo, selecione o banco de dados que você criou no servidor primário - por exemplo, mySampleDatabase.
Depois de concluir todas as etapas na seção Testar failover planejado, mantenha a página do grupo de failover aberta e use-a para o teste de failover dos clusters WLS mais tarde.

Obtenha a cadeia de conexão JDBC e o nome de usuário do administrador do banco de dados para o grupo de failover

As etapas a seguir direcionam você para obter a cadeia de conexão JDBC e o nome de usuário do banco de dados para o banco de dados dentro do grupo de failover. Esses valores são diferentes dos valores correspondentes para o banco de dados primário.

No portal do Azure, localize o grupo de recursos no qual você implantou o banco de dados primário.
Na lista de recursos, selecione o banco de dados primário com o tipo banco de dados SQL.
Em Definições, selecione Cadeias de ligação.
Selecione JDBC.
Na área de texto em JDBC (autenticação SQL), selecione o ícone de cópia para colocar o valor da cadeia de conexão JDBC na área de transferência.
Em um editor de texto, cole o valor. Você editá-lo em outra etapa.
Retorne ao grupo de recursos.
Selecione o recurso do tipo SQL Server que contém o banco de dados que você acabou de examinar nas etapas anteriores.
Em Gestão de dados, selecione Grupos de ativação pós-falha.
Na tabela no meio da página, selecione o grupo de failover.
Na área de texto em Ponto de extremidade do ouvinte de leitura/gravação, selecione o ícone de cópia para colocar o valor da cadeia de conexão JDBC na área de transferência.

Cole o valor em uma nova linha no editor de texto. Seu editor de texto agora deve ter linhas semelhantes ao exemplo a seguir:

jdbc:sqlserver://ejb010307db.database.windows.net:1433;database=ejb010307db;user=azureuser@ejb010307db;password={your_password_here};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
ejb010307failover.database.windows.net

Crie uma nova linha usando as seguintes modificações:
1. Copie toda a primeira linha.
2. Altere a parte do nome do host da URL para usar o nome do host da linha de ponto de extremidade do ouvinte de leitura/gravação.
3. Remova tudo depois do name=value par para database. Em outras palavras, remova tudo, incluindo e depois do imediatamente após database=ejb010307db.;
  
  Quando terminar, a cadeia de caracteres deverá ser semelhante ao exemplo a seguir:
```
jdbc:sqlserver://ejb010307failover.database.windows.net:1433;database=ejb010307db
```
  Esse valor é a cadeia de conexão JDBC.
No mesmo editor de texto, derive o nome de usuário do banco de dados obtendo o valor do parâmetro da cadeia de conexão JDBC original e substituindo o nome do user banco de dados pela primeira parte da linha de ponto de extremidade do ouvinte de leitura/gravação. Continuando com o exemplo anterior, o valor seria azureuser@ejb010307failover. Esse valor é o nome de usuário do administrador do banco de dados.

Instalar e configurar os clusters WLS primários no AKS

Nesta seção, você cria um cluster WLS no AKS usando a oferta Oracle WebLogic Server on AKS . O cluster no Leste dos EUA é o principal e está configurado como o cluster ativo.

Nota

Você pode encontrar mais informações sobre o Oracle WebLogic Server na oferta AKS nos seguintes artigos:

Preparar um aplicativo de exemplo

Nesta seção, você cria e empacota um aplicativo CRUD Java/JakartaEE de exemplo que posteriormente implanta e executa em clusters WLS para teste de failover.

O aplicativo usa a persistência de sessão JDBC do WebLogic Server para armazenar dados de sessão HTTP. A fonte jdbc/WebLogicCafeDB de dados armazena os dados da sessão para habilitar o failover e o balanceamento de carga em um cluster de WebLogic Servers. Ele configura um esquema de persistência para persistir dados coffee de aplicativos na mesma fonte jdbc/WebLogicCafeDBde dados.

Use as seguintes etapas para criar e empacotar o exemplo:

Use os seguintes comandos para clonar o repositório de exemplo e verificar a tag correspondente a este artigo:
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Se vir uma mensagem sobre Detached HEADo , é seguro ignorá-lo.
Use os seguintes comandos para navegar até o diretório de exemplo e, em seguida, compilar e empacotar o exemplo:
```
cd weblogic-cafe
mvn clean package
```

Quando o pacote é gerado com sucesso, você pode encontrá-lo em parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war.< Se não vir o pacote, tem de resolver o problema antes de continuar.

Criar uma conta de armazenamento e um contêiner de armazenamento para armazenar o aplicativo de exemplo

Use as etapas a seguir para criar uma conta de armazenamento e um contêiner. Alguns destes passos direcionam-no para outros guias. Depois de concluir as etapas, você pode carregar um aplicativo de exemplo para implantar no WLS.

Inicie sessão no portal do Azure.
Crie uma conta de armazenamento seguindo as etapas em Criar uma conta de armazenamento. Use as seguintes especializações para os valores no artigo:
- Crie um novo grupo de recursos para a conta de armazenamento.
- Em Região, selecione Leste dos EUA.
- Para Nome da conta de armazenamento, use o mesmo valor que o nome do grupo de recursos.
- Em Desempenho, selecione Standard.
- Em Redundância, selecione Armazenamento com redundância local (LRS).
- As guias restantes não precisam de especializações.
Prossiga para validar e criar a conta e, em seguida, volte a este artigo.
Crie um contêiner de armazenamento na conta seguindo as etapas na seção Criar um contêiner do Guia de início rápido: carregar, baixar e listar blobs com o portal do Azure.
Usando o mesmo artigo, carregue o pacote azure-café/weblogic-café/target/weblogic-café.war que você criou anteriormente, seguindo as etapas na seção Carregar um blob de bloco. Em seguida, volte a este artigo.

Implantar WLS no AKS

Use as seguintes etapas para implantar o WLS no AKS:

Abra a oferta Oracle WebLogic Server on AKS no seu navegador e selecione Criar. Você deve ver o painel Noções básicas da oferta.
Use as seguintes etapas para preencher o painel Noções básicas :
1. Verifique se o valor mostrado para Assinatura é o mesmo que tem as funções listadas na seção de pré-requisitos.
2. Você deve implantar a oferta em um grupo de recursos vazio. No campo Grupo de recursos, selecione Criar novo e preencha um valor exclusivo para o grupo de recursos - por exemplo, wlsaks-eastus-20240109.
3. Em Detalhes da instância, para Região, selecione Leste dos EUA.
4. Em Credenciais WebLogic, forneça uma senha para criptografia WebLogic Administrator e WebLogic Model, respectivamente. Guarde de lado o nome de utilizador e a palavra-passe do WebLogic Administrator.
5. Em Configuração básica opcional, para Aceitar padrões para configuração opcional?, selecione Não. A configuração opcional é exibida.
6. Para Prefixo de nome para Servidor gerenciado, preencha msp. Configurar a tabela WLS TLOG com prefixo TLOG_${serverName}_ mais tarde. Este artigo cria a tabela TLOG com o nome TLOG_msp${index}_WLStore. Se você quiser um prefixo de nome de servidor gerenciado diferente, verifique se o valor corresponde às Convenções de Nomenclatura de Tabela do Microsoft SQL Server e aos nomes de tabela reais.
7. Deixe os padrões para os outros campos.
Selecione Avançar para ir para o painel AKS .
Em Seleção de imagem, forneça as seguintes informações:
- Para Nome de usuário para autenticação Oracle Single Sign-On, preencha seu nome de usuário Oracle SSO a partir das pré-condições.
- Para Senha para autenticação Oracle Single Sign-On, preencha suas credenciais Oracle SSO a partir das pré-condições.
Em Aplicativo, use as seguintes etapas:
1. Na seção Aplicativo, ao lado de Implantar um aplicativo?, selecione Sim.
2. Ao lado de Pacote do aplicativo (.war,.ear,.jar), selecione Procurar.
3. Comece a digitar o nome da conta de armazenamento na seção anterior. Quando a conta de armazenamento desejada aparecer, selecione-a.
4. Selecione o contêiner de armazenamento na seção anterior.
5. Marque a caixa de seleção ao lado de weblogic-café.war, que você carregou na seção anterior. Selecione Selecionar.
6. Deixe os padrões para os outros campos.
Selecione Seguinte.
Deixe os padrões no painel Configuração TLS/SSL e selecione Avançar para ir para o painel Balanceamento de Carga.
No painel Balanceamento de Carga, ao lado de Criar entrada para o Console de Administração. Certifique-se de que nenhum aplicativo com o caminho /console*, ele causará conflito com o caminho do Console de Administração, selecione Sim.
Deixe os padrões para os outros campos e selecione Avançar
Deixe os valores padrão no painel DNS e selecione Avançar para ir para o painel Banco de dados.
Insira os seguintes valores no painel Banco de dados :
- Em Conectar ao banco de dados?, selecione Sim.
- Em Escolher tipo de banco de dados, selecione Microsoft SQL Server (Suporta conexão sem senha) .
- Para JNDI Name, digite jdbc/WebLogicCafeDB.
- Para DataSource Connection String, cole o valor salvo para a cadeia de conexão JDBC na seção Obter a cadeia de conexão JDBC e o nome de usuário administrador do banco de dados para o grupo de failover.
- Em Protocolo de transação global, selecione Nenhum.
- Para Nome de usuário do banco de dados, cole o valor salvo para o nome de usuário do administrador do banco de dados na seção Obter a cadeia de conexão JDBC e o nome de usuário do administrador do banco de dados para o grupo de failover.
- Introduza a palavra-passe de início de sessão do administrador do servidor de base de dados que guardou anteriormente para a Palavra-passe da Base de Dados. Digite o mesmo valor para Confirmar senha.
- Deixe os padrões para os outros campos.
Selecione Rever + criar.
Aguarde até que a Execução da validação final... seja concluída com êxito e, em seguida, selecione Criar. Depois de um tempo, você verá a página Implantação onde a Implantação está em andamento é exibida.

Nota

Se vir algum problema durante a execução da validação final..., corrija-o e tente novamente.

Dependendo das condições da rede e de outras atividades na região selecionada, a implantação pode levar até 70 minutos para ser concluída. Depois disso, você verá o texto Sua implantação foi concluída exibido na página de implantação.

Configurar o armazenamento de dados TLOG

Nesta seção, você configura o armazenamento de dados TLOG substituindo o modelo de imagem WLS por um ConfigMaparquivo . Para obter mais informações sobre o ConfigMap, consulte WebLogic Deploy Tooling model ConfigMap.

Esta seção requer um terminal Bash com a CLI do Azure e o kubectl instalados. Use as seguintes etapas para derivar o YAML necessário e configurar o armazenamento de dados TLOG:

Use as seguintes etapas para se conectar ao cluster AKS:
1. Abra o portal do Azure e vá para o grupo de recursos que você provisionou na seção Implantar WLS no AKS .
2. Selecione o cluster AKS na lista de recursos e, em seguida, selecione Conectar para se conectar ao cluster AKS.
3. Selecione CLI do Azure e siga as etapas para se conectar ao cluster AKS em seu terminal local.
Use as seguintes etapas para obter a topology: entrada do modelo de imagem WLS YAML:
1. Abra o portal do Azure e vá para o grupo de recursos que você provisionou na seção Implantar WLS no AKS .
2. Selecione Configurações>de implantações. Selecione a primeira implantação cujo nome começa com oracle.20210620-wls-on-aks.
3. Selecione Saídas. Copie o valor shellCmdtoOutputWlsImageModelYaml para a área de transferência. O valor é um comando shell que decodifica a cadeia de caracteres base64 do arquivo de modelo e salva o conteúdo em um arquivo chamado model.yaml.
4. Cole o valor em seu terminal Bash e execute o comando para produzir o arquivo model.yaml .
5. Edite o arquivo para remover todo o conteúdo, exceto a entrada de nível topology: superior. Não deve haver entradas de nível superior em seu arquivo, exceto para topology:.
6. Guarde o ficheiro.
Use as seguintes etapas para obter o nome e o ConfigMap nome do namespace do modelo de domínio WLS YAML:
1. Abra o portal do Azure e vá para o grupo de recursos que foi provisionado na seção Implantar WLS no AKS .
2. Selecione Configurações>de implantações. Selecione a primeira implantação cujo nome começa com oracle.20210620-wls-on-aks.
3. Selecione Saídas. Copie o valor de shellCmdtoOutputWlsDomainYaml para a área de transferência. O valor é um comando shell para decodificar a cadeia de caracteres base64 do arquivo de modelo e salvar o conteúdo em model.yaml.
4. Cole o valor no seu terminal e obterá um ficheiro denominado domain.yaml.
5. Procure os domain.yaml seguintes valores.
  - spec.configuration.model.configMap. Se você aceitou os padrões, esse valor é sample-domain1-wdt-config-map.
  - metadata.namespace. Se você aceitou os padrões, esse valor é sample-domain1-ns.
  Para sua conveniência, você pode usar o seguinte comando para salvar esses valores como variáveis de shell:
```
export CONFIG_MAP_NAME=sample-domain1-wdt-config-map
export WLS_NS=sample-domain1-ns
```

Use o seguinte comando para obter o ConfigMap YAML:

kubectl get configmap ${CONFIG_MAP_NAME} -n ${WLS_NS} -o yaml > configMap.yaml

Use as seguintes etapas para criar o arquivo tlog-db-model.yaml :
1. Em um editor de texto, crie um arquivo vazio chamado tlog-db-model.yaml.
2. Insira o conteúdo do seu model.yaml, adicione uma linha em branco e, em seguida, insira o conteúdo do seu arquivo configMap.yaml.

No arquivo tlog-db-model.yaml , localize a linha que termina com ListenPort: 8001. Anexe este texto na linha a seguir, tomando extremo cuidado que TransactionLogJDBCStore está exatamente abaixo ListenPort e as linhas restantes no trecho a seguir são recuadas por duas, como mostrado no exemplo a seguir:

TransactionLogJDBCStore:
  Enabled: true
  DataSource: jdbc/WebLogicCafeDB
  PrefixName: TLOG_${serverName}_

O tlog-db-model.yaml concluído deve parecer muito próximo do exemplo a seguir:

topology:
  Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
  ProductionModeEnabled: true
  AdminServerName: "admin-server"
  Cluster:
    "cluster-1":
      DynamicServers:
        ServerTemplate: "cluster-1-template"
        ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
        DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MinDynamicClusterSize: "0"
        CalculatedListenPorts: false
  Server:
    "admin-server":
      ListenPort: 7001
  ServerTemplate:
    "cluster-1-template":
      Cluster: "cluster-1"
      ListenPort: 8001
      TransactionLogJDBCStore:
        Enabled: true
        DataSource: jdbc/WebLogicCafeDB
        PrefixName: TLOG_${serverName}_
  SecurityConfiguration:
    NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
    NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"

resources:
  JDBCSystemResource:
    jdbc/WebLogicCafeDB:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/WebLogicCafeDB
          ]
          GlobalTransactionsProtocol: None
        JDBCDriverParams:
          DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
          URL: '@@SECRET:ds-secret-sqlserver-1709938597:url@@'
          PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1709938597:password@@'
          Properties:
            user:
              Value: '@@SECRET:ds-secret-sqlserver-1709938597:user@@'
        JDBCConnectionPoolParams:
            TestTableName: SQL SELECT 1
            TestConnectionsOnReserve: true

Substitua ConfigMapo modelo WLS pelo . Para substituir o modelo WLS, substitua o modelo existente ConfigMap pelo novo. Para obter mais informações, consulte Atualizando um modelo existente na documentação do Oracle. Execute os seguintes comandos para recriar o ConfigMap:

export CM_NAME_FOR_MODEL=sample-domain1-wdt-config-map
kubectl -n sample-domain1-ns delete configmap ${CM_NAME_FOR_MODEL}

# replace path of tlog-db-model.yaml
kubectl -n sample-domain1-ns create configmap ${CM_NAME_FOR_MODEL} \
  --from-file=tlog-db-model.yaml
kubectl -n sample-domain1-ns label configmap ${CM_NAME_FOR_MODEL} \
  weblogic.domainUID=sample-domain1

Reinicie o cluster WLS usando os seguintes comandos. Você precisa causar uma atualização contínua para fazer o novo modelo funcionar.

export RESTART_VERSION=$(kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}')
# increase restart version
export RESTART_VERSION=$((RESTART_VERSION + 1))

kubectl -n sample-domain1-ns patch domain sample-domain1 \
    --type=json \
    '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "'${RESTART_VERSION}'" }]'

Certifique-se de que os pods WLS estão em execução antes de seguir em frente. Você pode usar o seguinte comando para observar o status dos pods:

kubectl get pod -n sample-domain1-ns -w

Nota

Neste artigo, os modelos WLS são incluídos na imagem do contêiner do aplicativo, que foi criada pela oferta WLS on AKS. O TLOG é configurado substituindo o modelo existente pelo WDT ConfigMap que contém o arquivo de modelo e usa o campo CRD configuration.model.configMap do domínio para fazer referência ao mapa. Em cenários de produção, as imagens auxiliares são a melhor abordagem recomendada para incluir Model in Image model files, application archive files e a instalação do WebLogic Deploy Tooling em seus pods. Esse recurso elimina a necessidade de fornecer esses arquivos na imagem especificada em domain.spec.image.

Configurar redundância geográfica usando o Backup do Azure

Nesta seção, você usa o Backup do Azure para fazer backup de clusters AKS usando a extensão Backup, que deve ser instalada no cluster.

Use as seguintes etapas para configurar a redundância geográfica:

Crie um novo contêiner de armazenamento para a extensão de backup AKS na conta de armazenamento que você criou na seção Criar uma conta de armazenamento e contêiner de armazenamento para armazenar o aplicativo de exemplo.

Use os seguintes comandos para instalar a extensão de backup AKS e habilitar os drivers CSI e instantâneos para seu cluster:

#replace with your resource group name.
export RG_NAME=wlsaks-eastus-20240109
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv)

az aks update \
    --resource-group ${RG_NAME} \
    --name ${AKS_NAME} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

Demora cerca de 5 minutos para habilitar os motoristas. Certifique-se de que os comandos são concluídos sem erros antes de prosseguir.

Abra o grupo de recursos que implantou o AKS. Selecione o cluster AKS na lista de recursos.
Na página inicial do AKS, selecione Configurações>Backup>da Extensão de Instalação.
Na página Instalar a extensão AKS Backup, selecione Avançar. Selecione a conta de armazenamento e o contêiner de Blob criados nas etapas anteriores. Selecione Avançar e, em seguida, Criar. Demora cerca de cinco minutos a concluir esta etapa.

Abra o portal do Azure, na barra de pesquisa na parte superior, procure por cofres de backup. Você deve vê-lo listado em Serviços. Selecione-a.
Para habilitar o Backup do AKS, siga as etapas em Fazer backup do Serviço Kubernetes do Azure usando o Backup do Azure até, mas não incluindo, a seção "Usar ganchos durante o backup do AKS". Faça os ajustes indicados nas etapas a seguir.
Quando chegar à seção "Criar um cofre de backup", faça os seguintes ajustes:
- Para a etapa 1, em Regiões, selecione Leste dos EUA. Em Redundância de armazenamento de backup, use Globalmente redundante.
- Para a etapa 2, habilite a restauração entre regiões.
Quando chegar à seção "Criar uma política de backup", faça os seguintes ajustes quando solicitado a criar uma política de retenção:
1. Adicione uma regra de retenção onde Vault-standard esteja selecionado.
2. Selecione Adicionar.
Quando chegar à seção "Configurar backups", faça os seguintes ajustes. Os passos 1-5 são para a instalação da extensão AKS. Pule as etapas 1 a 5 e comece a partir da etapa 6.
- Para a etapa 7, você corre em erros de permissão. Selecione Conceder permissão para seguir em frente. Após a conclusão da implantação de permissão, se o erro ainda aparecer, selecione Revalidar para atualizar as atribuições de função.
- Para a etapa 10, localize Selecionar recursos para backup e faça os seguintes ajustes:
  - Para Nome da instância de backup, preencha um nome exclusivo.
  - Em Namespaces, selecione namespaces para WebLogic Operator e WebLogic Server. Neste artigo, selecione weblogic-operator-ns e sample-domain1-ns.
  - Para Outras opções, selecione todas as opções. Certifique-se de que a opção Incluir segredos está selecionada.
- Para a etapa 11, você se depara com um erro de atribuição de função. Selecione sua fonte de dados na lista e selecione Atribuir funções ausentes para atenuar o erro.

Preparar para restaurar o cluster WLS em uma região secundária

Nesta seção, você se prepara para restaurar o cluster WLS na região secundária. Aqui, a região secundária é o oeste dos EUA. Antes de restaurar, você deve ter um cluster AKS com AKS Backup Extension instalado na região Oeste dos EUA.

Configurar o Registro de Contêiner do Azure para replicação geográfica

Use as etapas a seguir para configurar o Azure Container Registry (ACR) para replicação geográfica, que contém a imagem WLS criada na seção Implantar WLS no AKS . Para habilitar a replicação ACR, você precisa atualizá-la para o plano de preços Premium. Para obter mais informações, consulte Replicação geográfica no Registro de Contêiner do Azure.

Abra o grupo de recursos que você provisionou na seção Implantar WLS no AKS . Na lista de recursos, selecione o ACR cujo nome começa com wlsaksacr.
Na página inicial do ACR, selecione Propriedades de configurações>. Para Plano de preços, selecione Premium e, em seguida, selecione Guardar.
No painel de navegação, selecione Replicações geográficas de serviços>. Selecione Adicionar para adicionar a região de replicação na página.
Na página Criar replicação, em Local, selecione Oeste dos EUA e, em seguida, selecione Criar.

Após a conclusão da implantação, o ACR é habilitado para replicação geográfica.

Criar uma conta de armazenamento em uma região secundária

Para habilitar a Extensão de Backup do AKS, você deve fornecer uma conta de armazenamento com um contêiner vazio na mesma região.

Para restaurar o backup entre regiões, você deve fornecer um local de preparo onde os dados de backup estejam hidratados. Esse local de preparo inclui um grupo de recursos e uma conta de armazenamento dentro da mesma região e assinatura que o cluster de destino para restauração.

Use as etapas a seguir para criar uma conta de armazenamento e um contêiner. Alguns destes passos direcionam-no para outros guias.

Inicie sessão no portal do Azure.
Crie uma conta de armazenamento seguindo as etapas em Criar uma conta de armazenamento. Você não precisa executar todas as etapas no artigo. Preencha os campos mostrados no painel Noções básicas . Em Região, selecione Oeste dos EUA e, em seguida, selecione Rever + criar para aceitar as opções predefinidas. Prossiga para validar e criar a conta e, em seguida, volte a este artigo.
Crie um contêiner de armazenamento para a Extensão de Backup AKS seguindo as etapas na seção Criar um contêiner do Guia de início rápido: carregar, baixar e listar blobs com o portal do Azure.
Crie um contêiner de armazenamento como um local de preparo para uso durante a restauração.

Preparar um cluster AKS em uma região secundária

As seções a seguir mostram como criar um cluster AKS em uma região secundária.

Criar um novo cluster AKS

Este artigo expõe um aplicativo WLS usando o Application Gateway Ingress Controller. Nesta seção, você cria um novo cluster AKS na região Oeste dos EUA. Em seguida, habilite o complemento do controlador de ingresso com uma nova instância do gateway de aplicativo. Para obter mais informações, consulte Habilitar o complemento do controlador de entrada para um novo cluster AKS com uma nova instância de gateway de aplicativo.

Use as seguintes etapas para criar o cluster AKS:

Use os seguintes comandos para criar um grupo de recursos na região secundária:

export RG_NAME_WESTUS=wlsaks-westus-20240109

az group create --name ${RG_NAME_WESTUS} --location westus

Use os seguintes comandos para implantar um cluster AKS com o complemento habilitado:
```
export AKS_NAME_WESTUS=${RG_NAME_WESTUS}aks
export GATEWAY_NAME_WESTUS=${RG_NAME_WESTUS}gw

az aks create \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --network-plugin azure \
    --enable-managed-identity \
    --enable-addons ingress-appgw \
    --appgw-name ${GATEWAY_NAME_WESTUS} \
    --appgw-subnet-cidr "10.225.0.0/16" \
    --generate-ssh-keys
```
Este comando cria automaticamente uma Standard_v2 SKU instância do gateway de aplicativo com o nome ${RG_NAME_WESTUS}gw no grupo de recursos do nó AKS. O grupo de recursos do nó é nomeado MC_resource-group-name_cluster-name_location por padrão.

Nota

O cluster AKS que você provisionou na seção Implantar WLS no AKS é executado em três zonas de disponibilidade na região Leste dos EUA. As zonas de disponibilidade não são suportadas na região Oeste dos EUA. O cluster AKS no oeste dos EUA não é redundante de zona. Se o ambiente de produção exigir redundância de zona, verifique se a região emparelhada oferece suporte a zonas de disponibilidade. Para obter mais informações, consulte a seção Visão geral das zonas de disponibilidade para clusters AKS de Criar um cluster do Serviço Kubernetes do Azure (AKS) que usa zonas de disponibilidade.

Use os comandos a seguir para obter o endereço IP público da instância do gateway de aplicativo. Deixe de lado o endereço IP, que você usa mais adiante neste artigo.

export APPGW_ID=$(az aks show \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --query 'addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId' \
    --output tsv)
echo ${APPGW_ID}
export APPGW_IP_ID=$(az network application-gateway show \
    --id ${APPGW_ID} \
    --query frontendIPConfigurations\[0\].publicIPAddress.id \
    --output tsv)
echo ${APPGW_IP_ID}
export APPGW_IP_ADDRESS=$(az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query ipAddress \
    --output tsv)
echo "App Gateway pubilc IP address: ${APPGW_IP_ADDRESS}"

Use o comando a seguir para anexar um rótulo de nome DNS (serviço de nome de domínio) ao recurso de endereço IP público. Substitua <your-chosen-DNS-name> por um valor apropriado - por exemplo, ejb010316.
```
az network public-ip update --ids ${APPGW_IP_ID} --dns-name <your-chosen-DNS-name>
```
Você pode verificar o nome de domínio totalmente qualificado (FQDN) do IP público com az network public-ip show. O exemplo a seguir mostra um FQDN com rótulo ejb010316DNS :
```
az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query dnsSettings.fqdn \
    --output tsv
```
Este comando produz uma saída semelhante ao exemplo a seguir:
```
ejb010316.westus.cloudapp.azure.com
```

Nota

Se você estiver trabalhando com um cluster AKS existente, conclua as duas ações a seguir antes de prosseguir:

Habilite o complemento do controlador de entrada seguindo as etapas em Habilitar complemento do controlador de entrada do gateway de aplicativo para um cluster AKS existente.
Se você tiver WLS em execução no namespace de destino, para evitar conflitos, limpe os recursos WLS no namespace WebLogic Operator e no namespace WebLogic Server. Neste artigo, a oferta WLS no AKS provisionou o Operador WebLogic no namespace weblogic-operator-ns e o WebLogic Server no namespace sample-domain1-ns. Execute kubectl delete namespace weblogic-operator-ns sample-domain1-ns para excluir os dois namespaces.

Ativar a extensão de backup AKS

Antes de continuar, use as seguintes etapas para instalar a extensão de backup AKS no cluster na região secundária:

Use o seguinte comando para se conectar ao cluster AKS na região Oeste dos EUA:

az aks get-credentials \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS}

Use o seguinte comando para habilitar os drivers CSI e instantâneos para seu cluster:

az aks update \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

Abra o grupo de recursos que implantou o AKS. Selecione o cluster AKS na lista de recursos.
Na página inicial do AKS, selecione Configurações>Backup>da Extensão de Instalação.
Na página Instalar a extensão AKS Backup, selecione Avançar. Selecione a conta de armazenamento e o contêiner de Blob criados nas etapas anteriores. Selecione Avançar e, em seguida, Criar. Demora cerca de cinco minutos a concluir esta etapa.

Nota

Para economizar custos, você pode parar o cluster AKS na região secundária seguindo as etapas em Parar e iniciar um cluster do Serviço Kubernetes do Azure (AKS). Inicie-o antes de restaurar o cluster WLS.

Aguarde até que um backup padrão do Vault aconteça

No AKS, a camada padrão do Vault é a única camada que suporta redundância geográfica e restauração entre regiões. Conforme indicado em Qual camada de armazenamento de backup o AKS suporta?, "Apenas um ponto de recuperação agendado por dia é movido para o nível do Vault." Você deve aguardar a realização de um backup padrão do Vault. Um bom limite inferior é esperar 24 horas após concluir a etapa anterior antes de continuar.

Parar o cluster primário

O cluster WLS primário e o cluster WLS secundário são configurados com o mesmo banco de dados TLOG. Apenas um cluster pode possuir o banco de dados ao mesmo tempo. Para garantir que o cluster secundário funcione corretamente, pare o cluster WLS primário. Neste artigo, pare o cluster AKS para desativar o cluster WLS usando as seguintes etapas:

Abra o portal do Azure e vá para o grupo de recursos que você provisionou na seção Implantar WLS no AKS .
Abra o cluster AKS listado no grupo de recursos.
Selecione Parar para parar o cluster AKS. Certifique-se de que a implantação seja concluída antes de prosseguir.

Restaurar o cluster WLS

O backup do AKS suporta backups de nível operacional e de nível de cofre. Somente os backups armazenados na Camada do Vault podem ser usados para fazer uma restauração em um cluster em uma região diferente (Região Emparelhada do Azure). De acordo com as regras de retenção definidas na política de backup, o primeiro backup bem-sucedido de um dia é movido para a região cruzada do contêiner de blob. Para obter mais informações, consulte a seção Qual camada de armazenamento de backup o AKS backup suporta? de O que é o backup do Serviço Kubernetes do Azure?

Depois de configurar a redundância geográfica na seção Configurar redundância geográfica usando o Backup do Azure, leva pelo menos um dia para que os backups da camada do Vault fiquem disponíveis para restauração.

Use as seguintes etapas para restaurar o cluster WLS:

Abra o portal do Azure e procure Centro de backup. Selecione Centro de backup em Serviços.
Em Gerenciar, selecione Instâncias de backup. Filtre o tipo de fonte de dados Serviços Kubernetes para localizar a instância de backup criada na seção anterior.
Selecione a instância de backup para ver a lista de pontos de restauração. Neste artigo, o nome da ocorrência é uma cadeia de caracteres semelhante a wlsonaks*\wlsaksinstance20240109.
Selecione o backup mais recente operacional e padrão do Vault e, em seguida, selecione Mais opções. Selecione Restaurar para iniciar o processo de restauração.
Na página Restaurar, o painel padrão é Ponto de restauração. Selecione Anterior para alterar para o painel Noções básicas . Em Região de restauração, selecione Região secundária e, em seguida, selecione Seguinte: Ponto de restauro.
No painel Ponto de restauração, em Selecione a camada a restaurar, selecione Loja do Vault e, em seguida, selecione Seguinte:Parâmetros de restauração.
No painel Parâmetros de restauração , use as seguintes etapas:
1. Para Selecionar cluster de destino, selecione o cluster AKS que você criou na região Oeste dos EUA. Você se depara com um problema de permissão, como mostra a captura de tela a seguir. Selecione Conceder permissão para atenuar os erros.
2. Em Local de preparo de backup, selecione a conta de armazenamento que você criou no oeste dos EUA. Você se depara com um problema de permissão, como mostra a captura de tela a seguir. Selecione Atribuir funções ausentes para atenuar os erros.
3. Se os erros ainda acontecerem após a conclusão das atribuições de função, selecione Revalidar para atualizar as permissões.
4. Ao conceder permissões ausentes, se solicitado a especificar um Escopo, aceite o valor padrão.
5. Selecione Validar. Você verá a mensagem Validação concluída com êxito. Caso contrário, solucione e resolva o problema antes de continuar.
Selecione Seguinte:Rever + restaurar e, em seguida, selecione Restaurar. Leva cerca de 10 minutos para restaurar o cluster WLS.
Você pode monitorar o processo de restauração a partir do Centro>de backup Monitoramento + emissão de relatórios>Trabalhos de backup, conforme mostrado na captura de tela a seguir:
Selecione Atualizar para ver o progresso mais recente.
Depois que o processo for concluído sem erros, pare o cluster AKS de backup. A falha em fazer isso causa conflitos de propriedade quando você acessa o banco de dados TLOG em etapas posteriores.
Inicie o cluster primário.

Configurar um Azure Traffic Manager

Nesta seção, você cria um Gerenciador de Tráfego do Azure para distribuir o tráfego para seus aplicativos voltados para o público nas regiões globais do Azure. O ponto de extremidade primário aponta para o Gateway de Aplicativo do Azure no cluster WLS primário e o ponto de extremidade secundário aponta para o Gateway de Aplicativo do Azure no cluster WLS secundário.

Crie um perfil do Azure Traffic Manager seguindo as etapas em Guia de início rápido: criar um perfil do Gerenciador de Tráfego usando o portal do Azure. Ignore a seção "Pré-requisitos". Você só precisa das seguintes seções: Criar um perfil do Gerenciador de Tráfego, Adicionar pontos de extremidade do Gerenciador de Tráfego e Testar perfil do Gerenciador de Tráfego. Use as etapas a seguir ao percorrer essas seções e retorne a este artigo depois de criar e configurar o Gerenciador de Tráfego do Azure:

Quando chegar à secção Criar um perfil do Gestor de Tráfego, no passo 2 Criar perfil do Gestor de Tráfego, utilize os seguintes passos:
1. Deixe de lado o nome de perfil exclusivo do Gerenciador de Tráfego para Nome - por exemplo, tmprofile-ejb120623.
2. Salve de lado o novo nome do grupo de recursos para o grupo de recursos - por exemplo, myResourceGroupTM1.
Quando chegar à seção Adicionar pontos de extremidade do Gerenciador de Tráfego, use as seguintes etapas:
1. Após a etapa Selecione o perfil nos resultados da pesquisa, use as seguintes etapas:
  1. Em Definições, selecione Configuração.
  2. Para DNS time to live (TTL), digite 10.
  3. Em Configurações do monitor de ponto final, para Caminho, digite /weblogic/ready.
  4. Em Configurações rápidas de failover de ponto de extremidade, use os seguintes valores:
    - Em Sondagem interna, digite 10.
    - Em Número tolerado de falhas, digite 3.
    - Para o tempo limite da sonda, 5.
  5. Selecione Guardar. Aguarde até que seja concluído.
2. Na etapa 4 para adicionar o ponto de extremidade myPrimaryEndpointprimário, use as seguintes etapas:
  1. Em Tipo de recurso de destino, selecione Endereço IP público.
  2. Selecione a lista suspensa Escolher endereço IP público e insira o endereço IP do Application Gateway implantado no cluster WLS do Leste dos EUA que você salvou anteriormente. Você verá uma entrada correspondida. Selecione-o para Endereço IP público.
3. Na etapa 6 para adicionar um ponto de extremidade de failover / secundário myFailoverEndpoint, use as seguintes etapas:
  1. Em Tipo de recurso de destino, selecione Endereço IP público.
  2. Selecione a lista suspensa Escolher endereço IP público e insira o endereço IP do Application Gateway implantado no cluster WLS do oeste dos EUA que você salvou anteriormente. Você verá uma entrada correspondida. Selecione-o para Endereço IP público.
4. Espere um pouco. Selecione Atualizar até que o status do Monitor atinja os seguintes estados:
  - O objetivo principal é Online.
  - O ponto de extremidade de failover é Degradado.
Quando você chegar à seção Testar perfil do Gerenciador de Tráfego, use as seguintes etapas:
1. Na subseção Verifique o nome DNS, na etapa 3, salve de lado o nome DNS do seu perfil do Gerenciador de Tráfego - por exemplo, http://tmprofile-ejb120623.trafficmanager.net.
2. Na subseção Exibir Gerenciador de Tráfego em ação, use as seguintes etapas:
  1. Nas etapas 1 e 3, acrescente /weblogic/ready ao nome DNS do seu perfil do Gerenciador de Tráfego no navegador da Web - por exemplo, http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Você verá uma página vazia sem qualquer mensagem de erro.
  2. Na etapa 4, você não pode acessar /weblogic/ready, o que é esperado porque o cluster secundário está parado.
  3. Reative o ponto de extremidade primário.

Agora, o ponto de extremidade primário tem os estados Habilitado e Online e o ponto de extremidade de failover tem os estados Habilitados e Degradados no perfil do Gerenciador de Tráfego. Mantenha a página aberta para monitorar o status do endpoint mais tarde.

Teste o failover do primário para o secundário

Para testar o failover, faça manualmente o failover do servidor de banco de dados primário e do cluster WLS para o servidor de banco de dados secundário e o cluster WLS nesta seção.

Como o cluster primário está ativo e em execução, ele atua como o cluster ativo e lida com todas as solicitações de usuário roteadas pelo seu perfil do Gerenciador de Tráfego.

Abra o nome DNS do seu perfil do Azure Traffic Manager em uma nova guia do navegador, anexando a raiz de contexto /weblogic-café do aplicativo implantado - por exemplo, http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Crie um novo café com nome e preço - por exemplo, Café 1 com preço 10. Essa entrada é mantida na tabela de dados do aplicativo e na tabela de sessão do banco de dados. A interface do usuário que você vê deve ser semelhante à seguinte captura de tela:

Se a interface do usuário não for semelhante, solucione o problema e resolva o problema antes de continuar.

Mantenha a página aberta para que você possa usá-la para testes de failover mais tarde.

Failover para o site secundário

Use as etapas a seguir para fazer failover do primário para o secundário.

Primeiro, use as seguintes etapas para parar o cluster AKS primário:

Abra o portal do Azure e vá para o grupo de recursos que foi provisionado na seção Implantar WLS no AKS .
Abra o cluster AKS listado no grupo de recursos.
Selecione Parar para parar o cluster AKS. Certifique-se de que a implantação seja concluída antes de prosseguir.

Em seguida, use as etapas a seguir para fazer failover do Banco de Dados SQL do Azure do servidor primário para o servidor secundário.

Alterne para a guia do navegador do seu grupo de failover do Banco de Dados SQL do Azure.
Selecione Failover>Sim.
Aguarde até que seja concluído.

Em seguida, use as etapas a seguir para iniciar o cluster secundário.

Abra o portal do Azure e vá para o grupo de recursos que tem cluster AKS na região secundária.
Abra o cluster AKS listado no grupo de recursos.
Selecione Iniciar para iniciar o cluster AKS. Certifique-se de que a implantação seja concluída antes de prosseguir.

Por fim, use as seguintes etapas para verificar o aplicativo de exemplo depois que o ponto de extremidade myFailoverEndpoint estiver no estado Online:

Mude para o separador do browser do Gestor de Tráfego e, em seguida, atualize a página até ver que o valor de estado do Monitor do ponto de extremidade myFailoverEndpoint entra no estado Online .
Alterne para a guia do navegador do aplicativo de exemplo e atualize a página. Você deve ver os mesmos dados persistentes na tabela de dados do aplicativo e na tabela de sessão exibida na interface do usuário, conforme mostrado na captura de tela a seguir:

Se você não observar esse comportamento, pode ser porque o Gerenciador de Tráfego está demorando para atualizar o DNS para apontar para o site de failover. O problema também pode ser que seu navegador armazenou em cache o resultado da resolução de nomes DNS que aponta para o site com falha. Aguarde um pouco e atualize a página novamente.

Nota

Uma solução HA/DR pronta para produção seria responsável pela cópia contínua da configuração WLS dos clusters primários para os secundários em um cronograma regular. Para obter informações sobre como fazer isso, consulte as referências à documentação do Oracle no final deste artigo.

Para automatizar o failover, considere o uso de alertas nas métricas do Gerenciador de Tráfego e na Automação do Azure. Para obter mais informações, consulte a seção Alertas sobre métricas do Gerenciador de Tráfego de Métricas e alertas do Gerenciador de Tráfego e Usar um alerta para disparar um runbook de Automação do Azure.

Failback para o site primário

Para fazer failover para o site primário, você precisa garantir que os dois clusters tenham uma configuração de backup espelhado. Você pode obter esse estado usando as seguintes etapas:

Habilite os backups de cluster AKS na região Oeste dos EUA seguindo as etapas na seção Configurar redundância geográfica usando o Backup do Azure, a partir da etapa 4.
Restaure o backup mais recente da camada do Vault para o cluster na região Leste dos EUA seguindo as etapas na seção Preparar para restaurar o cluster WLS em uma região secundária. Ignore as etapas já concluídas.
Use etapas semelhantes na seção Failover para o site secundário para fazer failover para o site primário, incluindo servidor de banco de dados e cluster.

Clean up resources (Limpar recursos)

Se você não vai continuar a usar os clusters WLS e outros componentes, use as seguintes etapas para excluir os grupos de recursos para limpar os recursos usados neste tutorial:

Na caixa de pesquisa na parte superior do portal do Azure, insira Cofres de backup e selecione os cofres de backup nos resultados da pesquisa.
Selecione Manage>Properties>Soft delete>Update. Ao lado de Ativar exclusão suave, desmarque a caixa de seleção.
Selecione Gerenciar>instâncias de backup. Selecione a instância que você criou e exclua-a.
Insira o nome do grupo de recursos dos servidores do Banco de Dados SQL do Azure (por exemplo, myResourceGroup) na caixa de pesquisa na parte superior do portal do Azure e selecione o grupo de recursos correspondente nos resultados da pesquisa.
Selecione Eliminar grupo de recursos.
Em Digite o nome do grupo de recursos para confirmar a exclusão, digite o nome do grupo de recursos.
Selecione Eliminar.
Repita as etapas 4 a 7 para o grupo de recursos do Gerenciador de Tráfego - por exemplo, myResourceGroupTM1.
Repita as etapas 4 a 7 para o grupo de recursos do cluster WLS primário - por exemplo, wls-aks-eastus-20240109.
Repita as etapas 4 a 7 para o grupo de recursos do cluster WLS secundário - por exemplo, wls-aks-westus-20240109.

Próximos passos

Neste tutorial, você configura uma solução HA/DR que consiste em uma camada de infraestrutura de aplicativo ativo-passivo com uma camada de banco de dados ativo-passivo e na qual ambas as camadas abrangem dois sites geograficamente diferentes. No primeiro site, a camada de infraestrutura de aplicativo e a camada de banco de dados estão ativas. No segundo site, o domínio secundário é desligado e o banco de dados secundário está em espera.

Continue a explorar as seguintes referências para obter mais opções para criar soluções HA/DR e executar WLS no Azure:

Soluções de recuperação de desastres para produtos Oracle Fusion Middleware

Documentação de fiabilidade do Azure

Crie soluções para alta disponibilidade

Failover automático usando o Gerenciador de Tráfego do Azure

Saiba mais sobre o Oracle WebLogic em VMs do Azure

Saiba mais sobre o Oracle WebLogic no AKS