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

いよいよ始まります。「エキスパートに聞こう！」　

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のデータの持っている意味が違ってくると思います。

そんな感じのディスカッションができればと思ってます。

エキスパートに聞こう！イベントが始まりました。

パフォーマンス指標によく利用されるこのツールですが一体どの数値がどういうことを意味しているのか、わからないことが

多いですよね。エキスパート上原さんのいう、本当の意味でのAnalyzer数値に関してこの二週間Discussionしていきましょう。

もちろん

「パフォーマンスデータを採取すると稼働に影響がかかるのか？」

「XXの稼働状況を確認したい場合はどの項目に注目するのか？」

「データを保存するにはどうすればいいのか？」

などAnalyzerに関することであればエキスパートまたこのコミュニティーでDiscussionしていきましょう。

FAST VPが適切なディスクへ配置を行っていることを、

Unisphere Analyzerを利用して、数値的に取得できる計測項目がありますでしょうか。

** 背景 **

　お客様に FAST VPのデモを計画しており、

　各ディスクへ適切な配置という点で、LunのMB/S（Total ,Read、Write）以外に

　Unisphere Analyzerで良い計測項目があれば、ご教授いただきたいです。

　FAST VPは、Lunを階層に分けてしまうため、

  部分的に良い/悪いが発生してしまうと考えております。

 

  継続的に使われている（部分的に良い）、あまり使われていない（悪い）のような

  データをみせることができると良いかと考えております。

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は下がることになります。これを確認していただければよいと考えられます。

FAST Cacheについてご教授下さい。

既存ストレージ（CX4/VNX）のパフォーマンスに対して向上を求められた際、

FAST Cacheは提案が容易で且つ結果も得やすい機能だと考えているのですが、

「どの程度効果が表れるか」を事前に調査する方法は無いでしょうか。

AnalyzerによるDirty Cacheの推移は１つの手なのかと思いますが、

いわゆる「IOの偏り」を調べて容量算出まではたどり着けません。

どのような調査で、予測される効果と適切なサイジングができるものでしょうか。

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

Relocation前後で確認するしかないようですね。理解いたしました。

また、TierのDiskのIOPSの変化をみせるという観点は、全くの盲点でした。

この観点で、お客様へのデモを検討させていただきます。

助かりました。有難うございます。

VNXでPool構成を使用した場合のSP Cacheヒット率に関してご教授ください。

現在Pool構成をおこなうとAnalyzerの項目にSP Cache Hit Ratioの項目がありません。

パフォーマンス検証を行いキャッシュヒットを考慮しながらディスクのサイジングを行いたいのですが、

キャッシュヒット率またはそれに準ずる値の導き方はありませんでしょうか。

SPに来るIO（SPAとSPBの合計）とディスク全体に来るIOを比較すればディスク全体のIOのほうが低くなると思っており

そこでおおよそのヒット率がわかると思ったのですが、ディスク全体のIOのほうが多くなってしまい悩んでいる状況です。

以上

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

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”の場合となります。

詳細なご回答ありがとうございます。

SP上ではWPが考慮されていなかったのですね。

とても参考になりました。

また、ディスクIOでサイジングはよく行うのですが、ディスクIOだけでサイジングするとかなりディスク本数が多くなることが多いです。

（WPの兼ね合いが大きいです。）

ディスクIOでやるとかなり安心感はあるのですが、他社のサイジング（メーカのサイジングツール使用しているようです）を見るとキャッシュヒット率も考慮されてかなりディスク本数に差があり提案等しづらくなっているため、キャッシュヒット率を考慮したいと検討していました。

この辺でディスクIOだけでなくキャッシュ等も含めたサイジングを行うに当たり何かいい情報はないでしょうか？

AnalyzerからではFAST Cacheの有用性を事前に把握することは難しいとのことで了解です。

Symmetrixの場合はヒートマップがあるのでFASTソリューションの有用性について、

事前に大よそ把握できるのでVNXでもできなものかな、と言うのが発端でした。

Symmetrixのログにはアクセスアドレスが含まれててVNXには含まれてない、と言うのが根本的な違いのようですね。

別角度からまた考えてみたいと思います。有難うございました。

日本語コミュニティーのモデレーターをやっている上原です。（今回のエキスパートの上原さんとは別人です）

第一回目の「エキスパートに聞こう！」イベントからいきなり高度なディスカッションになってますね！
まだ1週間以上時間があるので、この機会を是非利用してください。

とはいっても「どんな質問すればいいのだろう？」となやんでいる方がいるかと思います。

例えばなのですが、

「そもそもVNX/CLARiXのストレージとしてのパフォーマンスを見るために、まずはAnalyzerのどの項目をおさえておけばいいのか？」
「あるホストからのアクセスが遅くなったように感じた場合に、その原因がストレージにあるのかをAnalyzerを使って確認しようとしたら、何からどうやって始めればよいのか？」

っていうような基本的、といいつつ実はエキスパートでないと答えるのが難しい質問なんてどうでしょうか？（「あー、そうそう！」って思われた方がいらっしゃったら上の質問をコピペして利用して頂いて結構です）

またはUnisphere Analyzer Command Line Interface (CLI) ReferenceのP.38以降にあるそれぞれの項目の意味、例えば「Queue LengthとAverage Busy Queue Lengthって何が違うんだろう・・」なんていうのもありかと。

正直な話、EMC社内でも上原さんに質問が出来るチャンスは結構少なかったりします。今を逃すと一生わからないままになってしまうかも知れません（まぁそれが心残りになるとはちょっと思いにくいですが・・・）。是非この機会をお見逃しなく！

VNXでFAST Cacheを使用しています。

FAST Cacheの容量が現在のシステム構成で足りているか足りていないかを判断するためにはAnalyzerのどの項目を確認すればよろしいでしょうか。

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

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

ちなみにですが、ディスク構成がすべてRAID1/0でRandom IO（Read100 IO/Wirte100 IO）と仮定した場合、SPで取得できるWrite IOに関してはWPの2をかけて200 IOとRead 100 IOの合計300IOがディスクで処理されるべきIOPSとして考えれますでしょうか。

上記ができる場合、ディスクIOとSP IOの差がキャッシュでさばかれているIOと判断することは可能でしょうか？

前述の通りAnalyzerではPool BaseのLUNのキャッシュのヒット率は計測できません。
なので、お問い合わせのようなサイジングをAnalyzerで行うのはちょっと難しいかもしれません。

サイジングを行う場合には、上位側で必要とするIOPS、容量、アクセスパターン(Read/Writeの比率)を知る必要があります。
上位側の必要要件がわかるのであれば、DiskのIOPS(Rule of Thumb)から要求を満たすRaidレベル、Disk本数が計算されます。

サイジングとは異なるのですが、ボトルネックを探すような解析ということであれば、
まずはSP / LUN / DiskのUtilization / Queue Length / Response Time を参照、比較してみてください。