Load balancers are fantastic devices but sometimes we need to get around them. I can’t count the times I have needed or wanted to test/diagnosis the functionality of each PIA instance individually, especially when fighting what might appear at first as an intermittent or random issue. When we have multiple PeopleSoft PIA instances behind a load balancer or reverse proxy we set the virtual addressing URL in the web profile to be that of the URL to the load balancing device. If we try to hit SERVER-A or SERVER-B directly the URL is rewritten back to SERVER-LB. The following are some tips that may help you establish a connection to a specific PIA instance rather than the load balancer.
The hosts file
The first step I use to bypass a load balancer is to force my workstation to go to a particular PIA instance. I find the easiest way to do this is by editing the hosts file. Since Windows 7, editing this file now usually requires Admin access. So assuming you have Admin rights on your workstation, open notepad or your favorite editor as Administrator and open the file %SystemRoot%\System32\drivers\etc\hosts (usually known as C:\Windows\System32\drivers\etc\hosts). It would be /etc/hosts for everyone else and require root to modify. The file has an example entry that is commented out so you can see the syntax. At the end of the file add a line such as:
[code]
123.123.123.1 pshr.mydomain.com
[/code]
where 123.123.123.1 is the IP of the individual PIA instance you want to hit and pshr.mydomain.com is the normal name you use to access the load balanced environment. The IP and name should separated by a tab or single space. The hosts file is normally processed before DNS lookups so your workstation should now be configured to use an IP of your choice when connecting to the load balancer URL.
In simple environments this may be all you need to do. For example, in an all Windows environment without SSL, your load balancer may be listening on port 80 and using a pool of servers also listening on port 80. In this case this trick should be all you need. But if your servers are running on Linux or something else, your PIA instances are probably not on port 80. Maybe your load balancer is still listening on port 80 but forwarding to a pool listening on port 8080, or you have multiple PIA’s on one server all using different ports. The virtual addressing is set to use port 80 so the previous trick is not quite enough.
Using PortProxy
A solution to the problem in the last scenario is to change outbound traffic to one destination:port to another. On Linux I’d use an iptables rule to do this easily enough. On Windows I came up with the following solution: Use the netsh interface portproxy command. Microsoft Technet site describes portproxy as:
The Netsh Interface Portproxy commands provide a command-line tool for use in administering servers that act as proxies between IPv4 and IPv6 networks and applications.
So what we need to do is create a portproxy that redirects pshr.mydomain.com on port 80 to a specific PIA instance on port 8080. The way I use the command it creates a listening proxy on your workstation directly (it requires a command prompt running with Administration privileges).
add v4tov4 listenport= {Integer | ServiceName} [[connectaddress=] {IPv4Address | HostName}] [[connectport=] {Integer | ServiceName}] [[listenaddress=] {IPv4Address| HostName}] [[protocol=]tcp]
So our command becomes something like
[code]netsh interface portproxy add v4tov4 listenport=80 connectaddress=123.123.123.1 connectport=8080 listenaddress=192.168.100.10 protocol=tcp
[/code]
What this does is create a proxy that listens on port 80 of our workstation (assuming 192.168.100.10 is our workstation IP) and communication coming to it will be forwarded to 123.123.123.1 on port 8080. Now if you are paying attention, you will realize that this portproxy is taking care of sending packets directly to the PIA instance of your choice. So in this case we want our hosts file to actually point pshr.mydomain.com to our workstation. So edit the host file to use your workstation instead.
[code]
192.168.100.10 pshr.mydomain.com
[/code]
Now when you use your browser on your workstation and go to http://pshr.mydomain.com your browser hits your workstation on port 80 and the portproxy forwards the traffic over to a PIA on port 8080.
What about SSL offloading?
I don’t have a one-liner for this. What I’ve done in this case is usually to ensure the PIA instances are listening on both non-SSL and SSL ports and I access the site over SSL. I don’t worry about the cert errors, just that I can get connected and test what I wanted. So I use one of the two options above based on the configuration. There might be some trick with Fiddler since it can route you through it’s own cert to capture SSL data but I’ve not tried to figure out how to do that. If you know how to do it with Fiddler or another tool let me know and we can add it here.
Third party Authentication?
Sometimes there is a third party authentication or single sign on solution between the load balancer and the PIA’s and they may require customizations to the sign on process. If you have something like this in place you might be directed to a page that does not exist when trying to login while bypassing the load balancer. Usually this involves some reverse proxy as well. What you can try here is to sign in to PeopleSoft before making your changes above. Once you have a valid session you should be able to make the changes to bypass and continue the session.
Leave a Reply