X86 サーバー仮想化のリソース割り当てとパフォーマンス最適化の詳細な説明

仮想化は、通常、実際のベースではなく仮想ベースで実行されるコンピューティング要素を指す広い用語です。管理を簡素化し、リソースを最適化するソリューションです。サーバー仮想化は、x86 ベースのサーバーを統合してリソースの利用効率とパフォーマンスを向上させるために使用されるテクノロジーです。

この記事では、企業のビジネス システムと管理の観点から、X86 技術アーキテクチャにおける仮想ネットワーク カード、SR-IOV、NUMA、仮想ディスク形式の対応する特性の分析と研究に焦点を当て、さまざまなアプリケーション シナリオでのリソース パーティショニングとパフォーマンス最適化ソリューションを探ります。マルチアプリケーション システムでの実践と最適な構成を通じて、X86 サーバーのパフォーマンスとリソース利用効率が向上することが期待されます。

1. x86仮想化の2つの一般的なアーキテクチャ

x86 仮想化には、ホスト型アーキテクチャとベアメタル アーキテクチャという 2 つの一般的なアーキテクチャがあります。パラサイト アーキテクチャは、オペレーティング システム上で仮想化レイヤーを実行し、ハードウェアを幅広くサポートしながらアプリケーションとして実行します。対照的に、ベアメタル アーキテクチャでは、仮想化レイヤーが x86 ハードウェア システム上で直接実行されるため、オペレーティング システムを経由せずにハードウェア リソースに直接アクセスしてハードウェア アクセスを実現できるため、より効率的です。

VMware Workstation と VMware Server はどちらもホスト アーキテクチャに基づいて実装されていますが、VMware ESX Server は業界初のベア メタル アーキテクチャ仮想化製品であり、現在第 5 世代の製品がリリースされています。 ESX Server は、優れたパフォーマンスを提供し、大規模データ センターのパフォーマンス要件を完全に満たすことができる VMware 認定ハードウェア プラットフォーム上で実行する必要があります。この記事では主に、X86 ベアメタル アーキテクチャに基づくサーバーのリソース割り当てとパフォーマンス最適化の問題について説明します。

2. x86仮想化リソース分割の3つのレベル

簡単に言えば、サーバー リソースの分割には、ネットワーク、コンピューティング、ストレージの 3 つのレベルが含まれます。各仮想マシンは、接続されたネットワーク内で特定のコンピューティング タスクを実行し、計算されたデータをビジネス用に保存します。

2.1 ネットワーク層

ネットワークの観点から見ると、X86 物理マシンは物理スイッチに接続された物理ネットワーク カードを使用します。 X86 が複数の VM 仮想マシンに分割されると、仮想ネットワーク カードと仮想スイッチが生まれます。これにより、仮想ネットワークと物理ネットワーク間のトラフィックの伝送と相互作用が生成されます。図1に示すように:

図1: 仮想ネットワークと物理ネットワーク

同じ物理マシン上の VM は、同じネットワーク セグメントまたは異なるネットワーク セグメントに分割できます。仮想マシン間のネットワーク トラフィックが物理ネットワーク カードを通過するかどうかに応じて、次の 4 つの状況に分けられます。

最初のケースでは、たとえば、業務システムの VM が同じホストの同じネットワーク セグメントにある場合、仮想マシン間のネットワーク トラフィックはホストの物理ネットワーク カードを通過せず、最大ネットワーク トラフィックは 7.6 GB になります。 (テスト方法: testvm1 で jperf サーバーをネットワーク データ レシーバーとして有効にし、testvm2 で jperf クライアントを有効にして jperf サーバーに接続し、ネットワーク データ パケットを送信して、ネットワーク トラフィックを増やします。X86 ホストにはデュアル 10G ネットワーク カードがあります)

2 番目のケースでは、たとえば、業務システムの VM が同じホストの異なるネットワーク セグメントにある場合、仮想マシン間のネットワーク トラフィックはホストの物理ネットワーク カードを通過し、最大ネットワーク トラフィックは 5.6 GB になります。テスト方法は上記と同じです。

3 番目のケースでは、たとえば、業務システムの VM が異なるホストの同じネットワーク セグメントにある場合、仮想マシン間のネットワーク トラフィックはホストの物理ネットワーク カードを通過し、最大ネットワーク トラフィックは 6.5 GB になります。テスト方法は上記と同じです。

4 番目のケースでは、たとえば、業務システムの VM が異なるホストの異なるネットワーク セグメントにある場合、仮想マシン間のネットワーク トラフィックはホストの物理ネットワーク カードを通過し、最大ネットワーク トラフィックは 4.6 GB になります。テスト方法は上記と同じです。

いくつかのテストシナリオの比較表を表 1 に示します。

表1複数のシナリオにおけるVMテストデータの比較

X86 物理サーバー上の VM ネットワーク仮想化のもう 1 つのテクノロジは SR-IOV です。 SR-IOV テクノロジーは、パフォーマンスとスケーラビリティを向上できる、INTEL が提案するハードウェア ベースの仮想化ソリューションです。 SR-IOV 標準は、仮想マシン間で PCIe (Peripheral Component Interconnect Express) デバイスを効率的に共有することを可能にし、ハードウェアに実装されてネイティブ パフォーマンスに匹敵するネットワーク I/O パフォーマンスを実現します。たとえば、X86 物理サーバー上の 10G ネットワーク カードを SR-IOV テクノロジーを使用して 4 つの仮想ネットワーク カードに分割し、4 つの VM で使用すると、ネットワーク伝送パフォーマンスは VM で使用される仮想化ネットワーク カードよりもはるかに高くなります。

テスト方法: 1 台の X86 物理サーバー上で、4 つの VM が jperf サーバーをネットワーク データ レシーバーとして有効にします。別の X86 物理サーバーでは、4 つの VM により、jperf クライアントが jperf サーバーに接続してネットワーク データ パケットを送信し、ネットワーク トラフィックに負荷をかけることができます。 2 つの X86 ホストにはデュアル 10G ネットワーク カードが搭載されています。

SR-IOV 仮想化テスト アーキテクチャを図 2 に示します。

図2: SR-IOV仮想化テストアーキテクチャ

ネットワーク経由で送信されるデータ量の比較を表 2 に示します。

通常の仮想化伝送の最大データ量は 4.6Gbps ですが、SR-IOV の直接ハードウェア仮想化では 9.4Gbps に達します。

SR-IOV 対応デバイスには、省電力、アダプタ数の削減、配線の簡素化、スイッチ ポートの削減などの利点もあります。 SR-IOV には多くの利点がありますが、多くの制限もあります。たとえば、VMWARE の多くのオリジナル機能は、SR-IOV 仮想マシンでは使用できません。たとえば、Vmotion、Storage Vmotion、Vshield、NetFlow、高可用性、FT、DRS、DPM、一時停止と再開、スナップショット、仮想デバイスのホット アドと削除、クラスター環境への参加などです。

したがって、x86 ネットワーク仮想化を検討する際には、パフォーマンス、ビジネス特性、インフラストラクチャを総合的に考慮する必要があります。ビジネスで比較的高いパフォーマンスが必要で、それ以上の柔軟性は必要ない場合は、SR-IOV テクノロジーを検討できます。それ以外の場合は、一般的な X86 ネットワーク仮想化テクノロジを選択し、VMWARE と組み合わせて展開します。

2.2計算レベル

コンピューティングの観点から見ると、X86 物理サーバー上の CPU およびメモリ リソースを仮想マシンに提供できます。今日の高性能 X86 サーバーは、一般的にマルチ CPU マルチコア システムです。 NUMA アーキテクチャは、マルチプロセッサ、マルチコア、および非均一メモリ アーキテクチャ間の相互作用によってもたらされる新しい CPU およびメモリ リソース割り当て方法の課題を解決し、大量のメモリを占有するワークロードのパフォーマンスを向上できるため、ますます普及するでしょう。 NUMA アーキテクチャを図 3 に示します。

図3: NUMAアーキテクチャ図

従来のサーバー アーキテクチャでは、メモリが単一のストレージ プールに配置され、単一のプロセッサまたはコアを持つシステムに適しています。ただし、この従来の統合アクセス方法では、複数のコアが同時にメモリ空間にアクセスすると、リソースの競合やパフォーマンスの問題が発生します。

NUMA は、メモリが CPU に提示される方法を変更する、サーバー CPU およびメモリ設計の新しいアーキテクチャです。これは、サーバー内の各 CPU のメモリをパーティション分割することによって実現されます。各パーティション (またはメモリ ブロック) は NUMA ノードと呼ばれ、そのパーティションに関連付けられたプロセッサは NUMA メモリに高速にアクセスでき、サーバー上のリソースをめぐって他の NUMA ノードと競合する必要がありません (他のメモリ パーティションは他のプロセッサに割り当てられます)。 NUMA は、任意のプロセッサがサーバー上の任意のメモリ領域にアクセスできるようにもサポートします。

プロセッサは確かに異なる領域にあるメモリ データにアクセスできますが、そのためにはローカル NUMA ノードの外部への追加の転送とターゲット NUMA ノードからの確認が必要になります。これにより、全体的なオーバーヘッドが増加し、CPU およびメモリ サブシステムのパフォーマンスに影響します。

たとえば、8 コア プロセッサ 2 基と 128 GB のメモリを搭載したサーバーの場合、NUMA アーキテクチャでは、各プロセッサが 64 GB の物理メモリを制御でき、各プロセッサの 8 つのコアのそれぞれが 8 GB の NUMA ノードに対応します。これは VM のパフォーマンスにどのような影響を与えますか?

各プロセッサ コアは NUMA ノード内のメモリに他のノードよりも高速にアクセスするため、仮想マシンのメモリ サイズが NUMA ノードのメモリ サイズ以下の場合に、仮想マシンは理論的に最高のパフォーマンスを実現できます。したがって、この物理サーバーに仮想マシンを割り当てるときは、各仮想マシンに 8GB を超えるメモリを割り当てないでください。

仮想マシンにさらに多くのメモリが割り当てられると、仮想マシンは NUMA ノード外のメモリにアクセスする必要があり、パフォーマンスに多少影響します。アプリケーションが NUMA 対応であればさらに良いでしょう。 vSphere は vNUMA を使用して NUMA 対応の仮想マシンを作成します。仮想マシンは仮想 NUMA ノードに分割され、各 vNUMA ノードは異なる物理 NUMA ノードに配置されます。仮想マシンは依然として 2 つの NUMA ノードに分散されていますが、仮想マシン内のオペレーティング システムとアプリケーションは NUMA に対応しており、リソースの使用が最適化されています。

NUMA は、データセンター サーバーでのメモリのインストールおよび選択方法に多くの変更をもたらしました。サーバーに物理メモリを追加する場合は、マザーボード上の各プロセッサに同じ量のメモリが搭載されるように、NUMA ノード間で追加したメモリのバランスを取り、一致させるように注意する必要があります。サンプル サーバーにさらに多くのメモリが構成されている場合は、メモリ モジュールをプロセッサ間でバランスよく配置する必要があります。 64GB のメモリを追加すると、各プロセッサに 32GB のメモリが割り当てられ (各プロセッサで使用可能なメモリは 96GB に増加し、サーバーの合計メモリは 192GB に達します)、各 NUMA ノードのメモリ サイズは 8GB から 12GB に増加します。

VMWARE のベスト プラクティスに沿って、VMware は一般に CPU の推奨事項を提供しており、最大 64 個の vCPU をサポートし、通常は 32 個を超えないようにし、過剰構成しないことが最善です。メモリについては一般的に推奨事項は示されておらず、ビジネスによってメモリ サイズに関する要件は異なります。もちろん、NUMA ユニット間で呼び出しを行わないのが最善です。

もう一つの注意点は、NUMA アーキテクチャはコア (Core) ではなく物理 CPU (Socket) のみをターゲットにしていることです。各ソケットは異なるメモリ スロットを制御するため、メモリ スロットが偶数であることを確認してください。たとえば、128 GB のメモリを 8 つの 16 GB メモリ スティックに分割する場合は、4 つを 1 つのソケットのメモリ スロットに挿入し、残りの 4 つを別のソケットのメモリ スロットに挿入する必要があります。 vCPU リソースを仮想マシンに割り当てるときは、1X1、1X2、1X 4、1X8、2X1、2X2、2X4、2X8 など、ソケット/コアの倍数で割り当てるようにしてください。ただし、2X3、2X5、2X7 などの組み合わせは使用しないでください。後者の組み合わせでは、ソケット間のメモリ呼び出しが発生し、パフォーマンスの低下につながる可能性があります。

2.3 ストレージ層

ストレージの観点から見ると、X86 物理サーバー上の VM は、バックエンド ストレージから割り当てられた LUN に接続されます。 LUN 上に仮想ディスクを作成するには、シック プロビジョニング (Lazy Zeroed)、シック プロビジョニング (Eager Zeroed)、シン プロビジョニングの 3 つの方法があります。図4に示すように:

図4: 3つのディスクモード

シック プロビジョニング (Lazy Zeroed) (ゼロ シック) は、デフォルトのシック フォーマットで仮想ディスクを作成し、作成時に仮想ディスクに必要なすべてのスペースを割り当てます。物理デバイスに残っているデータは作成中に消去されませんが、後で仮想マシンからの最初の書き込み操作時に必要に応じてゼロに設定されます。簡単に言えば、指定されたサイズのスペースをすぐに割り当てるということです。スペース内のデータは一時的にクリアされるのではなく、後で要求に応じてクリアされます。 Eager Zeroed Thick は、クラスタリング機能 (フォールト トレランスなど) をサポートする Thick ディスクを作成します。

仮想ディスクを作成するときに、必要なスペースを割り当てます。フラット形式とは対照的に、物理デバイスに残っているデータは作成中にゼロに消去されます。この形式でディスクを作成すると、他の種類のディスクを作成する場合よりも時間がかかる場合があります。簡単に言えば、指定されたサイズのスペースを即座に割り当て、そのスペース内のすべてのデータをクリアします。シン プロビジョニング (thin) は、シン プロビジョニング形式を使用します。最初は、シンプロビジョニングされたディスクは、ディスクに最初に必要なデータストア領域のみを使用します。後でシン ディスクにさらに多くのスペースが必要になった場合は、割り当てられた最大容量まで拡張できます。簡単に言えば、ディスク ファイルの最大拡張スペースを指定し、拡張が必要になったときにその制限を超えていないかどうかをチェックします。

さらに、シン プロビジョニング形式を VM で使用すると、シック プロビジョニング形式と比較してパフォーマンスに若干の悪影響が生じます。これは、シンプロビジョニング形式のディスクが動的に拡張され、一度に数 GB の vmdk ファイルがディスク上に生成されないためです。そのため、シックプロビジョニングディスクのように連続したディスク領域を占有することはできません。したがって、シン プロビジョニング フォーマットでディスクにアクセスする場合、ヘッドが不連続なディスク ブロック間を移動するため、アドレス指定時間が必然的に長くなり、ディスク IO パフォーマンスに影響します。
まとめると、展開でもアプリケーションでも、シン プロビジョニング形式のパフォーマンスはシック プロビジョニング形式ほど良くないため、十分なスペースがある場合は、シック プロビジョニング形式の仮想ディスクを使用することをお勧めします。

3. ビジネスニーズに基づいてx86仮想化のパフォーマンスを最適化する方法

たとえば、Linux 上の postfix メール システムには、メール サーバー、データベース、およびネットワークが含まれます。ディスクを見るときのメール システムの最大の問題の 1 つは、多数の大きなファイルの読み取りと書き込みではなく、多数の小さなファイルの読み取りと書き込みであり、これらの読み取りおよび書き込み要求が複数のプロセスまたはスレッドから同時に発生することです。多数の小さなファイルを読み書きするアプリケーション サービスの場合、メール ユーザーが配置されているディスクを割り当てるときに、シン プロビジョニング モードを使用することをお勧めします。これにより、初期スペースを大量に占有することが回避されるだけでなく、必要に応じて拡張することも可能になります。
メモリの観点から見ると、Postfix の場合、各プロセスはメモリをあまり消費しません。期待されるのは、ディスク キャッシュで大量のメモリが自動的に使用され、ディスク I/O レートが向上することです。もちろん、私たちがこれを行う必要はありません。Linux が代わりに行います。デフォルトでは、Linux 仮想メモリ管理はすべての空きメモリ領域をハードディスク キャッシュとして使用します。したがって、数 GB のメモリを搭載した実稼働 Linux システムでは、使用可能なメモリが 20 MB しかないことも珍しくありません。プロセッサの観点から見ると、メール システムは、SMTP であれ IMAP であれ、CPU をあまり占有しません。このように、CPU およびメモリ リソースを割り当てるときに、NUMA アーキテクチャに応じて固定サイズのユニットを構成できます。たとえば、サーバーが 2 つの 8 コア プロセッサと 128 GB のメモリで構成され、4 つのメール サーバーに仮想化されている場合、各サーバーに 4 つのコアと 32 G を割り当てることができます。
ネットワークの観点から見ると、メール システムはネットワーク サブシステムを頻繁に使用しますが、メール システムのボトルネックとなるのは、依然としてネットワーク スループットではなくディスク スループットです。このタイプのアプリケーションでは、強力な相互作用は必要なく、遅延が許容されるため、ネットワーク カードが仮想であるか SR-IOV であるかはほとんど影響しません。
メールシステムのデータベース サーバーでは、小さなファイルが頻繁にランダムに読み書きされるため、データベース ディスクはシック プロビジョニング モードを選択して、小さなデータ ブロックの IO を向上させることができます。
さまざまなビジネス システムでは、特定の問題に対して特定の分析が必要になります。パフォーマンスの最適化は一夜にして実現できるものではありません。ビジネスが発展し変化すると、最適化の技術的な手段や方法もそれに応じて変化します。

4.企業における日常的な利用と管理の観点から見たx86サーバの仮想化

エンタープライズ レベルのアプリケーションによって、CPU、メモリ リソース、およびスペースの使用率は異なります。 NUMA アーキテクチャを使用してリソース割り当てを最適化し、パフォーマンスを向上させる方法は、エンタープライズ データ センターの管理にとっても非常に重要です。表3を参照してください。

表3 さまざまなエンタープライズアプリケーションのリソース使用率の比較

データベース サーバーの場合、CPU とメモリ リソースの要件が高いため、複数のマシンの共有リソースには適していません。そのため、より適切な構成の物理マシンを使用するようにしてください。 VDI デスクトップおよびファイル サーバーの場合、NUMA アーキテクチャで固定の CPU およびメモリ ユニットを割り当てる方が適しています。メールシステムは、特定の状況に応じて NUMA アーキテクチャのリソース割り当てを行う必要があります。オンデマンドで変更される Web サイトの場合、すべてが NUMA に適しているわけではありません。たとえば、Web サイトのキャッシュ サーバーは、非 NUMA アーキテクチャのメモリ割り当てに適しています。ディスク領域を割り当てる場合、シックプロビジョニングは、IO パフォーマンス要件が比較的高いビジネス システムに適しています。シン プロビジョニングは、IO パフォーマンス要件が低く、ビジネス成長の余地が限られているビジネス システムに適しています。

5. 結論

X86 サーバー仮想化は、サーバー リソースを統合し、効率を向上させるために使用されるテクノロジです。 X86 仮想化により、サーバー ハードウェアとシステム リソースの利用率が向上し、透過的な負荷分散、動的移行、自動障害分離、自動システム再構築、およびよりシンプルで統一されたサーバー リソース割り当て管理モデルを備えた信頼性の高いサーバー アプリケーション環境が提供されます。リソース分割後の X86 サーバー仮想化のパフォーマンス最適化により、データセンターの全体的なリソース使用率も大幅に向上し、今日の新しいグリーンエネルギー節約の概念と一致しています。