【Ask the Expert】エキスパートに聞こう！Unisphere(Navisphere)Analyzerの数値を読み解く！

すみません初歩的なことかもしれませんが確認させてください。

1.SP CacheのForced Flushesでよろしいのでしょうか？

　（これはFAST Cacheが2次Cacheなので１次Cacheがあふれなければ２次キャッシュの構成も十分という認識でよろしいでしょうか）

2.添付画面の通りなのですが、"SP Cache Forced Flushes/s"が項目にないのですが、現在は”SP Write Cache Flushes/s”という項目に変わったのでしょうか

よろしくお願いいたします。

AnalyzerのSPで "SP Cache Forced Flushes/s" と LUNの "Response Time" を確認してみてください。

Forced Flushがなく、LUNのResponse Timeの平均が低い場合(十数ミリ/s)にはFAST CACHEは充分な構成であると考えられます。

上記条件であれば上位側での要求が200IOPSに対して、Diskに要求されるIOPSは300 IOPSとなります。

なお、ディスクIOとSP IOの差でキャッシュヒット率を算出するのは困難です。
Pool Base LUNの場合には、Slice(1GB)の集合で構成されますのでDataの配置を管理するMeta Dataが存在します。
このMeta DataもUser Dataと同様の”Data”としてCache上で管理されます。それほど多いIO数ではありませんが
このMeta Dataの書き込みもWriteとしてDisk IOに反映されてしまいますので、IOカウントからキャッシュヒット率
を計算することは難しいと考えられます。

失礼しました。

Analyzerの LUN で”SP Cache Forced Flushes” です。

非常に初歩的な質問になってしまいお恥ずかしいのですが、

Analyserログファイルが複数ある場合の結合する手間を減らす方法をご教授頂けないでしょうか。

「Merge」で行う方法は知っているのですが、この方法では１つ１つ順番に結合する必要があり、

多くのファイルを結合しようとするとかなりの手間となっているので解消したく。

以前、EMCの方にはあきらめなさい、とは言われたのですが、

もし何か手間を減らす方法があるのであればお願いします。

残念ながらAnalyzerはGUIもCLIも2つのファイルのMergeしかできないので、スクリプトを組むか地道にMergeするかになります。

ちなみにCLIのコマンドは以下のようになります。

naviseccli analyzer -archivemerge -data < archive2> [-out outputarchive] [-overwrite y |n]

パフォーマンスの考察にあたり質問があります。

Clarix 及び BVNX(Block)のパフォーマンスデータを確認するにあたり、

主にThrouput, Bandwidth, Utilization , Queue 及びそれに伴うResponse Timeの変化が主な確認ポイントになると考えておりますが、これらの変化から、ある程度　原因の推察はできないでしょうか？

例えば、普段の同じ時間帯に比べてResponseTime及びその他4項目が下記のようであった場合

Response Time：            普段に比べて高い

Throuput：        普段に比べて高い

Bandwidth：     普段に比べて高い

Utilization：      普段に比べて高い

Queue  普段に比べて高い

この場合は、上位側から普段と違う量・大きさのI/Oが来たためResponseが悪くなったと思われる。普段と違う処理が入っていないか確認

とか

Response Time：            普段に比べて高い

Throuput：        普段通り

Bandwidth：     普段通り

Utilization：      普段通り

Queue  普段に比べて高い

この場合は、Storage内部処理が普段に比べて多くなった　つまり、

・SP- Disk間でRetryしていることが考えられる

・snapとの同期がされていることが考えられる

等、

単純に原因が特定はできないかとは思いますが、

代表的な、Storage構成が起因する例・Storage 側の処理が起因する例

上位側の構成・処理が起因する例等、

どこから疑うべきかの指針となるような代表的なパターンご教授いただけると幸いです。

まず、各ParameterはSP / LUN / Diskで計測されています。
ご質問の内容は ”LUN”　のResponse TimeとQueue Lengthが通常より高いという状況だと解釈させたいただきます。

LUNはTrespassやRedirectorによりSP-AとSP-Bの両方で使用される場合がありますが、
ここではそのようなことはなく、-Optimal(OwnerSP)がSP-AかSP-Bに固定され、-NonOptimal(Non-OwnerSP)の値は

全てゼロであると仮定します。

まず、Response Timeとは”処理待ちの時間を含めたコマンドを処理する時間の平均”ということになるのですが、式としては
Response Time = Queue Length x Service Time
となります。

Queue Length　：　IO処理されるのを待っているコマンド数の平均
Service Time　：　1つのIOを処理するのにかかる時間　(Response Timeとは異なり、待ち時間は含まない)

QueueはFIFO(Fast In Fast Out)で処理されますので、例えばQueue Lengthが10の状態の最後のコマンドは
前の9個が処理された後に処理されます。Service Timeは1つのコマンドを処理するのにかかる時間ですから、
Response Time = Queue Length x Service Time
となります。

－Service Time－
Throughput(IOPS)は1秒間で処理したIO数です。これに対してService Timeは”1つのコマンドを処理するのにかかる時間”です。
ということは、Utilizationが100%の場合には　Service Time = 1 / Throughput　となります。

Utilizationは、IO処理を行っている時間とIO処理を行っていない時間との比率となります。
Utilizationが20%の場合には、その計測単位時間(60s)のうちの20%の12秒間でIO処理をしていたことになります。
Service Timeは1つのIOを処理するのに要する時間ですからIO処理していた時間(Utilizationでカウントされている時間)だけを
考えればいいことになりますのでService Time = Utilization / Throughput　となります。

例)　100 IOPS ： Utilization 20%の場合
　　 --> 60秒間で処理されたIOはIOPS x 60sですから　100 x 60 = 6000 IO
　　 Utilizationが20%ですから、実際に処理を行っていた時間は60s x 20% = 12s
　　 よって Service Time = 処理していた時間 / IO数 = (Utilization x 計測時間) / (Throughput(IOPS) x 計測時間)

　　　　　　　　　　　　　　   (= 12 / 6000 = 2ms)
　　　　　　　　　　　　 　　　分子・分母を約分すると
　　　　　　　　　　　　 　　　= Utilization / Throughput(IOPS) = 20% / 100 = 2ms

－Queue Length－
Queue Lengthは”IO処理されるのを待っているコマンド数の平均”です。
Queue Length = (Average Busy Queue Length) x Utilization　となります。
Average Busy Queue LengthとはIO処理を行っている最中のQueue Lengthとなり、Utilizationでカウントされている時に

IO処理されるのを待っているコマンド数の平均となります。
これに対してQueue Lengthは計測の単位時間全体で考えた処理待ちコマンド数となります。

Response Time = Queue Length x Service Time　の式より今回のケースで考えた場合、2パターン考えられます。

(1) Service Timeが普段と同じ場合

Service Timeが固定されているのであればResponse Timeの上昇はQueue Lengthの上昇ということになります。
Queue Length = (Average Busy Queue Length) x Utilization　で、Utilizationは普段と変わらないということですから
Average Busy Queue Lengthがあがっていると考えられます。

IOPSも普段と変わらないということですので、60秒という計測単位時間で処理されたIO数は同じです。
Bandwidth(MB/s)も普段と変わらないということですからIO Sizeも同じと考えられます。
処理されたIO数が同じでAverage Busy Queue Lengthがあがるのはどのような時なのかというと
IOリクエストが平均的ではなくまとめてくるように変更された場合、IO Sizeの大きなものを使用するように変更された場合などが

考えられます。

(2) Service Timeが普段より高い場合

Service Time = Utilization / Throughput　で、UtilizationもThroughputも普段と同じとのことですService Timeが
上昇することはLUNレベルでは考えられません。

ということで、このケースでは普段よりもまとめてIOがくるようなバースト的IOパターンになっていたと考えられます。

ご回答ありがとうございました。

もっと簡単に場合分けできるもんかと思っていたんですが、

同じ値でも、もっと細かい項目によって原因が大きく違うんですね。

mergeの件、ご回答有難うございます。

小いさなことではあるんですが、

大量のデータが届くたびにマージしているとツライものがあったのでご質問させて頂きました。
今後も修行と思って地道にマージします。

Analyzerで確認できる状況の判断指針について記述されている資料は公開されていないのでしょうか。

当方はCLARiX時代（CX2時代）のパフォーマンスワークショップに参加したきりの知識なのですが、

最新のVNXや特にSSDやFAST Cacheについての値はどう判断すべきなのか把握したいと考えています。

当然、最新のパフォーマンスワークショップに出席すれば入手可能な情報なのかもしれませんが、

Monitoring and ReportやStorage Analyticsなどのパフォーマンスモニタリングツールがいくつもリリースされ、

一般ユーザでも確認可能な状況なので公開資料が無いものかと思い、ご質問させて頂きます。

Analyzerの各値に対する判断指標というのは明確なものはありません。
Applied Best Practices Guide: EMC VNX Unified Best Practices for Performance
のEssential Guidelinesに各HardwareレベルでのUtilizationを70%以下としてくださいと記載があるくらいです。
Link :
https://support.emc.com/docu42660_Applied-Best-Practices-Guide:-EMC-VNX-Unified-Best-Practices-for-Performance.pdf

どこまで許容するのかは、お客様の要件によって異なりますので明確に定義することは困難です。

Analyzerの各パラメータについてですが、まずはUnisphere のHelpで ”Performance Characteristics”を参照してみてください。
各パラメータの意味が記載されています。
他にもUnisphere Help内の
－Troubleshoot performance metrics
－Workload characteristics
などは参考になると思います。

まだ判断指標は無いですか・・・

世間の状況的に「何をもって正常と判断する」と言う話が増えているので期待したのですが、残念です。

（この点、VMware社のvCopsは優秀でして、

　そのOEMのStorage Analyticsも同じく何がしかの判断で健全性を計ってます。

　これが解明できればなぁ、と思った次第です。）

ヘルプはこれからも参考にしたいと思います。

昔お客様でAnalyzerの数値が一時飛躍的に高くなった・・・という方がいたのですがこの場合はいったいどういうことだったのでしょうか。どの数値がどれくらい。。といった記憶が定かではないのですがパフォーマンスが悪くなったという体感はまったくないのにそんな状況はありうるのでしょうか。