Getting Started with Citrix ADC
Deploy a Citrix ADC VPX instance
Optimize Citrix ADC VPX performance on VMware ESX, Linux KVM, and Citrix Hypervisors
Apply Citrix ADC VPX configurations at the first boot of the Citrix ADC appliance in cloud
Install a Citrix ADC VPX instance on Microsoft Hyper-V servers
Install a Citrix ADC VPX instance on Linux-KVM platform
Prerequisites for Installing Citrix ADC VPX Virtual Appliances on Linux-KVM Platform
Provisioning the Citrix ADC Virtual Appliance by using OpenStack
Provisioning the Citrix ADC Virtual Appliance by using the Virtual Machine Manager
Configuring Citrix ADC Virtual Appliances to Use SR-IOV Network Interface
Configuring Citrix ADC Virtual Appliances to use PCI Passthrough Network Interface
Provisioning the Citrix ADC Virtual Appliance by using the virsh Program
Provisioning the Citrix ADC Virtual Appliance with SR-IOV, on OpenStack
Configuring a Citrix ADC VPX Instance on KVM to Use OVS DPDK-Based Host Interfaces
Deploy a Citrix ADC 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
Configure a Citrix ADC VPX instance to use SR-IOV network interface
Configure a Citrix ADC VPX instance to use Enhanced Networking with AWS ENA
Deploy a Citrix ADC VPX instance on Microsoft Azure
Network architecture for Citrix ADC VPX instances on Microsoft Azure
Configure multiple IP addresses for a Citrix ADC 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
Configure a Citrix ADC VPX instance to use Azure accelerated networking
Configure HA-INC nodes by using the Citrix high availability template with Azure ILB
Configure a high-availability setup with Azure external and internal load balancers simultaneously
Configure address pools (IIP) for a Citrix Gateway appliance
Upgrade and downgrade a Citrix ADC appliance
Authentication, authorization, and auditing application traffic
Basic components of authentication, authorization, and auditing configuration
On-premises Citrix Gateway as an identity provider to Citrix Cloud
Authentication, authorization, and auditing configuration for commonly used protocols
Troubleshoot authentication and authorization related issues
-
-
-
-
-
-
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 for load balancing
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
Use case 15: Configure layer 4 load balancing on the Citrix ADC 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 Citrix ADC 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!
Customize your GSLB configuration
Once your basic GSLB configuration is operational, you can customize it by modifying the bandwidth of a GSLB service, configuring CNAME based GSLB services, static proximity, dynamic RTT, persistent connections, or dynamic weights for services, or changing the GSLB Method.
You can also configure monitoring for GSLB services to determine their states.
These settings depend on your network deployment and the types of clients you expect to connect to your servers.
Modify maximum connections or maximum bandwidth for a GSLB service
你可以限制新客户的数量n simultaneously connect to a load balancing or content switching virtual server by configuring the maximum number of clients and/or the maximum bandwidth for the GSLB service that represents the virtual server.
To modify the maximum clients or bandwidth of a GSLB service by using the command line interface
在命令提示符下,键入以下命令to modify the maximum number of client connections or the maximum bandwidth of a GSLB service and verify the configuration:
set gslb service [-maxClients ] [-maxBandwidth ] show gslb service
Example:
set glsb service Service-GSLB-1 –maxBandwidth 100 –maxClients 100 show gslb service Service-GSLB-1
To modify the maximum clients or bandwidth of a GSLB service by using the configuration utility
- Navigate toTraffic Management>GSLB>Services, and double-click a service.
- Click in theOther Settings部分,并设置以下参数:
- Max Clients—maxClients
- Max Bandwidth—maxBandwidth
Create CNAME-based GSLB services
To configure a GSLB service, you can use the IP address of the server or a canonical name of the server. If you want to run multiple services (like an FTP and a Web server, each running on different ports) from a single IP address or run multiple HTTP services on the same port, with different names, on the same physical host, you can use canonical names (CNAMES) for the services.
For example, you can have two entries in DNS as ftp.example.com and www.example.com for FTP services and HTTP services on the same domain, example.com. CNAME-based GSLB services are useful in a multilevel domain resolver configuration or in multilevel domain load balancing. Configuring a CNAME-based GSLB service can also help if the IP address of the physical server is likely to change.
If you configure CNAME-based GSLB services for a GSLB domain, when a query is sent for the GSLB domain, the Citrix ADC appliance provides a CNAME instead of an IP address. If the A record for this CNAME record is not configured, the client must query the CNAME domain for the IP address. If the A record for this CNAME record is configured, the Citrix ADC appliance provides the CNAME with the corresponding A record (IP address). The Citrix ADC appliance handles the final resolution of the DNS query, as determined by the GSLB method. The CNAME records can be maintained on a different Citrix ADC appliance or on a third-party system.
In an IP-address-based GSLB service, the state of a service is determined by the state of the server that it represents. However, a CNAME-based GSLB service has its state set to UP by default; the virtual server IP (VIP) address or metric exchange protocol (MEP) are not used for determining its state. If a desktop-based monitor is bound to a CNAME-based GSLB service, the state of the service is determined according to the result of the monitor probes.
你可以绑定一个CNAME-based GSLB服务只有一个GSLB virtual server that has the DNS Record Type as CNAME. Also, a Citrix ADC appliance can contain at most one GSLB service with a given CNAME entry.
以下是支持f的一些特性or a CNAME-based GSLB service:
- GSLB-policy based site affinity is supported, with the CNAME as the preferred location.
- Source IP persistence is supported. The persistency entry contains the CNAME information instead of the IP address and port of the selected service.
The following are the limitations of CNAME-based GSLB services:
- Site persistence is not supported, because the service referenced by a CNAME can be present at any third-party location.
- Multiple-IP-address response is not supported because one domain cannot have multiple CNAME entries.
- Source IP Hash and Round Robin are the only load balancing methods supported. The Static Proximity method is not supported because a CNAME is not associated with an IP address and static proximity can be maintained only according to the IP addresses.
Note: The Empty-Down-Response feature should be enabled on the GSLB virtual server to which you bind the CNAME-based GSLB service. If you enable the Empty-Down-Response feature, when a GSLB virtual server is DOWN or disabled, the response to a DNS query, for the domains bound to this virtual server, contains an empty record without any IP addresses, instead of an error code.
To create a CNAME-based GSLB service by using the command line interface
At the command prompt, type:
add gslb service -cnameEntry -siteName
Example:
add gslb service Service-GSLB-1 -cnameEntry transport.mycompany.com -siteName Site-GSLB-East-Coast add gslb service Service-GSLB-2 -cnameEntry finance.mycompany.com -siteName Site-GSLB-West-Coast
To create a CNAME-based GSLB service by using the configuration utility
- Navigate toTraffic Management>GSLB>Services.
- Create a service, and set theType to Canonical Name Based.
Configure transition Out-Of-Service State (TROFS) in GSLB
When you configure persistence on a GSLB virtual server to which a service is bound, the service continues to serve requests from the client even after it is disabled, accepting new requests or connections only to honor persistence. After a configured period of time, known as the graceful shutdown period, no new requests or connections are directed to the service, and all of the existing connections are closed.
When disabling a service, you can specify a graceful shutdown period, in seconds, by using the delay argument. During the graceful shutdown period, if the service is bound to a virtual server, its state appears as Out of Service.
Configure dynamic weights for services
In a typical network, there are servers that have a higher capacity for traffic than others. However, with a regular load balancing configuration, the load is evenly distributed across all services even though different services represent servers with different capacities.
To optimize your GSLB resources, you can configure dynamic weights on a GSLB virtual server. The dynamic weights can be based on either the total number of services bound to the virtual server or the sum of the weights of the individual services bound to the virtual server. Traffic distribution is then based on the weights configured for the services.
When dynamic weights are configured on the GSLB virtual server, requests are distributed according to the load balancing method, the weight of the GSLB service, and the dynamic weight. The product of the weight of the GSLB service and the dynamic weight is known as the cumulative weight. Therefore, when dynamic weight is configured on the GSLB virtual server, requests are distributed on the basis of the load balancing method and the cumulative weight.
When dynamic weight for a virtual server is disabled, the numerical value is set to 1. This ensures that the cumulative weight is a non-zero integer at all times.
Dynamic weight can be based on the total number of active services bound to load balancing virtual servers or on the weights assigned to the services.
Consider a configuration with two GSLB sites configured for a domain and each site has two services that can serve the client. If a service at either site goes down, the other server in that site has to handle twice as much traffic as a service at the other site. If dynamic weight is based on the number of active services, the site with both services active has twice the weight of the site with one service down and therefore receives twice as much traffic.
Alternatively, consider a configuration in which the services at the first site represent servers that are twice as powerful as servers at the second site. If dynamic weight is based on the weights assigned to the services, twice as much traffic can be sent to the first site as to the second.
Note: For details on assigning weights to load balancing services, seeAssigning Weights to Services.
As an illustration of how dynamic weight is calculated, consider a GSLB virtual server that has a GSLB service bound to it. The GSLB service represents a load balancing virtual server that in turn has two services bound to it. The weight assigned to the GSLB service is 3. The weights assigned to the two services are 1 and 2 respectively. In this example, when dynamic weight is set to:
- Disabled:The cumulative weight of the GSLB virtual server is the product of the dynamic weight (disabled = 1) and the weight of the GSLB service (3), so the cumulative weight is 3.
- SERVICECOUNT: The count is the sum of the number of services bound to the load balancing virtual servers corresponding to the GSLB service (2), and the cumulative weight is the product of the dynamic weight (2) and the weight of the GSLB service (3), which is 6.
- SERVICEWEIGHT: The dynamic weight is the sum of the weights of services bound to the load balancing virtual servers corresponding to the GSLB service (3), and the cumulative weight is the product of the dynamic weight (3) and the weight of the GSLB service (3), which is 9.
Note: Dynamic weights are not applicable when content switching virtual servers are configured.
To configure a GSLB virtual server to use dynamic weights by using the command line interface
At the command prompt, type:
set gslb vserver -dynamicWeight SERVICECOUNT | SERVICEWEIGHT
Example:
set gslb vserver vserver-GSLB-1 -dynamicWeight SERVICECOUNT
To set GSLB virtual server to use dynamic weights by using the configuration utility
- Navigate to Traffic Management > GSLB > Virtual Servers, double-click the GSLB virtual server whose method you want to change (for example, vserver-GSLB-1).
- Click theMethodsection and, from theDynamic Weightdrop-down list, selectSERVICECOUNTorSERVICEWEIGHT.
Share
Share
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.