Architectures for Oracle applications with Azure Virtual Machines with database on OCI

Applies to: ✔️ Linux VMs

Microsoft and Oracle work together to enable customers to deploy Oracle applications such as Oracle E-Business Suite, JD Edwards EnterpriseOne, and PeopleSoft in the cloud. With the introduction of the private network interconnectivity between Microsoft Azure and Oracle Cloud Infrastructure (OCI), Oracle applications can be deployed on Azure with their back-end databases in Azure or OCI. Oracle applications can also be integrated with Microsoft Entra ID, allowing you to set up single sign-on so that users can sign into the Oracle application using their Microsoft Entra credentials.

OCI offers multiple Oracle database options for Oracle applications, including DBaaS, Exadata Cloud Service, Oracle RAC, and Infrastructure-as-a-Service (IaaS). Currently, Autonomous Database isn't a supported back-end for Oracle applications.

There are multiple options for deploying Oracle applications in Azure, including in a highly available and secure manner. Azure also offers Oracle database VM images that you can deploy if you choose to run your Oracle applications entirely on Azure.

The following sections outline architecture recommendations by both Microsoft and Oracle to deploy Oracle E-Business Suite, JD Edwards EnterpriseOne, and PeopleSoft in a cross-cloud configuration or entirely in Azure. Microsoft and Oracle tested these applications and confirmed that the performance meets standards set by Oracle for these applications.

Architecture considerations

Oracle applications are made up of multiple services, which can be hosted on the same or multiple virtual machines in Azure and optionally in OCI.

Application instances can be set up with private or public endpoints. Microsoft and Oracle recommend setting up a bastion host VM with a public IP address in a separate subnet for management of the application. Then, assign only private IP addresses to the other machines, including the database tier.

When setting up an application in a cross-cloud architecture, planning is required to ensure that the IP address space in the Azure virtual network doesn't overlap the private IP address space in the OCI virtual cloud network.

For added security, set up network security groups at a subnet level to ensure only traffic on specific ports and IP addresses is permitted. For example, machines in the middle tier should only receive traffic from within the virtual network. No external traffic should reach the middle tier machines directly.

For high availability, you can set up redundant instances of the different servers in the same availability set or different availability zones. Availability zones allow you to achieve a 99.99% uptime SLA, while availability sets allow you to achieve a 99.95% uptime SLA in-region. Sample architectures shown in this article are deployed across two availability zones.

When deploying an application using the cross-cloud interconnect, you can continue to use an existing ExpressRoute circuit to connect your Azure environment to your on-premises network. However, you need a separate ExpressRoute circuit for the interconnect to OCI than the one connecting to your on-premises network.

E-Business Suite

Oracle E-Business Suite (EBS) is a suite of applications including Supply Chain Management (SCM) and Customer Relationship Management (CRM). To take advantage of OCI’s managed database portfolio, EBS can be deployed using the cross-cloud interconnect between Microsoft Azure and OCI. In this configuration, the presentation and application tiers run in Azure and the database tier in OCI, as illustrated in the following architecture diagram (Figure 1).

Figure 1: E-Business Suite cross-cloud architecture

In this architecture, the virtual network in Azure is connected to a virtual cloud network in OCI using the cross-cloud interconnect. The application tier is set up in Azure, whereas the database is set up in OCI. The recommendation is to deploy each component to its own subnet with network security groups to allow traffic only from specific subnets on specific ports.

The architecture can be adapted for deployment entirely on Azure with highly available Oracle databases configured using Oracle Data Guard in two availability zones in a region. The following diagram (Figure 2) is an example of this architectural pattern:

Figure 2: E-Business Suite Azure-only architecture

The following sections describe the different components at a high level.

Bastion tier

The bastion host is an optional component that you can use as a jump server to access the application and database instances. The bastion host VM can have a public IP address assigned to it, although the recommendation is to set up an ExpressRoute connection or site-to-site VPN with your on-premises network for secure access. Additionally, only SSH (port 22, Linux) or RDP (port 3389, Windows Server) should be opened for incoming traffic. For high availability, deploy a bastion host in two availability zones or in a single availability set.

You may also enable SSH agent forwarding on your VMs, which allows you to access other VMs in the virtual network by forwarding the credentials from your bastion host. Or, use SSH tunneling to access other instances.

Here's an example of agent forwarding:

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

This command connects to the bastion and then immediately runs ssh again, so you get a terminal on the target instance. You may need to specify a user other than root on the target instance if your cluster is configured differently. The -A argument forwards the agent connection so your private key on your local machine is used automatically. Note that agent forwarding is a chain, so the second ssh command also includes -A so that any subsequent SSH connections initiated from the target instance also use your local private key.

Application (middle) tier

The application tier is isolated in its own subnet. There are multiple virtual machines set up for fault tolerance and easy patch management. These VMs can be backed with shared storage offered by Azure NetApp Files and Ultra SSDs. This configuration allows for easier deployment of patches without downtime. The machines in the application tier should be fronted by a public load balancer so requests to the EBS application tier are processed even if one machine in the tier is offline due to a fault.

Load balancer

An Azure load balancer allows you to distribute traffic across multiple instances of your workload to ensure high availability. In this case, a public load balancer is set up, because users are allowed to access the EBS application over the web. The load balancer distributes the load to both machines in the middle tier. For added security, allow traffic only from users accessing the system from your corporate network using a site-to-site VPN or ExpressRoute and network security groups.

Database tier

This tier hosts the Oracle database and is separated into its own subnet. The recommendation is to add network security groups that only permit traffic from the application tier to the database tier on the Oracle-specific database port 1521.

Microsoft and Oracle recommend a high availability setup. High availability in Azure can be achieved by setting up two Oracle databases in two availability zones with Oracle Data Guard, or by using Oracle Database Exadata Cloud Service in OCI. When you use Oracle Database Exadata Cloud Service, your database is deployed in two subnets. You can also set up Oracle Database in VMs in OCI in two availability domains with Oracle Data Guard.

Identity tier

The identity tier contains the EBS Asserter VM. EBS Asserter allows you to synchronize identities from Oracle Identity Cloud Service (IDCS) and Microsoft Entra ID. The EBS Asserter is needed because EBS doesn't support single sign-on protocols like SAML 2.0 or OpenID Connect. The EBS Asserter consumes the OpenID connect token (generated by IDCS), validates it, and then creates a session for the user in EBS.

While this architecture shows IDCS integration, Microsoft Entra ID unified access and single sign-on also can be enabled with Oracle Access Manager with Oracle Internet Directory or Oracle Unified Directory. For more information, see the whitepapers on Deploying Oracle EBS with IDCS Integration or Deploying Oracle EBS with OAM Integration.

For high availability, the recommendation is to deploy redundant servers of the EBS Asserter across multiple availability zones with a load balancer in front of it.

Once your infrastructure is set up, E-Business Suite can be installed by following the installation guide provided by Oracle.

JD Edwards EnterpriseOne

Oracle's JD Edwards EnterpriseOne is an integrated applications suite of comprehensive enterprise resource planning software. It's a multi-tiered application that can be set up with either an Oracle or SQL Server database backend. This section discusses details on deploying JD Edwards EnterpriseOne with an Oracle database back-end either in OCI or in Azure.

In the following recommended architecture (Figure 3), the administration, presentation, and middle tiers are deployed to the virtual network in Azure. The database is deployed in a virtual cloud network in OCI.

As with E-Business Suite, you can set up an optional bastion tier for secure administrative purposes. Use the bastion VM host as a jump server to access the application and database instances.

Figure 3: JD Edwards EnterpriseOne cross-cloud architecture

In this architecture, the virtual network in Azure is connected to the virtual cloud network in OCI using the cross-cloud interconnect. The application tier is set up in Azure, whereas the database is set up in OCI. The recommendation is to deploy each component to its own subnet with network security groups to allow traffic only from specific subnets on specific ports.

The architecture can be adapted for deployment entirely on Azure with highly available Oracle databases configured using Oracle Data Guard in two availability zones in a region. The following diagram (Figure 4) is an example of this architectural pattern:

Figure 4: JD Edwards EnterpriseOne Azure-only architecture

The following sections describe the different components at a high level.

Bastion tier

The bastion host is an optional component that you can use as a jump server to access the application and database instances. The bastion host VM can have a public IP address assigned to it, although the recommendation is to set up an ExpressRoute connection or site-to-site VPN with your on-premises network for secure access. Additionally, only SSH (port 22, Linux) or RDP (port 3389, Windows Server) should be opened for incoming traffic. For high availability, deploy a bastion host in two availability zones or in a single availability set.

You may also enable SSH agent forwarding on your VMs, which allows you to access other VMs in the virtual network by forwarding the credentials from your bastion host. Or, use SSH tunneling to access other instances.

Here's an example of agent forwarding:

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

This command connects to the bastion and then immediately runs ssh again, so you get a terminal on the target instance. You may need to specify a user other than root on the target instance if your cluster is configured differently. The -A argument forwards the agent connection so your private key on your local machine is used automatically. Note that agent forwarding is a chain, so the second ssh command also includes -A so that any subsequent SSH connections initiated from the target instance also use your local private key.

Administrative tier

As the name suggests, this tier is used for administrative tasks. You can carve out a separate subnet for the administrative tier. The services and servers in this tier are primarily used for installation and administration of the application. Hence, single instances of these servers are sufficient. Redundant instances aren't required for the high availability of your application.

The components of this tier are as follows:

• Provisioning server - This server is used for end-to-end deployment of the different components of the application. It communicates with the instances in the other tiers, including the instances in the database tier, over port 22. It hosts the Server Manager Console for JD Edwards EnterpriseOne.
• Deployment server - This server is primarily required for the installation of JD Edwards EnterpriseOne. During the installation process, this server acts as the central repository for required files and installation packages. The software is distributed or deployed to other servers and clients from this server.
• Development client - This server contains components that run in a web browser and native applications.

Presentation tier

This tier contains various components such as Application Interface Services (AIS), Application Development Framework (ADF), and Java Application Servers (JAS). The servers in this tier communicate with the servers in the middle tier that are fronted by a load balancer that routes traffic to the necessary server based on the port number and URL that the traffic is received on. It's recommended that you deploy multiple instances of each server type for high availability.

The following are the components in this tier:

• Application Interface Services (AIS) - The AIS server provides the communication interface between JD Edwards EnterpriseOne mobile enterprise applications and JD Edwards EnterpriseOne.
• Java Application Server (JAS) - The JAS receives requests from the load balancer and passes it to the middle tier to execute complicated tasks. The JAS has the ability to execute simple business logic.
• BI Publisher Server (BIP) - This server presents reports based on the data collected by the JD Edwards EnterpriseOne application. You can design and control how the report presents the data based on different templates.
• Business Services Server (BSS) - The BSS enables information exchange and interoperability with other Oracle applications.
• Real-Time Events Server (RTE) - The RTE Server allows you to set up notifications to external systems about transactions occurring in the JDE EnterpriseOne system. It uses a subscriber model and allows third-party systems to subscribe to events. To load balance requests to both RTE servers, ensure that the servers are in a cluster.
• Application Development Framework (ADF) Server - The ADF server is used to run JD Edwards EnterpriseOne applications developed with Oracle ADF. This server is deployed on an Oracle WebLogic server with ADF runtime.

Middle tier

The middle tier contains the logic server and batch server. In this case, both servers are installed on the same virtual machine. For production scenarios, the recommendation is to deploy logic server and batch server on separate servers. Multiple servers are deployed in the middle tier across two availability zones for higher availability. An Azure load balancer should be created and these servers should be placed in its backend pool to ensure that both servers are active and processing requests.

The servers in the middle tier receive requests from the servers in the presentation tier and the public load balancer only. Network security group rules must be set up to deny traffic from any address other than the presentation tier subnet and the load balancer. An NSG rule can also be set up to allow traffic on port 22 from the bastion host for management purposes. You might be able to use the public load balancer to load balance requests between the VMs in the middle tier.

The following two components are in the middle tier:

• Logic server - Contain the business logic or business functions.
• Batch server - Used for batch processing

Database tier

The Database tier contains the database instances for the application. The database can be either an Oracle DB, Oracle RAC, or Oracle Exadata Database system.

If the choice is to use Oracle DB, the database instance may be deployed on Azure via the Oracle DB images available on the Azure Marketplace. Alternatively, you may use the interconnect between Azure and OCI to deploy the Oracle DB in a PaaS model on OCI.

For Oracle RAC, you can use OCI in PaaS model. It is recommended that you use a two-node RAC system. While it is possible to deploy Oracle RAC on Azure CloudSimple in IaaS model, it is not a supported configuration by Oracle. Refer to Oracle programs eligible for Authorized Cloud Environments.

Finally, for Exadata systems, use the OCI interconnect and deploy the Exadata system in OCI. The preceding architecture diagram above shows an Exadata system deployed in OCI across two subnets.

For production scenarios, deploy multiple instances of the database across two availability zones (if deploying in Azure) or two availability domains (in OCI). Use Oracle Active Data Guard to synchronize the primary and standby databases.

The database tier only receives requests from the middle tier. It is recommended that you set up a network security group (security list if deploying the database in OCI) to only allow requests on port 1521 from the middle tier and port 22 from the bastion server for administrative reasons.

For databases deployed in OCI, a separate virtual cloud network must be set up with a dynamic routing gateway (DRG) that is connected to your FastConnect circuit.

Identity tier

The Microsoft-Oracle partnership enables you to set up a unified identity across Azure, OCI, and your Oracle application. For JD Edwards EnterpriseOne or PeopleSoft application suite, an instance of the Oracle HTTP Server (OHS) is needed to set up single sign-on between Microsoft Entra ID and Oracle IDCS.

OHS acts as a reverse proxy to the application tier, which means that all the requests to the end applications go through it. Oracle Access Manager WebGate is an OHS web server plugin that intercepts every request going to the end application. If a resource being accessed is protected (requires an authenticated session), the WebGate initiates OIDC authentication flow with Identity Cloud Service through the user’s browser. For more information about the flows supported by the OpenID Connect WebGate, see the Oracle Access Manager documentation.

With this setup, a user already logged in to Microsoft Entra ID can navigate to the JD Edwards EnterpriseOne or PeopleSoft application without logging in again, through Oracle Identity Cloud Service. Customers that deploy this solution gain the benefits of single sign-on, including a single set of credentials, an improved sign-on experience, improved security, and reduced help-desk cost.

To learn more about setting up single sign-on for JD Edwards EnterpriseOne or PeopleSoft with Microsoft Entra ID, see the associated Oracle whitepaper.

PeopleSoft

Oracle's PeopleSoft application suite contains software for human resources and financial management. The application suite is multi-tiered and applications include human resource management systems (HRMS), customer relationship management (CRM), financials and supply chain management (FSCM), and enterprise performance management (EPM).

The recommendation is to have each tier of the software suite be deployed in its own subnet. An Oracle database or Microsoft SQL Server is required as the backend database for the application. This section discusses details on deploying PeopleSoft with an Oracle database backend.

The following diagram shows a canonical architecture for deploying the PeopleSoft application suite in a cross-cloud architecture (Figure 5).

Figure 5: PeopleSoft cross-cloud architecture

In this sample architecture, the virtual network in Azure is connected to the virtual cloud network in OCI using the cross-cloud interconnect. The application tier is set up in Azure, whereas the database is set up in OCI. The recommendation is to deploy each component to its own subnet with network security groups to allow traffic only from specific subnets on specific ports.

The architecture can also be adapted for deployment entirely on Azure with highly available Oracle databases configured using Oracle Data Guard in two availability zones in a region. The following diagram (Figure 6) is an example of this architectural pattern:

Figure 6: PeopleSoft Azure-only architecture

The following sections describe the different components at a high level.

Bastion tier

The bastion host is an optional component that you can use as a jump server to access the application and database instances. The bastion host VM can have a public IP address assigned to it, although the recommendation is to set up an ExpressRoute connection or site-to-site VPN with your on-premises network for secure access. Additionally, only SSH (port 22, Linux) or RDP (port 3389, Windows Server) should be opened for incoming traffic. For high availability, deploy a bastion host in two availability zones or in a single availability set.

You may also enable SSH agent forwarding on your VMs, which allows you to access other VMs in the virtual network by forwarding the credentials from your bastion host. Or, use SSH tunneling to access other instances.

Here's an example of agent forwarding:

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

This command connects to the bastion and then immediately runs ssh again, so you get a terminal on the target instance. You may need to specify a user other than root on the target instance if your cluster is configured differently. The -A argument forwards the agent connection so your private key on your local machine is used automatically. Note that agent forwarding is a chain, so the second ssh command also includes -A so that any subsequent SSH connections initiated from the target instance also use your local private key.

Application tier

The application tier contains instances of the PeopleSoft application servers, PeopleSoft web servers, elastic search, and PeopleSoft Process Scheduler. An Azure load balancer is set up to accept requests from users, which are routed to the appropriate server in the application tier.

For high availability, consider setting up redundant instances of each server in the application tier across different availability zones. The Azure load balancer can be set up with multiple back-end pools to direct each request to the right server.

PeopleTools Client

The PeopleTools Client is used to perform administration activities, such as development, migration, and upgrade. Because the PeopleTools Client isn't required for achieving high availability of your application, redundant servers of PeopleTools Client aren't needed.

Database tier

The Database tier contains the database instances for the application. The database can be either an Oracle DB, Oracle RAC, or Oracle Exadata Database system.

If the choice is to use Oracle DB, the database instance may be deployed on Azure via the Oracle DB images available on the Azure Marketplace. Alternatively, you may use the interconnect between Azure and OCI to deploy the Oracle DB in a PaaS model on OCI.

For Oracle RAC, you can use OCI in PaaS model. It is recommended that you use a two-node RAC system. While it is possible to deploy Oracle RAC on Azure CloudSimple in IaaS model, it is not a supported configuration by Oracle. Refer to Oracle programs eligible for Authorized Cloud Environments.

Finally, for Exadata systems, use the OCI interconnect and deploy the Exadata system in OCI. The preceding architecture diagram above shows an Exadata system deployed in OCI across two subnets.

For production scenarios, deploy multiple instances of the database across two availability zones (if deploying in Azure) or two availability domains (in OCI). Use Oracle Active Data Guard to synchronize the primary and standby databases.

The database tier only receives requests from the middle tier. It is recommended that you set up a network security group (security list if deploying the database in OCI) to only allow requests on port 1521 from the middle tier and port 22 from the bastion server for administrative reasons.

For databases deployed in OCI, a separate virtual cloud network must be set up with a dynamic routing gateway (DRG) that is connected to your FastConnect circuit.

Identity tier

The Microsoft-Oracle partnership enables you to set up a unified identity across Azure, OCI, and your Oracle application. For JD Edwards EnterpriseOne or PeopleSoft application suite, an instance of the Oracle HTTP Server (OHS) is needed to set up single sign-on between Microsoft Entra ID and Oracle IDCS.

OHS acts as a reverse proxy to the application tier, which means that all the requests to the end applications go through it. Oracle Access Manager WebGate is an OHS web server plugin that intercepts every request going to the end application. If a resource being accessed is protected (requires an authenticated session), the WebGate initiates OIDC authentication flow with Identity Cloud Service through the user’s browser. For more information about the flows supported by the OpenID Connect WebGate, see the Oracle Access Manager documentation.

With this setup, a user already logged in to Microsoft Entra ID can navigate to the JD Edwards EnterpriseOne or PeopleSoft application without logging in again, through Oracle Identity Cloud Service. Customers that deploy this solution gain the benefits of single sign-on, including a single set of credentials, an improved sign-on experience, improved security, and reduced help-desk cost.

To learn more about setting up single sign-on for JD Edwards EnterpriseOne or PeopleSoft with Microsoft Entra ID, see the associated Oracle whitepaper.

Next steps

Use Terraform scripts to set up Oracle apps in Azure and establish cross-cloud connectivity with OCI.

For more information and whitepapers about OCI, see the Oracle Cloud documentation.