(ヽ'ω`) < FSCTでWindowsファイル共有サービスのパフォーマンスを測定する - 概要-
(ヽ´ω`) < Windowsファイル共有のパフォーマンスを測定する
Windowsのファイル共有機能を提供する製品はいっぱいあるのだが、どの製品のどのランクのモノを選んでいいのかがわからない。パフォーマンスチューニングをしたのだが、どの程度の効果があるのかを測定したい。
そんな時には負荷テストを実施すると思うが、そんな時の助けになるのがこのツール。
(ヽ´ω`) < File Server Capacity Tool(FSCT)
Microsoftから提供されているWindowsのファイル共有機能に特化した計測ツール。
Download File Server Capacity Tool v1.2- (64 bit) from Official Microsoft Download Center
有名なのかそうじゃないのかよくわからなくて、Googleで検索しても日本語ページはほとんど引っかからず、hpのファイルサーバパフォーマンスに関するPDF文章で1件。
http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4AA3-8726jpn.pdf
英語のページを含めてもそんなに情報ソースが多く無い。使い方のソースになりそうなのが、Technetのページと本体に添付されている説明文章のみ。
あとはStorage Developer Conference 2008でMicrosoftの社員が作成したと思われる、プレゼン資料ぐらいか。
資料が少ないから調べるの大変そうだなー、と思っていたら本体添付の説明文章がかなり細かく書いてあるので、意外に楽だった。
(ヽ´ω`) < FSCTの特徴
ディスクパフォーマンスを測定するだけなら他にもいくつもツールが有るが、FSCTは以下の特徴を持っている。 (本体添付の説明文章、"Introducing FSCT"より)
実際のWindowsとWin32アプリケーションの挙動をシミュレートする
他のDiskストレスツールと比べて最も特徴的な点。
一般的なDiskストレスツールはひたすらファイルの作成や削除、コピーなどを繰り返し続ける。(複数の物理クライアントからの操作や、ファイルサイズの大小変更等の機能もあるが)
当然のことながら、このタイプのテストで発生する負荷は、実際にユーザが操作する際の挙動とはかけ離れている。
それに対してFSCTでは、Windowsでのファイル操作(コマンドライン・エクスプローラーからのファイル操作、Wordでのファイルオープン・セーブ・クローズ等)をシミュレートすることで、実際にユーザがWindowsを操作している時の挙動と同じような負荷をかける事ができる。
Workloadsと呼ばれるテストシナリオ機能
前項で実際のユーザの操作をシミュレートすると説明したが、実際にどのような操作が行われるかはWorkloadsと呼ばれるシナリオに沿って定義される。
どのようなサイズのファイルを使って、どういう操作を行うのか。その操作の時間あたりの頻度は。それらを記述したXMLとテキストファイルの集合がWorkloadsの本体となる。
FSCTでは"HomeFolders"という名前のWorkloadsが提供されている。これはユーザのホームディレクトリがファイルサーバに存在する場合を想定したシナリオとなっている。
FSCTで提供されているWorkloadsは"HomeFolders"だけだが、例えば
- 大きいファイルしか読み書きしない
- ファイルの読み込みだけで書き込みをしない
- ファイルのコピーしか行わない
というそれぞれのケースに合わせてWorkloadsを作成することで、自分の環境にマッチした系祖国を行うことができる。
1つの物理クライアントで複数のセッションを生成可能
ストレステストなので、リクエストを発行するクライアントPCはそれなりの台数が必要だが、10000台のクライアントを想定した環境で、実際に10000台のテスト用PCを用意することは
(ヽ´ω`) < 無理
FSCTでは1台のクライアントPC内に複数のユーザを作成し、それぞれのユーザからのリクエストをシミュレートすることができる。ファイルサーバの同時接続数の限界を測定するのに役に立つ。
詳細なレポート機能
FSCTでのテスト結果はテキストファイルで出力される。このファイルの中には
- スループット
- レイテンシ
- ネットワーク帯域
- OSのパフォーマンスカウンター(サーバ/クライアント両方)
等が含まれる。
更にEvent Tracing for Windows(ETW)のトレースデータとやらも出力可能とのこと。
ストレステストの場合、サーバ側の限界かと思っていたら、リクエストを送信するクライアントの限界だったというオチがあるので両方のデータが取得できるのは非常に便利。
テスト結果の出力例を引用すると
*** Results Users Overload Throughput Errors Errors [%] Duration [ms] 8000 0% 733 0 0% 181194 9000 0% 824 0 0% 181334 10000 0% 917 0 0% 180945 11000 19% 848 20 0% 203830 12000 200% 383 32 0% 216528
こんな感じで、上記の出力から察するにこのサーバの限界ユーザ数は10000～11000ぐらいと推測することができる。(Workloadsが適切に構成されていると仮定すると)
一度に複数パターンのユーザ数テストを行う事ができる
テストを行う際に、
- 最小ユーザ数
- 最大ユーザ数
- ユーザ増数
を指定することができる。
先ほどのテスト結果の例を再掲すると
*** Results Users Overload Throughput Errors Errors [%] Duration [ms] 8000 0% 733 0 0% 181194 9000 0% 824 0 0% 181334 10000 0% 917 0 0% 180945 11000 19% 848 20 0% 203830 12000 200% 383 32 0% 216528
とあるが、これは
- 最小ユーザ数 = 8000
- 最大ユーザ数 = 12000
- ユーザ増数 = 1000
でテストが行われたことがわかる。
ここで10000～11000あたりが限界とわかったので、次は
- 最小ユーザ数 = 10000
- 最大ユーザ数 = 11000
- ユーザ増数 = 100
として、条件を徐々に細かくしていくことで限界点を詳細に探ることができる。
(ヽ´ω`) < Warning！！
添付の説明文章にも特徴のすぐ後に書いてあるのだが、FSCTで行われるテストではボリュームのフォーマットが行われる。しかも事前確認なし。データが消える可能性がある。
If you use FSCT in a production environment, you risk unintentional data loss.
可能性というかフォーマットされたら確実に消えると思うのだが、兎に角、FSCTによるテストは導入時か移行時のみとし、現用の環境では行わないこと。
また、FSCTではADドメイン(あるいはWorkgroup)のパスワードを、クリアテキストでネットワーク上に流すため、可能な限り専用のネットワーク内で行うことをオススメする。
(ヽ´ω`) < 3つの登場人物
FSCTでは最低限3つの役割を演じるPCが必要となる。
Controller(コントローラ)
テスト全体を制御し、得られたデータを蓄積していくためのPC。
FSCTが動作するWindows OSが動作していなければならない。
Server(サーバ)
テスト対象となるWindowsファイル共有サービスが動作しているサーバー。
動作させるWorkloadsの内容によるが、FSCTに標準で用意されている"HomeDirectory"を使用するためには、ユーザ一人辺り100MBytesの要領が必要となる。
Windowsファイル共有サービスが動いていれば(CIFS/SMB)、非Windowsサーバ(殆どの場合はLinux+Sambaだと思うが)でもOK。その場合は、ディレクトリの作成やパーミッションの設定等の細かい設定を、手動で行っておく必要がある。
Client(s)(クライアント)
実際にサーバにリクエストを送るクライアントPC。
先に説明したとおり、1台のクライアントで複数のユーザリクエストをシミュレートが可能なのだが、サーバより先にクライアント側が悲鳴を上げないように、適切な台数を用意する必要がある。
それじゃあどうやってその適切な台数を導出するのか、という話だが、テストを行った際にクライアント側のパフォーマンスカウンターも取得できるというのは説明したとおり。この値を見て、クライアント側の負荷を計測する。もしもキツイようなら、クライアントの台数を増やす。
一つの目安として、添付の説明文章ではサーバのCPUコアの4倍の数だけ、クライアントのCPUコアを用意するべきと書かれている。
例えばサーバが4コア1CPUならば、クライアントは4コア1CPU4台、2コア1CPU8台、1コア1CPU16台と言った感じ。
ここからは推測になるのだが、Disk自体の性能ではなく、CPUのコア数で決定するということは、FSCTで行われるテストでは単純なDiskのI/Oの計測ではなく、サービスレイヤ(Windowsファイル共有サービス)でのスループット・アベイラビリティを計測することに主眼をおいているのではないかと。
クライアントではFSCTプログラムを走らせる必要があるため、コントローラ同様、Windows OSである必要がある。
DC(ドメインコントローラ)
AD環境でテストを行う場合は、当然ADのDCが必要となる。
FSCTでは非AD環境のWorkgroupでもテストを行えるため、必須ではない。
ただし、サーバが非Windows OSの場合はユーザの一括作成・削除のためにAD環境とDCが必要となる。(必須では無さそうだが、Workgroupで非Windows OSサーバでのテストは以下のように記載されているだけで、それ以上の情報がない)
There is not an easy way to run an FSCT test in a workgroup with a non-Windows server.
登場人物をまとめると
上記の3つの役割をまとめると以下の通り
| 名前 | 役割 | OSの制限 | 備考 |
|---|---|---|---|
| Controller | テストの全体的な制御とデータの取得を行う | Windowsのみ | |
| Server | テスト対象となるWindowsファイル共有サービス(CIFS/SMB)が稼働しているサーバ | 非Windows系OK | |
| Client(s) | Controllerから指令を受けて、Serverへのリクエストを送信する | Windows系のみ | サーバとクライアントのCPUコア数が1:4になるように台数を用意する |
(ヽ'ω`) < ここまで概要
FSCTの特徴と3つの登場人物ができたところで一旦区切り。
次はこの3つの登場人物を接続するためのネットワークについて説明し、実際にテストを行なっていく。
