Administering WebLogic Clusters

 

The following sections contain guidelines and instructions for configuring a WebLogic Server cluster:

• Before You Start

• Cluster Implementation Procedures

 

---

Before You Start

This section summarizes prerequisite tasks and information for setting up a WebLogic Server cluster.

Obtain a Cluster Licence

Installations for clustered WebLogic Server instances must have a valid cluster license. If you do not have a cluster license, contact your BEA sales representative.

Understand the Configuration Process

The information in this section will be most useful to you if you have a basic understanding of the cluster configuration process and how configuration tasks are accomplished.

You perform all configuration for a WebLogic Server 6.1 cluster using the Administration Console. The configuration information for the cluster in stored in the config.xml file for the domain that contains the cluster. The Administration Console also manages deployment of objects and Web applications to members of the cluster.

For general information about configuring WebLogic Server 6.1, see WebLogic Server Administration Guide.

Determine Your Cluster Architecture

Determine what cluster architecture best suits your needs. Key architectural decisions include:

• Should you combine all application tiers in a single cluster or segment your application tiers in separate clusters?

• How will you balance the load among server instances in your cluster? Will you:

  • Use basic WebLogic Server load balancing,

  • Implement a third-party load balancer, or

  • Deploy the Web tier of your application on one or more secondary HTTP servers, and proxy requests to it?

• Should you define your Web applications De-Militarized Zone (DMZ) with one or more firewalls?

To guide these decisions, see Planning WebLogic Server Clusters.

The architecture you choose affects how you set up your cluster. The cluster architecture may also require that you install or configure other resources, such as load balancers, HTTP servers, and proxy plug-ins.

Consider Your Network and Security Topologies

Your security requirements form the basis for designing the appropriate security topology. For a discussion of several alternative architectures that provide varying levels of application security, see Security Options for Cluster Architectures.

Notes: Some network topologies can interfere with multicast communication. If you are deploying a cluster across a WAN, see Multicast Requirements for WAN Clustering.

Avoid deploying server instances in a cluster across a firewall. For a discussion of the impact of tunneling multicast traffic through a firewall, see Firewalls Can Break Multicast Communication.

Choose Machines for the Cluster Installation

Identify the machine or machines where you plan to install WebLogic Server—throughout this section we refer to such machines as "hosts"—and ensure that they have the resources required. System and software prerequisites are listed in "Preparing to Install WebLogic Server" in Installing BEA WebLogic Server.

Note: Do not install WebLogic Server on machines that have dynamically assigned IP addresses.

WebLogic Server Instances on Multi-CPU machines

BEA WebLogic Server has no built-in limit for the number of server instances that can reside in a cluster. Large, multi-processor servers such as Sun Microsystems, Inc. Sun Enterprise 10000 can host very large clusters or multiple clusters.

In most cases, WebLogic Server clusters scale best when deployed with one WebLogic Server instance for every two CPUs. However, you should test the actual deployment with your target Web applications to determine the optimal number and distribution of server instances. For additional information, see "Performance Considerations for Multi-CPU Machines" in BEA WebLogic Server Performance and Tuning.

Check Host Machines' Socket Reader Implementation

For best socket performance, configure WebLogic Server host machines to use the native socket reader implementation for your operating system, rather than the pure-Java implementation. To understand why, and for instructions for configuring native sockets or optimizing pure-Java socket communications, see Peer-to-Peer Communication Using IP Sockets.

Identify Names and Addresses

During the cluster configuration process, you supply addressing information—IP addresses or DNS names—for the cluster and its members.

For information on intra-cluster communication, and how it enables load balancing and failover, see Server Communication in a Cluster.

When you set up your cluster, you must provide location information for:

• Administration Server

• Managed Servers

• Multicast location

Read the sections that follow for an explanation of the information you must provide, and factors that influence the method you use to identify resources.

Avoiding Listen Address Problems

As you configure a cluster, you can specify address information for the cluster, and the server instances that comprise it, using either IP addresses or DNS names.

DNS Names or IP Addresses?

Consider the purpose of the cluster when deciding whether to use DNS names or IP addresses. For production environments, the use of DNS names is generally recommended. The use of IP addresses can result in translation errors if:

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

• You have a firewall between the presentation and object tiers, for example, you have a servlet cluster and EJB cluster with a firewall in between, as described in the recommended multi-tier cluster.

You can avoid translation errors by binding the address of an individual server instance to a DNS name. Make sure that a server instance's DNS name is identical on each side of firewalls in your environment, and do not use a DNS name that is also the name of an NT system on your network.

For more information about using DNS names instead of IP addresses, see Firewall Restrictions.

When Internal and External DNS Names Vary

If the internal and external DNS names of a WebLogic Server instance are not identical, use the ExternalDNSName attribute for the server instance to define the server's external DNS name. Outside the firewall the ExternalDNSName should translate to external IP address of the server instance. Set this attribute in the Administration Console using the Server—>Configuration—>General tab. See Server—>Configuration—>General in Administration Console Online Help.

Localhost Considerations

If you identify a server instance's Listen Address as localhost, non-local processes will not be able to connect to the server instance. Only processes on the machine that hosts the server instance will be able to connect to the server instance. If the server instance must be accessible as localhost (for instance, if you have administrative scripts that connect to localhost), and must also be accessible by remote processes leave the Listen Address blank. The server instance will determine the address of the machine and listen on it.

Assigning Names to WebLogic Server Resources

Make sure that each configurable resource in your WebLogic Server environment has a unique name. Each domain, server, machine, cluster, JDBC connection pool, virtual host, or other resource must have a unique name.

Administration Server Address and Port

Identify the DNS name or IP address and Listen Port of the Administration Server you will use for the cluster.

The Administration Server is the WebLogic Server instance used to configure and manage all the WebLogic Server instances in its domain. When you start a server instance that belongs to a cluster, you identify the host and port of its Administration Server.

Managed Server Addresses and Listen Ports

Identify the DNS name or IP address of each Managed Server planned for your cluster.

Each Managed Server in a cluster must have a unique IP address and the same Listen Port number. A machine that hosts multiple clustered server instances must be multihomed to provide an IP address for each server instance.

Cluster Multicast Address and Port

Identify the address and port you will dedicate to multicast communications for your cluster.

Server instances in a cluster communicate with each other using multicast—they use multicast to announce their services, and to issue periodic heartbeats that indicate continued availability.

The multicast address for a cluster should not be used for any purpose other than cluster communications. If the machine where the cluster multicast address exists hosts or is accessed by cluster-external programs that use multicast communication, make sure that those multicast communications use a different port than the cluster multicast port.

Multicast and Multiple Clusters

Multiple clusters on a network may share a multicast address and multicast port combination if necessary.

Multicast and Multi-Tier Clusters

If you are setting up the Recommended Multi-Tier Architecture, described in Planning WebLogic Server Clusters, 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 Address

When you configure a cluster using the Administration Console, you supply a cluster address that identifies the Managed Servers in the cluster.

The cluster address is used in entity and stateless beans to construct the host name portion of URLs. If the cluster address is not set, EJB handles may not work properly.

The cluster address can be specified as:

• A DNS name that maps to the DNS names or IP addresses of the Managed Servers in the cluster.

• A list that contains the DNS name or IP address of each Managed Server in the cluster, as shown in the examples below:

DNSName1,DNSName2,DNSName3

IPaddress1,IPaddress2;IPaddress3

For production environments, BEA recommends that you set the cluster address to a DNS name that contains the host names or addresses of the Managed Servers in the cluster. If you do not define the cluster address as a DNS name that maps to the Managed Servers in the cluster, failover will not work for entity beans and EJB handles, as described in Failover for Entity Beans and EJB Handles.

Defining the cluster address as a comma-separated list of addresses is not recommended for production environments.

Note: The Administration Server should not participate in a cluster. Ensure that the Administration Server's IP address is not included in the cluster-wide DNS name. For more information, see Administration Server Considerations.

 

---

Cluster Implementation Procedures

This section describes how to get a clustered application up and running, from installation of WebLogic Server through initial deployment of application components.

Configuration Roadmap

We present a typical sequence of tasks for a cluster implementation, and highlight key considerations that influence your configuration choices. The exact process you follow is driven by the unique characteristics of your environment and the nature of your application. These are the tasks described in this section:

• Install WebLogic Server

• Define Machine Names (Optional)

• Create WebLogic Server Instances

• Create a New Cluster

• Configure Load Balancing Hardware (Optional)

• Configure Proxy Plug-Ins (Optional)

• Configure Replication Groups (Optional)

• Configure Clustered JDBC

• Configure JMS

• Deploy Web Applications and EJBs

• Configure In-Memory HTTP Replication

• Additional Configuration Topics

Not every step is required for every cluster implementation. Additional steps may be necessary in some cases.

Install WebLogic Server

If you have not already done so, install the WebLogic Server 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 Licence 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 (Optional)

WebLogic Server 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 resides 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. For instructions, see "Starting the WebLogic Administration Server" in WebLogic Server Administration Guide.

2. Start the administration console using the instructions in "Starting the Administration Console" in WebLogic Server Administration Guide.

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. Enter 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 Administration Console Online Help.

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. For instructions, see "Starting the WebLogic Administration Server" in WebLogic Server Administration Guide.

2. Start the administration console using the instructions in "Starting the Administration Console" in WebLogic Server Administration Guide.

3. Select the Servers node.

4. Select Configure a new Server.

5. Enter values for the following attribute fields:

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

     See Assigning Names to WebLogic Server Resources.

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

     See Avoiding Listen Address Problems.

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

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" in WebLogic Server Administration Guide.

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 Configure a new Cluster.

4. Enter 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. For more information, see Cluster Address.

   • Default Load Algorithm: Enter 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. Enter the cluster's multicast address in the Multicast Address attribute field.

8. Apply the changes.

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 identify the Administration Server the server instance should use. The configuration information for the server instance 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. For instructions, see "Starting the Administration Console" in WebLogic Server Administration Guide.

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

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

   The server instance'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" in WebLogic Server Administration Guide for more details.

3. As the clustered instance boots, monitor the log messages to see that it joins the cluster. The instance begins by binding the multicast address and common port number of the cluster:

   Starting Cluster Service ....
   

   <Jul 25, 2001 6:35:17 PM PDT> <Notice> <WebLogicServer> <ListenThread listening 
   on port 7001, ip address 172.17.13.25>
   

   <Jul 25, 2001 6:35:18 PM PDT> <Notice> <Cluster> <Listening for multicast messages 
   (cluster MyCluster) on port 7001 at address 239.0.0.84>
   

   <Jul 25, 2001 6:35:18 PM PDT> <Notice> <WebLogicServer> <Started WebLogic Managed 
   Server "MyServer-1" for domain "mydomain" running in Production Mode>
   

4. To verify that all clustered instances are participating in the cluster, open the Administration Console. Select the cluster, click the Monitoring tab, then select Monitor server participation in cluster. If one or more of the started server instances do not appear in the display, verify that the server instances have been configured with the correct multicast address and port number.

Configure Load Balancing Hardware (Optional)

This section provides general guidelines for setting up an external load balancer. For instructions on setting up a BIG-IP load balancer, see Configuring BIG-IP^TM Hardware with Clusters

For information about how WebLogic Server accesses clustered servlets and JSPs in a configuration that includes load balancing hardware, see Accessing Clustered Servlets and JSPs with Load Balancing Hardware.

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.

Using Active Cookie Persistence

WebLogic Server clusters do not support active cookie persistence mechanisms that overwrite or 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

A load balancer that uses passive cookie persistence can use a string constant in the WebLogic session cookie to associate a client with the server instance hosting its primary HTTP session state. The string constant uniquely identifies a server instance in the cluster. You must configure the load balancer with the offset and length of the string constant. The correct values for the offset and length depend on the format of the session cookie.

Understanding the Session Cookie

The basic format of a session cookie is:

 

where:

• Random Session ID is a randomly generated identifier of the HTTP session. The length of the value is configurable, by setting the IDLength parameter in the <session-descriptor> element in the weblogic.xml file for an application. By default, the length of the Random Session ID is 52 bytes.

• String Constant identifies the WebLogic Server instance hosting the session, including its host machine and listen ports.

  In a non-clustered environment, the string constant can be up to 60 bytes long, with this format:

  Primary_JVMID_Differentiator!HOST!PORT!SSLPORT

  In a clustered environment, the string constant specifies both the primary and the secondary WebLogic Server instances for the session—it may be up to 120 bytes long, with this format:

  Primary_JVMID_Differentiator!Host!Port!SSLPort!Secondary_JVMID_Differentiator!Host!Port!SSLPort

  The first 19 bytes of the string constant uniquely identify the primary WebLogic Server instance for the initial release of WebLogic Server version 6.1. For WebLogic Server version 6.1 Service Pack 1 and later, the first 10 bytes are sufficient to identify the server instance.

Session Cookie for WAP-Enabled Applications

Because many wireless devices do not support cookies, an alternative method of session tracking—URL rewriting—can be used for WAP applications. Because wireless devices often support only a limited length URL, use of URL rewriting for WAP-enabled applications requires a reduction in the length of session parameters. For more information about using URL rewriting for wireless applications, see "An Alternative Session-Tracking Method—URL Rewriting" in Programming WebLogic Server for Wireless Services.

There are two techniques that are used to shorten session parameters that can affect how you configure your load balancer:

• The length of the Random Session ID can be shortened by editing the value of the IDLength parameter in the <session-descriptor> element in the weblogic.xml file for your application application. The minimum length for Random Session ID is 8 bytes.

• The length of the session parameters that specify the primary and secondary server instances can be shortened by setting the WAPEnabled parameter in the config.xml file for the domain to "true". When WAPEnabled is "true", the primary and secondary server instances are identified in the cookie by short hash codes.

Shortening the Random Session ID and the session parameters that specify the server instances results in a string constant with this format:

Rand_Sess_ID!Primary_JVMID_HASH!Secondary_JVMID_HASH

where the length of:

Rand_Sess_ID is 8 bytes

Primary_JVMID_HASH is 8 to 10 bytes

SECONDARY_JVMID_HASH is 8 to 10 bytes

Configuring Load Balancer

If you have not changed the length of the Random Session ID from its default length of 52 bytes, use the facilities of your load balancer to set the offset and length of the string constant as described below:

• string constant offset—set to 53 bytes, the default Random Session ID length plus 1 byte for the delimiter character.

• string constant length—BEA recommends that you set the length of the string constant to at least 19 bytes, a length sufficient to ensure that the primary server instance can be uniquely identified.

If your application or environmental requirements dictate that you change the length of the Random Session ID from its default value of 52 bytes, you must set the string constant offset on the load balancer accordingly. The offset for the string constant must equal the length of the Random Session ID plus 1 byte for the delimiter character.

If your cluster hosts a WAP-enabled application, there are session parameter considerations that might affect how you configure your load balancer. For details, see Configuring Load Balancer for Reduced Length Session Parameters (WAP-Enabled).

Configuring Load Balancer for Reduced Length Session Parameters (WAP-Enabled)

If WAPEnabled is set to "true" for your domain, and IDLength is 8 bytes, set the offset and length of the string constant as follows:

• String constant offset—set to 9 bytes, the default Random Session ID length plus 1 byte for the delimiter character.

• String constant length—Set the length of the string constant to 8, the minimum length of the hash code that identifies the primary server instance.

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 WebLogic Server Administration Guide to configure your proxy software. Keep in mind that all Web servers that proxy requests to the cluster must be configured identically. For information about connection and failover using the proxy plug-in, see Accessing Clustered Servlets and JSPs Using a Proxy.

Configure Replication Groups (Optional)

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 Using Replication Groups to determine which server instances should participate in each replication group, and to determine each server instance'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 instance to configure.

4. Select the Cluster tab.

5. Enter values for the following attribute fields:

   • Replication Group: Enter the replication group name to which this server instance 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 instance.

6. Apply the changes.

Configure Clustered JDBC

This section provides instructions for configuring JDBC components using the Administration Console. The choices you make as you configure the JDBC components are reflected in the config.xml file for the WebLogic Server domain that contains the cluster.

First you create the connection pools and optionally a multipool, then you create the data source. When you create a data source object, you specify a connection pool or multipool as one of the data source attributes. This associates that data source with one specific connection pool or multipool.

• For an overview of how JDBC objects work in a WebLogic Server cluster, see JDBC Connections.

• For a description of how clustered JDBC can increase application availability, see Failover and JDBC Connections

• For a description of how clustered JDBC supports load balancing, see Load Balancing and JDBC Connections

Clustering Connection Pools

Perform these steps to set up a basic connection pool in a cluster:

1. Create a connection pool.

   For instructions, see "Configure a JDBC Connection Pool" in Administration Console Online Help.

2. Assign the connection pool to the cluster.

   For instructions, see "Assign a JDBC Connection Pool to One or More Servers or Clusters".

3. Create the data source. Specify the connection pool created in the previous step in the Pool Name attribute.

   For instructions, see "Configure a JDBC Data Source" in Administration Console Online Help

4. Assign the data source to the cluster.

   For instructions, see "Assign a JDBC Data Source".

Clustering Multipools

Perform these steps to create a clustered multipool for increased availability, and optionally, load balancing.

Note: Multipools are typically used to provide increased availability and load balancing of connections to replicated, synchronized instances of a database. For more information, see JDBC Connections.

1. Create two or more connection pools.

   For instructions, see "Configure a JDBC Connection Pool" in Administration Console Online Help.

2. Assign each connection pool to the cluster.

   For instructions, see "Assign a JDBC Connection Pool to One or More Servers or Clusters".

3. Create a multipool. Assign the connection pools created in the previous step to the multipool.

   For instructions, see "Configure a JDBC MultiPool".

4. Assign the Multipool to the cluster.

   For instructions, see "Assign a JDBC MultiPool to One or More Servers or Clusters".

5. Create the data source. Specify the multipool created in the previous step in the Pool Name attribute.

   For instructions, see "Configure a JDBC Data Source".

6. Assign the data source to the cluster.

   For instructions, see "Assign a JDBC Data Source".

Configure JMS

Follow the instructions in "Managing JMS" in the Administration Guide to configure JMS for a cluster. Adhere to the following guidelines:

• JMS Servers—You cannot deploy a JMS server on more than one Managed Server.

• Destinations—You cannot deploy the same destination on more than one JMS server.

• Connection Factories—Each connection factory can be deployed on multiple WebLogic Servers.

• Managed Servers—JMS clients depend on unique WebLogic Server names to successfully access clustered WebLogic Servers—even when the servers reside in different domains. Make sure that all Managed Servers that JMS clients contact have unique server names.

Configure In-Memory HTTP Replication

To support automatic failover for servlets and JSPs, WebLogic Server replicates HTTP session states in memory.

Note: WebLogic Server can also maintain the HTTP session state of a servlet or JSP using file-based or JDBC-based persistence. For more information on these persistence mechanisms, see "Configuring Session Persistence" in Assembling and Configuring Web Applications.

In-memory HTTP Session state replication is controlled separately for each application you deploy. The parameter that controls it—PersistentStoreType— appears within the session-descriptor element, in the WebLogic deployment descriptor file, weblogic.xml, for the application.

domain_directory/applications/application_directory/Web-Inf/weblogic.xml

To use in-memory HTTP session state replication across server instances in a cluster, set the PersistentStoreType to replicated. The fragment below shows the appropriate XML from weblogic.xml.

<session-descriptor> 

	<session-param> 

		<param-name> PersistentStoreType </param-name> 

		<param-value> replicated </param-value> 

	</session-param> 

</session-descriptor>

Deploy Web Applications and EJBs

Use the instructions in Packaging and Deploying Web Applications to deploy your Web application and/or EJBs to the cluster. When you select a target for the application or EJB, choose 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 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 server instances.

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

When you deploy an application with the Administration Console, the administration server sends a copy of the application file(s) to the targeted server instances, which then load the application.

Note: If deployment to a server instance fails, the deployment state across the target server instances may be inconsistent.

To learn about how clustered objects are bound in the cluster-wide JNDI tree, see Creating the Cluster-Wide JNDI Tree and Updating the JNDI Tree.

Additional Configuration Topics

The sections below contain useful tips for particular cluster configurations.

Configure IP Sockets

For best socket performance, BEA recommends that you use the native socket reader implementation, rather than the pure-Java implementation, on machines that host WebLogic Server instances.

If you must use the pure-Java socket reader implementation for host machines, you can still improve the performance of socket communication by configuring the proper number of socket reader threads for each server instance and client machine.

• To learn more about how IP sockets are used in a cluster, and why native socket reader threads provide best performance, see Peer-to-Peer Communication Using IP Sockets, and Client Interaction with the Cluster-Wide JNDI Tree.

• For instructions on how to determine how many socket reader threads are necessary in your cluster, see Determining Potential Socket Usage. If you are deploying a servlet cluster in a multi-tier cluster architecture, this has an effect on how many sockets you require, as described in Configuration Notes for Multi-Tier Architecture.

The sections that follow have instructions on how to configure native socket reader threads for host machines, and how to set the number of reader threads for host and client machines.

Configure Native IP Sockets Readers on Machines that Host Server Instances

To configure a WebLogic Server instance to use the native socket reader threads implementation:

1. Open the WebLogic Server Console.

2. Select the Servers node.

3. Select the server instance to configure.

4. Select the Tuning tab.

5. Check the Enable Native IO box.

6. Apply the changes.

Set the Number of Reader Threads on Machines that Host Server Instances

By default, a WebLogic Server instance creates three socket reader threads upon booting. If you determine that your cluster system may utilize more than three sockets during peak periods, increase the number of socket reader threads:

1. Open the WebLogic Server Console.

2. Select the Servers node.

3. Select the server instance to configure.

4. Select the Tuning tab.

5. Edit the percentage of Java reader threads in the Socket Readers attribute field. The number of Java socket readers is computed as a percentage of the number of total execute threads (as shown in the Execute Threads attribute field).

6. Apply the changes.

   Note: Due to a known problem in WebLogic Server 6.1 you must also set the desired thread pool size as a command line option when starting a Managed Server. For more information and instructions, see "CR179419" in WebLogic Server 6.1 Release Notes.

Set the Number of Reader Threads on Client Machines

On client machines you can configure the number of socket reader threads in the Java Virtual Machine (JVM) that runs the client. Specify the socket readers by defining the -Dweblogic.ThreadPoolSize=value and -Dweblogic.ThreadPoolPercentSocketReaders=value options in the Java command line for the client.

Configure Multicast Time-To-Live (TTL)

If your cluster spans multiple subnets in a WAN, the value of the Multicast Time-To-Live (TTL) parameter for the cluster must be high enough to ensure that routers do not discard multicast packets before they reach their final destination. The Multicast TTL parameter sets the number of network hops a multicast message makes before the packet can be discarded. Configuring the Multicast TTL parameter appropriately reduces the risk of losing the multicast messages that are transmitted among server instances in the cluster.

For more information about planning your network topology to ensure that multicast messages are reliably transmitted seeMulticast Requirements for WAN Clustering.

To configure the Multicast TTL for a cluster, change the Multicast TTL value in the Multicast tab for the cluster in the Administration Console. The config.xml excerpt below shows a cluster with a Multicast TTL value of three. This value ensures that the cluster's multicast messages can pass through three routers before being discarded:

<Cluster

	Name="testcluster"

	ClusterAddress="wanclust"

	MulticastAddress="wanclust-multi"

	MulticastTTL="3"

/>

Configure Multicast Buffer Size

If multicast storms occur because server instances in a cluster are not processing incoming messages on a timely basis, you can increase the size of multicast buffers. For information on multicast storms, see If Multicast Storms Occur.

TCP/IP kernel parameters can be configured with the UNIX ndd utility. The udp_max_buf parameter controls the size of send and receive buffers (in bytes) for a UDP socket. The appropriate value for udp_max_buf varies from deployment to deployment. If you are experiencing multicast storms, increase the value of udp_max_buf by 32K, and evaluate the effect of this change.

Do not change udp_max_buf unless necessary. Before changing udp_max_buf, read the Sun warning in the "UDP Parameters with Additional Cautions" section in the "TCP/IP Tunable Parameters" chapter in Solaris Tunable Parameters Reference Manual at http://docs.sun.com/?p=/doc/806-6779/6jfmsfr7o&.

Configuration Notes for Multi-Tier Architecture

If your cluster has a multi-tier architecture, see the configuration guidelines in Configuration Notes for Multi-Tier Architecture.

Enable URL Rewriting

In its default configuration, WebLogic Server uses client-side cookies to keep track of the primary and secondary server instance that host the client's servlet session state. If client browsers have disabled cookie usage, WebLogic Server can also keep track of primary and secondary server instances using URL rewriting. With URL rewriting, both locations of the client session state are embedded into the URLs passed between the client and proxy server. To support this feature, you must ensure that URL rewriting is enabled on the WebLogic Server cluster. For instructions on how to enable URL rewriting, see "Using URL Rewriting" in Assembling and Configuring Web Applications.