Cluster Operations

In order to administer a cluster from the Administration console, you should configure NodeManager on each server in the cluster. See Chapter 2, "Starting and Stopping," for details on how to configure NodeManager.

Start a cluster	Right-click on the icon of the cluster in the left pane of the Administration console. Select "Start this Cluster" from the drop-down list.
Stop a cluster	Right-click on the icon of the cluster in the left pane of the Administration console. Select "Stop this Cluster" from the drop-down list.

Of course, it is also possible to start and stop the cluster by starting and stopping the individual servers within the cluster. A clustered server contains information about the cluster to which it belongs in its config.xml file. It will automatically rejoin the cluster when it is started. ^[2]

^[2] Assuming, of course, that the Administration server is there to tell it what to do.

Deploying Applications

Deploying an application, EJB or what have you, to a cluster is similar to deploying to an individual server. In the left pane of the Administration console, click on the element you wish to deploy. From there, click on the Clusters tab. Click on the cluster to which you wish to deploy the element, and press the Apply button.

Note:

For WebLogic 7.0 the process is identical, but you must also click on the Deploy tab and the Deploy button contained therein.

Note that the deployment process described above assumes that your application has been developed, tested , and configured as a .war file. When running in production mode, WebLogic server will only recognize .war files. In particular, it will not recognize expanded directory structures. Make sure the setenv .cmd file contains the classpath of your application. The . war file is created with the following command:

 jar cvOf YourApplication *.war 

Under the Web Applications tab, click on the application you wish to deploy. On the Servers tab, use the arrows to select the servers on which you wish to deploy the application. Click Apply. If everything is configured correctly, the application will be copied to all the servers selected.

JDBC

JDBC connections cannot be configured to fail over automatically. However, roughly the same effect can be achieved by configuring identically named JDBC connection pools on each node in the cluster.

JNDI

When a new server joins a cluster, all the servers in the cluster work together to update their trees. Any resource that is not explicitly excluded from the clustering process ends up on all trees on all servers in the cluster. This process is transparent to both the user and the administrator.

JMS

Connection factories are associated with specific WebLogic servers. For this reason, they cannot be failed over. However, as with JDBC connection factories, roughly the same effect can be achieved by configuring a JMS server on each node in the cluster with identical copies of the associated queues and topics. (See Chapter 8 for more information about configuring JMS.)

RMI

Any RMI object can be deployed to a cluster. The same stub + skeleton mechanism that is used for remote invocation also works with cluster configurations.