Use a load balancer, or possibly a round-robbin dns resolution.
Using a load balancer we've run into some issues w/ the NSH Proxy where the LB will cut off the session and the connection to the NSH Proxy dies, so there are some settings to fiddle with there (session timeouts) or you can allow the client to connect directly to the NSH Proxy w/o going through the LB
How would the client connect to the proxy without going through the LB?
in the blasadmin settings for the 'AuthSvc' there are 2 urls that get handed out, the 'AuthSvcUrl' and the 'ProxySvcUrl' (they are the only 2 urls settings in there, I may not have them exactly right).
When you login, those Urls get sent to back to the client after authentication and that's you connect to w/ the gui or nsh. so by default it just hands out the hostname of the appserver. the session should be valid across either appserver, so you could have the 9840 port load balanced (to randomly choose a server to authenticate to) and then 9841 and 9842 go direct to the appserver w/o going through the LB. or 9841 is LB also and 9842 goes direct to the appserver (nsh proxy).
or, if you don't run into the nsh session issues through the LB you can just send everything through the LB and the SvcUrls would be the fqdn of the vip, not the appserver hostnames.
or do this w/ dns round robbin and a 'vip'.
any way you do it it should randomly distribute load across the app servers.
Thanks Bill. Yes, now I remember those two URL values in blasadmin. We haven't needed them yet so I didn't think of them. Your explanation makes sense. My only question is around the NSH proxy.
We would set 'AuthSvcUrl' to the VIP fqdn on P1 and P2, and the 'ProxySvcUrl' would be set to the P1-appserver host name on P1 and the P2-appserver name on P2 (to bypass the LB).
After logging into the client and an NSH session is opened, will NSH somehow know how to connect to the same app server that the client is connected to, or does it not matter? Doesn't the NSH proxy server you're connecting to have to match the app server that's listed in the auth profile (which would be the VIP)?
so what will happen is that the session stores the URLs that get handed out when you login. if you launch the gui, click the 'cache session credentials' option, then login, then launch another gui session and look at your session credentials you'll see the appserver url and the nsh proxy url.
when nsh fires up it looks in the cached credential file for the right url to connect to. it shouldn't matter if they are different URLs, though there might be some settings we need to change if there is an error thrown (a couple 'validate...' settings)
the issue we faced w/ connecting through the LB is that after some amount of time (15 min, 2 min, etc) the nsh console window will start spewing 'i/o' or 'ssl_connect' errors, it seems like what is happening is the f5 (or even firewall in some cases) is cutting the connection based on a timeout or session lifetime setting.
Hmm, so are you saying that as long as the proxy URL in the cached cred file is a valid one, that it will connect correctly? The secure file with the authentication profile value has no bearing on the NSH session working?
I just running through a test on my end:
My secure file has 'auth_profile=P1'
I logged into BL through nsh proxy / app server on P1
I open a 2nd BL session and log onto nsh proxy / app server on P2
(this means that P2 creds are stored in the cached cred file)
I open an NSH session and I get this error:
+SSO Error: Could not find a credential in cache file "C:\Users\...\bl_sesscc" that matches the current authentication profile.
Error in Initializing RBAC User and Role (SSO Proxy)
Network Shell can be used for local access+
Why would this happen if the creds in P2 are valid? When I change the secure file to 'auth_profile=P2', it starts up fine.
So in the case of LB, I was concerned about NSH causing errors if the LB chooses to connect to P1 nsh proxy server when the cred file is really storing P2 creds.
But if it's only checking for valid URL connections AND there is only one auth profile to choose from (with the VIP), I guess it be OK after all?
When you fire up nsh it's going to look in the secure file, then look in the cached creds file for creds for the profile name you specified in the secure file, along w/ what url (ProxySvcUrl) to connect to.
if the profile name is P2, and you're connecting to the P2 appserver, but P2 hands out the ProxySvcUrl for P1, that should still work (the nsh proxy can be on any box).
if you're connecting to the nsh proxy through a VIP/LB you'll be changing the ProxySvcUrl to be the VIP on both appservers. and that should work ok, the session creds should still be valid across both appservers