10 Setting Up WebLogic Clusters
Learn the guidelines and instructions for configuring an Oracle WebLogic Server cluster.
This chapter includes the following sections:
- Before You Start
Learn the prerequisite tasks for setting up a WebLogic Server cluster. - Cluster Implementation Procedures
The following sections describe how to get a clustered application up and running from the installation of the WebLogic Server through the initial deployment of application components.
Before You Start
Learn the prerequisite tasks for setting up a WebLogic Server cluster.
- Understand the Configuration Process
- Determine Your Cluster Architecture
- Consider Your Network and Security Topologies
- Choose Machines for the Cluster Installation
- Identify Names and Addresses
Parent topic: Setting Up WebLogic Clusters
Understand the Configuration Process
If you have a basic understanding of the cluster configuration process and how to accomplish the configuration tasks, information in this section will be most useful.
For information about the configuration facilities available in WebLogic Server and the tasks they support, see Understanding Cluster Configuration.
Parent topic: Before You Start
Determine Your Cluster Architecture
Determine the best cluster architecture that 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 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.
Parent topic: Before You Start
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.
Note:
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.
Parent topic: Before You Start
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. WebLogic Server allows you to set up a cluster on a single, non-multihomed machine. This new capability is useful for demonstration or development environments.
Note:
Do not install WebLogic Server on machines that have dynamically assigned IP addresses.
- WebLogic Server Instances on Multi-CPU Machines
- Check Host Machines' Socket Reader Implementation
- Setting Up a Cluster on a Disconnected Windows Machine
Parent topic: Before You Start
WebLogic Server Instances on Multi-CPU Machines
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.
Oracle recommends that you start with one server per CPU and then scale up based on the expected behavior. 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. For more information see Running Multiple Server Instances on Multi-Core Machines in Tuning Performance of Oracle WebLogic Server for additional information.
Parent topic: Choose Machines for the Cluster Installation
Check Host Machines' Socket Reader Implementation
For best socket performance, configure the host to use the native socket reader implementation for your operating system, rather than the pure-Java implementation. For understanding and the instructions about configuring native sockets or optimizing pure-Java socket communications, see Peer-to-Peer Communication Using IP Sockets.
Parent topic: Choose Machines for the Cluster Installation
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
.
Parent topic: Choose Machines for the Cluster Installation
Identify Names and Addresses
During the cluster configuration process, you supply addressing information, such as IP addresses or DNS names and port numbers for the server instances in the cluster.
For information on intra-cluster communication, and how it enables load balancing and failover, see Choosing WebLogic Server Cluster Messaging Protocols.
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
- Assigning Names to WebLogic Server Resources
- Administration Server Address and Port
- Managed Server Addresses and Listen Ports
- Cluster Multicast Address and Port
- Cluster Address
Parent topic: Before You Start
Avoiding Listen Address Problems
As you configure a cluster, you can specify address information using either IP addresses or DNS names.
Parent topic: Identify Names and Addresses
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 multitier 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.
Parent topic: Avoiding Listen Address Problems
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. 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.
Parent topic: Avoiding Listen Address Problems
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.
Parent topic: Avoiding Listen Address Problems
Assigning Names to WebLogic Server Resources
Ensure that each configurable resource in your WebLogic Server environment has a unique name. Each domain, server, machine, cluster, data source, virtual host, or other resource must have a unique name.
Parent topic: Identify Names and Addresses
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.
Parent topic: Identify Names and Addresses
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.
Parent topic: Identify Names and Addresses
Cluster Multicast Address and Port
Identify the address and port you will dedicate to multicast communications for your cluster. A multicast address is an IP address between 224.0.0.0 and 239.255.255.255.
Note:
The default multicast value used by WebLogic Server is 239.192.0.0. You should not use any multicast address with the value x.0.0.1.
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, ensure that those multicast communications use a different port than the cluster multicast port. For more information, see Using IP Multicast.
Parent topic: Identify Names and Addresses
Multicast and Multiple Clusters
Multiple clusters on a network may share a multicast address and multicast port combination if necessary.
Parent topic: Cluster Multicast Address and Port
Multicast and Multitier Clusters
If you are setting up the recommended multitier 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.
Parent topic: Cluster Multicast Address and Port
Cluster Address
In WebLogic Server cluster, the cluster address is used in entity and stateless beans to construct the host name portion of request URLs.
You can explicitly define the cluster address when you configure a cluster; otherwise, WebLogic Server dynamically generates the cluster address for each new request. For system administration, it is simple to allow the WebLogic Server to generate the cluster address dynamically and is suitable for both development and production environments.
- Dynamic Cluster Address
- Explicitly Defining Cluster Address for Production Environments
- Explicitly Defining Cluster Address for Development and Test Environments
- Explicitly Defining Cluster Address for Single, Multihomed Machine
Parent topic: Identify Names and Addresses
Dynamic Cluster Address
If you do not explicitly define a cluster address when you configure a cluster, and when a clustered server instance receives a remote request, WebLogic Server generates the cluster address, in the form:
listenaddress1:listenport1,listenaddress2:listenport2;listenaddress3: listenport3
Each listen address:listen port
combination in the cluster address corresponds to Managed Server and network channel that received the request.
-
If the request was received on the Managed Server's default channel, the
listen address:listen port
combinations in the cluster address reflect theListenAddress
andListenPort
values from the associatedServerMBean
andSSLMBean
instances. See The Default Network Channel in Administering Server Environments for Oracle WebLogic Server. -
If the request was received on a custom network channel, the
listen address:listen port
in the cluster address reflect theListenAddress
andListenPort
values fromNetworkAccessPointMBean
that defines the channel. For more information about network channels in a cluster, see Configuring Network Channels For a Cluster in Administering Server Environments for Oracle WebLogic Server.
The number of ListenAddress:ListenPort
combinations included in the cluster address is governed by the value of the NumberOfServersInClusterAddress
attribute on the ClusterMBean
, which is 3 by default.
Note:
You can set NumberOfServersInClusterAddress
attribute to a minimum value of 1. This attribute is used when WebLogic Server dynamically constructs cluster address for use with EJBs. In WebLogic Server cluster, the cluster address is used in entity and stateless beans to construct the host name portion of requested URLs. You can explicitly define the cluster address while configuring a cluster. Otherwise, WebLogic Server dynamically generates the cluster address for each new request. Allowing WebLogic Server to dynamically generate the cluster address is the simplest and convenient method for System Administration, and both development and production environments.
You can modify the value of NumberOfServersInClusterAddress
on the Environments > Clusters > ClusterName > Configuration > General page of the WebLogic Server Administration Console.
-
If there are fewer Managed Servers available in the cluster than the value of
NumberOfServersInClusterAddress
, the dynamically generated cluster address contains aListenAddress:ListenPort
combination for each of the running Managed Servers. -
If there are more Managed Servers available in the cluster than the value of
NumberOfServersInClusterAddress
, WebLogic Server randomly selects a subset of the available instances that is equal to the value ofNumberOfServersInClusterAddress
, and uses theListenAddress:ListenPort
combination for those instances to form the cluster address.
The order in which the ListenAddress:ListenPort
combinations appear in the cluster address is random; from request to request, the order will vary.
Parent topic: Cluster Address
Explicitly Defining Cluster Address for Production Environments
If you explicitly define a cluster address for a cluster 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 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 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. See Administration Server Considerations.
Parent topic: Cluster Address
Explicitly Defining Cluster Address for Development and Test Environments
If you explicitly define a cluster address for using it in development environments, you can use a cluster DNS name for the cluster address, as described in Explicitly Defining Cluster Address for Production 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:
Each cluster member has a unique address and port combination.
Parent topic: Cluster Address
Explicitly Defining 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.
Parent topic: Cluster Address
Cluster Implementation Procedures
The following sections describe how to get a clustered application up and running from the installation of the WebLogic Server through the initial deployment of application components.
- Configuration Roadmap
- Install WebLogic Server
- Create a Clustered Domain
- Configure Node Manager
- Configure Load Balancing Method for EJBs and RMIs
- Specifying a Timeout Value For RMIs
- Configure Server Affinity for Distributed JMS Destinations
- Configuring Load Balancers that Support Passive Cookie Persistence
- Configure Proxy Plug-Ins
- Configure Replication Groups
- Configure Migratable Targets for Pinned Services
- Package Applications for Deployment
- Deploy Applications
- Deploying, Activating, and Migrating Migratable Services
- Configure In-Memory HTTP Replication
- Additional Configuration Topics
Parent topic: Setting Up WebLogic Clusters
Configuration Roadmap
This section lists typical cluster implementation tasks, and highlights key configuration considerations. The exact process you follow is driven by the unique characteristics of your environment and the nature of your application. The following list describes the cluster implementation tasks:
Not every step is required for every cluster implementation. Additional steps may be necessary in some cases.
Parent topic: Cluster Implementation Procedures
Install WebLogic Server
If you have not installed WebLogic Server prior, install it. For more information about WebLogic Server installation, see Planning the Oracle WebLogic Server Installation in Installing and Configuring Oracle WebLogic Server and Coherence.
-
If the cluster will run on a single machine, do a single installation of WebLogic Server under the
/Oracle
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 LAN and must be reachable via IP multicast.
-
Parent topic: Cluster Implementation Procedures
Create a Clustered Domain
The are multiple methods of creating a clustered domain. See Methods of Configuring Clusters.
For instructions to create a cluster using the:
-
Configuration Wizard, do the following:
- For instructions on creating a domain, see Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard.
- For instructions on configuring a cluster, see Clusters in Creating WebLogic Domains Using the Configuration Wizard.
-
WebLogic Server Administration Console, see Create and configure clusters in Oracle WebLogic Server Administration Console Online Help.
Starting a WebLogic Server Cluster
There are multiple methods of starting a cluster. The available options include the command-line interface, scripts that contain the necessary commands, and Node Manager.
Note:
Node Manager eases the process of starting servers, and restarting them after failure.
To use Node Manager, you must first configure a Node Manager process on each machine that hosts Managed Servers in the cluster. See Configure Node Manager.
Regardless of the method you use to start a cluster, start the Administration Server first, then start the Managed Servers in the cluster.
Follow the instructions below to start the cluster from a command shell.
Note:
Each server instance is started in a separate command shell.
Parent topic: Create a Clustered Domain
Configure Node Manager
Node Manager is a standalone program provided with WebLogic Server that is useful for starting a Managed Server that resides 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 instructions to configure and use Node Manager, see Administering Node Manager for Oracle WebLogic Server.
Parent topic: Cluster Implementation Procedures
Configure Load Balancing Method for EJBs and RMIs
Follow the instructions in this section to select the load balancing algorithm 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, do as follows:
- Open the WebLogic Server Administration Console.
- Select Environments > Clusters.
- Select the name of your cluster in the table.
- If you have not already done so, click Lock & Edit in the top left corner of the Console.
- Enter the desired load balancing algorithm in the
Default Load Algorithm
field. - Select Advanced.
- Enter the desired value in the
Service Age Threshold
field. - Click Save to save your changes.
- Click Activate Changes in the top left corner once you are ready to activate your changes.
Parent topic: Cluster Implementation Procedures
Specifying a Timeout Value For RMIs
You can enable a timeout option when making calls to the ReplicationManager by setting the ReplicationTimeoutEnabled
in the ClusterMBean to true
.
The timeout value is equal to the multicast heartbeat timeout. Although you can customize the multicast timeout value, the ReplicationManager timeout cannot be changed. This restriction exists because the ReplicationManager timeout does not affect cluster membership. A missing multicast heartbeat causes the member to be removed from the cluster and the timed out ReplicationManager call will choose a new secondary server to connect to.
Note:
It is possible that a cluster member will continue to send multicast heartbeats, but will be unable to process replication requests. This could potentially cause an uneven distribution of secondary servers. When this situation occurs, a warning message is recorded in the server logs.
Parent topic: Cluster Implementation Procedures
Configure Server Affinity for Distributed JMS Destinations
To understand the server affinity support provided by WebLogic Server for JMS, see Load Balancing for JMS.
Parent topic: Cluster Implementation Procedures
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.
Note:
For vendor-specific instructions for configuring Big-IP load balancers, see Configuring BIG-IP Hardware with Clusters.
Parent topic: Cluster Implementation Procedures
Configure Proxy Plug-Ins
Refer to the instructions in this 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 proxy plug-ins, see Load Balancing with a Proxy Plug-in. For information about connection and failover using proxy plug-ins, see Replication and Failover for Servlets and JSPs , and Accessing Clustered Servlets and JSPs Using a Proxy.
-
If you use WebLogic Server as a Web server, set up
HttpClusterServlet
using the instructions in Set Up the HttpClusterServlet. -
If you use a supported third-party Web server, set up a product-specific plug-in (for a list of supported Web servers, see Load Balancing with a Proxy Plug-in) follow the instructions in Using Oracle WebLogic Server Proxy Plug-Ins.
Note:
Each Web server that proxies requests to a cluster must have an identically configured plug-in.
Set Up the HttpClusterServlet
To use the HTTP cluster servlet, configure it as the default Web application on your proxy server machine, as described in the steps below. For an introduction to Web applications, see Understanding Web Applications, Servlets, and JSPs in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
-
If you have not already done so, configure a separate, non-clustered Managed Server to host the HTTP Cluster Servlet.
-
Create the
web.xml
deployment descriptor file for the servlet. This file must reside in the\WEB-INF
subdirectory of the Web application directory. A sample deployment descriptor for the proxy servlet is provided in Sample web.xml.-
Define the name and class for the servlet in the
<servlet>
element inweb.xml
. The servlet name isHttpClusterServlet
. The servlet class isweblogic.servlet.proxy.HttpClusterServlet.
-
Identify the clustered server instances to which the proxy servlet will direct requests in the
<servlet>
element inweb.xml
, by defining theWebLogicCluster
parameter. -
Optionally, define the following
<KeyStore>
initialization parameters to use two-way SSL with your own identity certificate and key. If no<KeyStore>
is specified in the deployment descriptor, the proxy will assume one-way SSL.-
<KeyStore>
—The key store location in your Web application. -
<KeyStoreType>
—The key store type. If it is not defined, the default type will be used instead. -
<PrivateKeyAlias>
—The private key alias. -
<KeyStorePasswordProperties>
—A property file in your Web application that defines encrypted passwords to access the key store and private key alias. The file contents looks like this:KeyStorePassword={AES}yWv/i0qhfM4/IvzoghzjHj/xpJUkQPF8OWuSfh0f0Ss= PrivateKeyPassword={AES}wr86u9Z5DHr+5p7WIbzTDSy4M/sl7EYnX/K5xzcarDQ=
You must use the
weblogic.security.Encrypt
command-line utility to encrypt the password. For more information on theEncrypt
utility, as well as theCertGen
, andder2pem
utilities, see Using the Oracle WebLogic Server Java Utilities in the Command Reference for Oracle WebLogic Server.
-
-
Create
<servlet-mapping>
stanzas to specify the requests that the servlet will proxy to the cluster, using the<url-pattern>
element to identify specific file extensions, for example*.jsp
, or *.html
. Define each pattern in a separate<servlet-mapping>
stanza.You can set the
<url-pattern>
to "/
" to proxy any request that cannot be resolved by WebLogic Server to the remote server instance. If you do so, you must also specifically map the following extensions:*.jsp
,*.htm
, and*.html
, to proxy files ending with those extensions. For an example, see Sample web.xml. -
You can enable the
WLProxyPassThrough
attribute to allow the header to be passed through a chain of proxies and theWLProxySSLPassThrough
attribute so that the use of SSL is passed on to WebLogic Server. For a complete description of these attributes, see General Parameters for Web Server Plug-Ins in Using Oracle WebLogic Server Proxy Plug-Ins. -
Define, as appropriate, any additional parameters. See Table 10-1 for a list of key parameters. See Parameters for Web Server Plug-ins in Using Oracle WebLogic Server Proxy Plug-Ins for a complete list. Follow the syntax instructions in Proxy Servlet Deployment Parameters.
-
-
Create the
weblogic.xml
deployment descriptor file for the servlet. This file must reside in the\WEB-INF
subdirectory of the Web application directory.Assign the proxy servlet as the default Web application for the Managed Server on the proxy machine by setting the
<context-root>
element to a forward slash character (/) in the<weblogic-web-app>
stanza. For an example, see Sample weblogic.xml. -
In the WebLogic Server Administration Console, deploy the servlet to the Managed Server on your proxy server machine. For instructions, see Deploy applications and modules in Oracle WebLogic Server Administration Console Online Help.
- Sample web.xml
- Sample weblogic.xml
- Proxy Servlet Deployment Parameters
- Accessing Applications Via the Proxy Server
Parent topic: Configure Proxy Plug-Ins
Sample web.xml
This section contains a sample deployment descriptor file (web.xml
) for HttpClusterServlet
.
web.xml
defines parameters that specify the location and behavior of both versions of the proxy servlet.
-
The
DOCTYPE
stanza specifies the document type definition (DTD) used by WebLogic Server to validateweb.xml
. -
The
servlet
stanza:-
Specifies the location of the proxy plug-in servlet class. The file is located in the
weblogic.jar
in yourWL_HOME
/server/lib
directory. You do not have to specify the servlet's full directory path inweb.xml
becauseweblogic.jar
is put in yourCLASSPATH
when you start WebLogic Server. -
Identifies the host name (either DNS name or IP address) and listen port of each Managed Servers in the cluster, using the
WebLogicCluster
parameter. -
Identifies the key store initialization parameters to use two-way SSL with your own identity certificate and key.
-
-
The three
servlet-mapping
stanzas specify that the servlet will proxy URLs that end in '/', 'htm', 'html', or 'jsp' to the cluster.
For parameter definitions, see Proxy Servlet Deployment Parameters.
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"version="3.1"> <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|hostname2:7736|hostname:7736</param-value> </init-param> <init-param> <param-name>KeyStore</param-name> <param-value>/mykeystore</param-value> </init-param> <init-param> <param-name>KeyStoreType</param-name> <param-value>jks</param-value> </init-param> <init-param> <param-name>PrivateKeyAlias</param-name> <param-value>passalias</param-value> </init-param> <init-param> <param-name>KeyStorePasswordProperties</param-name> <param-value>mykeystore.properties</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>
Parent topic: Set Up the HttpClusterServlet
Sample weblogic.xml
This section contains a sample weblogic.xml
file. The <context-root>
deployment parameter is set to "/". This makes the proxy servlet the default Web application for the proxy server.
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 9.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic 810-web-jar.dtd"> <weblogic-web-app> <context-root>/</context-root> </weblogic-web-app>
Parent topic: Set Up the HttpClusterServlet
Proxy Servlet Deployment Parameters
Key parameters for configuring the behavior of the proxy servlet in web.xml
are listed in Before You Start.
The parameters for the proxy servlet are the same as those used to configure WebLogic Server plug-ins for Apache, Microsoft, and Netscape Web servers. For a complete list of parameters for configuring the proxy servlet and the plug-ins for third-part Web servers, see Parameters for Web Server Plug-ins in Using Oracle WebLogic Server Proxy Plug-Ins.
The syntax for specifying the parameters, and the file where they are specified, is different for the proxy servlet and for each of the plug-ins.
For the proxy servlet, specify the parameters in web.xml
, each in its own <init-param>
stanza within the <servlet>
stanza of web.xml
. For example:
<init-param> <param-name>ParameterName</param-name> <param-value>ParameterValue</param-value> </init-param>
Table 10-1 Proxy Servlet Deployment Parameter
Parameter | Usage |
---|---|
WebLogicCluster |
Where If you are using SSL between the plug-in and WebLogic Server, set the port number to the SSL listen port (see Configuring the Listen Port) and set the |
SecureProxy |
Valid values are ON and OFF. If you are using SSL between the plug-in and WebLogic Server, set the port number to the SSL listen port (see Configuring the Listen Port) and set the |
DebugConfigInfo |
Valid values are ON and OFF. If set to ON, you can query the |
ConnectRetrySecs |
Interval in seconds that the servlet will sleep between attempts to connect to a server instance. Assign a value less than The number of connection attempts the servlet makes before returning an Syntax:
|
ConnectTimeoutSecs |
Maximum time in seconds that the servlet will attempt to connect to a server instance. Assign a value greater than If Syntax:
|
PathTrim |
String trimmed by the plug-in from the beginning of the original URL, before the request is forwarded to the cluster. Syntax:
Example: If the URL http://myWeb.example.com/weblogic/foo is passed to the plug-in for parsing and if /weblogic the URL forwarded to WebLogic Server is: http://myWeb.example.com:7001/foo
|
TrimExt |
The file extension to be trimmed from the end of the URL. Syntax:
|
clientCertProxy |
Specifies to trust client certificates in the Valid values are true and false. The default value is false. This setting is useful if user authentication is performed on the proxy server—setting The For this reason, if you set |
PathPrepend |
String that the servlet prepends to the original URL, after
|
RoutingHandlerClassName |
Extends the proxy servlet to support Web service cluster routing. See Managing Web Services in a Cluster in Developing JAX-WS Web Services for Oracle WebLogic Server.
|
Parent topic: Set Up the HttpClusterServlet
Accessing Applications Via the Proxy Server
Ensure that application clients access through the proxy server are deployed to your cluster. Address client requests to the listen address and listen port of the proxy server.
If you have problems:
-
Ensure that all server instances have unique address/port combinations.
Each of the server instances in the configuration must have a unique combination of listen address and listen port.
-
Ensure that the proxy servlet is the default application for the proxy server.
If you get "page not found" error when you try to your application, make sure that
weblogic.xml
is in\WEB-INF
for the application and that it sets thecontext-root
deployment parameter to "/". -
When all else fails, restart
If you are having problems, try to restart all your servers. Some of the changes you made while configuring your setup may not persist to the configuration file.
-
Verify Your Configuration
To verify the configuration of the
HttpClusterServlet
:-
Set the
DebugConfigInfo
parameter inweb.xml
to ON. -
Use a Web browser to access the following URL:
http://myServer:port/placeholder.jsp?__WebLogicBridgeConfig
Where:-
myServer
is the Managed Server on the proxy machine whereHttpClusterServlet
runs, -
port
is the port number on the server that is listening for HTTP requests, and -
placeholder.jsp
is a file that does not exist on the server.
The plug-in gathers configuration information and run-time statistics and returns the information to the browser. For more information, see Parameters for Web Server Plug-ins in Using Oracle WebLogic Server Proxy Plug-Ins.
-
Parent topic: Set Up the HttpClusterServlet
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:
Parent topic: Cluster Implementation Procedures
Configure Migratable Targets for Pinned Services
WebLogic Server enables you to configure an optional migratable target, which is a special target that can migrate from one server in a cluster to another. As such, a migratable target provides a way to group pinned services that should move together. When the migratable target is migrated, all services hosted by that target are migrated. Pinned services include JMS-related services (for example, JMS servers, SAF agents, path services, and persistent stores) or the 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 available WebLogic Server instance in the cluster. See Understanding Migratable Targets In a Cluster.
Parent topic: Cluster Implementation Procedures
Package Applications for Deployment
You must package applications before you deploy them to WebLogic Server. For more information ,see Packaging Applications Using wlpackage in Developing Applications for Oracle WebLogic Server.
Parent topic: Cluster Implementation Procedures
Deploy Applications
Clustered objects in WebLogic Server should be deployed homogeneously. To ensure homogeneous deployment, when you select a target, use the cluster name rather than individual WebLogic Server instances in the cluster. If cluster is dynamic or mixed cluster type, you can select singleton or distributed deployment based on your need for one single instance across entire cluster or one instance per cluster member.
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). For a discussion of application deployment in clustered environments, see Methods of Configuring Clusters. For a broad discussion of deployment topics, see Deploying Applications to Oracle WebLogic Server.
Note:
All server instances in your cluster should be running when you deploy applications to the cluster using the WebLogic Server Administration Console.
- Deploying to a Single Server Instance (Pinned Deployment)
- Cancelling Cluster Deployments
- Viewing Deployed Applications
- Undeploying Deployed Applications
Parent topic: Cluster Implementation Procedures
Deploying to a Single 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 WebLogic Server Administration Console or using the command line weblogic.Deployer
.
Parent topic: Deploy Applications
Cancelling Cluster Deployments
You can cancel a deployment using the WebLogic Server Administration Console or using the command line weblogic.Deployer
.
- Cancel Deployment from the Command Line
- Cancel Deployment Using the WebLogic Server Administration Console
Parent topic: Deploy Applications
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
Parent topic: Cancelling Cluster Deployments
Cancel Deployment Using the WebLogic Server Administration Console
In the WebLogic Server Administration Console, open the Tasks node to view and to cancel any current deployment tasks.
Parent topic: Cancelling Cluster Deployments
Viewing Deployed Applications
To view a deployed application in the WebLogic Server Administration Console:
- In the WebLogic Server Administration Console, select Deployments.
- View a list of deployed applications in the table.
Parent topic: Deploy Applications
Undeploying Deployed Applications
To undeploy a deployed application from the WebLogic Server Administration Console, do as follows:
- In the WebLogic Server Administration Console, select Deployments.
- In the table, select the check box to the left of the application you want to undeploy.
- If you have not already done so, click Lock & Edit in the top left corner of the Console.
- Click Stop when you want the application to stop (undeploy).
- Click Yes.
- Click Activate Changes in the top left corner of the Console to activate your changes.
Parent topic: Deploy Applications
Deploying, Activating, and Migrating Migratable Services
The sections that follow provide guidelines and instructions for deploying, activating, and migrating migratable services.
- Deploying JMS to a Migratable Target Server Instance
- Activating JTA as a Migratable Service
- Migrating a Pinned Service to a Target Server Instance
Parent topic: Cluster Implementation Procedures
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 to migrate the service within the target server list at a later time. Use the instructions that follow to deploy a JMS service 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, 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).
Before you begin, use the instructions in Configure Migratable Targets for Pinned Services, to create a migratable target for the cluster. Then, deploy JMS-related services to a migratable target, as described in the following topics of Oracle WebLogic Server Administration Console Online Help:
Parent topic: Deploying, Activating, and Migrating Migratable Services
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. For instructions to change the current server instance that hosts the JTA service, see Migrating a Pinned Service to a Target Server Instance.
Parent topic: Deploying, Activating, and Migrating Migratable Services
Migrating a Pinned Service to a Target Server Instance
After you have deployed a migratable service, you can use the WebLogic Server Administration Console to manually 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 listed 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 activate the service upon the next startup. If you migrate a service to a running WebLogic Server instance, the migration takes place immediately.
Before you begin, use the instructions in Deploying JMS to a Migratable Target Server Instance, to deploy a pinned service to the cluster. Next, migrate the pinned service using the WebLogic Server Administration Console by following the appropriate instructions in the Oracle WebLogic Server Administration Console Online Help:
Here are some additional steps that are not covered in the Console Help instructions:
Parent topic: Deploying, Activating, and Migrating Migratable Services
Migrating When the Currently Active Host is Unavailable
Use this migration procedure if a clustered Managed Server that was the active server for the migratable service crashes or becomes unreachable.
This procedure purges the failed Managed Server's configuration cache. The purpose of purging the cache is to ensure that, when the failed server instance is once again available, it does not re-deploy a service that you have since migrated to another Managed Server. Purging the cache eliminates the risk that Managed Server which was previously the active host for the service uses local, out-of-date configuration data when it starts up again.
Parent topic: Migrating a Pinned Service to a Target Server Instance
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 Using Sessions and Session Persistence in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
In-memory HTTP session state replication is controlled separately for each application you deploy. For the application, the parameter that controls it is PersistentStoreType
, which appears within the session-descriptor element in the WebLogic deployment descriptor file and weblogic.xml
.
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> <persistent-store-type>replicated</persistent-store-type> </session-descriptor>
Parent topic: Cluster Implementation Procedures
Additional Configuration Topics
The sections below contain useful tips for particular cluster configurations.
- Configure IP Sockets
- Configure Multicast Time-To-Live (TTL)
- Configure Multicast Buffer Size
- Configure Multicast Data Encryption
- Configure Machine Names
- Configuration Notes for Multitier Architecture
- Enable URL Rewriting
Parent topic: Cluster Implementation Procedures
Configure IP Sockets
For best socket performance, Oracle 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 have to 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 to determine the number of socket reader threads necessary for your cluster, see Determining Potential Socket Usage. If you are deploying a servlet cluster in a multitier cluster architecture, this has an effect on how many sockets you require, as described in Configuration Considerations for Multitier Architecture.
The following sections have instructions to configure native socket reader threads for host machines and set the number of reader threads for host and client machines.
- Configure Native IP Sockets Readers on Machines that Host Server Instances
- Set the Number of Reader Threads on Machines that Host Server Instances
- Set the Number of Reader Threads on Client Machines
Parent topic: Additional Configuration Topics
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:
- Open the WebLogic Server Administration Console.
- Select Environments > Servers.
- Select the name of the server instance you want to configure.
- If you have not already done so, click Lock & Edit in the top left corner of the Console.
- Select Configuration > Tuning.
- Select the
Enable Native IO
check box. - Click Save.
- Click Activate Changes in the top left corner of the Console to activate your changes.
Parent topic: Configure IP Sockets
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:
- Open the WebLogic Server Administration Console.
- Select Environments > Servers.
- Select the name of the server instance you want to configure.
- If you have not already done so, click Lock & Edit in the top left corner of the Console.
- Select Configuration > Tuning.
- Edit the percentage of Java reader threads in the
Socket Readers
field. The number of Java socket readers is computed as a percentage of the number of total execute threads (as shown in theExecute Threads
field). - Click Save to save your changes.
- Click Activate Changes in the top left corner of the Console to activate your changes.
Parent topic: Configure IP Sockets
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.
Parent topic: Configure IP Sockets
Configure Multicast Time-To-Live (TTL)
If your cluster spans multiple subnets in a WAN, the value of the Multicast 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, see If Your Cluster Spans Multiple Subnets In a WAN .
To configure the Multicast TTL for a cluster, change the Multicast TTL
value on the Multicast page for the cluster in the WebLogic Server 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" />
Note:
When relying upon the Multicast TTL value, it is important to remember that within a clustered environment it is possible that timestamps across servers may not always be synchronized. For example, this can occur in replicated HTTP sessions and EJBs.
When the ClusterDebug flag is enabled and cluster members clocks are not synchronized, an error is printed to the server log.
Parent topic: Additional Configuration Topics
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 warning in the UDP Parameter With Additional Caution in Solaris Tunable Parameters Reference Manual.
Parent topic: Additional Configuration Topics
Configure Multicast Data Encryption
- Open the WebLogic Server Administration Console.
- Select Environment > Clusters > cluster_name > Multicast node.
- Select
Advanced
options. - Select Enable Multicast Data Encryption.
Only the data portion of the multicast message is encrypted. Information contained in the multicast header is not encrypted.
Parent topic: Additional Configuration Topics
Configure Machine Names
Configure a machine name, if:
-
Your cluster will span multiple machines, and multiple server instances will run on individual machines in the cluster.
Or
-
You plan to run Node Manager on a machine that does not host an Administration Server.
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 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.
Parent topic: Additional Configuration Topics
Configuration Notes for Multitier Architecture
If your cluster has a multitier architecture, see the configuration guidelines in Configuration Considerations for Multitier Architecture.
Parent topic: Additional Configuration Topics
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 Instead of Cookies in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
Parent topic: Additional Configuration Topics