WebLogic Server Cluster
STUB:
Clients that connect to a WLS instances and look like a single clustered object obtain a replica-aware-stub of the object. The stub contains the list of all the available server instances of the object. It also has a load balancing logic to distribute the load across the multiple hosts
Understanding WebLogic Server Clustering
This section is a brief introduction to WebLogic Server clusters. It contains the following information:
§ What Is a WebLogic Server Cluster?
§ What Are the Benefits of Clustering?
§ What Are the Key Capabilities of a Cluster?
§ What Types of Objects Can Be Clustered?
§ What Types of Objects Cannot Be Clustered?
What Is a WebLogic Server Cluster?
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.
What Are the Benefits of Clustering?
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.
What Are the Key Capabilities of a Cluster?
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 also 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 on 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.
Cluster Master’s Role in Whole Server Migration
In a cluster that contains migratable servers, one server instance acts as the cluster master. Its role is to orchestrate the server migration process. Any server instance in the cluster can serve as the cluster master. When you start a cluster that contains migratable servers, the first server to join the cluster becomes the cluster master and starts up the cluster manager service. If a cluster does not include at least one migratable server, it does not require a cluster master, and the cluster master service does not start up. In the absence of a cluster master, migratable servers can continue to operate, but server migration is not possible. These are the key functions of the cluster master:
Issues periodic heartbeats to the other servers in the cluster.
Periodically reads the lease table to verify that each migratable server has a current lease. An expired lease indicates to the cluster master that the migratable server should be restarted.
Upon determining that a migratable server’s lease is expired, waits for period specified by the FencingGracePeriodMillis on theClusterMBean, and then tries to invoke the Node Manager process on the machine that hosts the migratable server whose lease is expired, to restart the migratable server.
If unable to restart a migratable server whose lease has expired on its current machine, the cluster master selects a target machine in this fashion:
If you have configured a list of preferred destination machines for the migratable server, the cluster master chooses a machine on that list, in the order the machines are listed.
Otherwise, the cluster master chooses a machine on the list of those configured as available for hosting migratable servers in the cluster.
What Types of Objects Can Be Clustered?
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
§ Java Database Connectivity (JDBC) connections
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.
Servlets and JSPs
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 filesystem, 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.
EJBs and RMI Objects
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.
JDBC Connections
WebLogic Server allows you to cluster JDBC objects, including data sources and multi data sources, to improve the availability of cluster-hosted applications. Each JDBC object you configure for your cluster must exist on each managed server in the cluster—when you configure the JDBC objects, target them to the cluster.
§ Data Sources—In a cluster, external clients must obtain connections through a JDBC data source on the JNDI tree. The data source uses the WebLogic Server RMI driver to acquire a connection. The cluster-aware nature of WebLogic data sources in external client applications allows a client to request another connection if the server instance hosting the previous connection fails. Although not strictly required, Oracle recommends that server-side clients also obtain connections via a data source on the JNDI tree.
§ Multi data sources—Multi data sources are an abstraction around a group of data sources that provides load balancing or failover processing between the data sources associated with the multi data source. Multi data sources are bound to the JNDI tree or local application context just like data sources are bound to the JNDI tree. Applications lookup a multi data source on the JNDI tree just like they do for data sources, and then request a database connection. The multi data source determines which data source to use to satisfy the request depending on the algorithm selected in the multi data source configuration: load balancing or failover.
For more information about JDBC, see “Configuring WebLogic JDBC Resources” in the Configuring and Managing WebLogic JDBC.
Getting Connections with Clustered JDBC
To ensure that any JDBC request can be handled equivalently by any cluster member, each managed server in the cluster must have similarly named/defined data sources, if applicable, multi data sources. To achieve this result, data sources and multi data sources should be targeted to the cluster so they are cluster-aware and, if intended for use in external clients, their connections can be to any cluster members.
§ External Clients Connections—External clients that require a database connection perform a JNDI lookup and obtain a replica-aware stub for the data source. The stub for the data source contains a list of the server instances that host the data source—which should be all of the Managed Servers in the cluster. Replica-aware stubs contain load balancing logic for distributing the load among host server instances.
§ Server-Side Client Connections—For server-side use, connection requests will be handled by the local instance of the data source or multi data source. A server-side data source will not go to another cluster member for its JDBC connections. The connection is pinned to the local server instance for the duration of the database transaction, and as long as the application code retains it (until the connection is closed).
Failover and Load Balancing for JDBC Connections
Clustering your JDBC objects does not enable failover of connections, but it can ease the process of reconnecting when a connection fails. In replicated database environments, multi data sources may be clustered to support database failover, and optionally, load balancing of connections. See the following topics for more information:
§ To understand the behavior of clustered JDBC objects when failures occur, see Failover and JDBC Connections.
§ To learn more about how clustered multi data sources enable load balancing of connections, see Load Balancing for JDBC Connections.
§ For instructions on configuring clustered JDBC objects, see Configure Clustered JDBC.
JMS and Clustering
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.
What Types of Objects Cannot Be Clustered?
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.
Clients that connect to a WLS instances and look like a single clustered object obtain a replica-aware-stub of the object. The stub contains the list of all the available server instances of the object. It also has a load balancing logic to distribute the load across the multiple hosts
Understanding WebLogic Server Clustering
This section is a brief introduction to WebLogic Server clusters. It contains the following information:
§ What Is a WebLogic Server Cluster?
§ What Are the Benefits of Clustering?
§ What Are the Key Capabilities of a Cluster?
§ What Types of Objects Can Be Clustered?
§ What Types of Objects Cannot Be Clustered?
What Is a WebLogic Server Cluster?
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.
What Are the Benefits of Clustering?
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.
What Are the Key Capabilities of a Cluster?
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 also 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 on 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.
Cluster Master’s Role in Whole Server Migration
In a cluster that contains migratable servers, one server instance acts as the cluster master. Its role is to orchestrate the server migration process. Any server instance in the cluster can serve as the cluster master. When you start a cluster that contains migratable servers, the first server to join the cluster becomes the cluster master and starts up the cluster manager service. If a cluster does not include at least one migratable server, it does not require a cluster master, and the cluster master service does not start up. In the absence of a cluster master, migratable servers can continue to operate, but server migration is not possible. These are the key functions of the cluster master:
Issues periodic heartbeats to the other servers in the cluster.
Periodically reads the lease table to verify that each migratable server has a current lease. An expired lease indicates to the cluster master that the migratable server should be restarted.
Upon determining that a migratable server’s lease is expired, waits for period specified by the FencingGracePeriodMillis on theClusterMBean, and then tries to invoke the Node Manager process on the machine that hosts the migratable server whose lease is expired, to restart the migratable server.
If unable to restart a migratable server whose lease has expired on its current machine, the cluster master selects a target machine in this fashion:
If you have configured a list of preferred destination machines for the migratable server, the cluster master chooses a machine on that list, in the order the machines are listed.
Otherwise, the cluster master chooses a machine on the list of those configured as available for hosting migratable servers in the cluster.
What Types of Objects Can Be Clustered?
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
§ Java Database Connectivity (JDBC) connections
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.
Servlets and JSPs
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 filesystem, 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.
EJBs and RMI Objects
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.
JDBC Connections
WebLogic Server allows you to cluster JDBC objects, including data sources and multi data sources, to improve the availability of cluster-hosted applications. Each JDBC object you configure for your cluster must exist on each managed server in the cluster—when you configure the JDBC objects, target them to the cluster.
§ Data Sources—In a cluster, external clients must obtain connections through a JDBC data source on the JNDI tree. The data source uses the WebLogic Server RMI driver to acquire a connection. The cluster-aware nature of WebLogic data sources in external client applications allows a client to request another connection if the server instance hosting the previous connection fails. Although not strictly required, Oracle recommends that server-side clients also obtain connections via a data source on the JNDI tree.
§ Multi data sources—Multi data sources are an abstraction around a group of data sources that provides load balancing or failover processing between the data sources associated with the multi data source. Multi data sources are bound to the JNDI tree or local application context just like data sources are bound to the JNDI tree. Applications lookup a multi data source on the JNDI tree just like they do for data sources, and then request a database connection. The multi data source determines which data source to use to satisfy the request depending on the algorithm selected in the multi data source configuration: load balancing or failover.
For more information about JDBC, see “Configuring WebLogic JDBC Resources” in the Configuring and Managing WebLogic JDBC.
Getting Connections with Clustered JDBC
To ensure that any JDBC request can be handled equivalently by any cluster member, each managed server in the cluster must have similarly named/defined data sources, if applicable, multi data sources. To achieve this result, data sources and multi data sources should be targeted to the cluster so they are cluster-aware and, if intended for use in external clients, their connections can be to any cluster members.
§ External Clients Connections—External clients that require a database connection perform a JNDI lookup and obtain a replica-aware stub for the data source. The stub for the data source contains a list of the server instances that host the data source—which should be all of the Managed Servers in the cluster. Replica-aware stubs contain load balancing logic for distributing the load among host server instances.
§ Server-Side Client Connections—For server-side use, connection requests will be handled by the local instance of the data source or multi data source. A server-side data source will not go to another cluster member for its JDBC connections. The connection is pinned to the local server instance for the duration of the database transaction, and as long as the application code retains it (until the connection is closed).
Failover and Load Balancing for JDBC Connections
Clustering your JDBC objects does not enable failover of connections, but it can ease the process of reconnecting when a connection fails. In replicated database environments, multi data sources may be clustered to support database failover, and optionally, load balancing of connections. See the following topics for more information:
§ To understand the behavior of clustered JDBC objects when failures occur, see Failover and JDBC Connections.
§ To learn more about how clustered multi data sources enable load balancing of connections, see Load Balancing for JDBC Connections.
§ For instructions on configuring clustered JDBC objects, see Configure Clustered JDBC.
JMS and Clustering
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.
What Types of Objects Cannot Be Clustered?
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.
Comments
Post a Comment