Product Documentation
ADC
14.1 - Current Release 13.1 13.0 12.1
View PDF

Parent-child topology deployment using the MEP protocol

August 1, 2023
Contributed by: 
S

NetScaler GSLB provides global server load balancing and disaster recovery by creating mesh connections between all the involved sites and making intelligent load balancing decisions. Each site communicates with the others to exchange server and network metrics through the Metric Exchange Protocol (MEP), at regular intervals. However, with the increase in the number of peer sites, the volume of MEP traffic increases exponentially because of the mesh topology. To overcome this, you can use a parent-child topology. The parent-child topology also supports larger deployments. In addition to the 32 parent sites, you can configure 1024 child sites.

The GSLB parent-child topology is a two-level hierarchical design with the following characteristics:

  • At the top level are parent sites, which have peer relationships with other parents.
  • Each parent can have multiple child sites.
  • Each parent site exchanges health information with its child sites and with other parent sites.
  • A child site communicates only with its parent site.
  • In a parent-child relationship for GSLB, only the parent site responds to ADNS queries. The child sites act as normal load balancing sites.
  • Configure an ADNS service or DNS load balancing virtual server 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. Also, only the parent sites have GSLB virtual servers configured.

Note

  • In a parent-child topology, the exchange of site metrics is initiated from the lower of two IP addresses. However, from NetScaler release 11.1 build 51.x, the parent sites initiate connections to the child sites, and not the opposite way. Because the parent sites have information about all the child sites in the GSLB setup.

  • In a parent-parent connection, the exchange of site metrics is still initiated from the lower IP of two IP addresses.

  • In a parent-child topology, GSLB services are not always required to be configured on a child site. However, if you have more 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 differentNetScaler software versions. However, to use the GSLB automaticConfigSync option to synchronize the configuration across the parent sites, all parent sites must be on the sameNetScaler software versions. If you are not using the automaticConfigSync option, then the parent site and the child site can be on differentNetScaler 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.

Basic parent-child topology

In the diagram, SiteP1 and SiteP2 are parent sites in a peer relationship. Site P1C1 and P2C1 are the child sites of P1 and P2 respectively.

Parent-child-topology-diagram

Setting up a parent-child configuration for GSLB

If you have a firewall configured at a GSLB site, make sure that port 3011 is open.

The following diagram displays a sample parent-child configuration.

Parent-child configuration

  • The configuration of a child site includes the child site and its parent site, but no other parent or child sites.
  • Network metrics, such as RTT and persistence session information, are synchronized only across the parent sites. Therefore, parameters such as nwMetricExchange and sessionExchange are disabled by default on all the child sites.
  • To verify the correct parent-child configuration, check the states of all the GSLB services bound to the parent sites.

To set up a parent-child configuration for GSLB by using the CLI:

  1. On each parent site, configure all its child sites, its peer parent sites, and the child sites associated with the peer sites:

    Use the following command while adding a parent site:

    add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>]
<!--NeedCopy-->

    Use the following command while adding a child site:

    add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>] [-parentSite <string>]
<!--NeedCopy-->

  2. On the child sites, configure the child site and also associate the child site with its parent:

    Note:

    Configure the parent site and child site association correctly. For example, you must configure Site1_child1 with GSLB_Site1. You cannot configure Site1_child1 with GSLB_Site2.

    Use the following command to configure the parent site with which the child site is associated:

    add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>]
<!--NeedCopy-->

    Use the following command to add a child site and associate it with its parent site:

    add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>] [-parentSite <string>]
<!--NeedCopy-->

For a complete example of a parent-child configuration, using the command line interface, see Example of a Complete Parent-Child Configuration, Using the CLI.

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.

Backing up a parent site

Note: This feature was introduced in NetScaler release 11.1 build 51.x. To use the backup parent site topology, make sure that the parent site and the child sites are on NetScaler 11.1 build 51.x and later.

The backup parent site topology is useful in scenarios wherein many child sites are associated with a parent site. If this parent site goes DOWN, all of its child sites become unavailable. To prevent this, you can now configure a backup parent site to which the child sites can connect if the original parent site is DOWN. The parent site sends the backup parent list to the child sites through the MEP messages.

When a parent site is DOWN, the other parent sites in the GSLB get to know that a particular parent site is DOWN through MEP because MEP to that parent site is DOWN. The other parent sites in the GSLB setup look up the backup chain of the peer parent. The parent site with the highest preference adopts the child sites of the parent that went DOWN. The new parent then initiates a connection with the child site. A child site can accept or reject the connection after evaluating its existing connections and the information in the backup list. It takes a few seconds for the backup parent to adopt the child sites. When the original parent site is back UP, it tries to establish connections with its child sites that have migrated to a different parent. When a connection attempt is successful, the child site is reassigned to its original parent site.

Note:

  • Only parent sites can be configured as backups, and this configuration can only be done at the parent site.
  • All child sites use the backup parent set.
  • Synchronization is done only on the parent sites. GSLB child sites’ configuration is not affected by synchronization. This is because the parent site and the child site configurations are not identical. The child sites configuration consists only of its own and its parent site’s details. Also, GSLB services are not always required to be configured in the child sites.

Consider the configuration shown in the following figure, in which:

  • SiteP1, SiteP2, and SiteP3 are the parent sites.
  • Child_site1, Child_site2, and Child_site3 are the child sites of SiteP1, SiteP2, and SiteP3 respectively.
  • Backup parent sites;
    • SiteP1 backup parents - SiteP2 (higher preference) and SiteP3
    • SiteP2 backup parents – SiteP3 (higher preference) and SiteP1
    • SiteP3 backup parents – SiteP1 (higher preference) and SiteP2

Note: For illustration purposes, the figure shows only one backup parent for each parent site.

Parent-child topology diagram

The following list summarizes the behavior of the parent and child sites under various scenarios:

  • Scenario 1: SiteP1 goes DOWN.
    • SiteP2 and SiteP3 detect that SiteP1’s MEP connection is DOWN. SiteP2 is higher in the preference list of backup parents for SiteP1, so it tries to initiate a connection to Child_site1. SiteP3 assumes that Child_site1 is now the child site of parent SiteP2.
    • SiteP2 sends Child_Site1 the list of SiteP1’s backup parents (SiteP2 and SiteP3) to Child_site1. Child_site1 uses the list to decide whether to accept or reject the connection from SiteP2. It accepts the connection and becomes a child of SiteP2.
    • When SiteP1 is back UP, it sends Child_site1 a connection request. The new request takes precedence and Child_site 1 migrates to SiteP1.

  • Scenario 2: Only the MEP connection between SiteP1 and SiteP2 has gone DOWN. Child_site1 rejects SiteP2’s connection request, because its parent, SiteP1, is still UP.

  • Scenario 3: SiteP3 and Child_Site1 detect that SiteP1 is DOWN, and the MEP connection between SiteP3 and SiteP2 is also DOWN. However, SiteP2 detects that SiteP1 is UP, and the MEP connection between SiteP1 and SiteP2 is UP.
    • SiteP2 does not take any action.
    • SiteP3 checks SiteP1’s backup list and finds that SiteP2 has a higher preference than SiteP3. But SiteP2 is DOWN, so SiteP3 tries to establish a connection with Child_site1. Child_site1 has detected that SiteP1 is DOWN, so it accepts SiteP3’s connection request.
    • Now the connection between SiteP1 and SiteP2 goes DOWN. SiteP2 checks SiteP1’s backup list and finds itself as the most preferred backup, so it tries to connect to Child_site1. Child_site1 evaluates the new connection request based on SiteP1’s list and finds SiteP2 as the most preferred backup, so it migrates to SiteP2 from SiteP3.

To configure a backup parent site by using the command line interface

At the command prompt type:

set gslb site <sitename> -backupParentlist <bkp_site1> <bkp_site2> …<bkp_site5>
<!--NeedCopy-->

<sitename> is the current parent site.

Example:

For the parent site (SiteP1), the sites (SiteP2 and SiteP3) are configured as the backup parent sites.

set gslb site SiteP1 -backupParentlist SiteP2 SiteP3
<!--NeedCopy-->

Note:

  • You cannot add a new site as a backup parent. You must first add all the sites, and then configure the site as a backup parent.
  • To remove a backup parent, you must use the unset command, which unsets all the sites that were previously configured as backup parent sites.

To configure a backup parent site by using the GUI

  1. Navigate to Configuration > Traffic Management > GSLB > Sites.
  2. Add a new site or select an existing site.
  3. Choose the Backup Parent Sites option box while creating or configuring the GSLB site.
Parent-child topology deployment using the MEP protocol
August 1, 2023
Contributed by: 
S
August 1, 2023
Contributed by: 
S

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.