我是一名开发人员……正在涉足陌生领域。请原谅我的幼稚。
我开发了一个将数据存储在数据库和文件系统中的应用程序。
背景：集群和网络共享
过去，当我们运行集群应用程序（即多个应用程序服务器处理数据）时，我们按如下方式处理文件系统：
- 节点 A ：共享“数据目录”（通过 samba 或 nfs）
- 节点 B、C、D 等：挂载“网络共享”并在其“数据目录”中使用它
降低节点 B、C、D 的“磁盘速度”不是最理想的，但并不是什么大问题。
另请注意：应用程序使用自己的文件锁定机制。并发写入不是问题。
问题
那么，在现代数据中心光纤通道将服务器连接到 SANS 中，在多台服务器之间共享“一块磁盘”的最佳方法是什么？
这种‘磁盘共享’被广泛使用吗？
任何特定于操作系统的问题（“适用于 Linux，但不适用于 Windows”）
有什么注意事项吗？难以配置、不可靠等？
我从我们的系统管理员那里听到了很多“我们不能这样做”的话。当我询问更多细节时，他们说“嗯，从技术上讲这是可能的，但这不是我们在这里的做法”
提前致谢，
更新：感谢大家的回答。（他们都很好：我不得不选一个。如果不是你的，我很抱歉）正如我（有点）预料的那样：我希望你可以简单地将 NTFS 或 XFS 或任何“常规”文件系统附加到同一块“磁盘”上，但事实证明这种希望是幼稚的。集群文件系统才是关键。而花哨的文件系统并不是我们托管团队的首要任务）。
答案1
“嗯，从技术上讲这是可能的，但我们这里的做法不是这样的”
这听起来很像我经常告诉开发人员的话；)
从企业运营的角度来看，您希望应用程序尽可能使用标准可重复的解决方案。如果您的应用程序不需要/保证特殊处理，那么您将无法获得它。非标准解决方案需要专业技能、更昂贵或更多设备，如果它是“最先进的”，故障通常也是灾难性的。
对于许多应用程序来说，（高可用性）文件共享仍然是一种非常合适且常见的解决方案。
使用文件共享的常见 HA 替代解决方案包括：
不要将文件存储在文件系统上，而是使用高可用性数据库并将它们存储为 BLOB。这是一种非常常见的方法。通常您本来就需要一个数据库，这使得应用程序服务器几乎无状态，通过将许多锁定、复制、HA、一致性和访问问题转移到数据库层来解决这些问题，其中许多问题都是旧闻，很容易理解和解决。但是，一旦达到（相当一部分）PB 范围，维护成本就会很高。
适当的集群文件系统，允许通过光纤通道或 iSCSI 对共享存储进行并发读写块级访问。企业存储阵列往往是相当昂贵但这可以很好地扩展。集群文件系统通常需要为每个节点的集群 FS 软件购买（昂贵的）许可。在企业环境中，对于专业应用程序来说，这也是相当常见的。
使用分布式对象存储。这是更开源的解决方案，使用低端商用硬件，在软件中创建冗余和可扩展性。这是一种常见的“云”方法。
答案2
如果您将多台服务器连接到共享块设备（DASD / SAN），则仍然需要手动管理对磁盘块的访问（某些数据库在原始磁盘上执行此操作，LVM 也是一个选项，具有托管 LV 访问）或使用集群文件系统来管理并发访问。
即使使用基于每个文件的写锁进行管理，如果两台主机尝试同时在非集群 FS 上执行 FS 元数据更改，您也可能遇到 FS 损坏。顺便说一句，这没什么现代的，SAN 和并发块访问自 80 年代（如果不是 70 年代）以来就已经存在了。
所有现代操作系统都具有集群 FS 实现，如果您愿意自己编写所有内容，那么块块隔离也是可能的，因此它非常具体地取决于您打算使用的内容。
编辑：您的“旧”网络共享方法仍然非常可行，文件服务器将负责文件锁定，因此您不需要额外的锁定机制。如果您不追求额外的性能并且想要简单的部署，那么它可能仍然是最简单的途径。
现在，如果您想谈论“现代”，请开始考虑对象存储和扩展应用程序的架构。
答案3
您不仅需要共享硬件，还需要集群文件系统。
常规文件系统无法工作——两台计算机最终会覆盖彼此的更改，最终导致文件系统损坏。
集群文件系统让所有计算机互相通知他们所做的更改，并在需要时处理锁定文件，以免互相干扰。
其中一些文件系统是特定于应用程序的 - 例如 VMware 有 VMFS，而 Hyper-V 有群集共享卷 - 它们非常适合存储虚拟机，但并非用于通用文件存储。还有一些文件系统旨在存储任何文件。每种文件系统都有各种优点和缺点，因此哪种文件系统最好在很大程度上取决于您要用它做什么。据我所知，它们都是特定于操作系统的 - 您无法通过这种方式在 Windows 和 Linux 之间共享文件系统。
对于高可用性虚拟机故障转移等情况，您确实需要此功能。对于可以使用 SMB 或 NFS 的应用程序，它们通常是首选 - 它们可能稍慢一些，但出错的可能性要小得多，而且一旦发生故障，恢复起来也更容易。