Question

Explain how a cluster would typically use both shared memory and distributed memory paradigms. Explain how communication between processes would most likely occur in such a cluster.

Answer 1

Answer:-

Explain how a cluster would typically use both shared memory and distributed memory paradigms.

As a comparison between shared memory and distributed memory systems, the flow past the Onera-M6 wing system employing both the shared memory model and the distributed memory model for parallelization. The number of CPUs was varied between 1 and 32 with the blocking approach.

Up to 4 CPUs, the shared memory parallelized code performed as well or slightly better. The differences, however, were nominal. With 8 CPUs involved, the MPI-paralleization outperformed directives by 25 %. With 16 or more CPUs, the directive-approach was a waste of resources in comparison with message passing. The conclusion is that, as the size of the parallel region of the code decreases, the overhead associated with synchronizing different threads will dominate. Quite evidently, the MPI paralleization in this solver is less sensitive to this problem because the synchronization of the processes is realized implicitly. This way, the processes will wait for other processes only when it is really necessary.

Explain how communication between processes would most likely occur in such a cluster.

WebLogic Server Communication In a Cluster

WebLogic Server instances in a cluster communicate with one another using two basic network technologies:

• IP sockets, which are the conduits for peer-to-peer communication between clustered server instances.

• IP unicast or multicast, which server instances use to broadcast availability of services and heartbeats that indicate continued availability.

  When creating a new cluster, Oracle recommends that you use unicast for messaging within a cluster.

  Note:

  When creating a cluster, the default cluster messaging mode is unicast.

  If you encounter problems with updating JNDI trees for a cluster with unicast messaging, you might want to consider switching to multicast messaging mode.

  Oracle fully supports both UDP multicast-based and TCP unicast-based clustering in WebLogic Server. Beginning in WebLogic Server 10.0, unicast-based clustering has been made the default, primarily because it simplifies out of the box cluster configuration.

  For WebLogic Server versions 9.2 and earlier, you must use multicast for communications between clusters.

The way in which WebLogic Server uses IP multicast or unicast and socket communication affects the way you configure your cluster.

Using IP Multicast

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.

IP multicast broadcasts messages to applications, but it does not guarantee that messages are actually received. If an application's local multicast buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are "dropped." Because of this limitation, WebLogic Server instances allow for the possibility that they may occasionally miss messages that were broadcast over IP multicast.

Note:

A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255. The default multicast value used by WebLogic Server is 239.192.0.0. You should not use any multicast address within the range x.0.0.1.

WebLogic Server uses IP multicast for all one-to-many communications among server instances in a cluster. This communication includes:

• Cluster-wide JNDI updates—Each WebLogic Server instance in a cluster uses multicast to announce the availability of clustered objects that are deployed or removed locally. Each server instance in the cluster monitors these announcements and updates its local JNDI tree to reflect current deployments of clustered objects. For more details, see Cluster-Wide JNDI Naming Service.

• Cluster heartbeats—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. (Clustered server instances also monitor IP sockets as a more immediate method of determining when a server instance has failed.)

• Clusters with many nodes—Multicast communication is the option of choice for clusters with many nodes.

Multicast and Cluster Configuration

Because multicast communications control critical functions related to detecting failures and maintaining the cluster-wide JNDI tree (described in Cluster-Wide JNDI Naming Service) it is important that neither the cluster configuration nor the network topology interfere with multicast communications. The sections that follow provide guidelines for avoiding problems with multicast communication in a cluster.

If Your Cluster Spans Multiple Subnets In a WAN

In many deployments, clustered server instances reside within a single subnet, ensuring multicast messages are reliably transmitted. However, you may want to distribute a WebLogic Server cluster across multiple subnets in a Wide Area Network (WAN) to increase redundancy, or to distribute clustered server instances over a larger geographical area.