Cascaded Hierarchical GSLB Configurations

Global Server Load Balancing (GSLB) offers a lot of cool load balancing mechanisms out of the box. Active/Active, Active/Passive, Geo-IP based, etc. But what if you want to combine multiple of those in a cascaded/hierarchical load balancing decision?

Quick note, in case you ended up here for that particular topic. This has nothing to do with the GSLB Parent-Child Topology introduced in NetScaler 11, that’s a different story.

 

1. Background
2. Solution
3. Configuration
4. Result

Background

In a GSLB scenario you often end up having data centers scattered all over the globe. If you want to utilize them Active-Active with Static Proximity (GeoIP based) you could just apply the Static Proximity across all your nodes and that’s it, isn’t it?

In a real world GSLB scenario you typically end up having users gathered around one datacenter and therefore the load is spread uneven.

Let’s take a company that has data centers and users in Europe and North America for example. Let’s say there are two data centers on each continent. However, users are gathered only around one of each data centers in each continent.

Now that’s a problem if you want to have equal loads. But how can we solve that?

Solution

To distribute the load evenly you’d need a load balancing decision based on multiple factors. First factor would be the Static Proximity (GeoIP). Second factor would be Active-Active or Least Connection.

But NetScaler does not offer this cascaded/hierarchical  setup out of the box. You can’t have GSLB vServers pointing to other GSLB vServers to create the setup shown above.

Fortunately in NetScaler 11 GSLB Content Switching was introduced.

This enables us is to create two GSLB vServers, one for each continent. On top of that we can then setup a Content Switch and configure our own GeoIP based logic using NetScalers Advanced Policy Expressions.

This enables a GeoIP based decision tree as follows:

• If User comes from Europe and Europe is UP => Europe DCs
• If User comes anywhere and North America is DOWN => Europe DCs
• If User comes from elsewhere => North America DCs

Configuration

To configure this we first need two regular GSLB vServers, one for each region. Those could be of any type depending on your desire. In my case I’ve used a simple round robin lab setup without further health checks for demonstration purposes.

The important difference to a regular GSLB vServer setup is that we don’t bind a URL yet. That gets bound to the Content Switch later, similar to how a VIP only gets bound to the Content Switch and not the Load Balancing vServers in a traditional Content Switching setup.

Setup a basic GSLB vServer with two Services for Country-A

add gslb service gslb-hierarchy.gslb.svc.county-a.dc-a 10.100.100.10 HTTP 80 -healthMonitor NO -siteName sys.gslb.site.ns01
add gslb service gslb-hierarchy.gslb.svc.county-a.dc-b 10.100.100.20 HTTP 80 -healthMonitor NO -siteName sys.gslb.site.ns01
add gslb vserver gslb-hierarchy.gslb.vs.country-a HTTP -backupLBMethod ROUNDROBIN -tolerance 0
bind gslb vserver gslb-hierarchy.gslb.vs.country-a -serviceName gslb-hierarchy.gslb.svc.county-a.dc-a
bind gslb vserver gslb-hierarchy.gslb.vs.country-a -serviceName gslb-hierarchy.gslb.svc.county-a.dc-b

Setup a basic GSLB vServer with two Services for Country-B

add gslb service gslb-hierarchy.gslb.svc.county-b.dc-a 10.100.200.10 HTTP 80 -healthMonitor NO -siteName sys.gslb.site.ns01
add gslb service gslb-hierarchy.gslb.svc.county-b.dc-b 10.100.200.20 HTTP 80 -healthMonitor NO -siteName sys.gslb.site.ns01
add gslb vserver gslb-hierarchy.gslb.vs.country-b HTTP -backupLBMethod ROUNDROBIN -tolerance 0
bind gslb vserver gslb-hierarchy.gslb.vs.country-b -serviceName gslb-hierarchy.gslb.svc.county-b.dc-a
bind gslb vserver gslb-hierarchy.gslb.vs.country-b -serviceName gslb-hierarchy.gslb.svc.county-b.dc-b

Now that we have those in place we can go ahead and create the actual Content Switching logic.

First we’d need two Content Switching Actions pointing to the previously created GSLB vServers

add cs action gslb-hierarchy.gslb.cs.act.country-a -targetVserver gslb-hierarchy.gslb.vs.country-a
add cs action gslb-hierarchy.gslb.cs.act.country-b -targetVserver gslb-hierarchy.gslb.vs.country-b

Second we’ll create two Content Switching Policies assigning a region to a client. This is where all the magic happens.

The first policy basically applies “If Europe is UP” AND “Client is from Europe” OR “North America is DOWN”. The second policy just applies to all traffic that didn’t hit the first policy.

add cs policy gslb-hierarchy.gslb.cs.pol.country-a -rule "( CLIENT.IP.SRC.MATCHES_LOCATION("Europe.*") && SYS.VSERVER("gslb-hierarchy.gslb.vs.country-a").STATE.EQ(UP) ) || SYS.VSERVER("gslb-hierarchy.gslb.vs.country-b").STATE.EQ(UP).NOT" -action gslb-hierarchy.gslb.cs.act.country-a
add cs policy gslb-hierarchy.gslb.cs.pol.country-b -rule true -action gslb-hierarchy.gslb.cs.act.country-b

Once the policies are in place we can create a Content Switching vServer of type GSLB and bind the CS Policies.

add cs vserver gslb-hierarchy.gslb.cs.vs.global HTTP -targetType GSLB -cltTimeout 180
bind cs vserver gslb-hierarchy.gslb.cs.vs.global -policyName gslb-hierarchy.gslb.cs.pol.country-a -priority 100
bind cs vserver gslb-hierarchy.gslb.cs.vs.global -policyName gslb-hierarchy.gslb.cs.pol.country-b -priority 110

Finally we’ll bind the designated GSLB DNS Record to the GSLB Content Switch.

bind cs vserver gslb-hierarchy.gslb.cs.vs.global -domainName gslb-hierarchy.gslb.nerdscaler.lab -TTL 5

And thats it!

Result

This will result in the following. European clients get load balanced between the two services in Country-A.

North American and other clients get load balanced between the two services in Country-B.

 

Enjoy!