最初，存储解决方案只需要几 TB 的空间（<10TB）。
我最初的计划是使用 NAS，其他服务器装载存储在 NAS 设备上的数据，并从中推送和提取数据。由于这将是一个小型部署，因此 SAN 的成本无法证明，而且目前还不知道增长预期。因此它将是 NAS，但它需要可扩展。
但我发现这个设计存在一些问题；
首先，对于安装相同数据存储的多台服务器，SMB/CIFS 并不适用，NFS 似乎是更好的选择。不过，据我所知，这是我唯一的选择。这将是原生 Linux 部署，那么除了 NFS 之外，还有其他更好的协议可供我使用吗？或者这是我唯一的选择？
其次，当 NAS 设备缺少 I/O 容量或空间（以先到者为准）时，必须添加另一台 NAS（并且此过程将重复）。我如何将另一台 NAS 放入网络并扩展现有存储共享（就其他服务器的视图而言）以包含此附加存储空间？在 SAN 中添加另一台存储主机并在其上扩展文件系统的“NAS 等效”是什么？（据我所知这是不可能的，但我还是问一下以防我错了！）。
假设我在上面描述的场景中，一旦第一个 NAS 达到容量上限，这就是 SAN 的基本要求，对吗？更具可扩展性的方法是添加另一个 NAS，让服务器安装两个存储共享，并让应用程序支持使用多个存储空间，而不是尝试实现不断增长的存储空间？
答案1
SMB/CIFS 非常适合多台服务器安装相同的数据存储。它是一个并发性很强的文件系统，尽管比 NFS 速度慢且延迟更高，但可以很好地处理大量并发连接。更大的问题可能是用户访问，因为与 NFS 不同，所有到 CIFS 挂载的流量都将作为验证挂载的用户进行传输。总的来说，我确实认为 NFS 是服务器间文件共享的更强大的解决方案。
如果您计划在单个命名空间中实现可扩展性，那么纵向扩展比横向扩展要便宜得多。大多数供应商都会提供某种基于 SAS 的磁盘阵列解决方案。这些通常可以菊花链连接，您可以使用 LVM 或类似的卷管理器在它们上运行单个连贯的文件系统（请记住，如果一个磁盘架发生故障，它将破坏整个卷，因此您可能需要多条存储路径）。这可能是最具成本效益的解决方案，但有很多选择。您对文件系统的选择确实很重要，所以请记住这一点。我是 Solaris 11 上 ZFS 的粉丝，但如果您致力于使用免费软件解决方案，您的选择会更加多样化。
如果您执意要进行横向扩展，那么有许多并行文件系统可供选择，例如 Gluster 和 Ceph，但它们的成熟度和兼容性各不相同，因此目前我不建议将它们用于通用文件共享。
答案2
如果您使用 iSCSI，则可以将 NAS 变成 SAN。之后，将其与 cLVM 和 ocfs 一起使用，以同时将其安装在您的系统上。cLVM 将为您提供随意扩展的灵活性。