仮想化には多くの課題があり、仮想ハードウェアを選択したときはいくつかの重要な基準を考える必要はあります。それらはホスト上に置く仮想マシン(VM)の数やLUN(logical unit number)があります。
もし、それらの数値を決めない時は、仮想インフラはパフォーマンスの低減に陥ります。ここではVMware vSphereインフラでのそれら数値について考えてみます。
・仮想化ハードウェア連係割合:
詳細な連係割合をえるたの2つの手法:
○スケール・アップ:この手法ではユーザは現状の物理サーバへリソースを追加するか、新規で、さらに強力なホスト(例:48コアと512GBメモリをサポートできる8ソケットサーバ)を追加する。
○スケールアウト:このアプローチは小さな、物理マシン(例:8コアと128GBメモリをサポートする2ソケット・サーバ)を追加する、それでいくつかのマシン間でリソース負荷を分散できます。
各手法の長所と短所:スケールアップではユーザがいくつかの物理サーバを購入しますが、サーバが故障している期間多くの数のVMがクラッシュするリスクは増加します。一方スケール・アウト時、ユーザは多くの物理サーバを購入・管理します。しかしスケール・アウト・アーキテクチャはさらに柔軟なクラスタ・デザインを提供し、このデザインでサーバ故障は少ないVMに影響します。
多くのユーザはスケール・アウトを選択し、大型と小型サーバ間のスイート・スポットは4-6コアでメモリが256BMでの2から4CPUソケットのサーバです。
中規模VMワークロードでは、2ソケット、ミッドレンジ・サーバは16対1の圧縮比で、4ソケット・サーバは32対1に届きます。これらの仮想化ハードウェア統計はワークロードの依存します。
・仮想CPUカウントの覚え
VM対ホスト比率は一般的なパフォーマンス測定です。VMが複数の仮想CPU(vCPU)を使用できることで、vCPU対物理CPU(pCPU)比率はさらに制度の高いハードウェア測定です。慎重な比率は通常4対1です。
例えば12CPUコアを持ったホストは48 vCPUのサポートが可能です。CPUワークロードが低い場合は、 8対1 vCPU対pCPU比率に届くことが可能で、重たいワークロードではたった2対1です。
VMにアサインされた多重vCPUs (or vSMP)はまたvCPU対pCPU比率に影響します。 VMware CPUスケジューラにとってはシングルの vCPU VM用にCPUタイムを割り振ることは簡単です。ホスト上のトータルなVM数は、もしvSMP VMがいくつかあれば増加します。(特に4以上のvCPUでは)
・大きな絵を描く
仮想化はリソース使用を合理化し、DRS(Distributed Resource Scheduler)やDPM(Distributed Power Management)のような高度な機能はホスト・リソースをバランス化し無駄なアクティビティを削減します。
VMwareのHA(High Availability)機能はフェイル・オーバしたVMからのリソース負荷を吸収するために他のホスト用に充分な予備容量を持つ必要があります。ユーザのワークロードといくつ同時ホスト障害から保護したいかで、ユーザはホストを70%の使用率で稼動することができます。
・LUNと共有ストレージ・パフォーマンス
共有ストレージ(またはLUN)で稼動するVMの数はまた重要な測定基準です。1つのLUNで多数のVMはメタデータ・ロッキング問題(SCSIリザベーション)を発生させます。
LUN上で常駐するVMの最適な数はいくつかの変数に依存しますが、次のアドバイスは基準値です。
○VM/LUNの平均数は14-16
○アプリケーション・サーバのような軽いI/Oワークロード用:100VM+/LUN
○アプリケーション・インテンシブなディスクI/O用:8-10 VM/LUN
○低から中程度のワークロード:20-22 VM/LUN
いくつかのケースではLUNのさらなるVMを配置できます。特に低I/O要求な仮想デスクトップ・インフラ・インプリメンテーション。
ユーザのストレージ・サブシステムはこの方程式では大きな役割を背負っています。RAIDグループでのディスク・スピンドルや大きなキャッシュがあれば、多くのVMを可能とします。
・100%仮想化を避ける
vSphereの成熟と改善により、どんなワークロードの仮想化が可能です。100%の仮想化データ・センターはもちろん達成可能ですが、それをすべきということにはなりません。
仮想環境は複雑で、その依存性と故障は大きな影響があります。ドメイン・ネーム・サーバ、ダイナミック・ホスト・コンフィグレーション・プロトコール、AD(アクティブ・ディレクトリ)は接続するデータ・センター・サーバとクライアントはクリティカルなサービスです。ストレージ・エリア・ネットワーク(SAN)や、ネットワーク・スイッチなどのメジャーなコンポーネントの損失はユーザの大部分の仮想環境の提供を不可能とします
物理サーバで稼動するクリティカルなサービスは依存度が低いです。それで、環境障害による影響は少ないです。物理サーバは事故後の回復が早いです。結果としてユーザ環境の90%から95%の仮想化は充分です。
勿論、仮想化は数値ですが、仮想ハードウェア目標に挑戦的にならないことです。データセンター・パフォーマンスとアップタイムは最も重要な数値です。パフォーマンスと利用度を犠牲にすることなく確実な仮想化ハードウェア数値を達成するには、ユーザはアーキテクチャとコンフィグレーションを決定する影響を理解することが必要です。
関連トピックス:
- VMware vCenter サーバは仮想化にすべきかどうか?
- 仮想化のディザスタリ・リカバリ・プランに関するエッセンシャル・チェックリスト(プレゼンテーション)
- 仮想ハードウェアバージョン8の仮想マシンをVMware vSphere ESX4.1へクローン、移動はできません。【VMware vSphere 5】
- VMware vCenter Operations(パフォーマンス・モニタリング・バッジ)の概要
- vSphere5.1上に仮想マシンでvSphere5.1を構築するには
- VMware vSphereのための仮想化データベース・パフォーマンス・モニタリング
- VMware, 技術白書「The VMware Reference Architecture for Stateless Virtual Desktops on Local Solid-State Storage with VMware View 5」を発刊
- VMware vCenter Converter の概要紹介【VMware環境管理 VMware vCenter】