Windows Server 2016でのフェールオーバークラスターファイルサーバーのパフォーマンスの問題
最近サーバー2016で構成したフェールオーバークラスターで興味深いファイルサーバー転送速度のパフォーマンス問題に遭遇しました。特定の問題は、クラスター化されたストレージパス（例：\\ store01\share01）のファイル転送からファイル共有にアクセスする場合ですスピード（特に書いているようです）は方法ですが、wayは、現在の所有者ノードのローカルパス（たとえば、\\ 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 /分
これは、現在の所有者ノードやデータの転送元に関係なく問題です。当時はフォローしていませんでしたが、多かれ少なかれ このガイド に示されているようにサービスをインストールして構成しました。いくつかの設定をいじってみましたが、（私の知る限り）すべてデフォルトに戻りました。少し調べてみましたが、フェイルオーバークラスターの使用に関する大きなパフォーマンスの問題について具体的に言及しているものは何も見つからなかったため、ランダムな調査を行って、それを示すものはあまりありませんでした。
関連する可能性のある構成に関するいくつかのこと：
- クラスタには現在2つのノードがあります。どちらもServer 2016を実行しており、どちらも2つの1Gbit接続で構成される2つのNicチーム（Windowsで構成され、スイッチに依存しない）を持っています。
- 使用されている実際のストレージは、両方のマシンがiSCSI経由でアクセスするSynologyで、 これらの手順 を使用して構成されています。
- 他のすべては、フェイルオーバーのシミュレーションが機能し、他のノードが数秒後にかかるように、正常に機能しているようです。
これは、「私よりも多くのことを知っている人には自明」な状況の1つだと思います。または多分私はそれを望んでいるだけです。いずれにせよ、私はどんな指導にも感謝します！できるだけ短くしたので、他に情報が必要な場合はお知らせください。
前もって感謝します。
NICチーム化を削除し、適切な測定のために別のサブネット上のSynology/Serverに接続を配置した後も、パフォーマンスの向上は見られませんでした。
しかし、ようやく解決策に出会いました。共有の継続的可用性がオン（デフォルト）であることが原因であることがわかりました。書き込みキャッシュをバイパスするため、「わずかな」パフォーマンスペナルティ（ ここのように ）が発生する可能性があると記載されているドキュメントがあります。場合によっては、「わずかな」パフォーマンスペナルティは実際には「巨大」であるようです。以下は article です。これは、継続的可用性に関するかなり役立つ背景と、それを使用する場合（要約すると、共有が「汎用ファイルサーバー」用に構成されている場合はオフにする必要がある場合があります。 "そしてあなたはパフォーマンスに関心があります）。
つまり、要するに、クラスターで使用されている共有の継続的可用性を無効にし、両方のサーバーを適切に再起動して、パフォーマンスの問題を解決しました。フェールオーバーイベント中のデータの整合性を保証するためにこの機能をオンにしたいのですが、環境内でこれらが非常に少ないため、パフォーマンスのペナルティがそれに値しなかったのは間違いありません。
最初の問題は、iSCSI用にチーム化されたNICです。ターゲットとイニシエーターの両方がセッションごとに複数の接続をサポートする場合を除き、これを行うことはありません。
http://scst.sourceforge.net/mc_s.html
解決策：NICのチームを解除し、MPIOを使用する必要があります。
2番目の問題はSynology自体です。これはプライマリストレージに使用するものではなく、最高のバックアップユニットです。
解決策：コンテンツをローカルディスクにコピーし、Synologyをバックアップリポジトリなどとして使用します。