我最近在 Server 2016 中配置了一个故障转移群集，遇到了一个有趣的文件服务器传输速度性能问题。具体问题是，当我从群集存储路径（例如 \\store01\share01）访问文件共享时，文件传输速度（特别是写入速度）似乎非常快，方式比我通过当前所有者节点上的本地路径访问它时慢（例如\\srv04\e$\Shares\Share01）。
例如，我使用 Robocopy 复制了 499 个 .txt 文件（总计 26.07 MB）：
\\srv04\e$\Shares\Share01：0:0:03 - 635 MB/分钟
\\store01\share01：0：02：20 - 11.286 MB/分钟
无论当前所有者节点是什么，也无论数据从哪里传输，这都是一个问题。虽然我当时没有关注它，但我或多或少按照指示安装和配置了服务本指南。我尝试过修改一些设置，但它们都恢复为默认设置（据我所知）。我四处查看了一下，没有发现任何特别提到使用故障转移群集会导致严重性能问题的内容，因此我进行了一些随机研究，但没有什么结果。
关于配置可能相关的一些事项：
- 集群目前有两个节点。两个节点都运行 Server 2016，并且都有两个 Nic Teams（在 Windows 中配置，独立于交换机），每个 Nic Teams 由两个 1Gbit 连接组成。
- 实际使用的存储是两台机器都通过 iSCSI 访问的 Synology，配置为这些说明。
- 一切似乎都运行良好，就像模拟故障转移一样，另一个节点在几秒钟后接管。
我猜这是“对任何比我懂得多的人来说都是显而易见的”那种情况。或者也许我只是希望如此。无论如何，我都很感激任何指导！我尽量简短，所以如果您需要任何其他信息，请告诉我。
提前致谢。
答案1
第一个问题是为 iSCSI 而组队的 NIC。除非目标和启动器都支持每个会话多个连接，否则您永远都无法做到这一点，而您的情况是，它们都不支持。
http://scst.sourceforge.net/mc_s.html
解决方案：您必须解除 NIC 组合并使用 MPIO。
第二个问题是 Synology 本身。它不是您用来做主存储的设备，最多只能算是备份设备。
解决方案：您将内容复制到本地磁盘并使用 Synology 作为备份存储库或其他。
答案2
在移除 NIC 组合并将 Synology/Server 上的连接放置在不同的子网后，我仍然没有看到性能改善。
不过，我最终还是找到了解决方案。事实证明，共享的持续可用性处于开启状态（默认）是罪魁祸首。有文档称，这可能会导致“轻微”的性能损失（像这儿)，由于绕过了写缓存，在某些情况下，似乎“轻微”的性能损失实际上是“巨大的”。下面是一个文章这涉及到有关持续可用性的非常有用的背景知识以及何时可能需要使用它（总而言之，如果您的共享配置为“通用文件服务器”并且您担心性能，则可能需要将其关闭）。
长话短说，我禁用了集群使用的共享上的持续可用性，重新启动了两台服务器，性能问题得到了解决。虽然我更愿意在故障转移事件期间启用它以保证数据完整性，但在我的环境中这种情况很少见，因此毫无疑问，性能损失是不值得的。