Self-Tune-Ing of a J2EE Clustered Application
Total Page:16
File Type:pdf, Size:1020Kb
Self-TUNe-ing of a J2EE clustered application O. Chebaro L. Broto J.-P. Bahsoun D. Hagimont Toulouse University IRIT Laboratory 118 Route de Narbonne F-31062 TOULOUSE CEDEX 9 [email protected] Abstract really exists and dynamic reconfiguration remains a goal to achieve. This lack of manageability makes it very difficult The Java 2 Platform, Enterprise Edition (J2EE) defines to take full advantage of clustering capabilities, i.e. expand- a model for developing multi-tier distributed applications, ing/collapsing replicas sets as needed, and so on such as e-commerce applications. Such applications are A very promising approach to this issue is to implement typically composed of a web server, a servlet server, option- administration as an autonomic software. Such software can ally an EJB server and a database server. Clusters allow be used to deploy and configure applications in a distributed replication of each tier instance, thus providing an appro- environment. It can also monitor the environment and react priate infrastructure for high availability and scalability. to events such as failures or overloads and reconfigure ap- However, such applications are complex to administrate plications accordingly and autonomously. and often lack deployment and reconfiguration tools. More- This paper reports on an ongoing project that aims at over, the fact that management tasks are performed by hu- providing system administrators with a management en- mans leads to many configuration errors and low reactivity. vironment that is as automated as possible. This man- To address this issue, we designed and implemented an agement system called TUNe (Toulouse University Net- autonomic management system which provides an environ- work) targets a wide range of applications, especially ex- ment for deploying and autonomously reconfiguring dis- isting (legacy) applications. In this paper, we report on tributed applications as required. The main principle is our experience in using TUNe for the deployment (installa- to wrap legacy software pieces in components in order to tion/configuration) and reconfiguration of a clustered J2EE administrate a software infrastructure as a component ar- application. We show how TUNe allows deploying an in- chitecture. Several languages (textual, graphical) are intro- frastructure of servers such as Apache, Tomcat and Mysql, duced to describe deployment and reconfiguration policies. and a real benchmark application called RUBIS. This paper presents an overview of the TUNe autonomic management system and focuses on its application to the The rest of this paper is structured as follows. Section 2 management of a clustered J2EE application. overviews clustered J2EE applications and their life cycle and presents the issues related to deployment, configuration and more generally management. Then, Section 3 presents TUNe, a contribution to ease such applications management 1. Introduction by providing automatic deployment and configuration tools. Section 4 presents our experiments with J2EE and an ex- J2EE architectures are as a convenient way to build ef- perimental evaluation. After a review of related works in ficient ecommerce web applications. To address availabil- Section 5, Section 6 concludes and presents future work. ity and scalability issues, this multi-tiers model can benefit from clustering techniques that allow, by means of replica- tion and consistency mechanisms, to tolerate failures and 2. Administration of J2EE clusters increase application capacities. However, J2EE applications (the whole infrastructure in- cluding the middleware runtimes) are not easy to manage. This introductory section overviews clustered J2EE ap- Their deployment process (installation and configuration) is plications and their life cycle before presenting the associ- as complex as tricky, no execution monitoring mechanism ated management issues. 2.1. Clustered J2EE Applications and their Lifecycle J2EE applications [9] are usually composed of four dif- ferent tiers, either running on a single machine or on up to four ones: • A web server (e.g. Apache [13]), that manages in- coming client requests and, depending if those relate to Figure 1. Architecture of dynamic web appli- static or dynamic content, serves them or routes them cations to the presentation tier (the servlet container) using an appropriate protocol (e.g. AJP13 for Tomcat). Database clustering solutions often remain commercial, • A servlet container (e.g. Tomcat [12]), that receives like Oracle RAC (Real Application Cluster) or DB2 cluster forwarded requests from the web tier, interacts with the and require using a set of homogeneous full replicas. We EJB container for invoking business code and fetching can however cite C-JDBC [4], an open source JDBC clus- results, and generates a web document presenting the tering middleware that allows using heterogeneous partial results to the end-user. replicas providing with consistency, caching and load bal- database storing application data by sending SQL re- ancing. quests by the way of the JDBC framework and dynam- J2EE applications life cycle consists in three main steps ically as illustrated in Figure 2. These steps are detailed below: deployment, monitoring and reconfiguration. • An EJB container (e.g. Jonas [14]), that hosts En- terprise Java Beans which include the business code of the application. The invoked EJBs may have to be loaded/stored from the database by sending SQL re- quests through JDBC. • A database management system (e.g. MySQL server [10]), that manages the application’s persistent data. The main motivations for clustering are scalability and fault tolerance. Scalability is a key issue in case of web applications that must serve billion requests a day. Fault- tolerance does not necessarily apply to all sites, but to ap- plications where information delivery is critical (as com- mercial web sites for example). Both scalability and fault- Figure 2. J2EE Applications Life Cycle tolerance are offered through replication (and consistency management). In the case of J2EE applications, replication • Deployment. At the deployment step, tiers must firstly at the level of each tier provides applications with service be installed on hosts and be configured to be correctly availability when machine failures occur, as well as effi- bound to each other. Then, application logic and data ciency by load balancing incoming requests between repli- can be initialized. Application tiers are often delivered cas. through installable packages (e.g. RPMs) and the con- The architecture of clustered J2EE applications is de- figuration is statically expressed in configuration files picted in Figure 1 and detailed below in the case of an which map components to resources. Apache, Tomcat and MySQL clusters. Apache clustering is managed through HTTP load balancing mechanisms that • Monitoring. Once the application has been deployed can involve hardware and/or software balancers. on the J2EE cluster, one needs to know both the sys- Tomcat clustering is made by using the load balancing tem and the application states to be aware of problems feature of Apache’s mod jk plugin. Each mod jk can be that may arise. Most common issues are due either to configured in order to balance requests on all or on a subset hardware faults such as a node or network link failure, of Tomcat instances, according to a weighted round-robin or inappropriate resource usage when a node or a tier policy. of the application server becomes a bottleneck. • Reconfiguration. Once a decision has been taken 3.1. Component-Based Management (e.g., extension of a J2EE tier on new nodes to handle increased load), one must be able to perform appropri- Component-based management aims at providing a uni- ate reconfiguration, dynamically and avoiding as far as form view of a software environment composed of different possible to stop the application. types of servers. Each managed server is encapsulated in a component and the software environment is abstracted as a 2.2. Challenges component architecture. Therefore, deploying, configuring and reconfiguring the software environment is achieved by using the tools associated with the used component-based Currently, no integrated deployment environment exists middleware. for clustered J2EE applications. Each tier must be installed The component model we use in TUNe is Fractal [3], a manually and independently. The whole assembly, includ- reflective component model intended for the construction of ing clustering middleware, must be configured manually dynamically configurable and monitored systems. A Frac- mainly through static configuration files (and also there isnt tal component is a run-time entity that is encapsulated and any configuration consistency verification). Consequently, communicates with its environment through well-defined the deployment and configuration process is a complex task access points called interfaces. Fractal components com- to perform. municate through explicit bindings. A binding corresponds J2EE cluster monitoring is also a weakly covered aspect. to a communication path between two or more components. It is obviously possible to see hosts load or to track failures These binded components can form a component architec- using SNMP, but this is not enough to get accurate informa- ture. The Fractal specification specifies several useful con- tion about application components. trollers: the binding controller allows creating or removing In terms of reconfiguration, no dynamic mechanism is bindings between components; the life-cycle