Saiba mais sobre a Implantação do Oracle E-Business Suite no Oracle Cloud Infrastructure

Se quiser provisionar o Oracle E-Business Suite no Oracle Cloud Infrastructure ou migrar ambientes do Oracle E-Business Suite do seu data center para o Oracle Cloud Infrastructure, você poderá planejar uma topologia multihost, segura e de alta disponibilidade.

O Oracle fornece automação para provisionar, migrar e gerenciar o ciclo de vida dos ambientes Oracle E-Business Suite no Oracle Cloud Infrastructure seguindo as melhores práticas descritas neste documento. Isso pode eliminar grande parte da complexidade da implantação e gerenciamento manual. Revise o Documento 2517025.1, Conceitos Básicos do Oracle E-Business Suite e do Oracle Cloud Infrastructure para obter mais informações.

Considerações para Implantação no Oracle Cloud Infrastructure

A Oracle recomenda a criação de sub-redes separadas para suas instâncias, como host bastião, banco de dados, aplicativo e instâncias do balanceador de carga, para garantir que os requisitos de segurança apropriados possam ser implementados nas diferentes sub-redes.

Sub-redes Privadas ou Públicos

Você pode criar instâncias em uma sub-rede privada ou pública com base no fato de desejar permitir o acesso às instâncias pela Internet. As instâncias criadas em uma sub-rede pública recebem um endereço IP público e você pode acessar essas instâncias pela Internet. Não é possível designar um endereço IP público a instâncias criadas em uma sub-rede privada. Portanto, você não pode acessar essas instâncias pela internet.

A imagem a seguir mostra uma rede virtual na nuvem (VCN) com sub-redes públicas e privadas. A VCN contém dois domínios de disponibilidade e cada domínio de disponibilidade contém uma sub-rede pública e privada. Os servidores Web são colocados na sub-rede pública desta imagem, portanto, cada instância do servidor Web tem um endereço IP público anexado a ela. Você pode acessar essas instâncias da Oracle Cloud na sub-rede pública pela internet ativando a comunicação por meio do IGW (gateway de internet). Você terá que atualizar a tabela de roteamento para permitir o tráfego de e para o IGW. Para permitir o tráfego para os servidores Web a partir da Internet, você deve criar balanceadores de carga na sub-rede pública. Para acessar suas instâncias pela internet, você também precisa criar um host bastião na sub-rede pública e acessar o host bastião pelo IGW.

Os servidores de banco de dados são colocados na sub-rede privada desta imagem. Você pode acessar instâncias da Oracle Cloud na sub-rede privada de seus data centers conectando-se por meio do gateway de roteamento dinâmico (DRG). O DRG conecta suas redes locais à sua rede na nuvem. Para ativar a comunicação entre o DRG e o equipamento local do cliente, use o IPSec VPN ou o Oracle Cloud Infrastructure FastConnect. Você também precisará atualizar a tabela de roteamento para permitir o tráfego de e para a DRG.

Descrição da ilustração public_private_subnets_jde.png

Cenário 1: Implantar Todas as Instâncias em Sub-redes Privadas

A Oracle recomenda implantar todas as instâncias em sub-redes privadas para ambientes de produção onde não há pontos finais voltados para a Internet. Esse tipo de implantação é útil quando você deseja ter uma implantação híbrida com a nuvem como uma extensão para seus data centers existentes.

Nesta implantação, todas as instâncias, incluindo servidores de aplicativos e bancos de dados, são implantadas em uma sub-rede privada. Um endereço IP público não pode ser designado a instâncias criadas em uma sub-rede privada; portanto, você não pode acessar essas instâncias pela internet. Para acessar seus servidores de aplicativos em seu ambiente local nesta configuração, você pode:

Configure um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG antes de provisionar os servidores de aplicativos.
Crie um host bastion nesta configuração e acesse todos os servidores na sub-rede privada a partir do host bastion.

Cenário 2: Implantar Instâncias em Sub-redes Pública e Privada

Você pode implantar algumas instâncias em uma sub-rede pública e algumas instâncias em uma sub-rede privada. Esse tipo de implantação é útil quando a implantação inclui endpoints voltados para a Internet e não voltados para a Internet.

Nessa configuração, algumas instâncias da aplicação são colocadas em uma sub-rede pública e outras em uma sub-rede privada. Por exemplo, você pode ter instâncias da aplicação que atendem usuários internos e outro conjunto de instâncias da aplicação que atendem usuários externos. Nesse cenário, coloque as instâncias do aplicativo que atendem ao tráfego interno em uma sub-rede privada e coloque os servidores de aplicativos que atendem ao tráfego externo em uma sub-rede pública. Você também pode configurar um balanceador de carga público nas instâncias da aplicação voltadas para a Internet, em vez de colocar os servidores de aplicações que atendem ao tráfego externo em uma sub-rede pública. Se você colocar o bastion host em uma sub-rede pública, o bastion host receberá um endereço IP público e você poderá acessá-lo pela Internet. Você pode acessar suas instâncias na sub-rede privada por meio do servidor bastion.

Cenário 3: Implantar Todas as Instâncias em Sub-redes Públicas

A Oracle recomenda essa implantação para demonstrações rápidas ou para implantações de nível de produção sem pontos finais internos. Essa implantação só é adequada se você não tiver seu próprio data center ou não puder acessar instâncias por VPN e quiser acessar a infraestrutura pela Internet.

Nesta implantação, todas as instâncias, incluindo a aplicação e as instâncias do banco de dados, são implantadas em sub-redes públicas.

Cada instância da sub-rede pública tem um endereço IP público anexado a ela. Embora instâncias com endereços IP públicos possam ser acessadas pela internet, você pode restringir o acesso usando listas de segurança e regras de segurança. Para executar tarefas de administração, a Oracle recomenda que você coloque um host bastião nesta configuração. Nesse cenário, você não abriria portas de administração para a internet pública, mas abriria as portas de administração apenas para o host bastião e configuraria listas de segurança e regras de segurança para garantir que a instância só possa ser acessada a partir do host bastião.

Anti-Afinidade

Ao criar várias instâncias para alta disponibilidade em um domínio de disponibilidade no Oracle Cloud Infrastructure, a antiafinidade das instâncias pode ser obtida usando domínios de falha.

Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade contém três domínios de falha. Os domínios de falha permitem distribuir suas instâncias de forma que elas não fiquem no mesmo hardware físico de um único domínio de disponibilidade. Portanto, uma falha de hardware ou manutenção de hardware do Oracle Compute que afete um domínio de falha não afeta instâncias em outros domínios de falha. Usando domínios de falha, você pode proteger suas instâncias contra falhas de hardware inesperadas e interrupções planejadas.

Para alta disponibilidade de bancos de dados, você pode criar um sistema de BD VM (Virtual Machine) de 2 nós, que fornece Oracle RAC (Oracle Real Applications Clusters). Os dois nós do Oracle RAC são sempre criados em domínios de falha separados por padrão. Também é possível escolher manualmente um domínio de falha para os nós RAC durante o provisionamento do banco de dados Oracle RAC. Portanto, os nós do banco de dados não estão no mesmo host físico nem no mesmo rack físico. Isso protege as instâncias do banco de dados contra as falhas subjacentes do host físico e do switch top-of-the-rack.

Arquitetura

Você pode projetar sua implantação do Oracle E-Business Suite no Oracle Cloud Infrastructure em um único domínio de disponibilidade, em vários domínios de disponibilidade ou em várias regiões. Além disso, você pode incorporar uma zona desmilitarizada para isolar o tráfego externo e proteger os sistemas internos.

Domínio de disponibilidade único: Você pode implantar o Oracle E-Business Suite em um único domínio de disponibilidade e ainda garantir alta disponibilidade configurando várias instâncias da aplicação. Use essa arquitetura quando quiser garantir que sua aplicação esteja disponível mesmo quando uma instância da aplicação for desativada. As outras instâncias do aplicativo disponíveis no domínio de disponibilidade continuam a processar as solicitações.
Domínio de disponibilidade único com uma zona desmilitarizada (DMZ): use essa arquitetura quando quiser que seu aplicativo seja acessível de redes externas não confiáveis enquanto os sistemas internos estiverem isolados da rede externa.
Vários domínios de disponibilidade: use essa arquitetura quando quiser garantir que sua aplicação esteja disponível mesmo quando um domínio de disponibilidade for desativado. Você ainda pode acessar as instâncias da aplicação em outro domínio de disponibilidade.
Várias regiões: use essa arquitetura quando quiser configurar um site de recuperação de desastres para seu aplicativo em uma região diferente. Essa arquitetura é essencialmente a mesma que a arquitetura de vários domínios de disponibilidade, mas em vez de criar recursos em um segundo domínio de disponibilidade na mesma região, você cria recursos em outra região.

Observação:

Você também pode configurar um DMZ nos casos de vários domínios de disponibilidade e várias regiões.

Arquitetura para Implantar o Oracle E-Business Suite em um Único Domínio de Disponibilidade

Esta arquitetura mostra a implantação de uma aplicação Oracle E-Business Suite em um único domínio de disponibilidade, garantindo ao mesmo tempo alta disponibilidade.

A arquitetura consiste em uma rede virtual na nuvem (VCN) com bastião, balanceador de carga, aplicativo e hosts de banco de dados colocados em sub-redes separadas do VCN em um único domínio de disponibilidade. No diagrama de arquitetura a seguir, o host bastion é implantado em uma sub-rede pública e todas as outras instâncias são implantadas em sub-redes privadas. Você pode colocar as diferentes instâncias em sub-redes públicas ou privadas com base nas suas necessidades de negócios.

Nesta arquitetura, várias instâncias da camada da aplicação são implantadas em um único domínio de disponibilidade, mas as instâncias individuais da camada da aplicação são colocadas em domínios de falha separados, permitindo a alta disponibilidade da camada da aplicação. Os domínios de falha permitem que você distribua suas instâncias para que elas não estejam no mesmo hardware físico dentro de um único domínio de disponibilidade. Como resultado, uma falha de hardware ou manutenção de hardware que afeta um domínio de falha não afeta instâncias em outros domínios de falha.

As instâncias da sub-rede privada exigem conexão de saída com a Rede de Serviços Oracle para aplicar atualizações do sistema operacional (yum). Para isso, use um gateway de serviço na sua VCN. Com um gateway de serviço, os hosts da sub-rede privada podem acessar serviços Oracle suportados (como o repositório yum) de forma privada. As instâncias na sub-rede privada podem, opcionalmente, exigir conexão de saída com a Internet para fazer download de patches de aplicativos e para integrações externas. Para isso, use um gateway NAT (Network Address Translation) na sua VCN. Com um gateway NAT, os hosts da sub-rede privada podem iniciar conexões com a Internet e receber respostas, mas não receberão conexões de entrada iniciadas pela Internet.

Todas as instâncias do aplicativo no domínio de disponibilidade estão ativas. As instâncias do balanceador de carga recebem solicitações e as enviam para os servidores de aplicativos. Os servidores de aplicativos processam essas solicitações e as encaminham para as instâncias do banco de dados. Você pode acessar as instâncias em sub-redes privadas pela porta 22 por meio do bastion host ou do gateway de Roteamento Dinâmico (DRG) se tiver configurado um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG.

A Oracle recomenda que o banco de dados e os aplicativos implantados no Oracle Cloud Infrastructure tenham uma estratégia robusta de backup e recuperação. É recomendável armazenar backups de bancos de dados e instâncias da aplicação no Oracle Cloud Infrastructure Object Storage. É possível fazer backup dos bancos de dados e instâncias da camada da aplicação em sub-redes privadas para a Oracle Cloud Infrastructure Object Storage usando um gateway de serviço. Um gateway de serviço fornece acesso ao Oracle Cloud Infrastructure Object Storage sem passar pela Internet.

Os backups automáticos e sob demanda do banco de dados para o Oracle Cloud Infrastructure Object Storage podem ser configurados usando a console do Oracle Cloud Infrastructure. Isso requer conectividade com o Oracle Cloud Infrastructure Object Storage usando um ponto final Swift. Todos os backups do banco de dados no Oracle Cloud Infrastructure Object Storage são criptografados com a mesma chave mestra usada para criptografia de wallet TDE (Transparent Data Encryption). O serviço de backup automático de banco de dados usa a estratégia de backup incremental semanal para fazer backup de bancos de dados com uma política de retenção personalizada que você pode personalizar ao configurar backups automáticos.

O backup do aplicativo pode ser configurado usando o recurso de backup baseado em política do Oracle Cloud Infrastructure Block Volumes. O Oracle Cloud Infrastructure Block Volumes fornece a você a capacidade de executar backups de volume automaticamente com base em uma programação e retê-los com base na política de backup selecionada. Isso permite que você cumpra seus requisitos regulamentares e de conformidade de dados. Existem três políticas de backup predefinidas: Bronze, Prata e Ouro. Cada política de backup tem uma frequência de backup e um período de retenção predefinidos.

Descrição da ilustração single_availability_domain_ha_topology.png

Essa arquitetura suporta os seguintes componentes:

Host Bastion: O host bastion é um componente opcional que pode ser usado como um servidor jump para acessar instâncias na sub-rede privada. Um bastion host é uma instância do Oracle Cloud Infrastructure Compute que usa o Linux como seu sistema operacional. Coloque o bastião host em uma sub-rede pública e designe-lhe um endereço IP público para acessá-lo a partir da Internet.

Para fornecer um nível adicional de segurança, você pode configurar listas de segurança para acessar o bastion host somente a partir do endereço IP público da sua rede local. Você pode acessar instâncias do Oracle Cloud Infrastructure na sub-rede privada por meio do host bastion. Para fazer isso, ative o encaminhamento ssh-agent, que permite que você se conecte ao host bastion e acesse o próximo servidor encaminhando as credenciais do seu computador. Você também pode acessar as instâncias na sub-rede privada usando o túnel SSH dinâmico. O túnel SSH é uma maneira de acessar uma aplicação Web ou outros serviços de listening. O túnel dinâmico fornece um proxy SOCKS na porta local, mas as conexões são originadas do host remoto.
Camada do Balanceador de Carga: esta camada contém o Oracle Cloud Infrastructure Load Balancing. Ele recebe solicitações de usuários de aplicativos e, em seguida, balanceia o tráfego para servidores de aplicativos Oracle E-Business Suite. Use o Oracle Cloud Infrastructure Load Balancing para distribuir tráfego para as instâncias da aplicação dentro de um VCN. Este serviço fornece uma instância principal e stand-by do balanceador de carga para garantir que, se o balanceador de carga principal ficar inativo, o balanceador de carga stand-by encaminhará as solicitações. O balanceador de carga garante que as solicitações sejam roteadas para as instâncias do aplicativo íntegras. Se houver um problema com uma instância do aplicativo, o balanceador de carga removerá essa instância da configuração e iniciará o roteamento de solicitações para as instâncias do aplicativo íntegras restantes.
Camada da aplicação: esta camada contém mais de uma instância de uma aplicação Oracle E-Business Suite para fornecer alta disponibilidade. Configure várias instâncias de um aplicativo em um domínio de falha separado para garantir que você possa continuar acessando o aplicativo mesmo que uma instância do aplicativo seja desativada.

A Oracle recomenda implantar a configuração de várias camadas do Oracle E-Business Suite com binários de aplicativos compartilhados. Use o Oracle Cloud Infrastructure File Storage para criar um sistema de arquivos compartilhado para compartilhar binários da aplicação Oracle E-Business Suite.
Camada do banco de dados: esta camada contém instâncias do Oracle Cloud Infrastructure Database. Para requisitos de alta disponibilidade, a Oracle recomenda o uso de um sistema de BD VM (Virtual Machine) de 2 nós ou Exadata DB System.

Arquitetura para Implantar o Oracle E-Business Suite com uma Zona Desmilitarizada (DMZ)

Esta arquitetura mostra a implantação de uma aplicação Oracle E-Business Suite em um único domínio de disponibilidade contendo um DMZ.

A arquitetura consiste em uma rede virtual na nuvem (VCN) com o bastion host, um balanceador de carga interno, uma camada de aplicação interna, um balanceador de carga externo, uma camada de aplicação externa e hosts de banco de dados colocados em sub-redes separadas da VCN em um único domínio de disponibilidade. No diagrama de arquitetura a seguir, o balanceador de carga externo é implantado em uma sub-rede pública e todas as outras instâncias são implantadas em sub-redes privadas.

Veja a seguir a descrição da ilustração ebs-singlead-dmz.png
Descrição da ilustração ebs-singlead-dmz.png

O DMZ, que é implementado usando uma sub-rede pública do balanceador de carga, recebe solicitações de parceiros comerciais e fornecedores, enquanto o balanceador de carga interno, implementado usando uma sub-rede privada do balanceador de carga, recebe solicitações de usuários internos. As camadas de aplicativos dedicadas processam as solicitações provenientes desses dois tipos diferentes de usuários.

A Oracle recomenda que o banco de dados e os aplicativos implantados no Oracle Cloud Infrastructure tenham uma estratégia robusta de backup e recuperação. É recomendável armazenar backups de bancos de dados e instâncias da camada da aplicação no Oracle Cloud Infrastructure Object Storage. É possível fazer backup dos bancos de dados e instâncias da camada da aplicação em sub-redes privadas para a Oracle Cloud Infrastructure Object Storage usando um gateway de serviço. Um gateway de serviço fornece acesso ao Oracle Cloud Infrastructure Object Storage sem passar pela Internet.

Essa arquitetura suporta os seguintes componentes:

Host Bastion: O host bastion é um componente opcional que pode ser usado como um servidor jump para acessar instâncias na sub-rede privada. Um bastion host é uma instância do Oracle Cloud Infrastructure Compute que usa o Linux como seu sistema operacional.

Para fornecer um nível adicional de segurança, você pode configurar listas de segurança para acessar o bastion host somente a partir do endereço IP público da sua rede local. Você pode acessar instâncias do Oracle Cloud Infrastructure na sub-rede privada por meio do host bastion. Para fazer isso, ative o encaminhamento ssh-agent, que permite que você se conecte ao bastion host e acesse o próximo servidor encaminhando as credenciais do seu computador. Você também pode acessar as instâncias na sub-rede privada usando o túnel SSH dinâmico. O túnel SSH é uma maneira de acessar uma aplicação Web ou outros serviços de listening. O túnel dinâmico fornece um proxy SOCKS na porta local, mas as conexões são originadas do host remoto.
Camada do Balanceador de Carga Interno Esta camada contém o Oracle Cloud Infrastructure Load Balancing. Ele recebe solicitações de usuários internos da aplicação e, em seguida, balanceia o tráfego para servidores internos da aplicação Oracle E-Business Suite. Use o Oracle Cloud Infrastructure Load Balancing para distribuir tráfego para as instâncias da aplicação dentro de um VCN. Este serviço fornece uma instância principal e stand-by do balanceador de carga para garantir que, se o balanceador de carga principal ficar inativo, o balanceador de carga stand-by encaminhará as solicitações. O balanceador de carga garante que as solicitações sejam roteadas para as instâncias do aplicativo íntegras. Se houver um problema com uma instância do aplicativo, o balanceador de carga removerá essa instância da configuração e iniciará o roteamento de solicitações para as instâncias do aplicativo íntegras restantes.
Camada do Balanceador de Carga Externo: esta camada serve para a mesma finalidade que a camada do balanceador de carga interno, mas para usuários de aplicativos externos, como aqueles associados aos fornecedores.
Camada da aplicação: esta camada contém mais de uma instância de uma aplicação Oracle E-Business Suite para fornecer alta disponibilidade. Configure várias instâncias de um aplicativo em um domínio de falha separado para garantir que você possa continuar acessando o aplicativo mesmo que uma instância do aplicativo seja desativada.

Nessa arquitetura, a utilização de camadas de aplicativos separadas para seus usuários internos e externos permite isolar o tráfego e proteger a segurança do sistema.

A Oracle recomenda implantar a configuração de várias camadas do Oracle E-Business Suite com binários de aplicativos compartilhados. Use o Oracle Cloud Infrastructure File Storage para criar um sistema de arquivos compartilhado para compartilhar binários da aplicação Oracle E-Business Suite.
Camada do banco de dados: esta camada contém instâncias do Oracle Cloud Infrastructure Database. Para requisitos de alta disponibilidade, a Oracle recomenda o uso de um sistema de BD VM (Virtual Machine) de 2 nós ou Exadata DB System.

Arquitetura para Implantar o Oracle E-Business Suite em Vários Domínios de Disponibilidade

Esta arquitetura mostra a implantação de uma aplicação Oracle E-Business Suite em vários domínios de disponibilidade. Ela mostra uma rede virtual na nuvem (VCN) com as instâncias bastion, balanceador de carga, aplicativo e banco de dados colocadas em sub-redes separadas em dois domínios de disponibilidade.

Vários servidores de aplicativos são implantados em cada domínio de disponibilidade para garantir alta disponibilidade dentro de um domínio de disponibilidade. Todos os servidores de aplicativos dentro de um domínio de disponibilidade são implantados em diferentes domínios de falha. Usando domínios de falha diferentes, as instâncias do aplicativo são protegidas contra falhas inesperadas de hardware e interrupções planejadas devido à manutenção de hardware. Além disso, para garantir a disponibilidade caso o domínio de disponibilidade principal não esteja disponível, instâncias redundantes são criadas em outro domínio de disponibilidade. No diagrama de arquitetura, as instâncias no Domínio de Disponibilidade 1 estão ativas e as instâncias no Domínio de Disponibilidade 2 estão em stand-by. A Oracle recomenda que você configure instâncias de aplicativo e banco de dados em topologia simétrica entre domínios de disponibilidade para garantir que suas instâncias ativas atendam a toda a carga quando o domínio de disponibilidade principal não estiver disponível. Na topologia simétrica, você implanta o mesmo número de instâncias da aplicação e do banco de dados nos sites ativo e stand-by. Quando as instâncias no Domínio de Disponibilidade 1 estiverem ativas, o balanceador de carga será configurado para direcionar o tráfego apenas para essas instâncias ativas. O balanceador de carga não está configurado para direcionar o tráfego para as instâncias do servidor de aplicativos no Domínio de Disponibilidade 2. Isso significa que as instâncias do aplicativo no Domínio de Disponibilidade 2 não são adicionadas ao conjunto de backend do balanceador de carga. Se o Domínio de Disponibilidade 1 não estiver disponível, você terá que alternar manualmente o aplicativo e o banco de dados para o outro domínio de disponibilidade. Nesse cenário, as instâncias do servidor de aplicativos e bancos de dados no Domínio de Disponibilidade 2 se tornam ativas. Neste momento, você precisa atualizar o conjunto de backend do balanceador de carga com instâncias da aplicação no Domínio de Disponibilidade 2 e também remover as instâncias da aplicação do Domínio de Disponibilidade 1. O balanceador de carga aceitará solicitações e as encaminhará aos servidores de aplicativos no Domínio de Disponibilidade 2.

Para obter um failover contínuo entre domínios de disponibilidade, use nomes de host lógicos para o banco de dados Oracle E-Business Suite e instâncias da aplicação. Use os mesmos nomes de host lógicos nos sites principal e stand-by para reduzir o esforço para reconfigurar instâncias durante a alternância ou failover.

Recomenda-se que o banco de dados e a aplicação implantados no Oracle Cloud Infrastructure tenham um backup robusto da estratégia de recuperação. É recomendável armazenar o backup de bancos de dados e instâncias da aplicação no Oracle Cloud Infrastructure Object Storage. É possível fazer backup dos bancos de dados e instâncias da aplicação em sub-redes privadas na Oracle Cloud Infrastructure Object Storage usando um gateway de serviço. Um gateway de serviço fornece acesso ao Oracle Cloud Infrastructure Object Storage sem passar pela Internet.

O serviço de backup automático de banco de dados usa estratégia de backup incremental semanal para fazer backup de bancos de dados com uma política de retenção de 30 dias. Também é possível realizar um backup completo sob demanda de bancos de dados para requisitos ad-hoc.

No diagrama de arquitetura a seguir, o host bastion é implantado em uma sub-rede pública e todas as outras instâncias são implantadas em sub-redes privadas. Você pode colocar as diferentes instâncias em sub-redes públicas ou privadas com base nas suas necessidades de negócios. Você pode acessar as instâncias em sub-redes privadas pela porta 22 por meio do bastion host ou da DRG se tiver configurado um túnel IPSec VPN entre seu data center e o Oracle Cloud Infrastructure DRG.

Descrição da ilustração multiple_availability_domain_ha_topology.png

Essa arquitetura suporta os seguintes componentes:

Host Bastion: O host bastion é um componente opcional que você pode usar como um servidor jump para acessar as instâncias da aplicação e do banco de dados. Para alta disponibilidade, implante um host bastion em ambos os domínios de disponibilidade.
Camada do Balanceador de Carga: O Oracle Cloud Infrastructure Load Balancing distribui tráfego pelos servidores de aplicativos em um domínio de disponibilidade. O balanceador de carga pode ser provisionado como um balanceador de carga público ou privado.
Camada de aplicativos: Vários servidores de aplicativos são configurados em cada domínio de disponibilidade para garantir alta disponibilidade. Os servidores de aplicativos no Domínio de Disponibilidade 1 estão no estado ativo e os servidores de aplicativos no Domínio de Disponibilidade 2 estão no estado passivo. Para sincronizar servidores de aplicativos entre domínios de disponibilidade, use rsync.

A Oracle recomenda implantar a configuração de várias camadas do Oracle E-Business Suite com binários de aplicativos compartilhados. Use o Oracle Cloud Infrastructure File Storage para criar um sistema de arquivos compartilhado para compartilhar binários da aplicação Oracle E-Business Suite.
Camada de banco de dados: Configure instâncias de banco de dados altamente disponíveis em ambos os domínios de disponibilidade. O diagrama de arquitetura mostra que os servidores de banco de dados no Domínio de Disponibilidade 1 estão ativos e os servidores de banco de dados no Domínio de Disponibilidade 2 estão em stand-by. Para replicar o banco de dados entre domínios de disponibilidade, use o Oracle Active Data Guard ou o Oracle Data Guard. Você pode ativar o Oracle Data Guard para um banco de dados na console do Oracle Cloud Infrastructure ou usando APIs Oracle Cloud Infrastructure.

Arquitetura para Implantar o Oracle E-Business Suite em Várias Regiões

Você pode implantar o aplicativo Oracle E-Business Suite em várias regiões para recuperação de desastres. Essa arquitetura é semelhante à implantação do aplicativo Oracle E-Business Suite em vários domínios de disponibilidade. Nesse bastião de arquitetura, as instâncias do balanceador de carga, do aplicativo e do banco de dados são colocadas em sub-redes separadas em várias regiões.

Para garantir a disponibilidade caso a região principal não esteja disponível, instâncias redundantes são criadas na região stand-by. A região principal contém instâncias ativas em um domínio de disponibilidade. As instâncias em um domínio de disponibilidade na segunda região, chamada região de recuperação de desastres, estão em stand-by. A Oracle recomenda que você configure instâncias de aplicativo e banco de dados em topologia simétrica entre regiões para garantir que suas instâncias ativas atendam a toda a carga quando a região principal não estiver disponível. Na topologia simétrica, você implanta o mesmo número de instâncias da aplicação e do banco de dados nas regiões principal e stand-by. Nesta arquitetura, vários servidores de aplicativos são implantados em cada domínio de disponibilidade para garantir alta disponibilidade em um domínio de disponibilidade.

Como essa arquitetura é implantada em apenas um domínio de disponibilidade na região 1 e um domínio de disponibilidade na Região 2 para recuperação de desastres, ela não fornece tolerância a falhas para o domínio de disponibilidade na Região 1. Se o único domínio de disponibilidade em que o aplicativo foi implantado não estiver disponível, você precisará chamar a recuperação de desastres para fazer failover do aplicativo para a Região 2.

Se as instâncias na Região 1 não estiverem disponíveis, você deverá alternar manualmente para as instâncias na Região 2. Para obter um failover contínuo entre regiões, use nomes de host lógicos para as instâncias do banco de dados e da aplicação Oracle E-Business Suite. Use os mesmos nomes de host lógicos nos sites principal e stand-by para facilitar o failover ou o retorno sem reconfigurar instâncias.

Para replicar o banco de dados em várias regiões, use o Oracle Active Data Guard ou o Oracle Data Guard no modo assíncrono. Para sincronizar servidores de aplicativos em várias regiões, use rsync.

Veja a seguir a descrição da ilustração multiple_region_topology.png
Descrição da ilustração multiple_region_topology.png