IOPS性能値のRW比を変更した場合の概算性能を見積もる方法

 

※本ナレッジは学術的な根拠に基づくものではなく私個人が利用している評価方法です。結果についての責任は負いかねますので、ご利用の際は自己責任でお願いします。

 

 

背景

ストレージの性能指標としてIOPSやレイテンシやスループットを参照する場合がある。
多くの場合、ランダム Read/Write（RR/RW）とシーケンシャル Read/Write（SR/SW）における限界性能値であったり、サンプルワークロードとして、OLTP 32KB Read 70% や、RDMS Read 40%などの負荷に対する性能値として提示されている場合がある。
とはいえ、実際の環境ではそれらのIOパターンと一致していないことも、当然ながら多い。
そのようなときに、RW比が7:3ではなく、6:4のときのIOPS性能値が知りたいケースもある。

本記事ではそのようなときに既存の性能情報からざっくりと必要なRW比での情報を見積もる方法を紹介する。
 

 

必要な情報

そもそもの話として、実環境のRW比と必要となるIOPS性能値がわかっていなければ評価のしようがない。
また、平均的なIOサイズについても知っておく必要がある。

そして、評価対象であるストレージの性能情報についてもなるべく多くのパターンを入手する必要がある。
実環境のRW比、IOPS、IOサイズについては把握できていない環境も多いが、LiveOptics（無償）などのアセスメントツールを使うことで簡単に確認できる。

ストレージの性能情報についてはベンダーに確認する、もしくはSizing Toolなどから入手できる場合もある。
このとき、IOサイズのパターンが多ければ多いほど良い。IOサイズによってIOPSは大きく変わるが、RW比と異なり異なるIOサイズでの性能情報を見積もることは困難であるため、実環境に近いIOサイズで検証している性能情報を入手することが重要である。

 

 

100％ Read / 100％ Writeの限界性能値のみがわかる場合。

 

実環境の平均IOサイズが8KBのRead 50%で、評価対象ストレージの8KBでのMax Read / Max Write のIOPS情報のみが判明しているケースを仮定する。

ここでは仮に以下のように想定する。

Max Read IOPS：120000

Max Write IOPS：30000

 

この情報からこのストレージのRW比 7:3の場合のIOPSを想定してみる。
このとき、それぞれのIOPSに比率をかけて合計する方法が思い浮かぶかもしれない。具体的には以下のような計算だ。

120,000*0.5 + 30,000*0.5 = 75,000 IOPS

このような計算をするのは間違いである。

なぜならば、Write IO部分を切り出した際に、75000*0.5=37500 IOPSとなってしまい、ストレージのMax Write IOPSを超えてしまっていることがわかる

 

このような場合はIOPSで計算するのではなく、レイテンシから計算するのが良い。
IOPSとレイテンシは逆数の関係にあるため、Max Read/Write時のレイテンシを以下のように見積もる

 

Max Read IOPS時のレイテンシ = 1/120000 = 8.33 usec

Max Write IOPS時のレイテンシ = 1/30000= 33.33 usec

 

それぞれのレイテンシにそれぞれの比率をかけて、合計の平均レイテンシを計算する。

8.33 * 0.5 + 33.33 * 0.5 = 20.83 usec

この平均レイテンシを逆数を取って元に戻すとRead 50%のIOPS限界性能の概算値になる。

1/20.83 = 48000 IOPS

 このように計算すればRead/Writeそれぞれの限界性能を超えることなく見る盛ることができる。

 

RW比 7:3 のIOPSグラフが提供されている場合。

 

IOサイズ 32KB Read 70% のIOPSグラフ（縦軸IOPS/横軸レイテンシ）が提示されている状況で、同じく32KB のRead 60%の場合の性能情報を見積もって、要件となるIOPS性能値を満たすかどうかを確認したいとする。

↓IOPSグラフの例



 

このようなケースでの考え方は2通りある。

①コンサバ案：Write IOPSのみに着目して考える方法
②アグレッシブ案：レイテンシからIOPSを割り出す方法

 

①の方法は、WriteよりもReadのほうが性能が良い、という事実に着目し、Write IOPSが要件を満たしていれば必然的にRead IOPSも満たせているという考え方である。

②の方法は前述したやり方と同様にReadとWriteそれぞれのレイテンシからIOPSを算出する方法である。

 

 

①コンサバ案：Write IOPSのみに着目して考える方法

IOPS(6:4)でのIOPS性能値の要件がTとする。
その場合のWrite IOPS 要件は0.4 T となる。
IOPSグラフ(7:3)でのIOPSをT’としたときに、Write IOPS は0.3T’ となる。
IOPSグラフ内で以下の関係が成り立つT' を求める。

0.4T = 0.3T’

 
T'についてこの式を解くと以下のようになる。

T’= T * 4/3

したがって、IOPS性能値要件（6:4)の値を 4/3倍したIOPSをグラフから参照することで、Write IOPS要件を満たす（= Read IOPS要件も満たす）かどうかを確認することができる
 

 

②アグレッシブ案：レイテンシからIOPSを割り出す方法

R:W = 7:3 のときのIOPSをTとして、その時の平均レイテンシをL （msec）とする。

Ready IOPS （0.7*T）のレイテンシをx (msec)とする
Write IOPS（0.3*T）のレイテンシをy (msec)とする

 
ここで、Read IOPSはWrite IOPSの3倍の性能があると仮定する
レイテンシとIOPSは逆数の関係にあるため、y = 3x とする

※xとyの関係式を多少強引にでも用意しないとxとyについての二元一次方程式が解けません。Read IOPSをWrite IOPSの何倍で見積もるのが妥当かについては、ベンダーやストレージ有識者の意見をご参照ください。

※xとyの関係式を多少強引にでも用意しないとxとyについての二元一次方程式が解けません。Read IOPSをWrite IOPSの何倍で見積もるのが妥当かについては、ベンダーやストレージ有識者の意見をご参照ください。

 
また、IOPSと遅延の関係から以下の式となる

0.7Tx + 0.3Ty = TL

 
y = 3x を代入する
0.7Tx + 0.9Tx = TL
16x = 10L
x = 10L/16
y = 30L/16
 
R:W = 6:4 となる場合の平均レイテンシを求める

0.6 * 10L/16 + 0.4 * 30L/16 = 1.125L

つまり、R:W=7:3 とR:W=6:4では、後者の平均レイテンシが1.125倍になる。
レイテンシとIOPSは逆数の関係にあるため、もとのIOPS（7:3）であるTを1.125で割るとIOPS(6:4)のときの概算のIOPSを算出できる。
もしくは、IOPS性能要件（6:4）を1.125倍したときの値でIOPS(7:3)のグラフを参照すればよい。
 
以上

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

NTPと同期してくれないときのトラブルシューティング

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。 多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。 NTPサーバとの疎通確認 何はともあれ、まずはNTP側との疎通と動作確認が必要です。 以下のコマンドを実行してください。 ※ESXiにはntpdateコマンドはないのでスキップしてください。
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む