Administering WebLogic Clusters

 

This topic contains the following sections:

• Overview

• Plan Your Cluster Architecture

• Obtain a Cluster License

• Obtain Network Addresses

• Install WebLogic Server

• Define Machine Names

• Create WebLogic Server Instances

• Create a New Cluster

• Configure Replication Groups

• Configure Load Balancing Hardware (Optional)

• Configure Proxy Plug-ins (Optional)

• Deploy Web Applications and EJBs

• Starting a WebLogic Server Cluster

Overview

Follow these steps to configure a cluster using WebLogic Server version 6.0:

1. Plan Your Cluster Architecture.

2. Obtain a Cluster License.

3. Obtain Network Addresses.

4. Install WebLogic Server.

5. Define Machine Names.

6. Create WebLogic Server Instances.

7. Create a New Cluster.

8. Configure Replication Groups.

9. Configure Load Balancing Hardware (Optional) or Configure Proxy Plug-ins (Optional).

10. Deploy Web Applications and EJBs.

Plan Your Cluster Architecture

Read through the Planning WebLogic Server Clusters section to determine the clustered architecture that best suits your web application. The sections that follow focus on the recommended architectures described in that section.

If you want to set up a cluster that utilizes a layer of HTTP servers, you will need to configure those server systems as well as install the corresponding WebLogic Server proxy plug-ins. See the BEA WebLogic Server Administration Guide for instructions.

Obtain a Cluster License

To use WebLogic Server in a clustered configuration, you must have a special cluster license. Contact your BEA representative for information on obtaining a cluster license.

Obtain Network Addresses

Before you begin configuring a WebLogic Server cluster, obtain the IP addresses or DNS names described below.

WebLogic Server DNS names

Each WebLogic Server in the cluster requires a unique IP address or DNS name. To avoid address translation errors, you should bind individual servers to DNS names rather than IP addresses if:

• Clients will connect to the cluster through a firewall, or

• You are placing a firewall between a servlet cluster and EJB cluster

The DNS names must be the same both inside and outside the firewall, to avoid translation errors. An alternative to using DNS names is to use identical IP addresses both inside and outside of the firewall. However, publicizing IP addresses is not recommended as it may compromise the security of the web application.

Note: If you bind server instances to DNS names, do not use a DNS name that is the same as a Windows NT machine that hosts one or more servers. If you bind a server to the machine's DNS name, requests may go to the wrong address.

Administration Server IP address

All WebLogic Server instances in the same cluster utilize the same administration server for configuration and monitoring. When you start individual servers that join a cluster, you must specify the administration server to use.

If you have not already done so, obtains the name and IP address of the administration server you will use for the cluster.

Cluster Multicast Address

Multiple WebLogic Server version 6.0 clusters can share a dedicated IP multicast address. It is important that no other applications utilize the cluster's multicast.

If you are setting up the Recommended Multi-tier Architecture with a firewall between the clusters, you will need two dedicated multicast addresses: one for the presentation (servlet) cluster and one for the object cluster. Using two multicast addresses ensures that the firewall does not interfere with cluster communication.

Cluster DNS Name

In a production environment, client applications should access the cluster using a DNS name that contains the IP addresses or DNS names of each WebLogic Server instance in the cluster. Create a new DNS name for your cluster using the addresses you obtained in WebLogic Server DNS names.

When clients obtain an initial JNDI context by supplying the cluster DNS name, weblogic.jndi.WLInitialContextFactory obtains the list of all addresses that are mapped to the DNS name. This list is cached within WebLogic Server, and new initial context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a server in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if WebLogic Server is unable to reach any address in its cache.

Using a cached list of addresses avoids certain problems with relying on DNS round-robin alone. For example, DNS round-robin continues using all addresses that have been mapped to the domain name, regardless of whether or not the addresses are reachable. By caching the address list, WebLogic Server can remove addresses that are unreachable, so that connection failures aren't repeated with new initial context requests.

Cluster Address List

If you will be using the cluster only for development and testing, you can instead connect to the cluster using explicit IP addresses. For example, you can provide a comma-separated list of IP addresses where you would normally use a single IP address:

192.168.0.50,192.168.0.51,192.168.0.52:7001

Note: Using a comma-separated list is only recommended for developmental use. For actual client applications, use either a dedicated DNS name or load balancing hardware to connect to the cluster.

Assigning Names to Server Instances

Each server instance in your overall WebLogic environment should have a unique name. Regardless of the domain or cluster in which a server instance resides, or whether it is an Administration Server or a Managed Server, make sure that its name is unique.

Install WebLogic Server

If you have not already done so, install the WebLogic Server 6.0 product. For multihomed cluster installations, you can install a single WebLogic Server distribution under the /bea directory to use for all clustered instances. For remote, networked machines, perform the installation on each WebLogic Server host.

Installations for clustered WebLogic Server instances must also have a valid cluster license. See Obtain a Cluster License for more details.

Note: Do not use a shared filesystem and a single installation to run multiple WebLogic Server instances on separate machines. Using a shared filesystem introduces a single point of contention for the cluster. All servers must compete to access the filesystem (and possibly to write individual log files). Moreover, should the shared filesystem fail, you may be unable to start clustered servers.

Define Machine Names

WebLogic Server version 6.0 uses configured machine names to determine whether or not two server instances reside on the same physical hardware. Machine names are generally used with multihomed machines that host WebLogic Server instances. If you do not define machine names for such installations, each instance is treated as if it reside on separate physical hardware. This can negatively affect the selection of servers to host secondary HTTP session state replicas, as described in Using Replication Groups.

Before creating new WebLogic Server instances, use the following instructions to define the names of individual machines that will host the server instances:

1. Boot the administration server for your system. See Administration Server for more information.

2. Start the administration console using the instructions in Starting the Administration Console.

3. Select the Machines node.

4. Select Create a new Machine... to define a Windows NT machine, or select Create a new UNIX Machine...

5. Type in a unique name for the new machine in the Name attribute field.

6. Click Create to create the new machine definition.

7. If you wish to configure other attributes for a new UNIX server, refer to the online help for the administration console.

8. Repeat these steps for each machine that will host one or more WebLogic Server instances in the cluster.

Create WebLogic Server Instances

Before servers can join a cluster, you must create new definitions for each server instance using the WebLogic Server administration console. Follow these steps:

1. Boot the administration server for your system. See Administration Server for more information.

2. Start the administration console using the instructions in Starting the Administration Console.

3. Select the Servers node.

4. Select Create a new Server...

5. Type in values for the following attribute fields:

   • Name: Enter a name to use for this server in the Administration Console. You will use this name in the startup command to indicate which server you are booting.

     Assign a unique name to each server instance you create. Do not give a server instance a name that is the same as the name of any other Managed Server or Administrative Server in your WebLogic Server environment.

   • Listen Port: Enter the port number used to connect to this server. All servers in a given cluster must use the same port number.

   • Listen Address: Enter the DNS name or IP address to bind to this server.

6. For the Machine attribute, select the machine on which the new server resides. The Machine attribute lists all machine names that you created in Define Machine Names.

7. Click Create to create the new server configuration.

8. If you wish to configure other attributes of the new server, refer to Server Configuration Tasks.

9. Repeat these steps for each WebLogic Server that will participate in the cluster.

Create a New Cluster

After you have created the individual WebLogic Server instances, follow these steps to configure a new cluster:

1. Open the Administration Console.

2. Select the Clusters node.

3. Select Create a new Cluster...

4. Type in values for the following attribute fields:

   • Name: Enter the name to use for this cluster in the Administration Console. You will use this name to assign membership to the cluster and configure other cluster attributes.

   • Cluster Address: Enter the DNS name (containing the IP addresses or DNS names of all individual WebLogic Server instances in the cluster) to use for the cluster.

   • Default Load Algorithm: Type in the default load algorithm to use for this cluster, or accept the default.

5. Click Create to create the new cluster configuration.

6. Select the Multicast tab.

7. Type in the cluster's multicast address in the Multicast Address attribute field.

8. Apply the changes.

Configure Replication Groups

If your cluster will host servlets or stateful session EJBs, you may want to create replication groups of WebLogic Server instances to host the session state replicas. To do so, follow the instructions in Cluster Configuration Tasks to determine which servers should participate in each replication group, and to determine each server's preferred replication group.

To configure replication groups for a WebLogic Server instance:

1. Open the Administration Console.

2. Select the Servers node.

3. Select the server to configure.

4. Select the Cluster tab.

5. Type in values for the following attribute fields:

   • Replication Group: Enter the replication group name to which this server belongs.

   • Preferred Secondary Group: Enter the name of the replication group you would like to use to host replicated HTTP session states for this server.

6. Apply the changes.

Configure Load Balancing Hardware (Optional)

If you are using a hardware load balancing solution with HTTP session state replication, you must configure your load balancer to support WebLogic Server session cookies. The configuration steps depend on the type of persistence cookie persistence mechanism used on the load balancing hardware. The following table shows possible configurations.

	Persistence Type
Active Cookie Persistence		Passive Cookie Persistence
Load Balancer Overwrites Cookie	Load Balancer Inserts Additional Cookie
Not supported	No configuration required	Specify offset and differentiator

Using Active Cookie Persistence

WebLogic Server clusters doe not support active cookie persistence mechanisms that overwrite or in any way modify the WebLogic HTTP session cookie.

If the load balancer's active cookie persistence mechanism works by adding its own cookie to the client session, no additional configuration is required to use the load balancer with a WebLogic Server cluster.

Using Passive Cookie Persistence

If a load balancer uses passive cookie persistence, it can use a differentiator string in the WebLogic session cookie to associate a client with the server hosting its primary HTTP session state. The basic format of a cookie written for HTTP session state replication is:

To configure your load balancer, identify the differentiator by specifying its offset (53 bytes) and length (19 bytes) on the load balancing hardware.

Note: The default session ID length is 52 bytes. If you change the ID length in the <session-descriptor> element, make sure you specify the correct offset value when configuring your load balancer. The correct offset equals the ID length plus 1 byte for the delimiter character.

Configure Proxy Plug-ins (Optional)

If you are using web servers with WebLogic proxy plug-ins (or the HttpClusterServlet) to access the cluster, use the instructions in the Administration Guide to configure your proxy software. Keep in mind that all web servers that proxy requests to the cluster must be configured identically.

Deploy Web Applications and EJBs

Use the instructions in Deploying and Configuring Web Applications to deploy your web application and/or EJBs to the cluster. When you select a target for the application or EJB make sure you use the cluster name you specified in Create a New Cluster, rather than individual WebLogic Server instances in the cluster. Using the cluster name ensures that the application or EJB is deployed homogeneously throughout the cluster.

Clustered objects in WebLogic Server version 6.0 must be deployed homogeneously. If the object contains a replica-aware stub, use the Administration Console to deploy it using the cluster name. Otherwise, deploy non replica-aware ("pinned") objects only to individual servers.

The Administration Console automates deploying replica-aware objects to clusters. When you deploy an application or object to a cluster, the Administration Console automatically deploys it to all members of the cluster (whether they are local to the Administration Server machine or they reside on remote machines).

Starting a WebLogic Server Cluster

To start a WebLogic Server instance that participates in a cluster, you use the same procedure as you would for starting any managed server. You simply identify the administration server the instance should use. All configuration information for the server is obtained from the config.xml file associated with the administration server.

The basic process for starting up a cluster is:

1. Start the administration console for the domain in which the cluster resides. See Administration Server for more information.

2. Start individual, clustered servers instances as managed WebLogic Servers. For example:

   % java -ms64m -mx64m -classpath $CLASSPATH
   -Dweblogic.Domain=mydomain -Dweblogic.Name=clusterServer1
   -Djava.security.policy==/bea/weblogic600/lib/weblogic.policy
   -Dweblogic.management.server=192.168.0.101:7001 -Dweblogic.management.username=system
   -Dweblogic.management.password=systemPassword weblogic.Server

   The server's cluster configuration is stored by the administration server, so you do not need to explicitly include address binding or multicast information in the command line. You do, however, need to specify:

   • weblogic.Name, to identify the clustered instance you want to start.

   • weblogic.management.server, to identify the host and port number of the administration server that stores the clustered instance's configuration.

   • weblogic.management.username, to specify a username to connect to the administration server.

   • weblogic.management.password, to specify the user's password.

     See Starting a WebLogic Managed Server for more details.