windows server NWでのファイル共有が遅い場合
あけましておめでとうございます。2018年ですね。今年はwindowsを多く触ることになりそうなので、windowsネタが多くブログに上がることになりそうです。今年一年が充実したものになるといいですね。
で、今回はwindows serverでのトラブルシューティングです。正直、まだバージョン間の違いとか全然分かってないので、一つ一つ丁寧に学んでいければと思います。
WAN越しのファイル共有が遅い場合の検討事項
インターネットVPN（WAN越し）でファイルサーバへアクセスした場合のファイルオープンが遅い 場合の対応です。
環境はファイルサーバとしてwindows server2003、WANはギガビット回線 を利用したインターネットVPN インターネットは問題ないが、ファイル共有のみが遅いようで、1MB程度xlsファイルをオープンしようとすると 大体1分程度はかかるとのお話。 一般的にWAN経由の場合、ファイル共有はその他のプロトコルと比較して遅いことがほとんどです。 原因はファイル共有の利用するCIFSプロトコルにあり、WAN経由でやりとりを行うには、CIFSプロトコルは 転送先とのやりとりが非常に多く、TCPのような通信の確実性を担保している通信では、相当なパフォーマンスダウン となります。
特にWindows Server2003までのCIFSは古いSMB（1.0）を利用しており、その遅さが顕著になるようです。
windows7/windows server2008ではバージョンアップしたSMB2.0、2008 R2ではSMB2.1の 実装となります。windows8、Server2012以上だとファイルのやり取りを、さらにバージョンアップしたプロトコル SMB3.0を利用するので、1.0/2/0よりパフォーマンスが確保できるとの情報もありましたが、それも劇的に パフォーマンスアップを図るのは難しいです。
実際にテストしてみると、やや速いように感じるものの、全体のボトムアップという点では、疑問符が残る 結果でした。もちろんプロトコル以外にも原因がある可能性もありますので、具体的な調査方法について 検討してみます。
速度ボトルネックの調査
ファイルオープン（SMB）が遅いのか、他のプロトコルも全て遅いのかを確認します。 例えば、同じ容量のファイルをコピーする時間と、FTPでファイルをアップロードする時間を 比較検討します。
両方遅い場合、回線に問題があると判断ができます。（回線自体は速度が出ているため、可能性は低 い）
ファイルオープンのみが遅い場合→SMBのやり取りに問題があると判断できます。 今回合致するのはこの可能性が高そうです。
仮にファイル共有が遅いと判明した場合はファイル共有に絞って調査を行います。
今回はCIFS（SMB）が潜在的にもつ問題であると仮定して、対策を検討しました。 以下のような対策で効果が期待できます。
- ファイルサーバをwindows server2012以上にアップグレードするファイルサーバをwindows server2012以上にアップグレードする SMB3.0で通信を行うことにより、ファイル共有の速度をアップします。
- Branch Cacheを利用する
Windows Server2008から実装されているBranch Cache機能を利用します。 Branch Cacheは拠点側にファイルサーバのファイルキャッシュを持ち、通常はキャッシュへアクセス することで速度を確保する方法です。クライアント（分散キャッシュモード）でもサーバ（ホスト型キャッシュモード）でも実装が可能ですがクライアント（分散キャッシュモード）でもサーバ（ホスト型キャッシュモード）でも実装が可能ですが 信頼性を考えると、サーバへキャッシュを配置した方がよさそうです。 マイクロソフトではクライアントが50台以下の台数を分散キャッシュモードの閾値とアナウンスしており、 50台以上の場合はホスト型キャッシュモードを推奨するとのこと。 riverbedやF5、CISCOなどのベンダーから様々な種類のWAN回線最適化アプライアンスが リリースされており、ニーズに合わせて選定することが可能です。
まとめ
現在、windows server2003を実行している環境は殆ど無いと思いますが、もし2003を運用しているのなら、 ファイルコピー遅延は、windows2000ベースのドメインコントローラのスレッド優先順位付けの間の相互作用の結果です。
ドメインコントローラは変更通知要求への応答などのSMB処理よりディレクトリサービスとアカウント管理操作 を優先します。
このネットワークパフォーマンスの低下の問題は、クライアントが多くのファイルをドメインコントローラに コピーした場合にのみ発生します。遅延ACKタイマの値を変更すると、いくらか現象の発生を抑制することが できますが、コアTCP/IP値を変更すると、将来予測しない結果が発生する可能性があります。
そのため、マイクロソフトではタイマを変更する前に他の代替案を考えることをおすすめしています。 その他の解決方法はXcopyやwindows2000リソースキットに含まれるRobocopyなどを使用することが挙げられます。 ドメインコントローラでTcpDelAckTicksレジストリ値をを編集することでTCP遅延ACKタイマを調整できます。 TCP遅延ACKタイマを低い値に変更すると、サーバは短い間隔で頻繁にACKパケットを送信するようになります。
遅延が大きく、かつ著しく飽和したセグメントでは、ドメインコントローラからのACKパケットの増加によってネットワークにさらに負荷がかかることになる可能性があります。変更したTCP遅延ACKタイマの値がさらなるボトルネックの原因とならないようにす るために変更点は十分にテストする必要があります。
