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

Artigo
01/11/2024

Este tutorial mostra uma maneira simples e eficaz de implementar alta disponibilidade e recuperação de desastres (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 (Recovery Time Objective, objetivo de tempo de recuperação) e um RPO (Recovery Point Objective, 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 tema complexo, com muitas soluções possíveis. A melhor solução depende de suas necessidades exclusivas. Para outras maneiras de implementar HA/DR, consulte os recursos no final deste artigo.

Neste tutorial, você aprenderá a:

Use as práticas recomendadas otimizadas do Azure para obter alta disponibilidade e recuperação de desastres.
Configure um grupo de failover do Banco de dados SQL do Microsoft Azure em regiões emparelhadas.
Configure clusters WLS emparelhados em VMs do Azure.
Configure um Gerenciador de Tráfego do Azure.
Configure clusters WLS para alta disponibilidade e recuperação de desastres.
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 quanto a secundária têm uma implantação completa do cluster WLS. No entanto, apenas a região primária está atendendo ativamente às solicitações de rede dos usuários. A região secundária é passiva e ativada para receber tráfego somente quando a região primária sofre 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 WLS primário está 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 são persistentes e replicados no grupo de failover do Banco de Dados SQL do Azure.

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 somente pronto passivo 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 de negócios.

Este artigo foi escrito com o serviço Banco de Dados SQL do Azure porque o artigo se baseia nos 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.

Pré-requisitos

Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Verifique se você tem a função ou as OwnerContributor 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.
Instale e configure o Git.
Instale uma implementação Java SE, versão 17 ou posterior (por exemplo, a compilação 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 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 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) para esse 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 o 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 instruções a seguir ao longo do artigo e retorne a este artigo depois de criar e configurar o Banco de Dados SQL do Azure:

Quando você chegar à seção Criar um único banco de dados, use as seguintes etapas:
1. Na etapa 4 para criar um novo grupo de recursos, anote o valor Nome do grupo de recursos - por exemplo, myResourceGroup.
2. Na etapa 5 para o nome do banco de dados, anote o valor Nome do banco de dados - por exemplo, mySampleDatabase.
3. Na etapa 6 para criar o servidor, use as seguintes etapas:
  1. Anote 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. Anote o valor de logon do administrador do servidor - por exemplo, azureuser.
  5. Anote o valor de 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 você 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.
  
  Observação
  
  Se a entrada falhar com 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 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.

Insira a seguinte consulta para criar um esquema para TLOG.

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 de sessão para seus clusters e aplicativos do WLS. Para obter mais informações, consulte Usando um armazenamento JDBC TLOG e Usando um banco de dados para armazenamento persistente (persistência JDBC).

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 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 novo servidor secundário e use as seguintes etapas:
  1. Insira e anote o nome do grupo de failover - por exemplo, failovergroupname-ejb120623.
  2. Insira e anote o nome exclusivo do servidor - por exemplo, sqlserversecondary-ejb120623.
  3. Insira 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 a opção Permitir que os serviços do Azure acessem o servidor esteja 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 do WLS posteriormente.

Configurar clusters WLS emparelhados 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 é primário e é configurado como o cluster ativo posteriormente. O cluster no oeste dos EUA é secundário e é configurado como o cluster passivo posteriormente.

Configurar o cluster WLS primário

Primeiro, abra a oferta Oracle WebLogic Server Cluster em VMs do Azure em 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 :

Verifique se o valor mostrado para Assinatura é 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, forneça uma senha para a conta de administrador da VM e do WebLogic Administrator, respectivamente. Anote o nome de usuário e a senha do WebLogic Administrator.
Deixe os padrões para outros campos.
Selecione Avançar para ir para o painel Configuração TLS/SSL.

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

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

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

Selecione Editar rede virtual. Anote 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, anote o endereço inicial e o tamanho da sub-rede - por exemplo, 10.1.5.0 e /28.
Se você fizer modificações, salve as alterações.
Retorne ao painel Rede .
Selecione Avançar para ir para o painel Banco de Dados .

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

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

Depois de um tempo, você verá a página Implantação onde a Implantação está em andamento é exibida.

Observação

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

Dependendo das condições de rede e de outras atividades na região selecionada, a implantação pode levar até 50 minutos para ser concluída. Depois disso, você verá o texto Sua implantação 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 da 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, use 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-westtus-ejb120623.
2. Em Detalhes da instância, em Região, selecione Oeste dos EUA.
No painel Rede, use as seguintes etapas:
1. Para Editar rede virtual, insira o mesmo espaço de endereço da rede virtual que o cluster WLS primário - por exemplo, 10.1.4.0/23.
  
  Observação
  
  Você verá uma mensagem de aviso semelhante à seguinte: 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'. Redes virtuais com espaço de endereçamento sobreposto não podem ser emparelhadas. Se você pretende emparelhar 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. Para wls-subnet, insira o mesmo endereço inicial e tamanho de sub-rede que o cluster WLS primário - por exemplo, 10.1.5.0 e /28.
No painel Banco de Dados, use as seguintes etapas:
1. Para DataSource Connection String, substitua os espaços reservados pelos valores que você anotou na seção anterior para o Banco de dados SQL secundário - por exemplo, jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433; banco de dados=mySampleDatabase.
2. Para Nome de usuário do banco de dados, substitua os espaços reservados pelos valores que você anotou da 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 com êxito na verificação, 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 após a conclusão de sua implantação:

No painel Visão geral da página Implantação, selecione Ir para o grupo de recursos.
Selecione a interface adminVM_NIC_with_pub_ipde rede .
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. Anote o endereço IP privado.
4. Selecione Salvar.
Retorne ao grupo de recursos do cluster WLS primário e repita a etapa 3 para as interfaces mspVM1_NIC_with_pub_ipde rede , mspVM2_NIC_with_pub_ipe 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 monitoramento de 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 a interface de rede restante - por exemplo, 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Selecione-o e siga as etapas anteriores para anotar seu endereço IP privado.

Em seguida, use as seguintes etapas para definir as configurações de rede para o cluster secundário após a conclusão de sua implantação:

No painel Visão geral da página Implantação, selecione Ir para o grupo de recursos.
Para as interfaces adminVM_NIC_with_pub_ipde rede , mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ipe 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 as interfaces mspVM1_NIC_with_pub_ipde rede , e mspVM3_NIC_with_pub_ip, siga as etapas anteriores, mspVM2_NIC_with_pub_ipmas atualize o endereço IP privado para o mesmo valor usado com o cluster primário. Aguarde até que a atualização atual da interface de rede seja concluída antes de prosseguir para a próxima.

Observação

Não é possível alterar o endereço IP privado da interface de rede que faz parte de um ponto de extremidade privado. Para espelhar facilmente os endereços IP privados das interfaces de rede para servidores gerenciados, considere atualizar o endereço IP privado para adminVM_NIC_with_pub_ip 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	Interface 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 para 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, use 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 o endereço IP privado atualizado e selecione Salvar. Aguarde até que ele seja concluído.
Na seção Configurações, selecione Testes de integridade e, em seguida, selecione HTTPhealthProbe.
Certifique-se de que Desejo testar a integridade do back-end antes de adicionar o teste de integridade está selecionado e selecione Testar. Você deve ver que o valor Status do pool myGatewayBackendPool de back-end está marcado como íntegro. Se não estiver, verifique se os endereços IP privados estão atualizados conforme o esperado e se as VMs estão em execução e, em seguida, teste o teste de integridade novamente. Você deve solucionar e resolver o problema antes de continuar.

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

Cluster	Pool de back-end do Gateway de Aplicativo do Azure	Destinos de back-end (antes)	Alvos 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, considere usar 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 do WLS em cada cluster. O Gateway de Aplicativo do Azure atua como balanceador de carga para todos os servidores gerenciados no cluster. O servidor de administração do WLS fornece um console da Web para configuração de cluster.

Use 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. Anexe a cadeia de caracteres weblogic/ready e abra essa URL em uma nova guia do navegador. Você deve ver uma página vazia sem qualquer mensagem de erro. Se não o fizer, tem de resolver o problema antes de continuar.
Copie e anote 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ê anotou antes. Se não conseguir iniciar sessão, tem de resolver o problema antes de continuar.

Use as etapas a seguir para anotar o endereço IP do Gateway de Aplicativo do Azure para cada cluster. Use esses valores ao configurar o Gerenciador de Tráfego do Azure posteriormente.

Abra o grupo de recursos onde o cluster está implantado - por exemplo, selecione Visão geral para alternar de volta para o painel Visão geral da página de implantação. Em seguida, selecione Ir para o grupo de recursos.
Localize o recurso gwip com o tipo Endereço IP público e selecione-o para abri-lo. Procure o campo de endereço IP e anote 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 seguindo 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 à seção Criar um perfil do Gerenciador de Tráfego, use as seguintes etapas:
1. Na etapa 2 Criar perfil do Gerenciador de Tráfego, use as seguintes etapas:
  1. Anote o nome de perfil exclusivo do Gerenciador de Tráfego para Nome - por exemplo, tmprofile-ejb120623.
  2. Anote o novo nome do grupo de recursos para Grupo de recursos - por exemplo, myResourceGroupTM1.
Quando chegar à seção Adicionar pontos de extremidade do Gerenciador de Tráfego, use as seguintes etapas:
1. Execute esta ação adicional após a etapa Selecione o perfil nos resultados da pesquisa.
  1. Em Configurações, escolha Configuração.
  2. Para DNS time to live (TTL), digite 10.
  3. Em Configurações do monitor de ponto de extremidade, em Caminho, insira /weblogic/ready.
  4. Em Configurações rápidas de failover de ponto de extremidade, use os seguintes valores:
    - Para Sondagem interna, insira 10.
    - Em Número tolerado de falhas, insira 3.
    - Para o tempo limite da sonda, 5.
  5. Selecione Salvar. Aguarde até que ele 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 Gateway de Aplicativo implantado no cluster WLS Leste dos EUA que você anotou antes. Você deve ver uma entrada correspondida. Selecione-o para Endereço IP público.
3. Na etapa 6 para adicionar um ponto de extremidade secundário/failover 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 Gateway de Aplicativo implantado no cluster WLS do oeste dos EUA que você anotou antes. Você deve ver uma entrada correspondida. Selecione-o para Endereço IP público.
4. Aguarde um pouco. Selecione Atualizar até que o valor de status do Monitor para ambos os pontos de extremidade seja Online.
Quando você chegar à seção Testar perfil do Gerenciador de Tráfego, use as seguintes etapas:
1. Na subseção Verificar o nome DNS, use a seguinte etapa:
  1. Na etapa 3, anote 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ê deve ver uma página vazia sem qualquer mensagem de erro.
  2. Depois de concluir todas as etapas, certifique-se de habilitar o ponto de extremidade principal fazendo referência à etapa 2, mas substitua Desabilitado por Habilitado. Em seguida, retorne à página Pontos de extremidade .

Agora você tem os pontos de extremidade Habilitado 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 mais tarde.

Configurar os clusters do WLS para alta disponibilidade e recuperação de desastres

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

Preparar o aplicativo de exemplo

Nesta seção, você cria e empacota um aplicativo CRUD Java/JakartaEE de exemplo 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 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 aplicativo na mesma fonte jdbc/WebLogicCafeDBde dados.

Use as seguintes etapas para compilar e empacotar o exemplo:

Use os seguintes comandos para clonar o repositório de exemplo e confira 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 HEADo , é seguro ignorar.
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 êxito, você pode encontrá-lo em parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war.< Se você não vir o pacote, resolva o problema antes de continuar.

Implantar o aplicativo de exemplo

Agora use 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ê anotou antes.
Localize Domain structure>wlsd>Deployments no painel de navegação. Selecione Implantações.
Selecione Bloquear & Editar>Instalação>Carregue seu(s) arquivo(s)>Escolha Arquivo. Selecione o arquivo weblogic-café.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.
Alterne para a guia Controle e selecione weblogic-cafe na tabela de implantações. Selecione Iniciar com a opção Atendendo a todas as solicitações>Sim. Aguarde um pouco e atualize a página até ver que o estado da implantação weblogic-cafe é Ativo. Alterne para a guia Monitoramento e verifique se a raiz de contexto do aplicativo implantado é /weblogic-café. Mantenha o console de administração do WLS aberto para que você possa usá-lo mais tarde para configuração adicional.

Repita as mesmas 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

Use as etapas a seguir para tornar seus clusters WLS cientes do Gerenciador de Tráfego do Azure. Como o Gerenciador de Tráfego do Azure é o ponto de entrada para solicitações do 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 se você está conectado ao Console de Administração do WebLogic Server.
Navegue até Clusters de Ambiente>wlsd>de estrutura>de domínio no painel de navegação. Selecione Clusters.
Selecione cluster1 na tabela de clusters.
Selecione Bloquear & Editar>HTTP. Remova o valor atual do Host Front-end e insira o nome DNS do perfil do Gerenciador de Tráfego que você anotou antes, sem a entrelinha http:// - por exemplo, tmprofile-ejb120623.trafficmanager.net. Selecione Salvar>Ativar alterações.

Repita as mesmas 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 de log de transações

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

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

Verifique se você está conectado ao Console de Administração do WebLogic Server.
Navegue até Domain structure>wlsd>Environment>Servers no painel de navegação. Selecione Servidores.
Você deve ver servidores msp1, msp2e msp3 listados na tabela de servidores.
Selecione msp1>Bloqueio de Serviços>& Editar. Em Armazenamento de Log de Transações, selecione JDBC.
Em Tipo>de 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 mesmas etapas, exceto que o valor padrão para Nome do prefixo é TLOG_msp2_.
Selecione Servidores>msp3 e repita as mesmas etapas, exceto que o valor padrão para Nome do prefixo é TLOG_msp3_.
Selecione Ativar alterações.

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

Reinicie os servidores gerenciados do cluster primário

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

Verifique se você está conectado ao Console de Administração do WebLogic Server.
Navegue até Domain structure>wlsd>Environment>Servers no painel de navegação. Selecione Servidores.
Selecione a guia Controle . msp1Selecione , msp2e msp3. Selecione Desligar com a opção Quando o trabalho for concluído>Sim. Selecione o ícone de atualização. Aguarde até que o valor Status da Última Ação seja TAREFA CONCLUÍDA. Você deve ver que o valor de Estado para os servidores selecionados é SHUTDOWN. Selecione o ícone de atualização novamente para interromper o monitoramento de status.
Selecione msp1, msp2e msp3 novamente. Selecione Iniciar>Sim. Selecione o ícone de atualização. Aguarde até que o valor Status da Última Ação seja TAREFA CONCLUÍDA. Você verá que o valor de Estado para os servidores selecionados é RUNNING. Selecione o ícone de atualização novamente para interromper o monitoramento de status.

Pare as VMs no cluster secundário

Agora, use as seguintes etapas para parar 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 onde 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 entrada correspondida. Selecione-o para Valor. Escolha Aplicar. Você deve ver 4 VMs listadas, incluindo adminVM, mspVM1, mspVM2e mspVM3.
Selecione para abrir cada uma das VMs. Selecione Parar e confirmar para cada VM.
Selecione o ícone de notificações no portal do Azure para abrir o painel Notificações .
Monitore o evento Parando máquina virtual para cada VM até que o valor se torne Máquina virtual interrompida com êxito. Mantenha a página aberta para que você possa usá-la para o teste de failover mais tarde.

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

Observação

Uma solução HA/DR pronta para produção provavelmente desejaria obter um RTO mais baixo deixando as VMs em execução, mas apenas interrompendo o software WLS em execução nas VMs. Então, em caso de failover, as VMs já estariam em execução e o software WLS levaria menos tempo para iniciar. Este artigo optou por parar as VMs porque o software implantado pelo Oracle WebLogic Server Cluster 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 manipula todas as solicitações de usuário roteadas pelo seu 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, 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 e resolva o problema antes de continuar.

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

Testar failover do primário para o secundário

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

Failover para o site secundário

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

Localize o nome do grupo de recursos onde o cluster WLS primário está implantado - por exemplo, wls-cluster-eastus-ejb120623. Em seguida, 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 parar todas as VMs nesse cluster.
Alterne 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.
Alterne para a guia do navegador do aplicativo de exemplo e atualize a página. Você deve ver 504 Gateway Time-out ou 502 Bad Gateway porque nenhum dos endpoints está acessível.

Em seguida, use as seguintes etapas 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 grupo de failover do Banco de Dados SQL do Azure.
Selecione Failover>Sim.
Aguarde até que ele seja concluído.

Em seguida, use as seguintes etapas para iniciar todos os servidores no cluster secundário:

Alterne para a guia do navegador onde você parou todas as VMs no cluster secundário.
Selecione a VM adminVM. Selecione Iniciar.
Monitore o evento Iniciando a máquina virtual no adminVM painel Notificações e aguarde até que o valor se torne Máquina virtual iniciada.
Alterne 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 onde todas as VMs no cluster secundário estão listadas. Para as VMs mspVM1, mspVM2e mspVM3, selecione cada uma para abri-la e, em seguida, selecione Iniciar.
Para as VMs mspVM1, mspVM2e 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, use as seguintes etapas para verificar o aplicativo de exemplo depois que o ponto de extremidade myFailoverEndpoint estiver no estado Online :

Alterne 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 .
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.

Observação

Uma solução HA/DR pronta para produção seria responsável por copiar continuamente a configuração do WLS do cluster primário para o secundário 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

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

Primeiro, desligue as VMs no cluster secundário. Você deve ver que o ponto de extremidade myFailoverEndpoint se torna Degradado.
Em seguida, faça failover do Banco de Dados SQL do Azure do servidor secundário para o servidor primário.
Em seguida, 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 a usar os clusters do WLS e outros componentes, use as seguintes etapas para excluir os grupos de recursos para limpar os recursos usados neste tutorial:

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 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 de 1 a 4 para o grupo de recursos do Gerenciador de Tráfego - por exemplo, myResourceGroupTM1.
Repita as etapas de 1 a 4 para o grupo de recursos do cluster WLS primário - por exemplo, wls-cluster-eastus-ejb120623.
Repita as etapas de 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 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 fica em espera.

Continue a explorar as seguintes referências para obter mais opções para criar soluções 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

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