Set up a highly available PeopleSoft architecture on AWS - AWS Prescriptive Guidance
SummaryPrerequisites and limitationsArchitectureToolsBest practicesEpicsRelated resources

Set up a highly available PeopleSoft architecture on AWS

Created by Ramanathan Muralidhar (AWS)

Environment: Production

Technologies: Business productivity; Infrastructure; Web & mobile apps; Databases

Workload: Oracle

AWS services: Amazon EC2 Auto Scaling; Amazon EFS; Elastic Load Balancing (ELB); Amazon RDS

Summary

When you migrate your PeopleSoft workloads to AWS, resiliency is an important objective. It ensures that your PeopleSoft application is always highly available and able to recover from failures quickly.

This pattern provides an architecture for your PeopleSoft applications on AWS to ensure high availability (HA) at the network, application, and database tiers. It uses an Amazon Relational Database Service (Amazon RDS) for Oracle or Amazon RDS for SQL Server database for the database tier. This architecture also includes AWS services such as Amazon Route 53, Amazon Elastic Compute Cloud (Amazon EC2) Linux instances, Amazon Elastic Block Storage (Amazon EBS), Amazon Elastic File System (Amazon EFS), and an Application Load Balancer, and is scalable.

Oracle PeopleSoft provides a suite of tools and applications for workforce management and other business operations.

Prerequisites and limitations

Prerequisites

  • An active AWS account

  • A PeopleSoft environment with the necessary licenses for setting it up on AWS

  • A virtual private cloud (VPC) set up in your AWS account with the following resources:

    • At least two Availability Zones

    • One public subnet and three private subnets in each Availability Zone

    • A NAT gateway and an internet gateway

    • Route tables for each subnet to route the traffic

    • Network access control lists (network ACLs) and security groups defined to help ensure the security of the PeopleSoft application in accordance with your organization’s standards

Limitations

  • This pattern provides a high availability (HA) solution. It doesn’t support disaster recovery (DR) scenarios. In the rare occurrence that the entire AWS Region for the HA implementation goes down, the application will become unavailable.

Product versions

  • PeopleSoft applications running PeopleTools 8.52 and later

Architecture

Target architecture

Downtime or outage of your PeopleSoft production application impacts the availability of the application and causes major disruptions to your business.

We recommend that you design your PeopleSoft production application so that it is always highly available. You can achieve this by eliminating single points of failure, adding reliable crossover or failover points, and detecting failures. The following diagram illustrates an HA architecture for PeopleSoft on AWS.

Highly available architecture for PeopleSoft on AWS

This architecture deployment uses Amazon RDS for Oracle as the PeopleSoft database, and EC2 instances that are running on Red Hat Enterprise Linux (RHEL). You can also use Amazon RDS for SQL Server as the Peoplesoft database.

This architecture contains the following components: 

  • Amazon Route 53 is used as the Domain Name Server (DNS) for routing requests from the internet to the PeopleSoft application.

  • AWS WAF helps you protect against common web exploits and bots that can affect availability, compromise security, or consume excessive resources. AWS Shield Advanced (not illustrated) provides much broader protection.

  • An Application Load Balancer load-balances HTTP and HTTPS traffic with advanced request routing targeted at the web servers.

  • The web servers, application servers, process scheduler servers, and Elasticsearch servers that support the PeopleSoft application run in multiple Availability Zones and use Amazon EC2 Auto Scaling.

  • The database used by the PeopleSoft application runs on Amazon RDS in a Multi-AZ configuration.

  • The file share used by the PeopleSoft application is configured on Amazon EFS and is used to access files across instances.

  • Amazon Machine Images (AMIs) are used by Amazon EC2 Auto Scaling to ensure that PeopleSoft components are cloned quickly when needed.

  • The NAT gateways connect instances in a private subnet to services outside your VPC, and ensure that external services cannot initiate a connection with those instances.

  • The internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet.

  • The bastion hosts in the public subnet provide access to the servers in the private subnet from an external network, such as the internet or on-premises network. The bastion hosts provide controlled and secure access to the servers in the private subnets.

Architecture details

The PeopleSoft database is housed in an Amazon RDS for Oracle (or Amazon RDS for SQL Server) database in a Multi-AZ configuration. The Amazon RDS Multi-AZ feature replicates database updates across two Availability Zones to increase durability and availability. Amazon RDS automatically fails over to the standby database for planned maintenance and unplanned disruptions.

The PeopleSoft web and middle tier are installed on EC2 instances. These instances are spread across multiple Availability Zones and tied by an Auto Scaling group. This ensures that these components are always highly available. A minimum number of required instances are maintained to ensure that the application is always available and can scale when required.

We recommend that you use a current generation EC2 instance type for the OEM EC2 instances. Current generation instance types, such as instances built on the AWS Nitro System, support hardware virtual machines (HVMs). The HVM AMIs are required to take advantage of enhanced networking, and they also offer increased security. The EC2 instances that are part of each Auto Scaling group use their own AMI when replacing or scaling up instances. We recommend that you select EC2 instance types based on the load you want your PeopleSoft application to handle and the minimum values recommended by Oracle for your PeopleSoft application and PeopleTools release. For more information about hardware and software requirements, see the Oracle support website.

The PeopleSoft web and middle tier share an Amazon EFS mount to share reports, data files, and (if needed) the PS_HOME directory. Amazon EFS is configured with mount targets in each Availability Zone for performance and cost reasons.

An Application Load Balancer is provisioned to support the traffic that accesses the PeopleSoft application and load-balances the traffic among the web servers across different Availability Zones. An Application Load Balancer is a network device that provides HA in at least two Availability Zones. The web servers distribute the traffic to different application servers by using a load balancing configuration. Load balancing among the web server and application server ensures that load is distributed evenly across the instances, and helps avoid bottlenecks and service disruptions due to overloaded instances.

Amazon Route 53 is used as the DNS service to route traffic to the Application Load Balancer from the internet. Route 53 is a highly available and scalable DNS web service.

HA details

  • Databases: The Multi-AZ feature of Amazon RDS operates two databases in multiple Availability Zones with synchronous replication. This creates a highly available environment with automatic failover. Amazon RDS has failover event detection and initiates automated failover when these events occur. You can also initiate manual failover through the Amazon RDS API. For a detailed explanation, see the blog post Amazon RDS Under The Hood: Multi-AZ. The failover is seamless and the application automatically reconnects to the database when it happens. However, any process scheduler jobs during the failover generate errors and have to be resubmitted.

  • PeopleSoft application servers: The application servers are spread across multiple Availability Zones and have an Auto Scaling group defined for them. If an instance fails, the Auto Scaling group immediately replaces it with a healthy instance that’s cloned from the AMI of the application server template. Specifically, jolt pooling is enabled, so when an application server instance goes down, the sessions automatically fail over to another application server, and the Auto Scaling group automatically spins up another instance, brings up the application server, and registers it in the Amazon EFS mount. The newly created application server is automatically added to the web servers by using the PSSTRSETUP.SH script in the web servers. This ensures that the application server is always highly available and recovers from failure quickly.

  • Process schedulers: The process schedulers servers are spread across multiple Availability Zones and have an Auto Scaling group defined for them. If an instance fails, the Auto Scaling group immediately replaces it with a healthy instance that’s cloned from the AMI of the process scheduler server template. Specifically, when a process scheduler instance goes down, the Auto Scaling group automatically spins up another instance and brings up the process scheduler. Any jobs that were running when the instance failed must be resubmitted. This ensures that the process scheduler is always highly available and recovers from failure quickly.

  • Elasticsearch servers: The Elasticsearch servers have an Auto Scaling group defined for them. If an instance fails, the Auto Scaling group immediately replaces it with a healthy instance that’s cloned from the AMI of the Elasticsearch server template. Specifically, when an Elasticsearch instance goes down, the Application Load Balancer that serves requests to it detects the failure and stops sending traffic to it. The Auto Scaling group automatically spins up another instance and brings up the Elasticsearch instance. When the Elasticsearch instance is back up, the Application Load Balancer detects that it’s healthy and starts sending requests to it again. This ensures that the Elasticsearch server is always highly available and recovers from failure quickly.

  • Web servers: The web servers have an Auto Scaling group defined for them. If an instance fails, the Auto Scaling group immediately replaces it with a healthy instance that’s cloned from the AMI of the web server template. Specifically, when a web server instance goes down, the Application Load Balancer that serves requests to it detects the failure and stops sending traffic to it. The Auto Scaling group automatically spins up another instance and brings up the web server instance. When the web server instance is back up, the Application Load Balancer detects that it’s healthy and starts sending requests to it again. This ensures that the web server is always highly available and recovers from failure quickly.

Tools

AWS services

Best practices

Operational best practices

  • When you run PeopleSoft on AWS, use Route 53 to route the traffic from the internet and locally. Use the failover option to reroute traffic to the disaster recovery (DR) site if the primary DB instance isn’t available.

  • Always use an Application Load Balancer in front of the PeopleSoft environment. This ensures that traffic is load-balanced to the web servers in a secure fashion.

  • In the Application Load Balancer target group settings, make sure that stickiness is turned on with a load balancer generated cookie.

    Note: You might need to use an application-based cookie if you use external single sign-on (SSO). This ensures that connections are consistent across the web servers and application servers.

  • For a PeopleSoft production application, the Application Load Balancer idle timeout must match what is set in the web profile you use. This prevents user sessions from expiring at the load balancer layer.

  • For a PeopleSoft production application, set the application server recycle count to a value that minimizes memory leaks.

  • If you’re using an Amazon RDS database for your PeopleSoft production application, as described in this pattern, run it in Multi-AZ format for high availability.

  • If your database is running on an EC2 instance for your PeopleSoft production application, make sure that a standby database is running on another Availability Zone for high availability.

  • For DR, make sure that your Amazon RDS database or EC2 instance has a standby configured in a separate AWS Region from the production database. This ensures that in event of a disaster in the Region, you can switch the application over to another Region.

  • For DR, use Amazon Elastic Disaster Recovery to set up application-level components in a separate Region from production components. This ensures that in the event of a disaster in the Region, you can switch the application over to another Region.

  • Use Amazon EFS (for moderate I/O requirements) or Amazon FSx (for high I/O requirements) to store your PeopleSoft reports, attachments, and data files. This ensures that the content is stored in one central location and can be accessed from anywhere within the infrastructure.

  • Use Amazon CloudWatch (basic and detailed) to monitor the AWS Cloud resources that your PeopleSoft application is using in near real time. This ensures that you are alerted of issues instantly and can address them quickly before they affect the availability of the environment.

  • If you’re using an Amazon RDS database as the PeopleSoft database, use Enhanced Monitoring. This feature provides access to over 50 metrics, including CPU, memory, file system I/O, and disk I/O.

  • Use AWS CloudTrail to monitor API calls on the AWS resources that your PeopleSoft application is using. This helps you perform security analysis, resource change tracking, and compliance auditing.

Security best practices

  • To protect your PeopleSoft application from common exploits such as SQL injection or cross-site scripting (XSS), use AWS WAF. Consider using AWS Shield Advanced for tailored detection and mitigation services.

  • Add a rule to the Application Load Balancer to redirect traffic from HTTP to HTTPS automatically to help secure your PeopleSoft application.

  • Set up a separate security group for the Application Load Balancer. This security group should allow only HTTPS/HTTP inbound traffic and no outbound traffic. This ensures that only intended traffic is allowed and helps secure your application.

  • Use private subnets for the application servers, web servers, and database, and use NAT gateways for outbound internet traffic. This ensures that the servers that support the application aren’t reachable publicly, while providing public access only to the servers that need it.

  • Use different VPCs to run your PeopleSoft production and non-production environments. Use AWS Transit Gateway, VPC peering, network ACLs, and security groups to control the traffic flow between the VPCs and, if necessary, your on-premises data center.

  • Follow the principle of least privilege. Grant access to the AWS resources used by the PeopleSoft application only to users who absolutely need it. Grant only the minimum privileges required to perform a task. For more information, see the security pillar of the AWS Well-Architected Framework.

  • Wherever possible, use AWS Systems Manager to access the EC2 instances that the PeopleSoft application uses.

Reliability best practices

  • When you use an Application Load Balancer, register a single target for each enabled Availability Zone. This makes the load balancer most effective.

  • We recommend that you have three distinct URLs for each PeopleSoft production environment: one URL to access the application, one to serve the integration broker, and one to view reports. If possible, each URL should have its own dedicated web servers and application servers. This design helps make your PeopleSoft application more secure, because each URL has a distinct functionality and controlled access. It also minimizes the scope of impact if the underlying services fail.

  • We recommend that you configure health checks on the load balancer target groups for your PeopleSoft application. The health checks should be performed on the web servers instead of the EC2 instances running those servers. This ensures that if the web server crashes or the EC2 instance that hosts the web server goes down, the Application Load Balancer reflects that information accurately.

  • For a PeopleSoft production application, we recommend that you spread the web servers across at least three Availability Zones. This ensures that the PeopleSoft application is always highly available even if one of the Availability Zones goes down.

  • For a PeopleSoft production application, enable jolt pooling (joltPooling=true). This ensures that your application fails over to another application server if a server is down for patching purposes or because of a VM failure.

  • For a PeopleSoft production application, set DynamicConfigReload to 1. This setting is supported in PeopleTools version 8.52 and later. It adds new application servers to the web server dynamically, without restarting the servers.

  • To minimize downtime when you apply PeopleTools patches, use the blue/green deployment method for your Auto Scaling group launch configurations for the web and application servers. For more information, see the Overview of deployment options on AWS whitepaper.

  • Use AWS Backup to back up your PeopleSoft application on AWS. AWS Backup is a cost-effective, fully managed, policy-based service that simplifies data protection at scale.

Performance best practices

  • Terminate the SSL at the Application Load Balancer for optimal performance of the PeopleSoft environment, unless your business requires encrypted traffic throughout the environment.

  • Create interface VPC endpoints for AWS services like such as Amazon Simple Notification Service (Amazon SNS) and CloudWatch so that traffic is always internal. This is cost-effective and helps keep your application secure.

Cost optimization best practices

  • Tag all the resources used by your PeopleSoft environment, and enable cost allocation tags. These tags help you view and manage your resource costs.

  • For a PeopleSoft production application, set up Auto Scaling groups for the web servers and the application servers. This maintains a minimal number of web and application servers to support your application. You can use Auto Scaling group policies to scale the the servers up and down as required.

  • Use billing alarms to get alerts when costs exceed a budget threshold that you specify.

Sustainability best practices

  • Use infrastructure as code (IaC) to maintain your PeopleSoft environments. This helps you build consistent environments and maintain change control.

Epics

TaskDescriptionSkills required

Create a DB subnet group.

On the Amazon RDS console, in the navigation pane, choose Subnet groups, and then create an Amazon RDS DB subnet group with subnets in multiple Availability Zones. This is required for the Amazon RDS database to run in a Multi-AZ configuration.

Cloud administrator

Create the Amazon RDS database.

Create an Amazon RDS database in an Availability Zone of the AWS Region you selected for the PeopleSoft HA environment. When you create the Amazon RDS database, make sure to select the Multi-AZ option (Create a standby instance) and the database subnet group you created in the previous step. For more information, see the Amazon RDS documentation.

Cloud administrator, Oracle database administrator

Migrate your PeopleSoft database to Amazon RDS.

Migrate your existing PeopleSoft database into the Amazon RDS database by using AWS Database Migration Service (AWS DMS). For more information, see the AWS DMS documentation and the AWS blog post Migrating Oracle databases with near-zero downtime using AWS DMS.

Cloud administrator, PeopleSoft DBA
TaskDescriptionSkills required

Create a file system.

On the Amazon EFS console, create a file system and mount targets for each Availability Zone. For instructions, see the Amazon EFS documentation. When the file system has been created, note its DNS name. You will use this information when you mount the file system.

Cloud administrator
TaskDescriptionSkills required

Launch an EC2 instance.

Launch an EC2 instance for your PeopleSoft application. For instructions, see the Amazon EC2 documentation.

  • For Name, enter APP_TEMPLATE.

  • For OS images, choose Red Hat.

  • For Instance type, choose the instance type that’s appropriate for your PeopleSoft application. For more information, see Architecture details in the Architecture section.

Cloud administrator, PeopleSoft administrator

Install PeopleSoft on the instance.

Install your PeopleSoft application and PeopleTools on the EC2 instance you created. For instructions, see the Oracle documentation.

Cloud administrator, PeopleSoft administrator

Create the application server.

Create the application server for the AMI template and make sure that it connects successfully to the Amazon RDS database.

Cloud administrator, PeopleSoft administrator

Mount the Amazon EFS file system.

Log in to the EC2 instance as the root user and run the following commands to mount the Amazon EFS file system to a folder called PSFTMNT on the server.

sudo su –
mkdir /psftmnt
cat /etc/fstab

Append the following line to the /etc/fstab file. Use the DNS name you noted when you created the file system.

fs-09e064308f1145388.efs.us-east-1.amazonaws.com:/ /psftmnt nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0
mount -a
Cloud administrator, PeopleSoft administrator

Check permissions.

Make sure that the PSFTMNT folder has the proper permissions so that the PeopleSoft user can access it properly.

Cloud administrator, PeopleSoft administrator

Create additional instances.

Repeat the previous steps in this epic to create template instances for the process scheduler, web server, and Elasticsearch server. Name these instances PRCS_TEMPLATE, WEB_TEMPLATE, and SRCH_TEMPLATE. For the web server, set joltPooling=true and DynamicConfigReload=1.

Cloud administrator, PeopleSoft administrator
TaskDescriptionSkills required

Create a script to install the application server.

In the Amazon EC2 APP_TEMPLATE instance, as the PeopleSoft user, create the following script. Name it appstart.sh and place it in the PS_HOME directory. You will use this script to bring up the application server and also record the server name on the Amazon EFS mount.

#!/bin/ksh
. /usr/homes/hcmdemo/.profile.
psadmin -c configure -d HCMDEMO
psadmin -c parallelboot -d HCMDEMO
touch /psftmnt/`echo $HOSTNAME`
PeopleSoft administrator

Create a script to install the process scheduler server.

In the Amazon EC2 PRCS_TEMPLATE instance, as the PeopleSoft user, create the following script. Name it prcsstart.sh and place it in the PS_HOME directory. You will use this script to bring up the process scheduler server.

#!/bin/ksh
. /usr/homes/hcmdemo/. profile
/* The following line ensures that the process scheduler always has a unique name during replacement or scaling activity. */ 
sed -i "s/.*PrcsServerName.*/`hostname -I | awk -F. '{print "PrcsServerName=PSUNX"$3$4}'`/" $HOME/appserv/prcs/*/psprcs.cfg
psadmin -p configure -d HCMDEMO
psadmin -p start -d HCMDEMO
PeopleSoft administrator

Create a script to install the Elasticsearch server.

In the Amazon EC2 SRCH_TEMPLATE instance, as the Elasticsearch user, create the following script. Name it srchstart.sh and place it in the HOME directory.

#!/bin/ksh
/* The following line ensures that the correct IP is indicated in the elasticsearch.yaml file. */
sed -i "s/.*network.host.*/`hostname  -I | awk '{print "host:"$0}'`/" $ES_HOME_DIR/config/elasticsearch.yaml
nohup $ES_HOME_DIR/bin/elasticsearch &
PeopleSoft administrator

Create a script to install the web server.

In the Amazon EC2 WEB_TEMPLATE instance, as the web server user, create the following scripts in the HOME directory.

renip.sh: This script ensures that the web server has the correct IP when cloned from the AMI.

#!/bin/ksh
hn=`hostname`
/* On the following line, change the IP with the hostname with the hostname of the web template. */
for text_file in `find  *  -type f -exec grep -l '<hostname-of-the-web-template>' {} \;`
do
sed -e 's/<hostname-of-the-web-template>/'$hn'/g' $text_file > temp
mv -f temp $text_file
done

psstrsetup.sh: This script ensures that the web server uses the correct application server IPs that are currently running. It tries to connect to each application server on the jolt port and adds it to the configuration file.

#!/bin/ksh
c2=""
for ctr in `ls -1 /psftmnt/*.internal`
do
c1=`echo $ctr | awk -F "/" '{print $3}'`
/* In the following lines, 9000 is the jolt port. Change it if necessary. */
if nc -z $c1 9000 2> /dev/null; then
if [[ $c2 = "" ]]; then
c2="psserver="`echo $c1`":9000"
else
c2=`echo $c2`","`echo $c1`":9000"
fi
fi
done

webstart.sh: This script runs the two previous scripts and starts the web servers.

#!/bin/ksh
/* Change the path in the following if necessary. */
cd  /usr/homes/hcmdemo 
./renip.sh
./psstrsetup.sh
webserv/peoplesoft/bin/startPIA.sh
PeopleSoft administrator

Add a crontab entry.

In the Amazon EC2 WEB_TEMPLATE instance, as the web server user, add the following line to crontab. Change the time and path to reflect the values you need. This entry ensures that your web server always has the correct application server entries in the configuration.properties file.

* * * * * /usr/homes/hcmdemo/psstrsetup.sh
PeopleSoft administrator
TaskDescriptionSkills required

Create an AMI for the application server template.

On the Amazon EC2 console, create an AMI image of the Amazon EC2 APP_TEMPLATE instance. Name the AMI PSAPPSRV-SCG-VER1. For instructions, see the Amazon EC2 documentation.

Cloud administrator, PeopleSoft administrator

Create AMIs for the other servers.

Repeat the previous step to create AMIs for the process scheduler, Elasticsearch server, and web server.

Cloud administrator, PeopleSoft administrator

Create a launch template for the application server Auto Scaling group.

Create a launch template for the application server Auto Scaling group. Name the template PSAPPSRV_TEMPLATE. In the template, choose the AMI you created for the APP_TEMPLATE instance. For instructions, see the Amazon EC2 documentation.

  • In the launch template, select the instance type based on your requirements.

  • In the User data field of the Advanced details section, add the following entries. Make sure that the path and user information are correct. You created the appstart.sh script in a previous step.

    #! /bin/ksh
su -c “/usr/homes/hcmdemo/appstart.sh” - hcmdemo
Cloud administrator, PeopleSoft administrator

Create a launch template for the process scheduler server Auto Scaling group.

Repeat the previous step to create a launch template for the process scheduler server Auto Scaling group. Name the template PSPRCS_TEMPLATE. In the template, choose the AMI you created for the process scheduler.

  • In the User data field of the Advanced details section, add the following entries. Make sure that the path and user information are correct. You created the prcsstart.sh script in a previous step.

    #! /bin/ksh
su -c “/usr/homes/hcmdemo/prcsstart.sh” - hcmdemo
Cloud administrator, PeopleSoft administrator

Create a launch template for the Elasticsearch server Auto Scaling group.

Repeat the previous steps to create a launch template for the Elasticsearch server Auto Scaling group. Name the template SRCH_TEMPLATE. In the template, choose the AMI you created for the search server.

  • In the User data field of the Advanced details section, add the following entries. Make sure that the path and user information are correct. You created the srchstart.sh script in a previous step.

    #! /bin/ksh
su -c “/usr/homes/essearch/srchstart.sh” - essearch
Cloud administrator, PeopleSoft administrator

Create a launch template for the web server Auto Scaling group.

Repeat the previous steps to create a launch template for the web server Auto Scaling group. Name the template WEB_TEMPLATE. In the template, choose the AMI you created for the web server.

  • In the User data field of the Advanced details section, add the following entries. Make sure that the path and user information are correct. You created the webstart.sh script in a previous step.

    #! /bin/ksh
su -c “/usr/homes/hcmdemo/webstart.sh” - hcmdemo
Cloud administrator, PeopleSoft administrator
TaskDescriptionSkills required

Create an Auto Scaling group for the application server.

On the Amazon EC2 console, create an Auto Scaling group called PSAPPSRV_ASG for the application server by using the PSAPPSRV_TEMPLATE template. For instructions, see the Amazon EC2 documentation.

  • On the Choose instance launch options page, select the correct VPC and then select multiple subnets from different Availability Zones.

  • On the Configure advanced options page, do not select a load balancer.

  • On the Configure group size and scaling policies page, choose settings depending on how much load you want to architect your system for and whether you want to use a scaling policy. We recommend that you set the desired and minimum capacity to 2 at a minimum so that at least one instance is available to service the traffic at any point in time. For more information about Auto Scaling policies, see the Amazon EC2 documentation.

Cloud administrator, PeopleSoft administrator

Create Auto Scaling groups for the other servers.

Repeat the previous step to create Auto Scaling groups for the process scheduler, Elasticsearch server, and web server.

Cloud administrator, PeopleSoft administrator
TaskDescriptionSkills required

Create a target group for the web server.

On the Amazon EC2 console, create a target group for the web server. For instructions, see the Elastic Load Balancing documentation. Set the port to the port that the web server is listening on.

Cloud administrator

Configure health checks.

Confirm that the health checks have the correct values to reflect your business requirements. For more information, see the Elastic Load Balancing documentation.

Cloud administrator

Create a target group for the Elasticsearch server.

Repeat the previous steps to create a target group called PSFTSRCH for the Elasticsearch server, and set the correct Elasticsearch port.

Cloud administrator

Add target groups to Auto Scaling groups.

Open the web server Auto Scaling group called PSPIA_ASG that you created earlier. On the Load balancing tab, choose Edit and then add the PSFTWEB target group to the Auto Scaling group.

Repeat this step for the Elasticsearch Auto Scaling group PSSRCH_ASG to add the target group PSFTSRCH you created earlier.

Cloud administrator

Set session stickiness.

In the target group PSFTWEB, choose the Attributes tab, choose Edit, and set the session stickiness. For stickiness type, choose Load balancer generated cookie, and set the duration to 1. For more information, see the Elastic Load Balancing documentation.

Repeat this step for the target group PSFTSRCH.

Cloud administrator
TaskDescriptionSkills required

Create a load balancer for the web servers.

Create an Application Load Balancer named PSFTLB to load-balance traffic to the web servers. For instructions, see the Elastic Load Balancing documentation.

  • Provide the load balancer name.

  • For Scheme, choose Internet-facing.

  • In the Network mapping section, select the correct VPC and at least two public subnets from different Availability Zones.

  • In the Listeners and routing section, select the target group PSFTWEB and specify the correct protocol and port number.

Cloud administrator

Create a load balancer for the Elasticsearch servers.

Create an Application Load Balancer named PSFTSCH to load-balance traffic to the Elasticsearch servers.

  • Provide the load balancer name.

  • For Scheme, choose Internal.

  • In the Network mapping section, select the correct VPC and private subnets.

  • In the Listeners and routing section, select the target group PSFTSRCH and specify the correct protocol and port number.

Cloud administrator

Configure Route 53.

On the Amazon Route 53 console, create a record in the hosted zone that will service the PeopleSoft application. For instructions, see the Amazon Route 53 documentation. This ensures that all the traffic passes through the PSFTLB load balancer.

Cloud administrator

Related resources