-
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
-
-
-
Configure metrics exchange protocol
-
Use case: Deployment of domain name based autoscale service group
-
Use case: Deployment of IP address based autoscale service group
-
-
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 metrics exchange protocol
The data centers in a GSLB setup exchange metric with each other through the metrics exchange protocol (MEP), which is a proprietary protocol for NetScaler appliance. The exchange of the metric information begins when you create a GSLB site. These metrics comprise load, network, and persistence information.
MEP is required for health checking of data centers to ensure their availability. A connection for exchanging network metric (round-trip time) can be initiated by either of the data centers involved in the exchange, but a connection for exchanging site metrics is always initiated by the data center with the lower IP address. By default, the data center uses a subnet IP address (SNIP) to establish a connection to the IP address of a different data center. However, you can configure a specific SNIP, virtual IP (VIP) address, or the NSIP address, as the source IP address for metrics exchange. The communication process between GSLB sites uses TCP port 3011 or 3009, so this port must be open on firewalls that are between the NetScaler appliances.
Note: You can configure a SNIP or a GSLB site IP address as the source IP address for metrics exchange. For more information, see Configure source IP address for an RPC node.
If the source and target sites (the site that initiates a MEP connection and the site that receives the connection request, respectively) have both private and public IP addresses configured, the sites exchange MEP information by using the public IP addresses.
You can also bind monitors to check the health of remote services as described in “Monitoring GSLB Services.” When monitors are bound, metric exchange does not control the state of the remote service. If a monitor is bound to a remote service and metric exchange is enabled, the monitor controls the health status. Binding the monitors to the remote service enables the NetScaler appliance to interact with a non-NetScaler load balancing device. The NetScaler appliance can monitor non-NetScaler devices but cannot perform load balancing on them unless monitors are bound to all GSLB services and only static load balancing methods (such as the round robin, static proximity, or hash-based methods) are used.
With NetScaler release 11.1.51.x or later, to avoid unnecessary disruption of services, you can set a time delay for marking GSLB services as DOWN when a MEP connection goes DOWN.
MEP state in a high availability setup
In a high availability setup, the primary node establishes connections with the remote sites and the MEP state is not synchronized from the primary node to secondary nodes. Therefore, the MEP state in secondary node remains DOWN. When the secondary node becomes primary, it establishes MEP connections with the new GSLB site and updates the MEP state accordingly.
Enable site metrics exchange
Site metrics exchanged between the GSLB sites include the status of each load balancing, or content switching virtual server, the current number of connections, the current packet rate, and current bandwidth usage information.
The NetScaler appliance needs this information to perform load balancing between the sites. The site metric exchange interval is 1 second. A remote GSLB service must be bound to a local GSLB virtual server to enable the exchange of site metrics with the remote service.
To enable or disable site metrics exchange by using the command line interface
At a command prompt, type the following commands to enable or disable site metric exchange and verify the configuration:
set gslb site <siteName> -metricExchange (ENABLED|DISABLED)
show gslb site** <siteName>
<!--NeedCopy-->
Example:
set gslb site Site-GSLB-East-Coast -metricExchange ENABLED
set gslb site Site-GSLB-East-Coast -metricExchange DISABLED
show gslb site Site-GSLB-East-Coast
<!--NeedCopy-->
To enable or disable site metric exchange by using the GUI
- Navigate to Traffic Management > GSLB > Sites, and select the site.
- In the Configure GSLB Site dialog box, select the Metric Exchange option.
Enable network metric exchange
If your GSLB sites use the round-trip time (RTT) load balancing method, you can enable or disable the exchange of RTT information about the client’s local DNS service. This information is exchanged every 5 seconds.
For details about changing the GSLB method to a method based on RTT, see GSLB Methods.
To enable or disable network metric information exchange by using the command line interface
At the command prompt, type the following commands to enable or disable network metric information exchange and verify the configuration:
set gslb site <siteName> -nwmetricExchange (ENABLED|DISABLED)
show gslb site <<siteName>
<!--NeedCopy-->
Example:
set gslb site Site-GSLB-East-Coast -nwmetricExchange ENABLED
set gslb site Site-GSLB-East-Coast -nwmetricExchange DISABLED
show gslb site Site-GSLB-East-Coast
<!--NeedCopy-->
To enable or disable network metric information exchange by using the GUI
- Navigate to Traffic Management > GSLB > Sites.
- In the Configure GSLB Site dialog box, select the Network Metric Exchange option.
Configuring a time delay for the GSLB services to be marked as DOWN when a MEP connection goes DOWN
If the status of a MEP connection to a remote site changes to DOWN, the status of every GSLB service on that remote site is marked as DOWN, although the site might not actually be DOWN.
You can now set a delay to allow some time for reestablishment of the MEP connection before the site is marked as DOWN. If the MEP connection is back UP before the delay expires, the services are not affected.
For example, if you set the delay to 10, the GSLB services remain UP until the MEP connection has been DOWN for 10 seconds. After this duration, the GSLB services are marked as DOWN. However, if the MEP connection is back UP within the 10 seconds, the GSLB services remain in the UP state.
Note:
This delay is applicable only for services that are not bound to a monitor. The delay does not affect the trigger monitors.
To set a time delay by using the command line interface
At the command prompt, type the following command:
set gslb parameter** - GSLBSvcStateDelayTime <sec>
<!--NeedCopy-->
Example:
set gslb parameter - GSLBSvcStateDelayTime 10
Note
In a hierarchical deployment (parent-child topology), if you configure the GSLB service on both the parent and child sites, set the GSLB parameter on both the parent and child sites. If you do not configure the GSLB service on the child site, set the GSLB parameter only on the parent site.
To set a time delay by using the GUI
- Navigate to Configuration > Traffic Management > GSLB > Change GSLB Settings.
- In the GSLB Service State Delay Time (secs) box, type the time delay in seconds.
Configure a learning time for GSLB services when MEP connection status comes up to avoid flaps on GSLB services
When a node reboots or during HA failover, the system is initialized. Then, the node must learn current information about the configured local and child services to communicate the service state to remote nodes through MEP. The node takes some time to learn the correct information. Meanwhile, if a peer node connects to this node and requests for an update, the node might send an incorrect service state and statistics. This incorrect information might cause service flap and other functionality related issues on the remote peer nodes. To avoid this scenario, you can now set a learning time for the local and child GSLB service.
When a learning timeout is configured, the GSLB site gets some buffer time (learning timeout) to learn the correct statistics about its local and child services. When a service is in a learning phase, the remote GSLB site gets this information in MEP update, and does not honor the primary site state and statistics received through MEP for that service.
GSLB services enter the learning phase in any of the following scenarios.
- NetScaler appliance is rebooted
- High availability failover has occurred
- Owner node in a cluster GSLB setup is changed
- MEP is enabled on a local node
- GSLB site comes out of island scenario. A GSLB Site becomes island when it is not connected to any other site.
In a parent-child deployment, the backup parent (if configured) selectively moves the adopted child site’s GSLB services to the learning phase when the primary parent goes DOWN.
To set a service state learning time by using the CLI
At the command prompt, type the following command:
set gslb parameter – SvcStateLearningTime <sec>
<!--NeedCopy-->
You can set “SvcStateLearningTime” in seconds. Default value is 0 and maximum value is 3600. This parameter is applicable only if monitors are not bound to GSLB services.
Example:
set gslb parameter – SvcStateLearningTime 10
<!--NeedCopy-->
To set a service state learning time by using the GUI
-
Navigate to Configuration > Traffic Management > GSLB > Dashboard > Change GSLB Settings.
The Set GSLB Parameters page appears.
-
In the GSLB Service State Learning Time (secs) field, type the learning time in seconds.
Enable persistence information exchange
You can configure NetScaler appliance to provide persistent connections, so that a client transmission to any virtual server in a group can be directed to a server that has received previous transmissions from the same client.
You can enable or disable the exchange of persistence information at each site. This information is exchanged once every 5 seconds between NetScaler appliances participating in GSLB.
For details about configuring persistence, see Configuring Persistent Connections.
To enable or disable persistence information exchange by using the command line interface
At the command prompt, type the following commands to enable or disable persistence-information exchange and verify the configuration:
set gslb site <siteName> -sessionExchange (ENABLED|DISABLED)
show gslb site** <siteName>
<!--NeedCopy-->
Example:
set gslb site Site-GSLB-East-Coast -sessionExchange ENABLED
set gslb site Site-GSLB-East-Coast -sessionExchange DISABLED
show gslb site Site-GSLB-East-Coast
<!--NeedCopy-->
To enable or disable persistence information exchange by using the GUI
- Navigate to Traffic Management > GSLB > Sites, and double-click the site.
- In the Configure GSLB Site dialog box, select, or clear the Persistence Session Entry Exchange check box.
Share
Share
In this article
- MEP state in a high availability setup
- Enable site metrics exchange
- Enable network metric exchange
- Configuring a time delay for the GSLB services to be marked as DOWN when a MEP connection goes DOWN
- Configure a learning time for GSLB services when MEP connection status comes up to avoid flaps on GSLB services
- Enable persistence information exchange
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.