bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Using WebLogic Server Clusters

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

For information about the configuration facilities available in WebLogic Server and the tasks they support, see Understanding Cluster Configuration and Application Deployment.

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 Cluster Architectures, and Load Balancing in a Cluster.

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 If Your Cluster Spans Multiple Subnets in a WAN.

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.

Notes: WebLogic Server Version 7.0 allows you to set up a cluster on a single, non-multihomed machine. This new capability is useful for demonstration or development environments.

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, as with all capacity planning, you should test the actual deployment with your target Web applications to determine the optimal number and distribution of server instances. See "Performance Considerations for Multi-CPU Machines" in BEA WebLogic Server Performance and Tuning for additional information.

Check Host Machines' Socket Reader Implementation

For best socket performance, configure the WebLogic Server host machine 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.

Setting Up a Cluster on a Disconnected Windows Machine

If you want to demonstrate a WebLogic Server cluster on a single, disconnected Windows machine, you must force Windows to load the TCP/IP stack. By default, Windows does not load the TCP/IP stack if it does not detect a physical network connection.

To force Windows to load the TCP/IP stack, disable the Windows media sensing feature using the instructions in "How to Disable Media Sense for TCP/IP in Windows" at http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.

Identify Names and Addresses

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

For information on intra-cluster communication, and how it enables load balancing and failover, see WebLogic 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 Considerations.

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. Set this attribute in the Administration Console using the Server—>Configuration—>General tab. See Server—>Configuration—>General in Administration Console Online Help.

Note: If clients are accessing WebLogic Server over the default channel and T3, do not set the ExternalDNSName attribute, even if the internal and external DNS names of a WebLogic Server instance are not identical.

Using External DNS Name

Do not use an IP address for ExternalDNSName—it must be an actual domain name.

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 Managed Servers in its domain. When you start a Managed Server, 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 combination of address and Listen Port number. Clustered server instances on a single non-multihomed machine can have the same address, but must use a different Listen Port.

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 Cluster Architectures, 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, you define 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.

Cluster Address for Production Environments

In a production environment, specify the cluster address as a DNS name that maps to the IP addresses or DNS names of each WebLogic Server instance 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.

If you define the cluster address as a DNS name, the Listen Ports for the cluster members are not specified in the cluster address—it is assumed that each Managed Server in the cluster has the same Listen Port number. Because each server instance in a cluster must have a unique combination of address and Listen Port, if a cluster address is a DNS name, each of the server instance in the cluster must have:

- a unique address and

- the same Listen Port number

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 by WebLogic Server instances, and new initial context requests are fulfilled using addresses in the cached list with a round-robin algorithm. If a server instance in the cached list is unavailable, it is removed from the list. The address list is refreshed from the DNS service only if the server instance 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.

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 Address for Development and Test Environments

Use of a cluster DNS name for the cluster address, recommended for production environments in the previous section, is also fine for development and test environments.

Alternatively, you can define the cluster address as a list that contains the DNS name (or IP address) and Listen Port of each Managed Server in the cluster, as shown in the examples below:

DNSName1:port1,DNSName1:port2,DNSName1:port3

IPaddress1:port1,IPaddress2:port2;IPaddress3:port3

Note that in each cluster member has a unique address and port combination.

Cluster Address for Single, Multihomed Machine

If your cluster runs on a single, multihomed machine, and each server instance in the cluster uses a different IP address, define the cluster address using a DNS name that maps to the IP addresses of the server instances in the cluster. If you define the cluster address as a DNS name, specify the same Listen Port number for each of the Managed Servers in the cluster.

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:

1. Install WebLogic Server

2. Create a Clustered Domain

3. Configure Node Manager

4. Configure Load Balancing Method for EJBs and RMIs

5. Configuring Load Balancers that Support Passive Cookie Persistence

6. Configure Proxy Plug-Ins

7. Configure Replication Groups

8. Configure Migratable Targets for Pinned Services

9. Configure Clustered JDBC

10. Package Applications for Deployment

11. Deploy Applications

12. Deploying, Activating, and Migrating Migratable Services

13. Configure In-Memory HTTP Replication

14. 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 WebLogic Server. For instructions, see Installing BEA WebLogic Server.

- If the cluster will run on a single machine, do a single installation of WebLogic Server under the /bea directory to use for all clustered instances.

- For remote, networked machines, install the same version of WebLogic Server on each machine. Each machine:

  - Must have permanently assigned, static IP addresses. You cannot use dynamically-assigned IP addresses in a clustering environment.

  - Must be accessible to clients. If the server instances are behind a firewall and the clients are in front of the firewall, each server instance must have a public IP address that can be reached by the clients.

  - Must be located on the same local area network (LAN) and must be reachable via IP multicast.

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 server instances must compete to access the filesystem (and possibly to write individual log files). Moreover, should the shared filesystem fail, you might be unable to start clustered server instances.

Create a Clustered Domain

These instructions are for creating a cluster using the BEA Domain Configuration Wizard.

Notes: There are other methods for creating and maintaining cluster configurations See Methods of Configuring Clusters.

If you plan to use a custom network channel with your cluster, see "Configuring Network Channels with a Cluster" in Creating and Configuring WebLogic Server Domains. Follow the instructions there for creating Managed Servers, creating the cluster, creating and assigning the channel, and setting the multicast address.

1. Start the Configuration Wizard using Start -->Programs-->BEA WebLogic Platform--> Domain Configuration Wizard.

2. In the Choose Domain Type and Name window, click WLS Domain.

3. Enter a domain name, using alphanumeric characters with no embedded spaces, in the Name field. Click Next to continue.

4. In the Choose Server Type window, click Admin Server with Clustered Managed Server(s). Click Next to continue.

5. In the Choose Domain Location window, click Next to select the default directory that is shown, or browse to a different directory.

   The Choose Domain Location window shows:

   - the directory where your domain directory will be created

   - the full path for the domain directory to be created

     The domain directory name is the Domain Name you specified on the Choose Domain Type and Name window.

     Be sure the domain directory is under the BEA_HOME\user_projects\ directory, where BEA_HOME is the directory location where WebLogic Platform is installed.

6. In the Configure Clustered Server(s) window displayed, click Add to configure the first Managed Server for the cluster.

7. In the Add Server window, complete:

   - Server Name—Enter a server name, using alphanumeric characters with no embedded spaces

     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.

   - Server Listen Address—Enter machine address or name.

     For guidelines on how to specify the Listen Address, see Avoiding Listen Address Problems.

   - Server Listen Port—Enter a numeric value. The range of allowable values is 1 to 65535.

     Click Add to continue.

8. In the Add Server window click Add to add a Managed Server to the cluster, and repeat the previous step for each Managed Server in the cluster. When you are done adding Managed Servers, click Next to continue.

9. In the Configure Cluster window, complete:

   - Cluster Name—Contains the default value mycluster. Enter a name for the cluster, using alphanumeric characters with no embedded spaces

   - Cluster Multicast Address—Contains a default value 237.0.0.1. The range of allowable values is 224.0.0.0 to 239.255.255.255

   - Cluster Multicast Port—Contains a default value 7777.

   - Cluster Address—Contains a cluster address comprised of the address port combinations for each server instance in the cluster.

     If you modify the cluster address, use the appropriate address format, depending on whether the cluster will be used in production or not. For information on the cluster address format for production and non-production environments, see Cluster Address.

     Click Next to continue.

10. In the Configure Admin Server (with Cluster) window, complete:

    - Server Name—Contains default value myserver. Enter a name for the cluster's Administration Server, using alphanumeric characters with no embedded spaces.

      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.

    - Server Listen Address—Enter machine address or name.

      For guidelines on how to specify the Listen Address, see Avoiding Listen Address Problems.

    - Server Listen Port—The default port is 7001. The range of allowable values is 1 to 65535.

    - Server SSL Listen Port— The default port is 7002. The range of allowable values is 1 to 65535.

      Click Next to continue.

11. In the System User Name and Password window complete the User Name and Password fields. Enter a password with a minimum of eight characters.

    User name and password are required to start server instances in the cluster. The username must belong to a role that is permitted to start server instances. For information about roles, see "Protecting System Administration Operations" in BEA WebLogic Server Administration Guide.

    Click Next to continue.

12. In the Install Server as Windows Service window,

    Click Yes to install the domain as a Windows Service, to cause WebLogic Server service to start automatically each time the Windows system boots.

    or

    Click No if you do not want to run WebLogic as a Windows Service. If you choose No, the WebLogic Server service will not start automatically when the Windows system boots.

    Note: beaSvc is the service name in the domainname_ServerName variable.

13. In the Install Domain in Windows Start Menu window,

    Click Yes to add an entry for starting the new domain in your Windows Start Menu

    or

    Click No if you do not want an entry for the domain in your Windows Start Menu

    Click Next to continue.

14. In the Configuration Summary window, review the configuration summary information. Click:

    Previous if you wish to return to previous windows and modify configuration information.

    or

    Create to create the domain.

15. In the Configuration Wizard Complete window, click End Configuration Wizard to exit the wizard.

To make changes to the preceding configuration steps, and to complete the configuration process, use the Administration Console. For instructions on using the Administration Console, see Administration Console Online Help.

Note: The Administration Server for the domain containing the cluster must be running when you make changes to the cluster configuration. Follow steps 1 through 6 in the following section to start the Administration Server.

Starting a WebLogic Server Cluster

This section has instructions for starting a cluster. First start the Administration Server for the cluster, then start each of the Managed Servers in the cluster. Each server instance is started with a command that you execute in a separate command shell.

For a comprehensive discussion of procedures for starting and stopping server instances, see "Starting and Stopping WebLogic Servers" in BEA WebLogic Server Administration Guide.

1. Open a command shell.

2. Change directory to the domain directory that you created with the Configuration Wizard.

3. Type this command to start the Administration Server:

   StartWebLogic

4. Enter the user name for the domain at the "Enter username to boot WebLogic Server" prompt.

5. Enter the password for the domain at the "Enter password to boot WebLogic Server" prompt.

   The command shell displays messages that report the status of the startup process.

6. Open another command shell so that you can start a Managed Server.

7. Change directory to the domain directory that you created with the Configuration Wizard.

8. Type this command

   StartManagedWebLogic server_name address:port

   where:

   server_name is the name of the Managed Server you wish to start

   address is the IP address or DNS name for the Administration Server for the domain

   port is the listen port for the Administration Server for the domain

9. Enter the user name for the domain at the "Enter username to boot WebLogic Server" prompt.

10. Enter the password for the domain at the "Enter password to boot WebLogic Server" prompt.

    The command shell displays messages that report the status of the startup process.

    Note: After you start a Managed Server, it listens for heartbeats from other running server instances in the cluster. The Managed Server builds its local copy of the cluster-wide JNDI tree, as described in How WebLogic Server Updates the JNDI Tree, and displays status messages when it has synchronized with each running Managed Server in the cluster. The synchronization process can take a minute or so.

11. To start another server instance in the cluster, return to step 6. Continue through step 10.

12. When you have started all Managed Servers in the cluster, the cluster startup process is complete.

Configure Node Manager

Node Manager is a standalone Java program provided with WebLogic Server that is useful for starting a Managed Server that reside on a different machine than its Administration Server. Node Manager also provides features that help increase the availability of Managed Servers in your cluster. For more information, and for instructions to configure and use Node Manager, see "Managing Server Availability with Node Manager" in Creating and Configuring WebLogic Server Domains.

Configure Load Balancing Method for EJBs and RMIs

Follow the instructions in this section if you want to use weight-based or random load balancing for EJBs and RMI objects.

Unless you explicitly specify otherwise, WebLogic Server uses the round-robin algorithm as the default load balancing strategy for clustered object stubs. To understand alternative load balancing algorithms, see Load Balancing for EJBs and RMI Objects. To change the default load balancing algorithm:

1. Open the WebLogic Server Console.

2. Select the Clusters node.

3. Select your cluster.

4. Click the drop-down arrow next to the Default Load Algorithm to display load balancing algorithms.

5. In the item list, select the desired load balancing algorithm.

6. Enter the desired value in the Service Age Threshold field. For a definition of this attribute, see Administration Console Online Help.

7. Click Apply to save your changes.

Configuring Load Balancers that Support Passive Cookie Persistence

Load balancers that support passive cookie persistence can use information from the WebLogic Server session cookie to associate a client with the WebLogic Server instance that hosts the session. The session cookie contains a string that the load balancer uses to identify the primary server instance for the session.

For a discussion of external load balancers, session cookie persistence, and the WebLogic Server session cookie, see Load Balancing HTTP Sessions with an External Load Balancer.

To configure the load balancer to work with your cluster, use the facilities of the load balancer to define the offset and length of the string constant.

Assuming that the Session ID portion of the session cookie is the default length of 52 bytes, on the load balancer, set:

- string offset to 53 bytes, the default Random Session ID length plus 1 byte for the delimiter character.

- string length to 10 bytes

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

Notes: For vendor-specific instructions for configuring the Big-IP load balancer with WebLogic Server, see:Configuring BIG-IPTM Hardware with Clusters.

Configure Proxy Plug-Ins

Refer to the instructions in the section if you wish to load balance servlets and JSPs using a proxy plug-in. A proxy plug-in proxies requests from a Web server to WebLogic server instances in a cluster, and provides load balancing and failover for the proxied HTTP requests.

For information about load balancing using the proxy plug-in, see Load Balancing with a Proxy Plug-in. For information about connection and failover using the proxy plug-in, see Replication and Failover for Servlets and JSPs, and Accessing Clustered Servlets and JSPs Using a Proxy.

- If you use the BEA-provided Web server, set up its associated plug-in, HttpClusterServlet, using the instructions in Set Up the HttpClusterServlet.

- If you use a supported third-party Web server, you will set up a product-specific plug-in. For a list of supported servers, see Load Balancing with a Proxy Plug-in.

  To set up a plug-in for a third party Web server, follow the instructions in Using WebLogic Server with Plug-ins.

Note: Each Web server that proxies requests to a cluster must have an identically configured plug-in.

Set Up the HttpClusterServlet

This section has instructions for deploying the HttpClusterServlet.

1. Create a Web Application that includes the HttpClusterServlet, and a deployment descriptor file containing the elements described in this section. You can create a Web Application and its deployment descriptors manually or you can use the WebLogic Builder tool. For background and instructions, see:

   - "Overview of Web Applications" in Assembling and Configuring Web Applications

   - "Main Steps to Create a Web Application" in Assembling and Configuring Web Applications

   - "Writing Web Application Deployment Descriptors" in Assembling and Configuring Web Applications

   - WebLogic Builder Online Help

2. Create the web.xml deployment descriptor file for the Web Application. (For an example of a complete deployment descriptor, see Sample Deployment Descriptor for the HttpClusterServlet.)

   1. Register the HttpClusterServlet in the Web Application deployment descriptor in the <servlet> element. The class name for the HttpClusterServlet is weblogic.servlet.proxy.HttpClusterServlet:

      >     <servlet-name>HttpClusterServlet</servlet-name>
      >     <servlet-class>
      >        weblogic.servlet.proxy.HttpClusterServlet
      >     </servlet-class>

   2. Define, where appropriate, any additional parameters as described in "Parameters for Web Server Plug-ins"in Using WebLogic Server with Plug-ins. Refer also to Cluster Configuration and Proxy Plug-ins.

   3. Map the proxy servlet to a <url-pattern>. Specifically, map the file extensions you want to proxy, for example *.jsp, or *.html.

      If you set the <url-pattern> to "/", then any request that cannot be resolved by WebLogic Server is proxied to the remote server instance. However, you must also specifically map the following extensions: *.jsp, *.html, and *.html, if you want to proxy files ending with those extensions.

      Another way to set up the url-pattern is to map a <url-pattern> such as /foo and then set the pathTrim parameter to foo, which removes foo from the proxied URL.

For example:

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>/</url-pattern>
>     </servlet-mapping>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>*.jsp</url-pattern>
>     </servlet-mapping>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>*.htm</url-pattern>
>     </servlet-mapping>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>*.html</url-pattern>
>     </servlet-mapping>

1. Use Administration Console to configure this Web Application. (For detailed information on configuring and deploying a Web Application using the Administration Console, see "Configuring a New Web Application or Web Service" in Administration Console Online Help.

   1. Create a new server instance in your domain.

   2. Assign the Web Application you created as the default Web Application for the server instance that you just created.

   3. Deploy the Web Application on the server.

   Note: You can also use the weblogic.Deployer tool to deploy a Web Application. For more information, see "Deployer" in the BEA WebLogic Server Administration Guide.

Cluster Configuration and Proxy Plug-ins

Two WebLogic Server configuration attributes can be set at the cluster level to control the behavior of the HttpClusterServlet.

- WeblogicPluginEnabled—If you set this attribute to true for a cluster that receives requests from the HttpClusterServlet, the servlet will respond to getRemoteAddr calls with the address of the browser client from the proprietary WL-Proxy-Client-IP header, instead of returning the web server address.

- ClientCertProxy Enabled—If you set this attribute to true for a cluster that receives requests from HttpClusterServlet, the plug-in sends client certs to the cluster in the special WL-Proxy-Client-Cert header, allowing user authentication to be performed on the proxy server.

  Note: For more information see help for the Cluster -->Configuration-->General page in Administration Console Online Help.

Sample Deployment Descriptor for the HttpClusterServlet

The following is a sample of a Web Applications deployment descriptor, web.xml, for using the HttpClusterServlet:

Listing 7-1 Sample web.xml for Use with HttpClusterServlet

>     <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
>      //DTD Web Application 2.2//EN"
>      "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

>     <web-app>

>     <servlet>
>       <servlet-name>HttpClusterServlet</servlet-name>
>         <servlet-class>
>           weblogic.servlet.proxy.HttpClusterServlet
>         </servlet-class>

>       <init-param>
>         <param-name>WebLogicCluster</param-name>
>         <param-value>
>            hostname1:7736:7737|hostname2:7736:7737|hostname:7736:7737
>         </param-value>
>       </init-param>

>       <init-param>
>         <param-name>DebugConfigInfo</param-name>
>         <param-value>ON</param-value>
>       </init-param>

>     </servlet>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>/</url-pattern>
>     </servlet-mapping>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>*.jsp</url-pattern>
>     </servlet-mapping>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>*.htm</url-pattern>
>     </servlet-mapping>

>     <servlet-mapping>
>       <servlet-name>HttpClusterServlet</servlet-name>
>       <url-pattern>*.html</url-pattern>
>     </servlet-mapping>

>     </web-app>

Configure Replication Groups

To support automatic failover for servlets and JSPs, WebLogic Server replicates HTTP session states in memory. You can further control where secondary states are placed using replication groups. A replication group is a preferred list of clustered instances to be used for storing session state replicas.

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.

For instructions on how to determine which server instances should participate in each replication group, and to determine each server instance's preferred replication group, follow the instructions in Using Replication Groups.

Then follow these steps to configure replication groups for each WebLogic Server instance:

To configure replication groups for a WebLogic Server instance:

1. Open the WebLogic Server Console.

2. Select the Servers node.

3. Select the server 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 Migratable Targets for Pinned Services

WebLogic Server enables you to configure an optional migratable target, which defines a list of server instances in the cluster that can potentially host a migratable service, such as a JMS server or the Java Transaction API (JTA) transaction recovery service. If you want to use a migratable target, configure the target server list before deploying or activating the service in the cluster.

If you do not configure a migratable target in the cluster, migratable services can be migrated to any WebLogic Server instance in the cluster. See Migration for Pinned Services for more information.

Follow these steps to configure a migratable target for either JTA or JMS:

1. Start the Administration Server for the cluster and log in to the Administration Console.

2. Select the Servers node in the left pane, then select a server instance that is a member of the cluster you want to configure.

3. Select the Control->Migration Config. tab in the right pane to configure a migratable target for the JMS service. Or, Select the Control->JTA Migration Config. tab in the right pane to configure a migratable target for the JTA transaction recovery service.

4. Select one or more server names in the Available column and use the arrows to place them in the Chosen column. Server names in the Chosen column represent the list of server instances that can host the migratable service.

5. Click Apply to apply your changes to the migratable target.

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 for 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 "Creating and Configuring a JDBC Connection Pool" in Administration Console Online Help.

2. Assign the connection pool to the cluster.

   For instructions, see "Assigning 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 "Creating and Configuring a JDBC Data Source" in Administration Console Online Help

4. Assign the data source to the cluster.

   For instructions, see "Assigning a JDBC Data Source to a Server or Cluster".

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 "Creating and Configuring a JDBC Connection Pool" in Administration Console Online Help.

2. Assign each connection pool to the cluster.

   For instructions, see "Assigning 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 "Creating and Configuring a JDBC MultiPool".

4. Assign the Multipool to the cluster.

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

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

   For instructions, see "Creating and Configuring a JDBC Data Source".

6. Assign the data source to the cluster.

   For instructions, see Assigning a JDBC Data Source to a Server or Cluster.

Package Applications for Deployment

Use the instructions in "WebLogic Server Applications Packaging" in Developing WebLogic Server Applications to prepare your application for deployment. Packaging your application is a prerequisite for deployment.

Deploy Applications

This section provides instructions for common deployment tasks. For a discussion of application deployment in clustered environments see Application Deployment Topics. For a broad discussion of deployment topics, see "WebLogic Server Deployment" in Developing WebLogic Server Applications.

Deploying Applications to a Cluster

Follow the steps in this section to configure and deploy an application using the WebLogic Server Administration Console:

Note: All server instances in your cluster should be running when you deploy applications to the cluster using the Administration Console

1. Start the WebLogic Server Administration Console.

2. Select the Domain in which you will be working.

3. In the left pane of the Console, click Deployments.

4. In the left pane of the Console, click the Applications. A table is displayed in the right pane of the Console showing all the deployed Applications.

5. Select the Configure a new Application option.

6. Locate the .ear, .war, .jar, or .rar file you would like to configure for use with WebLogic Server. You can also configure an "exploded" application or component directory. Note that WebLogic Server will deploy all components it finds in and below the specified directory.

7. Click the WebLogic icon to the left of a directory or file to choose it and proceed to the next step.

8. Enter a name for the application or component in the provided field and click Create.

9. Enter the following information:

   - Staging Mode—specify the staging mode. The options include server, nostage, and stage.

   - Deployed—using the provided check box, indicate whether the .ear, .war, .jar, or .rar file should be deployed upon creation.

10. To configure components for the application, click the Configure Components in this Application.

11. The Components table is displayed. Click a component to configure.

12. Using the available tabs, enter the following information:

    - Configuration—Edit the staging mode and enter the deployment order.

    - Targets—Indicate the target for this configured application by moving the application from the Available list to the Chosen list.

Note: Clustered objects in WebLogic Server should be deployed homogeneously. If the object contains a replica-aware stub, use the console to deploy it using the cluster name.

To ensure homogeneous deployment, when you select a target use the cluster name, rather than individual WebLogic Server instances in the cluster.

The console automates deploying replica-aware objects to clusters. When you deploy an application or object to a cluster, the 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)

- Deploy—Deploy the application to all of the selected targets or undeploy it from all targets.

- Monitoring—View monitoring information related to the application.

- Notes—Enter notes related to the application.

Click Apply.

Deploying to a Server Instance (Pinned Deployment)

Deploying a application to a server instance, rather than the all cluster members is called a pinned deployment. Although a pinned deployment targets a specific server instance, all server instances in the cluster must be running during the deployment process.

You can perform a pinned deployment using the Administration Console or from the command line, using weblogic.Deployer.

Pinned Deployment from the Command Line

From a command shell, use the following syntax to target a server instance:

>     java weblogic.Deployer -activate -name ArchivedEarJar -source C:/MyApps/JarEar.ear -target server1

Pinned Deployment Using the Administration Console

Perform these steps to target a server instance:

1. In the Administration Console, open the Deployments node.

2. Click the application or component to be deployed.

3. In the right-hand panel, select the Targets --> Clusters tab and make sure the cluster is in the Available and not the Chosen list.

4. Select the Targets tab and make sure the server is in the Chosen list.

5. Click Apply.

Cancelling Cluster Deployments

You can cancel a deployment using the Administration Console or from the command line, using weblogic.Deployer.

Cancel Deployment from the Command Line

From a command shell, use the following syntax to cancel the deployment task ID:

>     java weblogic.Deployer -adminurl http://admin:7001 -cancel -id tag

Cancel Deployment Using the Administration Console

In the Administration Console, open the Tasks node to view and to cancel any current deployment tasks.

Viewing Deployed Applications

To view a deployed application in the Administration Console:

1. In the Console, click Deployments.

2. Click the Applications option.

3. View a list of deployed applications in the table displayed in the Console.

Undeploying Deployed Applications

To undeploy a deployed application from the WebLogic Server Administration Console:

1. In the Console, click Deployments.

2. Click the Applications option.

3. In the displayed table, click the name of the application you wish to undeploy.

4. Click the Configuration tab, and deselect the Deployed check box.

5. Click Apply.

Deploying, Activating, and Migrating Migratable Services

The sections that follow provide guidelines and instructions for deploying, activating, and migrating migratable services. For a discussion of migratable services, see Migration for Pinned Services

Deploying JMS to a Migratable Target Server Instance

The migratable target that you create defines the scope of server instances in the cluster that can potentially host a migratable service. You must deploy or activate a pinned service on one of the server instances listed in the migratable target in order to migrate the service within the target server list at a later time. Use the instructions that follow to deploy a JMS server on a migratable target, or activate the JTA transaction recovery system so that you can migrate it later.

Note: If you did not configure a migratable target, simply deploy the JMS server to any WebLogic Server instance in the cluster; you can then migrate the JMS server to any other server instance in the cluster (no migratable target is used).

To deploy a JMS server to a migratable target using the Administration Console:

1. Use the instructions in Configure Migratable Targets for Pinned Services" on page 23 to create a migratable target for the cluster, if you have not already done so.

2. Start the Administration Server for the cluster and log in to the Administration Console.

3. Select the JMS node in the left pane, then select the Servers node under JMS.

4. Select the name of the configured JMS server that you want to deploy to the cluster. This displays the JMS server configuration in the right pane.

5. Select the Targets->Migratable Targets tab in the right pane.

6. Select the name of a server instance from the drop-down list. The drop-down list specifies server names that are defined as part of a migratable target.

7. Click Apply to apply the JMS server to the select WebLogic Server instance.

Activating JTA as a Migratable Service

The JTA recovery service is automatically started on one of the server instances listed in the migratable target for the cluster; you do not have to deploy the service to a selected server instance.

If you did not configure a JTA migratable target, WebLogic Server activates the service on any available WebLogic Server instance in the cluster. To change the current server instance that hosts the JTA service, use the instructions in Migrating a Pinned Service to a Target Server Instance.

Migrating a Pinned Service to a Target Server Instance

After you have deployed a migratable service, you can use the Administration Console to migrate the service to another server instance in the cluster. If you configured a migratable target for the service, you can migrate to any other server instance listen in the migratable target, even if that server instance is not currently running. If you did not configure a migratable target, you can migrate the service to any other server instance in the cluster.

If you migrate a service to a stopped server instance, the server instance will immediately activate the service upon the next startup. If you migrate a service to a running WebLogic Server instance, the migration takes place immediately.

To migrate a pinned service using the Administration Console:

1. Use the instructions in Deploying JMS to a Migratable Target Server Instance to deploy a pinned service to the cluster, if you have not already done so.

2. Start the Administration Server for the cluster and log in to the Administration Console.

3. Select the Servers node in the left pane, then select a server instance that is a member of the cluster you want to configure.

4. Select Control->Migrate if you want to migrate the JMS service, or Control->JTA Migrate to migrate the JTA transaction recovery service.

   The Current Server field shows the WebLogic Server instance that currently hosts the pinned service. The Destination Server drop-down list displays server instances to which you can migrate the service.

5. Use the Destination Server drop-down list to select the new server instance that will host the pinned service.

6. Click Migrate to migrate the pinned service from the Current Server to the Destination Server.

7. If you chose to migrate the service to a stopped WebLogic Server instance, the Administration Console notifies you of the stopped server instance and asks if you would like to continue the migration. Click the Continue button to migrate to the stopped server instance, or click Cancel to stop the migration and select a different server instance.

8. The migration process may take several minutes to complete, depending on the server instance configuration. However, you can continue using other Administration Console features while the migration takes place. To view the migration status at a later time, simply click the Tasks node in the left pane to display the currently-running tasks for the domain; then select the task description for the migration task to view the current status.

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 "Making Sessions Persistent" in Programming WebLogic HTTP Servlets.

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>

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 Communication via Sockets.

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

Set the Number of Reader Threads on Client Machines

On client machines, you can configure the number 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 seeIf Your Cluster Spans Multiple Subnets in a WAN.

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

Configure Machine Names

It is possible to define a Machine Names for each server instance in a cluster. Machine Names are not required, but they are recommended if your clusters will span multiple machines, and multiple server instances will run on individual machines in the cluster.

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 machines that host multiple 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 server instances to host secondary HTTP session state replicas, as described in Using Replication Groups.

If you intend to run multiple server instances on a single machine, before you create those server instances, define the names of the machine(s) that will host the server instances:

1. Start the Administration Server. For instructions, see "Starting an Administration Server" in BEA WebLogic Server Administration Guide.

2. Select the Machines node.

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

4. Enter a unique name for the new machine in the Name attribute field.

5. Click Create to create the new machine definition.

6. If you wish to configure other attributes for a new UNIX server, see the Administration Console Online Help.

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

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.

- For JMS servers, you can identify either a single-server target or a migratable target, which is a set of WebLogic Server instances in a cluster that can host an migratable service. For more information on migratable targets, see Configuring JMS Migratable Targets.

- For connection factories, you can identify either a single-server target or a cluster target, which are WebLogic Server instances that are associated with a connection factory to support clustering.

For more information about these configuration attributes, see "Configuring JMS Servers" or "Configuring Connection Factories" in the Administration Guide.

Note: You cannot deploy the same destination on more than one JMS server. In addition, you cannot deploy a JMS server on more than one WebLogic Server.

Optionally, you can configure your physical destinations as part of a single distributed destination set within a cluster. For more information, see "Configuring Distributed Destinations" in the Administration Guide.

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.