ServerIron ADX Server Load Balancing Guide
Release 12.0.00
June 15, 2009

Table of Contents Previous Next Print


Server Load Balancing > Hash-Based SLB with Server Persistence

Hash-Based SLB with Server Persistence
This feature provides a persistent hashing mechanism for virtual server ports, which evenly distributes hash assignments and enables a client to always be redirected to the same real server. Command support is also provided to help you manage the introduction of a new server.
This feature enables a client to always be redirected to the same real server. The client will be directed to a new real server only if the assigned real server fails.
By default, SLB uses stateful load balancing for Virtual IP addresses (VIPs). In stateful load balancing, the ServerIron ADX creates session table entries for the connections between the client and the destination (the real server). If multiple real servers are bound to a VIP, then requests from the same client may be serviced by different real servers over a period of time. However for transaction-oriented systems, a client may need to be serviced by the same real server each time the client makes a request, irrespective of whether the requests were made within seconds of each other or over an extended period of time.
Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours. This setting may not be sufficient for systems that always need the client to be directed to the same real server, unless an event such as real server failure necessitates reassignment of the client to a different server.
Persistent Hash Table
Each virtual server port maintains a persistent hash table consisting of 256 entries. When the ServerIron ADX boots up initially, all the hash entries in the table are empty (no real server assignments to any of the entries). When a client makes a request to the VIP, the ServerIron ADX calculates a hash value based on the client IP. The hash will be a value between 0 and 255 and will map to one of the entries in the persistent hash table. The ServerIron ADX then retrieves the persistent hash table entry for the calculated hash value. If there is no real server allocated for the table entry, the ServerIron ADX will select a real server for that table entry using the configured SLB predictor. The system will then assign the real server to the table entry, and the client request will be serviced by the real server.
If the client makes another request to the VIP, for example after two days, then the ServerIron ADX will again calculate the hash based on the client IP and retrieve the persistent hash table entry. Since a real server has already been allocated to the persistent hash table entry, the ServerIron ADX will use this real server to service the client request. As an effect, the client will always be directed to the same real server.
Clear vs Reassign Mechanisms
You are provided two configurable mechanisms to handle the introduction of a new server:
clear-on-change — Whenever a new server comes up, the entire persistent hash table is cleared and assignments are started afresh. For more information, see “Enabling the Clear-On-Change Mechanism”.
reassign-on-change — The default. Whenever a new server comes up, the ServerIron ADX calculates the number of hash entries allocated to each existing server. The ServerIron ADX then reassigns some of these entries to the new server. For more information, see “Enabling the Reassign-On-Change Mechanism”.
Enabling Persistent Hashing
To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1
ServerIron(config-vs-vs1)# port http persist-hash
The reassign-on-change function is selected by default.
Syntax: [no] port <port> persist-hash [clear-on-change | reassign-on-change]
When peristent hashing is configured for a VIP, the round robin predictor for VIP is automatically enabled. This default is used to evenly distribute hash assignments. After you enter the port <port> persist-hash command, the predictor round-robin command automatically appears under the virtual server in the configuration file.
NOTE: SSL is a special case where sticky automatically gets turned on for SSL. If persistent hashing must be configured for port SSL, you need to explicitly turn off sticky on the SSL port using the no port ssl sticky command and then enable persistent hashing for this port.
Enabling the Clear-On-Change Mechanism
To enable the clear-on-change mechanism, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1
ServerIron(config-vs-vs1)# port http persist-hash clear-on-change
ServerIron(config-vs-vs1)# end
 
When the clear-on-change command is set for persistent hashing, the entire persistent hash table is cleared whenever a new server comes up. For example, the persistent hash table for a virtual server port is shown below:
Figure 2.15
Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the entire persistent hash table is cleared:
Figure 2.16
Enabling the Reassign-On-Change Mechanism
To enable the reassign-on-change mechanism, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip vs1
ServerIron(config-vs-vs1# port http persist-hash reassign-on-change
When reassign-on-change is enabled (the default), the ServerIron ADX reassigns some of the existing hash table entries on the introduction of a new server.
Configuring the Reassign Threshold and Duration
There are two configurable global parameters related to the reassign mechanism:
Reassign threshold — When the number of empty hash entries (buckets) in the persistent hash table falls to or below this threshold (less than or equal to), the ServerIron ADX reassigns some of the persistent hash entries on introduction of a new real server. By default, the ServerIron ADX will reassign persistent hash entries to the new real server only if there are no empty persistent hash entries (for example, the default persist hash reassign threshold is 0 percent).
To specify the threshold, enter commands such as the following:
ServerIron(config)# server persist-hash-threshold 5
Syntax: [no] server persist-hash-threshold <percent-value>
The <percent-value> can be any value from 0 to 99.
With the reassign mechanism, if multiple servers come up simultaneously and need reassignment because the number of empty hash table entries is below the reassign threshold, then the ServerIron ADX will clear the persistent hashing table.
Reassign duration — If the number of empty persistent hash entries is below the reassign threshold, the ServerIron ADX reassigns some of the persistent hash entries over a period of time to the new real server. This duration of time is known as the persist hash reassign duration.
To specify the reassign duration, enter commands such as the following:
ServerIron(config)#server persist-hash-reassign-duration 5
This global command is applied to all configured VIP ports that are persist-hash enabled. The ServerIron ADX will complete the reassignment within 2 minutes by default.
Syntax: [no] server persist-hash-reassign-duration <value>
The <value> can be a time duration from 2 to 30 minutes
Reassignment Sequence and Example
The sequence is performed as follows:
1.
When a new server is introduced, the ServerIron ADX calculates how many of the hash table entries in the persistent hash table are empty. If the number is greater than the persist-hash-reassign-threshold, the ServerIron ADX does no reassignment.
If the number of empty hash table entries is less than or equal to the persist hash reassign threshold, the ServerIron ADX proceeds with the reassignment. The system first calculates the total number of active real servers, which includes the new real server.
2.
X = entries per server = total assigned hash table entries/number of active real servers
3.
The ServerIron ADX attempts to reassign X persistent hash entries to the new real server over the duration specified by the persist-hash-reassign-duration.
The ServerIron ADX will stop reassigning persistent hash entries to the new real server when either of the following occurs:
The number of persistent hash entries assigned to the new real server is equal to the lowest number of persistent hash entries assigned to any of the existing real servers, whichever happens earlier.
Consider the following reassignment example:
Figure 2.17
Persistent hash entries have been assigned as follows. Entries 47 to 54 have been assigned to real server rs1. Entries 55 and 56 have been assigned to rs2. All other entries are empty (no real server has been assigned to them).
In this example, the administrator configures a reassign-threshold of 99 percent. That is, whenever the number of empty hash entries falls below 99 percent, the ServerIron ADX will reassign the persistent hash table entries whenever a new real server comes up. The reassign-duration is the default value (2 minutes).
Next, the administrator binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1. When real server rs3 comes up, the ServerIron ADX calculates the number of active real server ports. In this example, the number is 3 (rs1, rs2 and rs3). The system then calculates the number of empty hash table entries. In this example, the number is 246. Since less than 99 percent of the hash table entries are empty, the ServerIron ADX will attempt to reassign some of the persistent hash entries to the new real server rs3.
The ServerIron ADX now calculates entries per server X as follows:
X = total assigned hash table entries/number of active real servers = 10/3 = 3
The ServerIron ADX now attempts to reassign 3 persistent hash entries to the new real server over 2 minutes. The system will stop after it has reassigned 2 entries of real server rs1 to new real server rs3. The reason is once rs3 is assigned 2 persistent hash entries, the value is equal to the number of entries assigned to existing real server rs2.
The persistent hash table after the reassignment appears as follows:
Figure 2.18
Keeping the Persistent Hash Table Unchanged
To configure the ServerIron ADX not to clear the persistent hashing table when multiple servers come up simultaneously and need reassignment, enter commands such as the following:
SLB-ServerIron(config)# server virtual-name-or-ip vs1
SLB-ServerIron(config-vs-vs1)# port http no-auto-clear-persist-hash-buckets
If this command is configured and multiple servers need reassignment simultaneously, then the ServerIron ADX will leave the persistent hash table unchanged.
Syntax: port <port> no-auto-clear-persist-hash-buckets
Real Server Failure
If a real server fails, the ServerIron ADX will remove all assignments of the real server from all persistent hash table entries in the persistent hash table.
For example, consider a virtual server vs1 whose port HTTP is bound to port HTTP of real server rs1 and rs2. Assume the persistent hash table for vs1 for port HTTP is as follows:
Figure 2.19
Real server rs1 has been assigned to persistent hash table entries corresponding to hash value 0 and hash value 2. Real server rs2 has been assigned to the entry corresponding to hash value 1. Now assume all other hash table entries have not been assigned to any real servers.
If port HTTP of real server rs1 fails, then the ServerIron ADX will clear assignment of rs1 to the persistent hash entries in the above table. Once this is done, the persistent hash table will be as follows:
Figure 2.20
The ServerIron ADX will not immediately assign a new server to the cleared hash table entries. The ServerIron ADX will select and assign a real server for these entries using the SLB predictor the next time a client hashes to these hash table entries.
In the previous example, assume a client now makes an HTTP request for virtual server vs1. Assume also the client’s IP address hashes to a value of 2. The ServerIron ADX checks the hash table entry corresponding to hash value 2 in the above persistent hash table. Since no real server is associated with the hash entry, the ServerIron ADX selects a new real server, such as rs2, using the SLB predictor and then assigns it to the hash table entry. This and subsequent requests from the client will then be serviced by rs2.
Figure 2.21
Displaying Persistent Hash Table Entry and Statistics
To display the persistent hash table entry and statistics for a virtual server, rconsole into the BP and enter the following command:
ServerIron# show server persist-hash-buckets http-vs
Virtual port Persist Hash Buckets:
Virtual Server <http-vs> Port <80>:
Bucket: Server Hit Bucket: Server Hit
45: http-rs1 1
Virtual Server <http-vs> Port <53>:
Bucket: Server Hit Bucket: Server Hit
45: dns-ns 2
Syntax: show server persist-hash-buckets [virtual-server-name]
If you do not specify a virtual server name, then all the persistent hash tables for all virtual server ports for all virtual servers will be displayed.
 
Number of times the client IP has hashed to this entry and been serviced by the associated real server. Is is possible for multiple clients to hash to the same hash entry (bucket).
Clearing the Hit Count for the Persistent Hash Table
To clear the hit count for the persistent hash table for a virtual server port, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip http-vs
ServerIron (config-vs-http-vs)# port http clear-persist-hash-statistics
ServerIron (config-vs-http-vs)# end
Syntax: port <port> clear-persist-hash-statistics
Clearing the Persistent Hash Table
To clear the persistent hash table (all assignments and hit counts) for a virtual server port, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip http-vs
ServerIron(config-vs-http-vs)# port http clear-persist-hash-buckets
ServerIron(config-vs-http-vs)# end
Syntax: port <port> clear-persist-hash-buckets
Enabling Debugging for Persistent Hash
To enable debugging for persistent hashing, enter commands such as the following:
ServerIron(config)# server debug-persist-hash
ServerIron(config)# end
Syntax: server debug-persist-hash
Reassigning a Persistent Hash Table Entry
To manually reassign a persistent hash table entry to a real server for a specified client IP, enter a command such as the following:
ServerIron# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs1 80
Hash bucket for Client IP 1.1.1.33 = 36
Server http-rs1 allocation to bucket 36 of specified virtual server for port 80 completed!
Syntax: show server manual-persist-assign-hash <client-ip> <virtual-server-name> <virtual-port> <real-server-name> <real-port>
To verify the assignment, enter the following command:
ServerIron# show server persist-hash
Virtual port Persist Hash Buckets:
Virtual Server <http-vs> Port <80>:
Bucket: Server Hit Bucket: Server Hit
 
36: http-rs1 0
Syntax: show server persist-hash
If a real server is manually assigned to a hash entry, the hit count will not be incremented for the assignment.
Additionally, if you manually assign a real server for a hash table entry for which another real server is currently assigned, the new real server will replace the old real server for the hash entry as follows:
ServerIron# show server manual-persist-assign-hash 1.1.1.33 http-vs 80 http-rs2 80
Hash bucket for Client IP 1.1.1.33 = 36
Replacing current server http-rs1 allocated for hash 36 with server http-rs2
Server http-rs2 allocation to bucket 36 of specified virtual server for port 80 completed!

Server Load Balancing > Hash-Based SLB with Server Persistence

Table of Contents Previous Next Print
Copyright © 2009 Brocade Communications Systems, Inc.