2G.LinuxもWindowsも必要

2G(第2世代、2009年〜) 

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPU数は1または2系統搭載された。

x64アーキテクチャ	周波数（GHz）	2nd Cache（MB）	HyperTransport	Core	TDP
Opteron 2344 HE	1.7	2	1GHz	4	68
Opteron 2350	2	2	1GHz	4	95

概要

プライベートクラウドの第2世代では、まずは従来のSolaris Zone(コンテナ)を用いたDimensionPlusを線形進化。これがPhase2Server「Solaris x64VPS」という名前でサービスインすることとなる。

加えて、システム構築にはLinuxもWindowsも必要となったことから、VMware ESXiを利用していく。

ハイパバイザ

まずSolaris系サービスは、Solaris 10よりもLinuxに歩み寄りより革新的な機能を持ったOpenSolarisをラインナップに追加した。当社自身でコンテナ専用のOpenSolarisベースのディストリビューションを作成。これはコンテナ稼働のためだけに、必要なOpenSolarisのリソースセットを持ち、USBメモリで起動してオンメモリのRAMDISKだけで稼働するものだ。ブート用のストレージも不要となり、コンピュートノードのコストダウンにも寄与する(※ただしこれはその後、USBメモリの耐久性の低さやIOPSの低さ、バスとしての安定性の低さから終局していく)。

一方、このジェネレーションで導入されたハイパバイザとして、VMware vSphere ESXiが採用されたことが大きい。Solarisだけでシステム全てを構築するには無理もあり、システム構築にはLinuxもWindowsも必要となるためだ。

VMware ESXiを採用したのは、Type Iのハイパバイザながら商業的な実装であるVMwareがパフォーマンス的に優れていたためだ。

XenのようにType Iとしてストイックな実装のハイパバイザの場合、Guest Domain(仮想マシン)からIOリクエストを投げる際、一旦、ハイパバイザが受け取り、Dom0(ここではIO仮想ドメインと解釈する)で仮想化処理を行い、Dom0のデバイスドライバでハードウェアにアクセスする。ハイパバイザはPCIなどのリソースの大半をDom0にパススルーしているため、Dom0からはハードウェアが見えている為だ。

この方法は、Type Iハイパバイザとしてはアカデミックな実装であり、ハイパバイザを極小化、つまりマイクロハイパバイザにすることができる。一般に、もっともバグが入り込みやすいと言われるのはデバイスドライバで、これをハイパバイザから除去できるメリットは大きい。実装方法によっては、コントロールドメインがクラッシュしても、ゲストドメインがサスペンドするだけで済む場合もある(※これは理論的な話しであり、プロダクションのXenではDom0のクラッシュ、再起動でDomUが動き続ける事はない)。隔離性も高く、コントロール層の独立性も高い。

しかし、この時期のCPUやメモリは速度がそれほど速いわけでもなく、このレイテンシの遅さが顕著な性能劣化を引き起こす。そのため、プロダクション環境になると速度が出づらくなってしまう。

そこでVMware ESXiでは、Type Iのハイパバイザながらハイパバイザ側にドライバを持つことでIOを速くするという実装を行っている。このデメリットは、Xenのメリットと繋がるわけだが、現実問題、Xenのような実装であったとしても、デバイスドライバのクラッシュがGuest Domainを止めると言う問題は回避しにくい。その代わり、仮想Switchなどのデバイス仮想化Daemonの高負荷には弱いというボトルネックはある。

いずれにしても、この当時のハードウェアの現実解としてVMware ESXiは、ちょうど良い収まりどころになっていた。

CPU

ESXiのようなType I ハイパバイザを使う場合、ゲストOS用に異なるOS、カーネルを利用できるため、高度なIO管理やメモリ管理が必要になっていく。IO関連の仮想化はいち早くCPUに支援機能が実装され、またハイパバイザ自体にもパラバーチャリゼーションドライバが実装されたりしたことで、ベアメタルに比べてボトルネックは減ってきたが、メモリ確保にはロスが起きていた。これを解決するには、CPUに仮想化支援機能、特にNPTが重要だと判断していた。NPTはNested Page Tablesのことで、AMDではAMD-V RVI、IntelではIntel-VT EPTのことだ。

昨今のOSでは、アプリケーションはそれぞれ個別のメモリ空間を持つが、実際の物理メモリ空間は通常のコンピュータでは1つなので、CPUに内蔵するMMUがTLB(Translation Lookaside Buffer )を用いてハードウェアで変換している。しかし、ハイパバイザを用いる場合、ゲストOS毎に個別のメモリ空間を用いる必要があるため、このメモリアクセスは、アプリケーションの論理メモリ空間、ゲストOSが持つ(一見物理に見える)メモリ空間、ハイパバイザが扱う絶対的な物理空間と、ネストするメモリ空間マッピングが必要になるためだ。NPTが無い場合、これらはハイパバイザがTLBの入れ替えをしないとならないため、メモリアクセスの度にボトルネックが発生してしまい性能劣化が著しくなる。CPUにNPTがあればハードウェア処理で緩和できる。

AMD Opteron K10アーキテクチャ(Barcelona) には、4コア以上のモデルで、いち早くNPT(AMD-RVI)を搭載していた。そこで第二世代のクラウドシステムでは、これを採用することとなる。メモリバスが1CPUあたり10GBytes/sec、1コンピューティングノードあたり20GBytes/secと増強されたことも大きい。

搭載メモリ数は8Gと16GBモデルが採用。

ストレージは、2.5inchのSAS HDDを用いたRAIDに変わったのみで1Gから特に進化をしていない。