You can create instances in a private or a public subnet based on whether you want to permit access to the instances from the internet. Instances that you create in a public subnet are assigned a public IP address and you can access these instances from the Internet. You can’t assign a public IP address to instances created in a private subnet. Therefore you can’t access these instances over the internet.

The following image shows a virtual cloud network (VCN) with public and private subnets. The VCN contains two availability domains, and each availability domain contains a public and private subnet. The web servers are placed in the public subnet in this image, so each web server instance has a public IP address attached to it. You can access these Oracle Cloud instances in the public subnet from the internet by enabling communication through the internet gateway (IGW). You’ll have to update the route table to enable traffic to and from the IGW. To permit traffic to the web servers from the internet, you must create load balancers in the public subnet. To access your instances from the internet, you also need to create a bastion host in the public subnet and access the bastion host from the IGW.

The database servers are placed in the private subnet in this image. You can access Oracle Cloud instances in the private subnet from your data centers by connecting through the dynamic routing gateway (DRG). The DRG connects your on-premise networks to your cloud network. To enable communication between the DRG and the customer on-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect. You’ll also have to update the route table to enable traffic to and from the DRG.

Description of the illustration public_private_subnets_jde.png

While creating multiple instances for high availability in an availability domain on Oracle Cloud Infrastructure, the anti-affinity for instances can be achieved by using fault domains.

A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. So, a hardware failure or Oracle Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains. By using fault domains, you can protect your instances against unexpected hardware failures and planned outages.

For high availability of databases, you can create a 2-node Virtual Machine (VM) DB system, which provides Oracle Real Applications Clusters (Oracle RAC). The two nodes of Oracle RAC are always created in separate fault domains by default. It is also possible to manually choose a fault domain for the RAC nodes during the Oracle RAC database provisioning. So, the database nodes are neither on the same physical host nor on the same physical rack. This protects the database instances against the underlying physical host and top-of-the-rack switch failures.

This architecture shows the deployment of an Oracle E-Business Suite application in a single availability domain while ensuring high availability.

The architecture consists of a virtual cloud network (VCN) with the bastion, load balancer, application, and database hosts placed in separate subnets of VCN in a single availability domain. In the following architecture diagram, the bastion host is deployed in a public subnet, and all the other instances are deployed in private subnets. You can place the different instances in public or private subnets based on your business requirements.

In this architecture, multiple application tier instances are deployed in a single availability domain, yet the individual application tier instances are placed in separate fault domains, allowing for high availability of the application tier. Fault domains enable you to distribute your instances so that they are not on the same physical hardware within a single availability domain. As a result, a hardware failure or hardware maintenance that affects one fault domain does not affect instances in other fault domains.

Instances in the private subnet require outbound connection to Oracle Services Network to apply operating system (yum) updates. For this purpose, use a service gateway in your VCN. With a service gateway, the hosts in the private subnet can access supported Oracle services (such as the yum repository) privately. Instances in the private subnet may optionally require outbound connection to the Internet to download application patches and for external integrations. For this purpose, use a Network Address Translation (NAT) gateway in your VCN. With a NAT gateway, the hosts in the private subnet can initiate connections to the Internet and receive responses, but won’t receive inbound connections initiated from the Internet.

All application instances in the availability domain are active. The load balancer instances receive requests and send it to the application servers. The application servers process these requests and forward it to the database instances. You can access the instances in private subnets over port 22 through the bastion host or the Dynamic Routing gateway (DRG) if you have set up an IPSec VPN tunnel between your data center and Oracle Cloud Infrastructure DRG.

Oracle recommends that the database and the applications deployed on Oracle Cloud Infrastructure should have a robust backup and recovery strategy. It is recommended to store backups of databases and application instances in the Oracle Cloud Infrastructure Object Storage. The databases and application tier instances in private subnets can be backed up to Oracle Cloud Infrastructure Object Storage by using a service gateway. A service gateway provides access to Oracle Cloud Infrastructure Object Storage without traversing the Internet.

The automatic and on-demand database backups to Oracle Cloud Infrastructure Object Storage can be configured using the Oracle Cloud Infrastructure console. This requires connectivity to Oracle Cloud Infrastructure Object Storage using a Swift endpoint. All database backups on Oracle Cloud Infrastructure Object Storage are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption. The automatic database backup service uses weekly incremental backup strategy to backup databases with a custom retention policy that you can customize when configuring automatic backups.

The backup of application can be configured by using the policy-based backup feature of Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes provides you with the capability to perform volume backups automatically based on a schedule and retain them based on the selected backup policy. This allows you to adhere to your data compliance and regulatory requirements. There are three predefined backup policies: Bronze, Silver, and Gold. Each backup policy has a predefined backup frequency and retention period.

Description of the illustration single_availability_domain_ha_topology.png

This architecture supports the following components:

• Bastion host: The bastion host is an optional component that can be used as a jump server to access instances in the private subnet. A bastion host is an Oracle Cloud Infrastructure Compute instance that uses Linux as its operating system. Place the bastion host in a public subnet and assign it a public IP address to access it from the Internet.

  To provide an additional level of security, you can set up security lists to access the bastion host only from the public IP address of your on-premises network. You can access Oracle Cloud Infrastructure instances in the private subnet through the bastion host. To do this, enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your computer. You can also access the instances in the private subnet by using dynamic SSH tunneling. SSH tunneling is a way to access a web application or other listening services. The dynamic tunnel provides a SOCKS proxy on the local port, but the connections originate from the remote host.

• Load Balancer tier: This tier contains Oracle Cloud Infrastructure Load Balancing. It receives requests from application users, and then load balances traffic to Oracle E-Business Suite application servers. Use Oracle Cloud Infrastructure Load Balancing to distribute traffic to your application instances within a VCN. This service provides a primary and standby instance of the load balancer to ensure that if the primary load balancer goes down, the standby load balancer forwards the requests. The load balancer ensures that requests are routed to the healthy application instances. If there’s a problem with an application instance, then the load balancer removes that instance from configuration and starts routing requests to the remaining healthy application instances.

• Application tier: This tier contains more than one instance of an Oracle E-Business Suite application to provide high availability. Set up multiple instances of an application in separate fault domain to ensure that you can continue accessing the application even if an application instance goes down.

  Oracle recommends deploying the Oracle E-Business Suite multitier setup with shared application binaries. Use Oracle Cloud Infrastructure File Storage to create a shared file system to share Oracle E-Business Suite application binaries.

• Database tier: This tier contains Oracle Cloud Infrastructure Database instances. For high availability requirements, Oracle recommends using a 2-node Virtual Machine (VM) DB system or Exadata DB System.

This architecture shows the deployment of an Oracle E-Business Suite application in a single availability domain containing a DMZ.

The architecture consists of a virtual cloud network (VCN) with the bastion host, an internal load balancer, an internal application tier, an external load balancer, an external application tier, and database hosts placed in separate subnets of VCN in a single availability domain. In the following architecture diagram, the external load balancer is deployed in a public subnet, and all the other instances are deployed in private subnets.

Description of the illustration ebs-singlead-dmz.png

In this architecture, multiple application tier instances are deployed in a single availability domain, yet the individual application tier instances are placed in separate fault domains, allowing for high availability of the application tier. Fault domains enable you to distribute your instances so that they are not on the same physical hardware within a single availability domain. As a result, a hardware failure or hardware maintenance that affects one fault domain does not affect instances in other fault domains.

Instances in the private subnet require outbound connection to Oracle Services Network to apply operating system (yum) updates. For this purpose, use a service gateway in your VCN. With a service gateway, the hosts in the private subnet can access supported Oracle services (such as the yum repository) privately. Instances in the private subnet may optionally require outbound connection to the Internet to download application patches and for external integrations. For this purpose, use a Network Address Translation (NAT) gateway in your VCN. With a NAT gateway, the hosts in the private subnet can initiate connections to the Internet and receive responses, but won’t receive inbound connections initiated from the Internet.

All application instances in the availability domain are active. The load balancer instances receive requests and send it to the application servers. The application servers process these requests and forward it to the database instances. You can access the instances in private subnets over port 22 through the bastion host or the Dynamic Routing gateway (DRG) if you have set up an IPSec VPN tunnel between your data center and Oracle Cloud Infrastructure DRG.

The DMZ, which is implemented using a public load balancer subnet, receives requests from business partners and suppliers, while the internal load balancer, implemented using a private load balancer subnet, receives requests from internal users. Dedicated application tiers process the requests coming from these two different types of users.

Oracle recommends that the database and the applications deployed on Oracle Cloud Infrastructure should have a robust backup and recovery strategy. It is recommended to store backups of databases and application tier instances in the Oracle Cloud Infrastructure Object Storage. The databases and application tier instances in private subnets can be backed up to Oracle Cloud Infrastructure Object Storage by using a service gateway. A service gateway provides access to Oracle Cloud Infrastructure Object Storage without traversing the Internet.

The automatic and on-demand database backups to Oracle Cloud Infrastructure Object Storage can be configured using the Oracle Cloud Infrastructure console. This requires connectivity to Oracle Cloud Infrastructure Object Storage using a Swift endpoint. All database backups on Oracle Cloud Infrastructure Object Storage are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption. The automatic database backup service uses weekly incremental backup strategy to backup databases with a custom retention policy that you can customize when configuring automatic backups.

The backup of application can be configured by using the policy-based backup feature of Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes provides you with the capability to perform volume backups automatically based on a schedule and retain them based on the selected backup policy. This allows you to adhere to your data compliance and regulatory requirements. There are three predefined backup policies: Bronze, Silver, and Gold. Each backup policy has a predefined backup frequency and retention period.

This architecture supports the following components:

• Bastion host: The bastion host is an optional component that can be used as a jump server to access instances in the private subnet. A bastion host is an Oracle Cloud Infrastructure Compute instance that uses Linux as its operating system.

  To provide an additional level of security, you can set up security lists to access the bastion host only from the public IP address of your on-premises network. You can access Oracle Cloud Infrastructure instances in the private subnet through the bastion host. To do this, enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your computer. You can also access the instances in the private subnet by using dynamic SSH tunneling. SSH tunneling is a way to access a web application or other listening services. The dynamic tunnel provides a SOCKS proxy on the local port, but the connections originate from the remote host.

• Internal Load Balancer tier This tier contains Oracle Cloud Infrastructure Load Balancing. It receives requests from internal application users, and then load balances traffic to Oracle E-Business Suite internal application servers. Use Oracle Cloud Infrastructure Load Balancing to distribute traffic to your application instances within a VCN. This service provides a primary and standby instance of the load balancer to ensure that if the primary load balancer goes down, the standby load balancer forwards the requests. The load balancer ensures that requests are routed to the healthy application instances. If there’s a problem with an application instance, then the load balancer removes that instance from configuration and starts routing requests to the remaining healthy application instances.
• External Load Balancer tier: This tier serves the same purpose as the internal load balancer tier, but for external application users such as those associated with suppliers.

• Application tier: This tier contains more than one instance of an Oracle E-Business Suite application to provide high availability. Set up multiple instances of an application in separate fault domain to ensure that you can continue accessing the application even if an application instance goes down.

  In this architecture, leveraging separate application tiers for your internal and external users lets you isolate the traffic and protect the security of your system.

  Oracle recommends deploying the Oracle E-Business Suite multitier setup with shared application binaries. Use Oracle Cloud Infrastructure File Storage to create a shared file system to share Oracle E-Business Suite application binaries.

• Database tier: This tier contains Oracle Cloud Infrastructure Database instances. For high availability requirements, Oracle recommends using a 2-node Virtual Machine (VM) DB system or Exadata DB System.

This architecture shows the deployment of an Oracle E-Business Suite application across multiple availability domains. It shows a virtual cloud network (VCN) with the bastion, load balancer, application, and database instances placed in separate subnets across two availability domains.

Multiple application servers are deployed in each availability domain to ensure high availability within an availability domain. All application servers within an availability domain are deployed across different fault domains. By using different fault domains, application instances are protected against unexpected hardware failures and planned outages due to hardware maintenance. In addition, to ensure availability in case the primary availability domain is not available, redundant instances are created in another availability domain. In the architecture diagram, the instances in Availability Domain 1 are active and the instances in Availability Domain 2 are on standby. Oracle recommends that you set up application and database instances in symmetric topology across availability domains to ensure that your active instances serve the entire load when the primary availability domain is not available. In the symmetric topology, you deploy the same number of application and database instances on both the active and standby sites. When the instances in Availability Domain 1 are active, the load balancer is configured to direct traffic only to these active instances. The load balancer is not configured to direct traffic to the application server instances in Availability Domain 2. This means the application instances in Availability Domain 2 are not added to load balancer backend set. If Availability Domain 1 is not available, then you’ll have to manually switch over the application and database to the other availability domain. In this scenario, the application and database server instances in Availability Domain 2 become active. At this time, you need to update the backend set of the load balancer with application instances in Availability Domain 2 and also remove the application instances of Availability Domain 1. The load balancer will then accept requests and forward them to application servers in Availability Domain 2.

For a seamless failover across availability domains, use logical host names for the Oracle E-Business Suite database and application instances. Use the same logical host names on the primary and standby sites to reduce the effort for reconfiguring instances during switchover or failover.

The database and application deployed on Oracle Cloud Infrastructure is recommended to have a robust backup of recovery strategy. It is recommended to store backup of databases and application instances in the Oracle Cloud Infrastructure Object Storage. The databases and application instances in private subnets can be backed up to Oracle Cloud Infrastructure Object Storage by using a service gateway. A service gateway provides access to Oracle Cloud Infrastructure Object Storage without traversing the Internet.

The automatic and on-demand database backups to Oracle Cloud Infrastructure Object Storage can be configured using the Oracle Cloud Infrastructure console. This requires connectivity to Oracle Cloud Infrastructure Object Storage using a Swift endpoint. All database backups on Oracle Cloud Infrastructure Object Storage are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.

The automatic database backup service uses weekly incremental backup strategy to backup databases with a 30-day retention policy. It is also possible to perform an on-demand full backup of databases for ad-hoc requirements.

In the following architecture diagram, the bastion host is deployed in a public subnet and all other instances are deployed in private subnets. You can place the different instances in public or private subnets based on your business requirements. You can access the instances in private subnets over port 22 through the bastion host or the DRG if you have set up an IPSec VPN tunnel between your data center and Oracle Cloud Infrastructure DRG.

Description of the illustration multiple_availability_domain_ha_topology.png

This architecture supports the following components:

• Bastion host: The bastion host is an optional component that you can use as a jump server to access the application and database instances. For high availability, deploy a bastion host in both availability domains.

• Load Balancer tier: Oracle Cloud Infrastructure Load Balancing distributes traffic across the application servers in an availability domain. The load balancer can be provisioned as a public or private load balancer.

• Application tier: Multiple application servers are set up in each availability domain to ensure high availability. The application servers in Availability Domain 1 are in the active state, and the application servers in the Availability Domain 2 are in the passive state. To synchronize application servers across availability domains, use rsync.

  Oracle recommends deploying the Oracle E-Business Suite multitier setup with shared application binaries. Use Oracle Cloud Infrastructure File Storage to create a shared file system to share Oracle E-Business Suite application binaries.

• Database tier: Set up highly-available database instances in both availability domains. The architecture diagram shows that the database servers in Availability Domain 1 are active and the database servers in Availability Domain 2 are on standby. To replicate the database across availability domains, use either Oracle Active Data Guard or Oracle Data Guard. You can enable Oracle Data Guard for a database from the Oracle Cloud Infrastructure console or by using Oracle Cloud Infrastructure APIs.

You can deploy the Oracle E-Business Suite application across multiple regions for disaster recovery. This architecture is similar to deploying the Oracle E-Business Suite application across multiple availability domains. In this architecture bastion, load balancer, application, and database instances are placed in separate subnets across multiple regions.

To ensure availability in case the primary region is not available, redundant instances are created in the standby region. The primary region contains active instances in an availability domain. The instances in an availability domain in the second region, called the disaster recovery region, are on standby. Oracle recommends that you set up application and database instances in symmetric topology across regions to ensure that your active instances serve the entire load when the primary region is not available. In the symmetric topology, you deploy the same number of application and database instances on both the primary and standby regions. In this architecture, multiple application servers are deployed in each availability domain to ensure high availability within an availability domain.

As this architecture is deployed in just one availability domain in region 1 and one availability domain in Region 2 for disaster recovery, it does not provide fault tolerance for availability domain in Region 1. If the only availability domain where application has been deployed is not available, you’ll need to invoke disaster recovery to fail over your application to Region 2.

If the instances in Region 1 aren’t available, then you must manually switch over to the instances in Region 2. For a seamless failover across regions, use logical host names for the Oracle E-Business Suite database and application instances. Use the same logical host names on the primary and standby sites to make it easier to failover or switch back without reconfiguring instances.

To replicate the database across multiple regions, use either Oracle Active Data Guard or Oracle Data Guard in asynchronous mode. To synchronize application servers across multiple regions, use rsync.

Description of the illustration multiple_region_topology.png