Balancing For -based Grid Application Gan Keng Hoon, Chan Huah Yong and Fazilah Haron School of Computer Sciences University Science Malaysia 11800 Minden Penang {khgan,hychan,fazilah}@cs.usm.my Abstract: Our load balancing service is a generic tool for enhancing performance of accessing distributed objects from the web interface. We concentrate on objects with massive dynamic processing. The deployment of grid application on the web enable us to apply our load balancing service at the front end of the grid application in order to deal with bottlenecks at the application tier in web architecture. Keywords: Grid application, web, dynamic, load balancing, middleware. I. INTRODUCTION The computational grid is a combination of distributed and heterogeneous computing resources for executing largescale applications. These applications include modeling and simulation for solving complex scientific and engineering problems, diagnosis for medical conditions, weather forecasting etc. In grid environment, there are different layers in the architecture that represent grid fabric, grid middleware, grid tools and grid application ([23] & [24]). Each layer consists of components that reflect the functionality of the layer. The grid application layer consists of applications or portals built with grid-enabled language such HPC++, MPI etc. Grid portals offer web-enabled applications services where users can submit and collect results for their jobs on remote resources through a web interface. It provides an environment that hides the users from complexity of heterogeneous, distributed and high performance back end. In the following section, we introduce the general architecture of web application and the grid application on web environment. Then in Section 3, we discuss on some ways of load balancing attempted for general web applications architecture and state some problems in the relevant works done. In Section 4, we define our research scope in the grid-based web applications. In Section 5, we propose a load balancing service framework related to the identified problems. This is followed by some brief explanation of the load balancing policy in Section 6. Finally, we conclude our work. II. GRID APPLICATIONS ON THE WEB Grid applications on the web provide users with a variety of services through the web interface. Similarly to the general architecture of a web-based application (Figure 1), the webbased grid application has multi-tier architecture. Client Browser Server Engine Middle Application Back Data Storage Figure 1: A General -based Application Architecture Figure 1 depicts the overview of general web application architecture. Generally, there are three tiers in web application architecture. The application tier can be expanded to enable the architecture to become multi-tier architecture. In such way, different aspects of the web application can be developed independently. Separate optimization can be done to different type of services as well. s at the application tier are object-based components. For load balancing purpose, they are distributed across the network at different locations. The multi-tier architecture of grid applications (Figure 2) consists of web browser, the middle tier and also the back tier. The web browser based front tier enables visualization of complex computational tasks and to act as interacting interfaces for carry out operations, analysis, formatting of results etc. The middle-tier of the architecture is divided into two tiers. The web server tier process static requests, simple logic, formatting of results etc. The application tier provides transparent mapping of task from the requests at web tier to the real grid applications that are hidden at the back tier. The real applications are presented at the application tier by service components playing the role of proxies to the grid applications. It is important to keep the existing grid applications without the need to modify the 1
internal codes when deploys it on the web. Thus, a service component is a simple object that merely knows how to submit tasks to the application it represents but does not contain any application code. The back tier consists of the real grid application where it is executed by using heterogeneous back-end resources such as high performance systems, mass storage systems, database system etc. It also involves features and services like scheduling of complex task, parallel implementation of jobs, resource management, fault tolerance etc. Client Middle Back Browser static component logic component Application proxies service component Grid Applications Engineering Scientific Collaboration Prob. Solving Env. Grid Tools Languages Libraries Debuggers Monitoring Resource Broker Tools Grid Middleware Comm. Sign On & Security Information Process QoS Local Resources Managers OS Queuing Sys. Lib & App. Kernel TCP/IP & UDP Grid Fabric Networked Resources Computers Clusters Storage Sys. Data Sources Scientific Instruments Legend: Distributed Grid Application Component Figure 2: Multi-tier Architecture for Grid Applications III. RELATED WORKS A. Balancing Approaches for General Architecture Currently, most load balancing solutions for increasing web application performances are provided at the network layer and transportation layer of the OSI 1 model. This type of load balancing can be categorized as network-based load balancing. In this category, an earlier load balancing approach used by NCSA s web server [21], which is known as Round Robin DNS carried out load balancing by rotating a list of predefined IP address representing different web servers. However, this approach is static and only provides some degree of load sharing among multiple identical servers. Intelligent load balancing solution was introduced later and used in commercialized products. F5 3-DNS Controller provides comprehensive load balancing algorithms such as dynamic ratio, HOPS, random, least connections, round trip time etc. [8]. IBM Secure Way Network Dispatcher has an intelligent DNS-based component with load monitoring service [3]. 1 Open System Interconnection, an ISO standard for worldwide communications that defines a networking framework for implementing protocols in seven layers. Another load balancing approach in this category is IP-level load balancing. Residing behind the real IP address, there is a collection of virtual IP address to represent a collection of servers. These servers can be added or removed dynamically from the collection. [18]. Cisco Local Director monitors IP server load balancing by using three key variables, which are the network bandwidth, server performance and job size [5]. F5 BIG-IP identifies specific traffic based on HTTP header information [9]. There are much research done on the HTTP requests redirection. [6] develops a multi-faceted scheduling scheme by considering the aggregate impact of multiple parameters on system performance. [12] classifies HTTP requests to different service quality classes and service priority weight. It has a dynamic scheduling scheme that adapts to varying request resource demands and periodically repartitions servers. Master/slave architecture of web clustering is introduced in [11] for the scheduling optimization. This scheduling scheme considers the characteristics of web workloads, separates the static and dynamic content processing so that the static and dynamic requests are redirected to different resources in the architecture. Despite massive research on network-based load balancing, another load balancing technique was introduced by [19]. This approach can be categorized as application-based load balancing as it explores application-level techniques for distributing web content. The Distributed Cooperative Server (DCWS) distributes the load evenly among web 2
servers by dynamically manipulating hyperlinks stored within the web documents. B. Problematic According to [15], load balancing can be done at OS, network and middleware level of distributed system. In addition to this, there is research done on application level load balancing [19]. At the lowest level for the hierarchy, OS-based load balancing is done by distributed operating system in the form of lowest system level scheduling among processor [16]. It is a generic load balancing mechanism for any applications running on distributed operating system. Although network-based load balancing has been carried out successfully in different works, this approach is still limited for older web application architecture. Usually, this approach ensures load balancing for the web tier of web architecture. It works for web application that is only displaying static pages or processing simple logic or scripts. each service component represents complex grid application component. In this paper, the load balancing service is to be applied on distributed components of grid applications. Each service component is coupled with a real grid application component from the back end. Therefore, the application tier can be expanded to become multi tier architecture that accommodates different service components. In such way, different grid application component can be provided through the application tier independently. Separate optimization can be done according to different service components as well. Client Middle Application Component Replicas Back Both OS-based and network-based load balancing face limitation of inability to adapt load balancing based on the characteristics of web services, such as web service types, service priority, dynamic web contents, demand etc. Browser Server Engine Balancing Grid Environment The middleware-based load balancing resides between network level and application level. [15] contributes in this level by introducing common load balancing techniques implemented on CORBA ORB. Another similar approach is Microsoft s component load balancing [4] where the DCOM mechanism is based upon RPC. Application-based load balancing can be conducted in different ways. A new approach is through hyperlinks manipulation as mentioned above. For grid application on the web, application-based load balancing can done through parallel implementation on complex or computation intensive modules. This approach is specific for particular application and the load distribution task is usually considered during the design phase. IV. SCOPES This paper focuses on the middleware-based load balancing at the application tier of web architecture. Therefore, we will provide load balancing service for distributed components with the considerations of factors that cause the bottleneck at the application tier. According to [1], high performance web servers can typically deliver several hundreds of static pages per second. In contrast, generation of a dynamic page might take a couple seconds. Dynamic processing has become the cause of bottleneck for multi-tier application. From Figure 2, we could see similar problems at the application tier as Legend: Replica for different grid components Figure 3: Balancing in General Architecture Group Grid applications are usually dedicated in solving problems such as computation intensive functions, simulation, modeling etc. in domains such as scientific, engineering and so forth, some of them are already designed with load distribution or parallel algorithms. From Figure 3, we place our load balancing service at the application tier of web application architecture to complement the existing load balancing solutions in the grid environment. A. Technology components at application tier are object-based components that can be distributed or remotely located. To enable communication between these service components and load balancing service, we will use distributed objectbased middleware technology. Our load balancing service is a system-level service where it can be introduce to the application tier by using IDL-specified interfaces. System services are discussed in [10]. It is similar to the CORBA services [17]. 3
B. Goals Our method will directly address to problems at the application tier by i.) provide load balancing service for grid application components through service components. ii.) prevent bottlenecks at the application tier by enabling replication of service components in a scalable way to provide more access to the high performance back end resources. iii.) enabling high-availability of service components at application tier. There are a group of replicas of the same service to standby for any fail over. V. THE FRAMEWORK OF LOAD BALANCING SERVICE Balancing User Balancing Balancing Policy Decision Maker Monitor Agent Group Resource Allocation invokes Legend: A B Component Replicas Figure 4: Components of the Balancing The load balancing service functions as an independent module at the application tier. It actually augments the basic CORBA architecture. It does not interfere the implementation of services at this tier. For this research, the load balancing service user are system developers who need to apply load balancing mechanism to their application services. Figure 4 features the core components in our load balancing service. These components are the Decision Maker, Monitor, Agent, Resource Allocation and Group. 1) Group To use our load balancing service, object implementations (CORBA compliant object) of dynamic services need to register with the Group. A service group will be created whenever a new service registers itself with the group. It enables adding and removing of replica. Its main purpose is to provide a view containing simple information about the references to the locations of all replicas registered with group. We do not need to know exactly where the replica is located. 2) Decision Maker This component assigns the best replica in the service group to serve the request. The service decision maker acts as a proxy between the client and the dynamic service. It enables transparency between them without letting the client knowing about the multiple distributed service replicas. Thus, a client only need to invoke the service decision maker to get the best reference for the service and proceed with its normal procedure such as calling methods from the service etc. The implementation of service decision maker can be carried out in a simple manner to avoid the overhead cause by complexity of this component. First, this component has to be independent from other components, which are running real time processes. Second, it need to make decision as fast as possible. Therefore, it needs processed information from other components. Lastly, the decision maker makes its decision based on the algorithms defined in our load balancing policy. 3) Monitor monitor collects load information (CPU level usage) from every load agent within certain time interval. We are concern on the usefulness of information provided by load monitor. Two main concerns are the load information must well process and efficient for the usage of other component the load information is refreshed at a suitable interval so that the information provided is not expired. There are a few ways to carry out information processing at the load monitor. First, we can categorize the machines into groups such as below threshold, above threshold and idle. Second, we can sort the machines into a list ranging from the least busy to the most busy. Both information processing approaches that we mentioned above need high refresh rate. Otherwise, bottleneck will occur at the least busy machine. However, we notice that high refresh rate will cause overhead. We suggest an approach that can be practiced to overcome this problem. First, impose a moderate interval for load monitor to collect load information from every load agent. Second, place certain limit on number of request that can be assigned to single machine. Third, trigger an event to refresh only the machine that has been assigned with one or more request. 4) Agent The purpose of load agent is to provide load information of the machine it resides when requested by load monitor. We determine the load metric as the percentage of CPU usage. As different services might have replicas in the same machine, it is hard to presume the percentage of resource is being used by which service at particular moment. Therefore, a general metric is needed to indicate the level of 4
available resources at the machine during particular moment. 5) Resource Allocation The resource is limited. It is necessary to allocate the resource properly to optimize the load balancing performance result. The purpose of this component is to dynamically adjust the resource to achieve a balance load distribution among different services. This component makes decisions on some mechanisms such as service replication, services coordination, dynamic adjustment and requests prediction. In order to carry out service replication, we determine parameters such as initial number of replica, maximum number of replica, when to replicate, where to replicate etc. As different service contains different characteristics such as process time, priority and popularity, we coordinate services in order to avoid monopolizing of resource by popular service and unfair treatment for high priority service. For dynamic adjustment mechanism, we determine the events that will trigger the adjustment of resource. Lastly, we propose a mechanism that will contribute to the dynamic adjustment. As the dynamic adjustment is always based on current workload, the workload pattern might change after some time. We analyze the pattern of requests arrival rate for each service within certain period. Based on this history, we will predict the number of future requests for each service. VI. LOAD BALANCING POLICY The load balancing policy is deployed to share or equalize the workload among the available resources in order to optimize performance. We will discuss some policies that have been suggested or analyzed in previous works. A general purpose scheduling taxonomy is introduced by [20] to address resource management problems as well as to provide a common terminology and classification mechanisms to address these problems. Another load distribution taxonomy is introduced by [13]. This taxonomy presents a load distribution scheme, which separated the load distribution policy and the load distribution mechanism. sharing taxonomy in [22] presents analysis of level of information dependency for both source-initiative and server-initiative approaches. Different works [14,7,13,2] present their own set of policies for considerations and decisions in its load balancing algorithms or scheduling algorithms. For example, [14] presents transfer policy, selection policy, location policy and information policy. Although there are differences in the terminology of policies determined by these works, however their works provide similarities where these components co-operate with each other to ensure successive load balancing policy. In [7], three location policies were studied to address the appropriate level of complexity for load sharing policies. These policies include Random, Threshold and Shortest Queue. This work proves that simple policies offer performance that is close to performance expected from complex policies. Our load balancing policy will adapt three typical components from set of policies defined by current works. These policies are selection policy, location policy and information policy. We will briefly discuss these components to clarify its definition in our load balancing policy. 1) Selection policy This policy selects a task for transferring. As our task selection is based on incoming request, all newly arrive request will be selected as candidate for transferring. Therefore, there is no need for information for task selection. This policy is relatively simple as it selects the task based on First Come First Serve basis. 2) Location policy This policy selects a location for transferring the selected task. Basically, this policy will need to rely on the information policy for collecting certain information (e.g. load level) from different locations. Usually, this policy will attempt to choose the location with the least load level or below certain threshold. However, random location policy that was mentioned earlier does not need collection of any information. 3) Information policy This policy determines the level of information needed for task selection or location selection. It decides on when to collect the information and what information to be collected. It also decides whether to collect information from every locations or just part of them, to distribute the information at different locations or to centralize them etc. VII. CONCLUSION In this research work, we propose a generic load balancing tool for the application tier of web architecture. This paper introduces the general web application architecture and relates it with grid application architecture. When deploy grid application on the web, bottlenecks might occur at the middle tier of web application architecture. We see that the web only has one entry point for accessing grid applications at the back tier. With assumption that the back tier consists of high performance resources for the grid applications, we ensure that the middle tier does not become the bottleneck when handling requests for these grid applications. This work is still under implementation. REFERENCE [1] A. Iyengar, J. Challenger, D. Dias and P. Dantzig, Techniques for Designing High-Performance Sites, In IEEE Internet Computing, Vol. 4, No.2, Mar./Apr. 2000. 5
[2] B. A. Shirazi, A. R. Hurson and K. M. Kavi, Scheduling and Balancing in Parallel and Distributed Systems, IEEE Computer Society Press, Los Alamitos, CA, 1995. [3] C. Gage, IBM Secure Way Network Dispatcher Version 2.1: Scalability, Availability and -balancing for TCP/IP Application, IBM Corp., Apr. 1999. [4] C. Rees, Microsoft Application Center 2000 Component Balancing Technology Overview, Microsoft Corp., Sept. 2000. [5] Cisco Systems, Inc., Balancing: A Multifaceted Solution for Improving Server Availability, http://www.cisco.com/warp/public/cc/pd/cxsr/400/tech/lobal_wp.ht m, 1998. [6] D. Andresen, T. Yang and O. H. Ibarra, Toward A Scalable Distributed WWW Server on Workstation Clusters, Journal of Parallel and Distributed Computing, 42(1): 91--100, Apr. 1997. [7] D. L. Eager, E. D. Lazowska and J. Zahorjan, Adaptive Sharing in Homogeneous Distributed Systems, IEEE Transactions on Software Engineering, vol. 12, pages 662 675, May 1986. [8] F5 Networks Inc., The 3-DNS Controller Helps Companies Attain Their Global Internet Business Objectives, http://www.f5.com/solutions/whitepapers/3dnscontroller.html. [9] F5 Networks Inc., The Advantages of F5 s HTTP Header Balancing over Single-Point URL Parsing Solutions, http://www.f5.com/solutions/whitepapers/http.html. [10] H. Y. Chan, P. Chatonnay, B. Herrmann and L. Philippe, Auto- Adaptive Administration of Resource Allocation, ERSADS 99, Madeira Island-Portugal, 23-28 Apr. 1999. [11] H. Zhu, B. Smith and T. Yang, A Scheduling Framework for Server Clusters with Intensive Dynamic Content Processing, Technical Report TRCS-98-29, CS Dept., UCSB, Nov. 1998. [12] H. Zhu, H. Tang and T. Yang, Demand-driven Differentiation for Cluster-based Network Servers, In Proc. of IEEE INFOCOM 2001, Anchorage, AK, Apr. 2001. [13] K. P. Bubendorfer, Resource Based Policies for Distribution, Master of Science Thesis, Victoria University of Wellington, Aug. 1996 [14] N. G. Shivaratri, P. Krueger, and M. Singhal, Distributing for Locally Distributed Systems, IEEE Computer, vol. 25, pages 33--44, Dec. 1992. [15] O. Othman, C. O Ryan and D. C. Schmidt, Strategies for CORBA Middleware-based Balancing, IEEE Distributed Systems Online, Vol. 2, No. 3, Mar. 2001. [16] R. Chow and T. Johnson, Distributed Operating Systems and Algorithms, Addison Wesley Long, Inc., 1997. [17] R. Orfali and D. Harkey, Client/Server Programming with Java and CORBA: 2nd Ed., John Wiley & Sons, 1998. [18] S. Deshpande, Clustering Transparent Replication, Balancing, and Failover Building Scalable and Highly Available E-Commerce Applications with the Inprise Application Server, CustomWare, Jan. 2000. [19] S. M. Baker and B. Moon, Distributed Cooperative Servers, In Proc. of The Eight International WWW Conference, Toronto, Canada, May 11-14, 1999. [20] T. L. Casavant and J. G. Kuhl, A Taxonomy of Scheduling in General-Purpose Distributed Computing Systems, IEEE Trans. on Software Eng., vol. 14, no. 2, pages 141-154, Feb. 1988. [21] T. T. Kwan, R. E. McGrath and D. A. Reed, NCSA's World Wide Server: Design and Performance, IEEE Computer 28(11): 68- -74, Nov. 1995. [22] Y. T. Wang and R. J. T. Morris, Sharing in Distributed Systems, IEEE Trans. Computer, pages 204--217, Mar. 1985. [23] J. Giddy, D. Abramson and R. Buyya, Internet-Wide Global Supercomputing, AUUG 2000, Canberra. [24] M. Baker, R. Buyya and D. Laforenza, The Grid: International Efforts In Global Computing, SSGRR 2000, The Computer & ebusiness Conference, I`Aquila, Italy, Jul 31-Aug 6 2000. 6