Highlighted
4 Beryllium

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

ありがとうございます。

RAID LUNで”SP Cache Forced Flushes”を確認できました。


しかしPool LUNの場合はありませんでした。

やはり現在のVNXのAnalyzerですとPool構成で組んだ場合、キャッシュに関する情報を取得して

調査を行うのはかなり難しいようです。


以上

返信
Highlighted
4 Tellurium

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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

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

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

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

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

返信
Highlighted
1 Copper

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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

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

返信
Highlighted
4 Tellurium

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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

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

返信
Highlighted

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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 側の処理が起因する例

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

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

返信
Highlighted
1 Copper

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

まず、各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パターンになっていたと考えられます。

返信
Highlighted

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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

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

返信
Highlighted
4 Tellurium

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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

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

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

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

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

返信
Highlighted
1 Copper

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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-P...

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

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


返信
Highlighted
4 Tellurium

Re: エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!【AskTheExpert1】

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

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

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

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

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

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

返信