PK
>QFoa, mimetypeapplication/epub+zipPK >QF iTunesMetadata.plistg
This chapter describes the load balancing support that a WebLogic Server cluster provides for different types of objects, and related planning and configuration considerations for architects and administrators.
This chapter contains the following sections:
For information about replication and failover in a cluster, see Failover and Replication in a Cluster.
You can accomplish load balancing of servlets and JSPs with the built-in load balancing capabilities of a WebLogic proxy plug-in or with separate load balancing hardware.
Note: In addition to distributing HTTP traffic, external load balancers can distribute initial context requests that come from Java clients overt3 and the default channel. See Load Balancing for EJBs and RMI Objects for a discussion of object-level load balancing in WebLogic Server. |
The WebLogic proxy plug-in maintains a list of WebLogic Server instances that host a clustered servlet or JSP, and forwards HTTP requests to those instances on a round-robin basis. This load balancing method is described in Round-Robin Load Balancing.
The plug-in also provides the logic necessary to locate the replica of a client's HTTP session state if a WebLogic Server instance should fail.
WebLogic Server supports the following Web servers and associated proxy plug-ins:
WebLogic Server with the HttpClusterServlet
Netscape Enterprise Server with the Netscape (proxy) plug-in
Apache with the Apache Server (proxy) plug-in
Microsoft Internet Information Server with the Microsoft-IIS (proxy) plug-in
For instructions on setting up proxy plug-ins, see Configure Proxy Plug-Ins.
For a description of connection and failover for HTTP sessions in a cluster with proxy plug-ins, see Accessing Clustered Servlets and JSPs Using a Proxy.
Clusters that employ a hardware load balancing solution can use any load balancing algorithm supported by the hardware. These can include advanced load-based balancing strategies that monitor the utilization of individual machines.
If you choose to use load balancing hardware instead of a proxy plug-in, it must support a compatible passive or active cookie persistence mechanism, and SSL persistence.
Passive Cookie Persistence
Passive cookie persistence enables WebLogic Server to write a cookie containing session parameter information through the load balancer to the client. For information about the session cookie and how a load balancer uses session parameter data to maintain the relationship between the client and the primary WebLogic Server hosting a HTTP session state, see Load Balancers and the WebLogic Session Cookie..
Active Cookie Persistence
You can use certain active cookie persistence mechanisms with WebLogic Server clusters, provided the load balancer does not modify the WebLogic Server cookie. 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.
SSL Persistence
When SSL persistence is used, the load balancer performs all encryption and decryption of data between clients and the WebLogic Server cluster. The load balancer then uses the plain text cookie that WebLogic Server inserts on the client to maintain an association between the client and a particular server in the cluster.
A load balancer that uses passive cookie persistence can use a string in the WebLogic session cookie to associate a client with the server hosting its primary HTTP session state. The string 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.
The format of a session cookie is:
sessionid!primary_server_id!secondary_server_id
where:
sessionid
is a randomly generated identifier of the HTTP session. The length of the value is configured by the IDLength
parameter in the <session-descriptor>
element in the weblogic.xml
file for an application. By default, the sessionid
length is 52 bytes.
primary_server_id
and secondary_server_id
are 10 character identifiers of the primary and secondary hosts for the session.
Note: For sessions using non-replicated memory, cookie, or file-based session persistence, thesecondary_server_id is not present. For sessions that use in-memory replication, if the secondary session does not exist, the secondary_server_id is "NONE". |
For general instructions on configuring load balancers, see Configuring Load Balancers that Support Passive Cookie Persistence. Instructions for configuring BIG-IP, see Configuring BIG-IP Hardware with Clusters.
For programming constraints and recommendations for clustered servlets and JSPs, see Programming Considerations for Clustered Servlets and JSPs..
For a description of connection and failover for HTTP sessions in a cluster with load balancing hardware, see Accessing Clustered Servlets and JSPs with Load Balancing Hardware..
This section describes WebLogic Server load balancing algorithms for EJBs and RMI objects.
The load balancing algorithm for an object is maintained in the replica-aware stub obtained for a clustered object.
By default, WebLogic Server clusters use round-robin load balancing, described in Round-Robin Load Balancing. You can configure a different default load balancing method for a cluster by using the Administration Console to set weblogic.cluster.defaultLoadAlgorithm
. For instructions, see Configure Load Balancing Method for EJBs and RMIs. You can also specify the load balancing algorithm for a specific RMI object using the -loadAlgorithm
option in rmic
, or with the home-load-algorithm
or stateless-bean-load-algorithm
in an EJB's deployment descriptor. A load balancing algorithm that you configure for an object overrides the default load balancing algorithm for the cluster.
In addition to the standard load balancing algorithms, WebLogic Server supports custom parameter-based routing. For more information, see Parameter-Based Routing for Clustered Objects.
Also, external load balancers can distribute initial context requests that come from Java clients over t3
and the default channel. However, because WebLogic Server load balancing for EJBs and RMI objects is controlled via replica-aware stubs, including situations where server affinity is employed, you should not route client requests, following the initial context request, through the load balancers. When using the t3
protocol with external load balancers, you must ensure that only the initial context request is routed through the load balancers, and that subsequent requests are routed and controlled using WebLogic Server load balancing.
Oracle advises against using the t3s
protocol with external load balancers. In cases where the use of t3
and SSL with external load balancers is required, Oracle recommends using t3
tunneling through HTTPS. In cases where server affinity is required, you must use HTTP session IDs for routing requests, and must terminate SSL at the load balancer performing session-based routing to enable appropriate routing of requests based on session IDs.
WebLogic Server uses the round-robin algorithm as the default load balancing strategy for clustered object stubs when no algorithm is specified. This algorithm is supported for RMI objects and EJBs. It is also the method used by WebLogic proxy plug-ins.
The round-robin algorithm cycles through a list of WebLogic Server instances in order. For clustered objects, the server list consists of WebLogic Server instances that host the clustered object. For proxy plug-ins, the list consists of all WebLogic Server instances that host the clustered servlet or JSP.
The advantages of the round-robin algorithm are that it is simple, cheap and very predictable. The primary disadvantage is that there is some chance of convoying. Convoying occurs when one server is significantly slower than the others. Because replica-aware stubs or proxy plug-ins access the servers in the same order, a slow server can cause requests to "synchronize" on the server, then follow other servers in order for future requests.
Note: WebLogic Server does not always load balance an object's method calls. For more information, see Optimization for Collocated Objects. |
This algorithm applies only to EJB and RMI object clustering.
Weight-based load balancing improves on the round-robin algorithm by taking into account a pre-assigned weight for each server. You can use the Server > Configuration > Cluster page in the Administration Console to assign each server in the cluster a numerical weight between 1 and 100, in the Cluster Weight
field. This value determines what proportion of the load the server will bear relative to other servers. If all servers have the same weight, they will each bear an equal proportion of the load. If one server has weight 50 and all other servers have weight 100, the 50-weight server will bear half as much as any other server. This algorithm makes it possible to apply the advantages of the round-robin algorithm to clusters that are not homogeneous.
If you use the weight-based algorithm, carefully determine the relative weights to assign to each server instance. Factors to consider include:
The processing capacity of the server's hardware in relationship to other servers (for example, the number and performance of CPUs dedicated to WebLogic Server).
The number of non-clustered ("pinned") objects each server hosts.
If you change the specified weight of a server and reboot it, the new weighting information is propagated throughout the cluster via the replica-aware stubs. For related information see Cluster-Wide JNDI Naming Service.
Note: WebLogic Server does not always load balance an object's method calls. For more information, see Optimization for Collocated Objects.In this version of WebLogic Server, weight-based load balancing is not supported for objects that communicate using the RMI/IIOP protocol. |
The random method of load balancing applies only to EJB and RMI object clustering.
In random load balancing, requests are routed to servers at random. Random load balancing is recommended only for homogeneous cluster deployments, where each server instance runs on a similarly configured machine. A random allocation of requests does not allow for differences in processing power among the machines upon which server instances run. If a machine hosting servers in a cluster has significantly less processing power than other machines in the cluster, random load balancing will give the less powerful machine as many requests as it gives more powerful machines.
Random load balancing distributes requests evenly across server instances in the cluster, increasingly so as the cumulative number of requests increases. Over a small number of requests the load may not be balanced exactly evenly.
Disadvantages of random load balancing include the slight processing overhead incurred by generating a random number for each request, and the possibility that the load may not be evenly balanced over a small number of requests.
Note: WebLogic Server does not always load balance an object's method calls. For more information, see Optimization for Collocated Objects. |
WebLogic Server provides three load balancing algorithms for RMI objects that provide server affinity. Server affinity turns off load balancing for external client connections; instead, the client considers its existing connections to WebLogic Server instances when choosing the server instance on which to access an object. If an object is configured for server affinity, the client-side stub attempts to choose a server instance to which it is already connected, and continues to use the same server instance for method calls. All stubs on that client attempt to use that server instance. If the server instance becomes unavailable, the stubs fail over, if possible, to a server instance to which the client is already connected.
The purpose of server affinity is to minimize the number IP sockets opened between external Java clients and server instances in a cluster. WebLogic Server accomplishes this by causing method calls on objects to "stick" to an existing connection, instead of being load balanced among the available server instances. With server affinity algorithms, the less costly server-to-server connections are still load-balanced according to the configured load balancing algorithm—load balancing is disabled only for external client connections.
Server affinity is used in combination with one of the standard load balancing methods: round-robin, weight-based, or random:
round-robin-affinity—server affinity governs connections between external Java clients and server instances; round-robin load balancing is used for connections between server instances.
weight-based-affinity—server affinity governs connections between external Java clients and server instances; weight-based load balancing is used for connections between server instances.
random-affinity—server affinity governs connections between external Java clients and server instances; random load balancing is used for connections between server instances.
A client can request an initial context from a particular server instance in the cluster, or from the cluster by specifying the cluster address in the URL. The connection process varies, depending on how the context is obtained:
If the initial context is requested from a specific Managed Server, the context is obtained using a new connection to the specified server instance.
If the initial context is requested from a cluster, by default, context requests are load balanced on a round-robin basis among the clustered server instances. To reuse an existing connection between a particular JVM and the cluster, set ENABLE_SERVER_AFFINITY
to true in the hash table of weblogic.jndi.WLContext
properties you specify when obtaining context. (If a connection is not available, a new connection is created.) ENABLE_SERVER_AFFINITY
is only supported when the context is requested from the cluster address.
If you use WebLogic Server Common Secure Interoperability (CSIv2) functionality to support stateful interactions with the WebLogic Server Java EE Application Client ("thin client"), you must use an affinity-based load balancing algorithm to ensure that method calls stick to a server instance. Otherwise, all remote calls will be authenticated. To prevent redundant authentication of stateful CSIv2 clients, use one of the load balancing algorithms described in Round-Robin Affinity, Weight-Based Affinity, and Random-Affinity.
WebLogic Server has three load balancing algorithms that provide server affinity:
round-robin-affinity
weight-based-affinity
random-affinity
Server affinity is supported for all types of RMI objects including JMS objects, all EJB home interfaces, and stateless EJB remote interfaces.
The server affinity algorithms consider existing connections between an external Java client and server instances in balancing the client load among WebLogic Server instances. Server affinity:
Turns off load balancing between external Java clients and server instances
Causes method calls from an external Java client to stick to a server instance to which the client has an open connection, assuming that the connection supports the necessary protocol and QOS
In the case of failure, causes the client to failover to a server instance to which it has an open connection, assuming that the connection supports the necessary protocol and QOS
Does not affect the load balancing performed for server-to-server connections
The following examples illustrate the effect of server affinity under a variety of circumstances. In each example, the objects deployed are configured for round-robin-affinity.
Example 1—Context From Cluster
In the example shown in Figure 5-1, the client obtains context from the cluster. Lookups on the context and object calls stick to a single connection. Requests for new initial context are load balanced on a round-robin basis.
Client requests a new initial context from the cluster (Provider_URL=clusteraddress
) and obtains the context from MS1.
Client does a lookup on the context for Object A. The lookup goes to MS1.
Client issues a call to Object A. The call goes to MS1, to which the client is already connected. Additional method calls to Object A stick to MS1.
Client requests a new initial context from the cluster (Provider_URL=clusteraddress
) and obtains the context from MS2.
Client does a lookup on the context for Object B. The call goes to MS2, to which the client is already connected. Additional method calls to Object B stick to MS2.
Example 2—Server Affinity and Failover
The example shown in Figure 5-2 illustrates the effect that server affinity has on object failover. When a Managed Server goes down, the client fails over to another Managed Server to which it has a connection.
Client requests new initial context from MS1.
Client does a lookup on the context for Object A. The lookup goes to MS1.
Client makes a call to Object A. The call goes to MS1, to which the client is already connected. Additional calls to Object A stick to MS1.
The client obtains a stub for Object C, which is pinned to MS3. The client opens a connection to MS3.
MS1 fails.
Client makes a call to Object A.The client no longer has a connection to MS1. Because the client is connected to MS3, it fails over to a replica of Object A on MS3.
Example 3—Server affinity and server-to-server connections
The example shown in Figure 5-3 illustrates the fact that server affinity does not affect the connections between server instances.
A JSP on MS4 obtains a stub for Object B.
The JSP selects a replica on MS1. For each method call, the JSP cycles through the Managed Servers upon which Object B is available, on a round-robin basis.
Parameter-based routing allows you to control load balancing behavior at a lower level. Any clustered object can be assigned a CallRouter
. This is a class that is called before each invocation with the parameters of the call. The CallRouter
is free to examine the parameters and return the name server to which the call should be routed. For information about creating custom CallRouter
classes, see "Parameter-Based Routing for Clustered Objects" in Developing RMI Applications for Oracle WebLogic Server.
WebLogic Server does not always load balance an object's method calls. In most cases, it is more efficient to use a replica that is collocated with the stub itself, rather than using a replica that resides on a remote server. Figure 5-4 illustrates this.
In this example, a client connects to a servlet hosted by the first WebLogic Server instance in the cluster. In response to client activity, the servlet obtains a replica-aware stub for Object A. Because a replica of Object A is also available on the same server instance, the object is said to be collocated with the client's stub.
WebLogic Server always uses the local, collocated copy of Object A, rather than distributing the client's calls to other replicas of Object A in the cluster. It is more efficient to use the local copy, because doing so avoids the network overhead of establishing peer connections to other servers in the cluster.
This optimization is often overlooked when planning WebLogic Server clusters. The collocation optimization is also frequently confusing for administrators or developers who expect or require load balancing on each method call. If your Web application is deployed to a single cluster, the collocation optimization overrides any load balancing logic inherent in the replica-aware stub.
If you require load balancing on each method call to a clustered object, see Recommended Multi-Tier Architecture, for information about how to plan your WebLogic Server cluster accordingly.
As an extension to the basic collocation strategy, WebLogic Server attempts to use collocated clustered objects that are enlisted as part of the same transaction. When a client creates a UserTransaction
object, WebLogic Server attempts to use object replicas that are collocated with the transaction. This optimization is depicted in the example shown in Figure 5-5.
In this example, a client attaches to the first WebLogic Server instance in the cluster and obtains a UserTransaction
object. After beginning a new transaction, the client looks up Objects A and B to do the work of the transaction. In this situation WebLogic Server always attempts to use replicas of A and B that reside on the same server as the UserTransaction
object, regardless of the load balancing strategies in the stubs for A and B.
This transactional collocation strategy is even more important than the basic optimization described in Optimization for Collocated Objects. If remote replicas of A and B were used, added network overhead would be incurred for the duration of the transaction, because the peer connections for A and B would be locked until the transaction committed.WebLogic Server. By using collocating clustered objects during a transaction, WebLogic Server reduces the network load for accessing the individual objects.
WebLogic Server JMS supports server affinity for distributed JMS destinations and client connections.
By default, a WebLogic Server cluster uses the round-robin method to load balance objects. To use a load balancing algorithm that provides server affinity for JMS objects, you must configure the desired method for the cluster as a whole. You can configure the load balancing algorithm by using the Administration Console to set weblogic.cluster.defaultLoadAlgorithm
. For instructiolns, see Configure Load Balancing Method for EJBs and RMIs.
Server affinity is supported for JMS applications that use the distributed destination feature; this feature is not supported for standalone destinations. If you configure server affinity for JMS connection factories, a server instance that is load balancing consumers or producers across multiple members of a distributed destination will first attempt to load balance across any destination members that are also running on the same server instance.
For detailed information on how the JMS connection factory's Server Affinity Enabled option affects the load balancing preferences for distributed destination members, see "How Distributed Destination Load Balancing Is Affected When Using the Server Affinity Enabled Attribute" in Administering JMS Resources for Oracle WebLogic Server.
A system administrator can establish load balancing of JMS destinations across multiple servers in a cluster by configuring multiple JMS servers and using targets to assign them to the defined WebLogic Servers. Each JMS server is deployed on exactly one WebLogic Server and handles requests for a set of destinations. During the configuration phase, the system administrator enables load balancing by specifying targets for JMS servers. For instructions on setting up targets, see Configure Migratable Targets for Pinned Services. For instructions on deploying a JMS server to a migratable target, see Deploying, Activating, and Migrating Migratable Services.
A system administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic Servers. Connection factories are described in more detail in "ConnectionFactory" in Developing JMS Applications for Oracle WebLogic Server.
The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate server.
WebLogic Server provides server affinity for client connections. If an application has a connection to a given server instance, JMS will attempt to establish new JMS connections to the same server instance.
When creating a connection, JMS will try first to achieve initial context affinity. It will attempt to connect to the same server or servers to which a client connected for its initial context, assuming that the server instance is configured for that connection factory. For example, if the connection factory is configured for servers A and B, but the client has an InitialContext on server C, then the connection factory will not establish the new connection with A, but will choose between servers B and C.
If a connection factory cannot achieve initial context affinity, it will try to provide affinity to a server to which the client is already connected. For instance, assume the client has an InitialContext on server A and some other type of connection to server B. If the client then uses a connection factory configured for servers B and C it will not achieve initial context affinity. The connection factory will instead attempt to achieve server affinity by trying to create a connection to server B, to which it already has a connection, rather than server C.
If a connection factory cannot provide either initial context affinity or server affinity, then the connection factory is free to make a connection wherever possible. For instance, assume a client has an initial context on server A, no other connections and a connection factory configured for servers B and C. The connection factory is unable to provide any affinity and is free to attempt new connections to either server B or C.
Note: In the last case, if the client attempts to make a second connection using the same connection factory, it will go to the same server as it did on the first attempt. That is, if it chose server B for the first connection, when the second connection is made, the client will have a connection to server B and the server affinity rule will be enforced. |
This chapter describes how WebLogic Server clusters communicate using IP sockets and IP unicast or multicast.
WebLogic Server instances in a cluster communicate with one another using two basic network technologies:
IP unicast or multicast, which server instances use to broadcast availability of services and heartbeats that indicate continued availability. See Considerations for Choosing Unicast or Multicast for information on selecting unicast or multicast.
IP sockets, which are the conduits for peer-to-peer communication between clustered server instances.
This chapter includes the following sections:
WebLogic Server supports two cluster messaging protocols:
Multicast: This protocol relies on UDP multicast and has been supported in WebLogic Server clusters since WebLogic Server 4.0.
Unicast: This protocol relies on point-to-point TCP/IP sockets and was added in WebLogic Server 10.0.
This section includes the following topics:
Multicast is a simple broadcast technology that enables multiple applications to "subscribe" to a given IP address and port number and listen for messages.
Note: A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255. The default multicast value used by WebLogic Server is 239.192.0.0. You should not use any multicast address within the range x.0.0.1. Multicast ports have the normal UDP port ranges (0 to 65535), however certain UDP ports are reserved for specific purposes and should generally be avoided. |
Multicast broadcasts messages to applications, but it does not guarantee that messages are actually received. If an application's local multicast buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are "dropped." Because of this limitation, WebLogic Server instances allow for the possibility that they may occasionally miss messages that were broadcast over multicast.
The WebLogic Server multicast implementation uses standard UDP multicast to broadcast the cluster messages to a group that is explicitly listening on the multicast address and port over which the message is sent. Since UDP is not a reliable protocol, WebLogic Server builds its own reliable messaging protocol into the messages it sends to detect and retransmit lost messages.
Most operating systems and switches support UDP multicast by default between machines in the same subnet. However, most routers do not support the propagation of UDP multicast messages between subnets by default. In environments that do support UDP multicast message propagation, UDP multicast has a time-to-live (TTL) mechanism built into the protocol. Each time the message reaches a router, the TTL is decremented by 1 before it routes the message. When the TTL reaches zero, the message will no longer be propagated between networks, making it an effective control for the range of a UDP multicast message. By default, WebLogic Server sets the TTL for its multicast cluster messages to 1, which restricts the message to the current subnet.
When using multicast, the cluster heartbeat mechanism will remove a server instance from the cluster if it misses three heartbeat messages in a row to account for the fact that UDP is not considered a reliable protocol. Since the default heartbeat frequency is one heartbeat every 10 seconds, this means it can take up to 30 seconds to detect that a server instance has left the cluster. Socket death detection or failed connection attempts can also accelerate this detection.
In summary, WebLogic Server multicast cluster messaging protocol:
Uses a very efficient and scalable peer-to-peer model where a server instance sends each message directly to the network once and the network makes sure that each cluster member receives the message directly from the network.
Works out of the box in most environments where the cluster members are in a single subnet.
Requires additional configuration in the router and WebLogic Server (for example multicast TTL) if the cluster members span more than one subnet.
Uses three consecutive missed heartbeats to remove a server instance from another server's cluster membership list.
To test an environment for its ability to support the WebLogic Server multicast messaging protocol, WebLogic Server provides a Java command-line utility known as MulticastTest.
WebLogic Server uses multicast for all one-to-many communications among server instances in a cluster. This communication includes:
Cluster-wide JNDI updates—Each WebLogic Server instance in a cluster uses multicast to announce the availability of clustered objects that are deployed or removed locally. Each server instance in the cluster monitors these announcements and updates its local JNDI tree to reflect current deployments of clustered objects. For more details, see Cluster-Wide JNDI Naming Service.
Cluster heartbeats—Each WebLogic Server instance in a cluster uses multicast to broadcast regular "heartbeat" messages that advertise its availability. By monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed. (Clustered server instances also monitor IP sockets as a more immediate method of determining when a server instance has failed.)
Clusters with many nodes—Multicast communication is the option of choice for clusters with many nodes.
Because multicast communications control critical functions related to detecting failures and maintaining the cluster-wide JNDI tree (described in Cluster-Wide JNDI Naming Service) it is important that neither the cluster configuration nor the network topology interfere with multicast communications. The sections that follow provide guidelines for avoiding problems with multicast communication in a cluster.
In many deployments, clustered server instances reside within a single subnet, ensuring multicast messages are reliably transmitted. However, you may want to distribute a WebLogic Server cluster across multiple subnets in a Wide Area Network (WAN) to increase redundancy, or to distribute clustered server instances over a larger geographical area.
If you choose to distribute a cluster over a WAN (or across multiple subnets), plan and configure your network topology to ensure that multicast messages are reliably transmitted to all server instances in the cluster. Specifically, your network must meet the following requirements:
Full support of IP multicast packet propagation. In other words, all routers and other tunneling technologies must be configured to propagate multicast messages to clustered server instances.
Network latency low enough to ensure that most multicast messages reach their final destination in approximately 10 milliseconds.
Multicast Time-To-Live (TTL) value for the cluster high enough to ensure that routers do not discard multicast packets before they reach their final destination. For instructions on setting the Multicast TTL parameter, see Configure Multicast Time-To-Live (TTL).
Note: Distributing a WebLogic Server cluster over a WAN may require network facilities in addition to the multicast requirements described above. For example, you may want to configure load balancing hardware to ensure that client requests are directed to server instances in the most efficient manner (to avoid unnecessary network hops). |
Although it may be possible to tunnel multicast traffic through a firewall, this practice is not recommended for WebLogic Server clusters. Treat each WebLogic Server cluster as a logical unit that provides one or more distinct services to clients of a Web application. Do not split this logical unit between different security zones. Furthermore, any technologies that potentially delay or interrupt IP traffic can disrupt a WebLogic Server cluster by generating false failures due to missed heartbeats.
Although multiple WebLogic Server clusters can share a single IP multicast address and port, other applications should not broadcast or subscribe to the multicast address and port used by your cluster or clusters. That is, if the machine or machines that host your cluster also host other applications that use multicast communications, make sure that those applications use a different multicast address and port than the cluster does.
Sharing the cluster multicast address with other applications forces clustered server instances to process unnecessary messages, introducing overhead. Sharing a multicast address may also overload the IP multicast buffer and delay transmission of WebLogic Server heartbeat messages. Such delays can result in a WebLogic Server instance being marked as failed, simply because its heartbeat messages were not received in a timely manner.
For these reasons, assign a dedicated multicast address for use by WebLogic Server clusters, and ensure that the address can support the broadcast traffic of all clusters that use the address.
If server instances in a cluster do not process incoming messages on a timely basis, increased network traffic, including negative acknowledgement (NAK) messages and heartbeat re-transmissions, can result. The repeated transmission of multicast packets on a network is referred to as a multicast storm, and can stress the network and attached stations, potentially causing end-stations to hang or fail. Increasing the size of the multicast buffers can improve the rate at which announcements are transmitted and received, and prevent multicast storms. See Configure Multicast Buffer Size.
WebLogic Server provides an alternative to using multicast to handle cluster messaging and communications. Unicast configuration is much easier because it does not require the cross network configuration that multicast requires. Additionally, it reduces potential network errors that can occur from multicast address conflicts.
The WebLogic Server unicast protocol uses standard TCP/IP sockets to send messages between cluster members. Since all networks and network devices support TCP/IP sockets, unicast simplifies out of the box cluster configuration. It typically requires no additional configuration, regardless of the network topology between the cluster members. Unicast is the default cluster protocol in WebLogic Server.
Since TCP/IP sockets are a point-to-point mechanism, WebLogic Server's unicast implementation uses a group leader strategy to limit the growth in the number of sockets required as the cluster size grows. The cluster is split into one or more groups and each group has a group leader. Group members communicate with the group leader and the group leaders also communicate with other group leaders in the cluster. If a group leader fails, the group elects another group leader.
For small clusters of 10 Managed Servers or less, the cluster contains a single group and therefore a single group leader. The other server instances in the group make a TCP/IP socket connection to the group leader that they use to send and receive cluster messages. When the group leader receives a cluster message from one server instance, it retransmits that message to all other members of the group. The group leader acts as a message relay to propagate the messages across the cluster.
For larger clusters, the cluster splits into multiple groups of 10 Managed Servers. For example, a cluster of 16 Managed Servers will have two groups, one with 10 members and one with six. In these clusters with multiple groups, the group leaders are connected directly to one another. When a group leader receives a cluster message, it not only retransmits that message to other members of its group but also to every other group leader. This allows the entire cluster to receive every cluster message.
When using unicast, the cluster heartbeat mechanism will remove a server instance from the cluster if it misses a single heartbeat message since TCP/IP is a reliable protocol. Unicast will check every 15 seconds to see if it has missed a heartbeat. This extra five seconds is to allow sufficient time for the message to travel up to three hops, from the remote group's member to the remote group's leader to the local group's leader, and finally to the local group's member. Since the default heartbeat frequency is one heartbeat every 10 seconds, this means it should take no more than 15 seconds to detect that a server instance has left the cluster. Socket death detection or failed connection attempts can also accelerate this detection.
To understand how to expand or shrink running clusters that use unicast messaging, it is important to understand how Managed Servers are organized internally into groups. Each of the Managed Servers in a WebLogic Server cluster has a name. For unicast clusters, WebLogic Server reads these Managed Server names and then sorts them into an ordered list by alphanumeric name. The first 10 Managed Servers in the list (up to 10 Managed Servers) become the first unicast clustering group. The second set of 10 Managed Servers (if applicable) becomes the second group, and so on until all Managed Servers in the cluster are organized into groups of 10 Managed Servers or less. The first Managed Server for each group becomes the group leader for the other (up to) nine Managed Servers in the group.
When adding Managed Servers to an existing, running unicast cluster, Oracle recommends that you add these Managed Servers using Managed Server names that will be sorted into the bottom of the Managed Server list. If you add Managed Server names that will be sorted to the top of the list, this causes renegotiation of cluster group membership within the cluster, creating performance degradation or service interruptions. To avoid this scenario, when adding new Managed Servers to running unicast clusters, specify the new Managed Server names such that they will be sorted to the bottom of the list of Managed Server names. Using a simple naming convention, such as server1
, server2
, … serverN
will typically avoid the issues described above. This restriction regarding Managed Server naming conventions does not apply to dynamic cluster configurations (see Chapter 11, "Creating Dynamic Clusters"), to clusters that are shut down and restarted when Managed Servers are added, or to multicast clusters.
In addition, when adding Managed Servers to running unicast clusters, if you add enough Managed Servers such that another unicast group and group leader will be created (for instance, you add an 11th or 21st Managed Server to the cluster configuration), this will also cause a change to the group and group leader membership, causing intracluster communication problems and potentially creating performance degradation or service interruptions. Oracle recommends that you avoid adding this many Managed Servers to running unicast clusters, including configured unicast clusters and dynamic unicast clusters (see Chapter 11, "Creating Dynamic Clusters"). This restriction does not apply to clusters that are shut down and restarted when Managed Servers are added, or to multicast clusters.
In summary, the unicast cluster messaging protocol:
Uses a group leader model where a server instance sends each message directly to the group leader. The group leader is responsible for retransmitting the message to every other group member and other group leaders, if applicable.
Works out of the box in virtually any environment.
Requires no additional configuration, regardless of the network topology.
Uses a single missed heartbeat to remove a server instance from another server's cluster membership list.
Has limitations regarding how many servers can be dynamically added to running unicast clusters.
Unicast is configured using ClusterMBean.isUnicastBasedClusterMessagingEnabled()
. The default value of this parameter is false. Changes made to this MBean are not dynamic. You must restart your cluster for changes to take effect.
To define a specific channel for unicast communications, you can use the setNetworkChannelForUnicastMessaging(String NetworkChannelName)
. When unicast is enabled, servers will attempt to use the value defined in this MBean for communications between clusters. If the unicast channel is not explicitly defined, the default network channel is used.
When configuring WebLogic Server clusters for unicast communications, if the servers are running on different machines, you must explicitly specify their listen addresses or DNS names.
The following considerations apply when using unicast to handle cluster communications:
All members of a cluster must use the same message type. Mixing between multicast and unicast messaging is not allowed.
You must use multicast if you need to support previous versions of WebLogic Server within your cluster.
Individual cluster members cannot override the cluster messaging type.
The entire cluster must be shutdown and restarted to message modes.
JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:
The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.
JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility.
For more details, see "Using Multicasting with WebLogic JMS" in Developing JMS Applications for Oracle WebLogic Server.
Unicast is the default protocol because it simplifies out of the box cluster configuration and because it is likely to meet the majority of user requirements. However, Oracle fully supports both protocols equally. Both protocols require that the cluster members get sufficient processing time to send and receive cluster messages in a timely fashion. This prevents unnecessary cluster membership changes and the inherent resynchronization costs associated with leaving and rejoining the cluster. It is recommended that you eliminate unnecessary cluster membership changes due to over-utilization of available resources.
When using unicast in particular, make sure that the group leaders are not resource constrained since they act as the message relay to deliver a cluster message to the rest of the cluster. Any slowness on their part can impact multiple cluster members and even result in the group electing a new group leader.
Contrast this with multicast, where a slow member can only really impact its own membership to the cluster. Multicast clusters are generally more efficient in terms of cluster message propagation, and therefore tend to be more resilient to oversubscription of resources. For these reasons, multicast may be a better option for clusters with high throughput requirements, for larger clusters (more than 10 Managed Servers), or for clusters with complex WebLogic Server configuration requirements, provided the network environment supports WebLogic Server cluster UDP requirements.
Each protocol has its own benefits.Table 3-1 highlights some of the differences between multicast and unicast.
Table 3-1 Summary of Differences Between Multicast and Unicast
Multicast | Unicast |
---|---|
Uses UDP multicast |
Uses TCP/IP |
Requires additional configuration to routers, TTL when clustering across multiple subnets |
Requires no additional configuration to account for network topology |
Requires configuring the multicast listen address and listen port. May need to specify the network interface to use on machines with multiple NICs |
Only requires specifying the listen address. Supports using the default channel or a custom network channel for cluster communications |
Each message delivered directly to and received directly from the network |
Each message is delivered to a group leader, which retransmits the message to other group members (N - 1) and any other group leaders (M - 1), if they exist. The other group leaders then retransmit the message to their group members resulting in up to NxM network messages for every cluster message. Message delivery to each cluster member takes between one and three network hops. |
Every server sees every other server |
Group leaders act as a message relay point to retransmit messages to its group members and other group leaders |
Cluster membership changes require three consecutive missed heartbeat messages to remove a member from the cluster list |
Cluster membership changes require only a single missed heartbeat message to remove a member from the cluster |
IP sockets provide a simple, high-performance mechanism for transferring messages and data between two applications. Clustered WebLogic Server instances use IP sockets for:
Accessing non-clustered objects deployed to another clustered server instance on a different machine.
Replicating HTTP session states and stateful session EJB states between a primary and secondary server instance.
Accessing clustered objects that reside on a remote server instance. (This generally occurs only in a multi-tier cluster architecture, such as the one described in Recommended Multi-Tier Architecture.)
Note: The use of IP sockets in WebLogic Server extends beyond the cluster scenario—all RMI communication takes place using sockets, for example, when a remote Java client application accesses a remote object. |
Proper socket configuration is crucial to the performance of a WebLogic Server cluster. Two factors determine the efficiency of socket communications in WebLogic Server:
Whether the server instance host system uses a native or a pure-Java socket reader implementation.
For systems that use pure-Java socket readers, whether the server instance is configured to use enough socket reader threads.
Although the pure-Java implementation of socket reader threads is a reliable and portable method of peer-to-peer communication, it does not provide the optimal performance for heavy-duty socket usage in a WebLogic Server cluster. With pure-Java socket readers, threads must actively poll all opened sockets to determine if they contain data to read. In other words, socket reader threads are always "busy" polling sockets, even if the sockets have no data to read. This unnecessary overhead can reduce performance.
The performance issue is magnified when a server instance has more open sockets than it has socket reader threads—each reader thread must poll more than one open socket. When the socket reader encounters an inactive socket, it waits for a timeout before servicing another. During this timeout period, an active socket may go unread while the socket reader polls inactive sockets, as shown in Figure 3-1.
For optimal 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. Native socket readers use far more efficient techniques to determine if there is data to read on a socket. With a native socket reader implementation, reader threads do not need to poll inactive sockets—they service only active sockets, and they are immediately notified (via an interrupt) when a given socket becomes active.
Note: Applets cannot use native socket reader implementations, and therefore have limited efficiency in socket communication. |
For instructions on how to configure the WebLogic Server host machine to use the native socket reader implementation for your operating system, see Configure Native IP Sockets Readers on Machines that Host Server Instances.
If you do use t>he pure-Java socket reader implementation, you can still improve the performance of socket communication by configuring the proper number of socket reader threads for each server instance. For optimal performance, the number of socket reader threads in WebLogic Server should equal the potential maximum number of opened sockets. This configuration avoids the situation in which a reader thread must service multiple sockets, and ensures that socket data is read immediately.
To determine the proper number of reader threads for server instances in your cluster, see the following section, Determining Potential Socket Usage.
For instructions on how to configure socket reader threads, see Set the Number of Reader Threads on Machines that Host Server Instances.
Each WebLogic Server instance can potentially open a socket for every other server instance in the cluster. However, the actual maximum number of sockets used at a given time depends on the configuration of your cluster. In practice, clustered systems generally do not open a socket for every other server instance, because objects are deployed homogeneously—to each server instance in the cluster.
If your cluster uses in-memory HTTP session state replication, and you deploy objects homogeneously, each server instance potentially opens a maximum of only two sockets, as shown in Figure 3-2.
The two sockets in this example are used to replicate HTTP session states between primary and secondary server instances. Sockets are not required for accessing clustered objects, due to the collocation optimizations that WebLogic Server uses to access those objects. (These optimizations are described in Optimization for Collocated Objects.) In this configuration, the default socket reader thread configuration is sufficient.
Deployment of "pinned" services—services that are active on only one server instance at a time—can increase socket usage, because server instances may need to open additional sockets to access the pinned object. (This potential can only be released if a remote server instance actually accesses the pinned object.) Figure 3-3 shows the potential effect of deploying a non-clustered RMI object to Server A.
In this example, each server instance can potentially open a maximum of three sockets at a given time, to accommodate HTTP session state replication and to access the pinned RMI object on Server A.
Note: Additional sockets may also be required for servlet clusters in a multi-tier cluster architecture, as described in Configuration Notes for Multi-Tier Architecture. |
Clients of a cluster use the Java implementation of socket reader threads.
WebLogic Server allows you to configure server affinity load balancing algorithms that reduce the number of IP sockets opened by a Java client application. A client accessing multiple objects on a server instance will use a single socket. If an object fails, the client will failover to a server instance to which it already has an open socket, if possible. In older version of WebLogic Server, under some circumstances, a client might open a socket to each server instance in a cluster.
For optimal performance, configure enough socket reader threads in the Java Virtual Machine (JVM) that runs the client. For instructions, see Set the Number of Reader Threads on Client Machines.
Clients of a non-clustered WebLogic Server server instance access objects and services by using a JNDI-compliant naming service. The JNDI naming service contains a list of the public services that the server instance offers, organized in a tree structure. A WebLogic Server instance offers a new service by binding into the JNDI tree a name that represents the service. Clients obtain the service by connecting to the server instance and looking up the bound name of the service.
Server instances in a cluster utilize a cluster-wide JNDI tree. A cluster-wide JNDI tree is similar to a single server instance JNDI tree, insofar as the tree contains a list of available services. In addition to storing the names of local services, however, the cluster-wide JNDI tree stores the services offered by clustered objects (EJBs and RMI classes) from other server instances in the cluster.
Each WebLogic Server instance in a cluster creates and maintains a local copy of the logical cluster-wide JNDI tree. The follow sections describe how the cluster-wide JNDI tree is maintained, and how to avoid naming conflicts that can occur in a clustered environment.
Caution: Do not use the cluster-wide JNDI tree as a persistence or caching mechanism for application data. Although WebLogic Server replicates a clustered server instance's JNDI entries to other server instances in the cluster, those entries are removed from the cluster if the original instance fails. Also, storing large objects within the JNDI tree can overload multicast or unicast traffic and interfere with the normal operation of a cluster. |
Each WebLogic Server in a cluster builds and maintains its own local copy of the cluster-wide JNDI tree, which lists the services offered by all members of the cluster. Creation of a cluster-wide JNDI tree begins with the local JNDI tree bindings of each server instance. As a server instance boots (or as new services are dynamically deployed to a running server instance), the server instance first binds the implementations of those services to the local JNDI tree. The implementation is bound into the JNDI tree only if no other service of the same name exists.
Note: When you start a Managed Server in a cluster, the server instance identifies other running server instances in the cluster by listening for heartbeats, after a warm-up period specified by theMemberWarmupTimeoutSeconds parameter in ClusterMBean . The default warm-up period is 30 seconds. |
Once the server instance successfully binds a service into the local JNDI tree, additional steps are performed for clustered objects that use replica-aware stubs. After binding the clustered object's implementation into the local JNDI tree, the server instance sends the object's stub to other members of the cluster. Other members of the cluster monitor the multicast or unicast address to detect when remote server instances offer new services.
Figure 3-4 shows a snapshot of the JNDI binding process.
In the previous figure, Server A has successfully bound an implementation of clustered Object X into its local JNDI tree. Because Object X is clustered, it offers this service to all other members of the cluster. Server C is still in the process of binding an implementation of Object X.
Other server instances in the cluster listening to the multicast or unicast address note that Server A offers a new service for clustered object, X. These server instances update their local JNDI trees to include the new service.
Updating the local JNDI bindings occurs in one of two ways:
If the clustered service is not yet bound in the local JNDI tree, the server instance binds a new replica-aware stub into the local tree that indicates the availability of Object X on Server A. Servers B and D would update their local JNDI trees in this manner, because the clustered object is not yet deployed on those server instances.
If the server instance already has a binding for the cluster-aware service, it updates its local JNDI tree to indicate that a replica of the service is also available on Server A. Server C would update its JNDI tree in this manner, because it will already have a binding for the clustered Object X.
In this manner, each server instance in the cluster creates its own copy of a cluster-wide JNDI tree. The same process would be used when Server C announces that Object X has been bound into its local JNDI tree. After all broadcast messages are received, each server instance in the cluster would have identical local JNDI trees that indicate the availability of the object on Servers A and C, as shown in Figure 3-5.
Note: In an actual cluster, Object X would be deployed homogeneously, and an implementation which can invoke the object would be available on all four server instances. |
Simple JNDI naming conflicts occur when a server instance attempts to bind a non-clustered service that uses the same name as a non-clustered service already bound in the JNDI tree. Cluster-level JNDI conflicts occur when a server instance attempts to bind a clustered object that uses the name of a non-clustered object already bound in the JNDI tree.
WebLogic Server detects simple naming conflicts (of non-clustered services) when those services are bound to the local JNDI tree. Cluster-level JNDI conflicts may occur when new services are advertised over multicast or unicast. For example, if you deploy a pinned RMI object on one server instance in the cluster, you cannot deploy a replica-aware version of the same object on another server instance.
If two server instances in a cluster attempt to bind different clustered objects using the same name, both will succeed in binding the object locally. However, each server instance will refuse to bind the other server instance's replica-aware stub in to the JNDI tree, due to the JNDI naming conflict. A conflict of this type would remain until one of the two server instances was shut down, or until one of the server instances undeployed the clustered object. This same conflict could also occur if both server instances attempt to deploy a pinned object with the same name.
To avoid cluster-level JNDI conflicts, you must homogeneously deploy all replica-aware objects to all WebLogic Server instances in a cluster. Having unbalanced deployments across WebLogic Server instances increases the chance of JNDI naming conflicts during startup or redeployment. It can also lead to unbalanced processing loads in the cluster.
If you must pin specific RMI objects or EJBs to individual server instances, do not replicate the object's bindings across the cluster.
When a clustered object is removed (undeployed from a server instance), updates to the JNDI tree are handled similarly to the updates performed when new services are added. The server instance on which the service was undeployed broadcasts a message indicating that it no longer provides the service. Again, other server instances in the cluster that observe the multicast or unicast message update their local copies of the JNDI tree to indicate that the service is no longer available on the server instance that undeployed the object.
Once the client has obtained a replica-aware stub, the server instances in the cluster may continue adding and removing host servers for the clustered objects. As the information in the JNDI tree changes, the client's stub may also be updated. Subsequent RMI requests contain update information as necessary to ensure that the client stub remains up-to-date.
Clients that connect to a WebLogic Server cluster and look up a clustered object obtain a replica-aware stub for the object. This stub contains the list of available server instances that host implementations of the object. The stub also contains the load balancing logic for distributing the load among its host servers.
For more information about replica-aware stubs for EJBs and RMI classes, see Replication and Failover for EJBs and RMIs.
For a more detailed discussion of how WebLogic JNDI is implemented in a clustered environment and how to make your own objects available to JNDI clients, see "Using WebLogic JNDI in a Clustered Environment" in Developing JNDI Applications for Oracle WebLogic Server
WebLogic Server provides failover within MAN and WAN networks. This feature provides more reliability by allowing failover to occur across a larger geographic area. It also provides failover across multiple WebLogic Server domains.
To provide failover within a MAN/WAN environment, you must use hardware load balancers. This document outlines the procedures for configuring Radware hardware load balancers to work with WebLogic Server.
For information on configuring WebLogic Server to use MAN/WAN, see Session State Replication Across Clusters in a MAN/WAN. For information on configuring Radware hardware load balancers, see http://www.radware.com
.
The following sections describe how to configure Radware hardware load balancers:
Before performing the procedures described in this appendix, ensure that you have performed the following:
Installed and configured your WebLogic Server environment. This includes creating and configuring clusters and Managed Servers.
Installed and configured at least two Radware Web Server Director load balancers. This is the minimum hardware requirement for using Radware devices within a MAN/WAN environment. At least one of these must be configured as a global load balancer
Ensured that your network and DNS are configured correctly
Once these requirements are met, use the following procedures to configure your load balancers to work within a MAN/WAN environment.
The first step in configuring Web Server Director is to create an Authoritative Delegation Zone within the local DNS. To do this, perform the following using the Radware administration utility:
Click on the name of your local DNS.
Click New Delegation.
Enter a name for the new delegation zone
Add the IP address for each Radware device
Web Server Director balances load among servers within a server farm. Clients access a server using a virtual IP address. Web Server Director directs traffic from this virtual IP address to the appropriate server. The following sections describe how to create and configure server farm virtual IPs.
To create a farm IP, perform the following using the Radware administration utility:
Select WSD.
Select Farms.
Select Farm Table.
Click Create a Farm.
Enter an IP address and DNS alias for the farm.
Ensure that Admin Status is enabled.
Click Set.
To configure the dispatch method for the server farm, perform the following procedures using the Radware configuration utility:
Select WSD.
Select Farms.
Select Farm Table.
Select the farm you want to configure
In the Farm Properties window, select the menu next to Dispatch Method.
Select the desired algorithm
Click Set.
Use the following procedures to configure port multiplexing:
Select WSD.
Select Farms.
Select Farm Table.
Select the farm you want to configure.
In the Properties window, enter a value in the Multiplexed Port field.
Select WSD.
Select Servers.
Select Application Servers.
For each local server, select the server from the table and enter the application port in the Multiplexed Server Port field.
Click Set.
You must configure HTTP redirects in order to configure global load balancers to work within a MAN/WAN environment. HTTP redirects ensure proper distribution of traffic across Web Server Director devices.
To configure HTTP redirect, perform the following procedures using the Radware administration utility:
Select WSD.
Select Farms.
Select Farm Table.
Select the farm that you want to configure.
Select HTTP Redirection in the Redirection Mode section.
Select HTTP Redirection in the DNS Redirection Fallback section.
Click Set.
Select WSD.
Select Servers.
Select Application Servers.
Select the server in the farm that represents the distributed farm on the remote WSD
Server persistence is based on HTTP session IDs. Web Server Director inspects incoming traffic to a farm, then selects the appropriate server based on session information in the HTTP header. To configure session ID persistency, perform the following procedures using the Radware administration utility:
Select WSD.
Select L7 Load Balancing.
Select Session Persistency.
Click Create.
Select the farm you want to configure.
Set the application port of your farm.
Set Persistency Identification to JESESSIONID
.
Set Value Offset to 53
.
Set Stop Chars to :!
.
Set Inactivity Timeout
to the value of your session time-out.
Configuring the LRP component ensures that traffic is correctly distributed to remote locations. To configure LRP, perform the following:
Select WSD.
Select Distributed Systems.
Select Report Configuration.
Click Create Distributed Farm Address.
Set Distributed Farm Address to the remote farm IP address.
Set Remote WSD Address to the IP address of the second Radware device.
Click Set.
After you have configured your Radware devices, you must configure WebLogic Server to use MAN/WAN failover. For information on configuring WebLogic Server to use MAN/WAN, see Session State Replication Across Clusters in a MAN/WAN.
This chapter provides a brief introduction to WebLogic Server clusters.
This chapter includes the following sections:
A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
A dynamic cluster is any cluster that contains one or more dynamic servers. Dynamic clusters are based on a single shared server template. You use the server template to specify the configuration of the servers in your dynamic cluster so that each server does not need to be manually configured when expanding the cluster. Dynamic clusters allow you to easily scale up the number of server instances in your domain. When configuring your dynamic cluster, you can specify the number of server instances you anticipate needing at peak load. WebLogic Server will create the specified number of server instances and apply the calculated attribute values to each one. When you need additional server capacity, you can then start a server instance without having to first manually configure it and add it to the cluster. For more information see Chapter 11, "Creating Dynamic Clusters" and "Create dynamic clusters" in the Oracle WebLogic Server Administration Console Online Help.
A cluster is part of a particular WebLogic Server domain.
A domain is an interrelated set of WebLogic Server resources that are managed as a unit. A domain includes one or more WebLogic Server instances, which can be clustered, non-clustered, or a combination of clustered and non-clustered instances. A domain can include multiple clusters. A domain also contains the application components deployed in the domain, and the resources and services required by those application components and the server instances in the domain. Examples of the resources and services used by applications and server instances include machine definitions, optional network channels, connectors, and startup classes.
You can use a variety of criteria for organizing WebLogic Server instances into domains. For instance, you might choose to allocate resources to multiple domains based on logical divisions of the hosted application, geographical considerations, or the number or complexity of the resources under management. For additional information about domains see Understanding Domain Configuration for Oracle WebLogic Server.
In each domain, one WebLogic Server instance acts as the Administration Server—the server instance which configures, manages, and monitors all other server instances and resources in the domain. Each Administration Server manages one domain only. If a domain contains multiple clusters, each cluster in the domain has the same Administration Server.
All server instances in a cluster must reside in the same domain; you cannot "split" a cluster over multiple domains. Similarly, you cannot share a configured resource or subsystem between domains.
Clustered WebLogic Server instances behave similarly to non-clustered instances, except that they provide failover and load balancing. The process and tools used to configure clustered WebLogic Server instances are the same as those used to configure non-clustered instances. However, to achieve the load balancing and failover benefits that clustering enables, you must adhere to certain guidelines for cluster configuration.
To understand how the failover and load balancing mechanisms used in WebLogic Server relate to particular configuration options see Load Balancing in a Cluster, and Failover and Replication in a Cluster.
Detailed configuration recommendations are included throughout the instructions in Setting up WebLogic Clusters.
A WebLogic Server cluster provides these benefits:
Scalability
The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service—the application continues to run without impact to clients and end users.
High-Availability
In a WebLogic Server cluster, application processing can continue when a server instance fails. You "cluster" application components by deploying them on multiple server instances in the cluster—so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.
The choice to cluster WebLogic Server instances is transparent to application developers and clients. However, understanding the technical infrastructure that enables clustering will help programmers and administrators maximize the scalability and availability of their applications.
This section defines, in non-technical terms, the key clustering capabilities that enable scalability and high availability.
Application Failover
Simply put, failover means that when an application component (typically referred to as an "object" in the following sections) doing a particular "job"—some set of processing tasks—becomes unavailable for any reason, a copy of the failed object finishes the job.
For the new object to be able to take over for the failed object:
There must be a copy of the failed object available to take over the job.
There must be information, available to other objects and the program that manages failover, defining the location and operational status of all objects—so that it can be determined that the first object failed before finishing its job.
There must be information, available to other objects and the program that manages failover, about the progress of jobs in process—so that an object taking over an interrupted job knows how much of the job was completed before the first object failed, for example, what data has been changed, and what steps in the process were completed.
WebLogic Server uses standards-based communication techniques and facilities— including IP sockets and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of objects in a cluster. These techniques allow WebLogic Server to determine that an object stopped before finishing its job, and where there is a copy of the object to complete the job that was interrupted.
Note: For backward compatibility with previous versions, WebLogic Server allows you to use multicast for communications between clusters. |
Information about what has been done on a job is called state. WebLogic Server maintains information about state using techniques called session replication and replica-aware stubs. When a particular object unexpectedly stops doing its job, replication techniques enable a copy of the object pick up where the failed object stopped, and finish the job.
WebLogic Server supports automatic and manual migration of a clustered server instance from one machine to another. A Managed Server that can be migrated is referred to as a migratable server. This feature is designed for environments with requirements for high availability. The server migration capability is useful for:
Ensuring uninterrupted availability of singleton services—services that must run on only a single server instance at any given time, such as JMS and the JTA transaction recovery system, when the hosting server instance fails. A Managed Server configured for automatic migration will be automatically migrated to another machine in the event of failure.
Easing the process of relocating a Managed Server, and all the services it hosts, as part of a planned system administration process. An administrator can initiate the migration of a Managed Server from the Administration Console or command line.
The server migration process relocates a Managed Server in its entirety—including IP addresses and hosted applications—to one of a predefined set of available host machines.
Load Balancing
Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment. For load balancing to occur:
There must be multiple copies of an object that can do a particular job.
Information about the location and operational status of all objects must be available.
WebLogic Server allows objects to be clustered—deployed on multiple server instances—so that there are alternative objects to do the same job. WebLogic Server shares and maintains the availability and location of deployed objects using unicast, IP sockets, and JNDI.
Note: For backward compatibility with previous versions, WebLogic Server also allows you to use multicast for communications between clusters. |
A detailed discussion of how communications and replication techniques are employed by WebLogic Server is provided in Communications In a Cluster.
A clustered application or application component is one that is available on multiple WebLogic Server instances in a cluster. If an object is clustered, failover and load balancing for that object is available. Deploy objects homogeneously—to every server instance in your cluster—to simplify cluster administration, maintenance, and troubleshooting.
Web applications can consist of different types of objects, including Enterprise Java Beans (EJBs), servlets, and Java Server Pages (JSPs). Each object type has a unique set of behaviors related to control, invocation, and how it functions within an application. For this reason, the methods that WebLogic Server uses to support clustering—and hence to provide load balancing and failover—can vary for different types of objects. The following types of objects can be clustered in a WebLogic Server deployment:
Servlets
JSPs
EJBs
Remote Method Invocation (RMI) objects
Java Messaging Service (JMS) destinations
Different object types can have certain behaviors in common. When this is the case, the clustering support and implementation considerations for those similar object types may be same. In the sections that follow, explanations and instructions for the following types of objects are generally combined:
Servlets and JSPs
EJBs and RMI objects
The sections that follow briefly describe the clustering, failover, and load balancing support that WebLogic Server provides for different types of objects.
WebLogic Server provides clustering support for servlets and JSPs by replicating the HTTP session state of clients that access clustered servlets and JSPs. WebLogic Server can maintain HTTP session states in memory, a file system, or a database.
To enable automatic failover of servlets and JSPs, session state must persist in memory. For information about how failover works for servlets and JSPs, and for related requirements and programming considerations, see HTTP Session State Replication.
You can balance the servlet and JSP load across a cluster using a WebLogic Server proxy plug-in or external load balancing hardware. WebLogic Server proxy plug-ins perform round-robin load balancing. External load balancers typically support a variety of session load balancing mechanisms. For more information, see Load Balancing for Servlets and JSPs.
Load balancing and failover for EJBs and RMI objects is handled using replica-aware stubs, which can locate instances of the object throughout the cluster. Replica-aware stubs are created for EJBs and RMI objects as a result of the object compilation process. EJBs and RMI objects are deployed homogeneously—to all the server instances in the cluster.
Failover for EJBs and RMI objects is accomplished using the object's replica-aware stub. When a client makes a call through a replica-aware stub to a service that fails, the stub detects the failure and retries the call on another replica. To understand failover support for different types of objects, see Replication and Failover for EJBs and RMIs.
WebLogic Server clusters support multiple algorithms for load balancing clustered EJBs and RMI objects: round-robin, weight-based, random, round-robin-affinity, weight-based-affinity, and random-affinity. By default, a WebLogic Server cluster will use the round-robin method. You can configure a cluster to use one of the other methods using the Administration Console. The method you select is maintained within the replica-aware stub obtained for clustered objects. For details, see Load Balancing for EJBs and RMI Objects.
The WebLogic Java Messaging Service (JMS) architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to destinations from any WebLogic Server server instance in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, the same JMS topic or queue is still managed separately by each WebLogic Server instance in the cluster.
Load balancing is supported for JMS. To enable load balancing, you must configure targets for JMS servers. For more information about load balancing and JMS components, see Load Balancing for JMS, For instructions on setting up clustered JMS, see Configure Migratable Targets for Pinned Services, and Deploying, Activating, and Migrating Migratable Services.
The following APIs and internal services cannot be clustered in WebLogic Server:
File services including file shares
Time services
You can still use these services on individual WebLogic Server instances in a cluster. However, the services do not make use of load balancing or failover features.
Administering Clusters for Oracle WebLogic Server
12c (12.1.2)
E28074-07
February 2015
This document describes clusters and provides information for planning, implementing, and supporting a production environment that includes WebLogic Server clusters.
Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server, 12c (12.1.2)
E28074-07
Copyright © 2007, 2015, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
This chapter provides suggestions for troubleshooting IP multicast configuration problems. Using IP multicasting, WebLogic Server instances in a cluster can share a single IP address and port number. This capability enables all members of a cluster to be treated as a single entity and enables members of the cluster to communicate among themselves.
This chapter includes the following sections:
For general information on using and configuring multicast within a cluster, see Cluster Configuration and config.xml.
For information on configuring a multicast address from the Console, see "Clusters: Configuration: Multicast" in the Oracle WebLogic Server Administration Console Online Help.
For general cluster troubleshooting suggestions, see Chapter 14, "Troubleshooting Common Problems."
The first step in troubleshooting multicast problems is to verify that you have configured the multicast address and port correctly. A multicast address must be correctly configured for each cluster.
Multicast address and port configuration problems are among the most common reasons why a cluster does not start or a server fails to join a cluster. The following considerations apply to multicast addresses:
The multicast address must be an IP address between 224.0.0.0 and 239.255.255.255 or a host name with an IP address in this range.
The default multicast address used by WebLogic Server is 239.192.0.0.
Do not use any x.0.0.1 multicast address where x
is between 0 and 9, inclusive.
After you verify that the multicast address and port are configured correctly, determine whether network problems are interfering with multicast communication.
Ensure that no physical problems exist in your network.
Verify the network connection for each machine that hosts servers within the cluster.
Verify that all components of the network, including routers and DNS servers, are connected and functioning correctly.
Address conflicts within a network can disrupt multicast communications.
Use the netstat
utility to verify that no other network resources are using the cluster multicast address.
Verify that each machine has a unique IP address.
On UNIX systems, you may encounter the UnkownHostExceptions
error. This error can occur at random times even when the server is not under a heavy load. Check /etc/nsswitch.conf
and change the order to 'files,DNS,NIS'
to avoid this error.
For more information, see the nsswitch.conf
man page for your system.
After you verify that the multicast address and port are configured correctly and there are no physical or configuration problems with your network, you can use utils.MulticastTest
to verify that multicast is working and to determine if unwanted traffic is occurring between different clusters.
For instructions on using the MulticastTest utility, see MulticastTest
in "Using the Oracle WebLogic Server Java Utilities" in Command Reference for Oracle WebLogic Server.
If MulticastTest fails and the machine is multihomed, ensure that the primary address is being used. See Multicast and Multihomed Machines.
Note: You should set-Djava.net.preferIPv4Stack=true when specifying an IPv4 format address for the multicast address on Linux machines running dual IPv4/IPv6 stacks. |
The following sections describe how to tune various features of WebLogic Server to work with multicasting.
Multicast timeouts can occur during a Network Interface Card (NIC) failover. Timeouts can result in an error message like the following:
<Error><Cluster><Multicast socket receive error: java.io.InterruptedIOException: Receive timed out>
When this error occurs, you can:
Disable the NIC failover.
Disable the igmp snooping
switch. This switch is part of the Internet Group Management Protocol (IGMP) and is used to prevent multicast flood problems on the managed switch.
On Windows 2000, check the IGMP level to ensure that multicast packets are supported.
Set the Multicast Time-To-Live to the following:
MulticastTTL=32
For more information, see Configure Multicast Time-To-Live (TTL).
Each WebLogic Server instance in a cluster uses multicast to broadcast regular heartbeat messages that advertise its availability. By monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed.
The following sections describe possible solutions when cluster heartbeat problems occur.
Multicast Send Delay specifies the amount of time the server waits to send message fragments through multicast. This delay helps to avoid OS-level buffer overflow. This can be set via the MulticastSendDelay attribute of the Cluster MBean. For more information, see the MBean Reference for Oracle WebLogic Server.
If problems still occur after setting the Multicast Send Delay, you may need to set the following operating system parameters related to UDP settings:
xdp_xmit_hiwat
udp_recv_hiwat
If these parameters are set to a lower value (8K for example) there may be a problem if the multicast packet size is set to the maximum allowed (32K). Try setting these parameters to 64K.
A multicast storm is the repeated transmission of multicast packets on a network. Multicast storms can stress the network and attached stations, potentially causing end-stations to hang or fail.
Increasing the size of the multicast buffers can improve the rate at which announcements are transmitted and received, and prevent multicast storms. See Configure Multicast Buffer Size.
The following considerations apply when using multicast in a multihomed environment:
Ensure that you have configured a UnixMachine
instance from the WebLogic Server Administration Console and have specified an InterfaceAddress
for each server instance to handle multicast traffic.
Run /usr/sbin/ifconfig -a
to check the MAC address of each machine in the multihomed environment. Ensure that each machine has a unique MAC address. If machines use the same MAC address, this can cause multicast problems.
If multicast problems occur when cluster members are in different subnets you should configure Multicast-Time-To-Live. 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, see Configure Multicast Time-To-Live (TTL).
If you are still having problems with the multicast address after performing the troubleshooting tips above, gather debugging information for multicast.
The following utilities can help you debug multicast configuration problems.
The following debug flags are specific to multicast:
DebugCluster
DebugClusterHeartBeats
DebugClusterFragments
The following sections describe miscellaneous multicast issues you may encounter.
AIX version 5.1 does not support IPv4 mapped multicast addresses. If you are using an IPv4 multicast address, you cannot join a multicast group even if you are switching to IPv6. When running MulticastTest on AIX, use the order on the command line specified in the following example:
java -Djava.net.preferIPv4Stack=true utils.Multicast <options>
Additionally, verify the following settings on AIX to properly configure cluster operations:
Set the MTU size to 1500 by executing the following command and rebooting the machine:
chdev -1 lo0 -a mtu=1500 -P
Ensure that the following has been added to /etc/netsvc.conf:
hosts=local,bind4
This line is required to ensure that only IPv4 addresses are sent to name services for IP resolution.
The following resources may be helpful in resolving multicast problems:
Oracle Fusion Middleware Release Notes for Microsoft Windows
Oracle Support: https://support.oracle.com/
Oracle Forums: http://forums.oracle.com/
This preface describes the document accessibility features and conventions used in this guide—Administering Clusters for Oracle WebLogic Server.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc
.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info
or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
if you are hearing impaired.
The following text conventions are used in this document:
Convention | Meaning |
---|---|
boldface | Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. |
italic | Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. |
monospace | Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. |
The following sections describe the WebLogic Cluster API.
The WebLogic Cluster public API is contained in a single interface, weblogic.rmi.cluster.CallRouter
.
Class java.lang.Object Interface weblogic.rmi.cluster.CallRouter (extends java.io.Serializable)
A class implementing this interface must be provided to the RMI compiler (rmic
) to enable parameter-based routing. Run rmic
on the service implementation using these options (to be entered on one line):
$ java weblogic.rmic -clusterable -callRouter <callRouterClass> <remoteObjectClass>
The call router is called by the clusterable stub each time a remote method is invoked. The router is responsible for returning the name of the server to which the call should be routed.
Each server in the cluster is uniquely identified by its name as defined with the WebLogic Server Console. These are the names that the method router must use for identifying servers.
Example: Consider the ExampleImpl
class which implements a remote interface Example, with one method foo
:
public class ExampleImpl implements Example { public void foo(String arg) { return arg; } }
This CallRouter
implementation ExampleRouter
ensures that all foo
calls with 'arg' < "n" go to server1 (or server3 if server1 is unreachable) and that all calls with 'arg' >= "n" go to server2 (or server3 if server2 is unreachable).
public class ExampleRouter implements CallRouter { private static final String[] aToM = { "server1", "server3" }; private static final String[] nToZ = { "server2", "server3" }; public String[] getServerList(Method m, Object[] params) { if (m.GetName().equals("foo")) { if (((String)params[0]).charAt(0) < 'n') { return aToM; } else { return nToZ; } } else { return null; } } }
This rmic
call associates the ExampleRouter
with ExampleImpl
to enable parameter-based routing:
$ rmic -clusterable -callRouter ExampleRouter ExampleImpl
If a replica is available on the same server instance as the object calling it, the call will not be load balanced, because it is more efficient to use the local replica. For more information, see Optimization for Collocated Objects..