NetScaler appliances configured for global server load balancing (GSLB) provide for disaster recovery and ensure continuous availability of applications by protecting against points of failure in a wide area network (WAN). GSLB can balance the load across data centers by directing client requests to the closest or best performing data center, or to surviving data centers in the event of an outage.
There are three fundamental entities that must be configured for GSLB:
- Site: A GSLB site represents a NetScaler or a high availability (HA) pair of NetScaler appliances that maintain GSLB state information and provide information about how the NetScaler nodes should communicate. A site can also represent a data center.
- GSLB virtual server: A GSLB virtual server represents a group of resources to which users can be directed, and the logic used to select one resource verses another.
- GSLB service: A GSLB service represents a target resource and is bound to a GSLB virtual server. The target resource might be a load balancing virtual server on a NetScaler, or it could represent a third party server.
Sites and services are inherently linked to indicate proximity between the two. That is, all services must belong to a site, and are assumed to be in the same location as the GSLB site for proximity purposes. Likewise, services and virtual servers are linked, so that the logic is linked to the resources that are available.
- Relationships among GSLB Sites
- The concept of sites is central to NetScaler GSLB implementations. Unless otherwise specified, sites form a peer relationship among themselves. This relationship is used first to exchange health information and then to distribute load as determined by the selected algorithm. In many situations, however, a peer relationship among all GSLB sites is not desirable. Reasons for not having an all-peer implementation could be
- To clearly separate GSLB sites. For example, to separate sites that participate in resolving DNS queries from the traffic management sites.
- To reduce the volume of Metric Exchange Protocol (MEP) traffic, which increases exponentially with an increasing number of peer sites.
These goals can be achieved by using parent and child GSLB sites. Parent-child relationships can be used to build a two-level hierarchical GSLB design with the following characteristics:
- At the top level are parent sites that have peer relationships with other parents.
- Each parent can have multiple children, but each child can have only one parent.
- Each parent site exchanges health information with its children and with other parent sites.
- A child communicates only with its parent.
- In a parent-child relationship for GSLB, only the parent site responds to ADNS queries. The child sites act as normal load balancing sites.
- ADNS service or DNS load balancing virtual servers should be configured only in the parent site.
- A parent site can have a normal GSLB configuration, that is, services from local and all remote sites but a child site can have local services only.
Limitations of GSLB Parent-Child site configuration:
- You can configure upto 32 Parent sites and a total of 1024 Child sites.
- On the Child site, by default, the nwmetricExchange and sessionExchange options are disabled.
- Round Trip Time (RTT) GSLB method is not recommended for GSLB Parent-Child site configuration.
- Setting Up a Parent-Child Configuration for Global Server Load Balancing
- If you have a firewall configured at a GSLB site, make sure that port 3011 is open. Follow the procedures at the following location to create services and virtual servers: Configuring Global Server Load Balancing (GSLB)
Figure 1. GSLB Parent-Child Topology
In the above figure:
- GSLB_Site11 and GSLB_Site12 are parent sites in a peer relationship.
- site11_lb1 and site11_lb2 are the child sites of GSLB_Site11, while site12_lb1 and site_lb2 are the child sites of GSLB_Site12.
The configuration of each parent site includes the information about all the child sites associated with it, but the configuration of each child site pertains only to that child and its parent. A child site is not aware about any other parent site or other child sites in the configuration. For example, in the above figure, the configuration of child site site11_lb1 would include only information about its parent site, GSLB_Site11.
Note: GSLB auto sync syncs only the GSLB configuration across the parent sites. It does not sync any configuration to the child sites.