I'm looking for advice on handling server reboots, whether they're planned or unexpected, in a multi-tier Peoplesoft Campus Solutions setup. We've successfully run Peoplesoft Campus Solutions on AIX for years, but we're transitioning to Linux soon. My main concern is understanding how the rebooting of one server impacts other elements of the stack since we've noticed that each tier heavily relies on the others to function properly.
On AIX, we didn't have to think much about this because rebooting was rare, but with Linux, constant reboots are more common unless we use things like kpatch or tux. On top of that, we face potential problems like OOM killer situations that could affect parts of our app stack. Customers have told us that if a database server goes down, it's essential to bring down the app and web servers before bringing the database back up, otherwise, we might run into issues with the app not recovering. They also mentioned the importance of rebooting in a specific order and why some teams are hesitant to set up automated start/stop scripts. I'm eager to hear how others handle reboots in the Campus Solutions context!
1 Answer
We’re currently running Peoplesoft Campus Solutions on RHEL8/9 and we've set up Weblogic failover, which has worked well for us. In fact, we're right in the middle of a rolling PS reboot as I type this, and there’s no outage happening. I recommend checking out older presentations from HEUG, especially one from Alliance 2016, as we implemented some great strategies from that. It's crucial to have the database up first, followed by the app, and then the web server. Otherwise, you might face recovery issues. We do have services configured to autostart, but they often don't behave as expected, so I find myself starting them up manually using psadmin quite frequently.
Thanks for the insight! I think we can access HEUG resources, so I’ll see if I can track down that presentation. I can suggest a few architectural changes for CS, but I can't enforce them since I don't manage it. Originally, the setup was efficient with a cross web/app architecture but I’ve noticed most clients reverted back to a 1:1:DB relationship for no clear reason.
Wow, it sounds like finding that presentation is a bit of a chore! If you’re looking for it, focus on Weblogic failover or clustering sessions from Alliance. It can get overwhelming since there are so many options, but searching for specific keywords like 'Weblogic Clustering' may help you find it faster.