To configure a
GSLB service, you can use the IP address of the server or a canonical name of
the server. If you want to run multiple services (like an FTP and a Web server,
each running on different ports) from a single IP address or run multiple HTTP
services on the same port, with different names, on the same physical host, you
can use canonical names (CNAMES) for the services.
For example, you
can have two entries in DNS as ftp.example.com and www.example.com for FTP
services and HTTP services on the same domain, example.com. CNAME-based GSLB
services are useful in a multilevel domain resolver configuration or in
multilevel domain load balancing. Configuring a CNAME-based GSLB service can
also help if the IP address of the physical server is likely to change.
If you configure
CNAME-based GSLB services for a GSLB domain, when a query is sent for the GSLB
domain, the NetScaler appliance provides a CNAME instead of an IP address. If
the A record for this CNAME record is not configured, the client must query the
CNAME domain for the IP address. If the A record for this CNAME record is
configured, the NetScaler provides the CNAME with the corresponding A record
(IP address). The NetScaler appliance handles the final resolution of the DNS
query, as determined by the GSLB method. The CNAME records can be maintained on
a different NetScaler appliance or on a third-party system.
IP-address-based GSLB service, the state of a service is determined by the
state of the server that it represents. However, a CNAME-based GSLB service has
its state set to UP by default; the virtual server IP (VIP) address or metric
exchange protocol (MEP) are not used for determining its state. If a
desktop-based monitor is bound to a CNAME-based GSLB service, the state of the
service is determined according to the result of the monitor probes.
You can bind a
CNAME-based GSLB service only to a GSLB virtual server that has the
as CNAME. Also, a NetScaler appliance can contain at most
one GSLB service with a given CNAME entry.
The following are
some of the features supported for a CNAME-based GSLB service:
- GSLB-policy based site
affinity is supported, with the CNAME as the preferred location.
- Source IP persistence is
supported. The persistency entry contains the CNAME information instead of the
IP address and port of the selected service.
The following are
the limitations of CNAME-based GSLB services:
- Site persistence is not
supported, because the service referenced by a CNAME can be present at any
response is not supported because one domain cannot have multiple CNAME
- Source IP Hash and Round
Robin are the only load balancing methods supported. The Static Proximity
method is not supported because a CNAME is not associated with an IP address
and static proximity can be maintained only according to the IP addresses.
Empty-Down-Response feature should be enabled on the
GSLB virtual server to which you bind the CNAME-based GSLB service. If you
Empty-Down-Response feature, when a GSLB virtual
server is DOWN or disabled, the response to a DNS query, for the domains bound
to this virtual server, contains an empty record without any IP addresses,
instead of an error code.