X

The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

How to achieve PeopleSoft reverse proxy setup with support of Oracle Cloud Infrastructure Load Balancing service chaining

This blog post illustrates how to set up a reverse proxy for a public URL, accessed through the internet, using Oracle Cloud Infrastructure (OCI) Load Balancing service chaining.

The initial problem with the load balancer setup and our solution

When we adopt the cloud, it’s a best practice to deploy instances on private subnets with the instances load balanced using a private load balancer. This process ensures that the instances can’t be accessed from the internet, while providing service to internal customers. However, when we require customers to access through internet, we need to set up a public load balancer. Because of security concerns, we don’t advise configuring a private subnet as the backend for the public load balancer. Previously, OCI didn’t support the chaining of a public load balancer to private load balancer traffic.

The following diagram shows the reverse proxy setup using Oracle HTTP Server.

Figure 1. PeopleSoft Network Diagram, when load balancer chaining was not supported.

 Figure 1. PeopleSoft Network Diagram, when load balancer chaining was not supported.

We route the internet traffic from the public load balancer to Oracle HTTP server, a reverse proxy server, which is deployed in the public MT subnet and redirect the traffic to private load balancer. Private and public traffic serves separate webserver domains, which are the backends for two different listeners: the first for private URL routing and the second for accepting public URL traffic coming through the reverse proxy server. For details steps, see the section How to map Private and Public URL for different web server domain.

The architecture requires the customer to purchase extra shapes and storage, which adds network hops. As a solution, the reverse proxy setup can be done using load balancer chaining, as explained in the following architecture.

Figure 2. PeopleSoft network diagram using load balancer chaining.
Figure 2. PeopleSoft network diagram using load balancer chaining.

The SSL configuration between the public and the private load balancer can use SSL tunneling or end-to-end SSL. Here, the backend set of the public load balancer has one backend, the private load balancer.

To configure, go to the “Add Backends” UI of the public load balancer, select “IP addresses,” and fill in the IP address of the private load balancer.

Configuration steps

A screenshot of the Add Backends page, with the IP address filled in and outlined in orange.

A screenshot of the Backend Set Information page, showing the backend added.

  1. Find the IP address of the private load balancer on the details page of the load balancer.

    A screenshot of the Load Balancer details page with the IP address outlined in orange.

  2. Add backends.

  3. Configure the listeners in the private load balancer. This example uses two listeners: port 443 for customer internal traffic and port 8080 as the backend for the public load balancer.

    A screenshot of the Listeners page, showing the details of the two listeners.

  4. When we configure end-to-end SSL between public and pvt load balancer, ensure that you deploy the CA certificate and enable the handshake. Also, match the host name of the pvt load balancer hostname (port 8080) with the public load balancer host name.

  5. Import the certificate.

    A screenshot of the Add Certificate page, with the Specify CA certification box outlined in red.

How to map private and public URLs for different web server domains

Configure the private URL

Public traffic from public load balancer routing to the private load balancer is balanced between the backend server webserver domains. This balancing eliminates the requirement of extra shapes, storage, and network traffic.

If we’re configuring a production environment and have two URLs, one exists for internal customer usage and the other exists for external customers. Each URL is associated with a separate web domain: WEBDOM1 and WEBDOM2, in this example.

  1. Log in to PeopleSoft.

  2. In the navigator, go to PeopleTools, Web profile, and then Web Profile Configuration. Search “PROD.”

  3. Click the virtual addressing tab.

    A screenshot of the Virtual Addressing tab in the PeopleSoft application.

  4. Update the following information:

    • Protocol: https

    • Name: (Private URL)

    • Port: 443

  5. Click Save.

Configure the public URL

  1. In the navigator, select PeopleTools, Web Profile, and then Copy Web Profile.

  2. Search “PROD.”

  3. Save the web profile as “PRODE.”

  4. Click Save.

  5. Navigate to the Virtual Addressing tab.

  6. Update the following values:

    • Protocol: https

    • Name: (Public URL)

    • Port: 443

Update the configuration.properties file

  1. cd $PS_CFG_HOME/webserv/WEBDOM1/applications/peoplesoft/PORTAL.war/WEB-INF/psftdocs/peoplesoft01

  2. Open the configuration.properties. Update the web profile to “PROD.”

  3. cd $PS_CFG_HOME/webserv/WEBDOM2/applications/peoplesoft/PORTAL.war/WEB-INF/psftdocs/ peoplesoft02

  4. Open configuration.properties. Update the web profile to “PRODE.”

  5. Restart both web server domains.

Conclusion

Every use case is different. The only way to know if Oracle Cloud Infrastructure is right for you is to try it. You can select either the Oracle Cloud Free Tier or a 30-day free trial, which includes US$300 in credit to get you started with a range of services, including compute, storage, and networking.

Join the discussion

Comments ( 1 )
  • Pranay Kumar Tuesday, October 27, 2020
    This is good saving customer costs and easing operations
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha