Configurar uma Solução de DR Híbrida para o Oracle SOA Suite

Antes de Começar

Antes de começar a implantar uma solução de recuperação de desastres híbrida (DR) para o sistema Oracle SOA Suite, familiarize-se com as melhores práticas de Alta Disponibilidade na configuração de rede, armazenamento e host para sistemas Oracle WebLogic Server locais.

O sistema Oracle WebLogic Server usado neste documento é um ambiente de Alta Disponibilidade que foi configurado de acordo com as melhores práticas padrão MAA descritas no Enterprise Deployment Guide for Oracle SOA Suite (EDG) para sistemas Fusion Middleware. Embora nem todos os cenários sigam essa topologia exata aos detalhes, isso abrange muitos componentes e combinações diferentes, ele é usado frequentemente em implantações grandes e implementa recomendações de alta disponibilidade que devem ser aplicadas antes da implantação de um sistema de recuperação de desastres (DR). Portanto, ele é considerado o melhor exemplo de referência de um sistema principal para uma solução de DR híbrida para o Oracle WebLogic Server. Com base nisso, é altamente recomendável familiarizar-se com as melhores práticas de implantação do Oracle WebLogic Server High Availability e Enterprise para as melhores práticas de configuração de rede, armazenamento e host antes de implantar um sistema híbrido.

Consulte os seguintes itens para obter mais detalhes:

Oracle Fusion Middleware High Availability Guide
Oracle Fusion Middleware Enterprise Deployment Guide para Oracle SOA Suite
Oracle Fusion Middleware Enterprise Deployment Guides em MAA Best Practices - Oracle Fusion Middleware

Assegure-se de que você também esteja familiarizado com os conceitos e a administração do Oracle Cloud Infrastructure.

Arquitetura

Essa arquitetura mostra o principal ambiente de data center local com um sistema stand-by no Oracle Cloud Infrastructure (OCI). Use essa arquitetura para uma solução de recuperação de desastres híbrida (DR) para seu ambiente Oracle SOA Suite local.

O sistema principal é um sistema do Oracle SOA Suite localizado no local. O sistema stand-by é criado do zero em uma tenancy do OCI que usa o Oracle Cloud Infrastructure FastConnect (ou VPN Site a Site) para estabelecer conexão com o ambiente local.

A camada intermediária no OCI é criada instalando o SOA em VMs (máquinas virtuais) do OCI e não em uma instância do Oracle SOA Cloud Service ou do Oracle SOA Suite on Marketplace (há restrições nas versões do SO, nos usuários do SO e na estrutura de diretórios que impedem que a instância do Oracle SOA Cloud Service ou do Oracle SOA Suite on Marketplace funcione corretamente como standby para um sistema local).

A camada do banco de dados no site do OCI é um Sistema de BD do Oracle Real Application Clusters (Oracle RAC).

Descrição da ilustração maa-soa-hybrid-dr.png

maa-soa-híbrido-dr-oracle.zip

Essa arquitetura oferece suporte aos seguintes componentes no principal data center local:

Rede local
Essa rede é a rede local usada pela sua organização. É um dos porta-vozes da topologia.
Balanceador de Carga
Fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end.
Oracle SOA Suite
O ambiente SOA é configurado seguindo o Enterprise Deployment Guide for Oracle SOA Suite (EDG) padrão. Esta topologia abrange muitos componentes diferentes que são geralmente usados em implantações grandes e implementa recomendações de alta disponibilidade que devem ser aplicadas antes da implantação de um sistema de DR.
Oracle Real Application Clusters (Oracle RAC)
O Oracle RAC permite que você execute um único Oracle Database entre vários servidores para maximizar a disponibilidade e ativar a escalabilidade horizontal, enquanto acessa o armazenamento compartilhado. As sessões do usuário que se conectam às instâncias do Oracle RAC podem fazer failover e repetir com segurança as alterações durante interrupções, sem alterações nos aplicativos do usuário final, ocultando o impacto das interrupções dos usuários finais.

Essa arquitetura oferece suporte aos seguintes componentes no ambiente secundário stand-by no OCI:

Região
Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, chamados domínios de disponibilidade. As regiões são independentes de outras regiões, e grande distância pode separá-las (entre países ou até mesmo continentes).
Rede virtual na nuvem (VCN) e sub-rede
Uma VCN é uma rede personalizada e definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs permitem total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, que podem ter escopo em uma região ou em um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contínuo de endereços que não se sobrepõem com as 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.

As sub-redes privadas são geralmente recomendadas por motivos de segurança, a menos que o recurso deva ser acessível pela internet pública (se um Balanceador de Carga for acessado pela internet pública, ele deverá estar em uma sub-rede pública).
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 Oracle Cloud Infrastructure, uma rede local ou uma rede em outro provedor de nuvem.
FastConnect
O Oracle Cloud Infrastructure FastConnect fornece uma maneira fácil de criar uma conexão privada dedicada entre o seu data center e o Oracle Cloud Infrastructure. O FastConnect oferece opções de largura de banda mais alta e uma experiência de rede mais confiável quando comparado com conexões baseadas na internet.
Lista de segurança
Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.
Tabela de rota
As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, normalmente por meio de gateways.
Balanceador de carga
O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end.
Cloud Guard
Você pode usar o Oracle Cloud Guard para monitorar e manter a segurança de seus recursos no Oracle Cloud Infrastructure. O Cloud Guard usa receitas de detector que você pode definir para examinar seus recursos quanto a pontos fracos de segurança e monitorar operadores e usuários para determinadas atividades arriscadas. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a executar essas ações, com base em receitas do respondedor que você pode definir.
Sistema de Banco de Dados
O Sistema Oracle Database é um serviço de banco de dados do Oracle Cloud Infrastructure (OCI) que permite criar, escalar e gerenciar bancos de dados Oracle com todos os recursos. O Sistema de BD usa o armazenamento de Volumes em Blocos do OCI em vez do armazenamento local e pode executar o Oracle Real Application Clusters (Oracle RAC) para melhorar a disponibilidade.
Serviço Oracle Cloud Infrastructure File Storage
O Serviço Oracle Cloud Infrastructure File Storage fornece um sistema de arquivos de rede durável, escalável e seguro e de nível empresarial. Você pode se conectar a um sistema de arquivos do serviço File Storage de qualquer instância bare metal, de máquina virtual ou de contêiner em sua VCN (Rede Virtual na Nuvem). O File Storage Service suporta o protocolo Network File System versão 3.0 (NFSv3). O serviço suporta o protocolo NLM (Network Lock Manager) para a funcionalidade de bloqueio de arquivo.

O Oracle Cloud Infrastructure File Storage emprega armazenamento replicado em 5 direções, localizado em diferentes domínios de falha, para fornecer redundância para proteção resiliente dos dados. Os dados são protegidos com a codificação de exclusão. O File Storage Service foi projetado para atender às necessidades de aplicativos e usuários que precisam de um sistema de arquivos corporativo em uma grande variedade de casos de uso.
Oracle Cloud Infrastructure Block Volumes
O serviço Oracle Cloud Infrastructure Block Volumes permite provisionar e gerenciar dinamicamente volumes de armazenamento em blocos. Você pode criar, anexar, conectar e mover volumes, bem como alterar o desempenho do volume, conforme necessário, para atender aos requisitos de armazenamento, de desempenho e do aplicativo. Depois de anexar e conectar um volume a uma instância, você pode usar o volume como disco rígido comum.
Sistema de BD Oracle RAC
O Oracle Real Application Clusters (Oracle RAC) permite que os clientes executem um único Oracle Database entre vários servidores para maximizar a disponibilidade e ativar a escalabilidade horizontal, enquanto acessam o armazenamento compartilhado. As sessões do usuário que se conectam às instâncias do Oracle RAC podem fazer failover e repetir com segurança as alterações durante interrupções, sem alterações nos aplicativos do usuário final, ocultando o impacto das interrupções dos usuários finais. O framework de alta disponibilidade do·Oracle RAC mantém a disponibilidade do serviço armazenando as informações de configuração de cada serviço no OCR (Oracle Cluster Registry).

O Sistema de BD Oracle RAC está na camada de banco de dados.
Data Guard
O Oracle Data Guard fornece um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby para permitir 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 standby como cópias do banco de dados de produção. Em seguida, se o banco de dados de produção ficar indisponível por causa de uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados standby para a função de produção, minimizando o tempo de inatividade associado à interrupção.

Descrição da Topologia

A topologia de DR híbrida do Oracle SOA Suite usa um modelo ativo-passivo. O sistema principal está em um data center local e o sistema secundário está no OCI (Oracle Cloud Infrastructure). As redes locais e do OCI são interconectadas com o Oracle Cloud Infrastructure FastConnect (preferencial) ou VPN Site a Site.

Na camada db, os bancos de dados principal e secundário são configurados com o Oracle Data Guard. Com o Oracle Data Guard, todas as alterações aplicadas ao banco de dados principal são replicadas no banco de dados secundário (stand-by).

A mid-tier secundária é instalada em VMs (máquinas virtuais) OCI. Os binários e o Domínio SOA do Oracle Fusion Middleware são uma réplica dos binários e do Domínio SOA do principal, usando o serviço Oracle Cloud Infrastructure File Storage como a solução do sistema de arquivos de rede e o Oracle Cloud Infrastructure Block Volumes como a solução do sistema de arquivos de acesso privado do nó. Os aliases de nome de host do principal também são usados como endereços de listener do Servidor WebLogic no ambiente secundário. No local secundário, os aliases de nome de host são resolvidos com os endereços IP dos hosts secundários.

A camada Web no data center principal segue o modelo do Enterprise Deployment Guide (EDG) com dois hosts do Oracle HTTP Server e um balanceador de carga (LBR). A mesma topologia é implantada no sistema secundário usando um Balanceador de Carga do OCI e hosts do Oracle HTTP Server instalados em instâncias de computação do OCI. No sistema secundário, você pode, como alternativa, implementar a camada Web apenas com um Balanceador de Carga do OCI, que fornece a maioria dos recursos exigidos pela topologia de implantação empresarial. Ambas as opções, somente o OCI Load Balancer ou o OCI Load Balancer e os hosts do Oracle HTTP Server, estão incluídos neste documento.

Um endereço front-end exclusivo é configurado para acessar os aplicativos em execução no sistema. O nome do front-end virtual aponta para o IP do Balanceador de Carga no site principal. Em um switchover, o nome front-end é atualizado no DNS para apontar para o IP do Balanceador de Carga do OCI no site secundário. Ele sempre deve apontar para o IP do Balanceador de Carga do site que tem a atribuição principal.

Durante a operação de negócios normal, o banco de dados standby é um standby físico. Ele está no estado de montagem ou é aberto no modo somente leitura quando o Active Data Guard é usado. O banco de dados standby recebe e aplica redo do banco de dados principal, mas não pode ser aberto no modo leitura/gravação. O Oracle Data Guard replica automaticamente as informações que residem no banco de dados para o site secundário, incluindo esquemas de SOA (Server Oriented Architecture), informações do Oracle Platform Security Services, esquemas personalizados, logs de transação (TLOGs), armazenamentos persistentes de JDBC (Java Database Connectivity) e muito mais.

Durante as etapas de configuração do DR e validação do ciclo de vida descritas neste documento, você pode converter o banco de dados stand-by físico em um stand-by de snapshot para validar o site secundário sem executar um switchover completo. Um banco de dados no modo stand-by de snapshot é um banco de dados totalmente atualizável. Um banco de dados stand-by de snapshot recebe e arquiva, mas não se aplica, os dados redo recebidos de um banco de dados principal. Todas as alterações aplicadas a um stand-by de snapshot são descartadas quando são convertidas em um stand-by físico.

A configuração do Domínio WebLogic deve ser replicada do site principal para o secundário. Essa replicação é necessária e executada durante a configuração inicial da DR e também é necessária durante o ciclo de vida contínuo do sistema. Quando as alterações de configuração forem realizadas no domínio principal, elas deverão ser replicadas para o local secundário.

Quando um banco de dados stand-by é desativado durante a operação de negócios normal, ele não recebe atualizações do banco de dados principal e pode ficar fora de sincronia. Como isso pode resultar em uma perda de dados em um cenário de alternância, não é recomendável interromper o banco de dados stand-by durante a operação comercial normal. É possível interromper os hosts da camada intermediária stand-by. No entanto, quando hosts stand-by forem interrompidos, as alterações de configuração replicadas do site principal não serão enviadas para o domínio secundário. Nesse caso, quando um switchover acontece, o objetivo do tempo de recuperação (RTO) é aumentado, pois os hosts da camada intermediária standby devem ser iniciados e o domínio sincronizado com alterações principais.

Considerações sobre Topologia

Veja a seguir as premissas de topologia mais relevantes consideradas nesta configuração:

O sistema principal é um ambiente local existente
O ambiente inclui um banco de dados Oracle Real Application Clusters (Oracle RAC), hosts de camada intermediária e um balanceador de carga. A configuração do sistema local está fora do escopo deste documento.
O sistema secundário está no OCI (Oracle Cloud Infrastructure)
O sistema secundário é criado do zero no OCI e fornece uma versão do Oracle Cloud do seu sistema local. É um sistema Oracle Cloud totalmente padrão, com a capacidade de se tornar o sistema principal.
Oracle SOA Suite e componentes
Esse documento é focado no sistema Oracle SOA Suite, incluindo seus componentes. Por exemplo, Oracle Service Bus, Oracle Business Process Management, Oracle Enterprise Scheduler Service e muito mais. Embora os procedimentos e as recomendações deste documento possam se aplicar a outros componentes do Oracle Fusion Middleware que não fazem parte do Oracle SOA Suite (como Web Center e Business Intelligence), os detalhes e a possibilidade de suporte desses componentes são excluídos deste exercício.
Os sistemas primário e secundário são simétricos
O sistema secundário tem o mesmo número de nós na camada intermediária, camada Web e camada bd. Pode haver diferenças na camada da Web quando o OCI Load Balancer é usado sozinho no OCI (sem o Oracle HTTP Server).
Os sistemas primário e secundário usam recursos semelhantes
Embora as formas do OCI disponíveis possam não corresponder aos mesmos valores exatos na CPU e na memória da configuração principal existente, você deve usar as formas mais semelhantes. A Oracle recomenda o uso de standbys simétricos que forneçam um poder de processamento semelhante ao sistema principal. Caso contrário, poderão ocorrer problemas de desempenho e falhas em cascata quando a carga de trabalho for alternada para o sistema OCI.

Considerações para Rede

Considere o seguinte ao configurar a rede:

Conectividade entre a rede local e o Oracle Cloud Infrastructure (OCI)
Os bancos de dados locais e do OCI devem se comunicar entre si por meio do Oracle SQL*Net Listener (porta 1521) para o transporte redo do Oracle Data Guard. Os hosts locais e de camada intermediária do OCI devem se comunicar entre si usando a porta SSH (para cópias rsync). A Oracle recomenda o uso da comunicação do Oracle Cloud Infrastructure FastConnect entre o data center local e a Região do OCI. O Oracle Cloud Infrastructure FastConnect fornece conectividade e largura de banda seguras dedicadas, com latência, jitter e custo previsíveis. Como alternativa, você pode usar a VPN Site a Site, que também oferece conectividade segura entre sistemas locais e OCI. No entanto, isso fornece menor largura de banda e latência variável, jitter e custo.
Desativar conectividade entre hosts de camada intermediária e o banco de dados remoto
Espera-se que os hosts de camada intermediária nunca se conectem ao banco de dados remoto durante o runtime. A latência entre o local e o OCI geralmente desencoraja essa conectividade cruzada. Para evitar conexões acidentais e problemas de carga de trabalho, evite a conectividade dos hosts de camada intermediária com o banco de dados remoto.
Nomes de host virtual
Como prática recomendada, presume-se que o sistema local principal use nomes de host virtuais, em vez do nome do host do nó físico, como os endereços de listening do Oracle WebLogic Server. Normalmente, os nomes de host virtual são aliases do nome de host do nó físico. O uso de nomes de host virtuais facilita a movimentação de configurações para hosts diferentes; no entanto, esse não é um requisito obrigatório. A configuração neste documento funciona desde que os servidores secundários no OCI possam usar os nomes de host usados como endereços de listening na instância principal como um alias em cada nó (conforme resolvido no DNS ou em /etc/hosts local).
Um IP Virtual só é necessário para o endereço de listening do Servidor de Administração
A Migração Automática de Serviço é suportada e recomendada para alta disponibilidade local (HA), o que significa que os servidores gerenciados não são necessários para usar endereços IP virtuais. Somente o Servidor de Administração precisa de um VIP para failover local. Como prática recomendada, presume-se que o Servidor de Administração no sistema local principal escuta em um endereço VIP. Este documento fornece instruções para configurar um VIP para o Servidor de Administração no OCI. No entanto, esse endereço VIP não é um requisito difícil para configurar a Recuperação de Desastres no OCI com este documento. Se o Servidor de Administração principal não atender em um VIP, você poderá ignorar esse ponto.
Balanceador de carga
Um balanceador de carga front-end (LBR) é usado no ambiente local principal e um Balanceador de Carga do OCI é usado no ambiente stand-by.
Endereço front-end virtual
O sistema primário deve usar um nome front-end virtual (um URL personalizado, como mysoa.example.com) como ponto de entrada para os clientes. Esse nome front-end é resolvido no DNS com o endereço IP do balanceador de carga principal. Em uma topologia DR, o sistema secundário é configurado para usar o mesmo nome front-end virtual. Quando ocorre um switchover ou failover para o sistema secundário, o nome do front-end virtual é modificado no DNS para apontar para o endereço IP do balanceador de carga secundário. Dessa forma, o acesso dos clientes ao sistema é independente do site ser usado como principal. O mesmo se aplica a qualquer nome front-end virtual usado no sistema. Por exemplo, você pode usar um nome front-end adicional, como admin.example.com, para acessar funções administrativas da Console de Administração do Oracle WebLogic Server ou da Console do Fusion Middleware Control.

Você pode usar um nome front-end separado, como osb.example.com, para acessar os serviços do Oracle Service Bus. Este documento usa um nome de host front-end para simplificação.

Considerações para o Armazenamento

Considere o seguinte ao configurar o armazenamento:

Estrutura de diretórios baseada em EDG
Este documento usa uma estrutura de diretório do Enterprise Deployment Guide (EDG) para a configuração de domínio do Oracle WebLogic Server do sistema principal. O modelo EDG usa diretórios de domínio separados para a administração do Oracle WebLogic Server e para cada Oracle WebLogic Server gerenciado, conforme descrito em Preparando o Sistema de Arquivos para uma Implantação Empresarial. A estrutura do diretório EDG é usada como referência nos exemplos. Ele usa uma combinação de pastas compartilhadas e privadas, que abrange mais casos de uso. Se o sistema não usar a estrutura de diretórios EDG, adapte os exemplos para atender às especificidades do ambiente.
Considerações para armazenamento no local principal
É uma boa prática armazenar não apenas as pastas compartilhadas (diretório de domínio do Oracle WebLogic Server Admin Server, home de planos de implantação, runtime compartilhado etc.), mas também os binários home do Oracle Fusion Middleware e as configurações locais (diretórios de domínio do servidor gerenciado, pasta do gerenciador de nós) no armazenamento NFS no local principal. Isso facilita a cópia do principal para o standby. Embora cada host use seus próprios binários e sua própria configuração local de forma privada (volumes NFS separados para cada servidor), a cópia da configuração entre sites será mais fácil se esses residirem no armazenamento compartilhado. Usando essa abordagem, é possível montar todos eles de um nó exclusivo e executar a cópia rsync para os nós remotos em uma única operação. Sem essa abordagem, a cópia deve acontecer individualmente, de cada um dos nós principais que armazenam dados de forma privada.

Observação:
Os scripts fornecidos para a cópia rsync desses são flexíveis o suficiente para serem adaptados a qualquer caso.
Considerações para pastas compartilhadas no secundário (OCI)
As pastas que devem ser compartilhadas entre os hosts de camada intermediária (por exemplo, diretório de domínio do Servidor Admin do Oracle WebLogic Server, home de planos de implantação, runtime compartilhado etc.) devem ser armazenadas no armazenamento compartilhado. O OCI fornece o Oracle Cloud Infrastructure File Storage como a solução do sistema de arquivos de rede.
Artefatos diferentes são pastas compartilhadas e têm uso e ciclo de vida diferentes. Eles devem ser colocados em armazenamento compartilhado separado, de acordo com seu uso. Por exemplo:
- A configuração compartilhada (por exemplo, diretório de domínio do Servidor de Administração WebLogic, home de planos de implantação) é acessada principalmente pelo host do servidor de administração. Ele é acessado internamente pelo restante dos hosts (para planos de implantação, áreas de armazenamento de chaves compartilhadas etc.). Ele deve ser colocado em um sistema de arquivos do Oracle Cloud Infrastructure File Storage.
- Se o sistema usar artefatos de pasta compartilhada para runtime (por exemplo, arquivos criados e lidos pelo aplicativo), ele normalmente será usado simultaneamente por todos os hosts de camada intermediária. Você deve colocar artefatos de runtime em outro sistema de arquivos do Oracle Cloud Infrastructure File Storage ou em uma montagem do DBFS (Database File System).
Considerações para armazenamento de pastas privadas no secundário (OCI)
Os binários e as configurações locais do FMW são usados por cada host individualmente. É uma prática recomendada armazená-los no armazenamento externo em vez de no volume de inicialização padrão dos hosts.
- No OCI, você pode armazenar os binários do FMW no Oracle Cloud Infrastructure Block Volumes para cada host. Quando há mais de dois hosts de camada intermediária, é uma boa prática usar homes binários compartilhados redundantes (consulte o Guia de Alta Disponibilidade). Para fazer isso, use o Oracle Cloud Infrastructure File Storage para armazenar os binários FMW.
- Você pode armazenar a configuração local (por exemplo, diretórios de domínio do servidor gerenciado WebLogic e pasta do gerenciador de nós) no Oracle Cloud Infrastructure Block Volumes porque espera-se que eles sejam usados de forma privada por cada host. Como alternativa, você pode usar sistemas de arquivos do Oracle Cloud Infrastructure File Storage montados de forma privada por cada nó.
Para facilitar a cópia do site principal para o remoto, é possível montar os arquivos de armazenamento em um nó exclusivo e executar a cópia rsync em uma única operação (para Volumes em Blocos, outro host pode montar os arquivos no modo somente leitura). Como alternativa, a cópia pode ser feita individualmente, de cada um dos nós que armazena os dados de modo privado.

Observação:
Os scripts fornecidos para a cópia rsync desses são flexíveis o suficiente para serem adaptados a qualquer caso.
Replicação de armazenamento
Não há replicação direta no nível de armazenamento entre local e OCI. A cópia dos binários e da configuração do principal para o stand-by é executada com rsync no SSH (Secure Shell) por meio de uma conexão privada no Oracle Cloud Infrastructure FastConnect ou VPN Site a Site (nunca use a internet pública). A cópia dos artefatos de configuração e de runtime também pode ser baseada no DBFS, dependendo das necessidades do cliente. Mais detalhes sobre esse assunto são fornecidos mais adiante.
WebLogic armazenamentos persistentes
Supõe-se que os armazenamentos Persistentes WebLogic usados para mensagens TLOGS e JMS sejam armazenamentos persistentes JDBC e armazenados em tabelas de banco de dados. Dessa forma, os armazenamentos persistentes são acessíveis de qualquer membro do cluster (para fornecer HA local com Migração de Serviço). Isso também aproveita o Oracle Data Guard subjacente, que replica automaticamente o TLOGS e o JMS para o site secundário.

Considerações para o Banco de Dados

Considere o seguinte ao configurar os bancos de dados:

Várias Locações
O banco de dados principal deve ser um banco de dados multitenant (CDB/PDB). É necessário configurar um Oracle Data Guard híbrido no Oracle Cloud Infrastructure.
Níveis de patch
O Oracle Home do banco de dados local deve estar no mesmo nível de patch do banco de dados stand-by.
Criptografia transparente de dados
Use TDE (Transparent Data Encryption) para os bancos de dados principal e standby a fim de garantir que todos os dados sejam criptografados. Se o banco de dados local ainda não estiver ativado com TDE, é altamente recomendável converter em TDE antes de configurar o Oracle Data Guard para fornecer o ambiente mais seguro.
Alta disponibilidade
Para obter Alta Disponibilidade local no nível do banco de dados e seguir a topologia EDG, use o Oracle Real Application Clusters (Oracle RAC) para os bancos de dados principal e stand-by. Embora focado no Oracle RAC, esse procedimento é aplicável a um único banco de dados. No entanto, a prática recomendada é usar o Oracle RAC para obter Alta Disponibilidade local na camada de bd.
Serviço de banco de dados
A camada intermediária principal local deve usar um serviço de banco de dados de aplicativo para estabelecer conexão com o banco de dados principal.
Sistema de Banco de Dados do Oracle Cloud Infrastructure (OCI)
Use um Sistema de BD do OCI (bare metal, máquina virtual ou Oracle Exadata Database Service) como o banco de dados stand-by. Um Oracle Autonomous Database, compartilhado ou dedicado, está fora do escopo deste documento. Ele não fornece vários recursos necessários para a configuração de recuperação de desastres híbridos, como a capacidade de configurar o Oracle Data Guard com um banco de dados local e a conversão de snapshots standby.
Alias TNS nas strings de conexão do banco de dados WebLogic
Este documento usa um alias TNS para definir a string de conexão do banco de dados na configuração do Oracle WebLogic. O alias TNS é resolvido com um arquivo tnsnames.ora, que é diferente em cada site e aponta para o banco de dados local. Como o mesmo nome de alias é usado no principal e no secundário, não é necessário alterar a configuração WebLogic após replicá-la do principal para o secundário.

Se o principal ainda não estiver usando essa abordagem, uma configuração única inicial será necessária. Os detalhes sobre isso são descritos mais adiante neste documento.

Considerações para o Gerenciamento de Identidades

Considere o seguinte ao configurar o Gerenciamento de Identidades:

LDAP (Lightweight Directory Access Protocol)
O sistema pode usar um LDAP externo para autenticação (por exemplo, Oracle Unified Directory), desde que o LDAP externo possa ser acessado nos sistemas principal e stand-by.
Solução de recuperação de desastres para LDAP
A solução de recuperação de desastres para qualquer serviço LDAP externo está fora do escopo deste documento e deve ser fornecida pelo produto LDAP específico. A solução de DR para LDAP deve fornecer uma maneira exclusiva de acessá-la (normalmente um nome de host virtual), que não é alterada quando há uma alternância no sistema LDAP.

Resumo de Considerações

A seguir, há um resumo do que você deve considerar ao planejar uma solução de recuperação de desastres.

Considerações para	Resumo	Obrigatório ou Altamente Recomendado
Topologia	O sistema principal é um ambiente local existente.	Altamente Recomendado
Topologia	O sistema secundário está no Oracle Cloud Infrastructure (OCI) é criado do zero no OCI.	Obrigatório
Topologia	Os sistemas primário e secundário são simétricos e têm o mesmo número de nós nas camadas db, mid-tier e web.	Obrigatório
Topologia	A camada Web principal consiste em um balanceador de carga na frente do Oracle HTTP Server.	Altamente Recomendado
Topologia	Os sistemas primário e secundário usam recursos semelhantes (CPU, memória etc.).	Obrigatório
Rede	Use o OCI FastConnect para conectividade entre local e OCI, como alternativa VPN Site a Site. Nunca internet pública.	Obrigatório
Rede	Desative a conectividade entre os hosts de camada intermediária e o banco de dados remoto. Só será necessário se o Oracle Database File System (DBFS) for usado para replicar a configuração.	Altamente Recomendado
Rede	Use nomes de host virtual para endereços de listening do servidor WebLogic.	Altamente Recomendado
Rede	IP Virtual para o Servidor de Administração.	Altamente Recomendado
Rede	Endereço front-end virtual.	Obrigatório
Armazenamento	Estrutura de diretório baseada em EDG.	Altamente Recomendado
Armazenamento	Pastas privadas e compartilhadas locais em armazenamento externo para que possam ser montadas a partir de um nó exclusivo para centralizar operações rsync.	Altamente Recomendado
Armazenamento	Configuração compartilhada do OCI no Oracle Cloud Infrastructure File Storage.	Obrigatório
Armazenamento	Runtime compartilhado do OCI no OCI File Storage ou no Oracle Database File System (DBFS).	Obrigatório
Armazenamento	Pastas de binários do OCI FMW no OCI File Storage montadas em privado.	Altamente Recomendado
Armazenamento	Configurações locais do OCI no Oracle Cloud Infrastructure Block Volumes (como alternativa, o OCI File Storage foi montado em privado).	Altamente Recomendado
Armazenamento	Montagem de DBFS de preparação (somente quando a réplica baseada em DBFS para a configuração é usada).	Altamente Recomendado
Armazenamento	Replicação de armazenamento baseada em `rsync` (ou DBFS para alguns artefatos específicos, como configuração).	Altamente Recomendado
Armazenamento	WebLogic armazenamentos persistentes (TLOGS, JMS) em armazenamentos persistentes JDBC.	Obrigatório (*se as informações do JMS forem relevantes)
Banco de Dados	O nível de patch do banco de dados local é igual ao banco de dados standby.	Obrigatório
Banco de Dados	TDE (Transparent Data Encryption) para os bancos de dados principal e standby. Se o banco de dados local ainda não estiver ativado com TDE, é altamente recomendável converter em TDE antes de configurar o Oracle Data Guard.	Obrigatório
Banco de Dados	Oracle RAC Database para Alta Disponibilidade local.	Altamente Recomendado
Banco de Dados	Banco de dados principal multitenancy.	Obrigatório
Banco de Dados	Use um serviço de banco de dados de aplicativo, não o serviço de administração padrão, para estabelecer conexão com o banco de dados.	Obrigatório
Banco de Dados	No OCI, use o Sistema de BD (BM, VM ou Oracle Exadata Database Service), não o Oracle Autonomous Database.	Obrigatório
Banco de Dados	Alias de TNS nas strings de conexão do banco de dados WebLogic.	Altamente Recomendado
Gerenciamento de Identidades	O sistema pode usar um LDAP externo para autenticação (por exemplo, Oracle Unified Directory), desde que o LDAP externo possa ser acessado nos sistemas principal e stand-by.	Obrigatório (usar LDAP externo NÃO é obrigatório, mas se for usado, deve ser acessível em ambos os sites)
Gerenciamento de Identidades	A solução de recuperação de desastres para qualquer serviço LDAP externo está fora do escopo deste documento e deve ser fornecida pelo produto LDAP específico. A solução de DR para LDAP deve fornecer uma maneira única de acessá-la (normalmente um nome de host virtual), que não muda quando há um switchover no sistema LDAP.	Obrigatório (usar LDAP externo NÃO é obrigatório, mas se for usado e estiver protegido por DR, ele deverá fornecer um endereço de acesso virtual que permaneça o mesmo quando um switchover/failover acontecer para a maneira LDAP de acessá-lo)

Sobre Serviços e Funções Obrigatórios

Esta solução requer os seguintes serviços e atribuições:

Essas são as atribuições necessárias para cada serviço.

Nome do Serviço: Atribuição	Necessário para...
Oracle Cloud Infrastructure: `administrator`	Crie os recursos necessários na tenancy do OCI: compartimento, Sistema de BD, instâncias de computação, recursos do FSS e Balanceador de Carga.
Rede: `administrator`	Configure os recursos de rede necessários no local e no OCI: Fast Connect, VCNs e sub-redes no OCI, regras de segurança de rede e regras de roteamento.
Oracle Data Guard: `root`, `oracle` e `sysdba`	Configure o Oracle Data Guard entre o OCI principal local e o OCI stand-by e execute conversões de atribuição.
Oracle Database: `sysdba`	Gerenciar os bancos de dados.
Oracle WebLogic Server: `root`, `oracle`	Configure os hosts de camada intermediária conforme necessário: execute a configuração no nível do SO, adicione aliases de host, gerencie endereços IP virtuais e monte sistemas de arquivos.
Oracle WebLogic Server: `Weblogic Administrator`	Gerenciar o Oracle WebLogic Server: interromper, iniciar e aplicar as alterações de configuração do WebLogic.

Consulte https://docs.oracle.com/pls/topic/lookup?ctx=en/solutions/soa-dr-on-cloud&id=GCSSL para obter os serviços de nuvem necessários.