Product Documentation

Configuring Parent-Child Topology

Feb 13, 2017

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
  1. To clearly separate GSLB sites. For example, to separate sites that participate in resolving DNS queries from the traffic management sites.
  2. 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. 

Note

  • 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.
  • In a parent-child topology, GSLB services are not always required to be configured on a child site. However, if you have additional configuration such as client authentication, client IP address insertion, or other SSL-specific requirement, you must add an explicit GSLB service on the child site and configure it accordingly.
  • In a parent-child topology, the parent site and the child site can be on different NetScaler software versions. However, to use the GSLB automaticConfigSync option to synchronize the configuration across the parent sites, all parent sites must be on the same NetScaler software versions. If you are not using the automaticConfigSync option, then the parent site and the child site can be on different NetScaler software versions but make sure that you are not using any of the new features in the latest release. This is also applicable, in general, to two NetScaler nodes participating in GSLB.

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 BalancingIf 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.

To set up a parent-child configuration for GSLB by using the NetScaler command line

  1. On each parent site, enter the following command: add gslb site<siteName><siteIPAddress> [-publicIP<ip_addr|ipv6_addr|*>] [-parentSite<string>] For example: # add gslb site gslb_site11 1.1.1.1 -publicIP 1.1.1.1

    # add gslb site site11_lb1 1.1.1.2 -publicIP 1.1.1.2 -parentSite gslb_site11

    # add gslb site site11_lb2 1.1.1.3 -publicIP 1.1.1.3 -parentSite gslb_site11

    # add gslb site gslb_site12 3.3.3.1 -publicIP 3.3.3.1

    # add gslb site site12_lb1 3.3.3.2 -publicIP 3.3.3.2 -parentSite gslb_site12

    # add gslb site site12_lb2 3.3.3.3 -publicIP 3.3.3.3 -parentSite gslb_site12

    The above command makes the parent site aware of its child sites as well as of the other parent site in the configuration.

  2. On each child site, enter the following command: add gslb site<siteName><siteIPAddress> [-publicIP<ip_addr|ipv6_addr|*>] [-parentSite<string>] For example: # add gslb site gslb_site11 1.1.1.1 -publicIP 1.1.1.1

    # add gslb site site11_lb1 1 1.1.1.2 -publicIP 1.1.1.2 -parentSite gslb_site11

    The above command creates the child site and adds the parent-site information to child site’s configuration.

    In the child sites, only the child site and its respective parent site needs to configured and not other parent or child sites.    

    Network metrics, such as RTT and persistence session information, are synced only across the parent sites. Therefore, parameters like nwMetric and sessionExchange are disabled by default on all the child sites.

To verify correct parent-child configuration, check the states of all the GSLB services bound to the parent sites.

Note

If the load balancing virtual server IP address is a private IP address and the public IP address is different from this IP address, you need to configure a GSLB service for the local load balancing virtual server on the child site. This is required for statistics collection between the parent and the child site.

On the child site, at the command prompt, type:

add gslb service <name> <private IP/lb vserver IP> http 80 –sitename <childsite name> -publicip <public IP of LB vserver>

Example:

add gslb service Service-GSLB 192.168.1.3 http 80 -GSLB_Site11 site 11_lb1 172.16.1.1

Where 192.168.1.3 is a private IP address of the load balancing virtual server and 172.16.1.1 is a public IP address of the load balancing virtual server.