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 híbrida de recuperação de desastres (DR) para o sistema Oracle SOA Suite, familiarize-se com as melhores práticas de Alta Disponibilidade na rede, armazenamento e configuração de host para sistemas Oracle WebLogic Server on-premises.

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, é usado com frequência 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 rede, armazenamento e host, antes de implantar um sistema híbrido.

Para obter mais detalhes, consulte:

Oracle Fusion Middleware High Availability Guide
Guia de Implantação Empresarial do Oracle Fusion Middleware para o Oracle SOA Suite
Guias de Implantação do Oracle Fusion Middleware Enterprise em Melhores Práticas de MAA - Oracle Fusion Middleware

Certifique-se de também estar familiarizado com os conceitos e a administração do Oracle Cloud Infrastructure.

Arquitetura

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

O sistema principal é um sistema Oracle SOA Suite localizado on-premises. 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 on-premises.

A camada intermediária na OCI é criada instalando SOA em máquinas virtuais (VMs) da OCI e não em uma instância do Oracle SOA Cloud Service ou do Oracle SOA Suite on Marketplace (há restrições em versões do SO, usuários do SO e 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 stand-by para um sistema on-premises).

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

A seguir, descrição de maa-soa-hybrid-dr.png

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

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

Essa arquitetura suporta os seguintes componentes no data center local principal:

Rede on-premises
Essa rede é a rede local usada por sua organização. É um dos raios da topologia.
Balanceador de Carga
Fornece distribuição de tráfego automatizada 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. Essa topologia abrange muitos componentes diferentes que geralmente são 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 em vários servidores para maximizar a disponibilidade e permitir a escalabilidade horizontal, ao mesmo tempo em que acessa o armazenamento compartilhado. As sessões do usuário que se conectam às instâncias do Oracle RAC podem fazer failover e reproduzir alterações com segurança durante interrupções, sem qualquer alteração nos aplicativos do usuário final, ocultando o impacto das interrupções dos usuários finais.

Essa arquitetura suporta os seguintes componentes no ambiente stand-by secundário no OCI:

Região
Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).
Rede virtual na nuvem (VCN) e sub-rede
Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da 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.

As sub-redes privadas são genericamente recomendadas por motivos de segurança, a menos que o recurso deva estar 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 o 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 maior largura de banda e uma experiência de rede mais confiável quando comparado com as 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 roteamento
As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente 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 do detector que você pode definir para examinar seus recursos quanto a pontos fracos de segurança e para monitorar operadores e usuários em relação a determinadas atividades arriscadas. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e auxilia na execução dessas ações, com base nas receitas do respondedor que você pode definir.
Sistema de BD
O Oracle Database System é um serviço de banco de dados da Oracle Cloud Infrastructure (OCI) que permite criar, dimensionar e gerenciar bancos de dados Oracle com todos os recursos. O Sistema de BD usa o armazenamento do OCI Block Volumes 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 serviço File Storage 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 de dados resiliente. Os dados são protegidos com a codificação de apagamento. O serviço de Armazenamento de Arquivos 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 do Oracle RAC
O Oracle Real Application Clusters (Oracle RAC) permite que os clientes executem um único Oracle Database em vários servidores para maximizar a disponibilidade e permitir a escalabilidade horizontal, ao mesmo tempo em que acessam o armazenamento compartilhado. As sessões do usuário que se conectam às instâncias do Oracle RAC podem fazer failover e reproduzir alterações com segurança durante interrupções, sem qualquer alteração 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 do Oracle RAC está na camada de banco de dados.
Data Guard
O Oracle Data Guard fornece um conjunto abrangente de serviços que criar, manter, gerenciar e monitorar um ou mais bancos de dados stand-by 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 stand-by 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 stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção.

Descrição da Topologia

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

Na db-tier, 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 camada intermediária secundária é instalada em máquinas virtuais (VMs) da OCI. Os binários do Oracle Fusion Middleware e o Domínio SOA são uma réplica dos binários principais e do Domínio SOA, 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 WebLogic Server 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 da Web no data center principal segue o modelo EDG (Enterprise Deployment Guide) 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, apenas 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 do 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 stand-by é físico. Ele está no estado de montagem ou é aberto no modo somente leitura quando o Active Data Guard é usado. O banco de dados stand-by recebe e aplica redo do banco de dados principal, mas não pode ser aberto no modo de 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 SOA (Server Oriented Architecture), informações do Oracle Platform Security Services, esquemas personalizados, logs de transação (TLOGs), armazenamentos persistentes JDBC (Java Database Connectivity) e muito mais.

Durante as etapas de configuração de DR e validação do ciclo de vida descritas neste documento, você pode converter o banco de dados stand-by de um stand-by físico em um stand-by snapshot para validar o site secundário sem executar um switchover completo. Um banco de dados no modo stand-by snapshot é um banco de dados totalmente atualizável. Um banco de dados stand-by snapshot recebe e arquiva, mas não se aplica, aos dados redo recebidos de um banco de dados principal. Todas as alterações aplicadas a um stand-by 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 de DR e também é necessária durante o ciclo de vida contínuo do sistema. Quando as alterações de configuração são realizadas no domínio primário, elas devem ser replicadas para o local secundário.

Quando um banco de dados stand-by é submetido a shutdown durante a operação normal de negócios, ele não recebe atualizações do banco de dados principal e pode ficar fora de sincronia. Como isso pode resultar em perda de dados em um cenário de switchover, não é recomendável interromper o banco de dados stand-by durante a operação comercial normal. Os hosts da camada intermediária stand-by podem ser interrompidos. No entanto, quando os 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 ocorre um switchover, o RTO (Recovery Time Objective) é aumentado, pois os hosts de camada intermediária stand-by devem ser iniciados e o domínio sincronizado com as alterações principais.

Considerações para Topologia

Estas são as suposições 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á na Oracle Cloud Infrastructure (OCI)
O sistema secundário é criado do zero na 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
Este documento está 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), as especificidades e a capacidade de suporte desses componentes são excluídas 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, na camada Web e na camada db. Pode haver diferenças na camada da camada Web quando o Balanceador de Carga do OCI é usado sozinho no OCI (sem o Oracle HTTP Server).
Os sistemas primário e secundário usam recursos semelhantes
Embora as formas disponíveis do OCI 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 uma capacidade 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 transferida para o sistema OCI.

Considerações para Rede

Considere o seguinte ao configurar a rede:

Conectividade entre a rede local e a 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 transporte do Oracle Data Guard redo. Os hosts da camada intermediária on-premises e 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 fornece conectividade segura entre o local e o OCI. No entanto, isso fornece menor largura de banda e latência variável, jitter e custo.
Desativar a 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 on-premises e a OCI geralmente desencoraja essa conectividade cruzada. Para evitar conexões acidentais e problemas de carga de trabalho, exclua 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 virtual, em vez do nome do host do nó físico, como endereços de listening para os Oracle WebLogic Servers. Os nomes de host virtual normalmente são aliases do nome de host do nó físico. O uso de nomes de host virtual 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 no principal como um alias em cada nó (conforme resolvido no DNS ou no local /etc/hosts).
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 precisam usar endereços IP virtuais. Somente o Servidor de Administração precisa de um VIP para failover local. Como prática recomendada, supõe-se que o Servidor de Administração no sistema local principal escute 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 rígido para configurar o Disaster Recovery no OCI com este documento. Se o Servidor de Administração principal não escutar 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 principal deve usar um nome de front-end virtual (um URL personalizado, como mysoa.example.com) como ponto de entrada para os clientes. Esse nome de front-end é resolvido no DNS com o endereço IP do balanceador de carga principal. Em uma topologia de DR, o sistema secundário é configurado para usar o mesmo nome de 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 que está sendo usado como principal. O mesmo se aplica a qualquer nome de 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 de Controle do Fusion Middleware.

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 Armazenamento

Considere o seguinte ao configurar o armazenamento:

Estrutura de diretórios baseada em EDG
Este documento usa uma estrutura de diretório do EDG (Enterprise Deployment Guide) para a configuração de domínio do sistema principal do Oracle WebLogic Server. O modelo EDG usa diretórios de domínio separados para o Oracle WebLogic Server de administração 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 aos detalhes 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 Servidor Admin do Oracle WebLogic Server, home dos planos de implantação, runtime compartilhado etc.), mas também os binários do 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 stand-by. 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 eles residirem em armazenamento compartilhado. Usando essa abordagem, é possível montar todos eles a partir 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 scripts são flexíveis o suficiente para serem adaptados a qualquer caso.
Considerações para pastas compartilhadas no OCI (secundário)
As pastas que devem ser compartilhadas entre os hosts da camada intermediária (por exemplo, diretório de domínio do Servidor Admin do Oracle WebLogic Server, home dos planos de implantação, runtime compartilhado etc.) devem ser armazenadas no armazenamento compartilhado. A OCI fornece o Oracle Cloud Infrastructure File Storage como a solução de sistema de arquivos de rede.
Diferentes artefatos 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 Servidor de Administração do WebLogic Server, home dos planos de implantação) é acessada principalmente pelo host do servidor de administração. Ele é acessado residualmente 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 uma pasta compartilhada para artefatos de 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 Sistema de Arquivos de Banco de Dados (DBFS).
Considerações para armazenamento de pastas privadas no OCI (secundário)
Os binários do FMW e as configurações locais são usados por cada host individualmente. É uma boa prática 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 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 do 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 de 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 forma privada.

Observação:
Os scripts fornecidos para a cópia rsync desses scripts são flexíveis o suficiente para serem adaptados a qualquer caso.
Replicação do armazenamento
Não há replicação direta no nível de armazenamento entre o local e o OCI. A cópia dos binários e da configuração do principal para o stand-by é executada com rsync por meio do SSH (Secure Shell) em uma conexão privada no Oracle Cloud Infrastructure FastConnect ou na VPN Site a Site (nunca use a internet pública). A cópia dos artefatos de configuração e runtime também pode ser baseada no DBFS, dependendo das necessidades do cliente. Mais detalhes sobre isso serão fornecidos posteriormente.
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:

Multitenancy
O banco de dados principal deve ser um banco de dados multitenant (CDB/PDB). Isso é necessário para configurar um Oracle Data Guard híbrido no Oracle Cloud Infrastructure.
Níveis do 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 a Criptografia Transparente de Dados (TDE) para os bancos de dados principal e stand-by para garantir que todos os dados sejam criptografados. Se o banco de dados local ainda não estiver ativado com TDE, é altamente recomendável converter para 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 com foco 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 banco de dados.
Serviço de banco de dados
A camada intermediária local principal 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 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 desastre híbrida, como a capacidade de configurar o Oracle Data Guard com um banco de dados local e a conversão de snapshot stand-by.
Alias de TNS em strings de conexão de 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 primário e no secundário, você não precisa alterar a configuração WebLogic depois de replicá-la do primário para o secundário.

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

Considerações para 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 pelos 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 única de acessá-la (normalmente um nome de host virtual), que não muda quando há um switchover no sistema LDAP.

Resumo de Considerações

Veja a seguir um resumo do que você deve considerar ao planejar uma solução de recuperação de desastres.

Considerações sobre	Resumo	Obrigatório ou Altamente Recomendado
Topologia	O sistema principal é um ambiente local existente.	Altamente Recomendado
Topologia	O sistema secundário está no OCI (Oracle Cloud Infrastructure) e é criado do zero no OCI.	Obrigatória
Topologia	Os sistemas primário e secundário são simétricos e têm o mesmo número de nós em db-tier, mid-tier e web-tier.	Obrigatória
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ória
Rede	Use o OCI FastConnect para conectividade entre o local e o OCI, como alternativa, VPN Site a Site. Nunca a internet pública.	Obrigatória
Rede	Desative a conectividade entre hosts de camada intermediária e o banco de dados remoto. Só será necessário se o DBFS (Oracle Database File System) for usado para replicar a configuração.	Altamente Recomendado
Rede	Use nomes de host virtual para endereços de listener do servidor WebLogic.	Altamente Recomendado
Rede	IP Virtual do Servidor de Administração.	Altamente Recomendado
Rede	Endereço front-end virtual.	Obrigatória
Armazenamento	Estrutura de diretórios baseada em EDG.	Altamente Recomendado
Armazenamento	Pastas privadas e compartilhadas on-premises 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ória
Armazenamento	Runtime compartilhado do OCI no OCI File Storage ou no Oracle Database File System (DBFS).	Obrigatória
Armazenamento	Pastas de binários do OCI FMW no OCI File Storage montadas de forma privada.	Altamente Recomendado
Armazenamento	Configurações locais do OCI no Oracle Cloud Infrastructure Block Volumes (como alternativa, o OCI File Storage foi montado de forma privada).	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 JMS forem relevantes)
Banco de Dados	Nível de patch do banco de dados local igual ao banco de dados stand-by.	Obrigatória
Banco de Dados	Criptografia Transparente de Dados (TDE) para os bancos de dados principal e stand-by. Se o banco de dados local ainda não estiver ativado com TDE, é altamente recomendável converter para TDE antes de configurar o Oracle Data Guard.	Obrigatória
Banco de Dados	Banco de Dados Oracle RAC para Alta Disponibilidade local.	Altamente Recomendado
Banco de Dados	Banco de dados multitenancy principal.	Obrigatória
Banco de Dados	Use um serviço de banco de dados de aplicativos, não o serviço de administração padrão, para estabelecer conexão com o banco de dados.	Obrigatória
Banco de Dados	Na OCI, use o Sistema de BD (BM, VM ou Oracle Exadata Database Service), não o Oracle Autonomous Database.	Obrigatória
Banco de Dados	Alias de TNS em strings de conexão de 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 pelos sistemas principal e stand-by.	Obrigatório (usar LDAP externo NÃO é obrigatório, mas se usado, ele deverá estar acessível dos dois 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 usado e estiver protegido por DR, ele deverá fornecer um endereço de acesso virtual que permaneça o mesmo quando ocorrer um switchover/failover para a forma LDAP de acesso a ele)

Sobre Serviços e Atribuiçõ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	Obrigató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 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 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: interrompa, inicie e aplique 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.