www.Tutorialsforu.info

 

Clusters vs. NOWs

The key differences between a cluster and a NOW are:

 

• All of the compute nodes in a cluster are dedicated only for cluster usage. Whereas, individual workstation in NOWs may or may not be participating in the parallel computing environment, depending on whether that workstation is idle at that time or not. Thus on a cluster a parallel algorithm can assume certain amout of computational resources in a node to be available for its exclusive use, but on a NOW the parallel algorithm needs to take into account possible significant changes in available resources on a participating workstation.

   

• A cluster has a dedicated interconnect fabric  connecting its compute nodes. This interconnect fabric can be highly optimized to work best for the needs of parallel applications being run on the cluster. A NOW typically uses the building LAN network for the communication requirements of parallel algorithms running on its workstations. Since the building LAN is used for a very broad set of applications for various users, it cannot be optimized just for the use within a NOW.

   

• A workstation participating in a NOW is optimized for interactive usage of the workstation user. A cluster nodes, on the other hand, can be fully optimized for the parallel algorithms being run on them.

   

• A cluster is managed as a single entity located in a single computer center. A NOW consists of entities managed by multiple personnel, often by individual workstation owners.

   

 

Clusters vs. MPPs

The key differences between a cluster and an MPP system are:

 

• In a cluster various components or layers can change relatively independently of each other, whereas components in MPP systems are much more tightly integrated. For example, a cluster administrator can choose to upgrade the interconnect, say from fast ethernet to gigabit ethernet, just by adding new network interface cards (NICs) and switches to the cluster. On the other hand, in most cases the administrator for an MPP system cannot do such upgrades without upgrading the whole machine.

   

• A cluster decouples the development of system software from innovations in underlying hardware. Cluster management tools and parallel programming libraries can be optimized independent of the changes in the node hardware itself. This results in more mature and reliable cluster middleware software as compared to the system software layer in an MPP class system, which requires at least a major rewrite with each generation of the system hardware.

   

• An MPP usually has a single system serial number used for software licensing and support tracking. Clusters and NOW have multiple serial numbers, one for each of their constituent nodes.

   

 

Beowulf and its philosophy

Beowulf is a popular term to describe Linux compute clusters. The term originated as the name of a project at NASA Goddard, which resulted in creation of a cluster system comprising of 16 nodes in 1994. From that time on Beowulf has evolved into a broader term, describing a genre of high performance computer systems with a very enthusiastic (and vocal!) community of supporters. What exactly constitues a Beowulf is a subject of debate. Some people characterize any Linux compute cluster as being a Beowulf. Other folks deem the exclusive use of commodity hardware, open-source software and open & standard protocols as key for a system to be called Beowulf. According to the latter view the Beowulf philosophy is to not get tied to any particular vendor for any component of the system. The extreme form of this view supports building even the individual cluster nodes themselves from pieces parts by separately buying motherboards, CPUs, memory chips etc. The authors of this book very much subscribe to the Beowulf philosopy, and support using commodity off-the-shelf components whenever appropriate. But we also believe that many organizations will benefit significantly by deploying advanced technologies, which are not commodity yet, in their Linux clusters. Some organizations will also find it more cost effective to deploy vendor integrated nodes, even integrated clusters, instead of building their own expertise to do so.

 

Blurring boundaries

Many developments have blurred the boundaries between above mentioned types of systems. Their distinction, or lack thereof, is sometimes the subject of heated debates. This is a brief list of developments indicating the foray of one type of architecture into another architecture's domain:

 

• As vendors building NUMA based systems design their hardware to scale to the levels earlier only available in MPP domain, they hit operating system or application scalability issues. Therefore these vendors have to provide distributed memory style programming models on their systems.

   

• Fast cluster interconnects are coming close and even exceeding the performance of some of the proprietary interconnects used in MPP systems

   

• Various vendors are beginning to provide pre-packaged clusters with fast interconnects and cluster wide management tools, thus creating almost an MPP like experience for users and administrators.
  
  << Prev - Next >>