This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.
Parent-Child Topology Deployment using the MEP Protocol
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 Metric Exchange Protocol (MEP), at regular intervals. However, with the increase in 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.
- An 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. Also, only the parent sites have GSLB virtual servers configured.
- 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 vice versa, 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 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.
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.
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.
- 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 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 NetScaler command line
1. On each parent site, enter the following commands:
add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>] add gslb site<siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>] [-parentSite <string>] <!--NeedCopy-->
add gslb site GSLB_Site1 10.1.1.1 - publicIP 10.1.1.1 add gslb site Site1_child1 1 10.1.1.2 -publicIP 10.1.1.2 -parentSite GSLB_Site1 <!--NeedCopy-->
2. On each child site, enter the following commands:
add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>] add gslb site <siteName> <siteIPAddress> [-publicIP <ip_addr|ipv6_addr|*>] [-parentSite <string>] <!--NeedCopy-->
add gslb site* GSLB_Site1 10.1.1.1 - publicIP 10.1.1.1 add gslb site Site1_child1 1 10.1.1.2 -publicIP 10.1.1.2 -parentSite GSLB_Site1 <!--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 NetScaler CLI.
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>
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.
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 a large number of 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. 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.
- 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.
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-->
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-->
- 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 NetScaler GUI
- Navigate to Configuration > Traffic Management > GSLB > Sites.
- Add a new site or select an existing site.
- Choose the Backup Parent Sites option box while creating or configuring the GSLB site.
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.