VMWare vSphereに基づく仮想インフラストラクチャの最適化

実践により、ある程度まで、どのプロセスも常に最適化できることが示されています。 これは、仮想化に起因する可能性があります。 最適化の機会はたくさんあり、このタスクは多面的です。



この記事のフレームワーク内で、仮想マシンのサイズを決定する方法と、作業を最適化する方法について説明します。 この資料は技術的なものであり、すべてのvSphereスペシャリストに慣れるために推奨されます。



まず、主にvSphereのパフォーマンスに影響を与える2つのテクノロジーについてお話したいと思います。 これはNUMAテクノロジーとESXiハイパーバイザーシェダー技術です。



NUMAについての詳細な記事はたくさんありますが、この情報を改めて説明する意味はありません。素材の完全性に関する基本的な説明に限定します。 NUMA-不均一メモリアクセス。 これは、メモリへの不均等なアクセスとしてロシア語に翻訳できます。



実際、最新のマルチソケットサーバーは、1つのマザーボードに結合された複数の分離されたシングルソケットコンピューターです。 各プロセッサは、独自のRAMスロットを単独で所有し、それにのみアクセスできます。 同様に、各プロセッサには、マザーボードのさまざまなデバイスが接続される専用のPCI-Eバスと、PCI-E拡張スロットがあります。 プロセッサは高速データ交換バスによって相互接続されており、このバスを介して「外部の」デバイスにアクセスし、対応するホストプロセッサに要求します。 明らかな理由により、プロセッサが自身のメモリにアクセスするコストは、他の人のメモリよりもはるかに安価です。 今のところ、この技術について知る必要があるのはこれだけです。



vSphereはNUMAを十分に認識しており、仮想マシンのRAMが現在メモリにある物理プロセッサに仮想マシンコアを配置しようとしています。 しかし、落とし穴があります。 サーバーメーカーは、デフォルトでBIOSでNUMAエミュレーションを有効にすることを好みます。 つまり、オペレーティングシステムにはサーバーがNUMAデバイスではないように見え、vSphereはその最適化を使用してこのテクノロジーを管理できません。 vSphereのドキュメントでは、BIOSでこのオプションを無効（無効）にすることをお勧めします。これにより、vSphereが個別に問題に対処できるようになります。



NUMAで発生する可能性のある潜在的な問題を考慮してください。 vSphereはそれを認識し、正しく動作すると想定しています。 たとえば、2プロセッサシステムをNUMAの最も単純なバージョンと見なします。 物理サーバーに64 GBのRAMがあり、各ソケットに32があるとします。



1. 1つの仮想コア（vCPU）で仮想マシン（VM）を作成します。 当然、このような仮想マシンを実行できる物理プロセッサは1つだけです。 VMに48 GBのRAMを割り当てる必要がある状況を考えます。 32 GBのVMメモリは「独自の」物理プロセッサから取得され、さらに16 GBは「エイリアン」から取得する必要があります。 そして、これらの「外部」ギガバイトにアクセスすると、保証された高レイテンシが得られます。これにより、仮想マシンの速度が大幅に低下し、物理プロセッサ間のデータ転送バスの負荷が増加します。 仮想マシンにそれぞれ1コアの2つの仮想ソケットを与えると、状況を修正できます。 その後、vSphereは2つのVM vCPUを異なる物理プロセッサに分配し、それぞれから24 GBのRAMを使用します。 仮想マシンに1つの仮想ソケットを与えることにより、2つの物理プロセッサを正しく使用する機能を奪います。

2.最初の項目に加えて、10 GBのRAMと1つのvCPUを備えた2番目のVMを作成するときのオプション。 このVMが1つの場合、問題はありません。32GBのRAMを備えた1つのNUMAノードに完全に適合します。 ただし、両方のNUMAノードで24 GBのメモリを消費する最初のマシンが既にあり、各ノードには8 GBしか残っていません。 この状況では、NUMAの観点からはそれぞれが正しく構成されているようですが、最初または2番目のVMのいずれかが「エイリアン」メモリの一部を使用し始めます。 これは非常によくある間違いであり、設計中に仮想インフラストラクチャを非常に慎重に計算する必要があります。また、運用中に仮想マシンを構成するための包括的なアプローチが必要です。



NUMAとハイパースレッディングを使用する場合、vSphereには明確なロジックがあります。



VMに仮想ソケットが1つしかない場合、vCPUの増加により、マシンはハイパースレッディングテクノロジーを使用せずに、物理コア上の排他的に単一の物理プロセッサで実行されます。 vCPUの数が物理プロセッサコアの数を超える場合、VMはこの物理プロセッサ内で引き続き実行されますが、すでにハイパースレッディングを使用しています。 vCPUの数がハイパースレッディングを考慮してプロセッサコアの数を超えた場合、隣接するNUMAノード（他の物理プロセッサ）のカーネルが使用され始め、パフォーマンスが低下します（誤った数の仮想ソケットを指定した場合）。 物理プロセッサの負荷が高く、空き物理コアがない場合、いずれの場合も、ハイパースレッディングテクノロジが使用されます（仮想マシン構成で特に指定されていない限り）。 数値を見ると、純粋な物理コアと比較して純粋なハイパースレッディングで実行する場合、VMは平均してパフォーマンスの約30〜40％を失います。 ただし、ハイパースレッディングテクノロジを使用した場合、物理プロセッサ自体の全体的なパフォーマンスは、ハイパースレッディングテクノロジを使用しない場合（物理コアのみを使用）よりも約30％高くなります。 この指標は、負荷のタイプとマルチスレッド作業用のVMアプリケーションの最適化に大きく依存しています。



VMに複数の仮想ソケットがある場合、vSphereは実行可能なカーネルとRAMを異なる物理サーバープロセッサに配置することにより、そのようなVMの動作を最適化します。



明らかな理由により、物理サーバーの負荷状況は常に変化しています。 多くの場合、サーバーの物理プロセッサの負荷は不均一です。 vSphereはこれを追跡します。 Shedulerは、状況を分析し、VMまたはその一部を別のNUMAノードに移動するオーバーヘッド（メモリ、コアを移動する）を計算します。 これらのコストを移転の潜在的な利点と比較し、そのままにするか移転するかを決定します。 つまり、どのような状況でも、vSphereは仮想マシンのパフォーマンスを最適化しようとします。 私たちのタスクは、vSphereを単純化し、絶望的な状況に置かないことです。



NUMAノードを持つマシンが正しく構成されていない場合、どのような損失が発生しますか？ 私自身の経験から判断すると、損失は物理サーバーの合計パフォーマンスの最大30％に達する可能性があると言えます。 たくさんか少しかはあなた次第です。



NUMAとハイパースレッディングを少し理解したので、仮想マシンカーネルであるvCPUでshedulerがどのように機能するかについてもう少しお話ししたいと思います。



あまり深く掘り下げることはしません。これは誰にとってもあまり興味がありませんが、このメカニズムの原理と方法論についてお話したいと思います。 したがって、ハイパーバイザーの基本的なメカニズムは次のとおりです。 RAMでは、仮想マシンの作業に役立つプロセスが常に実行されています。 このプロセスは、準備完了状態パイプラインおよび待機状態ストアと考えることができます。 他の重要度の低い仮想マシンの状態は省略していますが、現在は重要ではありません。



認識を容易にするために、すべてのvCPU仮想マシンをチェーンとして認識することを提案します。 チェーン内の各リンクは、vCPUのコアです（vSphereの世界）。 マシンには、vCPUがあるのと同じくらい多くの世界があります。 各仮想マシンに付随する、さらに2つの目に見えないサービスワールドがあります。 1つはマシン全体のサービスを担当し、2つ目はその入出力を担当します。 これらのサービスワールドによる計算能力の実際の消費量はまったく重要ではなく、メモリ消費量は各仮想マシンのオーバーヘッドインジケータによって推定できます。 仮想コアと物理コアの数が等しい物理ホスト全体のサイズのVMを作成する場合、パフォーマンスの低下が発生する可能性があることに注意してください。 この瞬間をもう少し低くします。



READYコンベアは、このようなチェーンがすべて順番にドロップされる「パイプ」です。 タイムスロットとは、物理プロセッサによって仮想マシンが実行される時間です（vCPUが実行されます）。 現時点では、仮想マシンは物理サーバーと同様にほぼ無損失であり、ハードウェアサーバー（pCPU）の物理プロセッサを使用します。 タイムスロットの最大値は、人為的に1ミリ秒のオーダーの値に制限されています。 タイムスロットの有効期限が切れると、VM vCPUはシェダーによってREADYパイプラインキューに強制的に配置されます。 Shedulerには、READYパイプライン内の仮想マシンの順序を変更する機能があります。各マシンの優先度は、現在の実際の負荷、リソースに対する権利（共有）、マシンが物理プロセッサ上にあった時間、および重要性の低いパラメーターに基づいて計算されます。 ホストにVMが1つしかない場合は、READYキューパイプラインを遅延なく常に渡すと仮定するのは論理的です。 他のVMのリソースに対する競合はありません。



シェダーはどのように仮想マシンの世界を物理コアに配置しますか？ 物理サーバーにあるコア（ハイパースレッディングを含む）と同数の幅の列があるテーブルを想像してください。 高さでは、各行はサーバープロセッサの次のクロックサイクルに対応します。 2プロセッササーバー、プロセッサあたり6物理コア、およびハイパースレッディングを想像してみましょう。 合計で、サーバーあたり24コアを取得します。 サーバーの負荷が高く、vSphereがハイパースレッディングを使用することを余儀なくされていると仮定すると、それは簡単に考えられます。 いくつかの仮想マシンがあるとしましょう：



•4個の1コア

•2コアの4個

•8コアの2個

•16個のコアのうち1個



そのため、最初の時間枠が来ると、シェドラーが申請者を選択します。 最初の車を16コアにします。 最初の16個の物理コア（pCPU）が占有され、8個が残っています。たとえば、2個のコアを持つ4つのマシンが配置されました（さらに、16個のコアを持つマシンには、NUMAで正しく動作するために2つの仮想ソケットが必要です）。 すべて、タイムスロットがいっぱいです、これは理想的です。 パフォーマンスが低下することも、pCPUがアイドル状態になることもありません。 残りの仮想マシンは現在動作しておらず、READY待機キューにあります。 「幸せな」仮想マシンのタイムスロットは同じであるとします（実際には、すべてのVMのタイムスロットは異なり、多くの要因に依存しています）。 したがって、2番目のタイムスロットが来るので、シェダーはそれを埋める必要があります。



残った無人車：



•4個の1コア

•8コアの2個



充填を開始します。8コアの車2台、各1の車4台、pCPUの空きが4つあり、最初のタイムスロットですでに動作している2コアの車を2台入れることができます。 そこには何も収まらない、収まらない。 タイムスロットは再び完全に一杯になり、電力が失われることはありません。







同様に、シェダラーは仮想マシンの世界でタイムスロットを埋め続け、これを可能な限り効率的に実行して、充填の「穴」を減らし、仮想環境の効率を高めます。



以下は、ホスト上の仮想マシンの場所のネガティブバージョンです。 1つの大きなホストサイズのマシンと1つの小さなvCPUのマシン。 リソースに対する平等な権利とパフォーマンスに対する平等なニーズにより、これらのマシンは同じ数のタイムスロットを受け取ります。つまり、プロセッサ時間をマシン間で分割します。 なぜなら 両方のマシンが同時に動作することはできないため（1つのタイムスロットに収まらないため）、順番に動作し、小さなマシンは他の誰もいない空のタイムスロットで動作します（タイムスロットは無駄になります）。 大型のマシンは、このマシンに必要な場合でも、すべての要望があり、プロセッサー時間を取得できません。 たとえば、中央処理装置の周波数が3 GHzの場合、これらのマシンは両方とも最大1.5 GHzを取得できます。







仮想化を使用すると、ホスト上に複数の仮想マシンを作成できます。また、すべてのマシンのvCPUの総数が物理ホストのpCPUの数を超える場合が発生する場合があります。 これは非常に正常ですが、同時にすべてのvCPUが消費電力の100％を取得できないことを明確に認識する必要があります。 つまり、同じ仮想化ホストに複数のロードされたマシンがあり、vCPUの合計数がホストpCPUよりも多い場合、高い確率でこれらのマシンが相互に干渉し、全体的なパフォーマンスが低下します。



ここで、ホスト全体のサイズの仮想マシンの作成に戻りたいと思います。 さて、そのようなVMが最初のタイムスロット全体を引き継いで解決するようにします。 このマシンに付随するシステムの世界について思い出してください。 ハイパーバイザー自体とそのシステムプロセスを実行する必要があるため、これらも実行する必要があります。 つまり、タイムスロットを提供し、その中の特定の数のpCPUを占有する必要があります。 そして、この時点で大きなVMは何をすべきでしょうか？ そうです、すべてのpCPUのリリースがそこに適合することを期待してください。 つまり、ハイパーバイザーのサービスタスク（タイムスロット）のパフォーマンスが失われることが保証されており、これは悪いことです（上記の例を大小のマシンで思い出します）。 たとえば、高負荷のiSCSIソフトウェアイニシエーターは、最大6 GHzのプロセッサ電力を消費します。 これは、小さなVMの場合にはそれほど顕著ではありません。 サービスプロセスと並行して（同じタイムスロットで）動作します。 また、大きなVMの場合、これは機能しません。 タイムスロット全体とそのすべてのpCPUを占有し、システムプロセスであるにもかかわらず、そのpCPUの少なくとも1つが既に誰かによって占有されている場合、タイムスロットに収まりません。

仮想インフラストラクチャが適切に構成されておらず、マシンがノードごとに配置されている場合、どのような損失が発生しますか？ ゼロから無限大まで（理論上）。 それはすべて特定の状況に依存します。



それとは別に、仮想マシンのサイズを決める際に主なルールを表明したいと思います。仮想マシンにタスクを実行できる最小リソースを与えます。 VM 2コアで十分な場合は提供する必要はありません。 2で十分な場合、4を与える必要はありません（余分なコアはタイムスロットで発生します）。 同様に、メモリを使用して、マシンに多くを与えないでください。 おそらく、ライブマイグレーション（実際には、VMメモリの量をコピーする）とNUMAで発生する問題は言うまでもなく、別のマシンでは十分でない可能性があります。



タイムスロットのpCPUにvCPU仮想マシンを展開するメカニズムがわかったので、NUMAとその割り当てルールを思い出しましょう。 ハイパーバイザーシェダーでは、タイムスロットに入力する際に​​これらすべてのルールが重要です。 タイムスロットpCPUは、異なるNUMAノードに属することができます。 現在、ホストで仮想マシンを構成する際のNUMAのアカウンティングの難しさに加えて、タイムスロットを備えたshedulerハイパーバイザーを使用する方法による制限も受けています。 VMのパフォーマンスを向上させるには、すべての落とし穴に注意を払い、次のルールに従う必要があります。



•巨大なマシンを作成しないようにします（ホストサイズと比較して）

•大型マシンの場合、NUMAテクノロジーによって課される制限を考慮する必要があります。

•ホストpCPUに関連してvCPUの量を乱用しないでください。

•いくつかの小型または中型のマシンには、常に、巨大なマシンよりも柔軟性と全体的なパフォーマンスの利点があります。



最後に、ハイパーバイザーのシェダーのI / Oの動作について説明したいと思います。 仮想マシンがその仮想ハードウェアにアクセスすると、ハイパーバイザーはVMを一時停止し、pCPUから削除して、WAITリポジトリに配置します。 この状態では、車は機能せず、ただ待機します。 この時点で、ハイパーバイザーはゲストマシンの仮想デバイスのコマンドをハイパーバイザーのコマンドに対応する実際のコマンドに変換（「偽造」）し、その後、ハイパーバイザーは仮想マシンをREADYパイプラインに返します。 仮想デバイスがマシンに応答すると、仮想マシンの同様の「フリーズ」が発生します（ハイパーバイザーは答えを再度変換する必要がありますが、反対方向に変換します）。 仮想マシンが生成するI / Oコマンドが多いほど、頻繁にWAITの「フリーズ」状態になり、パフォーマンスが低下します。 古い仮想マシンはI / Oデバイスを使用するため、ハイパーバイザーがコマンドを変換することは難しくなり、VMの待機時間が長くなります。



VMWareは、ハイパーアクティブI / Oを使用したアプリケーションの仮想化を明示的および正式に推奨していません。 仮想マシンに準仮想デバイスを使用することにより、WAITの悪影響を減らすことができます。 これは、10ギガビットネットワークカードVMXNET3および準仮想SCSIハードディスクコントローラーPVSCSIです。 仮想マシンを高速化するように設計されたハードウェアデバイスの使用は、WAITの影響と全体的なパフォーマンスの向上を減らすのにも役立ちます。 これらは、ハードウェアiSCSIオフロード、ダイレクトメモリアクセス、仮想化をサポートするネットワークカードなどをサポートするさまざまなネットワークおよびHBAアダプターです。



これについて詳しく説明します。 この記事の情報がお役に立てば幸いです。仮想インフラストラクチャの構築や運用をより効果的に進めることができます。