Clustered NAS, Part One

It seems as though every manufacturer is now offering clustered NAS. There are so many variants that I can't cover everything about them in one entry, but basically each solution tends to focus on a particular capability; some are built for scale, others are built for performance, and, of course, there are solutions that try to deliver a happy medium. Over the next several entries we will do some exploration of these systems and where they might make sense for you.Like any other form of technology, there isn't just one description of clustered network-attached storage. We will start this series by dissecting the different types. In general, there are two types of clustered NAS solutions; tightly coupled clusters and loosely coupled clusters. One of the key areas of difference between the two is how a volume or file system is distributed.

A good example of a loosely coupled NAS is the OnStor NAS solution. In the cloud, storage area companies such as ParaScale offer a loosely coupled solution for building a private cloud. Each NAS head in loosely coupled solutions is essentially its own entity and isn't dependent on the other nodes in the cluster to stay up and running. Typically, each volume or file system is the property of a particular node in the cluster. It can be reassigned on the fly, but there is a one-to-one relationship at any given point in time. In the event of a node failure either through automated software or manually, a file system must be reassigned to another.

There are quite a few examples of tightly coupled clusters. Isilon offers a tightly coupled solution for primary storage, Cleversafe is an example of a tightly coupled solution in cloud storage, and Permabit is a good example in archive or retained storage. In a tightly clustered system, the volume or file system is distributed across every (or most) nodes in the cluster. These file systems are dependent upon other nodes in the cluster to stay up and running. Tightly coupled solutions offer some form of "RAID-like" redundancy so that a failed node doesn't result in data loss or even loss of access. Permabit, for example, uses a protection scheme called RAIN-EC that can survive multiple node failures while not requiring the redundant capacity that a mirror or triple-mirror protection scheme would require.

Be sure to register for our upcoming Webinar, Demystifying Primary Storage Data Reduction.

Track us on Twitter: http://twitter.com/storageswiss.

Subscribe to our RSS feed.

George Crump is founder of Storage Switzerland, an analyst firm focused on the virtualization and storage marketplaces. It provides strategic consulting and analysis to storage users, suppliers, and integrators. An industry veteran of more than 25 years, Crump has held engineering and sales positions at various IT industry manufacturers and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.