Load Balancing Predictors in Distributed Cloud Computing Systems

Transcription

1 130 Load Balancing Predictors in Distributed Cloud Computing Systems K. Meenakumari Assistant Professor, Department of MCA, New Horizon College of Engineering, Bangalore ABSTRACT Cloud computing is an on demand service in which shared resources, information, software and other devices are provided according to the clients requirement at specific time. It is a term which is generally used in case of Internet. The whole Internet can be viewed as a cloud. Capital and operational costs can be cut using cloud computing. Load balancing in cloud computing systems is really a challenge now. Always a distributed solution is required. Because it is not always practically feasible or cost efficient to maintain one or more idle services just as to fulfill the required demands. Jobs cannot be assigned to appropriate servers and clients individually for efficient load balancing as cloud is a very complex structure and components are present throughout a wide spread area. Here some uncertainty is attached while jobs are assigned. This paper considers some of the methods of load balancing in large scale Cloud systems. In this paper we will review the various load balancing predictors which acts as a parameter in balancing the client load across various servers in a distributed server systems. Keywords Cloud, Dynamic Load Balancing, Least Local Session, Load Balancing Predictors, Multiple Real Servers, NAT Translation, ServerIron 1. INTRODUCTION In case of Cloud computing services can be used from diverse and widespread resources, rather than remote servers or local machines. There is no standard definition of Cloud computing. Generally it consists of a bunch of distributed servers known as masters, providing demanded services and resources to different clients known as clients in a network with scalability and reliability of datacenter. The distributed computers provide on-demand services. Services may be of software resources (e.g. Software as a Service, SaaS) or physical resources (e.g. Platform as a Service, PaaS) or hardware/infrastructure (e.g. Hardware as a Service, HaaS or Infrastructure as a Service, IaaS ). Amazon EC2 (Amazon Elastic Compute Cloud) is an example of cloud computing service. A Cloud system consists of 3 major components such as clients, datacenter, and distributed servers. Each element has a definite purpose and plays a specific role. Figure 1: Three components make up a cloud computing solution 1.1 TYPE OF CLOUDS CLIENTS End users interact with the clients to manage information related to the cloud. Clients generally fall into three categories, Mobile: Windows Mobile Smartphone, Smartphone like Blackberry or an iphone Thin: They don t do any computation work. They only display the information. Servers do all the works for them. Thin clients don t have any internal memory. Thick: These use different browsers like IE or mozilla Firefox or Google Chrome to connect to the Internet cloud. Now-a-days thin clients are more popular as compared to other clients because of their low price, security, low consumption of power, less noise, easily replaceable and repairable etc DATA CENTER Datacenter is nothing but a collection of servers hosting different applications. A end user connects to the datacenter to subscribe different applications. A datacenter may exist at a large distance from the clients. Now-a-days a concept called virtualization is used to install software that allows multiple instances of virtual server applications DISTRIBUTED SERVERS Distributed servers are the parts of a cloud which are present throughout the Internet hosting different applications. But while using the application from the

2 131 cloud, the user will feel that he is using this application from his own machine. 2. LOAD BALANCING 2.1 INTRODUCTION It is a process of reassigning the total load to the individual nodes of the collective system to make resource utilization effective and to improve the response time of the job, simultaneously removing a condition in which some of the nodes are over loaded while some others are under loaded. A load balancing algorithm which is dynamic in nature does not consider the previous state or behavior of the system, that is, it depends on the present behavior of the system. The important things to consider while developing such algorithm are, estimation of load, comparison of load, stability of different system, performance of system, interaction between the nodes, nature of work to be transferred, selecting of nodes etc.,. This load considered can be in terms of CPU load, amount of memory used, delay or Network load. 2.2 GOALS OF LOAD BALANCING To improve the performance substantially, to have a backup plan in case the system fails even partially, to maintain the system stability and to accommodate future modification in the system. 2.3 TYPES OF LOAD BALANCING ALGORITHMS Depending on who initiated the process, load balancing algorithms can be of three categories Sender Initiated - If the load balancing g algorithm is initialized by the sender Receiver Initiated - If the load balancing algorithm is initiated by the receiver Symmetric - It is the combination of both sender initiated and receiver initiated Depending on the current state of the system, load balancing algorithms can be divided into two categories. Static - It does not depend on the current state of the system. Prior knowledge of the system is needed Dynamic - Decisions on load balancing are based on current state of the system. No prior knowledge is needed. So it is better than static approach. 2.4 DYNAMIC LAOD BALANCING ALGORITHMS In a distributed system, dynamic load balancing can be done in two different ways, distributed and nondistributed. In the distributed one, the dynamic load balancing algorithm is executed by all nodes present in the system and the task of load balancing is shared among them. The interaction among nodes to achieve load balancing can take two forms, cooperative and noncooperative. In cooperative, the nodes work side-by-side to achieve a common objective, for example, to improve the overall response time, etc. In non-cooperative form, each node works independently toward a goal local to it, for example, to improve the response time of a local task. Dynamic load balancing algorithms of distributed nature, usually generate more messages than the nondistributed ones because, each of the nodes in the system needs to interact with every other node. A benefit, of this is that even if one or more nodes in the system fail, it will not cause the total load balancing process to halt, instead it would affect the system performance to some extent. Distributed dynamic load balancing can introduce immense stress on a system in which each node needs to interchange status information with every other node in the system. It is more advantageous when most of the nodes act individually with very few interactions with others. In non-distributed type, either one node or a group of nodes do the task of load balancing. In Non-distributed dynamic load balancing algorithms can take two forms: centralized and semi-distributed. In the centralized form, the load balancing algorithm is executed only by a single node in the whole system, the central node. This node is solely responsible for load balancing of the whole system. The other nodes interact only with the central node. In semi-distributed form, nodes of the system are partitioned into clusters, where the load balancing in each cluster is of centralized form. A central node is elected in each cluster by appropriate election technique which takes care of load balancing within that cluster. Hence, the load balancing of the whole system is done via the central nodes of each cluster. Centralized dynamic load balancing takes fewer messages to reach a decision, as the number of overall interactions in the system decreases drastically as compared to the semidistributed case. However, centralized algorithms can cause a bottleneck in the system at the central node and also the load balancing process is rendered useless once the central node crashes. Therefore, this algorithm is most suited for networks with small size. 2.5 POLICIES OF DYNAMIC LOAD BALANCING Transfer Policy: The part of the dynamic load balancing algorithm which selects a job for transferring from a local node to a remote node is referred to as Transfer policy or Transfer strategy.

3 132 Selection Policy: It specifies the processors involved in the load exchange (processor matching) Location Policy: The part of the load balancing algorithm which selects a destination node for a transferred task is referred to as location policy or Location strategy. Information Policy: The part of the dynamic load balancing algorithm responsible for collecting information about the nodes in the system is referred to as Information policy or Information strategy. ServerIron. All inquiries made to that Web site by users on the Internet or the company's Intranet use either the URL or virtual IP address to reach the company's Web site. Figure 3 Single Virtual IP Address Mapped to Multiple Real Servers Figure 2: Three components make up a cloud computing solution 3. DISTRIBUTED LOAD BALANCING FOR THE CLOUDS 3.1 SERVER LAOD BALANCING Server Load Balancing (SLB) is based on associations between real servers and virtual servers. The real servers are your application servers. The virtual servers have one or more Virtual IP addresses (VIPs). You associate a real server with a virtual server by binding TCP/UDP ports on the real servers with TCP/UDP ports on the virtual server. When a client sends a TCP/UDP request for a port on the virtual server, the ServerIron sends the client's request to the real server. The client is unaware of the real servers behind the virtual server but does experience enhanced throughput and availability for TCP/UDP services. SLB maps one logical (virtual) server connection to multiple physical (real) servers. This allows a single IP address (virtual server IP address) can serve as the connection point for multiple TCP/UDP services such as HTTP, FTP or Telnet rather than each of the services requiring a different IP address for each service. These services can be located on a single server or across multiple servers. In Figure 3, a company establishes a Web site with the URL of The Web site is mapped to the virtual IP address , defined on a Once these inquiries are received at the company site, the requests are handled by one of four separate physical (real) Web servers that the system administrator has mapped to the virtual IP address. The addresses of the four physical (real) Web servers are unknown and unseen to those users who send the inquiries. The only address the users ever see for the Web site is the virtual IP address. Value of SLB SLB provides numerous benefits that ease overall administration of TCP/UDP applications on servers as well as increase their performance and reliability. In the previous example, Figure 3.1, the system administrator has greater flexibility in managing server resources for this application. When you use a ServerIron, you can add or remove the physical (real) servers to handle changing traffic requirements without disrupting service to the end users. The end users continue to access the virtual IP address configured on the ServerIron and are not aware of added or removed real servers that underlay the virtual IP address. SLB also enhances server security because the real servers' IP addresses are never broadcast. The ServerIron sends and responds to ARPs with the virtual IP address, not the actual IP addresses of the real servers. In addition to offering increased control over server resources and greater security within the network, SLB provides increased reliability of the server resources by providing support for both switch and server redundancy.

4 133 How SLB Works? A Foundry ServerIron running SLB software establishes a virtual server that acts as a front-end to physical servers, distributing user service requests among active real servers. SLB packet processing is based on the Network Address Translation (NAT) method. Packets received by the virtual server IP address are translated into the real physical IP address based on the configured distribution metric (for example, "round robin") and sent to a real server. Packets returned by the real server for the end user are translated by SLB so that the source address is that of the virtual server instead of the real server. NAT translation is performed for both directions of the traffic flow. Converting virtual services to real services requires IP and TCP checksum modifications. Port translation is not performed for any virtual port that is bound to a default virtual port. Load-Balancing Predictor The predictor is the parameter that determines how to balance the client load across servers. You can fine-tune how traffic is distributed across multiple real servers by selecting one of the following load balancing metrics (predictors). Least Connections Sends the requests to the real server that currently has the fewest active connections with clients. For sites where a number of servers have similar performance, the least connections option smoothens distribution if a server gets bogged down. For sites where the capacity of various servers varies greatly, the least connections option maintains an equal number of connections among all servers. This results in those servers capable of processing and terminating connections faster receiving more connections than slower servers over time. Round Robin Directs the service request to the next server, and treats all servers equally regardless of the number of connections or response time. For example, in a configuration of four servers, the first request is sent to server1, the second request is sent to server2, the third is sent to server3, and so on. After all servers in the list have received one request, assignment begins with server1 again. If a server fails, SLB avoids sending connections to that server and selects the next server instead. Weighted Round Robin Assigns a performance weight to each server. Weighted load balancing is similar to least connections, except servers with a higher weight value receive a larger percentage of connections at a time. You can assign a weight to each real server, and that weight determines the percentage of the current connections that are given to each server. The default weight is 0. For example, in a configuration with five servers of various weights, the percentage of connections is calculated as follows: Weight server1 = 7 Weight server2 = 8 Weight server3 = 2 Weight server4 = 2 Weight server5 = 5 Total weight of all servers = 24 The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/24, and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34. If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections at a given time. Because the server is faster than others, it can complete more than 50 percent of the total connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio but adjusts to server capacity over time. Server response time only Selects the real server with the fastest response time. If Layer 4 or Layer 7 health checks are disabled, the response time is based on how quickly the server responds to client requests forwarded by the ServerIron. If the health checks are enabled, the response time is the combination of the response to forwarded client queries and the response to the health checks. The ServerIron calculates the response time based on TCP SYN and TCP SYN ACK packets. When the Server Response Time method is used, the ServerIron generally forwards request to the server with the fastest response time. However, if a slower server has not been selected for more than one minute, it is selected so that the ServerIron can measure its response time. For SwitchBack (Direct Server Return) configurations, since the ServerIron does not see the server reply traffic, the ServerIron uses only the health check responses to measure the response time.

5 134 Least connection and server response time weights Compares a combination of a real server's leastconnections weight and server response time weight to the same values for the other real servers. The server response time method, when used by itself, always selects the real server with the fastest response time. If all your real servers have similar response capacities, then using the server response time metric by itself generally provides an even load-balancing distribution among the real servers. However, if your server farm contains a mixture of servers, some of which have greater response capability than others, you might want to set the Server Response time weights on individual real servers. The default server response time weight is 0 (no weight). You can specify a weight from Setting a real server's weight higher relative to other real servers biases the Server Iron's load-balancing selections toward that real server. Least local connections On an individual WSM CPU basis, the ServerIron selects the real server with the fewest active connections with clients. The predictor selects the real server that has the least number of connections created by the local WSM CPU. The local WSM CPU is the CPU that is managing the slot connected to the real server. This method applies to ServerIron Chassis devices only and is supported in software release and later 07.2.x releases. Least local sessions On an individual WSM CPU basis, the ServerIron selects the server that has the fewest active session on the WSM CPU attached to the real server. The number of sessions is updated when session entries are deleted. This method applies to ServerIron Chassis devices only and is supported in software releases , , and and later. You can assign these metrics on a global basis ("Globally Changing the Load-Balancing Method") and an individual virtual server basis ("Changing the Load Balancing Method on a Virtual Server"). By default, least connections is applied globally to all virtual servers. If you define a metric for a specific virtual server, that metric takes precedence over the globally defined metric. Weighted Round-Robin Scheduling The weighted round-robin scheduling is designed to better handle servers with different processing capacities. Each server can be assigned a weight, an integer value that indicates the processing capacity. Servers with higher weights receive new connections first than those with lesser weights and servers with higher weights get more connections than those with less weights and servers with equal weights get equal connections. The pseudo code of weighted round-robin scheduling is as follows: Supposing that there is a server set S = {S0, S1,, Sn-1}; W(Si) indicates the weight of Si; i indicates the server selected last time, and i is initialized with -1; cw is the current weight in scheduling, and cw is initialized with zero; max(s) is the maximum weight of all the servers in S; gcd(s) is the greatest common divisor of all server weights in S; while (true) { i = (i + 1) mod n; if (i == 0) { cw = cw - gcd(s); if (cw <= 0) { cw = max(s); if (cw == 0) return NULL; } } if (W(Si) >= cw) return Si; } For example, the real servers, A, B and C, have the weights, 4, 3, 2 respectively, a scheduling sequence will be AABABCABC in a scheduling period (mod sum(wi)). In an optimized implementation of the weighted round-robin scheduling, a scheduling sequence will be generated according to the server weights after the rules of IPVS are modified. The network connections are directed to the different real servers based on the scheduling sequence in a round-robin manner. 4. CONCLUSION Popular Web sites can neither rely on a single powerful server nor on independent mirrored- servers to support the ever increasing request load. Scalability and availability can be provided by distributed Web-server architectures that schedule client requests among the multiple server nodes in a user-transparent way. In this paper we reviewed the various load balancing predictors which acts as a parameter in balancing the client load across various servers in a distributed Web-server systems. The weighted round-robin scheduling is better

6 135 than the other techniques which were discussed, when the processing capacity of real servers are different. However, it may lead to dynamic load imbalance among the real servers if the load of the requests varies highly. In short, there is the possibility that a majority of requests requiring large responses may be directed to the same real server. [12] Ali M. Alakeel, A Guide to Dynamic Load Balancing in Distributed Computer Systems, IJCSNS International Journal of Computer Science and Network Security, VOL.10 No.6, June ACKNOWLEDGEMENTS I would like to thank the editorial team for their priceless suggestions REFERENCES [1] R.Hunter, The why of cloud, cd=226469&ref= g noreg, [2] M. D. Dikaiakos, D. Katsaros, P. Mehra, G. Pallis, and A. Vakali, Cloud computing: Distributed internet computing for IT and scientific research, Internet Computing, vol.13, no.5, pp.10-13, Sept.-Oct [3] P. Mell and T. Grance, The NIST definition of cloud computing, publications/nistpubs/ /sp pdf, [4] Microsoft Academic Research, Cloud computing, [5] Google Trends, Cloud computing, ting, 2012 [6] N. G. Shivaratri, P. Krueger, and M. Singhal, Load distributing for locally distributed systems, Computer, vol. 25, no. 12, pp , Dec [7] B. Adler, Load balancing in the cloud: Tools, tips and techniques, com/info center/whitepapers/ Load-Balancing-in-the-Cloud.pdf, 2012 [8] Z. Chaczko, V. Mahadevan, S. Aslanzadeh, and C. Mcdermid, Availability and load balancing in cloud computing, presented at the 2011 International Conference on Computer and Software Modeling, Singapore, [9] Anthony T.Velte, Toby J.Velte, Robert Elsenpeter, Cloud Computing A Practical Approach, TATA McGRAW-HILL Edition [10] Martin Randles, David Lamb, A. Taleb-Bendiab, A Comparative Study into Distributed Load Balancing Algorithms for Cloud Computing, 2010 IEEE 24th International Conference on Advanced Information Networking and Applications Workshops. [11] Mladen A. Vouk, Cloud Computing Issues, Research and Implementations, Proceedings of the ITI th Int. Conf. on Information Technology Interfaces, 2008, June