本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、
そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。
原文を参照したい方は Identifying & Resolving Excessive CPU Overcommitment (vCPU:pCore ratios) をご確認ください。
情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はID、パスワードの取得が必要です)
HELP! 私の環境のパフォーマンスがひどいのですが、コンサルやベンダーはキツいCPUオーバーコミットが原因だと言っています。どうしたら良いのでしょうか？
質問:どれくらいまでCPUのオーバーコミットはいけるんですか？
その答えはもちろん「場合によります！」であり、どのような仮想マシンを動作させるか、物理CPUは何を搭載しているかということだけではなく、他の仮想マシンがどのように動作しているかなど複雑な要素が絡み合います。
その他のよくある質問:
いま、どれだけのオーバーコミットをしているのですか？
そして
オーバーコミットがパフォーマンスの問題を引き起こしている原因であるかはどうすれば分かりますか？
さあ、それでは「いま、どれだけのオーバーコミットをしているのですか？」から触れていきましょう。
Nutanixを使うと非常に簡単にその作業ができます。
まず、PRISMのハードウェアというメニューからダイアグラムをクリックし、次に示すようにノードの１つを選択します。
そうすると、SummaryセクションにCPUのモデルやコア数、ソケット数が表示されます。
この場合、１ソケットあたり合計10個の物理コアが存在するため、2つのソケットと20個のコアがあることがお分かりいただけます。
クラスターに複数のノードの種類が存在する場合、クラスター内の異なる種類ごとにこの手順を繰り返してください。
次にクラスター内の物理コアの総数を単純に合計します。
このケースでは3つのノードがあり、それぞれ20個のコアがあり、合計60個の物理コアがあることになります。
次に、クラスター内に割り当てたvCPUの数を調べましょう。これはPRISMの仮想マシンのページで以下に示すように見つけることができます。
つまり、60ノードの物理コア(pCore)を持つ3ノードのクラスターがあり、130個のvCPUを割り当てていることが分かります。
ということで、vSphere Cluster Sizing Calculatorに確認した内容を入力し、希望する可用性レベル(この場合はN+1)を考慮したオーバーコミットの状況を識別することができます。
このカリキュレーターはコンサバティブに設計されており、構成された可用性レベルに必要なリソース(CPU/RAM)が計算から除外されている前提で情報を表示します。言い換えれば、vCPU:pCoreの比率はN+1の余裕を考慮したホストがクラスターの中に存在しないものと想定しています。
カリキュレーターはvCPU:pCoreの比率が3.25:1であることを示します。
SQLやExchange、OracleやSAPなどのビジネス上で重要なアプリケーションの場合、CPUのオーバーコミットを行わず(つまり1:1)にサイジングを行い、仮想マシンのパフォーマンスが低下しないようにすることを推奨します。
オーバーコミットの比率が分かったら次に何をすればよいでしょうか？
オーバーコミットの状況がもともと想定していた設計と一致しているかを確認し、現在の状態で仮想マシンがどのように動いているかを評価する必要があります。
素晴らしい設計はアプリケーション要件、CPUのオーバーコミット、仮想マシンの配置状況やDRSのルールといったパフォーマンスの要因を考慮するべきでしょう。
それでは、オーバーコミットがパフォーマンスの問題の原因となっているかはどのようにして確認すればよいのでしょうか？
仮想マシンがCPUスケジューリング競合を起こしているかどうかを判断するいちばんよい方法はAHVで”CPU準備時間”または”Stolen Time”を確認することです。
“CPU準備時間”は基本的に仮想マシンがCPUコアにスケジューリングされることを要求してから実際にスケジューリングされるまでの遅延です。
これを示すいちばん簡単な方法のひとつは、仮想マシンがスケジュールされることを待っている合計時間の割合を求めることです。
私が得た経験則は次のとおりです。
2.5%未満のCPU準備時間
一般的に問題ありません。
2.5%-5% CPU準備時間
ピーク時に監視する必要がある最小限の競合です。
5%-10% CPU準備時間
調査するべき重要な競合です。
10%より大きいCPU準備時間
早急に調査し、対処が必要な重大な競合です！
とは言え、"CPU準備時間"の影響はアプリケーションによって異なりますので、特にビジネスクリティカルなアプリケーションでは1%の競合も見落とすことのないように注意しましょう。
"CPU準備時間"は重要な性能基準であるため、Nutanixはこれを仮想マシンごとにPRISMに表示することにしました。これによりお客様はCPUスケジューリングの競合状況を簡単に識別することができます。
以下では、仮想マシンを強調表示した後、PRISMで仮想マシンのページに表示されるパフォーマンスの概要を示しており、ページの下部に”CPU準備時間”を示すグラフが表示されます。
2.5%のCPU準備時間は大多数の仮想マシンにとっては大きな問題を引き起こすことはないと思われますが、例えばデータベースや動画/音声などのレイテンシに敏感なアプリケーションでは、その2.5%という数字が大きな問題を引き起こす可能性があります。
私は仮想マシンに注目することをお勧めします。
そして、CPU準備時間が1%を超える程度だとしても、それがビジネスクリティカルなアプリケーションである場合、CPU準備時間が0.5%以下になるまでこの記事のトラブルシューティング手順に従い、性能差を評価してみてください。
Key Point: SQL ServerのAlwaysOnのような可用性グループ、Oracle RAC、Exchane DAGなどのアプリケーションの場合、CPU準備時間が発生している仮想マシンは他の仮想マシンが通信(またはレプリケーション)をしようとするフローに影響を与える可能性があります。
そのため、他の要因を調査する前に、仮想マシンやアプリケーションの依存性が”CPU準備時間”によって悪影響が起きていないことを確認してください。
端的に言えば、CPU準備時間が発生していないサーバーAは、サーバーBとの通信を試みているときにサーバーBのCPU率が高いことによって遅延が発生する可能性がある、ということです。
私がこのような話を持ち出す理由は「パフォーマンスの問題を調査するときは視野を狭めないことが重要」だと言えるからです。
さあ、ここからがおもしろいところで、CPU準備時間のトラブルシューティングと解決法です！
1. 仮想マシンの正しいサイジング
このステップを無視しないようにしてください！CPUオーバーコミット率は関係ありません。正しいサイジングはいつも仮想マシンの効率とパフォーマンスを向上させます。
より多くのvCPUをスケジューリングしようとするとハイパーバイザーレイヤーのオーバヘッドが増加しますので、オーバーコミットをさせないとしても仮想マシンはオーバーサイジングしないようにしましょう。よくある誤解として、90%のCPU使用率はボトルネックであることが挙げられますが、実際にはこれは正しいサイジングをした仮想マシンの兆候であると言えます。vCPUがピーク時のサイジングとなっていることが前提となりますが、仮想マシンが100%の使用率で長時間固定されている場合を除いて、100%となるCPUスパイクは必ずしも問題になるとはいえません。
次に仮想マシンの正しいサイジングによるメリットの例を示します。 (VM Right Sizing – An example of the benefits)
仮想マシンを正しくサイジングしたら、ステップ2へ進みましょう
2. NUMAを考慮してサイジングする
まず、NUMAとは何でしょうか？これは非常にシンプルで、コア数をソケット数で割ったものです。
これがNUMAであり、最高のメモリパフォーマンスと最適なCPUスケジューリングの恩恵を受けたい場合に仮想マシンが持てる最大のvCPU数でもあります。
ホストの合計RAMもまた、RAMの合計数をソケットの数で割ります。
これが仮想マシンに対して割り当てることができる最大のメモリ搭載量であり、これにそぐわない場合は約30%程度のパフォーマンスペナルティが発生します。
例:12コアを搭載したNutanixノード上で、12vCPU/96GBの仮想マシンでExchangeを動作させているお客様がいました。
(最終的にはマイクロソフト社の製品不具合でしたが)Exchangeがうまく動作しておらず、CPUの性能不足が問題であると主張しました。
そのため、お客様は仮想マシンに対し、18個のvCPUを増やすことにしました。
残念ながらこれはパフォーマンス問題を解決させることができませんでした。
そして、実際にはNUMAよりも大きな仮想マシンが他のワークロードを実行しているホスト上でその仮想マシンの”CPU準備時間”による影響を与えてしまったため、他のホストへもパフォーマンスに対する悪影響を及ぼしてしまいました。
結局12vCPUに戻して"CPU準備時間"を解放し、最終的にはマイクロソフト社のパッチでこの問題を解決しました。
3. 最重要仮想マシンを実行しているホストから他の仮想マシンを移行する
これはCPUスケジューリングの競合を緩和するための大変簡単なステップであり、CPUオーバーコミットをさせないことによるパフォーマンス上のメリットを確認することができます。仮想マシンのパフォーマンスが向上したとすると、パフォーマンスの問題の原因の少なくともひとつ見つけられた可能性があります。これはより難しい内容です。ひとつの仮想マシンごとにホストを用意する余裕がない限り、ホストを移行するためのコンプリメンタリーワークロードを特定する必要があります。コンプリメンタリーワークロードってなに？よくぞ聞いてくれました！例をご紹介しましょう。
正しくサイジングされた10vCPU/128GBのSQL Server用の仮想マシンがあり、そのホストは１ソケットあたり10コア(合計20コア)の2つのソケットと256GBのRAMを搭載したNX-8035-G4です。SQLであることから、ビジネスクリティカルなアプリケーションのバックエンドですので、IO要件は高いものと想定されます。
Nutanixであることから、さらにリソース(例えば8vCPUと32GBのメモリ)を使用してCVMも保持していることとなります。興味のある方は” Cost vs Reward for the Nutanix Controller VM (CVM)”をご覧ください。コンプリメンタリーワークロードには次に挙げるひとつ以上の特性があります:
コンプリメンタリーワークロードってなに？
よくぞ聞いてくれました！例をご紹介しましょう。
正しくサイジングされた10vCPU/128GBのSQL Server用の仮想マシンがあり、そのホストは１ソケットあたり10コア(合計20コア)の2つのソケットと256GBのRAMを搭載したNX-8035-G4です。
SQLであることから、ビジネスクリティカルなアプリケーションのバックエンドですので、IO要件は高いものと想定されます。
さらにNutanixであることから、追加でリソースを使用してCVMも保持していることとなります。(例えば8vCPUと32GBのメモリ)
興味のある方は "Cost vs Reward for the Nutanix Controller VM (CVM)” をご覧ください。
コンプリメンタリーワークロードには次に挙げるひとつ以上の特性があります:
A) 96GB未満のメモリ(ホストの搭載RAM256GB、SQL Server用の仮想マシン128GB、CVM32GBのとき、96GBの残容量)
B) vCPUが2以下 (これは1:1のvCPU:pCoreという比率を意味する)
C) vCPUの要件および使用率が低い
D) IO要件が低い
E) ディスク容量の要件が低い(これはデータローカリティを利用した最大のRead性能を考慮し、ノードのローカルに保持されるSQL Serverのデータ量を確保する)
F) SQLのワークロードとは異なる時刻にCPUやストレージを使用するワークロード
例:SQLは午前８時から午後6時までビジー状態になる可能性がありますが、その時間外は負荷が大幅に低下すると考えられます。
午後７時から深夜まで実行されるCPU/ストレージIO要件が高い仮想マシンは、オーバーコミットを可能にし、重複しない仮想マシンの動作時間に起因するパフォーマンスの影響を最小限に抑えるため、隙間をぬった負荷になると言えます。
4. より多くの物理コアを持つノードに仮想マシンを移行させる
これは当たり前かもしれませんが、より多くの物理コアを持つノードではCPUスケジューリングの柔軟性が増し、CPU準備時間を削減することができます。
仮想マシン上でvCPUを増やさなくても、仮想マシンは物理コア上で処理をするための時間を得る可能性が高く、それによりパフォーマンスが向上します。
5. 仮想マシンをよりCPUクロックの高いノードに移行させる
これもまた当たり前な内容のひとつですが、ベンダーやお客様が要件としてvCPUの数を引き合いに出すことはとても一般的です。
オーバーコミットのない最高のvCPUは１つの物理的なコアに相当します。物理コアはクロックが異なることがありますが、
高クロックなCPUは特に厄介とされるシングルスレッドアプリケーションのパフォーマンスに大きな影響を与えます。
注: クロックの高いCPUはコア数が少ないことが多いため、NUMAを超えるような仮想マシンの配置をしないようにしましょう。
6. 物理サーバーで高度な電源管理をオフにし、ポリシーとして”High Performance”を使用する (ESXiの場合)
高度な電源管理の設定は電力を節約し、場合によってはパフォーマンスへの影響を最小限に抑えることもできますが、パフォーマンス上の問題、
特にビジネスクリティカルなアプリケーションのトラブルシューティングには高度な電源管理を無効化することでパフォーマンスの問題が解決することもあります。
7. ハイパースレッディング(HT)を有効にする
ハイパースレッディングはCPUスケジューリングのメリットを提供し、多くの場合はパフォーマンスを向上させ、
CPUベンチマークでも10～30%程度の性能アップを実現させます。
長い話を簡単に言えば、Ready状態の仮想マシンは何もしていないので、ハイパースレッディングを有効にしてあげると、何もしないよりもより良いということです。
また、ハイパーバイザーは非常に賢く、優先的にvCPUをpCoreにスケジューリングするため、ビジー状態の仮想マシンはpCore上に存在せず、vCPUの要求の低い仮想マシンはハイパースレッディングにスケジューリングできます。Win-Winですね。
注:マイクロソフト社のExchangeのように一部のベンダーはハイパースレッディングをオフにすることを推奨しています。
しかしながら、この推奨事項は実際には物理サーバー上で動作するExchangeのみに適用されます。
仮想環境ではハイパースレッディング対応のワークロードとExchangeのようなvCPUとpCoreの比率を1:1に設定したようなワークロードを共存させることで、一貫した高性能を実現させます。
(マイクロソフト社のような)ハイパースレッディングを無効にするように主張しているベンダーと戦っているひとのための、ハイパースレッディングに関するアーキテクチャー状の考慮事項があります。
Example Architectural Decision – Hyperthreading with Business Critical Applications (Exchange 2013)
8. クラスターにノードを追加する
最適化されたワークロードを持つノードに適切なサイジングを施した仮想マシンがあり、最適なNUMA構成を保証し、
ビジネスクリティカルなアプリケーションを動作させている仮想マシンが最高のクロックのCPUで稼働していることを確認していながらも
パフォーマンスの問題が残っている場合は、１つまたは複数のノードをクラスターに追加します。
追加ノードはより多くのCPUコアを提供し、ひいてはより多くのCPUスケジューリングの機会を作ります。
私がよくされる質問は「重要な仮想マシンでCPU予約を使って、CPUを100%保証するのはなぜですか？」というものです。
言い換えれば、CPU予約を使用してもCPU準備時間の問題を解決することはできず、この内容について記事も書きました : Common Mistake – Using CPU reservations to solve CPU Ready
ワイルドカード: ストレージノードを追加する
待って、どういうこと？なぜストレージノードを追加するとCPUの競合が減るのでしょうか？
これは非常に簡単で、Read/WriteのIOレイテンシが低くなるため、CPUがIOを完了することを「待っている」時間であるCPU WAITが少なくなるためです。
例えば、I/OがNutanixでは1ms、従来のSANでは5ms必要な場合、仮想マシンをNutanixに移動させると仮想マシンのCPU待機時間が4ms少なくなります。これは仮想マシンが割り当てられたvCPUをより効率的に使用できることを意味します。
追加の容量が必要ない場合でも、ストレージノードを追加するとクラスター内の平均I/Oレイテンシが向上し、仮想マシンを物理コアにスケジューリングし、作業を完了させて、別の仮想マシンにpCoreを解放したり、その他の処理を実行したりします。
注: ストレージノードとデータの分散スループットの方法はNutanixの独自機能です。仮想マシン/アプリに変更を必要としないストレージノードでパフォーマンスがどのように改善されるかについては、次の記事を参照してください。
Scale out performance testing with Nutanix Storage Only Nodes
要約:
ストレージノードによるストレージの強化など"CPU準備時間"の問題に対処するためにできることはたくさんあります。
"CPU準備時間"に関するその他の記事
1. VM Right Sizing – An Example of the benefits
3. Common Mistake – Using CPU Reservations to solve CPU Ready
4. High CPU Ready with Low CPU Utilization
あとがき
量が多くて大変だなという記事でしたが、書いてあることは非常に重要なものです。
この記事では、仮想マシンのパフォーマンスはvCPUの数を増やせば向上するというものではなく、Nutanixのノードが搭載している物理コアの数やメモリの量、そして負荷の性質などを考慮した上で仮想マシンのリソースや配置を検討する必要があるという内容を示唆しています。
訳を作成する中で、個人的に興味深いフレーズもありました。
原文にある "It depends." というものです。
私は「場合によります！」という訳にしましたが、今年Citrix Synergyに参加したときにいろいろなアーキテクトと会話をし、サイジングの話ではだいたい "It depends." という言葉を耳にしています。
私自身もセミナーなどでサイジングの内容に触れるときは「お客様の使い方や条件、環境に依存します」という前提条件を付けます。
当然のことながら、ワールドワイドでもサイジングについては「絶対にこれだ！」という正解はないんだということを改めて実感しています。
記事担当者 : SI技術本部 海野航 (うんのわたる) @UnnoWataru
