• No results found

Partitioning and Clustering Demonstration

N/A
N/A
Protected

Academic year: 2021

Share "Partitioning and Clustering Demonstration"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

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

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

Contents

Partitions 1

Clustering 3

Homogeneous configuration 7 Naming Service fail-over 9

(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.

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\

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

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.

(3)

<! Define a non-SSL HTTP/1.1 Connector on port 8080 -->

<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.

Choose a name and a server for the cloned 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.

(4)

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.

View of console after step one.

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 8080 -->

<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

(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. <Service name="IIOP"> <Connector className="org.apache.catalina.connector.iiop.Ii opConnector" name="demo_connection" debug="0" />

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 8080 -->

<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"/>

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:

(6)

IIOP connection

Default—WebAppConnection myConnection iiop tc_inst1 WebAppConnection myConnection iiop demo_connection

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 completed Apache settings.

Step 5: Configure the Web application. In order for the IIOP connection to work, the Web application needs to have a web-borland.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

set for both IIOP and HTTP. This needs to be done for all deployed Web applications.

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

http://localhost/examples/jsp Execute carts.

Note: This ensures we are being serviced by Machine2. 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.

(7)

View of browser after adding items to cart.

View of console after stopping Machine2.

View of browser after removing items from cart.

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.

(8)

Step 2: Create a new Partition called Machine2. Disable JDataStore, Session, and Web container services. Enable the partition.

The setup is complete.

For a true homogeneous cluster, make sure all applications get deployed to both. To clearly show the load balancing and fail-over, 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.

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.

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.

public String getPartitionName() { return "Machine2";

}

Build the project.

Step 6. Deploy the bean to partition Machine2.

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.

(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.

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 95066-3249 • 831-431-1000 • www.borland.com • 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. • 13048

100 Enterprise Way

Scotts Valley, CA 95066-3249 www.borland.com | 831-431-1000

References

Related documents

innovation in payment systems, in particular the infrastructure used to operate payment systems, in the interests of service-users 3.. to ensure that payment systems

This essay asserts that to effectively degrade and ultimately destroy the Islamic State of Iraq and Syria (ISIS), and to topple the Bashar al-Assad’s regime, the international

Product Name Technical Licences Technical Licenses Required/ Optional GIS 8.0 Required GIS_INTERACTIONSERVICE 8.0 Required ics_custom_media_channel 8.0

National Conference on Technical Vocational Education, Training and Skills Development: A Roadmap for Empowerment (Dec. 2008): Ministry of Human Resource Development, Department

19% serve a county. Fourteen per cent of the centers provide service for adjoining states in addition to the states in which they are located; usually these adjoining states have

The total coliform count from this study range between 25cfu/100ml in Joju and too numerous to count (TNTC) in Oju-Ore, Sango, Okede and Ijamido HH water samples as

If the filer is aware that the subject has an account involved in the suspicious activity with a financial institution listed in Part III but the account number is unknown, record

The projected gains over the years 2000 to 2040 in life and active life expectancies, and expected years of dependency at age 65for males and females, for alternatives I, II, and