Stephen’s blog entry about NAS strikes so many chords with me that I find it hard to disagree with very much he writes in the entry but I am going to disagree with the central premise/question; you should not ignore NAS if you work in a Storage Team. You may hate it but you should not ignore it.
If you ignore NAS as the storage team, you will find your users going very much their own way and you will find that you have a half a dozen little NAS deployments deployed across your corporate network. This causes headaches for everyone; security, network teams, back-up teams all suffer when this happens. And when it all goes wrong, who is going to get called in to rescue the situation? Well, that would be the storage team and who will still get the blame, that will be the storage team.
Stephen talks about primary data-centre applications but what does this mean? I think that we all have our own prejudices about what constitutes a primary data-centre application but I am going to argue that this might not be a useful definition any more. If the data has value, it needs to be in a secure, supported environment.
However, it is worth looking at the problem that NAS is often used to solve; NAS is often seen as the simpler, more flexible and agile solution. In smaller SME environments where you do not have a dedicated team looking after storage and you only have a few systems; this can very much be the case. But as soon as your environment grows and increases in complexity, often interoperability issues start to raise their ugly heads.
Mostly this tends to be in the CIFS/SMB area in a mixed-environment. If there is one thing that you can currently do to avoid unwarranted complexity in your environment, that is do not deploy SMB in a mixed-environment. And even if some vendors allow you to do so, do not deploy NAS shares using SMB and NFS to share out the same volume; the security models will eventually cause you to cry.
A pure NFS environment generally works well; a pure Microsoft SMB environment generally works well. But they need looking after and the storage team needs to work closely with the server teams; the storage team needs to understand more that pure storage, they need to understand the operating systems that they are talking to. I think this is why often storage teams try to avoid NAS, they really want to focus on spinning rust not what the users want to use it for.
For the storage team, NAS is not simpler; it is more complex. So is it more flexible and agile?
Flexibility can probably summed up as shared-access to common areas. This is harder to achieve with traditional block storage and can bring you into the world of clustered file systems; these have traditionally been fairly complex and arcane to manage and set-up. They are getting better, GPFS is the one that I am most familiar with and it has come on massively in the terms of useability over the past decade. The only problem with most of the clustered file systems is that they are not available for all operating systems but with the growth of Linux and Windows in the data centre, this is becoming less of an issue.
Agility, it is probably quicker to throw up a NAS share than to present traditional block storage. It can use the same infrastructure as your already in place IP network. You do not need a traditional SAN and you do not need to put in extra cards in your servers. You can just put a NAS device on your network and start sharing. iSCSI, however could also be deployed in the same way, just as quickly and arguable more simply as you do not need to worry about integrating networked file-systems into your existing security domains.
Obviously this is rather fraught with danger but many NAS deployments start this way; this agility leads to a long term fragility in the NAS deployment. A NAS deployment should actually be designed with as much care and attention as a traditional SAN.
It is also possibly fair to say that the NAS vendors have paid more attention to their management UIs than the traditional block storage vendors; they have worked to make it simple to configure and administrate. However, the block vendors are now catching up in the simplicity stakes.
So if block storage can be less complex, as flexible and as agile as NAS deployments; perhaps we can ignore NAS? But if we had ignored the challenges that NAS had brought to the traditional block model then we probably would not have seen the improvements which have reduced complexity, increased flexibility and agility in the world of block storage.
And with convergence at the network layer coming in the form of DCB; neither NAS or SAN storage can sit on their laurels. I wouldn’t ignore either as technologies in my data centre but I wouldn’t ignore RESTful storage or clustered file-systems either.
