-
Getting Started with NetScaler
-
Deploy a NetScaler VPX instance
-
Optimize NetScaler VPX performance on VMware ESX, Linux KVM, and Citrix Hypervisors
-
Apply NetScaler VPX configurations at the first boot of the NetScaler appliance in cloud
-
Configure simultaneous multithreading for NetScaler VPX on public clouds
-
Install a NetScaler VPX instance on Microsoft Hyper-V servers
-
Install a NetScaler VPX instance on Linux-KVM platform
-
Prerequisites for installing NetScaler VPX virtual appliances on Linux-KVM platform
-
Provisioning the NetScaler virtual appliance by using OpenStack
-
Provisioning the NetScaler virtual appliance by using the Virtual Machine Manager
-
Configuring NetScaler virtual appliances to use SR-IOV network interface
-
Configure a NetScaler VPX on KVM hypervisor to use Intel QAT for SSL acceleration in SR-IOV mode
-
Configuring NetScaler virtual appliances to use PCI Passthrough network interface
-
Provisioning the NetScaler virtual appliance by using the virsh Program
-
Provisioning the NetScaler virtual appliance with SR-IOV on OpenStack
-
Configuring a NetScaler VPX instance on KVM to use OVS DPDK-Based host interfaces
-
-
Deploy a NetScaler VPX instance on AWS
-
Deploy a VPX high-availability pair with elastic IP addresses across different AWS zones
-
Deploy a VPX high-availability pair with private IP addresses across different AWS zones
-
Protect AWS API Gateway using the NetScaler Web Application Firewall
-
Configure a NetScaler VPX instance to use SR-IOV network interface
-
Configure a NetScaler VPX instance to use Enhanced Networking with AWS ENA
-
Deploy a NetScaler VPX instance on Microsoft Azure
-
Network architecture for NetScaler VPX instances on Microsoft Azure
-
Configure multiple IP addresses for a NetScaler VPX standalone instance
-
Configure a high-availability setup with multiple IP addresses and NICs
-
Configure a high-availability setup with multiple IP addresses and NICs by using PowerShell commands
-
Deploy a NetScaler high-availability pair on Azure with ALB in the floating IP-disabled mode
-
Configure a NetScaler VPX instance to use Azure accelerated networking
-
Configure HA-INC nodes by using the NetScaler high availability template with Azure ILB
-
Configure a high-availability setup with Azure external and internal load balancers simultaneously
-
Configure a NetScaler VPX standalone instance on Azure VMware solution
-
Configure a NetScaler VPX high availability setup on Azure VMware solution
-
Configure address pools (IIP) for a NetScaler Gateway appliance
-
Deploy a NetScaler VPX instance on Google Cloud Platform
-
Deploy a VPX high-availability pair on Google Cloud Platform
-
Deploy a VPX high-availability pair with external static IP address on Google Cloud Platform
-
Deploy a single NIC VPX high-availability pair with private IP address on Google Cloud Platform
-
Deploy a VPX high-availability pair with private IP addresses on Google Cloud Platform
-
Install a NetScaler VPX instance on Google Cloud VMware Engine
-
-
Solutions for Telecom Service Providers
-
Load Balance Control-Plane Traffic that is based on Diameter, SIP, and SMPP Protocols
-
Provide Subscriber Load Distribution Using GSLB Across Core-Networks of a Telecom Service Provider
-
Authentication, authorization, and auditing application traffic
-
Basic components of authentication, authorization, and auditing configuration
-
Web Application Firewall protection for VPN virtual servers and authentication virtual servers
-
On-premises NetScaler Gateway as an identity provider to Citrix Cloud
-
Authentication, authorization, and auditing configuration for commonly used protocols
-
Troubleshoot authentication and authorization related issues
-
-
-
-
-
-
Configure DNS resource records
-
Configure NetScaler as a non-validating security aware stub-resolver
-
Jumbo frames support for DNS to handle responses of large sizes
-
Caching of EDNS0 client subnet data when the NetScaler appliance is in proxy mode
-
Use case - configure the automatic DNSSEC key management feature
-
Use Case - configure the automatic DNSSEC key management on GSLB deployment
-
-
-
Persistence and persistent connections
-
Advanced load balancing settings
-
Gradually stepping up the load on a new service with virtual server–level slow start
-
Protect applications on protected servers against traffic surges
-
Retrieve location details from user IP address using geolocation database
-
Use source IP address of the client when connecting to the server
-
Use client source IP address for backend communication in a v4-v6 load balancing configuration
-
Set a limit on number of requests per connection to the server
-
Configure automatic state transition based on percentage health of bound services
-
-
Use case 2: Configure rule based persistence based on a name-value pair in a TCP byte stream
-
Use case 3: Configure load balancing in direct server return mode
-
Use case 6: Configure load balancing in DSR mode for IPv6 networks by using the TOS field
-
Use case 7: Configure load balancing in DSR mode by using IP Over IP
-
Use case 10: Load balancing of intrusion detection system servers
-
Use case 11: Isolating network traffic using listen policies
-
Use case 12: Configure Citrix Virtual Desktops for load balancing
-
Use case 13: Configure Citrix Virtual Apps and Desktops for load balancing
-
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
-
Use case 15: Configure layer 4 load balancing on the NetScaler appliance
-
-
-
-
-
Authentication and authorization for System Users
-
-
-
Configuring a CloudBridge Connector Tunnel between two Datacenters
-
Configuring CloudBridge Connector between Datacenter and AWS Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Datacenter and Azure Cloud
-
Configuring CloudBridge Connector Tunnel between Datacenter and SoftLayer Enterprise Cloud
-
Configuring a CloudBridge Connector Tunnel Between a NetScaler Appliance and Cisco IOS Device
-
CloudBridge Connector Tunnel Diagnostics and Troubleshooting
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)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
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.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Configure a GSLB service group
Service group enables you to manage a group of services as easily as a single service. If you enable or disable any option for a service group, the option gets enabled or disabled for all the members of the service group. For example, you can apply this feature to options such as Compression, Health monitoring, and Graceful shutdown.
After creating a service group, you can do any of the following:
- Bind the service group to a virtual server.
- Add services to the service group.
- Bind monitors to the service groups.
Important
If the load balancing virtual server is either in a GSLB node itself or is in a child node (in parent-child deployment) and no monitors are bound to the GSLB service, then make sure the following:
The GLSB service group IP address, port number, and protocol match the virtual server that the service is representing. Else, the service state is marked as DOWN.
The NetScaler supports the following types of GSLB service groups.
- IP address based service groups
- Domain name based service groups
- Domain name based autoscale service groups
GSLB domain name based autoscale service groups
The NetScaler hybrid and multi-cloud global server load balancing (GSLB) solution enables customers to distribute application traffic across multiple data centers in hybrid clouds, multiple clouds, and on-premises. The NetScaler GSLB solution supports various load balancing solutions, such as the NetScaler load balancer, Elastic Load Balancing (ELB) for AWS, and other third-party load balancers. Also, the GSLB solution performs global load balancing even if the GSLB and load balancing layers are independently managed.
In cloud deployments, users are given a domain name as a reference when accessing the load balancing solution for management purposes. It is recommended that external entities do not use the IP addresses that these domain names resolve to. Also, the load balancing layers scale up or down based on the load, and the IP addresses are not guaranteed to be static. Therefore, it is recommended to use the domain name to refer to the load balancing endpoints instead of IP addresses. This requires the GSLB services to be referred using the domain name instead of IP addresses and it must consume all the IP addresses returned for the load balancing layer domain name and have a representation for the same in GSLB.
To use domain names instead of IP addresses when referring to the load balancing endpoints, you can use the domain name based service groups for GSLB.
Monitor GSLB domain name based service groups
The NetScaler appliance has two built-in monitors that monitor TCP-based applications; tcp-default
and ping-default
. The tcp-default
monitor is bound to all TCP services and the ping-default
monitor is bound to all non-TCP services. The built-in monitors are bound by default to the GSLB service groups. However, it is recommended to bind an application specific monitor to the GSLB service groups.
Recommendation for setting the trigger monitors option to MEPDOWN
The Trigger Monitors option can be used to indicate if the GSLB site must use the monitors always, or use monitors when metrics exchange protocol (MEP) is DOWN.
The Trigger Monitors option is set to ALWAYS by default.
When the Trigger Monitors option is set to ALWAYS, each GSLB node triggers the monitors independently. If each GSLB node triggers the monitors independently, then each GSLB node might operate on different set of GSLB services. This might result in discrepancies in the DNS responses for the DNS requests landing on these GSLB nodes. Also, if each GSLB node is monitoring independently, then the number of monitor probes reaching the load balancer entity increases. The persistence entries also become incompatible across the GSLB nodes.
Therefore, it is recommended that the Trigger Monitors option on the GSLB site entity is set to MEPDOWN. When the Trigger Monitors option is set to MEPDOWN, the load balancing domain resolution and monitoring ownership lies with the local GSLB node. When the Trigger Monitors option is set to MEPDOWN, the load balancing domain resolution and subsequent monitoring is done by the local GSLB node of a GSLB service group. The results are then propagated to all other nodes participating in GSLB by using the metrics exchange protocol (MEP).
Also, whenever the set of IP addresses associated with a load balancing domain are updated, it is notified through MEP.
Limitations of GSLB service groups
- For a load balancing domain, the IP address that is returned in the DNS response is generally the public IP address. The private IP address cannot be applied dynamically when the load balancing domain is resolved. Therefore, public IP port and private IP port for the GSLB domain name based autoscale service groups IP port bindings are the same. These parameters cannot be set explicitly for the domain name based autoscale service groups.
- Site persistence, DNS views, and clustering are not supported for GSLB service groups.
Configure and manage GSLB service groups by using the CLI
To add a GSLB service group:
add gslb serviceGroup <serviceGroupName>@ <serviceType> [-autoScale ( DISABLED | DNS )] -siteName <string>
<!--NeedCopy-->
Example:
add gslb serviceGroup Service-Group-1 http -autoScale DNS -siteName Site1
<!--NeedCopy-->
To bind a GSLB service group to a virtual server:
bind gslb serviceGroup <serviceGroupName> ((<IP>@ <port>) | <serverName>@ | (-monitorName <string>@))
<!--NeedCopy-->
Example:
bind gslb serviceGroup Service-Group-1 203.0.113.2
bind gslb serviceGroup Service-Group-1 S1 80
bind gslb serviceGroup** Service-Group-1 -monitorName Mon1
<!--NeedCopy-->
To unbind a GSLB service group to a virtual server:
unbind gslb serviceGroup <serviceGroupName> ((<IP>@ <port>) | <serverName>@ | -monitorName <string>@)
<!--NeedCopy-->
Example:
unbind gslb serviceGroup Service-Group-1 -monitorName Mon1
<!--NeedCopy-->
To set parameters for a GSLB service group:
set gslb serviceGroup <serviceGroupName>@ [(<serverName>@ <port> [-weight <positive_integer>] [-hashId <positive_integer>] [-publicIP <ip_addr|ipv6_addr|*>] [-publicPort <port>]) | -maxClient <positive_integer> | -cip ( ENABLED | DISABLED ) | <cipHeader> | -cltTimeout <secs> | -svrTimeout <secs> | -maxBandwidth <positive_integer> | -monThreshold <positive_integer> | -downStateFlush ( ENABLED | DISABLED )] [-monitorName <string> -weight <positive_integer>] [-healthMonitor ( YES | NO )] [-comment <string>] [-appflowLog ( ENABLED | DISABLED )]
<!--NeedCopy-->
To unset parameters from a GSLB service group:
unset gslb serviceGroup <serviceGroupName>@ [<serverName>@ <port> [-weight] [-hashId] [-publicIP] [-publicPort]] [-maxClient] [-cip] [-cltTimeout] [-svrTimeout] [-maxBandwidth] [-monThreshold] [-appflowLog] [-monitorName] [-weight] [-healthMonitor] [-cipHeader] [-downStateFlush] [-comment]
<!--NeedCopy-->
To enable a GSLB service group
enable gslb serviceGroup <serviceGroupName>@ [<serverName>@ <port>]
<!--NeedCopy-->
Example:
enable gslb serviceGroup SG1 S1 80
<!--NeedCopy-->
To disable a GSLB service group
disable gslb serviceGroup <serviceGroupName>@ [<serverName>@ <port>] [-delay <secs>] [-graceFul ( YES /| NO )]
<!--NeedCopy-->
Example:
disable gslb serviceGroup SRG2 S1 80
<!--NeedCopy-->
Note
The service group that has to be disabled must be a DBS service group and not an autoscale service group.
To remove a GSLB service group:
rm gslb serviceGroup <serviceGroupName>
<!--NeedCopy-->
Example:
rm gslb serviceGroup Service-Group-1
<!--NeedCopy-->
To view the statistics of a GSLB service group:
stat gslb serviceGroup [<serviceGroupName>]
<!--NeedCopy-->
Example:
stat gslb serviceGroup Service-Group-1
<!--NeedCopy-->
To view the properties of a GSLB service group:
show gslb serviceGroup [<serviceGroupName> -includeMembers]
<!--NeedCopy-->
Example:
show gslb serviceGroup SG1
show gslb serviceGroup -includeMembers
<!--NeedCopy-->
Enable or disable GSLB service group members
You can selectively enable or disable an individual member of a GSLB (DNS-based) service group instead of enabling or disabling the entire service group. This feature is available in both autoscale service groups and non-autoscale service groups. Therefore, managing a GSLB service group is made easier.
For example, you have a requirement to avoid traffic to a particular server on a GSLB site. Let’s say, 10 GSLB services or servers (S1 to S10) are bound to a service group (SG1). You want to disable only service 5 (S5), that is avoid traffic to server 5. Without this feature, you have to separately bind services S1 to S4 and services S6 to S10. This process becomes tedious in a large GSLB service group where you have to disable or enable large number of services. With this feature, you can directly disable service 5 (S5) without impacting other services in the service group.
To enable a GSLB service group member by using CLI:
enable gslb serviceGroup <serviceGroupName>@ [<serverName>@ <port>]
<!--NeedCopy-->
Note:
To enable a GSLB service group, provide only the service group name. To enable a member of a service group, in addition to the GSLB service group name, provide the name of the server that hosts the service, and the port number of the service.
Example:
enable gslb serviceGroup http_svc_group 10.102.27.153 80
<!--NeedCopy-->
To disable a GSLB service group or a member of the GSLB service group by using CLI:
disable gslb serviceGroup <serviceGroupName>@ [<serverName>@ <port>]
<!--NeedCopy-->
Example:
disable gslb serviceGroup http_svc_group 10.102.27.153 80
<!--NeedCopy-->
Note:
To disable a GSLB service group, provide only the service group name. To disable a member of a service group, in addition to the GSLB service group name, provide the name of the server that hosts the service, and the port number of the service.
Changes to the existing GSLB CLI commands
The following are the changes that are done to the existing GSLB commands after the introduction of the GSLB service groups:
-
bind gslb vserver
- The service group name is added to the bind command.Example:
bind gslb vserver <name> ((-serviceName <string> [-weight <positive_integer>] ) | <serviceGroupName>@ | | (-domainName <string> [-TTL <secs>] [-backupIP<ip_addr|ipv6_addr|*>] [-cookieDomain <string>] [-cookieTimeout <mins>][-sitedomainTTL <secs>]) | (-policyName <string>@ [-priority<positive_integer>] [-gotoPriorityExpression <expression>] [-type REQUEST | RESPONSE )])) <!--NeedCopy-->
-
unbind gslb vserver
- The service group is added to the unbind command.Example:
unbind gslb vserver <name> (-serviceName <string> <serviceGroupName> @ /(-domainName <string> [-backupIP] [-cookieDomain]) | -policyName <string>@) <!--NeedCopy-->
-
show gslb site
- When this command is run, the GSLB service groups are also displayed. -
show gslb vs
- When this command is run, the GSLB service groups are displayed. -
stat gslb vs
- When this command is run, the GSLB service groups statistics are also displayed. -
show lb monitor bindings
- When this command is run, the GSLB service group bindings are also displayed.
Configure GSLB service groups by using the GUI
- Navigate to Traffic Management > GSLB > Service Groups.
- Create a service group and set the AutoScale mode to DNS.
Configure site persistence for the GSLB service groups
You can configure site persistence for the IP address based and domain name based service groups. Site persistence is not supported for domain name based autoscale service groups.
To set site persistence based on HTTP cookies by using the CLI
-
For connection proxy persistence, you do not have to set the site prefix.
At the command prompt, type:
set gslb service group <serviceGroupName> [-sitePersistence <sitePersistence>] <!--NeedCopy-->
-
For HTTP redirect persistence, you must first set the site prefix for a member of the service group and then set the
HTTPRedirect
persistence parameter for the service group.At the command prompt, type:
set gslb servicegroup <serviceGroupName> <serviceGroup member name|Ip> <port> [-sitePrefix <string>] set gslb servicegroup <serviceGroupName> [-sitePersistence <sitePersistence>] <!--NeedCopy-->
Examples:
-
Connection proxy persistence
set gslbservicegroup sg1 -sitePersistence connectionProxy <!--NeedCopy-->
-
HTTP Redirect persistence
set gslb servicegroup sg2 test1 80 -sitePrefix vserver-GSLB-1 set gslb servicegroup sg2 -sitePersistence HTTPRedirect <!--NeedCopy-->
To set site persistence based on cookies by using the GUI
- Navigate to Traffic Management > GSLB > Service Groups and select the service group that you want to configure for site persistence (for example, servicegroup-GSLB-1).
- Click the Site Persistence section and set the persistence that meets your requirement.
Tip
For deployment scenario and example configuration of GSLB service groups, see the following topics:
To change the GSLB site of a GSLB service group using CLI
At the command prompt, type:
set gslb serviceGroup <servicegroup_name> -siteName <new_site_name>
<!--NeedCopy-->
Example:
set gslb serviceGroup GSLB_SG1 -siteName Site-GSLB-West-Coast
<!--NeedCopy-->
To change the GSLB site of a GSLB service group using GUI
- Navigate to Traffic Management > GSLB > Service Groups.
- Select the service group for which you want to change the site name.
- Click Edit and in GSLB Service Group page, click Edit.
- Select the new site name, click Continue and click OK.
Share
Share
In this article
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group 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 Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.