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

Aplica-se a: ✔️ VMs do Linux

A Microsoft e a Oracle trabalharam em conjunto para habilitar os clientes a implantar aplicativos Oracle, como o Oracle E-Business Suite, o JD Edwards EnterpriseOne e o PeopleSoft, na nuvem. Com a introdução da versão prévia da interconectividade de rede privada entre o Microsoft Azure e a OCI (Oracle Cloud Infrastructure), aplicativos Oracle agora podem ser implantados no Azure com seus bancos de dados de back-end no Azure ou na 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 credenciais do Microsoft Entra.

A OCI oferece várias opções de banco de dados da Oracle para aplicativos Oracle, incluindo o DBaaS, o Exadata Cloud Service, o Oracle RAC e a IaaS (infraestrutura como serviço). Atualmente, o Autonomous Database não é um back-end compatível com aplicativos Oracle.

Há várias opções para implantar aplicativos Oracle no Azure, incluindo uma forma altamente disponível e segura. O Azure também oferece imagens de VM de banco de dados Oracle que você pode implantar caso prefira executar aplicativos Oracle totalmente no Azure.

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

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 aplicativo podem ser configuradas com pontos de extremidade públicos ou privados. A Microsoft e a Oracle recomendam configurar uma VM bastion com um endereço IP público em uma sub-rede separada para gerenciamento do aplicativo. Em seguida, atribua apenas endereços IP privados aos outros computadores, incluindo a camada de banco de dados.

Ao configurar um aplicativo em uma arquitetura entre nuvens, é necessário realizar um planejamento que garanta 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 virtual de nuvem da OCI.

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

Para alta disponibilidade, você pode configurar instâncias redundantes dos diferentes servidores no mesmo conjunto de disponibilidade ou em zonas de disponibilidade diferentes. As zonas de disponibilidade permitem que você atinja um SLA de tempo de atividade de 99,99%, enquanto os conjuntos de disponibilidade permitem atingir um SLA de tempo de atividade de 99,95% dentro da 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 usando um circuito do ExpressRoute existente para conectar o ambiente do Azure à rede local. No entanto, para interconexão da OCI, você precisa de um circuito do ExpressRoute separado daquele que se conecta à rede local.

E-Business Suite

O EBS (Oracle E-Business Suite) é um conjunto de aplicativos que inclui SCM (gerenciamento da cadeia de fornecedores) e CRM (gerenciamento de relacionamento com o cliente). Para tirar proveito do 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 de 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 está conectada a uma rede de nuvem virtual na OCI usando a interconexão entre nuvens. A camada de aplicativo está configurada no Azure, enquanto o banco de dados está configurado na OCI. Recomenda-se implantar cada componente na própria sub-rede com grupos de segurança de rede, a fim de permitir o tráfego apenas de sub-redes específicas em determinadas portas.

A arquitetura também 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 seguinte diagrama (Figura 2) é um exemplo desse padrão de arquitetura:

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

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

Camada Bastion

O Bastion Host é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias de aplicativo e banco de dados. A VM do Bastion Host 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 o tráfego de entrada. Para alta disponibilidade, implante um Bastion Host em duas zonas de disponibilidade ou em um único conjunto de disponibilidade.

Você também pode habilitar o encaminhamento de agente SSH em suas VMs, o que permite acessar outras VMs na rede virtual, encaminhando as credenciais de seu Bastion Host. 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`

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

Camada de aplicativo (intermediária)

A camada de aplicativo fica isolada na própria sub-rede. Várias máquinas virtuais são configuradas para fins de tolerância a falhas e gerenciamento fácil de patches. Essas VMs podem ter suporte do armazenamento compartilhado, que é oferecido pelo Azure NetApp Files e pelos SSDs Ultra. Essa configuração facilita a implantação de patches sem tempo de inatividade. Os computadores na camada de aplicativo devem contar com um balanceador de carga público para que as solicitações para a camada de aplicativo do EBS sejam processadas mesmo que um computador 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 da carga de trabalho para garantir a alta disponibilidade. Nesse caso, um balanceador de carga público está configurado pois os usuários têm permissão para acessar o aplicativo EBS pela Web. O balanceador de carga distribui a carga para os dois computadores na camada intermediária. Para maior segurança, permita o tráfego somente de usuários que acessam o sistema na rede corporativa usando uma VPN site a site ou o ExpressRoute com grupos de segurança de rede.

Camada de banco de dados

Essa camada hospeda o banco de dados Oracle e é separada na própria sub-rede. É recomendável adicionar grupos de segurança de rede que permitam apenas o tráfego da camada de aplicativo para a camada de banco de dados na porta 1521 do banco de dados específica do Oracle.

A Microsoft e a Oracle recomendam uma configuração de alta disponibilidade. A alta disponibilidade no Azure pode ser obtida 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. Ao usar o Oracle Database Exadata Cloud Service, seu banco de dados é implantado em duas sub-redes. Com o Oracle Data Guard, também é possível configurar o Oracle Database em VMs na OCI em dois domínios de disponibilidade.

Camada de identidade

A camada de identidade contém a VM do EBS Asserter. O EBS Asserter permite que você sincronize identidades do IDCS (serviço de nuvem de identidade) da Oracle e do Microsoft Entra ID. O EBS Asserter é necessário porque o EBS não dá suporte a protocolos de logon único, como o SAML 2.0 ou o OpenID Connect. O EBS Asserter consome o token do OpenID Connect (gerado pelo IDCS), valida-o e 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 por meio do Oracle Access Manager com o Oracle Internet Directory ou o Oracle Unified Directory. Para obter mais informações, confira os white papers sobre Como implantar o Oracle EBS com a integração do IDCS ou Como implantar o Oracle EBS com integração do OAM.

Para alta disponibilidade, é recomendável implantar servidores redundantes do EBS Asserter em diversas zonas de disponibilidade com um balanceador de carga que fornece a proteção.

Depois que a infraestrutura estiver configurada, o E-Business Suite poderá ser instalado por meio das etapas do guia de instalação fornecido pela Oracle.

JD Edwards EnterpriseOne

O JD Edwards EnterpriseOne da Oracle é um conjunto de aplicativos integrados composto por uma ampla gama de programas de software de planejamento de recursos empresariais. Ele consiste em um aplicativo de várias camadas que pode ser configurado com um back-end de banco de dados do Oracle ou do SQL Server. Esta seção aborda detalhes de como implantar o JD Edwards EnterpriseOne com um back-end de banco de dados Oracle na OCI ou no Azure.

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

Assim como acontece com o E-Business Suite, você pode configurar uma camada bastion opcional para fins de administração segura. Use o host da VM bastion como um servidor de salto para acessar as instâncias de aplicativo e de banco de dados.

Figura 3: Arquitetura entre nuvens do JD Edwards EnterpriseOne

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

A arquitetura também 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 seguinte diagrama (Figura 4) é um exemplo desse padrão de arquitetura:

Figura 4: Arquitetura do JD Edwards EnterpriseOne somente no Azure

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

Camada Bastion

O Bastion Host é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias de aplicativo e banco de dados. A VM do Bastion Host 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 o tráfego de entrada. Para alta disponibilidade, implante um Bastion Host em duas zonas de disponibilidade ou em um único conjunto de disponibilidade.

Você também pode habilitar o encaminhamento de agente SSH em suas VMs, o que permite acessar outras VMs na rede virtual, encaminhando as credenciais de seu Bastion Host. 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`

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

Camada administrativa

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

Os componentes da camada são os seguintes:

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

Camada de apresentação

Essa camada contém vários componentes, como o AIS (Application Interface Services), a ADF (Application Development Framework) e os JAS (Java Application Servers). Os servidores nessa camada se comunicam com os servidores na camada intermediária. Ele é protegido 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 diversas instâncias de cada tipo de servidor para obter alta disponibilidade.

Estes são os componentes desta camada:

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

Camada intermediária

A camada intermediária contém o servidor lógico e o servidor de lote. Neste caso, os dois servidores estão instalados na mesma máquina virtual. No entanto, em cenários de produção, recomenda-se implantar o servidor lógico e o servidor de 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 apenas dos servidores na camada de apresentação e do balanceador de carga público. Regras de 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 de NSG também pode ser configurada para permitir o tráfego na porta 22 do bastion host para fins de gerenciamento. Talvez você possa usar o balanceador de carga público para balancear a carga das solicitações entre as VMs na camada intermediária.

Estes dois componentes 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 de lote – usado para processamento em lotes

Camada de banco de dados

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

Se a opção for usar o Oracle DB, a instância do banco de dados pode ser implantada no Azure por meio das imagens do Oracle DB disponíveis no Azure Marketplace. Como alternativa, você pode usar a interconexão entre o Azure e o OCI para implantar o Oracle DB em um modelo PaaS no 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, não é uma configuração com suporte da Oracle. Consulte os programas Oracle qualificados para ambientes de nuvem autorizados.

Por fim, para sistemas Exadata, use a interconexão OCI e implante o sistema Exadata em OCI. O diagrama de arquitetura anterior acima mostra um sistema Exadata implantado em 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 estiver implantando no Azure) ou em dois domínios de disponibilidade (em OCI). Use o Oracle Active Data Guard para sincronizar os bancos de dados principal e de reserva.

A camada do 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 em OCI) para permitir apenas 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 entre Microsoft e Oracle permite que você configure uma identidade unificada entre o Azure, o OCI e seu aplicativo Oracle. No JD Edwards EnterpriseOne ou no PeopleSoft Application Suite, uma instância do Oracle HTTP Server (OHS) é necessária para configurar o logon único entre o Microsoft Entra ID e o Oracle IDCS.

O 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 ele. O WebGate do Oracle Access Manager é um plug-in do servidor Web OHS que intercepta todas as solicitações que vão para o aplicativo final. Se um recurso que está sendo acessado estiver protegido (precisar de uma sessão autenticada), o WebGate iniciará o fluxo de autenticação OIDC com o serviço de nuvem de identidade por meio do navegador do usuário. Para obter mais informações sobre os fluxos compatíveis com o WebGate do OpenID Connect, veja a documentação do Oracle Access Manager.

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

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

PeopleSoft

O conjunto de aplicativos PeopleSoft da Oracle contém programas de software de gerenciamento de recursos humanos e finanças. O conjunto de aplicativos tem várias camadas e os aplicativos incluem HRMS (sistemas de gerenciamento de recursos humanos), CRM (gerenciamento de relacionamento com o cliente), FSCM (gerenciamento da cadeia de fornecedores e finanças) e EPM (gerenciamento de desempenho empresarial).

Recomenda-se implantar cada camada do conjunto de software na própria sub-rede. Um banco de dados Oracle ou Microsoft SQL Server é necessário como banco de dados de back-end do aplicativo. Esta seção aborda detalhes sobre como implantar o PeopleSoft com um back-end de banco de dados Oracle.

Veja a seguir uma arquitetura canônica para implantar o conjunto de aplicativos PeopleSoft em uma arquitetura entre nuvens (Figura 5).

Figura 5: Arquitetura entre nuvens do PeopleSoft

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

A arquitetura também 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 seguinte diagrama (Figura 6) é um exemplo desse padrão de arquitetura:

Figura 6: Arquitetura do PeopleSoft somente no Azure

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

Camada Bastion

O Bastion Host é um componente opcional que você pode usar como um servidor de salto para acessar as instâncias de aplicativo e banco de dados. A VM do Bastion Host 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 o tráfego de entrada. Para alta disponibilidade, implante um Bastion Host em duas zonas de disponibilidade ou em um único conjunto de disponibilidade.

Você também pode habilitar o encaminhamento de agente SSH em suas VMs, o que permite acessar outras VMs na rede virtual, encaminhando as credenciais de seu Bastion Host. 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`

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

Camada de aplicativo

A camada de aplicativo contém instâncias dos servidores de aplicativos do PeopleSoft, dos servidores Web do PeopleSoft, da pesquisa elástica e do 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 ao servidor certo.

PeopleTools Client

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 no aplicativo, não são necessários servidores redundantes do PeopleTools Client.

Camada de banco de dados

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

Se a opção for usar o Oracle DB, a instância do banco de dados pode ser implantada no Azure por meio das imagens do Oracle DB disponíveis no Azure Marketplace. Como alternativa, você pode usar a interconexão entre o Azure e o OCI para implantar o Oracle DB em um modelo PaaS no 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, não é uma configuração com suporte da Oracle. Consulte os programas Oracle qualificados para ambientes de nuvem autorizados.

Por fim, para sistemas Exadata, use a interconexão OCI e implante o sistema Exadata em OCI. O diagrama de arquitetura anterior acima mostra um sistema Exadata implantado em 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 estiver implantando no Azure) ou em dois domínios de disponibilidade (em OCI). Use o Oracle Active Data Guard para sincronizar os bancos de dados principal e de reserva.

A camada do 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 em OCI) para permitir apenas 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 entre Microsoft e Oracle permite que você configure uma identidade unificada entre o Azure, o OCI e seu aplicativo Oracle. No JD Edwards EnterpriseOne ou no PeopleSoft Application Suite, uma instância do Oracle HTTP Server (OHS) é necessária para configurar o logon único entre o Microsoft Entra ID e o Oracle IDCS.

O 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 ele. O WebGate do Oracle Access Manager é um plug-in do servidor Web OHS que intercepta todas as solicitações que vão para o aplicativo final. Se um recurso que está sendo acessado estiver protegido (precisar de uma sessão autenticada), o WebGate iniciará o fluxo de autenticação OIDC com o serviço de nuvem de identidade por meio do navegador do usuário. Para obter mais informações sobre os fluxos compatíveis com o WebGate do OpenID Connect, veja a documentação do Oracle Access Manager.

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

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

Próximas etapas

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

Para saber mais e obter white papers sobre o OCI, confira a documentação do Oracle Cloud.