Windows Server 2016 的故障轉移群集文件伺服器性能問題
我最近在 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 中配置，獨立於交換機），每個包含兩個 1Gbit 連接。
- 實際使用的儲存是兩台機器都通過 iSCSI 訪問的 Synology，使用這些說明進行配置。
- 其他一切似乎都工作正常，就像模擬故障轉移工作和其他節點在幾秒鐘後接管一樣。
我猜這是“對任何比我了解更多的人都顯而易見”的情況之一。或者也許我只是希望如此。無論哪種方式，我都感謝任何指導！我盡量保持簡短，所以如果您需要任何其他資訊，請告訴我。
提前致謝。
在移除 NIC 組合併將 Synology/Server 上的連接放置在不同的子網上後，我仍然沒有看到性能提升。
不過，我終於遇到了解決方案。事實證明，共享的持續可用性（預設設置）是罪魁禍首。有文件說它可能會由於繞過寫入記憶體而導致“輕微”性能損失（如此處），在某些情況下，“輕微”性能損失似乎實際上是“巨大的”。這是一篇關於持續可用性的非常有用的背景文章以及您何時可能想要使用它（總而言之，如果您的共享配置為“通用文件伺服器”並且您擔心，您可能希望將其關閉）表現）。
因此，長話短說，我在集群使用的共享上禁用了持續可用性，重新啟動了兩台伺服器以進行良好的衡量，性能問題得到了解決。雖然我更願意在故障轉移事件期間保證數據完整性，但在我的環境中這些將如此之少而且相距甚遠，毫無疑問，性能損失是不值得的。
您的第一個問題是為 iSCSI 組合的 NIC。你永遠不會這樣做，除非你的目標和發起者都支持每個會話的多個連接，並且在你的情況下它們都不支持。
http://scst.sourceforge.net/mc_s.html
解決方案：您必須解組您的 NIC 並使用 MPIO。
您的第二個問題是 Synology 本身。它不是您用於主記憶體儲的東西，它充其量只是備份單元。
解決方案：您將內容複製到本地磁碟並使用 Synology 作為備份儲存庫或其他任何東西。