Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Initially only a few TBs of space is needed for a storage solution (<10TBs).

My initial plan is to have a NAS with other servers mounting the data stored on the NAS device, pushing and pulling data from it. Because this will be a small deployment the cost of a SAN can't be justified, and growth expectancy is unknown as of yet. So it will be NAS to being with, but it needs to be expandable.

I see a few problems with this design though;

Firstly; SMB/CIFS is not a good with multiple servers having the same data store mounted, NFS seems like a better option here. Although, as far as I know it's my only option. It would be a native Linux deployment, so are any better protocols available to me other than NFS, or is that my only choice here?

Secondly; As the NAS device gets short of either I/O capacity or space, which ever comes first, another will have to be added (and this process will repeat). How can I drop another NAS onto the network and extending the existing storage share (as far as the view from the other servers is concerned) to include this addition storage space? What is the "NAS equivalent" of adding another storage host in a SAN, and expanding the file system across it? (As far as I know this isn't possible, but I'm asking in case I'm wrong!).

Presumably what I have described in the scenario above, once the first NAS is at capacity, is the basic requirement for a SAN, is this correct? Would a more scalable approach be to add another NAS, and have the servers mount both storage shares, and have the application support the use of multiple storage spaces, rather then trying to implement an ever growing storage space?

share|improve this question
What kind of budget do you have for this project? –  Craig Feb 6 '12 at 21:44
add comment

2 Answers

up vote 2 down vote accepted

SMB/CIFS is perfectly fine with multiple servers having the same data store mounted. It's a plenty concurrent file system that, despite being slower and higher-latency than NFS, will deal just fine with a good number of concurrent connections. The bigger concern may be user access, since all traffic to your CIFS mount will go across as the user that authenticated the mount, in contrast to NFS. In general, I do consider NFS the more robust solution for server-server file sharing.

If you're planning for expandability in a single namespace, it's much cheaper to scale up than scale out. Most vendors will provide some kind of SAS-based disk array solution. These can typically be daisy-chained, and you can run a single coherent filesystem across them using LVM or a similar volume manager (keeping in mind that if one disk shelf fails it will trash your entire volume, so you probably want multiple paths to your storage). This is probably the most cost-effective solution for you, but there's a ton of options. Your choice of filesystem does matter, so keep that in mind. I'm a fan of ZFS on Solaris 11, but your choices are more diverse if you're dedicated to using a free software solution.

If you're dead-set on scaling out, there's a number of parallel filesystems like Gluster and Ceph out there, but they're at varying degrees of maturity and compatibility and I wouldn't recommend them for general-purpose file sharing at this point.

share|improve this answer
GlusterFS is quite popular and stable; I wouldn't rule it out so quickly. That combined with ZFS can deliver a pretty robust, deduplicated storage setup. –  gravyface Feb 6 '12 at 22:45
add comment

If you use iSCSI you can turn your NAS into a SAN. After that use it with cLVM and ocfs to concurrently mount it on your systems. cLVM will give you the flexibility to expand at will.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.