未解決
この投稿は5年以上前のものです
Community Manager
•
3.1K メッセージ
1
8943
【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週間にしましょう。
このメッセージは次により編集されています: コミュニティマネージャ
JPCommunityMgr
Community Manager
Community Manager
•
3.1K メッセージ
0
2013年4月11日 23:00
いよいよ始まります。「エキスパートに聞こう!」
Unisphere(Navisphere)Analyzerの数値を読み解く!
Warming UPは以下で
。
「Unisphere GUIを使ったVNXパフォーマンスデータの取り方」
https://community.emc.com/docs/DOC-20243
「Navisphere Managerを使ったClarixパフォーマンスデータの取り方」
https://community.emc.com/docs/DOC-20244
エキスパートからのメッセージ
パフォーマンスが“いい”“わるい”とは?
Throughputの単位はIOPSなのですが、これがまた面倒なパラメータなんです。
IOPSはその名の通り1秒間で処理されたIO数です。例えばLUNのThroughputが300 IOPSの場合、
ある人は“充分速い”と感じるでしょうし、“遅い”と感じる人もいるのではないでしょうか?
いろいろな理由で、速い/遅いの感じ方が変わってくると思いますがこんな場合はどうでしょう!
Unisphere (Navisphere) Analyzerの計測単位(Polling Interval)は60秒ですので、
“60秒間で処理されたIO数” ÷ “60秒” がIOPSです。
300 IOPSなら18,000 IOが60秒間で処理されていることになります。
この計測単位(Polling Interval)の最初の10秒間で18,000 IO処理された場合と、
60秒かけて18,000 IO処理したのとでは性能の指標としては意味が異なります。
しかし、どちらもAnalyzerのデータとしては300 IOPSなんです。
この状況はIOPSだけでは判断できないです。他のパラメータを確認することになります。
Unisphere(Navisphere) Analyzerのパラメータは計算値であることが多いです。
それぞれの計算値の意味がわかるとAnalyzerのデータの持っている意味が違ってくると思います。
そんな感じのディスカッションができればと思ってます。
JPCommunityMgr
Community Manager
Community Manager
•
3.1K メッセージ
0
2013年4月14日 21:00
エキスパートに聞こう!イベントが始まりました。
パフォーマンス指標によく利用されるこのツールですが一体どの数値がどういうことを意味しているのか、わからないことが
多いですよね。エキスパート上原さんのいう、本当の意味でのAnalyzer数値に関してこの二週間Discussionしていきましょう。
もちろん
「パフォーマンスデータを採取すると稼働に影響がかかるのか?」
「XXの稼働状況を確認したい場合はどの項目に注目するのか?」
「データを保存するにはどうすればいいのか?」
などAnalyzerに関することであればエキスパートまたこのコミュニティーでDiscussionしていきましょう。
Noritoshi Ito
1 Rookie
1 Rookie
•
185 メッセージ
0
2013年4月15日 18:00
FAST VPが適切なディスクへ配置を行っていることを、
Unisphere Analyzerを利用して、数値的に取得できる計測項目がありますでしょうか。
** 背景 **
お客様に FAST VPのデモを計画しており、
各ディスクへ適切な配置という点で、LunのMB/S(Total ,Read、Write)以外に
Unisphere Analyzerで良い計測項目があれば、ご教授いただきたいです。
FAST VPは、Lunを階層に分けてしまうため、
部分的に良い/悪いが発生してしまうと考えております。
継続的に使われている(部分的に良い)、あまり使われていない(悪い)のような
データをみせることができると良いかと考えております。
3BAJ
18 メッセージ
1
2013年4月15日 21:00
FAST VPはStorage PoolのDrive TypeはMIXEDとなり,1つのStorage PoolにSSD Disk / SAS Disk / NL SASの
Diskを混在させることが可能です。
内部的には、それぞれのDisk Type別にRaid Group / LUNを作成しています。
Extreme Performance -- SSD Diskで構成
Performance -- SAS Diskで構成
Capacity -- NL SAS Diskで構成
FAST VPは、計測されている時間内でIOの多いSlice(Thin LUNを構成するアクセス単位(1GB))のデータを
より性能が高いDiskで構成されるRaid Group内のLUNのSliceへ移動させます。
残念ながらUnisphere AnalyzerではSlice単位での性能測定はできませんので、実際にアクセスの多いSlice
が移動したことを明確にAnalyzerで確認することはできません。このため、”FAST VPの効果を測定する”
ということはRelocation前後でThin LUNの性能を比較することになります。
Performanceの代表的指標にThroughput(IOPS), Utilization, Queue Length, Response Timeがあります。
上位からのアクセスパターンが同じであれば、結果としてThroughput(IOPS)は高くなり、Utilziation、Queue Length、
Response Timeは低くなれば性能向上したと考えられますので、Thin LUNのレベルではRelocation前後で
上記を確認すればよいと考えられます。
Thin LUNの下のレイヤーでAnalyzerで表示可能なものはDiskとなります。
こちらもFAST VPによりDataのRelocationを行った前後で考えた場合、
例えば、IO頻度の高いSliceのデータがPerformance Tier(SAS Disk)からExtreme Performance Tier(SSD Disk)へ
移動された場合には、IOのアクセス先がRelocation前後でPerformance TierからExtreme Performance Tierへ移動された
ということですので、Extream Performance Tierに属するDiskのIOPSはあがり、Performance Tier(SAS)に属するDiskの
IOPSは下がることになります。これを確認していただければよいと考えられます。
Nori_Ishitsuka
1 Rookie
1 Rookie
•
706 メッセージ
0
2013年4月15日 21:00
FAST Cacheについてご教授下さい。
既存ストレージ(CX4/VNX)のパフォーマンスに対して向上を求められた際、
FAST Cacheは提案が容易で且つ結果も得やすい機能だと考えているのですが、
「どの程度効果が表れるか」を事前に調査する方法は無いでしょうか。
AnalyzerによるDirty Cacheの推移は1つの手なのかと思いますが、
いわゆる「IOの偏り」を調べて容量算出まではたどり着けません。
どのような調査で、予測される効果と適切なサイジングができるものでしょうか。
Noritoshi Ito
1 Rookie
1 Rookie
•
185 メッセージ
0
2013年4月15日 23:00
ご回答ありがとうございます。
Relocation前後で確認するしかないようですね。理解いたしました。
また、TierのDiskのIOPSの変化をみせるという観点は、全くの盲点でした。
この観点で、お客様へのデモを検討させていただきます。
助かりました。有難うございます。
mawatarai
3 Apprentice
3 Apprentice
•
1.3K メッセージ
0
2013年4月16日 09:00
VNXでPool構成を使用した場合のSP Cacheヒット率に関してご教授ください。
現在Pool構成をおこなうとAnalyzerの項目にSP Cache Hit Ratioの項目がありません。
パフォーマンス検証を行いキャッシュヒットを考慮しながらディスクのサイジングを行いたいのですが、
キャッシュヒット率またはそれに準ずる値の導き方はありませんでしょうか。
SPに来るIO(SPAとSPBの合計)とディスク全体に来るIOを比較すればディスク全体のIOのほうが低くなると思っており
そこでおおよそのヒット率がわかると思ったのですが、ディスク全体のIOのほうが多くなってしまい悩んでいる状況です。
以上
3BAJ
18 メッセージ
1
2013年4月16日 17:00
FAST CACHEは頻繁にアクセスされるデータをHDDからFAST CACHE(SSD)上に移動させることでSSDを有効に使用しようと
するものです。HDDとSSDで比較した場合に、SSDはHDDに対してSEEK Time、回転待ち時間がありませんので、
HDDと比較するとランダムアクセスに対しての優位性があります。
ということで上位からのアクセスが"Small Size Random Access"の場合にはFAST CACHEは非常に有効です。
残念ながらUnisphere Analyzerでは上位からきたIOのアドレスはわかりませんので、アクセスがSequentialなのか
Randomなのかを明確に確認することはできません。
FAST CACHEに関しての詳細はホワイトペーパーに記載されていますので、ご覧になってください。
https://support.emc.com/docu32136_White-Paper:-VNX-FAST-Cache-—-A-Detailed-Review.pdf
3BAJ
18 メッセージ
1
2013年4月16日 23:00
Pool BaseのLUN(Thin LUN / Thick LUN)のCache Hitに関しては確かに項目がありません。
これはCacheはHost LUN単位で管理しているわけではなく、実際にデータのRead / Writeを行う
Private LUN単位で管理しているからです。
Thin LUNに対して行われたIOは、Thin LUNを管理しているモジュールにて実際にデータのRead / Writeを行う
Private LUNとそのアドレスを特定されます。Cache内ではそのLUN単位で管理されます。
Private LUNのデータをAnalyzerで表示させることはできませんので、Pool BaseのLUNのキャッシュヒット率は
表示できないということになります。
SPに行われたIO数とDiskへのIO数でDisk IOのほうが多いとうことに関しては、Poolを構成している
Private LUNのRaidレベルによるものが考えられます。
PoolをRaid-5で構成している場合を考えると、Readの場合には読み出すDataがDiskをまたいでいない限り、
Hostからの1つのReadはDisk側でも1 Readで変わりません。Writeの場合ですが、
- Random Writeの場合 -
Random Writeの場合を考えてみると、例えば1block(512byte)のWriteを行う場合にはRaid-5ではOld ParityとOld Dataを
読み出し、
(New Parity) = (Old Parit) xor (Old Data) xor (New Data)
のようにしてNew Parityを計算し、New DataとNew Parityを書き込みます。
従って上位からの1 Writeを行うのに 2 Reads(Old Data, Old Parity) + 2 Writes(New Data, New Parity)の4IOが
必要となります。
Raid1/0の場合には、上位からの1 Writeに対して、内部では2 Write(Mirrorのため)が必要となり、
Raid-6の場合には、上位からの1 wirteに対して、内部では6 wirte必要となります。
- Sequential Writeの場合 -
Sequentialの場合には、Parity Raid(Raid-3/Raid-5/Raid-6)ではRaidのストライプのデータを
全て書き込むことができますので、Old Parityのデータを読み出す必要がありません。
従って、Raid-5では上位からの1 Writeに対して、内部では(1 + 1/N(Parity))のIOが発生します。
Raid1/0の場合には、上位からの1writeに対して内部では2 Writeが必要となり、
Raid-6の場合には、上位からの1 Writeに対して、(1 + 2/N(Parity))のWriteが必要となります。
サイジングに関してですが、まずはDiskのIOPSで考えてみてはどうでしょうか?
各Disk TypeのIOPSに関するRule of Thumbは以下のようになります。
NL-SAS : 90 IOPS
SAS10K : 140 IOPS
SAS15k : 180 IOPS
Flash : 3500 IOPS
上記がおおよその目安となります。かなり安全をみている数値となりもちろん最大値ではありません。
上記の条件ですがSmall Size(4KB) ”Random IO”の場合となります。
mawatarai
3 Apprentice
3 Apprentice
•
1.3K メッセージ
0
2013年4月16日 23:00
詳細なご回答ありがとうございます。
SP上ではWPが考慮されていなかったのですね。
とても参考になりました。
また、ディスクIOでサイジングはよく行うのですが、ディスクIOだけでサイジングするとかなりディスク本数が多くなることが多いです。
(WPの兼ね合いが大きいです。)
ディスクIOでやるとかなり安心感はあるのですが、他社のサイジング(メーカのサイジングツール使用しているようです)を見るとキャッシュヒット率も考慮されてかなりディスク本数に差があり提案等しづらくなっているため、キャッシュヒット率を考慮したいと検討していました。
この辺でディスクIOだけでなくキャッシュ等も含めたサイジングを行うに当たり何かいい情報はないでしょうか?
Nori_Ishitsuka
1 Rookie
1 Rookie
•
706 メッセージ
0
2013年4月17日 18:00
AnalyzerからではFAST Cacheの有用性を事前に把握することは難しいとのことで了解です。
Symmetrixの場合はヒートマップがあるのでFASTソリューションの有用性について、
事前に大よそ把握できるのでVNXでもできなものかな、と言うのが発端でした。
Symmetrixのログにはアクセスアドレスが含まれててVNXには含まれてない、と言うのが根本的な違いのようですね。
別角度からまた考えてみたいと思います。有難うございました。
Uehara Y.
Community Manager
Community Manager
•
5K メッセージ
0
2013年4月17日 20:00
日本語コミュニティーのモデレーターをやっている上原です。(今回のエキスパートの上原さんとは別人です)
第一回目の「エキスパートに聞こう!」イベントからいきなり高度なディスカッションになってますね!
まだ1週間以上時間があるので、この機会を是非利用してください。
とはいっても「どんな質問すればいいのだろう?」となやんでいる方がいるかと思います。
例えばなのですが、
「そもそもVNX/CLARiXのストレージとしてのパフォーマンスを見るために、まずはAnalyzerのどの項目をおさえておけばいいのか?」
「あるホストからのアクセスが遅くなったように感じた場合に、その原因がストレージにあるのかをAnalyzerを使って確認しようとしたら、何からどうやって始めればよいのか?」
っていうような基本的、といいつつ実はエキスパートでないと答えるのが難しい質問なんてどうでしょうか?(「あー、そうそう!」って思われた方がいらっしゃったら上の質問をコピペして利用して頂いて結構です)
またはUnisphere Analyzer Command Line Interface (CLI) ReferenceのP.38以降にあるそれぞれの項目の意味、例えば「Queue LengthとAverage Busy Queue Lengthって何が違うんだろう・・」なんていうのもありかと。
正直な話、EMC社内でも上原さんに質問が出来るチャンスは結構少なかったりします。今を逃すと一生わからないままになってしまうかも知れません(まぁそれが心残りになるとはちょっと思いにくいですが・・・)。是非この機会をお見逃しなく!
mawatarai
3 Apprentice
3 Apprentice
•
1.3K メッセージ
0
2013年4月17日 21:00
VNXでFAST Cacheを使用しています。
FAST Cacheの容量が現在のシステム構成で足りているか足りていないかを判断するためにはAnalyzerのどの項目を確認すればよろしいでしょうか。
以上よろしくお願いいたします。
mawatarai
3 Apprentice
3 Apprentice
•
1.3K メッセージ
0
2013年4月17日 23:00
ご回答ありがとうございます。
ちなみにですが、ディスク構成がすべてRAID1/0でRandom IO(Read100 IO/Wirte100 IO)と仮定した場合、SPで取得できるWrite IOに関してはWPの2をかけて200 IOとRead 100 IOの合計300IOがディスクで処理されるべきIOPSとして考えれますでしょうか。
上記ができる場合、ディスクIOとSP IOの差がキャッシュでさばかれているIOと判断することは可能でしょうか?
3BAJ
18 メッセージ
0
2013年4月17日 23:00
前述の通りAnalyzerではPool BaseのLUNのキャッシュのヒット率は計測できません。
なので、お問い合わせのようなサイジングをAnalyzerで行うのはちょっと難しいかもしれません。
サイジングを行う場合には、上位側で必要とするIOPS、容量、アクセスパターン(Read/Writeの比率)を知る必要があります。
上位側の必要要件がわかるのであれば、DiskのIOPS(Rule of Thumb)から要求を満たすRaidレベル、Disk本数が計算されます。
サイジングとは異なるのですが、ボトルネックを探すような解析ということであれば、
まずはSP / LUN / DiskのUtilization / Queue Length / Response Time を参照、比較してみてください。