Solarwinds is Windows based.  The need is to leverage F5 to load balance Solarwinds across two different data centers and this topic is to discuss how we could do this with either GTM using a WideIP or LTM or both.

We have a main polling/web engine and have 2 additional Web Engines.  We are currently balancing over the 2 additional Web Engines with F5 BigIP-DNS (aka: GTM).  The GTM WideIP has a single pool containing the two additional Web Engines as its pool members.  Note that I don’t include the main poller/web engine in the webGui pool but leave it with as many resources as possible for its polling.

We use the Static Persist LB method on the pool to ensure users maintain the same resolved IP address and do not resolve the other pool member.  This is necessary if you want to avoid having to re-login mid session because you ‘landed’ on the alternate pool member.  The Web Engines are not clustered and are unique entities so there is no persistence across the Web Engines.

The Static Persist LB method means that when a DNS server resolves an IP, that same IP will be resolved indefinitely when requested by that same DNS server.

Since the majority of our users utilize the same DNS server, we have found that we don’t get much of a balance and one of our Web Engines sits mostly idle.  We have learned that 25 concurrent sessions is suggested max for connections to any particular Web Engine.  That does not mean 25 users but 25 open tabs/sessions (at least that was my interpretation).  With better LB methodology, this will increase to 50 concurrent connections balanced over the 2 Web Engines.

Our solution will be to create an LTM Virtual Server that listens on a vIP and proxies, via round-robin LB method, the client browsers to the Web Engines and gives a better balance as the LB would be per client (LTM method) and not per DNS server (GTM method).  The LTM method would use cookie persistence to ensure any particular session is sticky/persisted to the same Web Engine.

With either method (GTM or LTM LB), if clients new the true IP/hostname of the Web Engines, they could still pick a specific one to connect to and would (obviously) persist to the one they choose.  Of course, your corporate FW would have to allow traffic to the Web Engines and not limit to only the LTM vIP.

The NetScalar can be setup in a similar fashion to the LTM method.  A vIP on the NetScalar could balance client browsers with cookie persistence across any number of Web Engine hosts.