4G.第4世代 IOの高速化が命題？

4G(第4世代、2015年〜)

特徴

利用されたCPUモデル

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

x64アーキテクチャ	周波数（GHz）	ターボブースト（GHz）	3rd Cache（MB）	Core（Threads）	メモリ	TDP
E5-2630	2.3	2.8	15	6（12）	DDR3-1333 x4	95
E5-2620 v2	2.1	2.6	15	6（12）	DDR3-1866 x4	80
E5-2670 v2	2.5	3.3	25	10（20）	DDR3-1866 x4	115
E5-2690 v2	3	3.6	25	10（20）	DDR3-1866 x4	130
E5-2695 v2	2.4	3.2	30	12（24）	DDR3-1866 x4	115
SPARCアーキテクチャ	周波数（GHz）	L2 Cache	3rd Cache（MB）	Core（Threads）	メモリ	TDP
SPARC S7	4.27	I: 512KB+D:1MB	16	8（64）	DDR4-2400 x4	115

---

概要

第4世代プライベートクラウドファブリックのコンセプトは、「マルチアーキテクチャ、マルチハイパバイザと、IO高速化」を命題にしている。

現役時代が長かったx86-64アーキテクチャのプライベートクラウドである第4世代は、前期・中期・後期と、細かなアーキテクチャの変化が多い。

第4世代で導入されたサービスは稼働台数が最も多く、当社では人気のサービスとなった。これは、この世代のx86-64アーキテクチャが拡張性が高く、アップグレードでCPUのコア数を上げることができ、同時にメモリバンドも変えることができたためだ。

一方、第5世代と第4世代のx64アーキテクチャのCPUの同一クロックでのCPU性能差はほぼわずか。第4世代と第5世代ではメモリの規格が異なり、第4世代はDDR3で1コンピュートノード当たり最大120GBytes/s、第5世代はDDR4で1コンピュートノード当たり120GBytes/secからスタートとメモリバンド幅は肉薄。その結果、大容量メモリの積載でDDR4を用いた第5世代が割高になってしまい、ほとんどのユーザがほぼ同じ性能で、メモリ容量を2倍近く利用できる第4世代を利用する結果となり、この世代のプライベートクラウドがユーザーに支持される結果となった。 

CPU

CPUには、第2世代コアアーキテクチャプロセサのIntel Xeon SandyBridge 〜 IvyBridgeを搭載。AVX命令を装備し、より効率良く並列ベクタ演算が可能になるなど、きめ細かいCPUの強化が行われたが、なによりメモリバンド（リリース当初、コンピュートノード辺り42GBytes/sから最終的には120GBytes/s）の向上による性能向上がプライベートクラウド用の仮想環境としては大きい。

商品ラインナップは後半につれて徐々に追加され、8/24/40/48論理コアと増加。メモリも8G/32GB/64GB/128GB/256GBと初期ラインナップに比べて後半では大幅な拡張が行われた。

SPARC アーキテクチャのプライベートクラウドも一新する。

SPARC S7プロセサを採用。このCPUはSunがOracleに買収された以降に設計され、そしてOracleが満を持してリリースされたCPUであり、コストパフォーマンスが高いながら高い性能を持つ。クロックは4.27GHzと、最早、SPARCの単一スレッドが遅かった時代は過去のものとなっていた。コアは1CPUごとに8コア、64スレッド。Dual CPUなので論理コアでは128スレッドの同時実行を誇る。SPARCは元々ccNUMA型でありメモリコントローラも内蔵。メモリバンドが1CPUあたり76.8GBytes/sec、1コンピュートノード当たり153.6GBytes/secとなっている。このCPUには暗号化支援機能や、DAXというデータベース専用命令群があるため、Oracle Databaseを動かすとより高速に動作させることができるが、そうでない一般的なワークロードであったとしても、同世代のx64アーキテクチャのCPUに比べ、概ね動作が速いCPUとなる。

ハイパバイザ

Solaris x86-64の仮想化機能は、Solaris Zoneのうち、Native Zoneという従来型のコンテナ型のものをやめ、Kernel ZoneというType II型ハイパバイザを採用した。これは、リソース効率の良いコンテナ型にたいして、運用過程で2つの大きな問題が起きていたためだ。

まず1つめにアップデート問題。Solaris コンテナはカーネルとユーザランドを合わせてアップデートをする必要があり、各ゲストOSの管理者との都合を合わせるのが困難となる。回避策としてアップデートが必要な度に、オフラインマイグレーションをして新しいカーネルのホストに移設しながらアップデートしていたが、これではリソース利用率の高さがスポイルされてしまう。

2つめにカーネルリソース問題。カーネルにはプロセスIDやら、メモリ空間、ファイルディスクリプタなど、全体で共通に使うリソースがあり、これらは隔離されているものの、全コンテナで共有している。これらのカーネルリソースの確保渋滞がパフォーマンスのボトルネックにつながってしまう。

特にメモリ問題が顕著だ。コンテナ型のシステムでは親OSからみて多量のプロセスが実行されるが、ゲストコンテナが増えるとこの量が甚大になり、常にメモリのマイナーフォールト＋レクレイム(MMUのTLBが溢れメインメモリと入れ替える処理)が発生する。大きなメモリ空間で、大量のプロセスを動かすことになると、大量のメモリ空間を頻繁にスキャンすることに繋がってしまう。ハイパバイザでメモリ空間を区分けをして、それぞれのゲストOSに割り振る方がむしろ可動性が高くなってしまう。

そこで、NPT対応が必須であるがSolarisではKernel Zoneを採用することになる。Kernel Zoneであれば、Kernel Zoneの中でコンテナ型のNative Zoneを立ち上げることができる。顧客毎の利用はKernel Zone単位で貸出を行い、コンテナであるNative Zoneは自由にユーザが立てられるようになった。

さて、ハイパバイザ技術としてこの世代から導入された技術は、Xen Server。

Xenは1Gの頃から研究されていたが、実際に利用が始まったのは4Gが最初となる。採用理由は2つだ。

1. ハードウェアが進化し、CPU、メモリが速くなり、Dom0を経由するレイテンシがプロダクション環境で気にならなくなった。CPUの仮想化命令の増強や、PVドライバを利用したPVHVMモード等の進化が大きい。
2. Solaris x86-64の利用範囲が減少した結果、クラウドインフラとしての「プランBの選択肢」として適合しなくなり、別のプランBが必要になった。

当社の技術的な指向として、「同じ目的の似た複数の技術を同時に利用する」という考え方がある。これには3つの理由がある。

1. 技術の革新が見えやすいこと。
2. ベンダユニーク範囲がわかりやすいこと。
3. サプライチェーン(選択肢のなさ)のカバレッジを高めること
   

Xen Private Cloud（後のHigh Response Private Cloud）をラインナップし、ユーザはSolaris、VMware、Xenと、性格の異なる複数のアーキテクチャのプライベートクラウドを選ぶことができるようになる。

 

ストレージ

プライベートクラウド用ストレージでは、初めてフルSSD化を行った。ハイブリッド型もふくめたHDDストレージの廃止となる。

IOを高速化する理由はプライベートクラウドがIOを集めてしまうためだ。海外勢のパブリッククラウドでは、IOを集めることによる問題に既に取り組んでおり、IOを「集めない」設計思想のクラウドシステムが作られていた。そのためにアプリケーション開発エンジニアは、特別なミドルウェアを使ったり、データストアへのアクセスをRDBからS3やBigTablesなどの分散KVSに変えたり、様々なソフトウェアロジックの変更を余儀なくされた。この多くは、IOの集約をさせたくないのだろうという設計思想が見え隠れする。

一方、日本のクラウドサービスでは、インフラの都合で新たにソフトウェアを作り直させること難しい事から、今まで通りのOSイメージで動かすことができる仮想環境が多い。結果、IOを集約するものも多く、様々なベンダでストレージIO不足に起因する障害を発生させていた。

当社においても、当社独自のルールで利用者にミドルウェアを強要し設計をして貰う事は難しい。そこで、IO集中問題に関しては2つの回答を用意した。

1つめは、IOを集めてしまうことにはなるが、代わりにIOをEnterprise SATA/SAS SSDを用いて可能な限り高速化したもの。エンタープライズニーズでは、P2Vニーズも多く、いわゆる従来からの業務アプリを移行するニーズが多いため、特別なミドルウェアを用いてIOバランシングすることは難しい。要求されたIOとニーズによって、SSDはSATAモデルとSASモデルを用意し、大幅な高速化を行った。サービス提供初期では、SSDファームウェアによる問題や、寿命管理の難しさや応答劣化の管理の難しさを伴った。

フルSSD化に伴い、ストレージエリアネットワークは高速化が余儀なくされる。

Solaris Private Cloudでは、第三世代で開発されたストレージファブリックをベースに2x10Gbpsの20Gbps MPxIO（マルチパスIO）を用いて高速化。VMware Private CloudではNFSv3をやめ、冗長パスに対応するためにiSCSIを用いてMPIO(マルチパスIO)化し、クラスタリングファイルシステムであるvmfsを採用。新しくVAAI(vStorage API for Array Integration)に対応したVMware専用ストレージ製品が使われた。

VMwareでiSCSIストレージを利用する場合、仮想マシンの数や全体容量の多いストレージ環境では、VAAIに対応することが事実上の必須条件となる。クラスタリングファイルシステムでは複数ホストから書き込みが発生するとき、要所要所でストレージのロックが必要となるが、通常のiSCSIのストレージではLUNボリューム全体のSCSI2 LUN LOCKしかファンクションが存在しない。VMFSはLUN単位でフォーマットされるため、ファイルシステム全体の広域ロックが生まれてしまう。

この広域ロックが行われるとき、VMFSに格納される全ての仮想マシンが、ミリセカンド単位でIO停止する。このロックはHAとも関係するため、一定のインターバル単位で仮想マシン毎にハートビートのように書き込まれている。仮想VMの数が増えるとロック頻度も上がり、一定の数を超えると、インターバル中のかなりの時間がロックに費やされるため、最早、無視できない性能劣化が発生する。

これを解決するのが狭域ロックを行うVAAIだ。VAAIがないストレージでは、概ね1LUNあたり20ゲストOS程度という不文律が生まれる。VAAIはロックを狭域ロックにすることで、これを緩和することができるわけだ。VAAIのオープンソース実装は見当たらなかったため、VMware用のストレージのみ第1世代から培ってきたSolarisベースのZFSを用いたEnterprise Storageを辞め、VAAI対応のベンダー製ストレージを利用することになった。(※なお、その後、単一ソフトウェアスタックによる不具合時の連鎖化などがあり、後の第6世代ではバージョンではNFS v4.1にリプレースされることになった。詳しくは第6世代を参照のこと)

IO集中に関する2つ目の回答は、Xen Private Cloudだ。第4世代初期のXenサービスではVMware Private Cloudと同じようにストレージファブリックを用いた実装であったものの、Xen内部のOpen vSwitchの集約により、Xen HAのハートビートとiSCSIが共にovsを経由することで、ovsのCPUパワーに関する遅延が目立つようになった(※この問題は、6Gfにてもう一度取り組み、解決する)。

そこでXen Private Cloudではパブリッククラウドに倣って3-Tier ストレージを利用しないサービスを追加。IO集中問題を回避するため、コンピュートノード内に専有バスで直接接続するInterconnected Storageをラインナップに追加した。これにより、コンピュートノードが個別のSSDをもつことで、ストレージIOが格段に高速化し、IO集中がほとんど起きなくなる。安定性とレスポンス速度が担保されるメリットが生まれたが、デメリットとしてはもしもコンピュートノードが破損したときは内蔵SSDの中のゲストOSがアクセス不能になってしまう。

この問題を軽減するために、稼働中の仮想OSイメージを、数時間に1度という短いスパンで、別筐体の3-Tierストレージにレプリケーションし、コンピュートノードの障害時にはバックアップから少し前の状態にリカバリーできるように設計した。このストレージは速度が必要としないため、バックアップ用のストレージでも良いため、バックアップを兼ね、コストダウンを計ることができる。

IOは集中していないので基本的にハイレスポンスであり、エフェメラルディスク並に速いもののバックアップは存在するため永続化ができる。また懸案である一貫性は、ゲストOS内部でデータベースクラスタなどを用いて解決する方法を推奨した。

ネットワーク

ネットワークファブリック面では、セキュリティに関する関心も高まり、ハードウェアアクセラレーション機能付きのFirewall UTMサービスを開始した。