Conceitos Básicos
A configuração deste playbook usa um único domínio do Oracle WebLogic Server no qual os servidores em dois sites participam do mesmo cluster (conhecido como cluster esticado) e contam com o Data Guard para fornecer proteção ao banco de dados.
Na OCI, recursos como gerenciamento de tráfego, verificações de integridade, balanceadores de carga, views privadas de DNS e gateways de roteamento dinâmico fornecem recursos aprimorados para dar suporte a essa configuração. Para ambientes on-premises, componentes equivalentes de rede e infraestrutura devem ser usados para atender a esses requisitos.
A latência de rede entre os sites ou regiões precisa ser suficientemente baixa para minimizar a penalidade de desempenho introduzida pelo atraso nas chamadas e para evitar inconsistências durante a implantação e o runtime. O sistema Oracle só suporta essa topologia quando a latência entre os servidores WebLogic e o banco de dados está abaixo do tempo de ida e volta (RTT) de 10 ms.
Para obter o melhor desempenho e comportamentos de failover, a Oracle recomenda que você analise cada aplicativo em execução em um cluster esticado WebLogic e ajuste os diferentes parâmetros discutidos neste playbook (tempos limite, configuração de replicação de sessão, leasing de migração de serviço, API de Transação Java (JTA) e assim por diante) de acordo.
Saiba Mais sobre Clusters Esticados do Oracle Fusion Middleware
O fornecimento da arquitetura de disponibilidade máxima (MAA) da Oracle é um dos principais requisitos para qualquer implantação empresarial do Oracle Fusion Middleware.
O Oracle Fusion Middleware inclui um amplo conjunto de recursos de alta disponibilidade, como detecção e reinicialização de morte do processo, clusterização de servidores, migração de serviços, GridLink, balanceamento de carga, failover, backup e recuperação, upgrades incrementais e alterações contínuas na configuração, que protegem uma implantação empresarial contra tempo de inatividade não planejado e minimizam o tempo de inatividade planejado. Esses recursos oferecem uma solução local de alta disponibilidade em um único data center.
Além disso, os aplicativos precisam de proteção contra desastres imprevistos, calamidades naturais e tempo de inatividade que podem afetar todo um data center. A maioria dos sistemas tradicionais de proteção contra desastres usa o modelo ativo-passivo, que envolve a configuração de um local de espera em um local geograficamente diferente do local de produção. Esse modelo geralmente é adotado quando a latência entre os sites é alta e não permite clusterização entre os dois sites. Essa abordagem fornece proteção completa da arquitetura de disponibilidade máxima (MAA). No entanto, isso resulta em custos operacionais e administrativos adicionais, porque o sistema de middleware stand-by espelha o sistema principal e requer replicação contínua. Este modelo é descrito no Oracle Fusion Middleware Disaster Recovery Guide.
Este playbook descreve outro modelo: o modelo ativo-ativo baseado em clusters estendidos do Oracle Fusion Middleware, que pode ser usado para proteger um sistema do Oracle Fusion Middleware contra tempo de inatividade em vários locais. Esse modelo usa uma configuração ativo-ativo para a camada intermediária, enquanto a camada de banco de dados usa uma configuração ativo-passivo com o Data Guard. Ele foi projetado para otimizar a capacidade e distribuir cargas de trabalho entre os sites. Ele utiliza os recursos de forma mais eficaz do que o modelo ativo-passivo, fazendo uso de todos os recursos disponíveis, em vez de deixar as máquinas em espera ociosas. Esse modelo é conhecido como implantação de clusters estendidos do FMW.
Especificamente, esse manual se concentra em como implementar esse modelo nas regiões da Oracle Cloud Infrastructure (OCI). Ele fornece as etapas de configuração para configurar a topologia e a orientação recomendadas sobre as implicações de desempenho e failover dessa configuração.
Os resultados e exemplos neste manual são baseados em um sistema Oracle SOA Suite 14.1.2 que segue a arquitetura do Guia de Implantação Empresarial. Este é um exemplo significativo porque inclui muitos recursos, como componentes padrão de Jacarta, replicação de sessão HTTP, persistência de metadados do banco de dados, um cluster do Coherence e armazenamentos persistentes do Java Message Service (JMS) e da API de transação Java (JTA), entre outras considerações relevantes para clusters estendidos. Como resultado, a topologia e as recomendações descritas também podem ser aplicadas a outros ambientes do Oracle Fusion Middleware.
Terminologia
-
Camada intermediária (também de camada intermediária ou middleware)
A camada intermediária refere-se à camada dentro de uma arquitetura de aplicativo de várias camadas que fica entre a interface do usuário (front-end) e o armazenamento de dados (back-end). Ele trata da lógica de negócios, do processamento de dados e da segurança, atuando como uma ponte entre o usuário e o banco de dados.
-
Oracle Fusion Middleware
O Oracle Fusion Middleware é uma família abrangente de produtos de middleware corporativo da Oracle que permite que as organizações criem, implantem e gerenciem aplicativos de forma eficiente e segura. Inclui soluções para servidores de aplicativos, integração, gerenciamento de processos de negócios, business intelligence, segurança, gerenciamento de identidade, servidores Web e muito mais.
-
Desastre
Um evento catastrófico súbito e não planejado que causa danos ou perdas inaceitáveis em um local ou área geográfica. Um desastre é um evento que compromete a capacidade de uma organização de fornecer funções, processos ou serviços críticos por um período inaceitável e faz com que a organização invoque seus planos de recuperação.
-
Disaster Recovery
Capacidade de proteger contra interrupções naturais ou não planejadas em um site de produção por ter uma estratégia de recuperação para aplicativos e dados para um site stand-by geograficamente separado
-
Arquitetura de disponibilidade máxima da Oracle
A arquitetura de disponibilidade máxima da Oracle (Oracle MAA) é o modelo de melhores práticas para proteção de dados e disponibilidade de produtos Oracle (Oracle Database, Oracle Fusion Middleware, Applications). A implementação das melhores práticas do Oracle MAA é um dos principais requisitos para qualquer implantação da Oracle. Ele fornece recomendações para configurar e gerenciar um sistema Oracle. O Oracle MAA inclui as recomendações do Oracle Fusion Middleware Enterprise Deployment Guide e adiciona as melhores práticas de proteção contra desastres para minimizar o tempo de inatividade planejado e não planejado para interrupções que afetem todo um data center ou região. Consulte a seção Explorar Mais para obter links para a documentação relacionada e outros recursos.
-
Site (ou data center)
Um site é o conjunto de diferentes componentes em um data center necessário para executar um grupo de aplicativos. Por exemplo, um site pode consistir em instâncias, bancos de dados, armazenamento, etc. do Oracle Fusion Middleware.
-
Sistema
Um sistema é um conjunto de destinos (hosts, bancos de dados, servidores de aplicativos, etc.) que trabalham juntos para hospedar seus aplicativos. Por exemplo, para monitorar um aplicativo no Oracle Enterprise Manager, primeiro você cria um sistema, que consiste nos destinos de banco de dados, listener, servidor de aplicativos e hosts nos quais o aplicativo é executado.
-
Cluster esticado
Um cluster esticado refere-se a uma arquitetura de cluster em que os nós em um único cluster lógico são distribuídos entre data centers ou locais geograficamente separados.
-
Fazer Switchover
Switchover é o processo de reverter as funções do site de produção e do site stand-by. Switchovers são operações planejadas feitas para validação periódica ou para executar a manutenção planejada no local de produção atual. Durante um switchover, o site stand-by atual se torna o novo site de produção e o site de produção atual se torna o novo site stand-by. Este playbook também usa o termo switchover para se referir a um switchover de site.
-
Reversão
Switchback é o processo de reverter o site de produção atual e o site stand-by atual para suas funções originais. Switchbacks são operações planejadas feitas após a conclusão da operação de switchover. Um switchback restaura as atribuições originais de cada site: o site stand-by atual se torna o site de produção e o site de produção atual se torna o site stand-by. Este playbook também usa o termo switchback para se referir a um switchback de site.
-
Fazer Failover
Failover é o processo de tornar o site stand-by atual o novo site de produção depois que o site de produção se torna inesperadamente indisponível devido, por exemplo, a um desastre no site de produção. Este playbook também usa o termo failover para se referir a um failover do site.
-
RPO (Recovery point Objective)
O objetivo do ponto de recuperação é a quantidade de perda de dados que um sistema pode tolerar do ponto de vista de negócios, como a quantidade de perda de dados que é aceitável quando ocorre uma interrupção.
-
RTO (Recovery Time Objectivo)
O objetivo de tempo de recuperação é a quantidade de tempo de inatividade que um sistema pode tolerar ou a quantidade aceitável de tempo que um aplicativo ou serviço pode permanecer indisponível quando ocorre uma interrupção, do ponto de vista comercial.
- Oracle Cloud Infrastructure
O Oracle Cloud Infrastructure (OCI) é um conjunto de serviços complementares de nuvem que permite criar e executar uma variedade de aplicativos e serviços em um ambiente hospedado altamente disponível. O OCI oferece recursos de processamento de alto performance (como instâncias físicas de hardware) e capacidade de armazenamento em uma rede virtual de sobreposição flexível que está acessível de forma segura pela sua rede on-premise.
-
Região da OCI
Uma região do OCI é uma área geográfica localizada que contém um ou mais data centers, hospedando domínios de disponibilidade. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou mesmo continentes).
Uma região é um local em termos de recuperação de desastres.
- Domínio de disponibilidade
Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.
- Rede e sub-rede virtual na nuvem da OCI
VCN (rede virtual na nuvem) é uma rede personalizável definida por software que você configura em uma região do OCI. Assim como as redes tradicionais do data center, as VCNs dão a você controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos de CIDR (Classless Inter-domain Routing) não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
- Gateway de roteamento dinâmico (DRG)
O DRG é um roteador virtual que fornece um caminho para tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do OCI, uma rede on-premises ou uma rede em outro provedor de nuvem.
- DNS do OCI
O serviço DNS (Domain Name System) do Oracle Cloud Infrastructure é uma rede global de DNS (sistema de nomes de domínio anycast) altamente escalável que oferece desempenho, resiliência e escalabilidade aprimoradas de DNS, para que os usuários finais se conectem rapidamente a aplicativos de internet, de qualquer lugar.
-
View privada de DNS do OCI
Uma view privada de DNS do OCI é uma coleção de uma ou mais zonas de DNS Privado do OCI, usadas para agrupar logicamente zonas de DNS e controlar como elas são resolvidas. Uma view é anexada a um resolvedor de DNS privado, que pode ser o resolvedor padrão de uma rede virtual na nuvem (VCN) ou personalizada. Isso permite gerenciar configurações de DNS separadas para diferentes ambientes ou aplicativos dentro da sua VCN.
-
IP Virtual
Um endereço IP virtual (VIP) refere-se a um endereço IP que não está vinculado a uma determinada interface de rede física ou dispositivo. Em vez disso, ele é abstraído e pode se mover entre dispositivos ou ser usado para várias funções de rede.
-
Gerenciamento de Tráfego do OCI
O OCI Traffic Management direciona de forma inteligente o tráfego do usuário para pontos finais ideais usando políticas avançadas baseadas em DNS (políticas de orientação de tráfego da OCI). Ele permite que as organizações controlem como as consultas de DNS são resolvidas, otimizando o roteamento de solicitações do cliente para maior disponibilidade, desempenho e resiliência de aplicativos ou serviços implantados na OCI ou em outro lugar.
-
Balanceador de carga
Um balanceador de carga é um sistema ou serviço que distribui o tráfego de rede recebido em vários servidores para garantir alta disponibilidade, confiabilidade e desempenho ideal dos aplicativos.
-
Balanceador de Carga do OCI
O OCI Load Balancer é um serviço totalmente gerenciado do Oracle Cloud Infrastructure que distribui automaticamente o tráfego de entrada entre vários servidores ou recursos de backend para garantir alta disponibilidade, melhor desempenho e escalabilidade para aplicativos.
-
Armazenamento em bloco
O armazenamento em blocos é um tipo de armazenamento de dados em que as informações são salvas em blocos de tamanho fixo e podem ser acessadas diretamente por servidores ou aplicativos por meio de protocolos de armazenamento, como iSCSI ou Fibre Channel.
- Volumes em Blocos do OCI
Com o Oracle Cloud Infrastructure Block Volumes, você pode criar, anexar, conectar e mover volumes de armazenamento e alterar o desempenho do volume para atender aos seus requisitos de armazenamento, desempenho e aplicativo. Depois de anexar e conectar um volume a uma instância, você pode usar o volume como disco rígido comum. Você também pode desconectar um volume e anexá-lo a outra instância sem perder dados.
-
Armazenamento compartilhado
Armazenamento compartilhado refere-se a um sistema de armazenamento ou recurso que pode ser acessado simultaneamente por vários servidores, computadores ou aplicativos dentro de um ambiente de TI. Essa configuração permite que todos os sistemas participantes leiam e gravem no mesmo repositório de dados, tornando-o ideal para cenários que exigem consistência de dados, colaboração, alta disponibilidade e escalabilidade.
- OCI File Storage
O Oracle Cloud Infrastructure File Storage fornece um sistema de arquivos da rede durável, escalável, seguro e de nível empresarial. Você pode estabelecer conexão com o OCI File Storage de qualquer instância bare metal, de máquina virtual ou de contêiner em uma VCN. Você também pode acessar o OCI File Storage de fora da VCN usando o Oracle Cloud Infrastructure FastConnect e a IPSec VPN.
-
Serviços de banco de dados do OCI
Os serviços de banco de dados da OCI se referem ao portfólio de soluções de banco de dados gerenciado fornecidas pela Oracle Cloud Infrastructure (OCI). Esses serviços oferecem uma variedade de opções de implantação e gerenciamento de banco de dados no Oracle Cloud, suportando diferentes cargas de trabalho, necessidades de desempenho e modelos de dados, como Oracle Base Database Service e Oracle Exadata Database Service.
- Oracle Data Guard
O Oracle Data Guard e o Active Data Guard fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados stand-by e que permitem que os bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses bancos de dados stand-by como cópias do banco de dados de produção usando a replicação na memória. Se o banco de dados de produção ficar indisponível devido a uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção. O Oracle Active Data Guard fornece a capacidade adicional de descarregar cargas de trabalho de leitura máxima para bancos de dados stand-by e também fornece recursos avançados de proteção de dados.
Este playbook usa a OCI como um exemplo de infraestrutura para implantar clusters estendidos do Oracle Fusion Middleware. Estas são as equivalências do local para o OCI para os principais componentes necessários para a configuração de cluster esticada do Oracle Fusion Middleware:
| On-premises (ou genérico) | Equivalente ao OCI |
|---|---|
| Site (ou data center) | Região do OCI |
| Armazenamento compartilhado (por exemplo, NFS) | OCI File Storage |
| Armazenamento em bloco | Volumes em Blocos do OCI |
| Balanceador de carga global | OCI Traffic Management e políticas de orientação |
| Balanceador de carga local | Balanceador de Carga do OCI |
| Rede | Rede virtual na nuvem do OCI |
| Regras de firewall/firewall | Regras de segurança de rede do OCI |
| DNS interno | View privada de DNS do OCI |
| Servidor físico/máquina virtual | Instância do OCI Compute |
| Banco de dados on-premises | Serviço de banco de dados OCI |
| Conectividade local entre sites | Pareamento remoto do OCI com gateway de roteamento dinâmico |
Arquitetura
As seguintes considerações se aplicam à arquitetura de cluster esticada FMW:
- Regiões
Há duas regiões, ou locais, nesta topologia. A latência entre eles não deve ser superior a 10 ms de tempo de ida e volta (RTT). Os requisitos de largura de banda dependerão dos tipos de payloads tratados por cada sistema, mas um mínimo de 1 ou 2 gigabits por segundo (Gbps) é recomendado.
- Camada intermediária
A camada intermediária opera em um modelo ativo-ativo, com um único domínio. Metade dos servidores gerenciados são implantados em um local, com o restante no outro. O Servidor de Administração é executado em um site, mas pode fazer failover para o outro site, se necessário. Essa configuração geralmente é chamada de cluster estendido.
- Camada de banco de dados
A camada do banco de dados usa uma arquitetura ativo-passivo, com suporte do Oracle Data Guard. O banco de dados principal está localizado em um local, enquanto o banco de dados stand-by reside no outro local. Todos os servidores de camada intermediária são configurados para conexão com o banco de dados que atualmente serve como principal, independentemente de sua localização. O Oracle Database configurado em cada site é um Oracle Real Application Clusters (Oracle RAC). O Oracle RAC permite a execução de um banco de dados da Oracle em um cluster de servidores dentro do mesmo data center, oferecendo tolerância a falhas, desempenho e escalabilidade sem a necessidade de alterações de aplicativos.
- Armazenamento
O armazenamento compartilhado é local para cada site. Por motivos de contenção e segurança, não é recomendável usar o armazenamento compartilhado entre sites. O espelhamento ou replicação de disco de site1 para site2 e vice-versa é recomendado para fornecer uma cópia recuperável dos artefatos em cada site.
- Armazenamentos Persistentes
As Lojas Persistentes WebLogic (Java Message Service (JMS) e a API de Transação Java (JTA)) são configuradas como armazenamentos JDBC (Java Database Connectivity) no banco de dados. Desta forma, eles são acessíveis a partir de ambos os sites. Isso permite que o recurso Migração Automática de Serviço funcione entre os dois sites.
- Solicitar encaminhamento
Os servidores Web em cada site encaminham solicitações apenas para as instâncias do Oracle WebLogic Server localizadas no mesmo site. Não há comunicação entre regiões entre os servidores Web (instâncias do Oracle HTTP Server) e os servidores WebLogic no outro site para minimizar a latência e o tráfego entre regiões.
- Balanceadores de carga
Cada site tem seu próprio balanceador de carga dedicado, que direciona solicitações exclusivamente para os servidores web dentro desse site local. Não há comunicação entre regiões entre os balanceadores de carga e os servidores Web localizados no outro site.
- Acesso front-end
Na frente do sistema, a solução fornece um único acesso front-end ao sistema. Os clientes se conectam usando um único endereço que permanece o mesmo, independentemente do site para o qual eles são direcionados. Este mecanismo oferece um nome de sistema de nomes de domínio (DNS) que é acessível a todos os clientes e encaminha solicitações para qualquer site com base em critérios e regras predefinidos, como a localização geográfica do cliente.
O diagrama a seguir ilustra a topologia de cluster esticada do Oracle Fusion Middleware
alongched-cluster-topology-oracle.zip
O diagrama a seguir ilustra o domínio WebLogic e os clusters na topologia de cluster esticada do Oracle Fusion Middleware:
Vantagens
- Administração simplificada
As implantações ativo-passivo incorrem em uma sobrecarga de administração adicional para manter a configuração sincronizada entre o site principal e o site stand-by. Embora a maioria das informações de runtime e metadados residam no banco de dados, a configuração do Oracle WebLogic Server reside no sistema de arquivos. Assim, além da replicação do Oracle Data Guard para o banco de dados, o modelo ativo-passivo requer uma replicação contínua do sistema de arquivos, que pode ser implementada de várias maneiras (rsync, réplica no nível de armazenamento e assim por diante).
No entanto, no modelo de clusters esticados FMW, a infraestrutura do Oracle WebLogic Server mantém a configuração sincronizada entre os vários nós no mesmo domínio. A maior parte dessa configuração geralmente reside no diretório de domínio do Servidor de Administração. Essa configuração é propagada automaticamente para os outros nós no mesmo domínio quando os servidores gerenciados são iniciados ou quando uma alteração é implementada. Por esse motivo, a sobrecarga de administração da implantação é muito pequena em comparação com qualquer abordagem ativa-passiva, na qual é necessária a replicação constante de alterações de configuração.
- Maior disponibilidade e menor RTO e RPO para alguns cenários de failover
O modelo de cluster esticado FMW fornece melhor RPO (Recovery Point Objective) e RTO (Recovery Time Objective) do que o modelo ativo-passivo nestes cenários:
- Falha completa do middle-tier em eventos de um local
Se todos os servidores de camada intermediária em um local falharem, o sistema poderá continuar atendendo solicitações com os servidores de camada intermediária no site de mesmo nível imediatamente. O RTO e o RPO são zero nesse tipo de cenário.
Para isso, os servidores de camada intermediária no local alternativo precisam ser capazes de sustentar a carga de trabalho combinada dos dois locais. É necessário um planeamento adequado da capacidade para ter em conta esses cenários. Dependendo do design, as solicitações dos clientes finais podem precisar ser limitadas quando apenas um local está ativo. Caso contrário, os locais devem ser projetados com capacidade excesdsive, derrotando parcialmente a finalidade do uso constante e eficiente da capacidade.
- Falhas nos eventos da camada do banco de dados
Um switchover do banco de dados ocorre no mesmo RTO e RPO em um modelo de cluster ativo-passivo e esticado FMW. O RTO geral do sistema, no entanto, é menor no modelo de cluster esticado porque os servidores de camada intermediária já estão ativos no site secundário. Não é necessário reiniciar as camadas intermediárias. Uma configuração de origem de dados apropriada, usando uma string de conexão dupla com as notificações GridLink e FAN (Fast Application Notification), automatiza o failover das conexões de banco de dados das camadas intermediárias, reduzindo o RTO do sistema.
- Falha completa do middle-tier em eventos de um local
Considerações
- Planejamento da capacidade
Este modelo requer planejamento de capacidade para considerar cenários de failover entre os dois sites. Se um site inteiro perder as camadas intermediárias, o outro deverá ser capaz de sustentar a carga de trabalho completa. Caso contrário, o site disponível pode ficar sem resposta devido à sobrecarga. Isso significa que, durante a operação normal, os nós de camada intermediária devem ser subutilizados para permitir capacidade suficiente para lidar com cenários de failover. A mesma regra se aplica à camada web. Se um site perder todos os seus servidores web, os servidores web do outro site devem ser capazes de lidar com todas as solicitações do sistema.
- Throughput de rede entre sites
O throughput da rede depende principalmente de duas coisas: o quão longe os sites estão e o quão bem a rede lida com a confiabilidade e o congestionamento. Não importa o quão rápido os servidores ou o software sejam, há um limite para a rapidez com que os dados podem se mover entre os sites. Dois fatores importantes que afetam isso são a latência e o jitter:
-
Latência é o tempo necessário para que os dados percorram a rede de um site para outro. Pode ser medida de ida (da origem ao destino) ou de ida e volta (lá e de volta). O tempo de ida e volta (RTT) é mais comum e pode ser verificado com o comando
ping. -
Jitter é a variação no tempo que leva para os pacotes de dados chegarem.
Para o modelo atual, manter a latência baixa é especialmente importante, pois o jitter geralmente só importa quando a latência já é muito baixa. Portanto, controlar a latência é a principal prioridade para um bom desempenho nesse tipo de configuração. A distância é normalmente a causa mais relevante de latência.
Os testes realizados mostraram que o desempenho nesse modelo (em que algumas instâncias do Oracle WebLogic Server no cluster estão em um site diferente do banco de dados) degrada consideravelmente quando a latência (RTT) excede 10 milissegundos.
A Oracle realizou vários testes com diferentes configurações afetadas por diferentes latências. As latências de referência mostradas neste playbook diferenciam entre clusters com:- Todos os membros no mesmo domínio de disponibilidade
- Membros em diferentes domínios de disponibilidade
- Membros em duas regiões OCI próximas, mas diferentes
A imagem a seguir mostra o throughput (transações por segundo) de um sistema SOA do Oracle Fusion Middleware que executa a Demonstração de Ordem do Fusion (FOD) para diferentes latências entre o servidor WebLogic e o banco de dados:
A imagem a seguir mostra o tempo ativo da API de Transação Java (JTA) para um sistema SOA do Oracle Fusion Middleware que executa a Demonstração de Ordem do Fusion (FOD) que usa um banco de dados em outro site com diferentes latências entre sites:
A imagem a seguir mostra a degradação observada no throughput geral do sistema em transações por segundo para diferentes latências entre os sites (ambos os sites que trabalham em conjunto com o banco de dados em um dos sites).
Observação:
Com tudo isso em mente e com as penalidades de desempenho observadas em muitos testes, a Oracle não suporta clusters estendidos do Oracle Fusion Middleware que excedem 10 milissegundos de latência (RTT) entre os sites. Os sistemas podem operar sem problemas, mas os tempos de transação aumentarão consideravelmente. Latências além de 10 milissegundos (RTT) também causarão problemas no cluster do Oracle Coherence usado para implantação e JTA, web services ou timeouts de aplicativos. Isso torna as soluções apresentadas neste playbook adequadas principalmente para sites ou regiões com baixa latência entre eles.
-
- Tráfego entre regiões
No modelo atual, você precisa minimizar o tráfego entre sites para reduzir o efeito da latência na taxa de transferência do sistema. Em um sistema FMW típico, as comunicações entre as diferentes camadas ou elementos são:
-
Acesso ao banco de dados nas instâncias do Oracle WebLogic Server para acesso a metadados e outras operações de leitura/gravação do banco de dados.
-
Chamadas HTTP de entrada de instâncias de balanceadores de carga (LBR) ou do Oracle HTTP Server e callbacks HTTP.
-
Chamadas JNDI (Java Naming and Directory Interface)/RMI (Remote Method Invocation, Chamada de método remoto) e JMS (Java Message Service) entre instâncias do Oracle WebLogic Server.
-
Notificações do Oracle Coherence entre todos os servidores do sistema. Por exemplo, SOA usa o Coherence para fornecer uma imagem composta e de metadados consistente.
-
Replicações de sessão HTTP entre as instâncias do Oracle WebLogic Server. Alguns componentes usam aplicativos web com monitoramento de estado que podem depender da replicação de sessão para permitir failover transparente de sessões entre servidores. Dependendo dos padrões de uso e do número de usuários, isso pode gerar uma quantidade considerável de dados de replicação.
-
O acesso ao armazenamento LDAP/policy/identity é executado pela infraestrutura do Oracle WebLogic Server para fins de autorização e autenticação. Idealmente, cada site deve ter um armazenamento independente de identidade e política que seja sincronizado regularmente para minimizar as chamadas de um site para o outro. Alternativamente, ambos os sites podem compartilhar a mesma loja. O impacto do compartilhamento da loja dependerá do tipo de loja e do padrão de uso do sistema.
Sempre que possível, todos os itens acima devem estar contidos no site para melhorar o desempenho. Por exemplo:
-
Os servidores em um site só devem receber chamadas de instâncias do Oracle HTTP Server no mesmo site.
-
Os servidores em um site devem fazer chamadas JMS, RMI e JNDI somente para servidores no mesmo site e devem receber callbacks gerados por servidores somente no mesmo site.
-
A replicação da sessão HTTP deve ser restrita apenas a outros servidores no mesmo site. Os requisitos de replicação e failover precisam ser analisados para cada caso de negócios, mas, idealmente, o tráfego de replicação de sessão deve ser reduzido em todos os sites, tanto quanto possível.
-
- Armazenamento compartilhado
A latência para gravações do sistema de arquivos de rede (NFS) entre sites pode causar grave degradação do desempenho. Os servidores devem usar dispositivos de armazenamento locais em seu site para eliminar a contenção em solicitações de leitura/gravação para sistemas de arquivos. O armazenamento compartilhado deve ser limitado a estar dentro de cada site.
- Outros Recursos
Os dois sites podem compartilhar outros recursos externos, como LDAP, destinos JMS externos, web services externos e assim por diante. É necessário que esses recursos estejam consistentemente disponíveis em ambos os locais. Os detalhes de configuração desses recursos externos estão fora do escopo deste playbook.
