Server Management in the WSD

Technical Application Note 1025 Server Management in the WSD Scope RADWare s Web Server Director (WSD) essentially allows multiple clients to be load balanced between an identical and redundant group of server, known as a server farm. In order to effectively manage the load for the servers, the WSD employs various techniques that allow the administrator to optimize the utilization of the servers in a farm, depending on the application. This document is a technical discussion of the variety of schemes used by the WDS to manage server-bound traffic. Also, configuration of these options is discussed. The document assumes that the reader has basic knowledge of WSD operation and it s configuration through SNMP management, such as RADWare s ConfigWare. Typical configuration The following diagram shows a typically configured WSD network. It can be referenced for all discussions in this document: Figure 1 1

The following table shows the general configuration of this setup: Farm IP (virtual IP) address Server IP address Server name 145.145.1.1 145.145.100.100 Larry 145.145.200.200 Moe 145.145.2.2 145.145.100.101 Larry 145.145.200.201 Moe Table 1 As shown in Table 1, there are 2 virtual addresses present on the WSD: 145.145.1.1 and 145.145.2.2. Each of them is bound to one of the IP addresses on each of the servers Larry and Moe. Notice that in selecting server names, there is consistency in naming the same physical box the same physical name. When a client approaches one of the WSD virtual addresses from the Internet/Intranet, a server from the appropriate farm is chosen and the client is directed to that server, through the WSD. For a detailed explanation of client management, refer to RADWare Technical Application Note 1020: Client Table Management in the WSD. Server health The WSD must be aware of the health of all the servers configured in its farms. To attain this, the following health checking options are available: 1. Pings: The WSD pings the server s IP address. A response from the server indicates that it s active and OK. 2. TCP Port - The WSD can be configured to monitor a specific TCP port on the servers in a farm. For example, in an HTTP farm, the WSD will monitor TCP port 80 of all the servers. This is done by continuous opening and resetting of TCP sessions for TCP port 80 to the servers. A successful session establishment indicates that the server is active. 3. UDP Port - Similar to TCP Port, the WSD can be configured to check for a response on a UDP port. With this method, the availability of a configured UDP port is monitored by the WSD. 4. HTTP-specific options A number of options specifically designed for checking of HTTP servers is available on the WSD: HTTP Page - The WSD can periodically check for the existence of a page/file one each of the servers in the farm. The page can be in the server s WWW root directory or further down the directory structure. HTTP Code - When using HTTP Page checking (and Content Checking see below), by default, the WSD first checks for an HTTP code response of 200 (Page OK). If the WSD does not receive the expected response, it will mark the server inactive. In addition to status code 200, a list of acceptable HTTP codes can be configured per server farm. A page response with any of these acceptable codes will indicate a healthy server to the WSD. Furthermore, status 2

code 200 can be deleted from this list. This can be helpful, for example, if the absence of a page is to be periodically checked by the WSD (status code 404 is acceptable). HTTP Content Checking - Additionally, when HTTP Page checking is enabled, the WSD can be configured to look for the presence or absence of a string of characters on that page (up to 64 contiguous characters). After a page is retrieved from a server, the WSD first checks to make sure the HTTP code is on the acceptable code list (described above). If this is the case, the WSD then checks the content of the page and searches for the presence or absence of the pre-configured string of text. The frequency of both above methods is user configurable. Also, the WSD can be configured to retry for a predefined number of times before marking a server as inactive. The WSD can also be configured not to do any server checking at all, per farm. During farm creation, the following parameters need to be configured for server health checking: 1. Check Connectivity Method: Can be selected as ping, disable, TCP port, UDP Port, or HTTP Page.. 2. Check Connectivity Port: The TCP/UDP port number to be checked. For reference, well known applications with predefined ports are indexed. However, any TCP/UDP port number can be manually entered in this field. If HTTP page checking is selected as the method, the WSD will use the TCP port defined here to open HTTP connections to the servers. 3. Polling Interval: How often (in seconds) the servers health is checked. 4. Number of Retries: After how many continuous polling failures will the WSD mark the server as inactive. This number multiplied by the polling interval will determine the time it would take the WSD to mark a server down after server failure. This parameter should be configured with consideration given to the fact that in busy networks, some packets (including successful server responses to WSD polling) may get lost. 5. Home Page: The web page to retrieve from a server, in case HTTP Page is selected as the Check Connectivity Method. 6. Retrieval Frequency: This parameters is used in conjunction with Home Page. If HTTP Page checking is configured, the page is retrieved with this frequency from the server. The WSD will do simple TCP checks to the server (for the configured TCP port) and once every Retrieval_Frequency TCP checks, the WSD will perform an HTTP GET for the specified page. For all check methods, the WSD will mark a server Inactive if it doesn't get a response within the specified time. However, the WSD will continue to poll the server and will mark it active when it receives an appropriate response. 3

Additional steps are necessary in order to configure acceptable HTTP codes and Content Checking. With ConfigWare, in the Farm Table window, two buttons are available for this configuration. Highlight a farm and press the: HTTP Code button to list the acceptable HTTP codes for the selected farm. By default, 200 is the first entry in this list. Other codes can be added to the list. Code 200 can also be removed from the list. Content Check button to configure content checking. The search string is configured here, per farm, along with whether the presence or the absence of the string indicates a healthy server. Server operational mode A server in a WSD farm can be configured to have one of 2 operational modes: 1. Regular: The server s health is checked and the server is eligible for receiving client requests. 2. Backup: The server s health is checked, but the server does not receive any client requests. The server is put in service and eligible for client requests when ALL the regular servers in a farm have failed or if all servers in the farm have reached their Connection Limits (if any have been set). During server creation or after a server is created, the parameter Server Operational Status can be configured to either regular or backup. Server Status A server configured in the WSD has 2 status indicators. One is known as the Operational Status and the other as the Administrative Status. The Operational Status is monitored dynamically through the health checking mechanisms above. Once a server is determined to be inactive (according to the polling criteria), all active entries in the client table for this server are immediately removed. Therefore, when the clients retry (manually or dynamically) to access the virtual address, they are sent to a server whose Operational Status is active. The Administrative Status of the servers is controlled by the administrator, through configuration and can be set to one of the following: 1. Enable: The server is active and eligible for receiving client requests. 2. Disable: The server is inactive and will not receive any clients. If active clients being sent by the WSD to a server when the server status is changed to disable, the clients are removed from the client table and the next packet from these clients will be sent to an active server. A server with a disabled Administrative Status has a Not In Service Operational Status. 3. Shutdown: An active server can be changed to Shutdown status to allow for server maintenance or updates. When a server is configured to Shutdown mode, the WSD will not send any new sessions to it, but it will allow existing clients on that server to complete their sessions. This mode allows for a graceful shutdown process to avoid abruptly disconnecting users. A trap is generated by the WSD when a server is gracefully cleared of all users. 4

While in operation, a server s Administrative Status can be changed to and from any of the Status settings listed above. When operational, both Operational Status and Administrative Status can be seen. The Operational Status is a read only parameter and the Administrative Status can be toggled between Enable, Disable and Shutdown. Load balancing algorithms The WSD employs a number sophisticated load balancing algorithms for distribution of servers to the clients: 1. Cyclic: The clients are distributed to the servers in the server farm in round robin fashion. 2. Least amount of users: When a client first approaches a WSD virtual address, it is directed to the server with the least number of session on it at that given time. The session number is defined by the active client table entries to this server. 3. Least amount of traffic: When a client first approaches a WSD virtual address, it is directed to the server with the least amount of traffic on it at that given time. The amount of traffic is defined as pps (packets per second) from the WSD to the server AND from the server to the WSD (back to the user). 4. Least amount of users - local: When a client first approaches a WSD virtual address, it is directed to the server with the least number of sessions on it at that given time from this farm only (users of other farms to which the server belongs are not considered). 5. Least amount of traffic - local: When a client first approaches a WSD virtual address, it is directed to the server with the least amount of traffic on it at that given time from this farm only (users of other farms to which the server belongs are not considered). 6. private-1 and private-2: Allows the WSD to monitor SNMP parameters on farm servers that have an SNMP agent running on them. These SNMP variables need to be configured under WSD Load Balancing Algorithms Private Parameters. During farm creation, the Dispatch Method parameter determines which of the above algorithms are used. Server Weights If the load balancing algorithm (dispatch method) used is anything other than cyclic a weight (or priority) can be assigned to each of the servers in a server farm. Weights operate as ratios. In the least number of users mode, the weights determine the ratio 5

of the number of users between the servers. If the least amount of traffic mode is used, then the weights determine the ratio of the amount of traffic between the servers. For example, if in Figure 1, clients are approaching the 145.145.1.1 farm of the WSD and the weight of server 145.145.100.100 is 5 and the weight of server 145.145.200.200 is 3, then the following table might show a general distribution of clients if the load balancing algorithm used is least number of users : Server weight # of clients/total=8 # of clients/total=80 # of clients/total=1600 145.145.100.100 5 5 50 1000 145.145.200.200 3 3 30 600 Table 2 Servers configured with the same weight, no matter what value, will be load balanced equally. If all servers in a farm are configured with a value of 10, they will all receive the same amount of traffic. When servers are being added to the server table of a farm, the Weight parameter determines the server s weight. A server can be configured with a Weight of 1-10. Server connection limit This feature is new to software version 4.30 of the WSD. The parameter allows the administrator to configure the maximum number of users a server is allowed to receive. The number of users is determined by the number of active entries in the client table of the WSD for this server. When setting this limit, the mode with which the client tables are operating needs to be taken into consideration. For a detailed description of the client table modes refer to RADWare Technical Application Note 1020: Client Table Management in the WSD. For example, if in the network depicted by Figure 1, server 145.145.100.100 in farm 145.145.1.1 is configured with a limit of 200, then the WSD will only allow 200 client table entries to be made for server 145.145.1.1 in this farm. Once the limit of 200 is reached, traps are generated by the WSD indicating the fact that the server limit has been reached. Connection limits can also be configured per physical server. See section below for further discussion. When servers are being added to the server table of a farm, the Server Connection Limit parameter determines the maximum number of client table entries for this server in this farm. If configured to 0, this mechanism is disabled for this server and there is no user number limit. 6

Physical server management The WSD also has the ability to manage physical servers. A physical server is defined by the server name. As shown in Table 1, in conjunction with Figure 1, different IP addresses on the same physical unit are referenced with the same server name. For example, server 145.145.100.100 in farm 145.145.1.1 and server 145.145.100.101 in farm 145.145.2.2 both share server name Larry. In essence, server Larry is known to the WSD as a collection of all the server IP addresses configured with server name Larry. 3 parameters are available for configuration per physical server: 1. Recovery time: This parameters defines a time in seconds. When a server s operational status is changed from inactive to active (dynamically or administratively), the server is not eligible to receive clients for this period of time. This applies to all servers in all farms who share the same server name, denoting the same physical machine. Once this time is reached, the server becomes eligible for receiving clients requests. If set to 0, the server is eligible immediately after changing operational status from inactive to active. 2. Warm up time: This parameter also defines a time in seconds and allows a gradual activation of a server. Once a server is deemed eligible for client requests, it s weight (or priority) is gradually raised for this period of time, at the end of which the server s weight will be the pre-configured weight. If set to 0, the server will have no gradual activation and will be at full weight upon a change in operational status from inactive to active. If set to 10, a server's weight will be incremented proportionally (starting at 1) over the Warm up time until it reaches 10. 3. Connection limit: Configured as a number of users, this parameter is similar to the Server Connection Limit mentioned above. However, this parameter defines a limit for a physical machine. Like before, the number of users is defined by the number of active client table entries in to all IP addresses on this physical server. If set to 0, this mechanism is disabled for this physical server and there is no user number limit. If the server is a member of multiple farms, using the same "Server Name" for that machine in each farm will allow the WSD to limit connections to that server from all farms to which it belongs. In the WSD-> Physical screen, all physical servers are listed with each of the above 3 parameters set to a default value of 0 (disabled). Parameter values can be changed per physical server. Conclusion The WSD allows maximum flexibility for server management enabling an administrator to have full control over traffic levels, activity, utilization, and maintenance of the servers. The following points can be made in conclusion: 7

1. When configuring connection limits, the client table mode with which the WSD is operating is essential to take in to consideration. 2. Connection limits can be used as a server-failure-prevention mechanism in case of hacker attacks, such as SYN attacks. Such violations are usually established by many successive and incomplete TCP sessions opening to the servers from random and invalid clients. If allowed to continue, the servers would allocate all resources for these invalid sessions and stop servicing valid ones. WSD limits allow an upper limit to be set on such bursts, causing the server status to be more controlled and manageable. 3. Server weights are not valid in cyclic operation. 8