Arquiteturas para aplicativos Oracle com Máquinas Virtuais do Azure com banco de dados em OCI

Aplica-se a: ✔️ Linux VMs

A Microsoft e a Oracle trabalham juntas para permitir que os clientes implantem aplicativos Oracle como Oracle E-Business Suite, JD Edwards EnterpriseOne e PeopleSoft na nuvem. Com a introdução da interconectividade de rede privada entre o Microsoft Azure e o Oracle Cloud Infrastructure (OCI), os aplicativos Oracle podem ser implantados no Azure com seus bancos de dados back-end no Azure ou OCI. Os aplicativos Oracle também podem ser integrados ao Microsoft Entra ID, permitindo que você configure o logon único para que os usuários possam entrar no aplicativo Oracle usando suas credenciais do Microsoft Entra.

A OCI oferece várias opções de banco de dados Oracle para aplicativos Oracle, incluindo DBaaS, Exadata Cloud Service, Oracle RAC e Infrastructure-as-a-Service (IaaS). Atualmente, o Banco de Dados Autônomo não é um back-end suportado para aplicativos Oracle.

Há várias opções para implantar aplicativos Oracle no Azure, inclusive de forma altamente disponível e segura. O Azure também oferece imagens de VM de banco de dados Oracle que você pode implantar se optar por executar seus aplicativos Oracle inteiramente no Azure.

As seções a seguir descrevem as recomendações de arquitetura da Microsoft e da Oracle para implantar o Oracle E-Business Suite, o JD Edwards EnterpriseOne e o PeopleSoft em uma configuração entre nuvens ou totalmente no Azure. A Microsoft e a Oracle testaram esses aplicativos e confirmaram que o desempenho atende aos padrões estabelecidos pela Oracle para esses aplicativos.

Considerações sobre arquitetura

Os aplicativos Oracle são compostos por vários serviços, que podem ser hospedados na mesma ou em várias máquinas virtuais no Azure e, opcionalmente, na OCI.

As instâncias de aplicativos podem ser configuradas com pontos de extremidade privados ou públicos. A Microsoft e a Oracle recomendam a configuração de uma VM de host bastion com um endereço IP público em uma sub-rede separada para o gerenciamento do aplicativo. Em seguida, atribua apenas endereços IP privados às outras máquinas, incluindo a camada de banco de dados.

Ao configurar um aplicativo em uma arquitetura entre nuvens, o planejamento é necessário para garantir que o espaço de endereço IP na rede virtual do Azure não se sobreponha ao espaço de endereço IP privado na rede de nuvem virtual OCI.

Para maior segurança, configure grupos de segurança de rede em um nível de sub-rede para garantir que apenas o tráfego em portas e endereços IP específicos seja permitido. Por exemplo, as máquinas na camada intermediária só devem receber tráfego de dentro da rede virtual. Nenhum tráfego externo deve chegar diretamente às máquinas de camada intermediária.

Para alta disponibilidade, você pode configurar instâncias redundantes dos diferentes servidores no mesmo conjunto de disponibilidade ou zonas de disponibilidade diferentes. As zonas de disponibilidade permitem que você atinja um SLA de 99,99% de tempo de atividade, enquanto os conjuntos de disponibilidade permitem que você atinja um SLA de 99,95% de tempo de atividade na região. As arquiteturas de exemplo mostradas neste artigo são implantadas em duas zonas de disponibilidade.

Ao implantar um aplicativo usando a interconexão entre nuvens, você pode continuar a usar um circuito de Rota Expressa existente para conectar seu ambiente do Azure à sua rede local. No entanto, você precisa de um circuito de Rota Expressa separado para a interconexão com a OCI do que aquele que se conecta à sua rede local.

E-Business Suite

O Oracle E-Business Suite (EBS) é um conjunto de aplicativos que inclui Supply Chain Management (SCM) e Customer Relationship Management (CRM). Para aproveitar o portfólio de banco de dados gerenciado da OCI, o EBS pode ser implantado usando a interconexão entre nuvens entre o Microsoft Azure e a OCI. Nessa configuração, as camadas de apresentação e aplicativo são executadas no Azure e a camada de banco de dados na OCI, conforme ilustrado no diagrama de arquitetura a seguir (Figura 1).

Figura 1: Arquitetura entre nuvens do E-Business Suite

Nessa arquitetura, a rede virtual no Azure é conectada a uma rede de nuvem virtual na OCI usando a interconexão entre nuvens. A camada de aplicativo é configurada no Azure, enquanto o banco de dados é configurado na OCI. A recomendação é implantar cada componente em sua própria sub-rede com grupos de segurança de rede para permitir o tráfego apenas de sub-redes específicas em portas específicas.

A arquitetura pode ser adaptada para implantação inteiramente no Azure com bancos de dados Oracle altamente disponíveis configurados usando o Oracle Data Guard em duas zonas de disponibilidade em uma região. O diagrama a seguir (Figura 2) é um exemplo desse padrão arquitetônico:

Figura 2: Arquitetura somente do Azure do E-Business Suite

As seções a seguir descrevem os diferentes componentes em um alto nível.

Nível de bastião

O host bastion é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias do aplicativo e do banco de dados. A VM do host bastion pode ter um endereço IP público atribuído a ela, embora a recomendação seja configurar uma conexão ExpressRoute ou VPN site a site com sua rede local para acesso seguro. Além disso, apenas SSH (porta 22, Linux) ou RDP (porta 3389, Windows Server) devem ser abertos para tráfego de entrada. Para alta disponibilidade, implante um host bastion em duas zonas de disponibilidade ou em um único conjunto de disponibilidade.

Você também pode habilitar o encaminhamento do agente SSH em suas VMs, o que permite que você acesse outras VMs na rede virtual encaminhando as credenciais do seu host bastion. Ou use o túnel SSH para acessar outras instâncias.

Aqui está um exemplo de encaminhamento de agente:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Esse comando se conecta ao bastião e, em seguida, é ssh executado imediatamente novamente, para que você obtenha um terminal na instância de destino. Talvez seja necessário especificar um usuário diferente de root na instância de destino se o cluster estiver configurado de forma diferente. O -A argumento encaminha a conexão do agente para que sua chave privada em sua máquina local seja usada automaticamente. Observe que o encaminhamento do agente é uma cadeia, portanto, o segundo ssh comando também inclui -A para que quaisquer conexões SSH subsequentes iniciadas a partir da instância de destino também usem sua chave privada local.

Camada (intermediária) do aplicativo

A camada de aplicativo é isolada em sua própria sub-rede. Há várias máquinas virtuais configuradas para tolerância a falhas e fácil gerenciamento de patches. É possível fazer backup dessas VMs com armazenamento compartilhado oferecido pelos Arquivos NetApp do Azure e SSDs Ultra. Essa configuração permite uma implantação mais fácil de patches sem tempo de inatividade. As máquinas na camada de aplicativo devem ser encabeçadas por um balanceador de carga público para que as solicitações à camada de aplicativo do EBS sejam processadas mesmo que uma máquina na camada esteja offline devido a uma falha.

Balanceador de carga

Um balanceador de carga do Azure permite distribuir o tráfego entre várias instâncias de sua carga de trabalho para garantir alta disponibilidade. Nesse caso, um balanceador de carga público é configurado, porque os usuários têm permissão para acessar o aplicativo EBS pela Web. O balanceador de carga distribui a carga para ambas as máquinas na camada intermediária. Para maior segurança, permita o tráfego apenas de usuários que acessam o sistema a partir de sua rede corporativa usando uma VPN site a site ou ExpressRoute e grupos de segurança de rede.

Camada de base de dados

Essa camada hospeda o banco de dados Oracle e é separada em sua própria sub-rede. A recomendação é adicionar grupos de segurança de rede que só permitam o tráfego da camada de aplicativo para a camada de banco de dados na porta de banco de dados específica do Oracle 1521.

A Microsoft e a Oracle recomendam uma configuração de alta disponibilidade. A alta disponibilidade no Azure pode ser alcançada configurando dois bancos de dados Oracle em duas zonas de disponibilidade com o Oracle Data Guard ou usando o Oracle Database Exadata Cloud Service na OCI. Quando você usa o Oracle Database Exadata Cloud Service, seu banco de dados é implantado em duas sub-redes. Você também pode configurar o Oracle Database em VMs no OCI em dois domínios de disponibilidade com o Oracle Data Guard.

Camada de identidade

A camada de identidade contém a VM do EBS Asserter. O EBS Asserter permite sincronizar identidades do Oracle Identity Cloud Service (IDCS) e do Microsoft Entra ID. O EBS Asserter é necessário porque o EBS não suporta protocolos de logon único como SAML 2.0 ou OpenID Connect. O EBS Asserter consome o token de conexão OpenID (gerado pelo IDCS), valida-o e, em seguida, cria uma sessão para o usuário no EBS.

Embora essa arquitetura mostre a integração do IDCS, o acesso unificado e o logon único do Microsoft Entra ID também podem ser habilitados com o Oracle Access Manager com Oracle Internet Directory ou Oracle Unified Directory. Para obter mais informações, consulte os whitepapers sobre Implantando o Oracle EBS com integração IDCS ou Implantando o Oracle EBS com integração OAM.

Para alta disponibilidade, a recomendação é implantar servidores redundantes do EBS Asserter em várias zonas de disponibilidade com um balanceador de carga à sua frente.

Uma vez configurada a infraestrutura, o E-Business Suite pode ser instalado seguindo o guia de instalação fornecido pela Oracle.

JD Edwards EnterpriseOne

O JD Edwards EnterpriseOne da Oracle é um pacote de aplicativos integrado de software abrangente de planejamento de recursos corporativos. É um aplicativo de várias camadas que pode ser configurado com um back-end de banco de dados Oracle ou SQL Server. Esta seção discute detalhes sobre a implantação do JD Edwards EnterpriseOne com um back-end de banco de dados Oracle na OCI ou no Azure.

Na arquitetura recomendada a seguir (Figura 3), a administração, a apresentação e as camadas intermediárias são implantadas na rede virtual no Azure. O banco de dados é implantado em uma rede de nuvem virtual na OCI.

Assim como no E-Business Suite, você pode configurar uma camada bastion opcional para fins administrativos seguros. Use o host bastion VM como um servidor de salto para acessar as instâncias de aplicativo e banco de dados.

Figura 3: Arquitetura entre nuvens do JD Edwards EnterpriseOne

Nessa arquitetura, a rede virtual no Azure é conectada à rede de nuvem virtual na OCI usando a interconexão entre nuvens. A camada de aplicativo é configurada no Azure, enquanto o banco de dados é configurado na OCI. A recomendação é implantar cada componente em sua própria sub-rede com grupos de segurança de rede para permitir o tráfego apenas de sub-redes específicas em portas específicas.

A arquitetura pode ser adaptada para implantação inteiramente no Azure com bancos de dados Oracle altamente disponíveis configurados usando o Oracle Data Guard em duas zonas de disponibilidade em uma região. O diagrama a seguir (Figura 4) é um exemplo desse padrão arquitetônico:

Figura 4: Arquitetura somente do JD Edwards EnterpriseOne Azure

As seções a seguir descrevem os diferentes componentes em um alto nível.

Nível de bastião

O host bastion é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias do aplicativo e do banco de dados. A VM do host bastion pode ter um endereço IP público atribuído a ela, embora a recomendação seja configurar uma conexão ExpressRoute ou VPN site a site com sua rede local para acesso seguro. Além disso, apenas SSH (porta 22, Linux) ou RDP (porta 3389, Windows Server) devem ser abertos para tráfego de entrada. Para alta disponibilidade, implante um host bastion em duas zonas de disponibilidade ou em um único conjunto de disponibilidade.

Você também pode habilitar o encaminhamento do agente SSH em suas VMs, o que permite que você acesse outras VMs na rede virtual encaminhando as credenciais do seu host bastion. Ou use o túnel SSH para acessar outras instâncias.

Aqui está um exemplo de encaminhamento de agente:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Esse comando se conecta ao bastião e, em seguida, é ssh executado imediatamente novamente, para que você obtenha um terminal na instância de destino. Talvez seja necessário especificar um usuário diferente de root na instância de destino se o cluster estiver configurado de forma diferente. O -A argumento encaminha a conexão do agente para que sua chave privada em sua máquina local seja usada automaticamente. Observe que o encaminhamento do agente é uma cadeia, portanto, o segundo ssh comando também inclui -A para que quaisquer conexões SSH subsequentes iniciadas a partir da instância de destino também usem sua chave privada local.

Nível administrativo

Como o nome sugere, essa camada é usada para tarefas administrativas. Você pode criar uma sub-rede separada para a camada administrativa. Os serviços e servidores nessa camada são usados principalmente para instalação e administração do aplicativo. Assim, instâncias únicas desses servidores são suficientes. Instâncias redundantes não são necessárias para a alta disponibilidade do seu aplicativo.

Os componentes desta camada são os seguintes:

• Servidor de provisionamento - Este servidor é usado para implantação de ponta a ponta dos diferentes componentes do aplicativo. Ele se comunica com as instâncias nas outras camadas, incluindo as instâncias na camada de banco de dados, pela porta 22. Ele hospeda o Console do Gerenciador do Servidor para JD Edwards EnterpriseOne.
• Servidor de implementação - Este servidor é necessário principalmente para a instalação do JD Edwards EnterpriseOne. Durante o processo de instalação, esse servidor atua como o repositório central para os arquivos e pacotes de instalação necessários. O software é distribuído ou implantado em outros servidores e clientes a partir deste servidor.
• Cliente de desenvolvimento - Este servidor contém componentes que são executados em um navegador da Web e aplicativos nativos.

Camada física de apresentação

Esta camada contém vários componentes, como Application Interface Services (AIS), Application Development Framework (ADF) e Java Application Servers (JAS). Os servidores nessa camada se comunicam com os servidores na camada intermediária que são encabeçados por um balanceador de carga que roteia o tráfego para o servidor necessário com base no número da porta e na URL em que o tráfego é recebido. É recomendável implantar várias instâncias de cada tipo de servidor para alta disponibilidade.

A seguir estão os componentes nesta camada:

• Application Interface Services (AIS) - O servidor AIS fornece a interface de comunicação entre os aplicativos empresariais móveis JD Edwards EnterpriseOne e o JD Edwards EnterpriseOne.
• Java Application Server (JAS) - O JAS recebe solicitações do balanceador de carga e as passa para a camada intermediária para executar tarefas complicadas. O JAS tem a capacidade de executar uma lógica de negócios simples.
• BI Publisher Server (BIP) - Este servidor apresenta relatórios baseados nos dados recolhidos pela aplicação JD Edwards EnterpriseOne. Você pode projetar e controlar como o relatório apresenta os dados com base em diferentes modelos.
• Business Services Server (BSS) - O BSS permite a troca de informações e a interoperabilidade com outros aplicativos Oracle.
• Real-Time Events Server (RTE) - O Servidor RTE permite configurar notificações para sistemas externos sobre transações que ocorrem no sistema JDE EnterpriseOne. Utiliza um modelo de subscritor e permite que sistemas de terceiros subscrevam eventos. Para balancear a carga de solicitações para ambos os servidores RTE, verifique se os servidores estão em um cluster.
• Servidor do Application Development Framework (ADF) - O servidor ADF é usado para executar aplicativos JD Edwards EnterpriseOne desenvolvidos com o Oracle ADF. Este servidor é implantado em um servidor Oracle WebLogic com tempo de execução ADF.

Camada média

A camada intermediária contém o servidor lógico e o servidor em lotes. Nesse caso, ambos os servidores são instalados na mesma máquina virtual. Para cenários de produção, a recomendação é implantar o servidor lógico e o servidor em lote em servidores separados. Vários servidores são implantados na camada intermediária em duas zonas de disponibilidade para maior disponibilidade. Um balanceador de carga do Azure deve ser criado e esses servidores devem ser colocados em seu pool de back-end para garantir que ambos os servidores estejam ativos e processando solicitações.

Os servidores na camada intermediária recebem solicitações dos servidores na camada de apresentação e somente do balanceador de carga público. As regras do grupo de segurança de rede devem ser configuradas para negar o tráfego de qualquer endereço diferente da sub-rede da camada de apresentação e do balanceador de carga. Uma regra NSG também pode ser configurada para permitir o tráfego na porta 22 do host bastion para fins de gerenciamento. Talvez você possa usar o balanceador de carga público para balancear a carga de solicitações entre as VMs na camada intermediária.

Os dois componentes a seguir estão na camada intermediária:

• Servidor lógico - Contém a lógica de negócios ou as funções de negócios.
• Servidor em lote - Usado para processamento em lote

Camada de base de dados

A camada Database contém as instâncias de banco de dados para o aplicativo. O banco de dados pode ser um sistema Oracle DB, Oracle RAC ou Oracle Exadata Database.

Se a opção for usar o banco de dados Oracle, a instância de banco de dados poderá ser implantada no Azure por meio das imagens de banco de dados Oracle disponíveis no Azure Marketplace. Como alternativa, você pode usar a interconexão entre o Azure e a OCI para implantar o banco de dados Oracle em um modelo PaaS na OCI.

Para Oracle RAC, você pode usar OCI no modelo PaaS. É recomendável usar um sistema RAC de dois nós. Embora seja possível implantar o Oracle RAC no Azure CloudSimple no modelo IaaS, ele não é uma configuração suportada pela Oracle. Consulte os programas Oracle qualificados para ambientes de nuvem autorizados.

Finalmente, para sistemas Exadata, use a interconexão OCI e implante o sistema Exadata na OCI. O diagrama de arquitetura anterior acima mostra um sistema Exadata implantado no OCI em duas sub-redes.

Para cenários de produção, implante várias instâncias do banco de dados em duas zonas de disponibilidade (se implantadas no Azure) ou em dois domínios de disponibilidade (em OCI). Use o Oracle Ative Data Guard para sincronizar os bancos de dados primários e em espera.

A camada de banco de dados só recebe solicitações da camada intermediária. É recomendável que você configure um grupo de segurança de rede (lista de segurança se estiver implantando o banco de dados na OCI) para permitir somente solicitações na porta 1521 da camada intermediária e na porta 22 do servidor bastion por motivos administrativos.

Para bancos de dados implantados em OCI, uma rede de nuvem virtual separada deve ser configurada com um gateway de roteamento dinâmico (DRG) conectado ao seu circuito FastConnect.

Camada de identidade

A parceria Microsoft-Oracle permite que você configure uma identidade unificada no Azure, OCI e seu aplicativo Oracle. Para o pacote de aplicativos JD Edwards EnterpriseOne ou PeopleSoft, uma instância do Oracle HTTP Server (OHS) é necessária para configurar o logon único entre o Microsoft Entra ID e o Oracle IDCS.

A OHS atua como um proxy reverso para a camada de aplicativo, o que significa que todas as solicitações para os aplicativos finais passam por ela. O Oracle Access Manager WebGate é um plug-in de servidor Web OHS que interceta todas as solicitações que vão para o aplicativo final. Se um recurso que está sendo acessado estiver protegido (requer uma sessão autenticada), o WebGate iniciará o fluxo de autenticação OIDC com o Identity Cloud Service através do navegador do usuário. Para obter mais informações sobre os fluxos suportados pelo OpenID Connect WebGate, consulte a documentação do Oracle Access Manager.

Com essa configuração, um usuário já conectado ao Microsoft Entra ID pode navegar até o aplicativo JD Edwards EnterpriseOne ou PeopleSoft sem fazer login novamente, por meio do Oracle Identity Cloud Service. Os clientes que implantam essa solução obtêm os benefícios do logon único, incluindo um único conjunto de credenciais, uma experiência de logon aprimorada, segurança aprimorada e custo reduzido de help-desk.

Para saber mais sobre como configurar o logon único para JD Edwards EnterpriseOne ou PeopleSoft com ID do Microsoft Entra, consulte o whitepaper Oracle associado.

PessoasSoft

O pacote de aplicativos PeopleSoft da Oracle contém software para recursos humanos e gestão financeira. O pacote de aplicativos é multicamadas e os aplicativos incluem sistemas de gerenciamento de recursos humanos (HRMS), gerenciamento de relacionamento com o cliente (CRM), finanças e gerenciamento da cadeia de suprimentos (FSCM) e gerenciamento de desempenho empresarial (EPM).

A recomendação é que cada camada do pacote de software seja implantada em sua própria sub-rede. Um banco de dados Oracle ou Microsoft SQL Server é necessário como o banco de dados back-end para o aplicativo. Esta seção discute detalhes sobre a implantação do PeopleSoft com um back-end de banco de dados Oracle.

O diagrama a seguir mostra uma arquitetura canônica para implantar o pacote de aplicativos PeopleSoft em uma arquitetura entre nuvens (Figura 5).

Figura 5: Arquitetura entre nuvens PeopleSoft

Nesta arquitetura de exemplo, a rede virtual no Azure é conectada à rede de nuvem virtual na OCI usando a interconexão entre nuvens. A camada de aplicativo é configurada no Azure, enquanto o banco de dados é configurado na OCI. A recomendação é implantar cada componente em sua própria sub-rede com grupos de segurança de rede para permitir o tráfego apenas de sub-redes específicas em portas específicas.

A arquitetura também pode ser adaptada para implantação totalmente no Azure com bancos de dados Oracle altamente disponíveis configurados usando o Oracle Data Guard em duas zonas de disponibilidade em uma região. O diagrama a seguir (Figura 6) é um exemplo desse padrão arquitetônico:

Figura 6: Arquitetura somente do PeopleSoft Azure

As seções a seguir descrevem os diferentes componentes em um alto nível.

Nível de bastião

O host bastion é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias do aplicativo e do banco de dados. A VM do host bastion pode ter um endereço IP público atribuído a ela, embora a recomendação seja configurar uma conexão ExpressRoute ou VPN site a site com sua rede local para acesso seguro. Além disso, apenas SSH (porta 22, Linux) ou RDP (porta 3389, Windows Server) devem ser abertos para tráfego de entrada. Para alta disponibilidade, implante um host bastion em duas zonas de disponibilidade ou em um único conjunto de disponibilidade.

Você também pode habilitar o encaminhamento do agente SSH em suas VMs, o que permite que você acesse outras VMs na rede virtual encaminhando as credenciais do seu host bastion. Ou use o túnel SSH para acessar outras instâncias.

Aqui está um exemplo de encaminhamento de agente:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Esse comando se conecta ao bastião e, em seguida, é ssh executado imediatamente novamente, para que você obtenha um terminal na instância de destino. Talvez seja necessário especificar um usuário diferente de root na instância de destino se o cluster estiver configurado de forma diferente. O -A argumento encaminha a conexão do agente para que sua chave privada em sua máquina local seja usada automaticamente. Observe que o encaminhamento do agente é uma cadeia, portanto, o segundo ssh comando também inclui -A para que quaisquer conexões SSH subsequentes iniciadas a partir da instância de destino também usem sua chave privada local.

Camada física da aplicação

A camada de aplicativo contém instâncias dos servidores de aplicativos PeopleSoft, servidores Web PeopleSoft, pesquisa elástica e PeopleSoft Process Scheduler. Um balanceador de carga do Azure é configurado para aceitar solicitações de usuários, que são roteadas para o servidor apropriado na camada de aplicativo.

Para alta disponibilidade, considere configurar instâncias redundantes de cada servidor na camada de aplicativo em diferentes zonas de disponibilidade. O balanceador de carga do Azure pode ser configurado com vários pools de back-end para direcionar cada solicitação para o servidor certo.

Cliente PeopleTools

O PeopleTools Client é usado para executar atividades de administração, como desenvolvimento, migração e atualização. Como o PeopleTools Client não é necessário para obter alta disponibilidade do seu aplicativo, servidores redundantes do PeopleTools Client não são necessários.

Camada de base de dados

A camada Database contém as instâncias de banco de dados para o aplicativo. O banco de dados pode ser um sistema Oracle DB, Oracle RAC ou Oracle Exadata Database.

Se a opção for usar o banco de dados Oracle, a instância de banco de dados poderá ser implantada no Azure por meio das imagens de banco de dados Oracle disponíveis no Azure Marketplace. Como alternativa, você pode usar a interconexão entre o Azure e a OCI para implantar o banco de dados Oracle em um modelo PaaS na OCI.

Para Oracle RAC, você pode usar OCI no modelo PaaS. É recomendável usar um sistema RAC de dois nós. Embora seja possível implantar o Oracle RAC no Azure CloudSimple no modelo IaaS, ele não é uma configuração suportada pela Oracle. Consulte os programas Oracle qualificados para ambientes de nuvem autorizados.

Finalmente, para sistemas Exadata, use a interconexão OCI e implante o sistema Exadata na OCI. O diagrama de arquitetura anterior acima mostra um sistema Exadata implantado no OCI em duas sub-redes.

Para cenários de produção, implante várias instâncias do banco de dados em duas zonas de disponibilidade (se implantadas no Azure) ou em dois domínios de disponibilidade (em OCI). Use o Oracle Ative Data Guard para sincronizar os bancos de dados primários e em espera.

A camada de banco de dados só recebe solicitações da camada intermediária. É recomendável que você configure um grupo de segurança de rede (lista de segurança se estiver implantando o banco de dados na OCI) para permitir somente solicitações na porta 1521 da camada intermediária e na porta 22 do servidor bastion por motivos administrativos.

Para bancos de dados implantados em OCI, uma rede de nuvem virtual separada deve ser configurada com um gateway de roteamento dinâmico (DRG) conectado ao seu circuito FastConnect.

Camada de identidade

A parceria Microsoft-Oracle permite que você configure uma identidade unificada no Azure, OCI e seu aplicativo Oracle. Para o pacote de aplicativos JD Edwards EnterpriseOne ou PeopleSoft, uma instância do Oracle HTTP Server (OHS) é necessária para configurar o logon único entre o Microsoft Entra ID e o Oracle IDCS.

A OHS atua como um proxy reverso para a camada de aplicativo, o que significa que todas as solicitações para os aplicativos finais passam por ela. O Oracle Access Manager WebGate é um plug-in de servidor Web OHS que interceta todas as solicitações que vão para o aplicativo final. Se um recurso que está sendo acessado estiver protegido (requer uma sessão autenticada), o WebGate iniciará o fluxo de autenticação OIDC com o Identity Cloud Service através do navegador do usuário. Para obter mais informações sobre os fluxos suportados pelo OpenID Connect WebGate, consulte a documentação do Oracle Access Manager.

Com essa configuração, um usuário já conectado ao Microsoft Entra ID pode navegar até o aplicativo JD Edwards EnterpriseOne ou PeopleSoft sem fazer login novamente, por meio do Oracle Identity Cloud Service. Os clientes que implantam essa solução obtêm os benefícios do logon único, incluindo um único conjunto de credenciais, uma experiência de logon aprimorada, segurança aprimorada e custo reduzido de help-desk.

Para saber mais sobre como configurar o logon único para JD Edwards EnterpriseOne ou PeopleSoft com ID do Microsoft Entra, consulte o whitepaper Oracle associado.

Próximos passos

Use scripts Terraform para configurar aplicativos Oracle no Azure e estabelecer conectividade entre nuvens com OCI.

Para obter mais informações e whitepapers sobre OCI, consulte a documentação do Oracle Cloud .