BPM-EAI

 Server clustering is one of the key concepts which allow users to scale up the hardware to meet the increased demand without sacrificing performance, security or affordability. In the past, clustering servers was primarily driven by the goal of increasing availability by ensuring that if a server becomes unavailable due to failure or planned downtime, another server in the cluster can assume the workload. A byproduct of clustering servers for scalability is that the additional redundancy of the multiple servers helps increase system availability. This means that server clusters can support more users at the current level of performance or improve application performance for the current number of users by sharing the workload across multiple servers. It is this particular benefit of greatly increased scalability that has made the clustering approach so desirable for the architects building Private Clouds. According to some experts, a properly organized and managed cluster has many, if not all, of the attributes associated with a cloud. If one adds the migration of assets between peer clusters within a hardware/networking pool, one has what many describe as a cloud. 

When planning for the workloads that a data server must support, a systems architect has two primary options for "scaling," or providing the required hardware processing capacity and resources to a data server. The first approach is to "scale up" where capacity is increased by adding processors and memory to a single physical machine up to the maximum capability of the hardware. With this approach, the data server cannot share data processing tasks with other separate systems. This means that once the database workload has exceeded the limitations of this system's hardware, it must be replaced with hardware of higher capacity.

The other approach, and one which is preferred by most vendors is to "scale out" where a cluster of data servers executing on multiple separate hardware systems operate together in a coordinated manner as a single logical system. Any "node" in the cluster can respond to any incoming client request for shared data. During maintenance or during a node failure, client applications can connect to any operational node in the cluster. 

here are, of course, a plethora of products available in the market which allow clustering to be implemented but the two most emphatic offerings are from the traditional rivals IBM and Oracle. Both these vendors adopt the "Scale Out" approach towards scaling up. Oracle currently offers the "Real Application Clustering (RAC)" component which helps organizations in achieving the distributed data architecture which is claimed to provide "Main-frame like" solutions in terms of performance and scalability. First available with the with Oracle Database 9i Enterprise Edition, the Oracle RAC enables a single database to run across a cluster of servers, providing fault tolerance, performance, and scalability with no application changes necessary.

BM, on the other hand, offers the DB2 for z/OS takes advantage of the unique System z IBM Parallel Sysplex® clustering design. It boasts of features like the centralized Coupling Facility hardware allow DB2 for z/OS to exhibit near-linear scalability as workload requirements grow for a proportional increase in overall database throughput. 

While both vendors claim to have a better product and the fierce competition leads to compelling arguments from both quarters, I don't really have a firm view on this. The IBM clustering technology essentially creates an in-memory repository for managing transaction data which claims to be much faster than the Oracle approach. The Oracle approach relies on a distributed lock and cache management architecture, which requires slower communication across various nodes in the cluster.

Irrespective of which technology is chosen, the importance of having a highly scalable data center can't be over-estimated.