How is an enterprise to choose a clustering technique, if any? This series of articles compares three methods of storage clustering, including examples of where each particular method is effectively applied. This installment covers non-distributed clustering.
Non-distributed clusteringThe non-distributed method, as opposed to the
Requires Free Membership to View
When you register for SearchStorage.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Our goal is to keep you informed on the hottest topics, the latest news and the biggest challenges you face as a storage professional today.
Rich Castagna, Editorial Director
paired-failover pseudo-cluster method , is a cluster method by definition. It consists of 2 to N controllers, which are physically arranged in a rack such that tightly coupled communication exists over a common (or, in some cases, redundant) backplane. In current practice, N is usually 4, 8, or at most 16. In addition, N is always a multiple of two—odd-numbered collections of controllers is not allowed by the architecture. Another name for this method is "multiple 2-way (dual) clustering." It is a collection of 2-way clusters. Since this collection of 2-way clusters is physically contained and tightly coupled within a single rack or enclosure, there is no protection of the system itself from failure. In essence, the entire system, although composed of several 2-way clusters, is at risk of compromise since the components cannot be physically distributed throughout distinct and separate locations. Non-distributed clustering is a physically "captive" technique.
In this method, distribution of LUNs throughout the cluster is a priority. As in paired-controller failover, one must decide which controller to provision and assign a LUN through before its creation. When active, a LUN is accessed via one and only one controller. In the case of any failure between the server (initiator) and its controller, the failing controller will attempt to move management of the appropriate LUNs over to its "partner" in the rack. However, unlike the paired-failover method, the non-distributed cluster can locate and move LUNs over to a controller other than its partner, if the partner is down or otherwise disabled and not participating in the cluster. This is the distinguishing characteristic of non-distributed clustering compared to paired-failover pseudo-clustering. This method also requires any server that desires access to the LUNs in the non-distributed cluster to install and operate specialized software to handle the failover from within the cluster, similar to the paired-failover method.
The advantage non-distributed clustering has over paired failover is its inherent greater reliability and resistance to unplanned downtime events. However, non-distributed clustering presents several points of inflexibility, as the pool of storage in the non-distributed cluster cannot be accessed by other non-distributed clusters. There is no provision for dynamic linking, in the virtual cluster sense, from one non-distributed cluster to another. Replication is required, just as it is in paired-failover, to achieve higher levels of data availability between multiple instances of non-distributed clusters. Therefore, non-distributed clustering presents the same business detriments and deterrents that paired-failover does in data-recovery scenarios.
Non-distributed clustering is non-optimal in that the entire (non-distributed) cluster can suffer loss of availability if the rack in which all the physical components are installed is compromised. Non-distributed clustering also fares no better than paired-controller pseudo-clustering in terms of its resistance against planned downtime.
Best fit for non-distributed clusteringThe best fit for non-distributed, tightly coupled clustering is an environment consisting of a single, large (up to supercomputer scale) server whose activity is concentrated into a single or small set of applications that require very highly available, relatively large storage volumes. A large server, with many HBAs, running a single, complex application, represents the best case for this architecture. However, in terms of generalized industry usage, this architecture represents a very small portion of "real-world" scenarios, and is thus self-limiting by its very nature. The complexity of non-distributed clustering becomes the limiting factor when applied to scenarios outside of the above.
About the author
Robert Peglar is the Chief Architect for XIOtech Corporation. He is responsible for storage architecture, healthcare technology and strategic direction. Robert is XIOtech's principal member of the SNIA, the IP Storage Forum and the Shared Solutions Forum.
This was first published in June 2004