我遇到了一个有趣的文件服务器传输速度性能问题，我最近在Server 2016中configuration了一个故障转移群集。具体问题是，当我从群集存储path（例如\\ store01 \ share01）访问文件共享时，文件传输速度（特别是写入，似乎）比当我通过当前所有者节点上的本地path（例如\\ 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 /分钟
无论当前所有者节点或数据从何处传输，都是一个问题。 虽然我当时没有遵循，但是我多less已经按照本指南的指示安装和configuration了服务。 我尝试了几个设置，但他们都回到默认（据我所知）。 我查了一下，没有发现任何特别提到使用故障转移群集的巨大性能问题，所以我一直在做一些随机的研究，没有太多的展示。
关于configuration的一些事情可能是相关的：
我猜这是对那些比我知道的人更为明显的情况之一。 或者也许我只是希望这一点。 无论哪种方式，我感谢任何指导！ 我试图保持简短，所以请让我知道，如果你需要任何其他信息。
提前致谢。
你的第一个问题是网卡联合iSCSI。 你永远不会这样做，除非你的目标和发起者支持每个会话多个连接，在你的情况下，他们都没有。
http://scst.sourceforge.net/mc_s.html
解决scheme：你必须解除你的网卡，并使用MPIO。
你的第二个问题是Synology本身。 这不是你用于主存储的东西，它最好是备份单元。
解决scheme：您将内容复制到本地磁盘，并使用Synology作为备份存储库或其他。
除去网卡绑定，并将连接放置在不同子网上的Synology / Server上后，我仍然没有看到性能改进。
不过，我终于遇到了这个解决scheme。 事实certificate，持续可用性（默认）是共享的罪魁祸首。 有文件说，由于绕过写caching，可能会导致“轻微”的性能损失（ 如这里 ），但在某些情况下，“轻微”的性能损失实际上是“巨大的”。 这里有一篇关于持续可用性的非常有用的背景文章 ，以及何时可能需要使用它（总而言之，如果您的共享configuration为“常规使用文件服务器”，则可能需要closures它，而您关心的是性能）。
因此，简而言之，我对集群正在使用的共享禁用“连续可用性”，重新启动两台服务器，以确保性能问题得到解决。 虽然我更愿意在故障转移事件期间保证数据的完整性，但是在我的环境中，这种情况会非常less，因此毫无疑问性能损失是不值得的。