第1回 最新モデルを意識したCPUとメモリのサイジング：Windows Server 2012 R2時代のHyper-Vサーバ設計術（3/3 ページ）
仮想化が一般化した昨今のサーバ・システム。旧サーバの延命が目的だった数年前とは違い、最初から仮想環境上で動作させることを前提としたシステムが求められている。本連載では、Windows Server 2012 R2のHyper-Vをベースにして、今使える仮想化システムの技術トレンドや設計、機器の選択方法などについて解説する。第1回では、CPUとメモリのサイジングについて解説する。
親パーティションのリソース消費量
先ほどから仮想マシンばかりに目を向けているが、Hyper-Vでは仮想マシン以外にも「親パーティション」と呼ばれる管理OS（ホストOS）が稼働している。このOSはHyper-Vに最適化されたものではなく、普通のWindows Server OSが利用され、仮想スイッチやデバイスのI/O処理、仮想マシン管理などを担っている。VMware ESXiのVMkernelに相当するものであるが、Hyper-Vの場合は普通のWindows Server OSが稼働していることもあり、それなりのリソースが消費される。
- プロセッサ： 2コア程度
- メモリ： 2〜3Gbytes
これらをどのようにサイジングに盛り込むかであるが、メモリについてはこの量を占有するものとして確保しておこう。しかしプロセッサ・コアについては、占有するかどうかはシステムの用途次第だ。
前ページのCPUサイジングでは物理コアをベースにしているが、実際のところは負荷が軽く、割り当てられたコアをほとんど使わない仮想マシンもあるかもしれない。そういった仮想マシンがいくつもある場合、この余力で親パーティション分のCPU消費を賄うようにすることもできる。逆に、こういったCPUのオーバーコミットは行わず、各仮想マシンの性能をできるだけ保証したいケースでは、親パーティション分も占有で確保しよう。
なお、親パーティションはServer Coreインストールでも動作するため、これを使えばメモリやディスクの消費量を改善できる。ただし、CPUの消費量についてはあまり期待できないほか、Server CoreはUPSやハードウェア監視、バックアップといったサードパーティ製品のエージェント・ツールが正常動作しないケースもあるので、事前検証を行おう。
仮想スイッチの処理負荷にも注意
親パーティションのCPU負荷だが、環境によっては2コアでは不足することがある。見落としがちな原因は仮想スイッチの処理負荷だ。
10Gbpsや40Gbpsなどの高速・広帯域なネットワークスイッチ機器には高性能な処理チップが搭載されていることを思い出してほしい。Hyper-Vも親パーティションにネットワーク・スイッチ（仮想スイッチ）が実装されているが、ソフトウェア・ベースのため、データ転送やスイッチング処理はすべてCPUが担うことになる。Hyper-Vは、ほかのハイパーバイザより仮想スイッチの負荷が少し高い傾向があるが、従来一般的だった1GbpsであればCPU使用率は1桁程度であったために問題視されなかった。
しかし、現在主流の10Gbpsになると帯域は10倍となる。1秒間に10倍のデータが流れるため、仕事量、つまりCPU負荷も10倍に跳ね上がってしまう。1GbpsでのCPU使用率が7％だとしたら、10Gbpsでは70％にもなり得るのだ。
この問題については、プロセッサ・ベンダであるIntelなどが推進する「SR-IOV（Single Root I/O Virtualization）」といった、ハードウェア側の技術を併用して対策していく必要がある（詳細なネットワーク設計については第3回で解説する。）。
図5「サーバ・サイジングのイメージ」
サーバ・サイジングは、プロセッサやメモリなどを消費する「需要側」と、サーバに実在する「供給側」のバランスが重要である。特に、Hyper-Vについては仮想マシンだけでなく、通常のWindows Server OSが稼働する親パーティション部分のリソースや仮想スイッチの負荷についても忘れないようにしたい。
メモリのオーバーコミット
先ほどのCPUオーバーコミットと同様に、メモリについてもオーバーコミットの概念がある。Hyper-VではWindows Server 2008 R2から「動的メモリ（Dynamic Memory）」という名称で導入されているが、従来VMwareを運用していたユーザーは勘違いを起こしやすい。
メモリ・オーバーコミットは言葉のとおり、許容範囲をオーバーして設定してしまうことだ。メモリを10Gbytesに設定した仮想マシンを4台稼働させる場合、サーバには最低でも40Gbytesのメモリが必要になるが、32Gbytesしか搭載されていないサーバで動かしてしまおうという技術である。不足分の8Gbytesを吸収するには、どこかで容量を削減し、それをゲストOSに気づかせない何らかの“まやかし”が必要になる。
こういった手法はストレージ側で技術が進んでおり、各社の仮想化製品はそれらを参考に、主に4つの手法でメモリ・オーバーコミットを実現している（表3参照）。
| 方式 | 説明 | Windows Server 2012 R2のHyper-Vでの対応 |
|---|---|---|
| シンプロビジョニング | 割り当てサイズにかかわらず、実使用量のみをメモリ上で確保する。確保済み領域を解放するために「バルーニング」という技術を用いる | ○（動的メモリ） |
| 重複排除 | ほかの仮想マシンと同じデータは重複を省いて1つだけにする | − |
| 圧縮 | アクセス頻度の低いデータは圧縮してサイズを縮小する | − |
| 階層化 | アクセス頻度の低いデータをディスクに退避する。「スワップアウト」という仕組みを用いる | − |
| 表3「x86仮想化におけるメモリ・オーバーコミットの実現方式」 x86仮想化におけるメモリ・オーバーコミット技術は、ストレージの技術を参考にしている。大きく4つの手法があり、Hyper-Vの動的メモリはシンプロビジョニング方式だ。 | ||
Hyper-Vの動的メモリではこのうちのシンプロビジョニング方式しか採用していない。ある時点で仮想マシンが使っていない領域はストック（プール）に返却され、メモリ不足の仮想マシンに融通するだけだ。重複排除や圧縮・階層化は行わないため、すべての仮想マシンがメモリ不足を主張し、ストックが枯渇してしまえばそこまでになる。
ここでサイジングの話に戻ろう。Hyper-Vのメモリ・オーバーコミットはメモリ領域をハイパーバイザ側のストックで集中管理し、必要な際に領域を借り受ける仕組みであるが、サーバにはメモリをどれだけ積んでおけばよいだろうか？
運用者の視点で言えば、ストックが枯渇してメモリを借りられなかったことでゲストOSやその上のアプリが止まってしまった、などといった障害は許されない。となると、サイジングの際には動的メモリはあまり意識せず、親パーティションや各仮想マシンの安定稼働に必要なメモリサイズを単純に積み上げて見積もることになる。
では、動的メモリを使えるのはテスト環境くらいで、実運用では役に立たない技術なのだろうか？
必ずしもそういうわけではない。例えば、容量見積もりの結果、メモリがほんの少しだけ足りないといった場合は、動的メモリで融通し合うことでその誤差を切り捨てて考えてもおそらく問題はないだろう。
また、通常時は4Gbytesのメモリで十分な2台の仮想マシンがあり、片方は昼間にだけ10Gbytesまで拡大し、もう片方は夜間にだけ10Gbytesまで拡大するものとする。この場合、先ほどの計算ではこの2台で10Gbytes＋10Gbytes＝20Gbytesのメモリが必要になるが、どちらも同時に拡大しないことが確実なのであれば、動的メモリを利用すると必要なメモリを10Gbytes＋4Gbytes＝14Gbytesで済ませることができる。
動的メモリはHyper-Vのバージョンが進むごとに改善されている。Windows Server 2012では親パーティションに必要なメモリ容量を自動保護するようになったほか、再起動時に突発的に大きな容量が必要になった場合に限って、ディスク・スワップを用いるようになった（スマート・ページング）。さらに、Windows Server 2012 R2では多くのLinuxゲストで動的メモリを利用できる。
メモリの搭載単位に注意
以上ではGbytes単位のメモリサイジングを解説したが、実際のところはそこまで細かくサイジングしても意味がないかもしれない。というのはメモリの搭載単位の関係で、サーバに搭載する物理メモリの容量を細かく指定できない実情があるためだ。
現在のx86プロセッサは、「NUMA（Non-Uniform Memory Access）」と呼ばれる、各プロセッサにメモリがぶら下がるアーキテクチャを取っており、しかも広く採用されている2ソケット・サーバではIntel、AMD共にメモリ・チャネルが4つとなっている。性能と安定性から、メーカーの推奨するメモリ・モジュールの搭載単位は「チャネル数×プロセッサ・ソケット数」であるため、2ソケット・サーバの場合はメモリ・モジュールを8枚単位で搭載するのが原則だ。
だが現在広く流通しているメモリ・モジュール（DIMM）の最低容量が4Gbytesであることを考えると、メモリの搭載・増設の単位は、最低でも32Gbytesになる。このため、例えば計算上36Gbytesのメモリ容量が必要な場合、64Gbytes（4Gbytes×16枚または8Gbytes×8枚）搭載するか、動的メモリによる削減を前提に32Gbytes（4Gbytes×8枚）という構成にすることになる。
図6「2ソケット・サーバのメモリ搭載単位」
現在主流の2ソケット・サーバでは、「クアッド・チャネル」という並列に接続された4つのメモリを束ねて利用する方式を採用している。非常に高速であるが、図中の色付けのとおり、同じ容量のメモリ・モジュール（DIMM）を8枚ずつセットで搭載していかなければならない。詳細なDIMMの装着規則は次の通りである。
・各プロセッサには4つのメモリ・チャネルがある。4つのチャネルを同時に動作させると最大限のパフォーマンスを発揮できるので、4つのチャネルに同時に同じ仕様のメモリを装着するのが原則である。
・各チャネルには最大3つのメモリ・スロット（DIMMソケット）があり、3つまでDIMMを装着できる。
・利用できるDIMMの種類は、DDR3のRDIMM（レジスタ付きDIMM）、LRDIMM（Load Reduced DIMM）、UDIMM（アンバッファDIMM）のいずれか。混在は不可。ただしUDIMMの場合は1チャネルで2つまでしか使えない（一番内側のスロット＝バンク3は空けておく）。
・スロットはCPUから遠い方（バンク1の方）から順に装着する。
実際のサーバ製品のDIMMスロットの例を次に示す。
図7「最新サーバのメモリ・スロットの例」
これは、2ソケット・サーバとしてよく導入されている「HP ProLiant DL380p Gen8（製品情報のページ）」（日本HP）の内部写真。図6と同じ24個のメモリ・スロットを搭載しており、各プロセッサに4つのチャネルが用意されている。装着順序を誤らないよう、バンク1のスロット（DIMMソケット）は白くなっている（白いスロットがバンク1、そこからプロセッサ側に向かって順にバンク2、バンク3となる）。LRDIMMを使うとシステム全体で最大768Gbytes（32Gbytes×24）まで搭載できる。RDIMM なら最大384Gbytes（16Gbytes×24）、UDIMMなら最大128Gbytes（8Gbytes×16）まで搭載可能。
今回は、サーバ集約率の算出に必要なCPUとメモリのサイジングについて解説した。次回はストレージ周りの設計について解説する。
Copyright© Digital Advantage Corp. All Rights Reserved.