Storagebod Rotating Header Image

Sound of One Node Clustered

I've got a quick and dirty implementation to do at work but like all quick and dirty pieces of work; you know that the decisions you make in haste will come back and haunt you if you don't do them right. Luckily, we have some idea what the end goal should be and are trying to put together the path which will get us to that end goal without causing us too much trouble but the user is impatient to have something, so we've got to give them something.

In this case, this means us potentially building a single node cluster; we could do what the user requires now without a cluster but it will be harder in a couple of months to retrofit the final solution in as opposed to simply expanding the cluster. Building a single node cluster in this case is not hard and really only requires us to ask for an extra set of IP addresses and installing the cluster software.
And this led me to scratching my head again!

Why on earth did NetApp create a non-cluster mode for OnTap 8; this is just storing pain for users at some point going forward? A well written cluster mode has so many advantages, it seems like madness not to encourage users to go for it and it's actually a very clever potential lock-in for NetApp.

Not only that, currently, it is pretty much as painful to go from OnTap 8 7-Mode to OnTap 8 Cluster-Mode as it is to refresh your NAS device with another vendor's kit. Personally, the more I think about it; the more I think that NetApp have missed a trick on this. I am absolutely convinced that they actually over-reached themselves on OnTap 8 and promised the earth; realistically they've under-delivered. 

Most users probably won't notice this under-delivery but NetApp could have made our lives a lot easier. A single install mode which was automatically ready to be clustered was what was wanted; seamless addition of heads and seamless migration between heads. This was an opportunity to not simply delight customers by meeting their needs today but also their needs in eighteen months time when they need to add more capacity. How much simpler would it be to simply add in another head with some additional capacity and have it available for the whole namespace without have to create another one?  For all NetApp's vaunted embracing of the cloud; this seems to be a missed opportunity. 

Starting small and growing incrementally does not really seem the order of the day for NetApp; hoping that they can do better in the next releases. But if they don't, there are an ever growing number of clustered NAS devices waiting in the wings which although on the face of it offer very little over the traditional NAS devices from NetApp (and EMC) but long-term if I was a service provider looking for a long-term strategy which does take account of growth and technical refresh, I would be tempted to be having a long hard look at.

Of course, one can't really call OnTap 8, quick and dirty… 


  1. TimC says:

    I would say it’s pretty obvious why there are two modes. Look at the feature set of cluster-mode vs. 7-mode. They absolutely had to get 8 out the door for 64-bit aggregate support which people have been demanding for 2 years now. Does it suck that there are two modes? Sure. But I’d rather have them release 2-modes and have one code-base to focus all their engineering efforts on than see them have 7G with a full feature set but significant limitations on space as well as 8 without the limitations but an incomplete feature set and an engineering split between the two.
    Given that nobody else doing clustering today even comes close to what NetApp is doing right now in 7-mode/7g, I’d say it’s not an easy problem to solve.

  2. Martin G says:

    Oh, I know it’s hard but basically at the moment, to all intents and purposes; OnTap 8 is two different products. I’m kind of hoping that NetApp come up with a seamless way to migrate from OnTap 8 non-clustered to OnTap 8 clustered. The same way that they need to come up with a seamless, data-in-place way of converting to 64 bit aggregates.
    Migration is becoming more and more of an issue and with 64-bit aggregates for example; the ability to do non-disruptive migrations is going to be absolutely vital.

Leave a Reply

Your email address will not be published. Required fields are marked *