I have been blogging about my experiences in using the NetScaler GSLB to manage the user load between datacenters. The interesting thing about GSLB is its differing uses. While companies use GSLB to balance traffic between sites, others use the technology to redirect traffic to Disaster Rocovery (D/R) sites only in the event of a catastrophic failure or only during extended planned datacenter maintenance.
I’d like to a moment to review these two methodologies today.
Disaster Recovery Site Redirection
This popular NetScaler configuration uses the concept of a “backup site” to route the user requests to the alternate site on an exception basis. Only when the primary site/sites is/are down, is user traffic sent to the D/R site for business continuity. Naturally, for this to be effective, application and data equivalence must exist at the disaster recovery site in advance of the load shift.
Datacenter Load Balancing
The NetScaler GSLB algorithms can also be configured to distribute user requests to different datacenters on a constant basis so that many datacenters share the load. In fact, my BLOG series has refered to this type of configuration.
There are datacenter load balancing implementation choices. These are too numerous to explore in depth here, but they do include round robin, weighted round robin, sites offering least response times, least return trip time, least connections, IP proximity, and, of course, combinations of these with the ability to invoke alternate methodologies in real time.
Additional methodologies exist for inter-datacenter load balancing of Access Gateway virtual server VIPs. These include least used, as in the least number of connected users. This ensures that users are not sent to an Access Gateway that is already hosting its maximum licensed user count.
But Don’t Go There…
In both modes – datacenter load distribution and disaster recovery – the NetScaler GSLB algorithms use health checks to ensure that inoperative sites and services are not selected for GSLB distribution.
NetScaler has always made it easy to define application specific probes and response checks to ensure the eligibility of servers and their applications for intra-datacenter load balancing.
Brought outward to another level, these health checks are applied at the GSLB site level. In other words, if all instances of an application malfunction in one site, application health checks at the GSLB level will cause that site to be removed from the GSLB selection pool until at least one instance of the application returns to healthy service.
As a value-add, the NetScaler configuration wizards – for both load balancing and GSLB – generate appropriate health checks when defining load balancing and GSLB for XenApp and XenDesktop environments.
On a local datacenter basis, if a load balanced Web Interface does not respond correctly to the pre-generated health probes, its associated services will not be assigned any user traffic by the load balancing algorithms.
Taken to the GSLB level, if the GSLB based monitors determine that all instances of the application in any site are unavailable, then that site is removed from selection eligibility by the GSLB algorithms.
Back to Our Theme
But in this blog series, I will continue to focus on configuring GSLB to use IP Proximity, leaving references the other methodologies, health checks, and distribution persistence for another time.
In my next GSLB blog, in fact, I will be discussing how I adjusted the assignment of regions to specific datacenters. Stay tuned.
As always, I welcome your comments.