Clustered Storage: Myths and Reality

[Ahmad]

The term "clustered storage" is used to describe many different kinds of offerings by storage vendors. In its most common avatar, it is associated with high performance computing. Sometimes they are deployed as network attached storage (NAS) file servers (refer: Clustered storage technologies catch on). As it gets more and more acceptance by the corporate world, there are still, unfortunately, many myths surrounding it...

Myth 1: Clusters are not grids, grids are not clusters.

Reality: A cluster is, essentially, a grid and a grid is a cluster. A cluster can be local or remote and can use proprietary or open solutions just like a storage grid. Some vendors misguide customers by masking a cluster by calling it a grid, so that their offering stands out in the market. But the fact is: a cluster is an implementation of a grid.



Myth 2: Clustered storage is only for parallel or sequential access.

Reality: This is not true. Besides paralle or sequential access, some solutions support OLTP, as well as general file serving, while others can handle bulk storage applications cost-effectively.



Myth 3: Clustered storage is only for large IT environments.

Reality: This is partly true because of huge costs. However, clustered storage can simplify things for small sites leveraging modular growth in terms of performance or capacity or ease of management.



Myth 4: Clustered storage is only for performance applications.

Reality: Definitely not limited to performace oriented implementations. It is equally effective for NAS consolidation, as well as for home directors, bulk storage, near-line archiving of structured and unstructured data.



Myth 5: More ports, processors, nodes, networks and devices guarantee more performance.

Reality: It's not just about the number of components or speed. More nodes, ports, memory and disks do not guarantee more performance for applications. It depends on how these resources are deployed and how the storage management software enables those resources to avoid bottlenecks. For some systems, more nodes are required purely to compensate for overhead or performance congestion.