Unicast Clustering Vs Multicast Clustering

INTRODUCTION:-

1.1 Unicast

Unicast is a type of transmission in which information is sent from only one sender to only one receiver. In another words, Unicast transmission is between one-to-one nodes (involving two nodes only).

1.2 Multicast

Multicast is a very much different from Unicast and Multicast in definition and application as well. It is a type of transmission or communication in which there may be more than one senders and the information sent is meant for a set of receivers. Note that sometimes information might not be directed towards any receiver at all.

Multicast operates on a different class of IP address (Class D IP Series). All the other computers electing to receive information in a multicasted network must be a part of MulticastIP based network. Also, unlike Unicast and Broadcast which uses TCP for its communication, Multicast uses UDP. This is only because TCP does not support Multicast mode of communication.

1.3 Examples of Unicast and Multicast:-

Unicast

Unicast is a one-to one connection between the client and the server. Unicast uses IP delivery methods such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), which are session-based protocols. When a Windows Media Player client connects using unicast to a Windows Media server, that client has a direct relationship to the server. Each unicast client that connects to the server takes up additional bandwidth. For example, if we have 10 clients all playing 100-kilobits per second (Kbps) streams, those clients as a group are taking up 1,000 Kbps. If we have only one client playing the 100 Kbps stream, only 100 Kbps is being used.

Examples of Unicast transmission are http, smtp, telnet, ssh, pop3 where the request for information is directed from one sender to only one receiver at the other end.

To understand this better, try to imagine a scenario where one computer’s request for the URL [http://www.google.com] is received by every other computer that’s connected to the Internet. This way Internet will be flooded with such requests and therefore there is a strong need for Unicast transmission on small and large networks. All Ethernet and IP networks support this type of transmission.

Unicast uses TCP for its communication and packet transmission.

Multicast

Multicast is a true broadcast. The multicast source relies on multicast-enabled routers to forward the packets to all client subnets that have clients listening. There is no direct relationship between the clients and Windows Media server. The Windows Media server generates an .nsc (NetShow channel) file when the multicast station is first created. Typically, the .nsc file is delivered to the client from a Web server. This file contains information that the Windows Media Player needs to listen for the multicast. This is similar to tuning into a station on a radio. Each client that listens to the multicast adds no additional overhead on the server. In fact, the server sends out only one stream per multicast station. The same load is experienced on the server whether only one client or 1,000 clients are listening 

One good example of Multicast based network is video transmission network in which one computer needs to transmit video channel to a specific group of computers. This way when the other computers are also a part of this Multicast IP network, they will be able to receive sameset of data at the same time. Multicast offers savings on bandwidth and is the preferred way of data communication when data is to transmitted to a set of computers.

1.4    COMPARISON BETWEEN CLUSTER MULTICAST MESSAGING AND UNICAST MESSAGING MODE

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.

Mode of Communication:

Multicast – A multicast address and multicast port is used for listening to the messages.

Unicast – A network channel is used for communication between the servers. If no channel is specified, default network channel is used.

=====================

Method of communication between servers:

Multicast – Each server communicates with every member server in the cluster. This means heartbeats are sent to every server.

Unicast - For the member servers in the cluster, group leaders are chosen and only those group leaders communicate with the servers among the group and these leaders notify each other about the availability of all the other servers.

For example: Suppose there are 6 servers in the cluster. 2 groups are made and there are 2 group leaders. Other 2 servers of the group will notify their leader that they are alive and the group leader will send this information to the leader of other group.

The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.

=====================

For new server versions, using unicast is recommended because it is a simplified communication mode. But for backward compatibility with the previous versions, you will need to use multicast if there is a communication requirement between clusters of versions prior to WLS 10.0.

Whenever the messaging mode of the cluster is changed, all the servers in the cluster need a restart because the changes are not dynamic.

Multicast Vs. Unicast with WebLogic Clustering

WebLogic Clusters manage membership via messaging within its members. The members join/leave the cluster as well as update other members via messages to the entire cluster. There are two ways for cluster messaging in WLS - Multicast or Unicast. This post goes provides a brief overview of the cluster messaging and some general guidelines around using the different messaging options.

2   WLS Cluster 

WebLogic clustering provides a homogeneous model for managing a set of server instances while providing scalability, load balancing and high availability to the services running within the member instances. For the end client, it appears like one single and uniform service with all the RASP (reliability, availability, scalability, performance) capabilities. Each cluster member is aware of other members and advertise each other services in addition to their own

2.1 Unicast & Multicast

Multicast is easier to explain over Unicast. Multicast is a broadcast UDP option for sending a packet/announcement over to a group that is listening on a specific multicast address and port over which the announcement is sent.There is a defined range for valid Multicast address (224.0.0.1 to 239.255.255.255). Everyone listening on the given address hears the announcement just like following a Twitter post. Some limitations with Multicast is the TTL (time to live) across machines/subnets/routers needs to be adjusted and the routers configured to retransmit the multicast packet across subnets.

Unicast is more of a point to point UDP option to send the packet to a specific member and not everyone. That way, unicast is more of a private conversation between two individuals while multicast is more of a shout to a group or room. Both are UDP based, so there can be losses unlike TCP that handles retransmissions on message loss. But Unicast can span across routers and does not have to worry about TTL without the everyone hearing the announcement. So, Network Admins in general prefer to go with Unicast over Multicast for these reasons.

2.2 WLS Cluster Configuration

When a cluster is created within a WLS Domain (either via wlst or config wizard or copy/update of existing domain), it is configured as using Unicast or Multicast messaging. As part of complete Cluster configuration, the multicast listen address and port should be specified if going with Multicast option. Also the managed servers should be targeted/added to the Cluster instance. There can be multiple clusters and any given managed server instance can only belong to atmost one cluster (or none). This will let the clustered managed servers (Admin Server should not be part of any cluster nor can cluster span domains) go with Unicast or Multicast when they are started. It should be noted that Multicast used to be the only option in WebLogic prior to 10.0 version while either Unicast or Multicast can be used from version 10 onwards.

2.3 Cluster Messaging

How does each member join the cluster and see or recognize others? At bootstrap time, the managed servers get their configuration via JMX MBeans from the Admin server (or from cached configurations if the Admin server was down) and recognize that they belong to a cluster and they have to go with Unicast or Multicast.

3  WLS Multicast Messaging 

So, in a multicast messaging cluster, the managed servers start listening to the specified multicast address once it checks its configuration and knows it belongs to so and so cluster and has to use specified multicast address and port. Once it listens on the specified multicast address, it sends an announcement about its arrival to others via multicast - more like a shout-out. Other running clustered members of the same cluster who are already listening will respond back and add the new member to their list of known cluster members. The new member will also update its cluster list with other members. This process continues as new members get added. The membership gets renewed based on each member sending periodic announcements to other members proclaiming its liveliness. If a member goes down (shutdown or killed or not able to respond), then it wont be able to send its broadcasts and other members will drop it from the cluster list and re-add it when it comes back online. If a member is directly talking to another cluster member, just the direct socket connection is enough in establishing its membership with its connected member. Since multicast is a broadcast, just a single announcement  retain’s  a instance's membership and let others continue to maintain it in their cluster list till its time to renew its membership. Its a mesh where every member can see every other member in the cluster.

4  WLS Unicast Messaging

With Unicast, WLS divides the cluster into a multiple groups, each having a max of 10 members. The division happens as the servers come up. Each of the server listens on their specified listen address and the other members can send/receive unicast packets over that listen address as every clustered member knows the configurations of other cluster members.

The oldest within the group is designated the group leader. The group leader communicates over Unicast to other members (over the specified member's listen address) within its group and adds/drops them based on them renewing their membership or not responding. The group leaders communicate amongst themselves. So, if there are 4 group leaders, each group having 10 servers, a membership announcement from server1 in group1 will be picked by GroupLeader1 of group1 and retransmitted to all other members within the group1 as well as to other three group leaders. The remaining group leaders will in-turn retransmit the membership information within their groups. This way, every change is picked up and retransmitted by the group leaders to within their group and to other groups via group leader to group leader communication. The group leaders remain the hub for each group while they themselves form a mesh with other group leaders.

5 COMPARISONS between Unicast & Multicast

Multicast	Unicast
Only option in pre-10.0 versions of WLS, continues to exist in version 10+	Available from version 10 onwards
Requires configurations to Routers, TTL	No configuration required
Requires configuring the Multicast Listen Address and port	Just specify the listen address (can be Default Channel or use a Custom Network Channel for Cluster communication)
One announcement to join/maintain membership	one transmission to group leader has to be retransmitted to other group members (N) + to other group leaders (M) who then again retransmit to their group members resulting in (NxM) packets
Everyone sees everyone	Group Leaders have to do real heavy lifting of retransmitting everything across its group and other group leaders and can get bogged down in just retransmitting
Can lead to big broadcasts through the entire subnet/LAN if there are frequent joins/drops of members or change in services (JNDI updates of bound services, frequent app deployments or members going out of sync)	Not a broadcast throughout the subnet/lan, but still more packets to be sent across as Group Leaders have to retransmit everything. Can consume bigger bandwidth

As listed in the table above, these would be the guidelines:

1.                   If the cluster is small and simple (under 20 members), go with Unicast. No configurations required and the group leaders won’t be stretched retransmitting data.

2.                   If the Network configurations strictly prohibit multicast and members have to reside in different subnets and cluster sizes are still under or mid-20s, go with Unicast.

3.                   If it’s a real large cluster (over 20 members) and members can reside in the same subnet or even if they are not on same subnet but network router configurations can allow multicast, go with Multicast.

4.                   If over 50 members, change to network configurations to allow multicast and stick with Multicast.

5.                   Over 100 members try to break up the domain into multiple separate domains and individual clusters for better administration and management even though Multicast option can handle such large domains. Or use custom scripts/wlst to manage and monitor individual members instead of relying on a single application (like console) to manage/monitor/handle all servers at the domain level.

The reason for recommending Multicast over Unicast for large clusters is due to the work load on the group leaders and retransmissions. The group leaders have to retransmit every member's packet within their group as well as to other group leaders (who again send to their group members) which can just lead to more and more work as the cluster grows bigger.

Another big reason is that WLS Multicast based messaging is quite mature and stable compared to Unicast which got only introduced with version 10. Also, with unicast, there can still be retransmits (as it’s not auto error correcting) and it can consume more bandwidth due to repeat retransmits by group leaders to others compared to one transmit for multicast.

*********************************************************************************************************