Cluster

What is a cluster?
A cluster is a logical group of WebLogic Servers instances, acting together for high
availability and Load Balancing.
A WLS cluster consists of multiple WLS instances running simultaneously and
working together to provide increased scalability and reliability. A cluster appears to
clients to be a single WLS instance. The server instances that constitute a cluster
can run on the same machine or be located on different machines. 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.
WebLogic Server Cluster support multiple algorithms for load balancing and failover:
round-robin, weight-based,random,round-robin-affinity, weight-based-affinity and
random-affinity.(by default, WLS cluster will use the round-robin method).
Advantages of cluster:
1. 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.
2. Load Balancing: The ability to distribute requests across all members of the
cluster according to the work load on each server.
3. High Availability: A mix of features that ensure applications and services are
available even if a server or machine fails. Clients can continue to work with
little or no disruption in a highly available environment. WebLogic achieves
high availability using combination of features: replication, failover and
migrate services.

What is horizontal and vertical cluster?

Horizontal Cluster: it involves running multiple java application servers that are run
on two or more separate physical machines. Horizontal scaling is more reliable than
vertical scaling, since there are multiple machines involved in the cluster
environment, as compared to only one machine.
Vertical Cluster: Vertical Cluster however consists of multiple java application
servers on a single physical machine with vertical scaling the processing power,
CPU usage, JVM heap memory configurations are the main factors in deciding how
many server instances should be run on one machine.
What is unicast and multicast?

SessionReplication:
Session Replication is nothing but having the user sessions on two locations for high
availability. So when the session gets created on one server which is called primary
then it will get copy the sessions to other server which is called secondary, the
cookies will have the details about both the primary and secondary session server
details, if something happens to primary server then the user requests will be
forwarded to secondary server which will become primary and it copy the session to
some new secondary server in the cluster.
There are two types of session replication in WLS cluster.
1. In-memory
2. DB bases session
1 In-memory Replication: Primary servers process the request and choose other
server to keep the backup of http session details so the secondary server will only
keep the backup not process the request. The information of replication will be sent
back to browser (cookies). In case the primary server goes down the Load Balancer
will direct to the secondary server based upon cookies to process the request from
the point where primary server stopped. It is called In-memory Replication.
2 DB-based Replication: Instead of storing http session backup in other managed
server, it can be stored in DB. Now, Load Balancer can direct any available server to
continue the request if primary server goes down. It is called DB based Replication.

How notification made when a server is added to a cluster?

The WLS cluster broadcasts the availability of anew server instance each time a new
instance joins the cluster. Cluster-aware stubs also periodically update their list of
available server instances.

Stubs work in WLS cluster: 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.

Cluster Algorithms & Load Balancing

Friday, July 26, 2013

HTTP LOAD BALANCING AND TUNNELING

When T3 tunneling is used with clients that connect to a WebLogic Server cluster using a WebLogic
Server plug-in, the HttpClusterServlet, or a third party load balancer, the client will attempt to load balance
requests within a session across other members of the cluster, and try to connect directly to other server
instances in the cluster.

If a firewall exists, the direct connections will fail and the client will transparently failover use the
connection through the firewall.

If there is no firewall, the client will connect directly to a server instance in the cluster.
To ensure that clients connect only through the tunneled connection, set the load balancing algorithm for
the cluster to one of the server affinity algorithms, Set the load-balancing algorithm on the Cluster>Configuration->General tab in the Administration Console.
Load Balancing with a Proxy Plug-in
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.
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

Sun One Web Serverwith the Netscape (proxy) plug-in

Apache with the Apache Server (proxy) plug-in

Microsoft Internet Information Server with the Microsoft-IIS (proxy) plug-in

LOAD BALANCING HTTP SESSIONS WITH AN EXTERNAL LOAD BALANCER

Clusters that utilize 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.

Cluster Algorithms

ROUND ROBIN LOAD BALANCING

WebLogic Server uses the round-robin algorithm as the default load balancing strategy for
clustered object stubs when no algorithm is specified at the object level. 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.

Weight-Based Load Balancing

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 preassigned weight for each server. You can use the Server -> Configuration -> Cluster tab 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 roundrobin 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.

RANDOM LOAD BALANCING

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.

Domain and Cluster:

=================
All the servers of a cluster should belong to same domain. We cannot put managed servers of
different domain under one cluster.
Also, we cannot share configured resources among clusters of different domains. e.g. If JDBC
connection pool is created in a domain, it cannot be used by cluster of other domain.
As per behavior is concerned, cluster and non-clustered weblogic servers behave similarly. It is
transparent to user i.e. user is not aware of clustering or not.

In sort:
All servers in a cluster must also be
in the same domain.
All servers within a cluster must be at the same Maintenance Pack level.
Clustered servers can be on the same or different machines.
You can have multiple clusters in a domain.

Horizontal Clustering : step by step

Friday, July 26, 2013

Cluster across multiple physical machines

Horizontal clustering involves running multiple Java application servers that are run on two or more

separate physical machines.

like shown below where all the managed servers are in a cluster -

Machine-1
- Admin Server
- MS-1
- MS-2Machine-2
- MS-3
- MS-4

How to do Horizontal Clustering ?

1. Install weblogic server on both machines with same installation directories.
2. Create domain on primary machine where you want your Admin server and copy domain to second
machine.
Step by Step 1. Install weblogic server on both machines with same installation directories. ( see my other post on
installation )
2. Start domain wizard on primary & select option "create a new weblogic domain"

3. Select default first option

4. Enter a name for your domain

5. Enter Admin Server credentials, username & password

6. Select your mode ( development or production ) and jdk you want to use

7.Select below two options

8. If you want, update your Admin Server Name, listen address, port & enable ssl if required

9. Add the number of managed servers you want for your domain, enter listen address, port & ssl
information if required.

10. Create cluster

11. Assign all managed servers to the cluster ( click on each server one by one and click on right arrow )

12. This is the turning point for horizontal clustering Create two machines ( usually create it with the name of machines, suppose you ant clustering between
to machines with hostname like hostname1.something.com &
hostname2.something.com, then create machine names like hostname1 & hostname2 )
Enter listen address of particular machine ( server ), like for mac1 enter listen address of
hostname1.something.com & for mac2, enter listen address of hostname2.something.com )
Enter port for nodemanager

13. Assign MS1 & MS2 to mac1 & MS3 & MS4 to Mac2, this will allow nodemanager to start managed
server 1 & 2 on machine1 ( hostname1.something.com ) and start managed server 3 & 4 on machine 2 (
hostname2.something.com )

14. Select create button.

Now go to Middleware Directory, D:\Oracle\Middleware, make a copy of user_projects, copy it under

same folder on another machine ( D:\Oracle\Middleware on machine 2 ).