こうした傾向はCPUだけでなくメモリモジュールやディスクなども同様のため、やみくもに集約度を上げるのではなく、性能当たり、容量当たりのコストパフォーマンスを考慮することをお勧めしたい。逆にローエンドな構成にした場合に、上位の構成と比べると性能の割に安くない、というケースもあるため、バランスが重要といえる。

　また、サーバ仮想化環境の推奨ハードウェア構成は、サーバ仮想化ソフトウェアの機能によっても左右される。サーバ仮想化ソフトウェアの機能は、単体ではなく複数の物理サーバを組み合わせてクラスタ化することで実現されるものが多数ある。クラスタを構成する際にはストレージやネットワークにまで考慮事項が及ぶ。

　よって、サーバ仮想化環境のハードウェア構成を考える際には、サーバ仮想化ソフトウェアのどのような機能を使って運用を行うか、というところまで想定した上で、詳細なハードウェア構成に落とし込むのが望ましい。

　この想定が不十分なまま、ハードウェア構成が先に決められた状態で話が進んでしまうと、あまり望ましくない構成や、最悪の場合サポート外の構成であることが後から判明する可能性もあるため、注意していただきたい。

ハードウェア選びのポイント

　サーバ仮想化環境で利用するハードウェアを選ぶ際、サーバのCPU、メモリ、内蔵ディスク、ネットワークインタフェース（NIC）などのコンポーネントは注文段階でカスタマイズ可能な構成要素である。また、共有ストレージについてもさまざまな選択肢が存在する。ここでは、それぞれについて選び方のポイントを解説する。

仮想化支援機能

　ミッドレンジ以上ではあまり気にする必要はない場合が多いが、特に安価なローエンドのサーバにおいては、仮想化支援機能の有無に注意する必要がある。仮想化支援機能が部分的にしか搭載されないケースがあるためだ。

　仮想化支援機能には主として、CPU処理を支援する機能（Intel　VT-x、AMD-V）とI/O処理を支援する機能（Intel VT-d、IOMMU）がある。サーバ仮想化が普及し始めた当初は、サーバ購入時に選択可能なCPUに、これらの機能が搭載されていないモデルも多くあったが、現在ではCPU処理の支援についてはほとんどのモデルに搭載される。一方、特にローエンドのサーバにおいては、I/O処理の支援機能を搭載しない構成が選択可能な場合もある。従って、PCIスロットに搭載した物理デバイスをVMに認識させるパススルー機能を使用する場合などには確認が必要である。

CPU

　CPU単体に目を向けるとコア数とクロック周波数で比較することになる。仮想化環境では多数のVMを同時稼働させるが、単一のOS上で複数のプロセスがCPUを時分割で利用するのと同様に、VMがCPUコアを時分割で利用することになる。そのため、CPUコア当たりのVM数があまりに多過ぎると、CPUコアを利用するVMを切り替える処理によるオーバーヘッドや、CPUキャッシュの利用効率の低下などにつながる。逆に言えば、CPUコア数を増やすことは集約度を上げることにつながる。

　前述の通り、1コア当たりのVM数には限界があるため、クロック周波数については集約数よりも、VMが必要とする性能の観点で考える。サーバ仮想化環境では、VMに対して時分割でCPUが割り当てられる仕組みのため、VMの仮想CPU1つ当たりの最大性能は、物理CPUの1コア分が上限となる。例えば、クロック周波数が3GHzのCPUであれば、仮想CPU1つ当たりの最大性能も3GHzとなる。複数の物理CPUの性能を1つの仮想CPUに足し合わせることはできない。そのため、CPUコア単体の処理能力が求められるようなアプリケーションを動作させる用途が見込まれる場合には、物理CPUのクロック周波数も考慮する。

　使用するサーバ仮想化ソフトウェアやミドルウェアのライセンス形態によって、CPUの搭載数（ソケット数）にも注意した方が良い。具体的には、利用するソフトウェアのライセンスの計算方法がソケット単位かホスト単位かによって、ソフトウェアのコストに大きな差が付く。

　サーバ単体ではなく、サーバ仮想化環境全体に目を移すとCPU世代（機能）の統一についても考慮が必要である。サーバ仮想化環境では、稼働中のVMをホスト間で移動するライブマイグレーションや、ホストのダウンに巻き込まれたVMを自動で再起動する高可用性（HA）機能を用いて可用性を担保する。これらの機能を利用する場合には、サーバをクラスタ構成にするが、そのための要件としてCPUの世代を統一する必要がある。CPUの機能をマスクすることで異世代CPUでもクラスタを組むことが可能だが、あえてCPU機能を無効化するため、わずかながらも性能に影響する可能性がある。

　とはいえ、社内の部門がバラバラな時期に導入したサーバを統合するケースなどでは、サーバを同じ時期に一斉に入れ替えられるとは限らない。そのような場合はせめて、ある程度まとまった台数を何段階かに分けて入れ替え、同一のタイミングで調達したサーバごとにクラスタを構成するのが望ましい。

メモリ

　搭載メモリの選択に当たっては、CPUによる影響を考慮する必要がある。

　CPU1つ当たりに搭載可能なメモリ枚数は決まっており、シングルソケットのサーバであればCPU1つで利用可能な数のメモリスロットしか搭載されていない。一方、マルチソケットのサーバではメモリスロットに空きがあっても、CPUの搭載数によって実際に利用可能なメモリ枚数が制限されることになる。Nehalem以降のインテル製CPUやAMDのOpteronはメモリアーキテクチャがNUMA（Non-Uniform Memory Access）であり、メモリコントローラーをチップセットではなくCPUに内蔵している。そのため、サーバに複数のCPUを搭載した場合には、各CPUソケットとメモリスロットの対応関係を考慮してメモリを搭載するなど、メーカーからの指示に応じた対応が必要となる。

　また、メモリの搭載枚数についてはチャネル数を考慮する。CPUのモデルによって、デュアルチャネル、トリプルチャネル、クアッドチャネルのように、複数のメモリチャネルを束ねて転送速度を向上させたモードが利用可能であるが、これを十分に活用するには対応するチャネル数の倍数のメモリ枚数を搭載する必要がある。トリプルチャネル対応のCPUを搭載したマシンに、3の倍数ではない枚数のメモリを搭載しても動作はするが、チャネルを束ねた動作ではなくなるため、性能を生かしきれないことになる。

　例えば図1は、CPUソケットが2つあり、トリプルチャネル対応で、それぞれのCPUに対応するメモリスロットが9つずつあるサーバの例である。この場合、CPUを1つしか搭載しない場合、左側の9枚のメモリスロットしか活用できない。トリプルチャネルを活用するためには、メモリを3の倍数で搭載する必要がある。また、メモリ搭載枚数が3枚や6枚の場合には、ソケット番号の1から順に寄せるのではなく、3つのチャネルを使うように1・4・7、2・5・8という3枚1組で搭載する必要がある。

　Nehalemよりも前、Coreマイクロアーキテクチャまではメモリコントローラーがマザーボードに搭載され、デュアルチャネルまでの対応であったため、2の倍数での調達が基本であったが、現在はCPUにより異なるため注意が必要である。

　なお、実際のメモリ搭載位置については必ずメーカーのガイドに従うよう注意してほしい。

ストレージ

内蔵ストレージ

　サーバ仮想化環境においては、可用性を考慮する必要性のないVMを除いては、ライブマイグレーションや高可用性機能を利用するため、VMのデータは共有ストレージに格納するケースが多い。そのため、内蔵ストレージに格納されるのはハイパーバイザーのブート領域や、メモリ不足時のスワップ領域（機能の有無はハイパーバイザーにより異なる）などに限られる。

　SSDやフラッシュストレージをサーバに内蔵することで、スワップ発生時のパフォーマンス低下を抑える機能を持ったハイパーバイザーもあるが、こうした機能はあくまで最終手段としての保険であり、そもそもメモリ容量がひっ迫した状態での運用は避けるのが賢明である。

　容量については、スワップ領域をローカルストレージに指定した場合には、稼働するVMのメモリサイズに応じて使用する可能性のある領域が増えるが、メモリが不足している状況を除いては、アクセス頻度が高い領域ではないため、性能面よりも可用性を重視してRAID 1などの方法で保護を行うことが重要である。

共有ストレージ

　共有ストレージにはさまざまな選択肢があるが、接続方式としてはFibre Channel（FC）、FCoE、iSCSI、NFS、CIFSなどがある。どの方式が利用可能、あるいは推奨されるかというのは、利用するハイパーバイザーによって異なる。これは、ハイパーバイザーによって接続先のストレージにどのような形式でデータを格納するか（どのようなフォーマットなのか、仮想HDDがイメージファイル／ブロックデバイスのどちらなのか、など）に差異があり、ハイパーバイザー側の機能と相性のよいストレージが異なるためである。

　数年前であれば接続速度の点からFCが選択されることが多かったが、10ギガビットイーサネット（GbE）の登場によってiSCSIやNFSでも高いパフォーマンスが得られるようになっており、選択の幅が広がったといえる。ストレージのタイプを先に決めるのではなく、利用するハイパーバイザーや機能を想定し、推奨されるものを確認した上での選択が望ましい。

　また、ストレージの機種によってはハイパーバイザーとの連携機能を持っているものもあり、パフォーマンスの最適化や管理の統合が可能な場合もある。

　なお、サーバ仮想化ソフトウェアの最近のバージョンでは、共有ストレージを持たずにローカルストレージ間でライブマイグレーションを実行できるものが出てきている。これにより共有ストレージが完全に不要になると誤解を生むことが多いが、高可用性機能には共有ストレージが必要となる。ソフトウェアレベルで仮想的な共有ストレージを実現する代替ソリューションも存在するが、性能や要求スペックなどの理由で物理的な共有ストレージからは置き換えづらい場合も多く、共有ストレージが不要となったわけではない。また、ローカルストレージ間のライブマイグレーションは、仮想HDDをネットワーク越しに転送するため、メモリデータのみを転送する従来のライブマイグレーションよりも所要時間や負荷が非常に大きいため、あまり頻繁な利用は望ましくない。ライブマイグレーションによるホスト負荷の平準化などを行うなど、多数のVMを頻繁にライブマイグレーションする可能性がある場合には、従来通り共有ストレージにVMを配置するのが現実的であるといえる。

　ストレージ装置に搭載するディスクについても注意が必要である。サーバ仮想化環境では、多数のVMによる仮想HDDへのI/Oが同一の物理ディスクに対して集中することになるため、ディスクの性能が低いと環境全体に悪影響を及ぼすことになる。SATAやニアラインSASなど、回転速度が1分当たり7200回転のディスクでは明らかにIOPSが不足するケースが非常に多いため、SASを選ぶ方が安全である。この点は仮想HDDへのI/Oに限らず、バックアップ領域などにおいてもバックアップジョブに要する時間短縮などの観点から、基本的にSASのディスクを使用することをお勧めする。

ネットワーク

　サーバに搭載するネットワークインタフェース（NIC）は、サーバを設置する物理ネットワーク環境とセットで考えるべき部分である。

　サーバ仮想化環境におけるネットワークの用途には、主に以下のものが挙げられる。

• 業務ネットワーク：VMが他のホストやVMと通信を行う
• 管理ネットワーク：管理者や管理サーバがハイパーバイザーにアクセスする
• ストレージネットワーク：ハイパーバイザーとストレージ間の通信を行う
• ハートビート：ハイパーバイザーの死活監視用の通信を行う
• ライブマイグレーション：ハイパーバイザー間でVMのメモリデータを転送する

　これらのネットワークをどのように物理NIC構成に結び付けるかは、性能と冗長性を考慮する必要がある。

　10GbEであれば十分な帯域を確保しやすいが、サーバ設置先のネットワーク環境が1GbEである場合もまだ多い。規模や稼働するVMの用途にもよるが、業務ネットワークやストレージネットワークは多数のVMによるワークロードをさばくことになるため、1Gbpsでは帯域不足となる可能性がある。また、ライブマイグレーションを実行する際にも一時的にネットワーク帯域を多く使用する。対応としては、高負荷となる可能性のあるネットワークは物理的に別のNICを使うように構成するといった方法がある。ただし、何の通信トラフィックを分割する設定ができる、あるいは分割が推奨されているかはハイパーバイザーごとに異なるため、事前にハイパーバイザーのマニュアルやホワイトペーパーを確認する必要がある。

　他には、Active／Activeのチーミングで複数の物理NICを束ねる方法があるが、こちらもハイパーバイザーによってチーミングのモード（挙動）や要件が異なるため、使用するハイパーバイザーがどのような動作のチーミングモードに対応しているかは、事前に確認しておくべき点である。

　冗長性については、いずれ用途のネットワークにも求められる要件であるため、各NICをチーミングするのに加え、スイッチなど経路の冗長化にも考慮する必要がある。

　上記のように帯域幅と冗長性、いずれを考慮した場合もNICチーミングを行うため、自ずとNICの枚数は多くなる。近年はサーバの調達段階で10GbEインタフェースを搭載できるようになっており、複数の用途を単一の物理ネットワークに集約できて効果的ではあるものの、既存のネットワーク環境にサーバを増設する場合などはスイッチが1GbEの場合も多い。そのような場合には用途ごとのネットワーク分離と冗長化を行った結果、思った以上に必要NIC数が多くなる可能性がある点に注意しておきたい。

ハードウェアを最初に決めない

　今回はサーバ仮想化環境で利用するハードウェアを選ぶ際の、基本的なポイントについて解説した。これらはあくまで特定のハイパーバイザーや特定のハードウェアベンダーに依存しない内容を書き並べてきた。実際にハードウェアを選ぶ際にはハードウェアベンダーごとに独自の管理ツールや監視ツールも組み合わせて導入することが多い。コモディティ化されたサーバ環境においては、それらの部分がハードウェアベンダーごとの差別化要素となっている点も知っておいていただきたい。

　最後に、繰り返しになるが、サーバ仮想化環境に最適なハードウェアは「これ」と言い切れるものではなく、どのような観点を評価するかによって異なってくる。しかし必ず注意すべき点として「利用する機能や運用イメージを考慮せずにハードウェアだけを先に決めない」という点には注意し、サーバ仮想化ベンダーの公開しているホワイトペーパーなども参考にして、後から後悔しないハードウェア選びをしていただきたい。