未解決
この投稿は5年以上前のものです
Community Manager
•
3.1K メッセージ
1
8948
【Ask the Expert】エキスパートに聞こう!Unisphere(Navisphere)Analyzerの数値を読み解く!
待望のAskTheExpertイベント(エキスパートに聞こう!)が日本語フォーラムでついに開催されます!
記念すべき第一回目のTopic はUnisphere(Navisphere) Analyzerについて。
パフォーマンス解析の指標として使われるAnalyzerの結果について、あなたはどれくらい知っていますか?間違った認識で性能解析をしていませんか?
Unisphere(Navisphere) Analyzerのエキスパートがあなたの疑問に答えます。
またAnalyzerを使っている他のユーザーとも情報を交換して、より有効なAnalyzerの使用方法を探していきましょう!
Topic:Unisphere(Navisphere) Analyzerについて
Date :4月15日から26日17時まで
Name:上原信行 Data General社時代のCL Series(EMC clariion(日本ではClarix)から現在のEMC VNXに至るまでストレージ畑一筋のエンジニア。 CLARiXとは20年来の付き合いになるそうです。丁寧かつ理論的な説明には定評があり、ファンも多数。トレーニング講師も数多く務める、SCSI好きのスポーツマン。 メッセージ:現実的なUnisphere(Navisphere) Analyzerでの性能解析における方法,またSP, LUN, Diskなどの計測が行われているオブジェクトとそこで計算される値について、各値の意味とそれらの値から装置の状態をどのように推測するかなどをディスカッションできればと思います。 |
投稿について:Unisphere(Navisphere) Analyzerに関する質問をこちらのディスカッションに投稿してください。なお今回のTopic と関連性がないと判断された場合、適切なスペースへ移動されることがあります。
1つの質疑応答が進行していても並行して他の質問を投稿することは可能です。質問に対する回答はエキスパートでなくても投稿可能です。
ディスカッション期間は2週間になりますのでこのチャンスをお見逃しなく!
それでは有意義な2週間にしましょう。
このメッセージは次により編集されています: コミュニティマネージャ
mawatarai
3 Apprentice
3 Apprentice
•
1.3K メッセージ
0
2013年4月18日 00:00
すみません初歩的なことかもしれませんが確認させてください。
1.SP CacheのForced Flushesでよろしいのでしょうか?
(これはFAST Cacheが2次Cacheなので1次Cacheがあふれなければ2次キャッシュの構成も十分という認識でよろしいでしょうか)
2.添付画面の通りなのですが、"SP Cache Forced Flushes/s"が項目にないのですが、現在は”SP Write Cache Flushes/s”という項目に変わったのでしょうか
よろしくお願いいたします。
3BAJ
18 メッセージ
1
2013年4月18日 00:00
AnalyzerのSPで "SP Cache Forced Flushes/s" と LUNの "Response Time" を確認してみてください。
Forced Flushがなく、LUNのResponse Timeの平均が低い場合(十数ミリ/s)にはFAST CACHEは充分な構成であると考えられます。
3BAJ
18 メッセージ
0
2013年4月18日 01:00
上記条件であれば上位側での要求が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カウントからキャッシュヒット率
を計算することは難しいと考えられます。
3BAJ
18 メッセージ
0
2013年4月18日 01:00
失礼しました。
Analyzerの LUN で”SP Cache Forced Flushes” です。
mawatarai
3 Apprentice
3 Apprentice
•
1.3K メッセージ
0
2013年4月18日 01:00
ありがとうございます。
RAID LUNで”SP Cache Forced Flushes”を確認できました。
しかしPool LUNの場合はありませんでした。
やはり現在のVNXのAnalyzerですとPool構成で組んだ場合、キャッシュに関する情報を取得して
調査を行うのはかなり難しいようです。
以上
Nori_Ishitsuka
1 Rookie
1 Rookie
•
706 メッセージ
0
2013年4月18日 22:00
非常に初歩的な質問になってしまいお恥ずかしいのですが、
Analyserログファイルが複数ある場合の結合する手間を減らす方法をご教授頂けないでしょうか。
「Merge」で行う方法は知っているのですが、この方法では1つ1つ順番に結合する必要があり、
多くのファイルを結合しようとするとかなりの手間となっているので解消したく。
以前、EMCの方にはあきらめなさい、とは言われたのですが、
もし何か手間を減らす方法があるのであればお願いします。
3BAJ
18 メッセージ
0
2013年4月18日 23:00
残念ながらAnalyzerはGUIもCLIも2つのファイルのMergeしかできないので、スクリプトを組むか地道にMergeするかになります。
ちなみにCLIのコマンドは以下のようになります。
naviseccli analyzer -archivemerge -data < archive2> [-out outputarchive] [-overwrite y |n]
vTbQCM2nu61197353438918
1 Rookie
1 Rookie
•
61 メッセージ
0
2013年4月21日 21:00
パフォーマンスの考察にあたり質問があります。
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 側の処理が起因する例
上位側の構成・処理が起因する例等、
どこから疑うべきかの指針となるような代表的なパターンご教授いただけると幸いです。
3BAJ
18 メッセージ
1
2013年4月22日 01:00
まず、各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パターンになっていたと考えられます。
vTbQCM2nu61197353438918
1 Rookie
1 Rookie
•
61 メッセージ
0
2013年4月22日 20:00
ご回答ありがとうございました。
もっと簡単に場合分けできるもんかと思っていたんですが、
同じ値でも、もっと細かい項目によって原因が大きく違うんですね。
Nori_Ishitsuka
1 Rookie
1 Rookie
•
706 メッセージ
0
2013年4月22日 23:00
mergeの件、ご回答有難うございます。
小いさなことではあるんですが、
大量のデータが届くたびにマージしているとツライものがあったのでご質問させて頂きました。
今後も修行と思って地道にマージします。
Nori_Ishitsuka
1 Rookie
1 Rookie
•
706 メッセージ
0
2013年4月22日 23:00
Analyzerで確認できる状況の判断指針について記述されている資料は公開されていないのでしょうか。
当方はCLARiX時代(CX2時代)のパフォーマンスワークショップに参加したきりの知識なのですが、
最新のVNXや特にSSDやFAST Cacheについての値はどう判断すべきなのか把握したいと考えています。
当然、最新のパフォーマンスワークショップに出席すれば入手可能な情報なのかもしれませんが、
Monitoring and ReportやStorage Analyticsなどのパフォーマンスモニタリングツールがいくつもリリースされ、
一般ユーザでも確認可能な状況なので公開資料が無いものかと思い、ご質問させて頂きます。
3BAJ
18 メッセージ
1
2013年4月23日 01:00
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
などは参考になると思います。
Nori_Ishitsuka
1 Rookie
1 Rookie
•
706 メッセージ
0
2013年4月23日 17:00
まだ判断指標は無いですか・・・
世間の状況的に「何をもって正常と判断する」と言う話が増えているので期待したのですが、残念です。
(この点、VMware社のvCopsは優秀でして、
そのOEMのStorage Analyticsも同じく何がしかの判断で健全性を計ってます。
これが解明できればなぁ、と思った次第です。)
ヘルプはこれからも参考にしたいと思います。
ayas
Moderator
Moderator
•
6.7K メッセージ
0
2013年4月24日 00:00
昔お客様でAnalyzerの数値が一時飛躍的に高くなった・・・という方がいたのですがこの場合はいったいどういうことだったのでしょうか。どの数値がどれくらい。。といった記憶が定かではないのですがパフォーマンスが悪くなったという体感はまったくないのにそんな状況はありうるのでしょうか。