Introduction
Cluster enable a Server
Deploying an Application to a cluster
Redeploying an Application to a cluster
Debugging
Troubleshooting
|
Cluster deployment This article describes how to deploy a J2EE Application to all nodes of a cluster
Introduction
Cluster enable a Server Deploying an Application to a cluster Redeploying an Application to a cluster Debugging Troubleshooting 1 Introduction
This article will explain how a J2EE Application can be deployed (or redeployed) to all active nodes of a cluster of Orion Application Servers. By deploying an Application to all active nodes of a cluster, the administrator can rely on that all nodes will be running the same version of a certain Application by just issuing a single command through the Orion Administration tool. The Orion Administration tool will then deploy the Application to all active nodes in the cluster. Throughout this article, a cluster will mean a number of cluster enabled Servers. Each cluster enabled Server will be referred to as a cluster node. The cluster service uses multicast packets to send and receive identification messages throughout the cluster. These packets are sent over the network where they are picked up by other cluster nodes using the same multicast address and port. This also means that the data is available to any application, such as a custom cluster monitor, that has registered itself as a listener on the same multicast address and port. Multicast addresses have IP addresses in the range 224.0.0.0 to 239.255.255.255. Normally, a Multicast packet has a TTL (time to live) value less than 60, which normally limits the packet to the local network and thereby making sure that they won't flood the network. For more information on multicast and related issues such as TTL, please use a resource as this as multicast in itself is out of scope for this article. In order to identify a cluster node the cluster service uses the cluster id specified in server.xml of the node. When an Application is deployed to a cluster node using the Orion Administration tool, the cluster node will first deploy the Application locally, and then deploy the Application to all known cluster nodes. Any resulting output will be returned to the Orion Administration tool. 1.1 Requirements In order for the cluster-deployment to work, the following requirements must be met: 2 Cluster enable a Server In order for a Server to be a node in a cluster, go through the following steps: 2.1 Step 1: RMI-cluster enable the Server The first step is to RMI-cluster enable the Server as described in this guide. 2.2 Step 2: Verify setup Start up the Server with the cluster.debug system properties turned on as described in listing 1 below.
If your Server is properly configured to participate in a cluster, a message like the one below should be seen when the Server is started:
If there are other active cluster nodes in the cluster, the output in listing 2 above should be followed with a message like the one below in listing 3 for each active cluster node:
3 Deploying an Application to a cluster This section will describe how a J2EE Application can be deployed to all nodes of an Orion Application Server cluster by taking advantage of the Orion Administration tool (admin.jar) bundled with the Orion distribution.
Step 1: Make sure that the Server is cluster enabled
Step 2: Make sure that the Server is running Step 3: Use the Orion Administration tool to deploy the Application 3.1 Step 1: Make sure that the Server is cluster enabled If the Server is not yet configured to participate as a node in a cluster, refer to the setup section above. 3.2 Step 2: Make sure that the Server is running Make sure that the cluster node that you will deploy the Application is running. If it is not, start it. 3.3 Step 3: Use the Orion Administration tool to deploy the Application Issue a command such as the example in listing 4 below from the Orion installation directory:
The command above would use the Orion Administration tool to connect through ormi to the Orion Application Server at localhost listening at the default port. It would try to authenticate itself using the specified username and password parameters as credentials. Once authenticated, the tool would tell the Server to take the specified file specified in the -file argument (sample.ear) and upload it to the default applications directory and then to deploy it using the deployment-name specified in the -deploymentName argument (sample) to this Server and all other active nodes of the cluster this Server participates in (as the -cluster switch was given). The Server would respond by deploying the Application locally and then to all other active cluster nodes. The resulting output from each deployment at each cluster node would then be reported back to the Orion Administration tool and presented to the user. Please notice that the example in listing 4 above only uses the bare-minimum arguments that can be used when deploying an Application through the Orion Administration tool. For information regarding all available arguments and how they can be used please see the Orion Administration tool section of the Tools Overview article. Just as with a normal Application deployment, any Orion-specific deployment configuration files included in the .ear file will be used as a base for the generated deployment configuration files the first time this Application is deployed using this deployment-name. During redeployment, the existing deployment configuration files will not be overwritten with information from the deployment configuration files included in the .ear-file per default (see the redeploy information below for instructions to change this behaviour. 4 Redeploying an Application to a cluster Redeploying Applications to a cluster is performed just as a normal deploy as outlined in the section above). If so wanted, the -ignorePreviousDeployment can be used to make sure that every cluster node will remove the Application before deploying it. This argument can be used to make sure that any included Orion specific deployment configuration files are used as base when generating the deployment configuration files for this Application deployment. The -ignorePreviousDeployment argument and other are described in more details in the Orion Administration tool section of the Tools Overview article. 5 Debugging This section describes common techniques that can be used to debug clustering-deployment. 5.1 Tracing In order to get trace information from the cluster services, start the Orion Server with the cluster.debug system property set to true, as exemplified in listing 4 below.
The cluster.debug property will list common cluster debug information to the console. In order to receive even more trace information, try to also set rmi.debug to true. 5.2 Server logs Issues the clustering service has with either sending or receiving messages can be found in the Servers server.log file per default. 6 Troubleshooting This section describes common problems and possible solutions. 6.1 Firewall issues Make sure that any firewalls allows for the Servers to communicate on the configured multicast address in both directions, both sending and receiving information. Using a simple multicast sender/receiver test application allows for testing the configured multicast address and make sure that packets can be both sent and received. 6.2 Proxies/Gateways issues As multicast packets are known to hog down networks if allowed to roam free, most proxies and gateways won't let multicast packets pass. Make sure that the multicast packets can reach all nodes in the cluster and configure any proxies/gateways accordingly. Copyright © 2005 IronFlare AB |