-
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
-
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
-
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
-
-
-
-
-
-
-
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!
Hashing methods
Load balancing methods based on hashes of certain connection information or header information constitute most the Citrix ADC appliance’s load balancing methods. Hashes are shorter and easier to use than the information that they are based on, while retaining enough information to ensure that no two different pieces of information generate the same hash and are therefore confused with one another.
You can use the hashing load balancing methods in an environment where a cache serves a wide range of content from the Internet or specified origin servers. Caching requests reduces request and response latency, and ensures better resource (CPU) utilization, making caching popular on heavily used websites and application servers. Since these sites also benefit from load balancing, hashing load balancing methods are widely useful.
The Citrix ADC appliance provides the following hashing methods:
- URL hash method
- Domain hash method
- Destination IP hash method
- Source IP hash method
- Source IP Destination IP hash method
- Source IP Source Port hash method
- Call ID hash method
- Token method
Most of the hashing algorithms calculate two hash values:
- A hash of the service’s IP address and port.
- A hash of the incoming URL, the domain name, the source IP address, the destination IP address, or the source and destination IP addresses, depending on the configured hash method.
The Citrix ADC appliance then generates a new hash value by using both of those hash values. Finally, it forwards the request to the service with the highest hash value. As the appliance computes a hash value for each request and selects the service that processes the request, it populates a cache. Subsequent requests with the same hash value are sent to the same service. The following flow chart illustrates this process.
Note
Starting from Citrix ADC release 13.0 build 79.x, Prime Re-Shuffled Assisted CARP (PRAC) and Jump table Assisted Ring Hash (JARH) consistent hashing algorithms are supported. The consistent hashing algorithms ensure minimal disruption when services are added to or deleted from your load balancing setup, or during a service flap event in load balancing setup. For more details, see Consistent hashing algorithms.
Figure 1. How the Hashing Methods Distribute Requests
Hashing methods can be applied to IPv4 and IPv6 addresses.
Consider a scenario where three services (Service-HTTP-1, Service-HTTP-2, and Service-HTTP-3) are bound to a virtual server, any hash method is configured, and the hash value is Hash1. When the configured services are UP, the request is sent to Service-HTTP-1. If Service-HTTP-1 is down, the Citrix ADC appliance calculates the hash value for the last log of the number of services. The appliance then selects the service with the highest hash value, such as Service-HTTP-2. The following diagram illustrates this process.
Figure 2. Entity Model for Hashing Methods
Note
If the Citrix ADC appliance fails to select a service by using a hashing method, it defaults to the least connection method to select a service for the incoming request. Adjust server pools by removing services during periods of low traffic to enable the caches to repopulate without affecting performance on your load balancing setup.
Consistent hashing algorithms
The consistent hashing algorithms are used to achieve stateless persistency. The hash-based LB methods use one of the following three consistent hashing algorithms:
-
Cache Array Routing Protocol (CARP)
The CARP algorithm is used in load-balancing HTTP requests across multiple proxy cache servers. This algorithm is enabled by default.
-
Prime Re-Shuffled Assisted CARP (PRAC)
The Citrix ADC appliance uses the proprietary PRAC algorithm to provide uniform traffic distribution.
-
Jump table Assisted Ring Hash (JARH)
The Citrix ADC appliance uses the proprietary JARH algorithm to provide consistency and uniform distribution of the traffic. This algorithm uses hash fingers. Higher number of fingers provide better distribution of traffic. However, increasing the number of fingers increases the memory usage as well.
To choose the consistent hashing algorithm by using CLI
set lb parameter [-lbHashAlgorithm [DEFAULT|JARH|PRAC] [-lbHashFingers <positive_integer>]
<!--NeedCopy-->
Example:
set lb parameter -lbHashAlgorithm JARH -lbHashFingers 10
<!--NeedCopy-->
ARGUMENTS:
-
lbHashAlgorithm-Specify the hashing algorithm to be used for the following hash-based load balancing methods:
- URL hash method
- Domain hash method
- Destination IP hash method
- Source IP hash method
- Source IP Destination IP hash method
- Source IP Source Port hash method
- Call ID hash method
- Token method
Possible values: DEFAULT, PRAC, JARH Default value: DEFAULT
-
lbHashFingers-Specify the number of fingers to be used in PRAC and JARH algorithms for hash-based LB methods. Increasing the number of fingers provides better distribution of traffic at the expense of extra memory.
Default value: 256 Minimum value: 1 Maximum value: 1024
To choose the consistent hashing algorithm by using GUI
- Navigate to Traffic Management > Load Balancing > Change Load Balancing parameters.
-
In the Configure Load Balancing Parameters pane, enter appropriate values for the following fields based on your requirement:
- LB Hash Fingers
- In the LB Hash Algorithm field, choose the consistent hashing algorithm from the drop-down menu.
The URL Hash Method
When you configure the Citrix ADC appliance to use the URL hash method for load balancing the services, for selecting a service, the appliance generates a hash value of the HTTP URL present in the incoming request. If the service selected by the hash value is DOWN, the algorithm has a method to select another service from the list of active services. The appliance caches the hashed value of the URL, and when it receives subsequent requests that use the same URL, it forwards them to the same service. If the appliance cannot parse an incoming request, it uses the round robin method for load balancing instead of the URL hash method.
For generating the hash value, the appliance uses a specific algorithm and considers a part of the URL. By default, the appliance considers the first 80 bytes of the URL. If the URL is of less than 80 bytes, the complete URL is used. You can specify a different length. The hash length can be from 1 byte to 4096 bytes. Generally, if long URLs are used where only a few characters are different, it is a good idea to make the hash length as high as possible to try to ensure a more even load distribution.
Consider a scenario where three services, Service-HTTP-1, Service-HTTP-2, and Service-HTTP-3, are bound to a virtual server, and the load balancing method configured on the virtual server is the URL hash method. The virtual server receives a request and the hash value of the URL is U1. Appliance selects Service-HTTP-1. If Service-HTTP-1 is DOWN, the appliance selects Service-HTTP-2.
The following diagram illustrates this process.
Figure 3. How URL Hashing Operates
If both Service-HTTP-1 and Service-HTTP-2 are DOWN, the appliance sends requests with hash value U1 to Service-HTTP-3.
If Service-HTTP-1 and Service-HTTP-2 are down, requests that generate the hash URL1 are sent to Service-HTTP-3. If these services are UP, the requests that generate the hash URL1 are distributed in the following manner:
- If the Service-HTTP-2 is up, the request is sent to Service-HTTP-2.
- If the Service-HTTP-1 is up, the request is sent to Service-HTTP-1.
- If Service-HTTP-1 and Service-HTTP-2 are up at the same time, the request is sent to Service-HTTP-1.
To configure the URL hash method, see Configuring a Load Balancing Method that Does Not Include a Policy. Select the load balancing method as URL Hash, and set the hash length to the number of bytes to be used for generating the hash value.
The Domain Hash Method
A load balancing virtual server configured to use the domain hash method uses the hashed value of the domain name in the HTTP request to select a service. The domain name is taken from either the incoming URL or the Host header of the HTTP request. If the domain name appears in both the URL and the Host header, the appliance gives preference to the URL.
If you configure domain name hashing, and an incoming HTTP request does not contain a domain name, the Citrix ADC appliance defaults to the round robin method for that request.
The hash-value calculation uses the name length or hash length value, whichever is smaller. By default, the Citrix ADC appliance calculates the hash value from the first 80 bytes of the domain name. To specify a different number of bytes in the domain name when calculating the hash value, you can set the hashLength parameter (Hash Length in the configuration utility) to a value of from 1 to 4096 (bytes).
To configure the domain hash method, see Configuring a Load Balancing Method that Does Not Include a Policy.
The Destination IP Hash Method
A load balancing virtual server configured to use the destination IP hash method uses the hashed value of the destination IP address to select a server. You can mask the destination IP address to specify which part of it to use in the hash value calculation, so that requests that are from different networks but destined for the same subnet are all directed to the same server. This method supports IPv4 and IPv6-based destination servers.
This load balancing method is appropriate for use with the cache redirection feature.
To configure the destination IP hash method for an IPv4 destination server, you set the netMask parameter. To configure this method for an IPv6 destination server, you use the v6NetMaskLen parameter. In the configuration utility, text boxes for setting these parameters appear when you select the Destination IP Hash method.
To configure the destination IP hash method, see Configuring a Load Balancing Method that Does Not Include a Policy.
The Source IP Hash Method
A load balancing virtual server configured to use the source IP hash method uses the hashed value of the client IPv4 or IPv6 address to select a service. To direct all requests from source IP addresses that belong to a particular network to a specific destination server, you must mask the source IP address. For IPv4 addresses, use the netMask parameter. For IPv6 addresses, use the v6NetMaskLength parameter.
To configure the source IP hash method, see Configuring a Load Balancing Method that Does Not Include a Policy.
The Source IP Destination IP Hash Method
A load balancing virtual server configured to use the source IP destination IP hash method uses the hashed value of the source and destination IP addresses (either IPv4 or IPv6) to select a service. Hashing is symmetric. The hash value is the same regardless of the order of the source and destination IPs. This ensures that all packets flowing from a particular client to the same destination are directed to the same server.
To direct all requests that belong to a particular network to a specific destination server, you must mask the source IP address. For IPv4 addresses, use the netMask parameter. For IPv6 addresses, use the v6NetMaskLength parameter.
To configure the source IP destination IP hash method, see Configuring a Load Balancing Method that Does Not Include a Policy.
The Source IP Source Port Hash Method
A load balancing virtual server configured to use the source IP source port hash method uses the hash value of the source IP (either IPv4 or IPv6) and the source port to select a service. This ensures that all packets on a particular connection are directed to the same service.
This method is used in connection mirroring and firewall load balancing. For more information about connection mirroring, see Connection Failover.
To direct all requests that belong to a particular network to a specific destination server, you must mask the source IP address. For IPv4 addresses, use the netMask parameter. For IPv6 addresses, use the v6NetMaskLength parameter.
To configure the source IP source port hash method, see Configuring a Load Balancing Method that Does Not Include a Policy.
The Call ID Hash Method
A load balancing virtual server configured to use the call ID hash method uses the hash value of the call ID in the SIP header to select a service. Packets for a particular SIP session are therefore always directed to the same proxy server.
This method is applicable to SIP load balancing. For more information about SIP load balancing, see Monitoring SIP Services.
To configure the call ID hash method, see Configuring a Load Balancing Method that Does Not Include a Policy.
Share
Share
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.