Understand the PeopleSoft Architecture

Learn about the different tiers in a PeopleSoft deployment.

About the Bastion Host

A bastion host is an optional component that you can use with firewall policies to protect the management interfaces of database and application servers from external access. 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 service. The dynamic tunnel provides a SOCKS proxy on the local port, but the connections originate from the remote host.

About the Load Balancer Tier

Use Oracle Cloud Infrastructure Load Balancing to distribute traffic to your application instances across availability domains 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 and starts routing requests to the remaining healthy application instances.

Based on your requirements, you can place load balancers in a public or private subnet.

• For internal endpoints, that aren’t accessible from the internet, use a private load balancer. A private load balancer has a private IP address, and it isn’t accessible from the internet. Both the primary and the standby instances of a load balancer reside in the same private subnet. You can access private load balancers in the VCN or in your data center over the IPSec VPN through a DRG. The private load balancer accepts traffic from your data center, and distributes the traffic to underlying application instances.

• For internet-facing endpoints, use a public load balancer. A public load balancer has a public IP address, and it’s accessible from the internet. You can access the public load balancers from the internet through the internet gateway.

• For accessing internal endpoints and internet-facing endpoints, set up private load balancers and public load balancers. Set up private load balancers to serve the internal traffic, and set up public load balancers to serve the traffic from the internet.

Register the public or private IP address of Oracle Cloud Infrastructure Load Balancing instances in your on-premises or public domain name server (DNS) for domain resolution of your application endpoint.

About the Application Tier

All the instances in the application tier are configured and connected to database instances which are in the active state. The application tier contains the following PeopleSoft internet architecture components:

• PeopleSoft web servers: The PeopleSoft web servers receive application requests from the web environment, the internet and the intranet, through the load balancer. Incoming traffic is distributed by the load balancer over port 8000. It forwards the requests to the Oracle Tuxedo Jolt port on the application server. In the architecture diagram, multiple web servers have been deployed to support high availability.

• ElasticSearch servers: The Oracle PeopleSoft search framework provides a standard method to use search indexes for all PeopleSoft applications. The search framework depends on ElasticSearch servers. It interacts with the PeopleSoft web servers over port 9200.

• PeopleSoft application servers: PeopleSoft application servers handle the bulk of the workload in the PeopleSoft system. It runs the business logic, and it processes all the application requests coming from the web server over Oracle Tuxedo Jolt ports 9000. The application server is also responsible for maintaining the SQL connection to the database over port 1521. Application requests are received at the web server. These requests are forwarded to the application servers, and then the application servers submit the SQL to database servers.

• PeopleSoft Process Scheduler: An instance of the PeopleSoft Process Scheduler is required in order to run Windows-specific processes or jobs, such as NVision. This instance is deployed on Windows operating system.

• PeopleTools client: PeopleTools clients are Windows-based clients. They are also referred to as the PeopleTools Development Environment. These clients, which run on supported Microsoft Windows platforms, can connect to the PeopleSoft database using client connectivity software (a two-tier connection) over port 1521 or through a PeopleSoft application server (a three-tier connection) over port 7000. The PeopleTools client is an integrated part of PeopleSoft internet architecture because it helps administrators perform management and migration tasks.

Set up Oracle Cloud Infrastructure File Storage to stage PeopleSoft software. A single file storage file system can be created to share software binaries across application servers, web servers, and ElasticSearch servers.

You can use Oracle Cloud Infrastructure Object Storage to back up the PeopleSoft application instances.

About the Database Tier

For high availability requirements, Oracle recommends that you use one of the following options to set up the PeopleSoft database instances:

• Two-node, Oracle Real Application Clusters (Oracle RAC) database systems on virtual machine.

• Oracle Database Exadata Cloud Service instances. This service provides Oracle Database hosted on Oracle Exadata Database Machine in Oracle Cloud.

Place database systems in a separate subnet.

The database instances are set up to be highly available, and both instances of the database in an availability domain are active. Requests received from the application tier are load balanced across the database instances. If one database instance is down, then the other database instance services the requests. You can use Oracle Cloud Infrastructure Object Storage to back up the PeopleSoft database using RMAN.

Use security lists to restrict access to the database servers only from the bastion host, application servers, and on-premises servers. Set up security lists to ensure that communication occurs only over port 22, through the bastion host, and over port 1521, through the application server. Also ensure that the database systems can’t be accessed over the internet.

If you deployed PeopleSoft in multiple availability domains, then use Oracle Active Data Guard in synchronous mode to replicate the database across the availability domains. Port 1521 is open for communication with Oracle Active Data Guard. Data Guard transport services use port 1521 to transmit redo log files of Oracle Active Data Guard.

About the Security Lists

In Oracle Cloud Infrastructure, firewall rules are configured through security lists. A separate security list is created for each subnet.

Oracle recommends that you create separate subnets for the database, application, load balancer, and bastion hosts to ensure that the appropriate security list is assigned to the instances in each subnet. Use security lists to permit traffic between different tiers and between the bastion host and external hosts. Security lists contain ingress and egress rules to filter traffic at the subnet level. They also contain information about communication ports through which data transfer is permitted. Those ports (or in some cases, the protocols that will need open ports in the security rules) are shown on each security rule line in the architecture diagrams.

Each security list is enforced at the instance level. However, when you configure your security lists at the subnet level, all instances in a particular subnet are subject to the same set of rules. Each subnet can have multiple security lists associated with it, and each list can have multiple rules. The transfer of a data packet is permitted if a rule in any of the lists allows traffic (or if the traffic is part of an existing connection that’s being tracked). In addition to security lists, use iptables to implement another layer of security at the instance level.

For deployments in a public subnet, you can provide an additional level of security by preventing access to the application and database instances from the internet. Use a custom security list to prevent access to the application and database instances from the internet, and permit access to the database and application hosts over port 22 from the bastion host for administration purposes. Don’t enable SSH access to the application and database instances from the internet, but you can permit SSH access to these instances from the subnet that contains the bastion host.

You can access your instances in the private subnet through the bastion server.

For multiple availability domain architecture, use same security lists across the subnets in all availability domains.

Security List for the Bastion Host

The bastion security list allows the bastion host to be accessible from the public Internet over port 22.

• To permit SSH traffic from the on-premises network to the bastion host over Internet:

  Stateful ingress: Allow TCP traffic from the source CIDR 0.0.0.0/0 and all source ports to the destination port 22 (SSH).

  Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

  You can also restrict bastion host to be accessible over the Internet on port 22 only from your data center instead of public Internet (0.0.0.0/0). To achieve this, use your edge router IP instead of the source CIDR as 0.0.0.0/0 in the stateful ingress rule.

• To permit SSH traffic from the bastion host to Oracle Cloud Infrastructure Compute instances:

  Stateful egress: Allow TCP traffic to the destination CIDR 0.0.0.0/0 from all source ports to all destination ports.

  Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Security List for the Load Balancer Tier

The architecture diagrams show private load balancers, which are placed in private subnets. If you place the load balancer instances in a public subnet, then you’re permitting traffic from the Internet (0.0.0.0/0) to the load balancer instances.

• To permit traffic from the Internet to the load balancer:

  Stateful ingress: Allow TCP traffic from source CIDR (Internet) 0.0.0.0/0 and all source ports to the destination port 8000/8448 (HTTP) or 443 (HTTPS).

  Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 8000/8448 or 443

• To permit traffic from the on-premises network to the load balancer:

  Stateful ingress: Allow TCP traffic from the on-premises network CIDR block and all source ports to the destination port 8000/8448 (HTTP) or 443 (HTTPS).

  Source Type = CIDR, Source CIDR = <CIDR block for onpremises network>, IP Protocol = TCP, Source Port Range = All, Destination port range = 8888 or 443

• To permit traffic from the load balancer tiers to the application tiers:

  Stateful egress: Allow TCP traffic to destination CIDR 0.0.0.0/0 from all source ports to the destination port 8000/8448 (HTTP) .

  Destination Type = CIDR, Destination CIDR = <CIDR block for application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 8000/8448

Security List for the Application Tier

• To permit traffic from the bastion host to the application tier:

  Stateful ingress: Allow TCP traffic from source CIDR block of the bastion host on TCP to destination port 22.

  Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• To permit traffic from the load balancer subnet to web server subnet in the application tier:

  Stateful ingress: Allow TCP traffic from source CIDR block of the load balancer tiers to destination port 8000 or 8443.

  Source Type = CIDR, Source CIDR = <CIDR block of load balancer subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 8000 or 8443

• To permit traffic from the web server subnet to application server subnet:

  Stateful ingress: Allow TCP traffic from source CIDR blocks of the PeopleSoft web servers to destination ports 9033 to 9039.

  Source Type = CIDR, Source CIDR = <CIDR block of web server subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 9033 to 9039

• To permit traffic from the web server subnet to ElasticSearch servers:

  Stateful egress: Allow TCP traffic from source CIDR blocks of the web servers to destination port 9200.

  Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 9200

• To permit traffic from ElasticSearch servers to Process Scheduler servers:

  Stateful egress: Allow TCP traffic from source CIDR blocks of the web servers to destination port 3389.

  Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 3389

• To permit traffic from the application server subnet to PeopleTools client:

  Stateful egress: Allow TCP traffic from source CIDR blocks of PeopleTools Client subnet to destination port 3389.

  Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 3389

• To permit traffic from the application tier to the database tier:

  Stateful egress: Allow TCP traffic source CIDR blocks of the application server subnet to destination port 1521.

  Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 1521

Security List for the PeopleTools Client

The PeopleTools Client uses Windows operating system, so you have to RDP to this instance.

• To permit traffic from the bastion host to the PeopleTools Client:

  Stateful ingress: Allow TCP traffic from source CIDR blocks of the bastion host on TCP to destination port 3389 using RDP.

  Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 3389

• To permit traffic from PeopleTools Client to database server subnet:

  Stateful egress: Allow TCP traffic from source CIDR blocks of PeopleTools Client subnet to destination port 1521.

  Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 1521

Security List for the Database Tier

• To permit traffic from the bastion host to the database tier:

  Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• To permit traffic from the application tiers to the database tier:

   Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range =1521

• To permit traffic from the database tier to the application tier:

  Stateful egress: Destination Type = CIDR, Destination 0.0.0.0/0 on TCP, source port = All, destination port = All

• To permit traffic for backup of database to Oracle Cloud Infrastructure Object Storage:

  Stateful egress:  Destination Type = Service, Destination OCI <region> Object Storage, source port = All, destination port = 443

  For multiple availability domain architecture, to permit traffic between the database tiers across availability domains for Oracle Active Data Guard:

  • Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of database subnet in availability domain 1>, IP Protocol = TCP, Source Port Range = All, Destination port range =1521

  • Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of database subnet in availability domain 2>, IP Protocol = TCP, Source Port Range = All, Destination port range =1521

For Oracle Database Exadata Cloud Service system provisioning, the following additional rules are required:

• Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of exadata client subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range =All

• Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of exadata client subnet>, IP Protocol = ICMP, Type and Code = All

• Stateful egress: Destination Type = CIDR, Destination CIDR = <CIDR block of exadata client subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

• Stateful egress: Destination Type = CIDR, Destination CIDR = <CIDR block of exadata client subnet>, IP Protocol = ICMP, Type and Code = All