WebLogic Administration Concepts

Domain

• A domain is an interrelated set of WebLogic Server resources that are managed as a unit.

• A domain 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

• A domain can include multiple clusters.

Admin server

• In each domain, only one WebLogic Server instance acts as the Administration Server.

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

Managed server

• It is also a weblogic server instance. A domain includes one or more WebLogic Server instances, which can be clustered, non-clustered, or a combination of clustered and non-clustered instances.

Cluster

• Cluster can run on the same machine, or be located on different machines
• Adding additional servers to cluster on existing machine at any time. You can add server instances to a cluster without interruption of service—the application continues to run without impact to clients and end users.
• Each server instance in a cluster must run the same version of WebLogic Server.
• All server instances in a cluster must reside in the same domain; you cannot "split" a cluster over multiple domains.
  

Clustering Architecture

• A cluster architecture in which all tiers of the Web application are deployed to a single WebLogic Server cluster is called a combined tier architecture.
• The advantages are

Ease of administration

Flexible Load Balancing

Robust Security

• Multi tier architecture can be used when we need to load balance the calls to clustered EJB’s
• The Cluster architecture combines all web application tiers and puts everything in one cluster
• A cluster architecture in which all tiers of the Web application are deployed to a single WebLogic Server cluster is called a combined tier architecture.
• Because a single cluster hosts static HTTP pages, servlets, and EJBs, you can configure the entire Web application and deploy/undeploy objects using the WebLogic Server Console. You do not need to maintain a separate bank of Web servers (and configure WebLogic Server proxy plug-ins) to benefit from clustered servlets.

Services That Can Be Clustered

• 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 connections

• WebLogic Server provides clustering support for servlets and JSPs by replicating the HTTP session state of clients that access clustered servlets and JSPs

Types of Objects Cannot Be Clustered?

• File services
• Time services
• WebLogic Events (deprecated in WebLogic Server 6.0)
• Workspaces (deprecated in WebLogic Server 6.0)

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.

Benefits of Clustering

• Clustering Provides

- High Availability

- Load Balancing

- Scalability

• High Availability – Achieved by replication of services.
• Scalability - The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand.
• Load Balancing - Load balancing is the even distribution of jobs and associated communications

Communications in a Cluster

• WebLogic Server uses standards-based communication techniques and facilities—multicast, IP sockets, and the Java Naming and Directory Interface (JNDI)—to share and maintain information about the availability of objects in a cluster.
• IP multicast is a simple broadcast technology that enables multiple applications to "subscribe" to a given IP address and port number and listen for messages. A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255.
• 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.
• In 8.1 to setup a cluster in one machine the server need not be multi homed
• We can use one IP address and different multicast port numbers to each server in the cluster

WebLogic Server “Heartbeat”

• All server instances in a cluster use multicast to broadcast regular server heartbeat messages to other members of the cluster.
• Each heartbeat message contains data that uniquely identifies the server that sends the message.
• Servers broadcast their heartbeat messages at regular intervals of 10 seconds. In turn, each server in a cluster monitors the multicast address to ensure that all peer servers’ heartbeat messages are being sent.
• If a server monitoring the multicast address misses three heartbeats from a peer server (i.e., if it does not receive a heartbeat from the server for 30 seconds or longer), the monitoring server marks the peer server as “failed.” It then updates its local JNDI tree, if necessary, to retract the

services that were hosted on the failed server.

One to Many Communication - Multicast

Multicast

M1

M2

JNDI

Cluster-wide

“JNDI new/changed”

One to One Communication - Sockets

Multicast

M1

M2

JNDI

HTTP/Object State

HTTP/Object State

IP Socket

Cluster-wide

Multicast Test Utility

• It is a good practice to make sure that Multicast test is successful before deploying application.

What if multicast is not working:

1) Make sure to provide proper TTL value if there are network hops.

2) Turn off IGMP snooping and see if it fixes the problem.

Further details, check the multicast pattern at:

http://support.bea.com/application_content/product_portlets/support_patterns/wls/Multicast_Pattern.html

Cluster-wide JNDI tree

• It is similar to a single server instance JNDI tree. 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.

Configure and Manage a Simple Cluster

• Requirements for Clustering

- All the servers must be located on one LAN

- Set to use static IP addresses

- Configured with the same build

- Each Weblogic server instance must use the same IP address and different Port or use different IP address and same port

- All the servers operating in a cluster must be the same version and service pack of weblogic server

- Installations for clustered WebLogic Server instances must have a valid cluster license. If you do not have a cluster license, contact your BEA sales representative.

Configure and Manage a Simple Cluster

• Creating A Cluster

- Select the clusters node in the left Pane, in the right pane select create new cluster

• Name—assign a unique name to the cluster. Each configurable resource in your WebLogic Server environment should have a unique name.
• Cluster Address—supply a cluster address that identifies the Managed Servers in the cluster.

- DNSName1:port1,DNSName1:port2,DNSName1:port3

- IPaddress1:port1,IPaddress2:port2;IPaddress3:port3

Features and Infrastructure - Load Balancing of Clustered Services

• Can be accomplished either by using separate load balancing hardware or by using the built-in load balancing capabilities of a WebLogic proxy plug-in

• Clusters that utilize a bank of web servers and WebLogic proxy plug-ins, the proxy plug-ins provide only a round-robin algorithm for distributing requests to servlets and JSPs in a cluster

• Clusters that utilize a hardware load balancing solution can utilize any load balancing algorithms supported by the hardware. These may include advanced load-based balancing strategies that monitor the utilization of individual machines

Load Balancing for Clustered Objects

WebLogic Server clusters support several algorithms for load balancing clustered objects. The particular algorithm you choose is maintained within the replica-aware stub obtained for the clustered object. Configurable algorithms for load balancing clustered objects are:

Round-robin

Weight-based

Random

Round-Robin (Default)

• WebLogic Server Detects Failures by monitoring

• Socket connections to a peer server

• Regular server "heartbeat" messages – “three (10 second) strikes and your out”

• Failover for Clustered Servlets and JSPs

• Proxy plug-in handles failover transparently to the client

• Hardware load balancing simply redirects client requests to any available server in the WebLogic Server cluster. The cluster itself obtains the replica of the client's HTTP session state from a secondary server in the cluster

• Failover for Clustered Objects

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

• Idempotent Objects -Automatic failover generally occurs only in cases where there the object is idempotent

• Other Failover Exceptions - even if a clustered object is not idempotent, WebLogic Server performs automatic failover in the case of a ConnectException or MarshalException

HTTP Session State Replication

• Overview

• Requirements for HTTP Session State Replication

• Using Replication Groups

• Accessing Clustered Servlets and JSPs Using a Proxy

• Accessing Clustered Servlets and JSPs with Load Balancing Hardware

HTTP Session State Replication - Overview

• Supports automatic failover for servlet and JSP HTTP session states

Weblogic.xml

<session-descriptor>

<session-param>

<parama-name>PersistentStoreType</param-name>

<param-value>replicated</param-value>

</session-param>

</session-descriptor>

HTTP Session State Replication - Requirements for HTTP Session State Replication

• You must access the WLS cluster using either load balancing hardware, or a collection of web servers with WLS proxy plug-ins (configured identically)

• Proxy Requirements

• Plug-ins maintain a list of WLS instances that host a clustered servlet or JSP, and forward HTTP requests to those instances using a round-robin strategy. It also provides the logic to locate the replica of a client's HTTP session state if a WebLogic Server instance should fail.

• WebLogic Server + HttpClusterServlet

• Netscape Enterprise Server + Netscape (proxy) plug-in

• Apache + Apache Server (proxy) plug-in

• Microsoft Internet Information Server + Microsoft-IIS (proxy) plug-in

Load Balancer Requirements

Hardware must support SSL persistence and passive cookie persistence.

Enables WebLogic Server to write cookies (containing information about the location of replicated HTTP session states) through the load balancer to the client. The load balancer interprets an identifier in the client's cookie to maintain the relationship between the client and the primary WLS Server hosting the HTTP session state

Session Requirements

Ø Session Data Must Be Serializable

Ø Use setAttribute() to Change Session State

Ø Consider Serialization Overhead for Session Objects

Types of Session Persistence

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

ü WebLogic has five different implementations of session persistence: (set in weblogic.xml)

ü Memory (default)

File system persistence (session info stored in text file)

<session-descriptor>

<session-param>

<param-name> PersistentStoreType</param-name>

<param-value>file <param-value>

<param-name>PersistenceStoreDir</param-name>

<param-value> Shared folder location </param-value>

</session-param>

</session-descriptor>

JDBC persistence (session info stored in database)

<session-descriptor>

<session-param>

<param-name> PersistentStoreType</param-name>

<param-value>jdbc <param-value>

<param-name>PersistentStorePool</param-name>

<param-value> Pool Name </param-value>

</session-param>

</session-descriptor>

In-memory replication (Most commonly used in cluster setup)

<session-descriptor>

<session-param>

<param-name> PersistentStoreType</param-name>

<param-value>replicated <param-value>

</session-param>

</session-descriptor>

Cookie-based session persistence (session info stored in client browser)

Limitation: You can store only string attributes in the session

How replication happens:

Primary server chooses its secondary based on algorithm

Once a secondary is chosen, it would remain secondary for lifetime of the server unless a new server is added to cluster that would alter the algorithm.

Replication process starts at the end of the request.

Only session attributes marked “dirty” (setAttribute())

are replicated at the end of call before sending the response back to client.

Persistent JDBC Replication

• ALL server instances have access to ALL sessions

• Subsequent requests from same client can be handled by ANY server

• Changing session object causes (slow) DB synchronization

• Great fail over capability

• Significant performance reduction

In-Memory State Replication

• Session objects exist only on two servers

• Proxy must be used to ensure client integrity

• Backup session becomes primary session if sever with primary session fails

• Mediocre fail over capability

• Reasonable load balancing performance

Replication Group

• A replication group is a subset of servers that:
• are in the same cluster
• are preferred “buddies” for replication of data
• can be used to force replication across server

Configure HTTP Cluster Servlet

1. Create a Domain Server and three managed server
2. One server is the Admin Server
3. One is the proxy server (man1 port 8001) where you configure the HttpClusterServlet.
4. The rest two are the managed servers where the application will reside (man2 port 9001 and man3 port 10001).
5. Start the admin server.
6. Start the man1 server.
7. Deploy the ClusterServApp.war on it.
8. Now start the man2 server and the man3 server.
9. Deploy any web application that you need to access through the weblogic
10. Access the application using the following url http://localhost:8001/%3capp-name>
11. One or more web address associated with them
12. Allow you to make one web server behave as if it were multiple servers
13. It allows one web server to host multiple internal and external corporate sites
14. Convenient to have the same web server respond to requests for more than one domain name.

Setting up Virtual Host

Use the Administration Console to define a virtual host.

1. Create a new Virtual Host.

a. Expand the Services node in the left pane. The node expands and displays a list of services.

b. Click the virtual hosts node. If any virtual hosts are defined, the node expands and displays a list of virtual hosts.

c. Click Create a New Virtual Host in the right pane.

d. Enter a name to represent this virtual host.

e. Enter the virtual host names, one per line. Only requests matching one of these virtual host names will be handled by the WebLogic Server instance or cluster targeted by this virtual

host.

f. Click Create

2. Define logging and HTTP parameters:

a. (Optional) Click on the Logging tab and fill in HTTP access log attributes

b. Select the HTTP tab and fill in the HTTP Parameters.

3. Define the servers that will respond to this virtual host.

a. Select the Targets --> Servers tab. You will see a list of available servers.

b. Select a server.

c. Click Apply.

4. Define the clusters that will respond to this virtual host (optional). You must have previously defined a WebLogic Cluster.

a. Select the Targets tab.

b. Select the Clusters tab. You will see a list of available clusters.

c. Select a cluster.

d. Click Apply.

5. Target Web Applications to the virtual host.

a. Click the Web Applications node in the left panel.

b. Select the Web Application you want to target.

c. Select the Targets tab in the right panel.

d. Select the Virtual Hosts tab.

e. Select Virtual Host.

f. Click Apply.

You must add a line naming the virtual host to the etc/hosts file on your server to ensure that the virtual host name can be resolved.