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 subinet. The web servers are placed in the public subnet in this image, so the web server instances have 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 bastion host in 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 is the gateway that connects your on-premises network to your cloud network. To enable communication between the DRG and the customer-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 2-node Oracle Real Application Clusters (Oracle RAC) database systems. The two nodes of Oracle RAC are always created in separate fault domains by default. 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 a PeopleSoft application in a single availability domain while ensuring high availability.

The architecture consists of a VCN with the bastion, load balancer, application, and database hosts placed in separate subnets of the VCN in a single availability domain. 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.

In this architecture, redundant instances are deployed in the application tier and database tier to ensure high availability within the availability domain. This ensures that your application is available even when an application instance goes down. The other available application instances in the availability domain continue to process the requests. All application instances in the availability domain are active. The load balancer instances receive requests and sends it to the application servers. This high availability of an application within an availability domain can be achieved by placing application instances in separate fault domains. 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 the Internet to download patches as well as to apply operating system and application updates. For this purpose, use a Network Address Translation (NAT) gateway in your VCN. With a NAT gateway, the hosts in private subnet can initiate connections to the Internet and receive responses, but won’t receive inbound connections initiated from the Internet.

Oracle recommends that the database and the applications deployed on Oracle Cloud Infrastructure should 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.

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 peoplesoft_single_availability_domain_ha_topology.png

This architecture shows the deployment of PeopleSoft application servers in multiple availability domains. It shows a VCN with the bastion, load balancer, application, and database hosts placed in separate subnets across two availability domains.

In the architecture diagram, the bastion host is deployed in a public subnet, and all other instances are deployed in private subnets. You can place the 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. All instances are active in the two availability domains. The only passive components in the architecture are the database hosts in Availability Domain 2.

The bastion hosts in Availability Domain 1 and Availability Domain 2 are active and can serve SSH requests to instances in both availability domains at all times. The on-premises DNS or external DNS service receives request for PeopleSoft application. These requests are round-robin load balanced to one of the load balancers in Availability Domain 1 or 2. The load balancer then routes the request to one of the underlying PeopleSoft web server in Availability Domain 1 or 2. The PeopleSoft web server then routes the request to one of the PeopleSoft application servers, and finally the application server forward requests to the active database instances in Availability Domain 1 for processing.

If Availability Domain 1 is not available, you must manually remove the entry of Availability Domain 1 load balancer from the DNS service and switch over the database to the database instances in Availability Domain 2. Requests received from DNS service are now routed to the load balancer in Availability Domain 2, and then finally to the database in Availability Domain 2 for processing.

Description of the illustration peoplesoft_multiple_availability_domain_ha_topology.png

• Bastion host: A bastion host is an optional component that you can provision in each availability domain to act as a jump host to access application and database instances. Bastion hosts in both Availability Domain 1 and Availability Domain 2 are in the active state.

• Load balancer instances: Oracle Cloud Infrastructure Load Balancing instances distribute traffic across the application servers in both of the availability domains. Load balancer instances in both Availability Domain 1 and 2 are active. Requests received at the PeopleSoft URL are round-robin load balanced to a load balancer in Availability Domain 1 or 2 by an on-premises or an external DNS service.

• Application tier: Both Availability Domain 1 and Availability Domain 2 contain redundant instances of PeopleSoft application server, PeopleSoft web server, ElasticSearch servers, and PeopleSoft Process Scheduler. All instances in the application tier across the two availability domains are in the active state.

• PeopleTools client: Use PeopleTools client to perform administration activities, such as development, migration, and upgrade.

• Database tier: Se up highly-available database instances in both availability domains. Availability Domain 1 hosts the primary database instances. Availability Domain 2 hosts the standby database instances. In each availability domain, at least two database instances are set up to ensure high availability. If a database instance is not available in Availability Domain 1, then the second database instance in Availability Domain 1 continues processing requests.

  Use Oracle Active Data Guard in synchronous mode to replicate the database across availability domains in a region.

This architecture shows the deployment of PeopleSoft application servers across multiple regions while ensuring high availability and disaster recovery. It shows a VCN with the bastion, load balancer, application, and database instances placed in separate subnets across two regions. To ensure that you can access PeopleSoft application instances, even when all availability domains in a region go down, deploy PeopleSoft across multiple regions.

The architecture diagram shows two regions. In Region 1, PeopleSoft is deployed in multiple availability domains to ensure high availability across availability domains within a region. Region 2 is the disaster recovery region. All instances are active in the two availability domains in Region 1. The passive components in the architecture are the database hosts in Availability Domain 2 and all the instances in Region 2. Oracle recommends that the number of instances you deploy for each tier in the availability domain in Region 2 should be the same as the number of instances deployed in an availability domain in Region 1. This ensures that the application instances can take the entire load after disaster recovery is invoked.

It is also possible to have this architecture deployed in just one availability domain in region 1 and one availability domain in region 2 for disaster recovery. However, this architecture 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.

In Region 1, the bastion hosts in Availability Domain 1 and Availability Domain 2 are active and can serve SSH requests to instances in both availability domains at all times. The on-premises DNS or external DNS service receives request for PeopleSoft application. These requests are round-robin load balanced to one of the load balancers in Availability Domain 1 or 2. The load balancer then routes the request to one of the underlying PeopleSoft web server in Availability Domain 1 or 2. The PeopleSoft web server then routes the request to one of the PeopleSoft application servers, and finally the application server forward requests to the active database instances in Availability Domain 1 for processing.

If the instances in Region 1 aren’t available, then you must manually switch over to the instances in Region 2. In this scenario, the load balancer and database instances in Region 2 act as the primary load balancer and database instances. Requests received at the PeopleSoft URL are routed to the load balancer in Region 2, which then routes traffic to the underlying PeopleSoft web server in Region 2. The PeopleSoft web servers route the request to PeopleSoft application instances, and then the PeopleSoft application servers forward the requests to the database instances in Region 2 for processing.

In the architecture diagram, the bastion host and load balancer is deployed in public subnets, and all other instances are deployed in private subnets. You can place the 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 peoplesoft_multiple_regions_ha_topology.png

This architecture supports these components:

• Bastion host: A bastion host is an optional component that you can provision in each availability domain to act as a jump host to access application and database instances. Bastion hosts in both Availability Domain 1 and Availability Domain 2 are in the active state.

• Load balancer instances: Oracle Cloud Infrastructure Load Balancing instances distribute traffic across the application servers in both the availability domains. Availability Domain 1 and 2 in Region 1 hosts the primary load balancer instances.

• Application tier: Both Availability Domain 1 and Availability Domain 2 in Region 1 contain at least one instance of PeopleSoft application server, PeopleSoft web server, ElasticSearch servers, and PeopleSoft Process Scheduler. All instances in the two availability domains in Region 1 are in the active state. The application tier instances in Region 2 are in the passive state. To synchronize application servers across availability domains and across the regions, use rsync.

• PeopleTools client: Use the PeopleTools client to perform administration activities, such as development, migration, and upgrade.

• Database tier: Availability Domain 1 in Region 1 hosts the primary database instances. Availability Domain 2 in Region 1 and Region 2 host the standby database instances. In each availability domain, at least two database instances are set up to ensure high availability. If a database instance goes down in Availability Domain 1, then the second database instance in Availability Domain 1 continues processing requests. If Region 1 is not available, then the database instances in Region 2 process the requests.

  Oracle recommends using Oracle Active Data Guard in synchronous mode to replicate the database across availability domains in a region. To replicate database across regions, use Oracle Active Data Guard in asynchronous mode.