Cluster

A cluster is a group of managed servers running simultaneously and working together to provide increased scalability and reliability

•     Scalability through parallelism
•     Reliability/Availability: through replication and redundancy
•     A cluster appears as single instance to most clients.
•   Clusters enable some advanced features, such as whole server migration, and clustered JMS destinations.

Cluster guidelines:

   All servers in a cluster must also be in the same domain.

   All servers within a cluster must be at same maintenance pack level.

   Clustered Servers can be on the same or different machines.

   You can have multiple clusters in a domain

Load balancing in cluster:

    For JSPs and Servlets:

               Load balancing is external

               Web server proxy plug-in (round robin)

               HTTP proxy servlet (i.e., using WLS as a load balancer)

               3rd party h/w or s/w load balancer

    

    EJBs and RMI Objects:

            load balancing is done at connection

            Objects are cluster-aware

            Load balancing algorithm is stored in the clustered object's stub

            Objects are available on all cluster members; remote objects connect/use according the LB algorithm in the stub

    Load balancing algorithms: 

               Round robin

               Weighted

               Random

               Server affinity

Failover in cluster:

    Servlets and JSPs

          HTTP session state is replicated to a secondary server in the cluster or to a database

    EJBs and RMI Objects:

          Replicas available throughout the cluster

          Exceptions caught and retired on another instance

          For stateful session Beans, state is replicated on a secondary server

Communication in a cluster:

       Peer to peer using sockets-used 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.

       Peer to peer using Unicast or Multicast-used for:

             Cluster-wide JNDI updates

             Heartbeates

       Cluster-wide JNDI tree

              Lists local resources and resources available throughout the cluster

              List is maintained on all servers in the cluster

Messaging modes of cluster:

          When servers are in a cluster, these member servers communicate with each other by sending heartbeats and indicating that they are alive. For this communication between the servers, either unicast or multicast messaging is used. This is chosen from the admin console in Cluster -> Configuration -> Messaging -> Messaging Mode.

To use multicast messaging, hardware configuration and support for multicast packets is required. Unicast does not have this requirement, which is why using unicast in latest versions is recommended.

When multicast messaging is used, it is a one-to-many communication; every server sends the notification/heartbeat/multicast packet to each other. This causes a heavy load on the application’s multicast buffer, so if the buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are dropped. So there is a possibility that the server instances miss the messages. This might lead in the cluster throwing out the server instances out of the cluster.

Unicast configuration is much easier because it does not require cross network configuration that multicast requires. Additionally, it reduces potential network errors that can occur from multicast address conflicts.