GSLB return real ip instead of vip

[Brian Major1709152798]

I have NetScalers in my major sites but none in my smaller remote offices. Is there a way I can have the NetScaler heartbeat a server in a remote office and have gslb return the server's real ip instead of using a vip?

 

For example, I have gslb.mydomain.com delegated to the NetScaler. In my large sites I have a vip on the NetScaler pointing to my local domain controllers. A dns lookup for ldap.gslb.mydomain.com returns the vip of the closest domain controller based on the geographic site the client is in. However, I would like the smaller sites without a NetScaler to do this as well. Can the NetScaler in my larger sites heartbeat the DC's in the smaller remote sites and return the DC's ip in response to a dns query from the smaller site? I don't want to configure a vip for the remote sites' DC's because traffic from a client should hit its local DC directly without having to flow through the NetScaler in the larger sites.

 

Can the NetScaler be configured this way?

 

[CarlStalhood]

Sure. The GSLB Service can point to any IP address. If you bind a monitor to the GSLB Service then NetScaler will use the GSLB monitor to determine service availability instead of using MEP and LB vServer monitors.

[Nelson Molwantwa]

On 24/02/2014 at 1:03 AM, Carl Stalhood1709151912 said:

Sure. The GSLB Service can point to any IP address. If you bind a monitor to the GSLB Service then NetScaler will use the GSLB monitor to determine service availability instead of using MEP and LB vServer monitors.

Thanks Carl. Just noticed this was posted 5 years ago. Have you lab tested it? Please share and/or elaborate more like you usually do. I will also think about it and lab try the behaviour. 

[Rhonda Rowland1709152125]

A GSLB service just represents the IP you want the GSLB FQDN to resolve to. Usually the service's IP matches a lb/cs/vpn VIP on the NS. But it can just as easily hand out any IP.

add gslb service gslb_svc1 <IP1> <protocol> <port>

 

As Carl, said though, if the GSLB Service's IP isn't an entity on this NetScaler like a lb vserver, then it has no direct way of knowing if the destination IP should be used or not. So, you would need to create a monitor and bind to the gslb svc (like regular load balancing services), so there is an up/down state indicator. Now the GSLB vserver can select between the up gslb services.

 

Example 1: (gslb with regular lb vservers)

add lb vserver lb_vsrv_demo1 http <vip1> 80

add lb vserver lb_vsrv_demo2 http <vip2> 80

 

# gslb services with the same VIP as the vservers....

add gslb service gslb_svc_demo1 <vip1> http 80 -siteName gslb_site1

add gslb service gslb_svc_demo2 <vip2> http 80 -siteName gslb_site2

###[notes]

In this case, the gslb services don't have monitors. But the NS recognizes that the IP of the service <VIP1>:80 matches a local lb vserver it knows about lb_vsrV_demo1, so it determines the gslb service up/down state based on its own vserver. (And the partner site updates it about the status of lb_vsrv_demo2 to control the up/down state of gslb_svc_demo2).

 

The gslb service is just the potential ip the gslb vserver can use to resolve the FQDN of the gslb vserver too.

GSLB services have the unique distinction of being to represent an entity on this NS or a remote entity (like an external destination.

 

Example 2:  gslb with an IP address (not corresponding to a local vserver)

add gslb service gslb_svc_demo1 <IP3> http 80 siteName gslb_site1

bind gslb service gslb_svc_demo1 -monitorName mon_demo1

#  In this case the gslb_svc is pointing directly to the IP you plan to resolve. Technically, a server object is created just like in regular load balancing.

# in order for this NS to determine the up/down state, you need a monitor. Remember: monitors override mep.

# Monitor can be almost any of the monitor types you use in regular load balancing, just make sure monitor type and gslb service protocol are consistent. If SSL, don't forget the "secure" flag in the monitor.

# for the remote site's service, decide if it will update partner NetScaler via MEP (or if it will be directly monitored)

add gslb service gslb_svc_demo2 <IP4> http 80 siteName gslb_site2

bind gslb service gslb_svc_demo2 -monitorName mon_demo2

 

 

[Nelson Molwantwa]

Awesome. Thanks Rhonda for breaking it down.

 

When you bind a remote service to a GSLB virtual server, the GSLB sites exchange metric information, including network metric Information, which is the round-trip-time and persistence Information.

If a metric exchange connection is momentarily lost between any of the participating sites, the remote 

---

---

---

By default, when you bind a monitor to a remote GSLB service, the NetScaler appliance uses the state of the service reported by the monitor. However, you can configure the NetScaler appliance to use monitors to evaluate services in the following situations:

Always use monitors (default setting).

Use monitors when MEP is DOWN.

Use monitors when remote services and MEP are DOWN.

 

And that should scale and load balance the 'IPs' just fine? There'd be tradeoffs or pros/cons I guess depending on what my customer may want to do.

We're still not sure how they'd want to persist and/or loadbalance across these 'IP's.

But this' quite interesting, so thanks