Tutorial: Migrar o Oracle WebLogic Server para Máquinas Virtuais do Azure com alta disponibilidade e recuperação de desastre

Artigo
09/01/2024

Este tutorial mostra uma maneira simples e eficaz de implementar alta disponibilidade e recuperação de desastre (HA/DR) para Java usando o Oracle WebLogic Server (WLS) em VMs (Máquinas Virtuais) do Azure. A solução ilustra como alcançar um RTO (Objetivo de Tempo de Recuperação) e um RPO (Objetivo de Ponto de Recuperação) baixos usando um aplicativo Jakarta EE simples orientado por banco de dados em execução no WLS. HA/DR é um tópico complexo, com muitas soluções possíveis. A melhor solução dependerá das suas necessidades específicas. Para conhecer outras maneiras de implementar HA/DR, consulte os recursos ao final deste artigo.

Neste tutorial, você aprenderá a:

Use as práticas recomendadas otimizadas do Azure para entender a alta disponibilidade e recuperação de desastre.
Configure um grupo de failover do Banco de Dados SQL do Microsoft Azure em regiões associadas.
Configure clusters WLS associados em VMs do Azure.
Configure um Gerenciador de Tráfego do Azure.
Configure clusters WLS de alta disponibilidade e recuperação de desastre.
Teste o failover do primário para o secundário.

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

O Gerenciador de Tráfego do Azure verifica a integridade de suas regiões e roteia o tráfego de acordo com a camada de aplicativo. Tanto a região primária como a região secundária têm uma implantação completa do cluster do WLS. No entanto, somente a região primária processa ativamente solicitações de rede dos usuários. A região secundária é passiva e se mantém ativada para receber tráfego apenas quando a região primária apresenta uma interrupção do serviço. O Gerenciador de Tráfego do Azure usa o recurso de verificação de integridade do Gateway de Aplicativo do Azure para implementar esse roteamento condicional. O cluster primário WLS se mantém em execução e o cluster secundário é desligado. O RTO de failover geográfico da camada de aplicativo depende do tempo para iniciar VMs e executar o cluster WLS secundário. O RPO depende do Banco de Dados SQL do Azure porque os dados persistem e replicam no grupo de failover do Banco de Dados SQL do Azure.

A camada do 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 passivo somente leitura e conectado ao cluster WLS secundário. Um failover geográfico alterna todos os bancos de dados secundários no grupo para a função primária. Para RPO de failover geográfico e RTO do Banco de Dados SQL do Azure, consulte Visão geral da continuidade dos negócios.

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

Pré-requisitos

Uma assinatura do Azure. Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Verifique se você tem as funções Owner ou Contributor e User Access Administrator na assinatura. Você pode verificar a atribuição pelas 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.
Instale e configure o Git.
Instale uma implementação do Java SE, versão 17 ou posterior (por exemplo, o build da Microsoft do OpenJDK).
Instale o Maven, versão 3.9.3 ou posterior.

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

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

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

Quando você chegar à seção Criar um banco de dados individual, siga estas etapas:
1. Na etapa 4 para criar um novo grupo de recursos, salve o valor Nome do grupo de recursos; por exemplo myResourceGroup.
2. Na etapa 5 para o nome do banco de dados, salve o valor Nome do banco de dados; por exemplo, mySampleDatabase.
3. Na etapa 6 para criar o servidor, sigas estas etapas:
  1. Salve 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 do SQL.
  4. Salve o valor de Logon do administrador do servidor; por exemplo, azureuser.
  5. Salve o valor da Senha.
4. Na etapa 8, em Ambiente de carga de trabalho, selecione Desenvolvimento. Leia a descrição e considere outras opções para sua carga de trabalho.
5. Na etapa 11, em 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, em Permitir que serviços e recursos do Azure acessem este servidor, selecione Sim.
Ao acessar a seção Consultar o banco de dados, siga estas etapas:
1. Na etapa 3, insira as informações de entrada do administrador do servidor de autenticação SQL para entrar.
  
  Observação
  
  Se a entrada falhar e gerar uma mensagem de erro semelhante a Cliente com endereço IP "xx.xx.xx.xx" não tem permissão para acessar o servidor, selecione IP da lista de permissões xx.xx.xx.xx no servidor <your-sqlserver-name> ao 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 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 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 Consulta bem-sucedida: Linhas afetadas: 0.

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

Então, 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 recuperação panejada. Use as etapas a seguir ao ler o artigo e, em seguida, retorne a este artigo depois de criar e configurar o grupo de failover do Banco de Dados SQL do Azure:

Quando você 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 servidor secundário e execute as seguintes etapas:
  1. Insira e salve o nome do grupo de failover; por exemplo, failovergroupname-ejb120623.
  2. Insira e salve o nome exclusivo do servidor; por exemplo, sqlserversecondary-ejb120623.
  3. Digite o mesmo administrador e senha do servidor primário.
  4. Em Local, selecione uma região diferente daquela usada para o banco de dados primário.
  5. Verifique se Permitir que os serviços do Azure acessem o servidor está selecionado.
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 recuperação panejada, mantenha a página do grupo de failover aberta e use-a para o teste de failover dos clusters WLS posteriormente.

Configurar clusters WLS associados em VMs do Azure

Nesta seção, você cria dois clusters WLS em VMs do Azure usando a oferta Oracle WebLogic Server Cluster em VMs do Azure. O cluster no Leste dos EUA é o primário, configurado como cluster ativo mais adiante. O cluster no Oeste dos EUA é secundário e é configurado como o cluster passivo mais adiante.

Configurar o cluster WLS primário

Primeiro, abra a oferta Oracle WebLogic Server Cluster em VMs do Azure no navegador e selecione Criar. Você deve ver o painel Noções básicas da oferta.

Siga estas etapas para preencher o painel Noções básicas:

Certifique-se de que o valor mostrado em Assinatura seja o mesmo que tem as funções listadas na seção de pré-requisitos.
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, wls-cluster-eastus-ejb120623.
Em Detalhes da instância, em Região, selecione Leste dos EUA.
Em Credenciais para Máquinas Virtuais e WebLogic, informe uma senha para a conta de administrador da VM e Administrador do WebLogic, respectivamente. Salve o nome de usuário e a senha do Administrador do WebLogic.
Deixe os padrões dos outros campos.
Selecione Avançar para ir ao painel Configuração TLS/SSL.

Mantenha os padrões no painel Configuração TLS/SSL, selecione Avançar para ir ao painel Gateway de Aplicativo do Azure e siga as etapas a seguir.

Em Conectar-se ao Gateway de Aplicativo do Azure?, selecione Sim.
Para Selecionar a opção de certificado TLS/SSL desejada, selecione Gerar um certificado autoassinado.
Selecione Avançar para acessar o painel Rede.

Você deve ver todos os campos pré-preenchidos com os padrões no painel Rede. Siga estas etapas para salvar a configuração da rede:

Selecione Editar rede virtual. Salve o espaço de endereço da rede virtual; por exemplo, 10.1.4.0/23.
Selecione wls-subnet para editar a sub-rede. Em Detalhes da sub-rede, salve o endereço inicial e o tamanho da sub-rede; por exemplo, 10.1.5.0 e /28.
Salve todas as alterações que você fizer.
Retorne ao painel Rede.
Selecione Avançar para acessar o painel Banco de Dados.

As etapas a seguir mostram como preencher o painel Banco de Dados:

Em Conectar a um banco de dados?, selecione Sim.
Em Escolher tipo de banco de dados, selecione Microsoft SQL Server (Suporta conexão sem senha).
Em Nome JNDI, digite jdbc/WebLogicCafeDB.
Para String de Conexão de Fonte de Dados, substitua os espaços reservados pelos valores salvos na seção anterior para o Banco de Dados SQL primário; por exemplo, jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
Para Protocolo de transação global, selecione Nenhum.
Em Nome de usuário do banco de dados, substitua os espaços reservados pelos valores salvos na seção anterior para o banco de dados SQL primário; por exemplo, azureuser@sqlserverprimary-ejb120623.
Digite a senha de entrada do administrador do servidor que você salvou anteriormente para Senha do Banco de Dados. Insira o mesmo valor para Confirmar senha.
Deixe os padrões dos outros campos.
Selecione Examinar + criar.
Aguarde até que Execução da validação final... seja concluída com êxito e selecione Criar.

Depois de alguns instantes, você deverá ver a página Implantação, onde Implantação em andamento é exibido.

Observação

Se você encontrar problemas 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é 50 minutos para ser concluída. Depois disso, você deverá ver o texto Sua implantação está concluída exibido na página de implantação.

Enquanto isso, você pode configurar o cluster WLS secundário em paralelo.

Configurar o cluster WLS secundário

Siga as mesmas etapas na seção Configurar o cluster WLS primário para configurar o cluster WLS secundário na região Oeste dos EUA, exceto pelas seguintes diferenças:

No painel Noções básicas, execute as seguintes etapas:
1. No campo Grupo de recursos, selecione Criar novo e preencha um valor exclusivo diferente para o grupo de recursos; por exemplo, wls-cluster-westus-ejb120623.
2. Em Detalhes da instância, em Região, selecione Oeste dos EUA.
No painel Rede, execute as seguintes etapas:
1. Em Editar rede virtual, insira o mesmo espaço de endereçamento da rede virtual do cluster WLS primário; por exemplo, 10.1.4.0/23.
  
  Observação
  
  Você deve ver uma mensagem de aviso semelhante a esta: O espaço de endereço "10.1.4.0/23 (10.1.4.0 - 10.1.5.255)" se sobrepõe ao espaço de endereço "10.1.4.0/23 (10.1.4.0 - 10.1.5.255)" da rede virtual "wls-vnet". As redes virtuais com espaço de endereçamento sobreposto não podem ser associadas. Para associar essas redes virtuais, altere o espaço de endereço "10.1.4.0/23 (10.1.4.0 - 10.1.5.255)". Você pode ignorar essa mensagem porque precisa de dois clusters WLS com a mesma configuração de rede.
2. Em wls-subnet, insira o mesmo endereço inicial e tamanho de sub-rede do cluster WLS primário; por exemplo, 10.1.5.0 e /28.
No painel Banco de Dados, execute as seguintes etapas:
1. Para String de Conexão de Fonte de Dados, substitua os espaços reservados pelos valores salvos na seção anterior para o Banco de Dados SQL secundário; por exemplo, jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
2. Em Nome de usuário do banco de dados, substitua os espaços reservados pelos valores salvos na seção anterior para o banco de dados SQL secundário; por exemplo, azureuser@sqlserversecondary-ejb120623.

Espelhar as configurações de rede para os dois clusters

Durante a fase de retomada de transações pendentes no cluster WLS secundário após um failover, o WLS verifica a propriedade do repositório TLOG. Para passar na verificação com êxito, todos os servidores gerenciados no cluster secundário devem ter o mesmo endereço IP privado que o cluster primário.

Esta seção mostra como espelhar as configurações de rede do cluster primário para o cluster secundário.

Primeiro, use as seguintes etapas para definir as configurações de rede para o cluster primário depois de fazer a implantação:

No painel Visão Geral da Implantação, selecione Ir para o grupo de recursos.
Selecione o adaptador de rede adminVM_NIC_with_pub_ip.
1. Em Configurações, selecione Configurações de IP.
2. Selecione ipconfig1.
3. Em Configurações de endereço IP privado, selecione Estático para Alocação. Salve o endereço IP privado.
4. Selecione Salvar.
Retorne ao grupo de recursos do cluster WLS primário e repita a etapa 3 para os adaptadores de rede mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip e mspVM3_NIC_with_pub_ip.
Aguarde até que todas as atualizações sejam concluídas. Você pode selecionar o ícone de notificações no portal do Azure para abrir o painel Notificações para monitorar o status.
Retorne ao grupo de recursos do cluster WLS primário e copie o nome do recurso com o tipo Ponto de extremidade privado; por exemplo, 7e8c8bsaep. Use esse nome para localizar o adaptador de rede restante; por exemplo, 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Selecione-o e siga as etapas anteriores para obter seu endereço IP privado.

Em seguida, siga estas etapas para definir as configurações de rede para o cluster secundário depois de concluir a implantação:

No painel Visão Geral da Implantação, selecione Ir para o grupo de recursos.
Para os adaptadores de rede adminVM_NIC_with_pub_ip, mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip e mspVM3_NIC_with_pub_ip, siga as etapas anteriores para atualizar a alocação de endereço IP privado para Estático.
Aguarde até que todas as atualizações sejam concluídas.
Para os adaptadores de rede mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip e mspVM3_NIC_with_pub_ip, siga as etapas anteriores, mas atualize o endereço IP privado para o mesmo valor usado com o cluster primário. Aguarde até que a atualização atual do adaptador de rede seja concluída antes de passar para a próxima.

Observação

Você não pode alterar o endereço IP privado do adaptador de rede que faz parte de um ponto de extremidade privado. Para espelhar facilmente os endereços IP privados de adaptadores de rede para servidores gerenciados, atualize o endereço IP privado para adminVM_NIC_with_pub_ip de um endereço IP que não seja usado. Dependendo da alocação de endereços IP privados em seus dois clusters, talvez seja necessário atualizar o endereço IP privado no cluster primário também.

A tabela a seguir mostra um exemplo de espelhamento das configurações de rede para dois clusters:

Cluster	Adaptador de rede	Endereço IP privado (antes)	Endereço IP privado (depois)	Atualizar sequência
Primária	`7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a`	`10.1.5.4`	`10.1.5.4`
Primária	`adminVM_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.7`
Primária	`mspVM1_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.5`
Primário	`mspVM2_NIC_with_pub_ip`	`10.1.5.8`	`10.1.5.9`	1
Primária	`mspVM3_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.6`
Secundário	`1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1`	`10.1.5.8`	`10.1.5.8`
Secundário	`adminVM_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.4`	4
Secundário	`mspVM1_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.5`	5
Secundário	`mspVM2_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.9`	2
Secundário	`mspVM3_NIC_with_pub_ip`	`10.1.5.4`	`10.1.5.6`	3

Verifique o conjunto de endereços IP privados de todos os servidores gerenciados, que consiste no pool de back-end do Gateway de Aplicativo do Azure implantado em cada cluster. Se ele for atualizado, execute as seguintes etapas para atualizar o pool de back-end do Gateway de Aplicativo do Azure adequadamente:

Abra o grupo de recursos do cluster.
Localize o recurso myAppGateway com o tipo Gateway de aplicativo. Selecione-a para abri-la.
Na seção Configurações, selecione Pools de back-end e selecione myGatewayBackendPool.
Altere os valores de Destinos de back-end com um ou mais endereços IP atualizados e selecione Salvar. Aguarde a conclusão.
Na seção Configurações, selecione Investigações de integridade e, em seguida, selecione HTTPhealthProbe.
Verifique se Desejo testar a integridade do back-end antes de adicionar a investigação de integridade está marcada e, em seguida, selecione Testar. Você verá que o valor Status do pool de back-end myGatewayBackendPool está marcado como íntegro. Se não estiver, verifique se os endereços IP privados foram atualizados conforme o esperado e se as VMs estão em execução. Em seguida, teste a investigação de integridade novamente. Você deve resolver o problema antes de continuar.

No exemplo a seguir, o pool de back-end do Gateway de Aplicativo do Azure de cada cluster é atualizado:

Cluster	Pool de back-end do Gateway de Aplicativo do Azure	Destinos de back-end (antes)	Destinos de back-end (depois)
Primária	`myGatewayBackendPool`	(`10.1.5.5`, `10.1.5.8`, `10.1.5.6`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)
Secundário	`myGatewayBackendPool`	(`10.1.5.7`, `10.1.5.6`, `10.1.5.4`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)

Para automatizar o espelhamento de configurações de rede, use a CLI do Azure. Para obter mais informações, consulte Introdução à CLI do Azure.

Verificar as implantações dos clusters

Você implantou um Gateway de Aplicativo do Azure e um servidor de administração WLS em cada cluster. O Gateway de Aplicativo do Azure age como balanceador de carga para todos os servidores gerenciados no cluster. O servidor de administração WLS fornece um console Web para configuração de cluster.

Execute as etapas a seguir para verificar se o Gateway de Aplicativo do Azure e o console de administração do WLS em cada cluster funcionam antes de passar para a próxima etapa:

Retorne à página Implantação e selecione Saídas.
Copie o valor da propriedade appGatewayURL. Acrescente a cadeia de caracteres weblogic/ready e abra essa URL em uma nova guia do navegador. Você deve ver uma página vazia sem nenhuma mensagem de erro. Se não vir, resolva o problema antes de continuar.
Copie e salve o valor da propriedade adminConsole. Abra-o em uma nova guia do navegador. Você deve ver a página de entrada do Console de Administração do WebLogic Server. Entre no console com o nome de usuário e a senha do administrador do WebLogic que você salvou anteriormente. Se você não conseguir entrar, solucione o problema antes de continuar.

Execute as etapas a seguir para obter o endereço IP do Gateway de Aplicativo do Azure para cada cluster. Você usa esses valores ao configurar o Gerenciador de Tráfego do Azure posteriormente.

Abra o grupo de recursos em que o cluster está implantado – por exemplo, selecione Visão Geral, para voltar ao painel Visão geral da página de implantação. Depois, selecione Ir para grupo de recursos.
Localize o recurso gwip com o tipo Endereço IP público e selecione-o para abri-lo. Procure o campo Endereço IP e salve seu valor.

Configurar um Gerenciador de Tráfego do Azure

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 Gerenciador de Tráfego do Azure de acordo com 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 o perfil do Gerenciador de Tráfego. Siga estas etapas ao percorrer essas seções e, em seguida, retorne a este artigo depois de criar e configurar o Gerenciador de Tráfego do Azure.

Quando você chegar à seção Criar um perfil do Gerenciador de Tráfego, siga estas etapas:
1. Na etapa 2 Criar perfil do Gerenciador de Tráfego, execute as seguintes etapas:
  1. Salve o nome de perfil exclusivo do Gerenciador de Tráfego para Nome; por exemplo, tmprofile-ejb120623.
  2. Em Grupo de recursos, salve o novo nome do grupo de recursos; por exemplo, myResourceGroupTM1.
Quando você chegar à seção Adicionar pontos de extremidade do Gerenciador de Tráfego, execute as seguintes etapas:
1. Execute esta ação adicional após a etapa Selecionar o perfil nos resultados da pesquisa.
  1. Em Configurações, escolha Configuração.
  2. Em Vida útil (TTL) do DNS, digite 10.
  3. Em Configurações do monitor de ponto de extremidade, em Caminho, insira /weblogic/ready.
  4. Em Configurações de failover de ponto de extremidade rápido, use os seguintes valores:
    - Em Investigação interna, digite 10.
    - Em Número tolerado de falhas, digite 3.
    - Para Tempo limite de investigação, 5.
  5. Selecione Salvar. Aguarde a conclusão.
2. Na etapa 4 para adicionar o ponto de extremidade primário myPrimaryEndpoint, execute as seguintes etapas:
  1. Para 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 Gateway de Aplicativo implantado no cluster WLS Leste dos EUA que você salvou anteriormente. Você deve ver uma correspondência de entrada. Selecione-a para Endereço IP público.
3. Na etapa 6 para adicionar um failover/ponto de extremidade secundário myFailoverEndpoint, execute as seguintes etapas:
  1. Para 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 Gateway de Aplicativo implantado no cluster WLS Oeste dos EUA que você salvou anteriormente. Você deve ver uma correspondência de entrada. Selecione-a para Endereço IP público.
4. Aguarde. Selecione Atualizar até que o valor de Status do Monitor dos dois pontos de extremidade seja Online.
Quando você chegar à seção Testar perfil do Gerenciador de Tráfego, siga estas etapas:
1. Na subseção Verificar o nome do DNS, execute a seguinte etapa:
  1. Na etapa 3, salve 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, execute 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ê deve ver uma página vazia sem mensagem de erro.
  2. Depois de concluir todas as etapas, habilite seu ponto de extremidade primário conforme a etapa 2, mas substitua Desabilitado por Habilitado. Em seguida, volte à página Pontos de Extremidade.

Agora você tem os dois pontos de extremidade Habilitados e Online no perfil do Gerenciador de Tráfego. Mantenha a página aberta e use-a para monitorar o status do ponto de extremidade posteriormente.

Configurar os clusters WLS de alta disponibilidade e recuperação de desastre

Nesta seção, você configura clusters WLS para alta disponibilidade e recuperação de desastre.

Preparar o aplicativo de exemplo

Nesta seção, você cria e compacta um aplicativo CRUD Java/JakartaEE de amostra que você implanta e executa posteriormente 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 de dados jdbc/WebLogicCafeDB 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 os dados do aplicativo coffee na mesma fonte de dados jdbc/WebLogicCafeDB.

Use as seguintes etapas para criar e compactar o exemplo:

Use os seguintes comandos para clonar o repositório de amostra 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 você vir uma mensagem sobre Detached HEAD, pode ignorá-la com segurança.
Use os seguintes comandos para acessar o diretório de exemplo e, em seguida, compilar e compactar o exemplo:
```
cd weblogic-cafe
mvn clean package
```

Quando o pacote for gerado com êxito, ele estará em <parent-path-to-your-local-clone>/azure-cafe/weblogic-cafe/target/weblogic-cafe.war. Se você não vir o pacote, resolva o problema antes de continuar.

Implantar o aplicativo de exemplo

Agora, execute as seguintes etapas para implantar o aplicativo de exemplo nos clusters, começando pelo cluster primário:

Abra o adminConsole do cluster em uma nova guia do navegador da Web. Entre no Console de Administração do WebLogic Server com o nome de usuário e a senha do Administrador do WebLogic que você salvou anteriormente.
Localize Estrutura de domínio>wlsd>Implantações no painel de navegação. Selecione Implantações.
Selecione Bloquear & Editar>Instalar>Carregar seus arquivos>Escolher Arquivo. Selecione o arquivo weblogic-cafe.war que você preparou anteriormente.
Selecione Próximo>Próximo>Próximo. Selecione cluster1 com a opção Todos os servidores no cluster para os destinos de implantação. Selecione Avançar>Concluir. Selecione Ativar Alterações.
Mude para a guia Controle e selecione weblogic-cafe na tabela de implantações. Selecione Iniciar com a opção Processando todas as solicitações>Sim. Aguarde um pouco e atualize a página até ver que o estado da implantação weblogic-cafe é Ativo. Mude para a guia Monitoramento e verifique se a raiz de contexto do aplicativo implantado é /weblogic-cafe. Mantenha o console de administração do WLS aberto para que usá-lo mais tarde para configuração adicional.

Repita as etapas no Console de Administração do WebLogic Server, mas para o cluster secundário na região Oeste dos EUA.

Atualizar o host front-end

Execute as etapas a seguir para que seus clusters WLS reconheçam o Gerenciador de Tráfego do Azure. Como o Gerenciador de Tráfego do Azure é o ponto de entrada para solicitações de usuário, atualize o Host Frontal do cluster do WebLogic Server para o nome DNS do perfil do Gerenciador de Tráfego, começando pelo cluster primário.

Verifique sua conexão com o Console de Administração do WebLogic Server.
Acesse Estrutura de domínio>wlsd>Ambiente>Clusters no painel de navegação. Selecione Clusters.
Selecione cluster1 na tabela de clusters.
Selecione Bloquear & Editar>HTTP. Remova o valor atual de Host de Front-end e insira o nome DNS do perfil do Gerenciador de Tráfego que você salvou anteriormente, sem o http:// inicial; por exemplo, tmprofile-ejb120623.trafficmanager.net. Selecione Salvar>Ativar Alterações.

Repita as etapas no Console de Administração do WebLogic Server, mas para o cluster secundário na região Oeste dos EUA.

Configurar o repositório do log de transações

Em seguida, configure o Armazenamento de Log de Transações JDBC para todos os servidores gerenciados de clusters, começando pelo cluster primário. Essa prática é descrita em Usar arquivos de log de transações para recuperar transações.

Execute as seguintes etapas no cluster WLS primário na região Leste dos EUA:

Verifique sua conexão com o Console de Administração do WebLogic Server.
Acesse Estrutura de domínio>wlsd>Ambiente>Servidores no painel de navegação. Selecione Servidores.
Você deve ver os servidores msp1, msp2 e msp3 listados na tabela de servidores.
Selecione msp1>Serviços>Bloquear & Editar. Em Armazenamento de Log de Transações, selecione JDBC.
Em Tipo>Fonte de Dados, selecione jdbc/WebLogicCafeDB.
Confirme se o valor de Nome do Prefixo é TLOG_msp1_, que é o valor padrão. Se o valor for diferente, altere-o para TLOG_msp1_.
Selecione Salvar.
Selecione Servidores>msp2 e repita as etapas, exceto pelo fato de que o valor padrão de Nome do Prefixo é TLOG_msp2_.
Selecione Servidores>msp3 e repita as etapas, exceto pelo fato de que o valor padrão de Nome do Prefixo é TLOG_msp3_.
Selecione Ativar Alterações.

Repita as etapas no Console de Administração do WebLogic Server, mas para o cluster secundário na região Oeste dos EUA.

Reiniciar os servidores gerenciados do cluster primário

Depois, use as seguintes etapas para reiniciar todos os servidores gerenciados do cluster primário para que as alterações entrem em vigor:

Verifique sua conexão com o Console de Administração do WebLogic Server.
Acesse Estrutura de domínio>wlsd>Ambiente>Servidores no painel de navegação. Selecione Servidores.
Selecione a guia Controle . Selecione msp1, msp2 e msp3. Selecione Desligar com a opção Quando o trabalho for concluído>Sim. Selecione o ícone Atualizar. Aguarde até que o valor Status da Última Ação seja TASK COMPLETED. Você verá que o valor de Estado para os servidores selecionados é SHUTDOWN. Selecione novamente o ícone de atualização para interromper o monitoramento de status.
Selecione novamente msp1, msp2 e msp3. Selecione Iniciar>Sim. Selecione o ícone Atualizar. Aguarde até que o valor Status da Última Ação seja TASK COMPLETED. Você verá que o valor de Estado para os servidores selecionados é RUNNING. Selecione novamente o ícone de atualização para interromper o monitoramento de status.

Parar as VMs no cluster secundário

Agora, execute as seguintes etapas para interromper todas as VMs no cluster secundário para torná-lo passivo:

Abra a página inicial do portal do Azure em uma nova guia do navegador e selecione Todos os recursos. Na caixa Filtrar para qualquer campo..., insira o nome do grupo de recursos em que o cluster secundário está implantado; por exemplo, wls-cluster-westus-ejb120623.
Selecione Tipo igual a todos para abrir o filtro Tipo. Em Valor, insira Máquina virtual. Você deve ver uma correspondência de entrada. Selecione-o para Valor. Escolha Aplicar. Você deve ver 4 VMs listadas, incluindo adminVM, mspVM1, mspVM2 e mspVM3.
Selecione para abrir cada VM. Selecione Parar e confirme para cada VM.
Selecione o ícone de notificações no portal do Azure para abrir o painel Notificações.
Monitore o evento Parando a máquina virtual de cada VM até que o valor se torne Máquina virtual interrompida com êxito. Mantenha a página aberta para usá-la para o teste de failover posteriormente.

Agora, mude para a guia do navegador onde você monitora o status dos pontos de extremidade do Gerenciador de Tráfego. Atualize a página até perceber que o ponto de extremidade myFailoverEndpoint está Degradado e o ponto de extremidade myPrimaryEndpoint está Online.

Observação

Para uma solução de HA/DR pronta para produção, seria recomendável obter um RTO mais baixo, deixando as VMs em execução, mas apenas interrompendo o software WLS que está em execução nelas. Então, em caso de failover, as VMs já estariam em execução, enquanto o software WLS levaria menos tempo para iniciar. Para fins deste artigo, as VMs foram interrompidas, porque o software implantado pelo Cluster do Oracle WebLogic Server em VMs do Azure inicia automaticamente o software WLS quando as VMs são iniciadas.

Verificar o aplicativo

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

Abra o nome DNS do seu perfil do Gerenciador de Tráfego do Azure em uma nova guia do navegador, acrescentando a raiz de contexto /weblogic-cafe do aplicativo implantado; por exemplo, http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Crie um café com nome e preço; por exemplo, Café 1 com preço 10. Essa entrada persiste na tabela de dados do aplicativo e na tabela de sessão do banco de dados. A UI que você verá deve ser semelhante à seguinte captura de tela:

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

Mantenha a página aberta para usá-la para o teste de failover posteriormente.

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

Para testar o failover, você realiza o failover manual do servidor de banco de dados primário e do cluster para o servidor de banco de dados secundário e o cluster e, em seguida, faz o failback usando o portal do Azure nesta seção.

Failover para o site secundário

Primeiro, execute as seguintes etapas para desligar as VMs no cluster primário:

Localize o nome do grupo de recursos no qual o cluster WLS primário está implantado; por exemplo, wls-cluster-eastus-ejb120623. Depois, siga as etapas na seção Parar VMs no cluster secundário, mas altere o grupo de recursos de destino para o cluster WLS primário para interromper todas as VMs nesse cluster.
Mude para a guia do navegador do Gerenciador de Tráfego, atualize a página até ver que o valor de Status do Monitor do ponto de extremidade myPrimaryEndpoint se torna Degradado.
Mude para a guia do navegador do aplicativo de exemplo e atualize a página. Você deverá ver 504 Gateway Time-out ou 502 Bad Gateway, porque nenhum dos pontos de extremidade está acessível.

Em seguida, siga as próximas etapas para fazer failover do Banco de Dados SQL do Azure do servidor primário para o servidor secundário:

Mude para a guia do navegador do grupo de failover do Banco de Dados SQL do Azure.
Selecione Failover>Sim.
Aguarde a conclusão.

Em seguida, siga estas etapas para iniciar todos os servidores no cluster secundário:

Mude para a guia do navegador em que você parou todas as VMs no cluster secundário.
Selecione a VM adminVM. Selecione Iniciar.
Monitore o evento Iniciando a máquina virtual para adminVM no painel Notificações e aguarde até que o valor se torne Máquina virtual iniciada.
Mude para a guia do navegador do Console de Administração do WebLogic Server para o cluster secundário e atualize a página até ver a página de boas-vindas para entrar.
Volte para a guia do navegador em que todas as VMs no cluster secundário estão listadas. Para as VMs mspVM1, mspVM2 e mspVM3, selecione cada uma para abri-la e, em seguida, selecione Iniciar.
Para as VMs mspVM1, mspVM2 e mspVM3, monitore o evento Iniciando a máquina virtual, no painel Notificações, e aguarde até que os valores se tornem Máquina virtual iniciada.

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

Mude para a guia do navegador do Gerenciador de Tráfego e atualize a página até ver que o valor de Status do Monitor do ponto de extremidade myFailoverEndpoint entra no estado Online.
Mude para a guia do navegador do aplicativo de exemplo e atualize a página. Você deverá ver os mesmos dados persistidos 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 até 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.

Observação

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

Para automatizar o failover, use 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.

Fazer failback para o primário primário

Siga as mesmas etapas na seção Failover para o site secundário para fazer failback para o site primário, incluindo o servidor de banco de dados e o cluster, exceto pelas seguintes diferenças:

Primeiro, desligue as VMs no cluster secundário. Você verá que o ponto de extremidade myFailoverEndpoint se torna Degradado.
Em seguida, faça o failover do Banco de Dados SQL do Azure do servidor secundário para o servidor primário.
Então, inicie todos os servidores no cluster primário.
Por fim, verifique o aplicativo de exemplo depois que o ponto de extremidade myPrimaryEndpoint estiver Online.

Limpar os recursos

Se você não for continuar usando os clusters WLS e outros componentes, siga estas etapas para excluir os grupos de recursos para limpar os recursos usados neste tutorial:

Na caixa de pesquisa da parte superior do portal do Azure, insira o nome do grupo de recursos dos servidores do Banco de Dados SQL do Azure (por exemplo, myResourceGroup) e selecione o grupo de recursos correspondente nos resultados da pesquisa.
Selecione Excluir grupo de recursos.
Em Inserir nome do grupo de recursos para confirmar a exclusão, insira o nome do grupo de recursos.
Selecione Excluir.
Repita as etapas 1 a 4 para o grupo de recursos do Gerenciador de Tráfego; por exemplo, myResourceGroupTM1.
Repita as etapas 1 a 4 para o grupo de recursos do cluster WLS primário; por exemplo, wls-cluster-eastus-ejb120623.
Repita as etapas 1 a 4 para o grupo de recursos do cluster WLS secundário; por exemplo, wls-cluster-westus-ejb120623.

Próximas etapas

Neste tutorial, você configura uma solução HA/DR que consiste em uma camada de infraestrutura de aplicativo ativa-passiva com uma camada de banco de dados ativa-passiva em que as duas 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 se mantém em espera.

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

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

Documentação de confiabilidade do Azure

Criar 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