![]() |
![]() |
|
|
| |
Administering WebLogic Clusters
The following sections contain guidelines and instructions for configuring a WebLogic Server cluster:
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:
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:
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:
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.
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:
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:
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:
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:
See Assigning Names to WebLogic Server Resources.
After you have created the individual WebLogic Server instances, follow these steps to configure a new cluster:
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:
% 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:
See "Starting a WebLogic Managed Server" in WebLogic Server Administration Guide for more details.
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>
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-IPTM 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:
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:
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:
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:
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:
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.
Clustering Connection Pools
Perform these steps to set up a basic connection pool in a cluster:
For instructions, see "Configure a JDBC Connection Pool" in Administration Console Online Help.
For instructions, see "Assign a JDBC Connection Pool to One or More Servers or Clusters".
For instructions, see "Configure a JDBC Data Source" in Administration Console Online Help
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.
For instructions, see "Configure a JDBC Connection Pool" in Administration Console Online Help.
For instructions, see "Assign a JDBC Connection Pool to One or More Servers or Clusters".
For instructions, see "Configure a JDBC MultiPool".
For instructions, see "Assign a JDBC MultiPool to One or More Servers or Clusters".
For instructions, see "Configure a JDBC Data Source".
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:
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.
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:
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:
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.
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|