JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.

ORG

107

A probing algorithm with Adaptive Workload Load Balancing capabilities for heterogeneous clusters
S. Kontogiannis and A. Karakos
AbstractThis paper presents an adaptive load balancing algorithm, called AWLB for cluster based web systems. This algorithm maintains agents both at the web cluster and web servers in order to adapt its balancing decisions accordingly. AWLB algorithm also maintains its own protocol specification for signalling purposes among web switch and cluster nodes and al so utilizes other protocols such as SNMP and ICMP for its balancing process. Performance gains are shown from tests of AWLB against known balancing Least Connections (LC) and Least Loaded (LL) algorithms used by web-farms. Finally, CPU performance tests at the web switch show both advantages and drawbacks of complicated but accurate adaptive decisions over less accurate but misbalancing policies. Index TermsCloud computing, distributed web systems, load balancing algorithms, web clusters.

1 INTRODUCTION
eb based applications demands and increasing usage of HTTP services, lead to the building of more efficient web servers. Emerging web 2.0 technologies and tools, like Google development toolkit, content managers platforms (CMS), social (facebook, twitter), ehealth, e-learning (Learning Management Systems) and egovernment (electronic elections, citizen services) web services, are mature indications that the WWW and specifically HTTP is definitely becoming the most excessive form of traffic for routers. That of course in turn causes a geometrical increase of web server performance efforts to come over the following years. A commonly used technique for increasing web server performance is via distributed load balancing web architectures, such as Cluster-based web systems (or web clusters), where a centralised point of connection exists for serving incoming HTTP requests, called web switch [1]. Cluster-based systems routing methods are divided into content aware (layer 7) and non-content aware (layer 4). Balancing systems that use layer 7 routing are mainly proxy servers or application gateway systems [2, 3, 4]. Such systems redirect requests at application layer causing requests to traverse the entire protocol stack and thus limit their performance potential as number of requests increase. Usually such systems try to moderate degradation of cluster performance by limiting the number of

users that request service, or with the use of caching techniques at the web switch. Layer 4 routing mechanisms redirect connections based on less sophisticated balancing algorithms, which are unaware of session or application layer attributes. Routing mechanisms used in a non content aware web switch are the following: Distributed packet rewriting (Direct Routing) [5], IP network address translation (NAT), Packet tunnelling and Link layer packet forwarding (also referred to as MAC address translation) [6, 7]. In this paper we focus on cluster based system balancing algorithms that use Layer 4 NAT routing mechanisms. We categorize load balancing algorithms used of a web switch into four distinct categories: 1. Stateless non adaptive, 2. state full non adaptive, 3. stateless/state full adaptive algorithms and 4. content aware algorithms. As state full/stateless algorithms, we characterise those algorithms that keep track or not of client connection requests. As adaptive/non adaptive, we characterize those algorithms that take into account web server status metrics feedback and adapt their behaviour based on metric transitions accordingly, while content aware algorithms extend adaptive algorithms potential by also investigating HTTP requests header information and/or HTTP requests payload size (content length) for balancing decisions. In this paper we focus on adaptive balancing policies.

2 ADAPTIVE-NON ADAPTIVE LOAD BALANCING S. Kontogiannis is with the Electical and Computer Eng. Department, Democritus University of Thrace, University Campus Kimmeria, Xanthi, ALGORITHMS FOR CLUSTER BASED SYSTEMS 67100, Greece. A. Karakos is with the Electical and Computer Eng. Department, Democri- Non-adaptive algorithms put to test in this paper keep track tus University of Thrace, University Campus Kimmeria, Xanthi, 67100, of client connections at the web switch. Main representatives Greece.
of this category are Least Connections, Weighted Least Con-

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

108

nections (LC-WLC) algorithms [8, 9]. Adaptive balancing algorithms take into account web server state metrics but do not keep track of connection state information. These algorithms use monitor agents running on either the web switch or web servers. The information retrieved from agent lookups is taken into account in order to determine balancing weights. Some commonly used metrics are: CPU load, memory usage, disk usage, current process number and ICMP requestreply time. Adaptive algorithms weight calculation formulas are based on augmentation of web server metric values followed by normalization process. That is, a linear aggregate in terms of summation of metric values load
Wi = W0 + 1

value
Agg load i

as: Agg

load i

= Ki SM ik ,where:
i =1

, is the aggregate load calculated

i

Agg load i
=1

weight per web server and

SM ik are the web server met-

rics used [7, 1, 8]. Moreover, also non linear weight calculation processes may be applicable, such as the following formula used by Linux load balancer to calculate web server weights: W = i

tion, two sided Quartile-Weighted Median (QWM) [12, 13] and Linux local director weight calculation function [10] can also be used by web servers for load prediction and in some cases perform better than linear trackers do (more responsive to load incidents). Examples of adaptive algorithms follow. An example algorithm called Least Loaded (LLLLoad) uses a CPU utilization metric value of web servers stored by SNMP agents to the SNMP manager instantiated at the web switch [7, 10, 8]. ALBL (Adaptive Load Balancing Algorithm) [14, 15, 16], uses two metrics to adjust web server weights. These metrics are: HTTP response time (estimation of web server processing capability of a random process executed at the web server) and network delay (queuing delay of packets that traverse the cluster) metrics. Statefull adaptive algorithms use both adaptive algorithm metrics and client flow state information such as: Number of connections or ratio of connections that a server has received to the average connections received at a specific time interval [11, 9], source or destination IP address (locality aware based [17, 8]).

W0
3

1 Agg load i

[10, 11, 9].

3 AWLB ALGORITHM
We present a new workload balancing algorithm called Adaptive Work Load Balancing (AWLB) that tries to predict processing capabilities of a distributed cluster of heterogeneous web server nodes. This is achieved with the use of agents that instantiate both at the web switch and slave nodes of the web cluster. Agents communicate with each other with the use of a WorkLoad Balancing (WLB) protocol and exchange information regarding node status and link conditions between web switch and web servers. Then based on previous information, estimation weight per web server node is calculated at the web switch at predefined time intervals. These weights determine the part of the designated workload effort that should be assigned to a specific web server of the distributed system. In section 3.1, AWLB algorithm metrics are presented, in 3.2 the WLB protocol specification is presented and AWLB weight calculation process for balancing decisions is described in detail, in section 3.3 .

moving average: SMA( Sn(t )) = j i

Moreover, adaptive algorithms offer load predictions based on system (web server) resource metrics called load trackers and systems that try to predict web servers behaviour based on load tracker results called load predictors. Usually, both trackers and predictors do not operate on the same system due to performance issues. Load trackers are divided to: 1. Linear trackers, that use formulas such as simple
Mj

, or exponential moving or simple

average: EMA( Sn (ti )) = a Sn + (1 a ) EMA( Sn (ti 1 )) ,

moving median (SMA). Autoregressive models (AR) are also considered as linear tracker functions, since they use linear functions to calculate weights from metric values. AR model is a linear combination of the past k resource metric values represented as a vector. An AR load tracker weight value over time is calculated as: AR( Sk (ti )) = a1 St + ... + a k St + e(t ) , where e(t) is a
i i k 1

distribution sequence of difference or deviation of metric values, called residuals sequence. Furthermore, ARIMA models (Autoregressive Integrated Moving Average) [12, 13] are obtained by the AR model and the moving average model as a linear combination of the past metric values and q noise terms of the calculated metrics. Based on tracked data measures over a time period, residual and differential measured data values are calculated and weight values are predicted. 2. Non linear load trackers, such as cubic spline func-

3.1 AWLB Algorithm metrics AWLB algorithm uses agents that probe web cluster nodes periodically. Metric values derived from this probing process are used for weight calculation and therefore for balancing decisions of the web switch. Metrics used by AWLB are: network delay and response time. Calculation of previous metrics values is performed by the web switch during WLB registration and verification states. Another metric used is the processing effort metric that is calculated by the web servers and metric values are an-

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

109

nounced to the web switch during WLB protocol heartbeat state periods. Furhter analysis of metrics used by AWLB algorithm is presented in the following paragraphs Network delay metric is calculated as follows: The web switch sends ICMP echo-request messages to each one of the verified web servers that comprise the distributed cluster and waits for an ICMP echo-reply message. The time difference between request and reply equals to the response time metric value. This time difference is an approximation of propagation and queuing delay at the network path between the web switch and the web server. Network delay metric is a good approximation of network delay of a small size packet that traverses the network path from the web switch to each one of the registered web nodes, if the node is not overloaded. Network Re Re delay equals to: Ndelay = QPr op + Qn quest + Qn ply = RTTi , where

ters that are dependable only on node operating system and hardware. This is, CPU processing ability (C CPU ), memory capacity (size of computers physical and virtual memory C MEM ) and maximum I/O disk access time for read write processes accordingly ( I / O , I / O ). For hard drives, disk access time is determined as the sum of the spin-up time, seek time, rotational delay, and transfer time. Dynamic performance parameters are highly dependable parameters to the workload effort that the web server system achieved or is set to achieve. In this paper we selected the following dynamic performance parameters for the AWLB processing effort metric calculation process: 1. Processor/s utilization ratio (U CPU ): This is the CPU average aggregated user and system load measured as the number of CPU NOPs for a dt time period. Percentage of the system utilization for the respective period. 2. Memory utilization ratio (U MEM ): The size of the node memory (physical) used over the systems physical memory plus the size of the virtual memory used over the
1+ ( ) U ( MEM ) CVMEM CMEM

C max C min

RTTi is the round trip time of ICMP request-ICMP

Pr op is under the reply messages. Propagation delay assumption that is the same for all distributed system link

U VMEM

paths and queuing delay:

Qn

Re quest + Re ply

is the sum of all

delays encountered by an ICMP packet from the time of its insertion into the network until the delivery to its destination. AWLB response time metric (Wresp i ) value is calculated during the WLB protocol registration phase, as described later at section 3.2. In detail, AWLB response time is the processing time t i , where i=1..n web server nodes, required by each one of the registered to the cluster web server nodes to perform a short term algorithmic calculation by using an O(n) algorithmic process and return the calculated results to the web switch. If such results are send back and verified as correct by the web switch, only then, the AWLB response time metric is set as accurate. In case of partial or no data response packet, then a penalty value of [0-1] is set, depending on how successful or not the partial calculation is (0 no calculation data returned while 1 all returned calculated data were verified successfully by the web switch). This penalty value is then multiplied to the previous WLB request-reply time difference in order to provide a more accurate calculation of AWLB response time metric value. AWLB response time metric values are also calculated at predefined of the distributed workload algorithm checkpoints or on demand checkpoints signalled by the network administrator. AWLB processing effort metric values are calculated at periodic T p time intervals, where T p is statically set by the administrator at least 10 times more of the maximum estimated web server node clock granularity. AWLB processing effort metric is a vector of five web server performance parameters (static or dynamic). As Static performance parameters we characterise changeless parame-

of transmitted data, goodput of received data (data without protocol overhead or retransmission efforts) and retransmission efforts of TCP retransmission packets over a dt time interval. MTU is the maximum transfer unit of the network interface as set for the dt time interval. 4. Disk I/O utilization parameter (U I/O ) is calculated by using the following disk I/O metric values: Await time (Aw(t)): The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them. Service time (Sv(t)): The average service time (in milliseconds) for I/O requests that were issued to the device. This value is an indication of whether I/O device is performing roughly as expected by the I/O disc access time metric. Read req m/s (Rr): Read requests merged per second queued for the I/O device. Write req m/s (Rw): Write requests merged per second queued for the I/O device. Based on previous I/O parameters I/O utilization parameter is calculated using the following formula:

systems virtual memory: . 3. Network flux (N f ): In terms of data transmitted and received by the web server system active network interRTRIF * MTU ThrIF + Goodput IF + dt faces: .That is, throughput

U I /O =

Aw(t ) ( Rr + Rw) Sv(t ) . This utilization parameter

metric is an indication of the I/O operations (read or

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

110

write) to be served by the medium queue. Previous metric values form the WLB processing efSlave Web switch fort metric vector and are send to the web switch using an Node SNMP set message to the web switch manager followed by an SNMP notification message to the SNMP manager (heartbeat state of the WLB protocol). Fig.1 Registration Handshake process of the WLB protocol between 5. Active connections (C i ): The number of assigned ac- web switch and web server nodes. tive connections serviced currently by that web server.
Registration Request Register Reply

3.2 WLB Protocol specification MSG PROTO_ID MSG LEN TYPE Algo Client ID HB Period Payload WorkLoad Balancing (WLB) protocol uses a connection4 Bytes 4 Byte 2 Bytes 2 Bytes 4 Bytes 4 Byte less UDP datagram based schema of three distinct states of operation. These states are the following: Registration state: This state involves a registration process Fig.2 Registration request and reply message header format. of the available to commit to cluster web server nodes. nodes. The web server node captures the WLB registraRegistration phase is performed with a datagram handshake between the web switch and each on of the web tion packet, decodes calculation algorithm and payload server nodes as depicted at Fig. 1. Registration request data and starts the calculation process. After completion of the calculation process, the node and reply messages contain the following fields in their constructs a registration reply packet containing the data header as shown at Fig. 2: Protocol ID: This is the value 0x01 of the WLB proto- of the calculation process results and sends it back to the col registration phase. web switch. After the reception of the registration reply Msg Len: The length of the packet payload data send packet the web switch calculates for each one of the web to the web server node or received at the web switch. servers that replied the initial AWLB response time met Msg Type: 0x00 for request, 0x01 for reply and 0x02 ric value, as the time difference between registration refor request for registration packet. quest and registration reply received at the web switch. In Algorithm used: The algorithm used for calculation case of successful registration of a web server node, that of the initial AWLB response metric value. That is a se- node is added to the available load balancing nodes and lection of 3 algorithms. Prime number generation (no thus for that node a periodic weight calculation process payload data reception-0x01), Bubble shorting algo- shall infer. rithm (non sorted data reception-0x02) and adjoint Verification state: After successful completion of the matrix calculation (matrix data reception-0x03). registration state, verification state occurs. The web Client ID: This is the web server node number that switch during registration state performs the initial calcuidentifies the node and is set incrementally from the lation send as a request message to all web servers and web switch. verifies either the registration reply packet payload re Heart Beat Period: This is a time frame period in sults or the portion of the correct results received from seconds, which both web switch and web server web server nodes. In case of no calculation performed or nodes negotiate during registration handshake state. partial calculation a penalty value is set to 1 (100%) or to Then as selected heartbeat period T H is portion of the performed accurate calculations accordSW Node ingly [0-1). Then calculation of the initial network delay the min(TH , TH ) . Payload: Data send by the web switch and processed metric is performed by the web switch. An appropriate data received at the web switch based on algorithm probing timeout is set for ICMP messaging. The timeout and data requests send from switch to web server value can be modified according to network topology and the maximum expected latency of the distributed system. nodes. Registration phase is performed as follows: At first, If timeout occurs then node is removed from the workthe web switch sends a registration request packet to all load balancing process until the next on demand registraknown web server nodes (such knowledge is based either tion state. Network delay metric calculation is also peron static configuration or dynamically, by sending re- formed for both web servers with no data reply or partial quests to all web server nodes with a functional web ser- data reply messages. Heartbeat state: WLB protocol heartbeat state is a perivice, under existing registered subnets). Appropriate odic state repeated every T H sec for every node accordtimer is set by the web switch in case a timeout of the registration state occurs. RTO WLB timeout values are set to 2- ingly. In this state each slave node sends to the web 3s. Registration request packet includes the calculation switch an informatory heartbeat packet in terms of an algorithm and payload data for a short calculation proc- SNMP notification message (UDP packet send to SNMP ess that shall be performed by each one of the web server manager instantiated at the web switch-port 161). In or-

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

111

der to protect web servers burst heartbeat packets data integrity from DoS and impersonation attacks, heartbeat SNMP v3 notification messages support both authentication (SHA/MD5) and encryption-verification (DES/AES) [18, 19] may be applicable. In our case these methods are supported by the WLB protocol, using MD5 authentication digests and 128bit 3-DES algorithm for the encryption process of the heartbeat authentication messages. Moreover, we used a static username that matches the community string private and authentication and digest passwords (auth pass = digest pass) that are calculated from an MD5 hash process over the web server IP address, Client ID and payload data included in the registration request packet of the WLB registration state. For simplification of the AWLB weight calculation process, WLB protocol maintains an MIB structure under the web switch SNMP manager MIB SMI tree. This structure is under the internet.experimental MIB tree (1.3.6.1.3.x.0/1/2.), where x=0..n-1, where n is the number of verified web servers after the WLB registration and verification phase. As leaves of each web server node MIB branch (x.0, x.0/1/2.0, x.0/1/2.1, x.0/1/2.2, x.0/1/2.3) are the five sub metrics that comprise the WLB processing effort vector (U CPU, U MEM, N f , U I/O, C i ). All values per web server of the WLB processing effort vector values are send by the web servers using SNMP set operations on 1.3.6.1.3.x.0.0-3 OIDs of the MIB tree, where x.0 represents per web server current AWLB processing effort vector values, while x.1 represents minimum AWLB processing effort vector values and x.2 maximum AWLB processing effort vector values per web server. Min-max values of AWLB processing effort metric are calculated by the web switch every time a heartbeat notification message arrives at the web switch. At the end of every heartbeat period, AWLB weight calculation process occurs. Based on these web server weights on the next load balancing period T WLB requests are assigned to web server in a WRR manner based on AWLB weight calculation process. If a web server does not send a heartbeat message during a heartbeat period then this web server is removed from the following period weight calculation process. If this web server insists on not updating its heartbeat value for 3 consecutive load balancing periods, then WLB registration phase restarts for that web server. If registration fails then that web server is removed from the balancing process. Request for Registration state: A web server can be added to the web server farm (web server cloud) at any time by sending a Request for Registration packet at the web switch. This packet header has the same format with registration request packet as depicted at Fig. 2 and includes only Proto_Id, MSG_LEN, and Client ID fields, where protocol id is 0x02, Client id is set to 0x00. When a request for registration is received at the web switch then

WLB protocol initiates the WLB initial registration state for that web server.

3.3 AWLB Weight Calculation Before analyzing how AWLB weight calculation is performed, we define the work load balancing period T WLB. This is a period where requests are assigned to each one of the registered web servers (web servers that belong to the web server cloud) in a round robbin manner. For ALBL (Adaptive Load BaLancing algorithm) [14, 15, 16], this balancing period is a time interval that is divided to the web servers using TDM (Time Division Multiplexing). That is web servers are randomly selected to balance for each period regardless of the weight values assigned to each one accordingly. AWLB algorithm uses the same random selection schema but not over time but over requests (CDM connection division multiplexing). Moreover, AWLB does not use a static period of requests but an adaptive one based on min and max per web server weight deviation values. The first load balancing period is statically set to 10-50 requests. During the time interval that these requests are serviced, at least two WLB heartbeat states pass and thus weight calculation process occurs at least twice in order for the system to acquire minimum and maximum weight values per web server. Then an index value called Exponential Step (ES) is calculated. That is, for i=1..n web servers registered to the cloud and min i , max i the maximum and minimum weight values per web server, ES calculation is as follows:

ES =

max(min i ), if min i 0 min(max i ), min(max i ) max(min i )

(1)

Where as min(max i ) is the selected the value that min(max i )max(min i ). If min(max i )~max(min i ), then the ES=1 and the next exponential step equals to 2Previous ES value. That is the load balancing period increases in exponential manner. If min(max i )<max(min i ), then ES is between [0.5-0.9]. In that case a multiplicative balancing period decrease is performed of Previous ES value. If min(max i )<<max(min i ), then slow start is performed to the initial set load balancing period. In every case a load balancing period cannot fall to less that 10 requests, because in high burstiness request conditions, 10 serviced requests time interval is close to web servers clock granularity (of the heartbeat time interval). ES index value is based on the following assumption. If the web server cloud is homogenous and the requests are received at the web switch at a constant rate then a large balancing period is needed. If the web server cloud is highly heterogeneous and received requests follow exponential distribution then a smaller balancing period is needed with frequent alteration of the CDM balancing process. AWLB weight calculation process is similar to ALBL algorithm weight calculation process [16]. ALBL algo-

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

112

rithm uses agents that probe web servers of a web server farm periodically. Metric values of HTTP response time and network delay, derived from that probing process are used for weight calculation and therefore for balancing decisions at the web switch. Similarly AWLB load balancing algorithm uses previously mentioned metrics of AWLB response time, AWLB network delay and AWLB processing effort vector. AWLB load balancing weight is a vector value that tries to express three distinct attributes: link path network delay, in terms of AWLB network delay metric (N d ), processing capability (C p ), hard disc access time capability (C H ) and network flux (N f ). Processing capability of each web server is calculated based on equation 2, while access time capability is calculated using equation 3.

Ci Ci ' Wi = 1 n p , 2 n H , 3 i i CH Cp i =1 i=1
3. 4. calculates as: Final

Nfi , Ci 4 Ndi n Nf Ci i =1 i

(5)

The final weight calculation metric value wi is

wi = [Wi ' ]

normalization

process

occurs

as:

wi' =

wi

wi i
=1

C p = Wrespi (

U CPUi max(U CPU j

=1.. n

U MEMi max(U MEM j

=1.. n

)
(2)

Based on these values, incoming connections are redirected to the appropriate target server in a random manner (servicing server is selected randomly from the pool and its selection is not dependent on the weight value score) for the balancing period in a CDM manner.

(3) Where W respi is the per web server response time value calculated dusing WLB resistration state and C i the number of connections that are currently active on that web server. Based on equations (2), (3) the AWLB weight load balancing vector is shown at equation (4):

U CH = I / O Ci

4 TESTBED SCENARIOS
For our work case scenarios, we used a web cluster of 4 web servers of equivalent processing power and web content, connected to a 100Mbit web switch. Apache version 2.2 is the web server software and the default prefork model MPM is used as processing model for HTTP requests. We performed our cluster tests with Apachebench, a set of Perl scripts designed to support the automation of benchmarking with httperf tool [20]. The web switch is a Pentium IV computer with a CPU that operates at 3.2GHz and 2GB of memory. The operating system of the web switch is a Linux monolithic kernel operating system. Our AWLB algorithm uses Linux netfilter NAT (Network Address Translation routing mechanism) [21] as the routing process and a set of threaded Perl agents for the collection of metric values and implementation of AWLB, WLB protocol and other testbed algorithms. For each experimental scenario we used a cluster of 24 Dual Core Pentium (2.1GHz) clients that send HTTP requests to the 4 web servers of the web server farm (Scenario I/II and III). For scenarios I and III the 4 web server farm includes web servers of heterogeneous processing capabilities (see Table I). For scenario II the 4 web servers are of homogeneous capacities (4 web servers with Dual Core Pentium 2.1 CPU processors) but heterogeneous links. For each test bed performance scenario we used the following performance metrics: -Average Throughput, in terms of average web cluster response rate caused by an aggregate of HTTP client requests. That is the average throughput achieved by a bundle of
n

(4) AWLB algorithm weight calculation process based on vector W i metric values (where i=1..n the servers registered to the web server farm using WLB protocol) is performed as follows: 1. First calculation of n W i vectors is performed at the web switch 2. Then second stage normalization process occurs for the n W i vectors. That is all vector elements are individually multiplied with one of the four coefficient parameters ( 1 , 2 , 3 , 4 ), statically set by administrator. Coefficient parameter value of 1 ranges between 0.7-1, 2 and 3 values are both set to 0.5 while 4 is set to a value of 1 + 2 + 3 . These coefficient parameter values derived from experimentation and try to increase the effect of the first element of the balancing vector (AWLB response time metric), by decreasing by half the effect of network flux and by setting AWLB network delay metric to comparative values in respect to AWLB response time metric values. The new balancing vector W i that occurs is shown at equation (5)

Ci Wi = n p , Ci p i=1

Nfi , C Ci , n n Nf i CH C i i =1 i =1 i
i H

i Nd

fixed k requests per second: 1 n n i =1 quests are received. -Average Response time: We calculate total response time of an aggregate

n k Thrk , until n rek k =1

response time as the of k HTTP requests.

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

113

This value is then averaged until n HTTP requests are serviced by the web-switch. -system utilization metric (S U ): It is calculated using the following equation:

SU = a

U CPU U + (1 a) MEM , where U CPU ,is the % Ci Ci

Least Loaded (LL) and AWLB (Adaptive Workload Load Balancing). In experimental scenario III, we investigate performance of AWLB by putting to the test CPU processing efforts set by all previous balancing algorithms at the web switch.

average web switch CPU utilization over the number of successfully serviced requests C i (i=number of HTTP requests) and

U MEM

is the % average web system mem-

ory utilization over the number of successfully serviced requests. This metric is calculated at the web switch at predefined time intervals statically set at 30sec. Value of a is statically set to 0.75.

SU o , is the web switch utilization

initial value when no requests exist and is calculated using the following formula:

SU o = a

number of connections that shall be maintained according to the experimental scenario performed at the web switch. TABLE 1 W EB SERVER FARM CPU PROCECING POWER

U CPUo U + (1 a) MEMo , where N is the total N N

4.1 AWLB performance scenario I In this scenario we put to the test the performance of Least Connections (LC), LLoad (LL) and AWLB balancing algorithms under a case of a web server farm of heterogeneous capacities (see Table I). That is, web server 4 CPU is 1.5 times faster than web server 2, web server 1 CPU is 1.8 times faster than web server 4 CPU, while web server 3 CPU is 1.5 times faster than web server 1 CPU. HTTP clients send a CPU consuming HTTP GET request and wait for the processing result. This consuming CPU request includes a set of 100 sequential integer numbers between [a,b] (randomly chosen a,b), send to web farm to check whether are prime or not and then the reply includes only the total number of primes found (100250bytes object size) from the web cluster. Complexity of each operation equals to O(n2/ln(n)), where n is the total numbers checked for primarity. In depth, for a small n, runtime appears to be close to O(n), while for a large n close to O(n2). Experimental scenario is initially performed at rate of 20 HTTP requests per second until a total number of 120,000 HTTP requests is reached and then the same experiment is repeated each time with a contention increase of 20 requests per second. We also set the client request timeout value to 10 seconds and set a large value for web server HTTP timeout in order to minimize HTTP request timeout events. As seen at Fig. 3, LC algorithm fails to balance among the heterogeneous web servers as contention in terms of response time per bulk of requests (equal to request rate) as request rate increases. This failure is presented as an

sw The ratio of: % PPr oc Effort =

SU SUo , gives as the % procSUo

essing effort of each algorithm at the web switch per contention increase of the requests rate. -Dropped Requests metric (Dr i ): This is the % number of total dropped requests due to request timeout or web server connection failed cases over the total number of requests send by the client cloud. In our test bed experimental scenarios I and II we investigate performance and web switch utilization of the following balancing algorithms: Least Connections (LC),

Fig. 3. Scenario I, Average HTTP response time in msec of LC, LL and AWLB over contention increase of client req/sec, until a total of 120,000 HTTP connections per request rate.

average increase of the HTTP response time. This is of course because LC tries to spot heterogeneous conditions by looking at servicing requests per web server only. Such conditions are not easily discovered by the number

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

114

of under service requests sustained and thus delays are added to requests due to erroneous balancing decisions. LL (LLoad) algorithm performs better than LC due to its SNMP based CPU load metric probing mechanism. AWLB algorithm presents similar performance characteristics with LL for low contention increase cases (up to 260 req/sec) in terms of response time. From 260-400 req/sec AWLB outperforms LL. This is caused due to mainly two reasons. Firstly, AWLB uses a range of metrics that causes its web server status feedback to be more accurate than LL (that uses only CPU load metric). Secondly, AWLB has a better and more accurate probing mechanism (supported by the WLB protocol) than LL has (static probing mechanism of 30sec maximum granularity of the web servers agent SNMP set operations to the web switch SNMP manager). From Fig. 3 it is also obvious that for cases of saturation due to contention burstiness (400 req/sec) both algorithms perform almost the same (Both metric accuracy and fine grained probing mechanisms seem to contribute equally with a less accurate and less frequently probing mechanism as LL.

seconds in order to increase HTTP request drops (HTTP request timeout is by default set to 120s by web servers).

Fig. 4. Scenario II(a), Average Throughput in Kb/sec of LC, LL and AWLB over contention increase of client req/sec, until a total of 24,000 HTTP connections per request rate.

4.2 AWLB performance scenario II In this scenario we put to the test the performance of Least Connections (LC), LLoad (LL) and AWLB balancing algorithms under a case of a web server farm of heterogeTABLE 2 W EB SERVER FARM TBF DOWN LINK DELAY

neous network links. This is of course due to either limited network resources or congested network link paths. In order to achieve a congested link, we shape the traffic that passes through each one of the web servers, using a Token Bucket Filter (TBF queuing discipline) [22, 23, 21]. This queuing discipline limits only the down-link bandwidth of the web server at different rates and adds extra latency in terms of queuing delay to packets that traverse from web servers via the web switch. Such delay is presented at Table II for our 100Mbit max network links capability and 10msec Linux OS granularity. HTTP clients request 2Kb of random objects from the web cluster. This operation is initially performed at rate of 20 HTTP requests per second and then the same experiment is repeated, each time with a contention increase of 20 requests per second until a total number of 24,000 HTTP requests is reached. In this scenario we use a total of 24,000 connections instead of 120,000 due to BW limitations set. We also set the client request timeout value to 5

Fig. 5. Scenario II(b), Total number of dropped/timeout requests of LC, LL and AWLB (dropped requests metric %Dr i ) over contention increase of client req/sec, until a total of 24,000 HTTP connections per request rate.

From this scenario results, depicted at Fig. 4, LC algorithm presents worse performance characteristics than LL (LLoad) and AWLB in terms of average throughput achieved per bulk of requests (equal to requests rate). This failure is denoted also at Fig. 5, where the total number of dropped requests per request rate contention increases dramatically up to 10% of the total number of connection requested from the client cloud. LL algorithm performance in terms of throughput is better than LC but worse than AWLB is. LL algorithm based mainly on CPU load instances fail to predict cases of congested or network utilized link paths while adequate web server resources exist. This failure is much more clearly depicted at Fig. 5, where LL drops reach an average of 2.43% more request drops than AWLB algo-

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

115

rithm. From the other hand AWLB algorithm that takes into account network conditions with the use of network delay metric, manages to successfully detect several of the network delay changes in the cluster cloud. Despite the effort of both self timing probing mechanism and network delay metric indications of the AWLB algorithm, still it does not perform as adequately as expected. This is due the existence of an average of 0.87% drops over the total number of requests, which indicates that the algorithm is fairly better than other examined algorithms, but still there is a window for improvement. It is suspected by authors that possible reason for this mis-predictive behaviour is caused due to the important effect of web server load metric values over network delay metric value at the weight calculation process. Further investigation of this behaviour is set as future work.

4.3 AWLB performance scenario III In this scenario we put to the test LC, LL (LLoad), and AWLB algorithms in order to check algorithms effort requirements at the web switch and raise a pre-mature conclusion regarding AWLB algorithm scalability. This case scenario includes of a web server farm of heterogeneous capacities (see Table I). That is, web server 4 CPU is 1.5 times faster than web server 2, web server 1 CPU is 1.8 times faster than web server 4 CPU, while web server 3 CPU is 1.5 times faster than web server 1 CPU. Scenario operations are performed at rates that escalate from 20 HTTP till 400 HTTP requests per second and 1Kb size random object requests. Fig. 6, shows additive processing effort of LC, LL(LLoad) and AWLB algorithms at the web switch in terms of the % percentage of the initial state utilization of the web switch system. LC algorithm added utilization is close to 11% of the web switch system initial utilization for slow contention increase request rates. As contention increases LC utilization follows an exponential curve, until 400 req/sec, where it nearly stabilizes to 29% of the web switch initial state utilization. LL and AWLB follow more or less a logarithmic curve of processing effort for LL algorithm from 20% for 40 req/sec until 39% for 400 req/sec and for AWLB algorithm from 23% up until 50% of initial utilization system state effort. These results, presented at Table 3, show the increased processing efforts of adaptive strategies over state full ones (up to 178% more processing effort in average). Results clearly indicate the compensation with processing effort of a frequent probing-multi metric, with complicated weight calculation process followed by protocol support of AWLB algorithm over a single metric with less complex calculation process and no protocol support such as LL algorithm. This is shown at Table 3, with an average addition of 14.5% of processing effort using AWLB instead of LL.

Fig. 6. Scenario III, % Processing effort of LC, LL and AWLB algorithms (in terms of System Utilization metric SU) over incoming connections request rate at the web switch.

TABLE 3 AVERAGE % MORE CPU EFFORT OF AWLB ALGORITHM OVER LL AND LC

CONCLUSION

In this paper we present AWLB balancing algorithm for cluster based web systems. AWLB main characteristic is that takes into account web servers load metrics as well as network conditions for its balancing process. It also maintains its own communication protocol (WLB protocol) supported by states and FSM logic for signalling purposes and in order to distinguish and apply different balancing policies over web server load or lack of network resources accordingly . We compare performance of AWLB algorithm against statefull LC and adaptive LL algorithms. From the experimental results we show that AWLB outperforms conventional state full and adaptive balancing algorithms. In particular, AWLB balances efficiently HTTP traffic under unbalanced conditions that dynamically change in cases such as: (a) Due to web server heterogeneous and limited computational resources and (b) due to heterogeneous utilized network resources or congestion incidents. Finally, we show with performance measurements of LC and LL over AWLB, the significant performance gains that may occur from frequent probing multi-metric with

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 7, JULY 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ WWW.JOURNALOFCOMPUTING.ORG

116

complex but accurate calculation process algorithms such as AWLB that also tries to estimate network conditions and network congestion incidents. We also pinpoint the performance efforts at the web switch by the use of such algorithm and possible scalability issues that may occur. Further reduction of AWLB processing effort at the web switch is set for investigation and future work.

[22] B. Hubert, G. Maxwell, R. Van Mook, M. Van Oosterhout, P. Schroeder, J. J. Spaans, and P. Larroy, Linux Advanced Routing and Traffic Control HOWTO, http://www.tldp.org/HOWTO/Adv-RoutingHOWTO, 2004. [23] E. Magana, E. Izkue, and J. Villadangos, Review of traffic scheduler features on general purpose platforms, in Proc. of SIGCOMM Workshop on Data communication in Latin America and the Caribbean, 2001, pp. 5079. Sotirios Kontogianns is a P hD candidate student at the Dept. of Electrical and C omputer Eng., Democritus University of Thrace, Xanthi, Greece. He received a f ive-year Eng. diploma and M Sc in Software Eng. from Department of Electrical and Computer Eng., Democritus University of Thrace. His research interests are in the areas of Distributed systems, computer networks, middlware protocol design, computer networks protocol testing and computer networks performance evaluation. His e-mail is: skontog at ee.duth.gr. Alexandros Karakos received the Degree of Mathematician from the Department of Mathematics from Aristoteles University of Thessaloniki, Greece and the Maitrise d' Informatique from the university PIERRE ET MARIE CURIE, Paris. He completed his PhD studies at university PIERRE ET MARIE. He is Assistant Professor at the Dept. of Electrical and C omputer Eng., Democritus University of Thrace, Greece. His research interests are in the areas of Distributed systems, data analysis and pr ogramming languages. His e-mail is: karakos at ee.duth.gr.

REFERENCES
[1] V. Cardellini, E. Casalicchio, M. Colajanni, and P. S. Yu, The State of the Art in Locally Distributed Web-Server Systems, ACM Computing Surveys, vol. 34, no. 2, pp. 263311, 2002. [2] CISCO, Distributed Director, http://www.cisco.com/warp/public/cc/pd/cxsr/dd/, 2004. [3] SQUID, web proxy cache, http://www.squid-cache.org, 1995. [4] D. Wessels and K. Claffy, Internet Cache Protocol (ICP) version 2, RFC 2186, 1997. [5] L. Aversa and A. Bestavros, Load Balancing a Cluster of Web servers using Distributed Packet Rewriting, in Proc. of IEEE International Performance, Computing and Communications conference, 2000, pp. 24 29. [6] M. Colajanni, P. S. Yu, and D. M. Dias, Analysis of task assignment policies in scalable distributed Web-server systems, IEEE Trans. on Parallel and Distributed Systems, vol. 9, pp. 585600, 1998. [7] V. Cardellini, M. Colajanni, and P. S. Yu, Dynamic load balancing on web server systems, IEEE Internet Computing, vol. 3, no. 3, pp. 2839, 1999. [8] CISCO, CISCO Services Modules - Understanding CSM Load Balancing Algorithms, http://www.cisco.com/warp/public/117/csm/lb_algorithms.pdf, 2007. [9] W. Zhang, Build highly-scalable and highly-available network services at low cost, Linux Magazine, vol. 3, pp. 2331, 2003. [10] D. Maltz and P. Bhagwat, Linux Director: a connection director fo scalable network services, Computer Science and Technology, vol. 15, no. 6, pp. 560 571, 2000. [11] P. ORourke and M. Keefe, Performance Evaluation of Linux Virtual Server, in Proc. of the 15th LISA System Administration Conference, 2001, pp. 7992. [12] M. Andreolini and S. Casolari, Load prediction models in webbased systems, in Proc. of the 1st international conference on Performance evaluation methodolgies and tools. ACM, 2006, p. 27. [13] M. Andreolini, S. Casolari, and M. Colajanni, Models and Framework for Supporting Runtime Decisions in Web-Based Systems, ACM Transactions on the Web., vol. 2, no. 3, pp. 1743, 2008. [14] A. Karakos, D. Patsas, A. Bornea, and S. Kontogiannis, Balancing HTTP traffic using dynamically updated weights, an implementation approach, in Proc. of the 10th Panhellenic Conference on Informatics, 2005, pp. 873878. [15] S. Kontogiannis, S. Valsamidis, P. Efraimidis, and A. Karakos, Probing based load balancing for web server farms, in Proc. of the 13th Panhellenic Conference on Informatics, 2009, pp. 175180. [16] S. Kontogiannis, S. Valsamidis, and A. Karakos, ALBL, ALBL/HSC algorithms: Towards more scalable, more adaptive and fully utilized balancing systems, Journal of Computing, vol. 3, no. 2, pp. 4 19, 2011. [17] V. Cardellini, M. Colajanni, and P. S. Yu, Geographic load balancing for scalable distributed Web systems, in Proc. of the 8th International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, 2000, pp. 2028. [18] D. Harrington, R. Presuhn, and B. Wijnen, An architecture for describing simple network management protocol (snmp) management frameworks, United States, Tech. Rep., 2002. [19] U. Blumenthal and B. Wijnen, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), Lucent Technologies, RFC 3414, Dec. 2002. [20] D. Mosberger and T. Jin, A Tool for Measuring Web Server Performance, in Proc. of ACM Workshop on Internet Server Performance. ACM, 1998, pp. 5967. [21] Netfilter, Linux Netfilter Project, http://www.netfilter.org, 2000.