In Episode 7, we talk all about Load Balancers and PeopleSoft. We also clarify PeopleTools updates with Selective Adoption, why you may not need PSAESRV, a funny Chrome extension and more!
We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at email@example.com, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.
You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.
- PeopleTools updates now delivered by Selective Adoption/PI, not that PT becomes selective (Thanks Graham for clarification)
- PeopleSoft Talk with Greg Kelly – Security
- PeopleSoft Talk with Paco – Cloud Architecture (last half of talk)
- Let’s Encrypt: free encryption certification
- Cloud to Butt Chrome Extension
- Disabling the App Engine Server
- PeopleSoft for the Oracle DBA
- 2084851.1 – SES 12c Upgrade Instructions
- Smart v Dumb Load Balancing
- F5 Deployment Guide for PeopleSoft
- 662674.1 – XMLLink fix
- 1968048.1 – Show client IP in web server logs
3 thoughts on “#7 – Load Balancers”
Excellent podcast and related articles.
I would always recommend doing SSL termination on the load balancer
– The load balancer has decrypt the packet anyway because it needs to inspect the cookie in order to do cookie sticky load balancing
– You don’t then have to install certificates on every web server,, every application server (PSRENSRV) and Process Scheduler (PSDSTSRV posting HTTPS). However, you will still have to put root certificates into the Process Scheduler distribution server (PSDSTSRV) keystore if you are posting reports by HTTPS.
The load balancer becomes a single point of certificate management (and will probably be managed by somebody else). Certificates have a limited life and you will have to manage their renewal, usually every 2 years.
The web servers don’t need to run an HTTPS listener, but they should be firewalled off to prevent direct access.
I agree with points made about web-application server load balancing and failover. I generally prefer to co-locate web and app servers on the same nodes or VMs. The webserver uses a lot of memory but little CPU. The application server uses a lot of CPU and some memory. Splitting them up just partitions CPU and memory resources and leads to wastage. Web and Application servers should not be on separate VLANs, and if you use the PSRENSRV then you need to have a route from the load balancer to the RENSRV. I would then have the web server connect to app servers on the same server before failing over to other app servers. Thus the load balancer balances load for the application servers as well as the web server. With the combination of connection pool, load balancing and failover syntaxes in the connection string in connection.properties you could control the behaviour. You might fail over to app servers on a local server in preference to others on a remote site.