Configurar Clusters Esticados FMW

Configurar regiões

O modelo de cluster esticado do Oracle Fusion Middleware (FMW) é configurado em dois sites separados.

Na Oracle Cloud Infrastructure (OCI), você pode implementá-la em regiões da OCI que têm baixa latência entre elas. A latência máxima entre regiões suportada é de 10 ms de tempo de ida e volta (RTT). Você pode verificar a latência entre regiões na Console do OCI selecionando Rede, Centro de Comando de Rede e Latência entre regiões.

Considerando os valores de latência, você pode implantar esse modelo entre regiões como Frankfurt e Amsterdã, que têm 6-7 ms RTT. No entanto, não é possível implantar esse modelo entre locais como Ashburn e Phoenix, porque a latência entre essas regiões excede 50 ms RTT.

Exemplo de pares de regiões com latência entre regiões inferior a 10 ms RTT:

Amsterdã (AMS) - Paris (CDG)
Amesterdão (AMS) - Newport (CWL)
Amsterdã (AMS) - Frankfurt (FRA)
Amsterdã (AMS) - Londres (LHR)
Paris (CDG) - Frankfurt (FRA)
Paris (CDG) - Londres (LHR)
Paris (CDG) - Newport (CWL)
Marselha (MRS) - Milão (LIN)
Zurique (ZHR) - Frankfurt (FRA)
Zurique (ZHR) - Milão (LIN)
Osaka (KIX) - Tóquio (NRT)
Singapura (SIN) - Batan (HSG)
São Paulo (GRU) - Vinhedo (VCP)
Singapura (SIN) - Singapura 2 (XSP)
Batan (HSG) - Singapura 2 (XSP)
Seul (ICN) - Chuncheon (YNY)
Toronto (YYZ) - Montreal (YUL)

Em relação à largura de banda, não há uma largura de banda garantida entre as regiões da OCI, e a OCI não oferece uma ferramenta específica de medição de largura de banda da OCI. Para medições precisas da largura de banda, use ferramentas como iPerf. A largura de banda testada entre Frankfurt e Amsterdã é de cerca de 2 a 2,5 gigabits por segundo (Gbps).

Você também pode implementar esse modelo entre domínios de disponibilidade (ADs) que estão na mesma região. A implantação dos servidores do Oracle WebLogic Server em ADs é, na verdade, o comportamento padrão em serviços de plataforma como serviço (PaaS), como o Oracle SOA Suite on Marketplace e as pilhas do Oracle WebLogic Server for OCI. No entanto, implementar esse modelo em ADs em vez de em regiões não é realmente uma solução de proteção contra desastres, porque não protege contra eventos que afetam uma região inteira.

Dica:

Para criar as sub-redes, regras, instâncias de computação, armazenamento compartilhado e balanceadores de carga necessários para uma implantação de FMW em cada site, você pode usar a estrutura WLS-HYDR (consulte o procedimento "Criar infraestrutura").

Configurar a Rede

As redes virtuais na nuvem (VCNs) nas regiões em que você implanta essa topologia devem estar interconectadas para permitir o tráfego entre todos os servidores WebLogic no cluster e dos servidores WebLogic para os bancos de dados.

Os seguintes recursos de rede são necessários para a configuração:

Uma VCN e sub-redes em camadas em cada região.
Uma conexão de pareamento remoto entre as VCNs, com gateways de roteamento dinâmico (DRGs).
As regras de roteamento apropriadas para rotear o tráfego entre os sites. Na Região 1, as tabelas de roteamento devem incluir uma rota para o CIDR da VCN da Região 2 por meio do gateway de roteamento dinâmico. Da mesma forma, as tabelas de roteamento da Região 2 devem incluir uma rota para o CIDR da VCN da Região 1 por meio do gateway de roteamento dinâmico.
As regras de segurança de rede para permitir a seguinte comunicação para o cluster esticado:
- Abra as portas WebLogic Server e Gerenciador de Nós entre as sub-redes de camada intermediária da região 1 e da região 2. Se o Coherence for usado, permita o tráfego TCP e UDP para as portas do Coherence também.
- Permita o tráfego para o listener de banco de dados e as portas do Oracle Cloud Infrastructure Notifications (ONS) em ambas as regiões das sub-redes de camada intermediária da região 1 e da região 2.
- Por padrão, não há necessidade de comunicação entre regiões entre os servidores OHS e WebLogic. As portas do WebLogic Server na sub-rede de camada intermediária só devem estar acessíveis por servidores OHS dentro da mesma região. No entanto, a comunicação entre regiões pode ser necessária em circunstâncias excepcionais, como se todos os servidores da Web em uma região falhassem. Mais detalhes são fornecidos na seção Gerenciando Falhas.
Todos os nomes de host usados pelo sistema (endereços de listening WebLogic e os endereços SCAN e VIP do banco de dados principal e stand-by) devem ser resolvidos de ambos os sites. Por padrão, no OCI, os nomes de host só podem ser resolvidos dentro de cada VCN. Para permitir que os nomes da região 1 sejam resolvidos na região 2, crie uma view de DNS privada na região 2 para o domínio da região 1 e adicione os nomes e endereços IP relevantes. Repita esse processo na região 1 para resolver nomes da região 2.
Em cada site, o nome do front-end do sistema (como frontend.example.com) deve apontar para o endereço IP do balanceador de carga local. Para isso, adicione o nome do front-end a uma view de DNS privada em cada região ou ao arquivo /etc/hosts dos hosts de camada intermediária. Isso garante que qualquer retorno de chamada de um servidor WebLogic para o front-end seja direcionado para a região local.

Configurar o Banco de Dados

Configure um sistema de banco de dados Oracle Real Application Clusters (Oracle RAC) na região 1 com um sistema de banco de dados RAC stand-by na região 2.

É importante usar RAC dentro de cada região porque a alta disponibilidade local é um requisito fundamental. A configuração do domínio de disponibilidade cruzada (AD) ou da proteção entre regiões só será eficaz se já houver proteção confiável contra falhas locais em uma única região. Se a alta disponibilidade local, como a fornecida pelo RAC, não for implementada, a adição de proteção em vários ADs ou regiões não abordará o risco de falhas no ambiente local.

Para manter o aplicativo conectado e receber notificações do Oracle Notification Service em caso de falhas no nó ou na instância do banco de dados RAC, certifique-se de que seu aplicativo se conecte ao banco de dados plugável (PDB) usando um serviço de banco de dados CRS (Cluster Ready Services). O mesmo serviço CRS deve existir no principal e no stand-by. Exemplos de comandos para criar um serviço para estabelecer conexão com o PDB:


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

Configurar Armazenamento Compartilhado

O Oracle Cloud Infrastructure File Storage é um serviço de sistema de arquivos totalmente gerenciado, escalável e seguro fornecido pela OCI. Ele foi projetado para fornecer armazenamento de arquivos de alto desempenho para aplicativos empresariais que exigem sistemas de arquivos compartilhados e persistentes.

Várias instâncias de computação podem montar e acessar o mesmo sistema de arquivos simultaneamente por meio do protocolo NFS (Network File System).

O modelo de cluster esticado do Oracle Fusion Middleware (FMW) na OCI usa sistemas OCI File Storage em cada região para os sistemas de arquivos compartilhados (por exemplo, para configuração compartilhada ou para dados de runtime compartilhados). O OCI File Storage fornece alta disponibilidade na região: ele usa internamente armazenamento redundante em vários domínios de falha dentro de um domínio de disponibilidade. No entanto, o OCI File Storage não pode ser acessado entre regiões. Portanto, o armazenamento compartilhado é local para a região.

Use backups locais e réplicas do sistema de arquivos entre regiões para fornecer uma cópia recuperável dos artefatos.

Configurar camada intermediária

Os nós de computação de camada intermediária são distribuídos entre as duas regiões.

Os nós de computação de camada intermediária são distribuídos entre as duas regiões, com metade dos nós localizados na região 1 e a outra metade na região 2. O processo de provisionamento e instalação é igual ao da criação de um único domínio WebLogic. Para implementar os recursos de alta disponibilidade (como Java Message Service (JMS) e migração de serviço Java Transaction API (JTA), failover do Administration Server, detecção automática de falhas com o Gerenciador de Nós etc.) use as melhores práticas recomendadas nos Guias de Implantação do FMW Enterprise referenciados na seção Explorar Mais.

Você pode criar o domínio e configurá-lo com todos os servidores gerenciados desde o início ou pode expandir um domínio existente executado em uma única região adicionando nós na outra região.

Observação:

O modelo de cluster esticado do Oracle Fusion Middleware (FMW) pode ser aplicado a domínios criados usando serviços de plataforma como serviço (PaaS), como Oracle WebLogic Server for OCI e pilhas do Oracle SOA Suite on Marketplace. Os recursos de provisionamento e expansão desses serviços PaaS suportam apenas uma única região por padrão; portanto, você precisa expandir manualmente o cluster para adicionar nós em outra região. Consulte os procedimentos para expandir um cluster WLS para obter as etapas necessárias para executar esta operação. Observe que esses serviços PaaS não incluem uma camada Web e não implementam determinadas melhores práticas de alta disponibilidade, como failover do Servidor de Administração. Portanto, algumas das recomendações deste documento podem não se aplicar a esses ambientes.

Estes são os aspectos mais relevantes a serem implementados na configuração WebLogic ao usar o modelo de cluster esticado FMW:

Usar armazenamentos persistentes do banco de dados
A Oracle suporta clusters stretch que usam armazenamentos persistentes de banco de dados para logs de transação do Oracle WebLogic Server e JMS. O armazenamento dos logs de transação e dos dados persistentes no banco de dados aproveita os recursos integrados de replicação e alta disponibilidade do banco de dados, como Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard. Com JMS, logs de transação (TLOGs) e metadados em um banco de dados protegido pelo Data Guard, a sincronização entre sites é simplificada e a consistência no nível do aplicativo é garantida. Isso também significa que a camada intermediária não precisa mais de armazenamento compartilhado para esses artefatos (embora ainda precise dele para failover do Servidor de Administração, planos de implantação e alguns adaptadores, como o Adaptador de Arquivos).

No entanto, o uso de TLOGs e JMS no banco de dados tem uma penalidade no desempenho do sistema. Essa penalidade é aumentada quando uma das camadas intermediárias precisa se comunicar com o banco de dados no outro site. Do ponto de vista do desempenho, um armazenamento compartilhado que seja local para cada site teria melhor desempenho, mas isso introduz complexidade e limitações para garantir zero perda de dados entre regiões e consistência de aplicativos.
Artefatos do sistema de arquivos compartilhados locais para cada região
Conforme indicado nos Guias de Implantação do Oracle Fusion Middleware Enterprise, o diretório de domínio do Servidor de Administração (ASERVER_HOME) deve residir no armazenamento compartilhado, separado da pasta de domínio do servidor gerenciado (MSERVER_HOME). Isso, juntamente com o uso de um nome de host virtual para o endereço de listening do Servidor de Administração, permite que o Servidor de Administração faça failover para outro host, dentro da mesma região ou em outra.

Outros artefatos que residem em sistemas de arquivos compartilhados são as instalações do Oracle home (binários), os planos de implantação e os diretórios do adaptador de arquivos (pasta de runtime).

Em uma topologia de cluster esticada FMW, cada região utiliza seu próprio armazenamento compartilhado local. Consequentemente, a segunda região mantém seus próprios binários redundantes (garantindo pelo menos duas instalações binárias por site para alta disponibilidade) e seus próprios diretórios compartilhados para configuração compartilhada, planos de implantação, arquivos de runtime e muito mais. Todos esses artefatos devem usar caminhos idênticos em ambas as regiões para garantir consistência e failover contínuo.
Usar um algoritmo baseado em afinidade para o cluster WebLogic
Para minimizar o tráfego entre sites, use a afinidade local para a resolução de fábrica de contexto JNDI (Java Naming and Directory Interface). Para definir o Algoritmo de Carga Padrão do Cluster WebLogic como um algoritmo baseado em afinidade:
1. Vá para Editar Árvore na WebLogic Console Remota.
2. Vá para Ambiente, selecione Clusters e selecione o cluster.
3. Na guia Geral, defina o Algoritmo de Carga Padrão do Cluster WebLogic para afinidade round-robin (o padrão é round-robin) ou para qualquer algoritmo "baseado em afinidade".
O Endereço do Cluster não precisa ser definido com a lista explícita de todos os servidores no cluster. Quando estiver vazio, o valor de Endereço do Cluster será gerado automaticamente. Apenas certifique-se de que a propriedade Número de Servidores em Endereço do Cluster, que limita o número de servidores a serem listados ao gerar o endereço do cluster automaticamente, tenha um valor alto o suficiente para incluir todos os servidores no cluster.
Usar configuração de Migração Automática de Serviço
A Oracle recomenda configurar o Automatic Service Migration com armazenamentos persistentes do Java Database Connectivity (JDBC) para topologias de implantação empresarial. Em uma topologia de cluster esticada por FMW, a Migração Automática de Serviço é possível dentro e também entre regiões, desde que os dados JMS e TLOGs estejam acessíveis de ambos os sites. Ao usar armazenamentos persistentes JDBC, nenhuma consideração especial é necessária para configurar o ASM em um cluster esticado.

O tempo gasto para uma operação de migração de serviço da região 1 para a região 2 pode aumentar quando há alta latência entre sites. Esse aumento é causado pelo tempo gasto na recuperação das mensagens no outro servidor, porque elas são lidas do armazenamento persistente no banco de dados na outra região. Essa latência aumenta com o número de mensagens pendentes nos armazenamentos persistentes. No entanto, a penalidade só se torna relevante com latências muito altas ou com um grande número de mensagens pendentes. Consulte a seção "Revisar Dados de Desempenho" para obter detalhes sobre os comportamentos esperados.
Nome e resolução do host front-end
Ao configurar o host front-end do cluster WebLogic, especifique o nome do host virtual que os clientes usam para acessar o sistema, como em qualquer implantação padrão. Os clientes devem resolver esse nome de host virtual para um endereço externo balanceado entre as instâncias do OCI Load Balancer na Região 1 e na Região 2. Consulte "Sobre o Balanceamento de Carga Global".

Para garantir que os servidores WebLogic em cada região roteiem apenas chamadas internas para seu respectivo OCI Load Balancer local, configure os servidores para resolver o nome do host front-end para o endereço IP do OCI Load Balancer dentro de sua região. Isso pode ser obtido adicionando uma entrada ao arquivo /etc/hosts em cada host de servidor WebLogic ou adicionando-os a uma view privada de DNS em cada região:

Para servidores na Região 1:
```
[IP address of Region 1 OCI Load Balancer] [frontend hostname]
```
Para servidores na Região 2:
```
[IP address of Region 2 OCI Load Balancer] [frontend hostname]
```
Essa configuração garante que as comunicações internas dos servidores WebLogic sejam direcionadas ao balanceador de carga regional apropriado, otimizando o roteamento e o desempenho.

Configurar Origens de Dados WebLogic

Use origens de dados GridLink com uma string de conexão dupla em todas as origens de dados WebLogic (para os metadados do Oracle Fusion Middleware (FMW), armazenamentos persistentes de banco de dados, tabelas de leasing, Adaptador de BD etc.) para automatizar o failover do banco de dados. Eles devem se reconectar automaticamente quando houver uma falha ou um shutdown em um dos nós do Oracle Real Application Clusters (Oracle RAC), mas também quando houver um switchover completo do banco de dados para a outra região. Para isso, aplique estas recomendações:

Usar Origens GridLink de Dados
As fontes de dados GridLink utilizam o Oracle Notification Service (ONS) para detectar e responder rapidamente a falhas de nó de banco de dados ou interrupções de rede, melhorando a disponibilidade e a resiliência do aplicativo. Eles distribuem automaticamente as conexões de banco de dados com base em informações de carga de trabalho em tempo real, otimizando o desempenho e o uso de recursos em todos os nós RAC. As alterações na topologia do banco de dados (como adicionar ou remover nós RAC) são reconhecidas e tratadas automaticamente, reduzindo a sobrecarga administrativa e minimizando o tempo de inatividade.

Não é necessário especificar manualmente o host e a porta do ONS na configuração da origem de dados GridLink. A lista ONS é fornecida automaticamente pelo banco de dados ao driver, que recupera as informações do ONS para os bancos de dados principal e stand-by, facilitando as conexões com ambos.
Usar um alias TNS
Na string de conexão das origens de dados, use um alias TNS que aponte para uma entrada no arquivo tnsnames.ora, que inclui endereços SCAN principais e stand-by. O formato de string de conexão recomendado é o seguinte, com uma descrição e duas listas de endereços, uma por banco de dados RAC:
```
PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)
```
Para obter mais detalhes sobre como configurar o alias TNS nas origens de dados e nos arquivos de configuração FMW, consulte Using TNS Alias in Connect Strings no Enterprise Deployment Guide for Oracle SOA Suite.
Usar a opção Testar Conexões na Reserva
Certifique-se de que a opção Testar Conexões na Reserva esteja ativada para todas as origens de dados. Isso é especialmente importante para origens de dados usadas para acessar armazenamentos persistentes, porque os armazenamentos persistentes são críticos no estado geral dos servidores WebLogic. Esse flag permite que o Servidor WebLogic teste uma conexão antes de fornecê-la ao aplicativo.

Para Testar Nome da Tabela, use o valor padrão SQL ISVALID. Este é um teste rápido e eficiente, pois realiza uma validação leve para determinar se a conexão do banco de dados ainda está ativa, sem exigir acesso a uma tabela física específica.
Ajustar a capacidade inicial
Quando um servidor WebLogic é iniciado, um tempo considerável é dedicado à criação das conexões iniciais para os pools de origem de dados. Diferentes atrasos são esperados de acordo com as configurações de capacidade inicial nas origens de dados. Por padrão, a maioria das origens de dados FMW usa uma capacidade inicial zero para seu pool de conexões. No entanto, para reduzir o tempo de resposta do sistema durante a operação normal de tempo de execução, pode ser benéfico aumentar a capacidade inicial do pool.
Como a capacidade inicial é configurada no nível da origem de dados (pool de conexões), essas definições influenciam o tempo de inicialização de todos os servidores dentro do cluster (os locais para o banco de dados e os remotos para ele). Em um cluster esticado FMW, os servidores que residem remotamente no Banco de Dados mostrarão maior latência no início, à medida que a capacidade inicial do pool for usada (consulte "Tempo de Início da Revisão"). Portanto, é necessária uma decisão equilibrada entre a otimização dos tempos de resposta durante a operação normal e a minimização do horário de início para determinar as configurações ideais de capacidade inicial.
Ajustar a capacidade máxima
O número de conexões de origem de dados ativas aumenta com maior latência para o banco de dados. Nos testes realizados, os servidores na região remota mostram até 2x conexões ativas do que o servidor colocado no banco de dados (consulte "Revisar Testes de Estresse"). Monitore o uso no seu aplicativo e considere isso para um dimensionamento correto das origens de dados e sessões de banco de dados WebLogic.

Configurar Servidores Web

Se o sistema usar uma camada Web com instâncias do Oracle HTTP Server, cada região deverá ter pelo menos dois servidores para fornecer alta disponibilidade dentro da região.

Para reduzir o tráfego entre regiões, não use uma configuração de lista de servidores dinâmicos nas seções de roteamento do Oracle WebLogic Server. Em vez disso, configure uma lista estática dos servidores, definindo o parâmetro DynamicServerList como OFF. Isso tem a advertência de detecção de falha mais lenta: quando um servidor WebLogic falha, o servidor HTTP leva mais tempo para detectar a falha do que com uma lista dinâmica. Além disso, é necessário atualizar a configuração se novos servidores forem adicionados. No entanto, melhora o desempenho do sistema.

Os trechos a seguir dos arquivos mod_wl_ohs.conf no Oracle HTTP Server fornecem um exemplo da configuração necessária para o roteamento para o aplicativo web soa-infra.

Na região 1:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

Na região 2:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

Configurar Balanceadores de Carga

Cada região deve ter seu próprio balanceador de carga para distribuir solicitações entre os servidores desse site.

Configure o listener em ambas as regiões com o mesmo certificado SSL em cada balanceador de carga. Configure os servidores de back-end para que o balanceador de carga na região 1 inclua as instâncias do Oracle HTTP Server (OHS) da região 1 (se o sistema não usar servidores Web, os servidores com backup serão o WebLogicservidores da região 1), e o balanceador de carga na região 2 inclui os servidores OHS da região 2 (se o sistema não usar servidores Web, os servidores de back-end serão os servidores WebLogic da região 2).

Configure verificações de integridade para determinar a disponibilidade dos servidores de back-end, usando um URL que reflita com precisão o status do aplicativo. Isso impede que o tráfego seja roteado para um servidor em que o Oracle WebLogic Server esteja em execução, mas o aplicativo em si esteja indisponível, o que pode acontecer se a verificação de integridade atingir apenas o contexto raiz (/). No entanto, evite usar verificações de integridade com uso intensivo de recursos, pois verificações pesadas frequentes podem sobrecarregar os servidores com backup. Por exemplo, para o Oracle SOA, o URL de verificação de integridade recomendado é /soa-infra/services/isSoaServerReady .

Sobre o Balanceamento de Carga Global

O modelo de cluster esticado do Oracle Fusion Middleware (FMW) precisa de um elemento no topo do balanceador de carga de cada data center para equilibrar as solicitações do cliente entre as duas regiões.

Em implementações on-premises, isso é tradicionalmente implementado com um balanceador de carga global, que é responsável pelo roteamento inteligente, geralmente baseado nos endereços IP da origem. Esse balanceador de carga global geralmente está localizado em um dos sites, com um backup no outro site para failover.

No Oracle Cloud Infrastructure (OCI), não há um serviço de balanceador de carga global dedicado. Você pode, no entanto, obter a funcionalidade de balanceamento de carga global usando políticas de gerenciamento de tráfego.

Usar o OCI Traffic Management Steering Policies como um Balanceador de Carga Global

Use políticas de orientação de gerenciamento de tráfego do OCI (Oracle Cloud Infrastructure) para balancear a carga do tráfego do cliente entre os dois sites.

As políticas de direção do gerenciamento de tráfego oferecem respostas inteligentes às consultas do sistema de nomes de domínio (DNS), o que significa que diferentes respostas podem ser fornecidas para a consulta, dependendo da lógica definida na política. Há vários tipos de política:

Política do balanceador de carga
As políticas do Balanceador de Carga distribuem o tráfego entre muitos pontos finais. Podem ser atribuídos pontos finais com pesos iguais para distribuir tráfego uniformemente entre os pontos finais ou pesos personalizados para balanceamento da carga de proporção. Os monitores e sondagens sob demanda do Oracle Cloud Infrastructure Health Checks são aproveitados para avaliar a integridade do ponto final. Se um ponto final não estiver íntegro, o tráfego de DNS será distribuído automaticamente para os outros pontos finais.
Política de failover
As políticas de failover permitirão que você priorize a ordem na qual deseja que as respostas sejam atendidas em uma política (por exemplo, principal e secundária). Os monitores e sondagens sob demanda do OCI Health Checks são aproveitados para avaliar a integridade das respostas na política. Se a resposta principal não for íntegra, o tráfego DNS será direcionado automaticamente para a resposta secundária.
Política de orientação de geolocalização
As políticas de orientação de geolocalização distribuem o tráfego de DNS para diversos pontos finais com base na localização do usuário final. Os clientes podem definir regiões geográficas compostas de continente de origem, países ou estados/províncias (América do Sul) e definir um ponto final ou conjunto de pontos finais separados para cada região.
Política de orientação do ASN
As políticas da direção do ASN permitem que você oriente o tráfego de DNS com base nos números de sistema autônomo (ASN). As consultas de DNS originárias de um ASN específico ou de um conjunto de ASNs podem ser direcionadas para um ponto final especificado.
Política de orientação de prefixo IP
As políticas de orientação de Prefixo IP permitem que os clientes direcionem o tráfego de DNS com base no Prefixo IP da consulta de origem.

Escolha a política que melhor atenda às suas necessidades. As opções mais adequadas para uma implantação de cluster esticada são a política de orientação de geolocalização e a política de orientação de prefixo IP. A política de failover é adequada para serviços executados apenas em um dos sites, como a WebLogic Console Remoto.

Independentemente do tipo de política, você deve definir um OCI Health Checks para verificar a disponibilidade do site. Isso evita o tráfego que chega a um site onde os servidores são interrompidos ou o aplicativo não está disponível. Certifique-se de permitir o tráfego de entrada dos pontos de vantagem que executam a verificação de integridade para as portas do OCI Load Balancer que você está verificando.

O diagrama a seguir mostra o balanceamento de carga global com as políticas de direção do gerenciamento de tráfego da OCI.

Veja a seguir a descrição da instrução-policies.png do balanceador de carga global

Descrição da ilustração global-load-balancer-steering-policies.png

global-load-balancer-steering-policies-oracle.zip

Ao usar as políticas de direção do gerenciamento de tráfego do OCI para emular um balanceador de carga global:

Tempo de reação de failover
O tempo de resposta a uma falha do site depende dos intervalos de verificação de integridade (que determinam a rapidez com que um site é marcado como indisponível) e do valor de tempo de vida do registro DNS (TTL). Mesmo depois que um site é sinalizado como indisponível e o tráfego é direcionado para outro local, os clientes não receberão o endereço IP atualizado até que o DNS TTL anterior expire em seu cache local. Para minimizar atrasos de failover, é recomendável definir um valor de TTL de política baixo.
Limite de persistência de sessão
Como o balanceamento de carga com essas políticas depende dos valores de resposta do DNS, não há mecanismo incorporado para persistência de sessão. Como resultado, ao usar uma política de balanceador de carga aleatória ou simples, a resposta de DNS fornecida aos clientes pode mudar a qualquer momento, afetando potencialmente as sessões do aplicativo que exigem persistência. Se seu aplicativo exigir sessões persistentes, certifique-se de que todas as localizações possíveis do cliente sejam definidas explicitamente dentro de regras baseadas em geolocalização e evite o uso de algoritmos de direção aleatórios ou do balanceador de carga.

Veja a seguir um exemplo de configuração das políticas de orientação do gerenciamento de tráfego da OCI para um sistema de cluster esticado do Oracle Fusion Middleware (FMW) implantado nas regiões de Frankfurt e Amsterdã, com três front-ends: um para o Oracle SOA, um para o OSB e outro para a WebLogic Console Remota. O IP do balanceador de carga (LBR) em Frankfurt é 111.111.111.111 e o IP do LBR em Amsterdã é 222.222.222.222. Neste exemplo, as políticas de orientação definem as seguintes regras:

Para front-ends SOA e OSB, os clientes da Alemanha, Europa, Ásia e América do Sul receberão do DNS o IP do balanceador de carga Frankfurt como a resposta principal.
Para os front-ends SOA e OSB, os clientes da Holanda, África, Oceania e América do Norte receberão do DNS o IP do balanceador de carga de Amsterdã como a resposta principal.
Para quaisquer outros clientes (que não são esperados, uma vez que todas as regiões estão incluídas nas regras de geolocalização), o DNS retornará uma resposta padrão para que eles sejam redirecionados para Frankfurt.
As verificações de integridade do OCI são definidas para cada front-end; portanto, se a instância principal for marcada como indisponível, o tráfego será direcionado para o registro de IP alternativo.
O front-end WebLogic Remote Console usa um modelo de failover. O DNS retorna o IP do balanceador de carga Frankfurt para todos os clientes. Quando a verificação de integridade falha em Frankfurt, o DNS retorna o IP do balanceador de carga de Amsterdã.

Estas são as políticas de direção do gerenciamento de tráfego do OCI definidas:

Uma política de direção de geolocalização para acessar o front-end SOA.

Item de configuração	Valores de Exemplo
Nome da Política	strecthed_cluster_steering_policy-SOA
Modelo	Orientação de geolocalização
TTL da Política	60s
Resposta Pool1 (Frankfurt_Pool)	Nome: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Pool de Respostas 2 (Amsterdam_Pool)	Nome: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Regra de Orientação da Geolocalização 1	Geolocalização: Alemanha, Europa, Ásia, América do Sul Prioridade do pool 1: Frankfurt_Pool Prioridade do pool 2: Amsterdam_Pool
Regra de Orientação da Geolocalização 2	Geolocalização: Países Baixos, África, Oceania, América do Norte Prioridade do pool 1: Amsterdam_Pool Prioridade do pool 2: Frankfurt_Pool
Catch-all Global	Resposta Pool1 (Frankfurt_Pool)
Anexar verificação de integridade	Tipo de Solicitação: HTTP Verificação de integridade: `SOA_IS_ALIVE` (HTTPS)
Domínios Anexados	soafrontend.example.com

Uma política de direção de geolocalização para acessar o front-end do OSB.

Item de configuração	Valores de Exemplo
Nome da Política	strecthed_cluster_steering_policy-OSB
Modelo	Orientação de geolocalização
TTL da Política	60s
Pool de Respostas 1(Frankfurt_Pool)	Nome: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Pool de Respostas 2 (Amsterdam_Pool)	Nome: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Regra de Orientação da Geolocalização 1	Geolocalização: Alemanha, Europa, Ásia, América do Sul Prioridade do pool 1: Frankfurt_Pool Prioridade do pool 2: Amsterdam_Pool
Regra de Orientação da Geolocalização 2	Geolocalização: Países Baixos, África, Oceania, América do Norte Prioridade do pool 1: Amsterdam_Pool Prioridade do pool 2: Frankfurt_Pool
Catch-all Global	Resposta Pool1 (Frankfurt_Pool)
Anexar verificação de integridade	Tipo de Solicitação: HTTP Verificação de integridade: `OSB_IS_ALIVE` (HTTPS)
Domínios Anexados	osbfrontend.example.com

Uma política de failover é usada para acessar a WebLogic Remote Console. Durante a operação normal, o servidor de Administração é executado somente em um dos sites (Frankfurt, neste caso). Somente em caso de falha do site, ele é iniciado no outro site. Portanto, o acesso à WebLogic Console Remota e ao EM é controlado por uma política de failover.

Item de configuração	Valores de Exemplo
Nome da Política	strecthed_cluster_steering_policy-ADMINISTRAÇÃO
Modelo	Fazer Failover
TTL da Política	60s
Resposta Pool1 (Frankfurt_Pool)	Nome: Frankfurt_LBR_IP Tipo: A RDATA: 111.111.111.111
Pool de Respostas 2 (Amsterdam_Pool)	Nome: Amsterdam_LBR_IP Tipo: A RDATA: 222.222.222.222
Prioridade do Pool 1	Frankfurt_Pool
Prioridade do Pool 2	Amsterdam_Pool
Anexar verificação de integridade	Tipo de Solicitação: HTTP Verificação de integridade: `EM_IS_ALIVE` (HTTPS)
Domínios Anexados	admin.example.com

Esta é a configuração das Verificações de Integridade do OCI usadas por cada política de orientação de DNS:

Verificação de integridade do front-end SOA. O SOA fornece uma página simples para verificar o status SOA, no caminho /soa-infra/services/isSoaServerReady. Portanto, essa verificação de integridade executa uma solicitação HEAD com HTTPS para esse caminho para verificar se o aplicativo SOA está disponível. O cabeçalho host é necessário para especificar o nome do front-end que você deseja testar (neste exemplo, soafrontend.example.com) ao usar hosts virtuais nomeados nos servidores Web e balanceadores de carga.

Item de configuração	Valores de Exemplo
Nome da verificação de integridade	SOA_IS_ALIVE
Alvos	111.111.111.111 (IP LBR de Frankfurt) 222.222.222.222 (IP LBR de Amsterdã)
Pontos de vantagem	Microsoft Azure Norte da Europa Google Leste dos EUA
Tipo	HTTP
Protocolo	HTTPS
Porta	443
Caminho	`/soa-infra/services/isSoaServerReady`
Cabeçalhos	Host: soafrontend.example.com:443
Método	HEAD
Interval	30 segundos
Localização	10 segundos

Verificação de integridade do front-end OSB. O OSB não implementa um URL de integridade para seus serviços. Alguns dos URLs normalmente usados para verificar o status do OSB (como /sbinspection.wsil) exigem autenticação, e o serviço OCI Health Checks não suporta o cabeçalho authorization. Portanto, para verificar o status do OSB, implante um serviço de proxy REST personalizado simples. Este OCI Health Checks executa uma solicitação HEAD para esse ponto final por HTTPS. O cabeçalho host é necessário para especificar o nome do front-end que você deseja testar (neste exemplo, osbfrontend.example.com) ao usar hosts virtuais nomeados nos servidores Web e balanceadores de carga.

Item de configuração	Valores de Exemplo
Nome da verificação de integridade	OSB_IS_ALIVE
Alvos	111.111.111.111 (IP LBR de Frankfurt) 222.222.222.222 (IP LBR de Amsterdã)
Pontos de vantagem	Microsoft Azure Norte da Europa Google Leste dos EUA
Tipo	HTTP
Protocolo	HTTPS
Porta	443
Caminho	/`default/isOSBReadySample`
Cabeçalhos	Host: osbfrontend.example.com:443
Método	HEAD
Interval	30 segundos
Localização	10 segundos

Verificação de integridade do front-end EM_IS_ALIVE da Console Remota WebLogic.

O serviço OCI Health Checks executa uma solicitação HEAD com HTTPS no caminho /em/faces/targetauth/emasLogin para verificar o status da Console do FMW Control.

Item de configuração	Valores de Exemplo
Nome da verificação de integridade	SOA_IS_ALIVE
Alvos	111.111.111.111 (IP LBR de Frankfurt) 222.222.222.222 (IP LBR de Amsterdã)
Pontos de vantagem	Microsoft Azure Norte da Europa Google Leste dos EUA
Tipo	HTTP
Protocolo	HTTPS
Porta	443
Caminho	`/em/faces/targetauth/emasLogin`
Cabeçalhos	Host: admin.example.com:445
Método	HEAD
Interval	30 segundos
Localização	10 segundos

Usar um Balanceador de Carga Global de Terceiros

Como alternativa às políticas de orientação de gerenciamento de tráfego do Oracle Cloud Infrastructure (OCI), você pode usar um GLBR (balanceador de carga global) de terceiros.

Será responsável por executar o roteamento inteligente das solicitações entre os balanceadores de carga locais.

O GLBR é um balanceador de carga configurado para ser acessível como um endereço pelos usuários de todos os sites e locais externos. O dispositivo fornece um servidor virtual que é mapeado para um nome de sistema de nomes de domínio (DNS) que é acessível a qualquer cliente, independentemente do site ao qual ele se conectará.

O GLBR direciona o tráfego para qualquer local com base em critérios e regras configurados. Esses critérios podem ser baseados no IP do cliente, por exemplo. Isso deve ser usado para criar um perfil de persistência que permita ao GLBR mapear usuários para o mesmo site mediante solicitações iniciais e subsequentes. O GLBR mantém um pool que consiste nos endereços de todos os balanceadores de carga locais. Em caso de falha de um dos sites, os usuários são automaticamente redirecionados para o site ativo sobrevivente.

Em cada site, um balanceador de carga local recebe a solicitação do GLBR e direciona as solicitações para o servidor HTTP apropriado. Para eliminar roteamentos indesejados, o GLBR também é configurado com regras específicas que roteiam retornos de chamada apenas para o LBR que é local para os servidores que os geraram. Por exemplo, isso é útil para consumidores internos de serviços do Oracle SOA. Essas regras GLBR podem ser resumidas da seguinte forma:

Se as solicitações forem provenientes do site1 (por exemplo, solicitações originadas dos servidores WebLogic no local 1), o GLBR será roteado para o LBR em site1.
Se as solicitações forem provenientes do site2 (por exemplo, solicitações originadas dos servidores WebLogic no local 2), o GLBR será roteado para o LBR em site2.
Se as solicitações forem provenientes de qualquer outro endereço (chamadas de cliente), o carregamento GLBR equilibra as conexões com ambos os LBRs.
Regras de encaminhamento adicionais podem ser definidas no GLBR para encaminhar clientes específicos para locais específicos (por exemplo, os dois locais podem fornecer tempos de resposta diferentes com base nos recursos de hardware em cada caso).

Configurar Outros Recursos

As duas regiões podem usar recursos externos, como LDAP, armazenamentos de identidades, armazenamentos de políticas, destinos JMS (jave java message service) externos, web services externos, Oracle Cloud Infrastructure Object Storage etc.

Os detalhes de configuração desses recursos externos estão fora do escopo deste documento. No entanto, é necessário que esses recursos sejam consistentes em ambas as regiões para fornecer um comportamento uniforme.

Por exemplo, no Oracle SOA, os callbacks assíncronos podem reidratar instâncias que foram iniciadas em outra região. Da mesma forma, no caso de recuperação automática, qualquer Oracle WebLogic Server pode assumir a atribuição de mestre de cluster e executar operações de recuperação em qualquer região. Para garantir que esses processos funcionem perfeitamente e forneçam um comportamento consistente, os mesmos recursos externos devem estar acessíveis de ambas as regiões.