存储解决scheme（<10TB）最初只需要几TB的空间。
我最初的计划是让NAS和其他服务器一起安装存储在NAS设备上的数据，并从中推送和提取数据。 因为这将是一个小的部署，SAN的成本是不合理的，到目前为止，增长预期还不得而知。 所以这将是NAS的使用，但它需要是可扩展的。
我看到这个devise有一些问题，
首先; 在安装了相同数据存储的多台服务器上，SMB / CIFS不太合适，NFS在这里似乎是一个更好的select。 虽然，据我所知，这是我唯一的select。 这将是一个本地的Linux部署，除NFS之外，还有更好的协议可用吗？还是我唯一的select呢？
其次; 由于NAS设备的I / O容量或空间不足，先到先得，另一个将不得不被添加（这个过程将重复）。 如何将另一个NAS放到networking上并扩展现有的存储共享（就其他服务器而言），以包含这个额外的存储空间？ 在SAN中添加另一台存储主机的“NAS等效”是什么，并在其上扩展文件系统？ （据我所知，这是不可能的，但我问，如果我错了！）。
假设我在上面的场景中描述过，一旦第一个NAS处于满负荷状态，就是SAN的基本要求，这是正确的吗？ 更可扩展的方法是添加另一个NAS，让服务器安装两个存储共享，并且让应用程序支持使用多个存储空间，而不是试图实现不断增长的存储空间？
SMB / CIFS对安装了相同数据存储的多台服务器来说是完美的。 这是一个大量的并发文件系统，尽pipe速度比NFS慢，延迟也比较高，但可以很好地处理大量的并发连接。 更大的担心可能是用户访问，因为与NFS相比，所有到CIFS安装的stream量都将作为对安装进行身份validation的用户进行传输。 一般来说，我认为NFS是服务器 – 服务器文件共享更强大的解决scheme。
如果您计划在单个命名空间中实现可扩展性，则扩展比扩展要便宜得多。 大多数供应商将提供某种基于SAS的磁盘arrays解决scheme。 这些通常是菊花链式连接的，您可以使用LVM或类似的卷pipe理器在它们之间运行单个连贯的文件系统（请记住，如果一个磁盘架失败，将会损坏整个卷，因此您可能需要多个path存储）。 这可能是您最具成本效益的解决scheme，但有很多select。 你select的文件系统很重要，所以记住这一点。 我是Solaris 11上ZFS的粉丝，但如果您致力于使用免费软件解决scheme，则您的select更加多样化。
如果你在扩展的时候遇到了问题，那么Gluster和Ceph就有很多并行的文件系统，但是它们的成熟度和兼容性都是不同的，我不会推荐它们在这个通用的文件共享上点。
如果您使用iSCSI，则可以将您的NAS变成SAN。 之后，将其与cLVM和ocfs一起使用，以便在您的系统上同时安装它。 cLVM将为您提供灵活性来随意扩展。