This section presents a case study of configuring a large farm of WebLogic Servers (WLS) (see Figure 5). The Provisioning System (PS) Master Server (MS) has been installed on node 0 under Solaris 9 together with a WWW server for load-balancing purposes (Apache 2.0.53 with the WebLogic plug-in). Nodes 1 to 30 run PS Remote Agents and several WLS run in separate Solaris 10 zones. The Nodes Repository stores information about nodes which are present in the farm. This information is used by the MS to check if new nodes are added to farm and eventually add those nodes to the PS management list. Information in the Nodes Repository is updated by the Node Discovery agent started in the Global Zone of each new node added to the farm. 4.1. Preparing for the Provisioning
The preparation of the system being studied concerns mainly process setup and activation of the test farm with the N1 Provisioning Server tool. In this phase stress is placed to a large extent on the automation of subsequent deployment. We have decided M. Jarzab et al. / Configuration Management of Massively Scalable Systems 179
to install a farm containing 31 B100s nodes as 30 nodes under Solaris 10 and a single node under Solaris 9. The default configurations of the operating system were cus- tomized to perform functions of the N1 Grid Provisioning System Server (PS) Master Server (MS) (Figure 6) on the node operated under Solaris 9, since the exiting version 5.0 is not available for Solaris 10. Other nodes run the N1 Grid Provisioning System Remote Agent (RA).
Node1 W LS RA W LS W LS RA W LS RA Node Discovery
Global Zone Zone 1 Zone N
Node 0 S olaris 9 MS Apache Nodes Repository Node 30 W LS RA W LS W LS RA W LS RA Node Discovery
Global Zone Zone 1 Zone N
S olaris 10 S olaris 10 Node1 W LS RA W LS W LS RA W LS RA Node Discovery
Global Zone Zone 1 Zone N
Node1 W LS RA W LSW LS RA W LS W LS RA W LSW LS RA W LS RA Node Discovery
Global Zone Zone 1 Zone N
Node 0 S olaris 9 MS Apache Nodes Repository MS Apache Nodes Repository Node 30 W LS RA W LS W LS RA W LS RA Node Discovery
Global Zone Zone 1 Zone N
Node 30 W LS RA W LSW LS RA W LS W LS RA W LSW LS RA W LS RA Node Discovery
Global Zone Zone 1 Zone N
S olaris 10 S olaris 10
Figure 5. Testing farm configuration
More specifically, the test farm installation was performed in the following steps:
1. Modification of boot scripts of the Solaris system so that this software is run
automatically following system startup.
2. Modification of N1 Grid Provisioning System Remote Agent software boot
scripts in order to make it work independently of the IP address of the host it is installed on. This proved necessary because this software has to be attached to the image of the operating system and this image cannot have IP addresses bound into its configuration statically. The reason is that the Provisioning Server assigns addresses to nodes during farm creation. Software that checks for the launching of the MS RA component is also installed on the node. It sends information about RA status and parameters periodically to the repository for the given farm. Data collected in the given repository serves for generating a configuration of available nodes in the N1 Grid Provisioning System.
3. Generating of images of:
– Solaris 10 system with RA software.
– Solaris 9 system with N1 Grid Provisioning system software.
4. Installation of tools and software:
– DNS (Berkley Internet Name Domain v. 9.3.1) server used as a method of
dynamically configuring IP addressing for newly created zones.
– Apache Web Server with configured WLS plug-in for clustering purposes.
This step consists of copying the already present installation from the “Gold Server” to the target node and adjusting parameters in httpd.conf (Table 2) for WLS cluster load balancing.
Table 2. Sample configuration of the Apache plug-in for WLS clustering. Lines 1-3 depict nodes and port numbers at which WLS cluster instances run and Location medical-rec is a context (Web application) for which HTTP requests must be load-balanced between WLS cluster nodes.
1. <IfModule mod_weblogic.c>
2. WebLogicCluster wlsnode1:7001, wlsnode2:7001, wlsnode3:7001 3. </IfModule>
4. <Location /medical-rec> 5. SetHandler weblogic-handler 6. </Location>
– WLS on nodes using silent installation procedure with a configuration file
defining one administration server. The Weblogic administration server is used by the PS to create new copies of server instances (a.k.a. managed servers). Depending on the defined strategy each instance can run one or several J2EE applications. Furthermore, at least one instance of WLS must act as a “Gold Server” storing previously-installed applications which in turn can be replicated to other instances of WLS clusters or single instances. Unfortunately, mechanisms for managing the WLS infras- tructure are not provided by PS by default. Therefore administrators of PS must install special a BEA-Weblogic plug-in which provides functionality for the creation and management (e.g. application deployment, starting/ stopping) of both the administration and managed server instances and also automatic cluster creation.
– Software that adjusts parameters for resource consumption (CPU shares,
memory usage, LWPS number) between zones and also for services running in these zones.
5. For each piece of software installed in the previous step, the PS component
configuration is generated and tested.
Figure 6. Master Server console with installed components for managing Solaris 10 zones
4.2. Example of Installation Flow
Thanks to the previously-described procedure, a typical deployment scenario is reduced to the following steps:
1. Deployment of the farm using the N1 Provisioning Server which automates
the process of creation the physical infrastructure, accelerating the process of farm creation with the usage of predefined operating system images. Each image has already installed N1 PS RA for remote management of software configuration at each node and MS for managing the whole deployment process.
2. Applying the node image with the preinstalled N1 Provisioning System
software. The process of the initialization of the PS configuration occurs automatically thanks to applying the node-discovery mechanism. This is done by adding Solaris 10 nodes (from the Nodes Repository) to the configuration of the PS MS host group “global zones”.
3. Installation under PS tools for creating and managing zones. This requires
interaction depicted in Figure 7 between N1 PS MS, the DNS system, and software for configuration management (scripts) of resource for zones.
4. Creation and configuration of a suitable number of zones. This process
consists of creating the new zones in the following stages:
– Uploading parameters (IP, Host name) to the DNS server for the new zone. – Downloading parameters (IP, Host name) from the DNS server at the
moment of initialization of the local zone.
5. Installation of the WLS software on selected zones using silent-installation
mode performed by PS. Each installed WLS server has one domain which is managed by the administration server. Following installation, the adminis- tration servers configuration (http port, installation directory, admin user and password) at each node must also be specified in the MS, because it is used for creation of new instances (managed servers) of WLS using the MS Web browser console. At least one instance of the managed server must be dedicated to testing purposes (“Gold Server”). The resultant WLS cluster con- sists of already-installed managed servers. The N1 PS admin can check if the application deployed on the “Gold Server” works faultlessly. If there are no errors, this application can be captured and easily replicated among WLS cluster nodes.
6. Installation of the WWW Apache Server. Applying PS to installation.
Automatic configuration of the WLS service plug-in.
Figure 7. Deployment scenarios interaction for Solaris 10 zones N1 Provisioning System MS DNS Solaris 10 Global zone Zone creation request
DNS update
Getting IP, Host Name for new zone
5. Conclusions
Configuration management of applications running over virtualized resources in large computer systems can be effectively exercised with a new class of software supporting the provisioning process. This process should integrate flexible control of virtualized resources with mechanisms for setting up applications configuration parameters and support for easy replication of exiting installations over large numbers of nodes. The tested SUN tools N1 Provisioning System and N1 Provisioning Server satisfy most of these requirements.
References
[1] Service Oriented Architecture (SOA) description available at O’Reilly WebServices, http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
[2] J2EE 1.4 Platform specification, http://java.sun.com/j2ee/1.4
[3] J2EE Connector Architecture specification, http://java.sun.com/j2ee/connector/index.jsp [4] Open Grid Service Architecture (OGSA) Specification, http://www.globus.org/ogsa [5] Utility Computing , Business White Paper SUN Microsystems, March 2004
[6] Deployment strategies focusing on Massive Scalability, OSS Through Java Initiative, Brian Naughton, April 2003
[7] Consolidating applications with Solaris containers, SUN Microsystems Technical White Paper, November 2004
[8] SUN Solaris Container technology vs. IBM Logical Partitions and HP Virtual Partitions, Edison Group’s Business Strategy Report
[9] JMX (Java Management Extension) specification, http://java.sun.com/products/JavaManagement/ [10] SUN Java System Application Server, http://www.sun.com/software/products/appsrvr/index.xml [11] JBoss application server, http://www.jboss.org/products/jbossas
[12] BEA Weblogic Application Server, http://www.bea.com/framework.jsp?CNT=index.htm&FP=/ content/products/server
[13] N1 Provisioning Server Blades Edition, http://wwws.sun.com/software/products/provisioning _server/index.html
[14] N1 Provisioning System, http://wwws.sun.com/software/products/service_provisioning/ index.html
[15] N1 Grid Console, http://www.sun.com/software/products/grid_console/index.xml [16] Solaris Containers – What They Are and How to Use Them, SUN BluePrints OnLine, Menno Lageman,
May 2005