Partitioning and Clustering Demonstration

Transcription

1 Partitioning and Clustering Demonstration Improve performance for Web and application deployment with Borland Enterprise Server by Joe Overton, U.S. Systems Engineer, Borland Software Corporation May 2002 Contents Partitions 1 Clustering 3 Homogeneous configuration 7 Naming Service fail-over 9 Conclusion 9 Introduction Rapidly changing business requirements mean corporations must roll out e-business applications faster than ever before. Modern Web applications require a solid deployment platform that supports rich, dynamic content and provides the tools necessary to implement caching, session management, and the database needs of real-world applications. The Borland Enterprise Server is one of the most reliable and scalable J2EE application servers available, with sophisticated clustering, load balancing, fault tolerance, and fail-over. This paper offers demonstrations of clustering and partitioning with the Borland Enterprise Server. Partitions Partitions provide the environment for J2EE applications running in the Borland Enterprise Server. For example, each AppServer Edition partition instance provides: Web container (Tomcat 4.0) for hosting JavaServer Pages (JSP ) and servlets EJB container for hosting Enterprise JavaBeans (EJB) components Transaction Service for transaction management, including XA Session Service JSS or Java Session Service provides state management Naming Service supports both VisiBroker Edition and AppServer Edition JDataStore all-java database from Borland

2 Creating a new partition To create a new partition, run the Borland Enterprise Server server and console. From the console, expand enterprise servers and your server name. Configuration is required prior to starting the partition due to conflicts with other partition services. The common conflicts are: Tomcat HTTP port server.xml 8080 JDataStore remote JDBC port jdatastore.properties 2508 Vbroker listener port vbroker.properties dynamic JDK Home (if donor is remote) partition_server.config installdir/jdk Right-click on the partitions folder and select New partition. Enter a name for the partition and select OK. A new partition is created based on the default located at: <installroot>\var\defaults\partitions\ Configuring partitions Every partition can have its own unique configuration details. This allows multiple J2EE applications to run in an isolated environment within one Borland Enterprise Server. When making configuration changes to the partition services, the console will prompt the user to restart the partition. It is recommended that the user decline the restart until all configurations have been made. It is required to change the port number the Web container uses before running a new partition. Right-click on Web container and select configure. The partition is idle (stopped) upon creation. 2 Change the port number in the section that reads:

3 <!-- Define a non-ssl HTTP/1.1 Connector on port > <Connector classname="org.apache.catalina.connector.http.httpconn ector" port="8080" minprocessors="5" maxprocessors="75" enablelookups="true" redirectport="8443" acceptcount="10" debug="0" connectiontimeout="60000"/> This is the minimum configuration required to get new partitions up and running. Cloning partitions After a partition is configured, it is often useful to make a copy. The cloning feature provides this function. To clone a partition, right-click on the partition and select clone. It is required that the user stops the partition to be cloned. Configuration is required to eliminate any conflicts with the original partition. Clustering The following demos go through the clustering features of each edition of Borland Enterprise Server and focus on the services found in the Web, AppServer Edition and VisiBroker Edition. Each enterprise application is unique and has its own configuration requirements. Web Edition Clustering the Web Edition requires two or more partitions with Web Edition services running (containers/jss). This demo illustrates clustering multiple Web containers and synchronizing their sessions with a central JSS. The setup includes two partitions with Web containers, one partition with the JSS and the core services Smart Agent, and Apache running at the server level. Each Web container uses the JSS. Apache connects to each of the Web containers using the IIOP plug-in. The lookup happens via the Smart Agent. This configuration allows for load balancing and fail-over at the Web container level. Load balancing: The Smart Agent will round-robin requests from Apache to the Web containers. Fail-over: The Smart Agent will round-robin requests to the next available Web container. The Web container will load the current state from the JSS. Choose a name and a server for the cloned partition. 3

4 View of console after step one. Diagram from Chapter 3 of the Developers Guide. Web Edition demo The Developers Guide states: Borland Enterprise Server, Web Edition provides an operational Apache Web Server and Tomcat Web Container connection as "out of the box" upon startup. The two components are connected with each other via the IIOP Plug-in. This Plug-in allows both Apache and Tomcat to communicate via Internet Inter-ORB Protocol (IIOP) to one another with no required configuration. As an exercise, this demo will go through each configuration detail by modifying the defaults when possible. Do not start any partitions of services until instructed. Step 1: Create a new Partition called JSSPartition, which represents machine 4 in the diagram. Disable all services except the Session Service. Right-click on the Session Service and configure. Change the factory name to JSSMachine4. Step 2: Create a new Partition called Machine2, which represents machine 2 in the diagram. Disable all the services in Machine2 except the Web container. Right-click the Web container and configure. This brings up an editor with the Web container s Server.xml. Modify the following: Port Number Change to 8090 <!-- Define a non-ssl HTTP/1.1 Connector on port > <Connector classname="org.apache.catalina.connector.http.httpconn ector" port="8090" minprocessors="5" maxprocessors="75" enablelookups="true" redirectport="8443" acceptcount="10" debug="0" connectiontimeout="60000"/> Persistent Manager Uncomment the Manger XML, change the default storename (jss_factory) to JSSMachine4, change the default maxidlebackup (-1) to 6 seconds. This setting is available to both the HTTP and IIOP connectors. For this example, change the setting for the IIOP connector. 4

5 <!-- Uncomment the following line for storing your session data in JSS--> <Manager classname="org.apache.catalina.session.persistentmanag er" debug="0" maxidlebackup="6" checkinterval="60"> <Store classname="org.apache.catalina.session.borlandstore" storename="jssmachine4" debug="0" /> </Manager> Note: The Web container also supports native session management. This allows Tomcat to talk directly to JDataStore. Using the JSS is recommended because of the following advantage: Once you have defined a JSS with a given name, it can run anywhere in the local network. Afterwards, stopping the initial JSS and starting a new one requires no changes to the configuration entries. This is called "location transparency." JSS does not require setup of database tables for session storage. The database tables are automatically created by JSS. JSS also has a mechanism to store EJB session information in the Borland Enterprise Server. All your session information is easily stored in one place using the same JSS. IIOP connection change the default name (tc_inst1) to demo_connection. Step 3: Clone Machine2 partition and name it Machine3. This represents machine 3 in the diagram. All the services in Machine3 are disabled except the Web container. Right-click the Web container and configure. This brings up an editor with the Web container s Server.xml. Modify the following property: Port Number change to 8091 <!-- Define a non-ssl HTTP/1.1 Connector on port > <Connector classname="org.apache.catalina.connector.http.httpconn ector" port="8091" minprocessors="5" maxprocessors="75" enablelookups="true" redirectport="8443" acceptcount="10" debug="0" connectiontimeout="60000"/> <Service name="iiop"> <Connector classname="org.apache.catalina.connector.iiop.ii opconnector" name="demo_connection" debug="0" /> Completed view through step 3. Step 4: Right-click Apache and configure. Select the httpd.conf tab. Scroll to the bottom. Make the following changes: 5

6 IIOP connection Default WebAppConnection myconnection iiop tc_inst1 WebAppConnection myconnection iiop demo_connection set for both IIOP and HTTP. This needs to be done for all deployed Web applications. Deployed Web Apps Default WebAppDeploy examples myconnection /examples/ Leave the default. This must be set for each deployed Web application. The example Web application is deployed by default and can be viewed under deployed modules in the console. Restart Apache when prompted. View of DD Editor with examples.war open. Configuration is complete and ready to run the demo. Start the following partitions in order: Start JSSPartition. Start Machine2. Next open your browser and point to Execute carts. View of completed Apache settings. Note: This ensures we are being serviced by Machine2. Step 5: Configure the Web application. In order for the IIOP connection to work, the Web application needs to have a webborland.xml with the <web-deploy-path> defined. This can be done by opening the.war file with the Deployment Descriptor Editor (DD). The demo will use the pre-deployed example Web application. Open the DD Editor. Open file <install root>/var/servers/servername/partitions/m achine2/wars/examples.war Click on the.war file and select the Web Deploy Paths tab on the bottom of the window. The Service, Engine, and Host are Start Machine3. Using the browser, add the first three items to the cart. Using the console, stop the partition Machine2. Using the browser, remove the second selection. The Web container running in Machine3 will service this request. It talks to the JSS to get the current state of the cart. 6

7 View of browser after adding items to cart. View of browser after removing items from cart. View of console after stopping Machine2. VisiBroker Edition and AppServer Edition The VisiBroker Edition and AppServer Edition share clustering capabilities. This is due to the fact that the AppServer is based on VisiBroker. VisiBroker provides two services, osagent and Naming Service, for clustering. The Naming Service provides both CosNaming for CORBA applications and JNDI for EJBs. This section includes one demo with two configurations. The first uses a cluster of homogeneous EJB containers with load balancing and fail-over provided by osagent. The second configuration uses the same EJB containers with load balancing provided by the Naming Service. This configuration supports heterogeneous clustering. Homogeneous configuration Homogeneous clusters in Borland Enterprise Server are multiple partitions with the same deployed modules and services. This demo will contain two partitions, each with Naming, Transaction, and EJB container services. The Smart Agent will load balance calls to the Naming Service. Step 1: Create a new Partition called Machine1. Disable JDataStore, Session, and Web container services. Enable the partition. 7

8 Step 2: Create a new Partition called Machine2. Disable JDataStore, Session, and Web container services. Enable the partition. In the source for Enterprise1Bean, add return Machine1 to the getpartitionname method. public String getpartitionname() { return "Machine1"; } Build the project. Step 4. Deploy the bean to partition Machine1. Step5. Return to JBuilder and modify the return statement for getpartitionname. It will now return Machine2. Rebuild the project. The setup is complete. For a true homogeneous cluster, make sure all applications get deployed to both. To clearly show the load balancing and failover, requires the creation of a new session bean. The session bean has one method called getpartitionname. The method will return the partition name it is running in. public String getpartitionname() { return "Machine2"; } Build the project. Step 6. Deploy the bean to partition Machine2. Step 3: Create a new project in JBuilder. Next, create a new designer for EJB 2.0. Title the EJB module ClusterDemo. Next, create a new session bean in the designer. Add a new method call getpartitionname. It should return a String and have a remote interface. Step 7. Return to JBuilder and create an EJB test client. Leave all the defaults. In main method of the test client, add two lines of code: client.create(); System.out.println("The Partition hosting this service is " + client.getpartitionname()); Run the client multiple times. The output will round-robin between Machine1 and Machine2. 8

9 Heterogeneous clustering Heterogeneous clusters in Borland Enterprise Server are multiple partitions with different services and modules deployed. For our configuration, the difference will be the use of a centralized Naming Service. Step 1: Stop both partitions. Disable the Naming Service in each partition. Step 2: Create a new partition called NamingPartition. Disable each service except the Naming Service. Step 3: Modify vbroker.properties. <installroot>/var/servers/servername/adm/properties/partitio ns/namingpartition/ Add the following line: vbroker.naming.propbindon=1 Step 4: Enable each partition starting with NamingPartition. Return to JBuilder and run the test client multiple times. The output will round robin between Machine1 and Machine2. Naming Service fail-over The previous section exposed a single point of failure, the Naming Service. One can overcome this by enabling the Master/Slave function of the Naming Service. With this configuration, the Master Naming Service handles all requests. It stores all contexts and binding to a database. A Slave Naming Service is also running. If the Master should fail, the slave will handle future client requests. It will read in the contexts and bindings from the database. For complete details on this configuration, see the example: <installroot>/examples/vbe/ins/naming_failover Conclusion With Borland Enterprise Server, performance and application development is improved with sophisticated clustering, load balancing, fault tolerance, and fail-over. Three editions, Web, VisiBroker and AppServer, provide multiple levels of functionality designed to address the software infrastructure needs of enterprises of all sizes. 100 Enterprise Way Scotts Valley, CA Made in Borland Copyright 2002 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other marks are the property of their respective owners. Corporate Headquarters: 100 Enterprise Way, Scotts Valley, CA Offices in: Australia, Brazil, Canada, China, Czech Republic, France, Germany, Hong Kong, Hungary, India, Ireland, Italy, Japan, Korea, the Netherlands, New Zealand, Russia, Singapore, Spain, Sweden, Taiwan, the United Kingdom, and the United States