プライベートクラウドのジェネレーション（世代）について

プライベートクラウドより前の世代について(2002年〜)

レンタルサーバ（Webホスティング）時代〜プライベートクラウド開始まで

2002年にリリースされたPhase1Plus（フェイズワンプラス）は、ApacheベースのVirtualHostでテナントを分離し、FTPによりコンテンツデータをアップロードする、「いわゆる通常のレンタルサーバ」だった。現在もWebホスティングは小規模層に人気であり、十分コモディティ化されている。ただしマルチテナント環境としての隔離性は、UNIX/Linuxのユーザグループとしての隔離に過ぎず、リソース制限もulimit程度でしかない。当時のPhase1Plusの基本構造は、ほぼそれと同じものだった。

まず、データベースはMySQLかPostgreSQLの共有であり、やはりUNIXユーザによる隔離で、リソース制限はつけられない。コンテンツやプログラムはFTPという暗号化されない方法でアップロード。当時からFTPをすて、SFTPなどの必需性は叫ばれていたが、当時は使いやすいWindowsクライアントがなかったり、SFTP自体がOS設定にshellアクセス権を要求することもあったなど、苦渋の選択でFTPを採用する必要があったのだ。

アップロードされたプログラムは、「SuExec」というユーザ毎（この場合テナント毎）に異なるユーザ権限で実行する。これである程度の権限分離はできるものの、同サーバ上に設置したプログラムが書き込んだファイルは、ブラウザ経由では見えなくしたとしても、ファイルやディレクトリのパーミッションの設定をミスすると、プログラム同士で互いに閲覧可能になってしまう。つまりセキュリティ・マンションのようなもので「裏口の鍵を持つ人（FTPでアクセス出来るホストに収容された人達） は悪い人ではないに違いない」という性善説に基づいて作られているのだ。このレベルのセキュリティ、サービス的な脆さでは問題があるのなら、なるべく高効率にテナント毎の隔離を行う必要がある。

仮想化の出番だ。

仮想化といっても一般的にはハイパバイザを用いたものが多いが、当時のコンピュータでその技術を用い、サービスレベルまで漕ぎ着けるのは、様々な面で困難が伴う。そこで、様々な試験的サービスを作ることなり、これがプライベートクラウドの技術的な礎になっていく。

まず評価を行なったのが当時のVMware Workstationだ。起動時にVNC Desktopを起動し、仮想デスクトップ上にVMware Workstationだけを起動するという変則的な実装だ。ここでゲストOSを稼働させ、サーバとする。隔離性はあるものの、当時のマシンのスペックからすると1台に乗せられる仮想OSが少ないし、ライセンス的な問題もあるだろうということで、自社内の試験環境の利用に留まった。

2つめにUML（UserMode Linux）。技術としては非常に面白いもので、テナント単位のカーネルが個別のユーザランドプロセスになる一方で、ゲストOSのプログラムが親OSからみるとカーネルスレッドに見えるというもの。当時人気を集めていたLinuxで隔離実行ができることも面白い部分だったが、リソース隔離性は低く、当時はデプロイが難しいところがあったり、多数のゲストOSの動作には一工夫が必要なこともあり、当社内では試験で終わった。

3つめに、FreeBSDのjail。プロセスパーティション、いわゆるコンテナ型技術で、プロセスレベルで隔離してカーネル層を共有するため、リソース利用率という意味で着目した。すでにjail break技術はちらほらとは存在したものの、プロセスレベルの隔離よりはよほど隔離性が高い。FreeBSD(※)であると言うことを除き、当時としては良いソリューションだと考えられた。(※当時の当社の顧客はLinuxを好んでいたため)

Linuxへのコンテナ実装は、現在はLXCが標準実装であるものの当時は存在していない。また、OpenVZという技術評価も行われたが、残念ながらOSのディストリビューションにメインストリームとして入る技術ではなかったため、様々な状況で試験利用に留まった。

当時のCPUは命令セット、アーキテクチャの面の双方で仮想化に対してはまだ貧弱であった。

メインストリームは、Pentium 4 NetBurstアーキテクチャベースのXeon（Prestonia/Nocona）。このCPUは消費電力が大きく、また、当時のデータセンターは電力に余裕があまりないこともあって、1ラックあたりの集積度問題を抱えていた。このCPUはHyper-Threadingによって1CPUで2並列の動作が可能であったが、むしろ有効にすることによって、ほとんどの実アプリのベンチマークが悪化するため、無効にすることもあった。結果として、消費電力が少ないPentiumM（PentiumⅢベースのモバイル用CPU）系のCPUを搭載した小型サーバを並べた方がラック効率が高いため、その導入は何度も検討されていた。

こうした流れの中、InfiniCloudの最初のプライベートクラウドである「Phase2Server Lite」「Solaris x86 VPS」というプロジェクトへ繋がっていく。

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」という名前でサービスインすることとなる。

OSはオープンソースである、Solaris系OSであるOpenSolarisに変更。さらに自社で特殊なOpenSolarisベースのディストリビューションを作成。これはコンテナ稼働のためだけに必要なOpenSolarisのリソースセットを持ち、USBメモリで起動してオンメモリのRAMDISKだけで稼働。ブート用のストレージも不要となり、コンピュートノードのコストダウンにも寄与する。

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

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のみだった。

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高速化」を命題にしている。

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

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

ハイパバイザ技術としてこの世代から導入された技術は、XenServer。XenPrivate Cloud（後のHigh Response Private Cloud）をラインナップし、ユーザはSolaris、VMware、Xenと、性格の異なる複数のアーキテクチャのプライベートクラウドを選ぶことができるようになる。

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

Solarisの仮想化機能は、x64アーキテクチャ、SPARCアーキテクチャ共々、Solaris Zoneのうち、Native Zoneという従来型のコンテナ型のものをやめ、Kernel ZoneというType II型ハイパバイザを採用。SPARCでは引き続きLDOMも利用可能。メモリやCPUパワーの増加でハイパバイザ型が中心となった。

リソース効率の良いコンテナ型だが、運用過程では2つの大きな問題が起きていた。

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

2つめにカーネルリソース問題。カーネルにはプロセスIDやら、メモリ空間、ファイルディスクリプタなど、全体で共通に使うリソースがあり、これらは隔離されているものの、全コンテナで共有している。これらのカーネルリソースの確保渋滞がパフォーマンスのボトルネックにつながってしまう。特にメモリ問題が顕著だ。コンテナ型のシステムでは親OSからみて多量のプロセスが実行されるが、ゲストコンテナが増えるとこの量が甚大になり、常にメモリのマイナーフォールト＋レクレイム(MMUのTLBが溢れメインメモリと入れ替える処理)が発生する。大きなメモリ空間で、大量のプロセスを動かすことになると、大量のメモリ空間を頻繁にスキャンすることに繋がってしまう。ハイパバイザでメモリ空間を区分けをして、それぞれのゲストOSに割り振る方がむしろ可動性が高くなってしまう。

Solaris Zoneでは、Kernel Zoneの上で、コンテナ型のNative Zoneを立ち上げることができる。顧客毎の利用はKernel Zone単位で貸出を行い、コンテナであるNative Zoneは自由にユーザが立てられるようにした。

プライベートクラウド用ストレージファブリックでは、フルSSD化を行った。ハイブリッド型もふくめたHDDストレージの廃止となる。IOを高速化する理由はプライベートクラウドがIOを集めてしまうためだ。海外勢のパブリッククラウドでは、IOを集めることによる問題に既に取り組んでおり、IOを「集めない」設計思想のクラウドシステムが作られていた。そのためにアプリケーション開発エンジニアは、特別なミドルウェアを使ったり、データストアへのアクセスをRDBから分散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ストレージを利用する場合、ゲストOSの数や全体容量の多いストレージ環境では、VAAIに対応することが事実上の必須条件となる。クラスタリングファイルシステムでは複数ホストから書き込みが発生するとき、要所、要所でストレージのロックが必要となるのだが、通常のiSCSIのストレージではLUNボリューム全体のSCSI2 LUN LOCKしかファンクションが存在しない。つまり広域ロックが生まれてしまうのだ。この広域ロックが行われるとき、LUNボリュームに格納されるゲストOSの全てのIOがミリセカンド単位で停止する。格納ゲストOSの数が増えるとロック頻度も上がり、一定のゲストOSの数で最早無視できない性能劣化が発生していく。そのため、VAAIがないストレージでは、概ね1LUNあたり20ゲストOS程度という不文律が生まれる。VAAIはロックを狭域ロックにすることで、これを緩和することができるわけだ。これがVAAI対応ストレージを使うことになった最大の理由である。(※なお、その後、単一ソフトウェアスタックによる不具合時の連鎖化などがあり、後の第6世代ではバージョンではNFS v4.1にリプレースされることになった。詳しくは第6世代を参照のこと)

IO集中に関する2つ目の回答は、Xen Private Cloudだ。第4世代初期のXenサービスではVMware Private Cloudと同じようにストレージファブリックを用いた実装であったものの、Xen内部のiSCSIに関連するInitiatorの処理の遅延や、Xen HAの構造上の問題が散見され、ストレージに対する要求はVMware以上にシビアなものになっていた。そこでいっそのことストレージファブリックを利用することをやめ、かつ、IO集中問題を回避するため、コンピュートノード内に専有バスで接続される形に進化。コンピュートノードが個別のSSDをもつことで、ストレージIO集中時の安定性とレスポンス速度が担保されたが、もしもコンピュートノードが破損したときは、内蔵SSDの中のゲストOSがアクセス不能になってしまう。そこで稼働中の仮想OSイメージを1時間に1度程度という短いスパンでバックアップ専用HDDストレージ(このストレージは速度が必要としないためHDD)にリアルタイムバックアップすることで、コンピュートノードの障害時にはバックアップから少し前の状態にリカバリーできるように設計した。IOは集中していないので基本的にハイレスポンスであり、一貫性はゲストOS内部でデータベースクラスタなどを用いて解決できる。(※これはその後、第6世代でHigh Response Private Cloudと目的特化型へとさらに進化する)

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

なお、第4世代で導入されたサービスは、今現在も稼働台数が最も多く、当社では2018年まで販売されていた。

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

※当社Private Cloudの場合、たとえ利用開始が第4世代のころであったとしても、ネットワークファブリック、ストレージファブリックなど、アップデート時にリプレース可能なものはメンテナンスを経て、第5世代、第6世代のものとより高性能な環境へと入れ替わることが多い。これも第4世代が支持され続けた原因の1つとなっている。

6G(第6世代、2020年〜)/6Gs(第6世代セカンドエディッション) 〜現行世代〜

VMware Private Cloud、Solaris Xeon Private Cloud、High Response Private Cloudで提供中。で提供中。

特徴

プライベートクラウド・ラインナップ

プライベートクラウドのコンピュートノードのラインナップは下記の通り。

x64アーキテクチャ	論理コア合計（Threads）	メモリバンド合計最大値	メモリ搭載(GB)	備考
Xeon Silver(Skylake-SP)	32	230GBytes/sec	96	〜2022年新規販売終了
Xeon Silver(Skylake-SP)	40	230GBytes/sec	192	〜2022年新規販売終了
Xeon Gold(Skylake-SP)	64	256GBytes/sec	384	〜2022年新規販売終了
Xeon Gold(Skylake-SP)	88	256GBytes/sec	768	〜2022年新規販売終了
Xeon Silver(Cascade lake refresh)	48	230GBytes/sec	192GB
Xeon Silver(Cascade lake refresh)	48	230GBytes/sec	384GB
Xeon Gold(Cascade lake refresh)	80	256GBytes/sec	768GB
Xeon Gold(Cascade lake refresh)	96	280GBytes/sec	1.5TB
SPARC S7-2	128	307GBytes/sec	256/512GB
SPARC T8-1	256	187GBytes/sec	512/1024GB
SPARC T8-2	512	374GBytes/sec	1024/2048GB

---

利用中のCPUモデル

x64アーキテクチャ	周波数(GHz)	2nd Cache(MB)	3rdCache(MB)	Core	メモリバンド	TDP
Xeon Silver 4110	2.1	8 × 1	11	8 (16)	6 × DDR4-2400	85 W
Xeon Silver 4114	2.2	10 × 1	13.75	10 (20)	6 × DDR4-2400	85 W
Xeon Gold 6130	2.1	16 × 1	22	16 (32)	6 × DDR4-2666	125 W
Xeon Gold 6152	2.1	22 × 1	30.25	22 (44)	6 × DDR4-2666	140 W
Xeon Silver 4214	2.2	12	16.5	12 (24)	6 × DDR4-2400	85 W
Xeon Gold 5218R	2.1	20	27.5	20 (40)	6 × DDR4-2667	125 W
Xeon Gold 6240R	2.4	24	35.75	24 (48)	6 x DDR4-2933	165 W
SPARCアーキテクチャ	周波数(GHz)	2nd Cache	3rdCache(MB)	Core	メモリバンド	TDP
SPARC S7	4.27	I: 512KB+D:1MB	16	8（64）	DDR4-2400 x4	115 W
SPARC M8	5.06	32 × (I: 128KB+ D: 256KB)	64	32 (256)	374GBytes/sec	非公開

概要

第6世代のクラウドファブリックのコンセプトは、「ハイブリッドクラウド時代の片翼を担うプライベートクラウドのIaaSは、パブリッククラウドのIaaSより原則として高速でなくてはならない」という命題のもとに設計されている。これは、5Gケータイ普及に伴うサービスの高速化ニーズ、デジタルトランスフォーメーション(DX)によるITインフラストラクチャに対する性能向上の期待に応えたものだ。

コンピュートノード(プライベートクラウド基盤)の進化

まず、x64アーキテクチャプライベートクラウドはCPU世代を一新してIntel Xeon Scalable Processorを採用。このプロセッサは、科学技術シミュレーションや、AI・画像処理に秀でたAVX-512などの拡張命令群を装備しており、論理コア数の向上、なによりもメモリバスの向上が大きい。リーズナブルなモデルでも48論理コア(スレッド)、ハイエンドでは96論理コア(スレッド)を持ち、加えて幅広いメモリバンド（1コンピュートノードあたり230GBytes/sec 〜 280GBytes/sec）を持つため、メモリの大容量化時の性能劣化を抑えることができる。プライベートクラウド基盤には、192GB〜1.5TBのメモリモデルがあるため、このCPU性能の向上は、多くのインスタンスを稼働させるのに役立っている。

これを動作させるハイパバイザは、5Gに引き続きVMware ESX Enterprise Plusと、XenServerを採用した。VMwareはx86/x64のハイパバイザとしては一日の長があり、オンプレミス仮想化基盤のマイグレーションには強く役立つ。VMware Private Cloudでは基本、1つのユーザ毎に1つのvCenterを持つため、オンプレミスからのワークロードの移設には極めて親和性が高いだろう。下記に記すインターリージョナルファブリックと組み合わせてDRセットにした場合、異なるリージョンで同一のネットワークセグメントを持ち、異拠点vMotionなどを駆使して、容易に異拠点のDR環境を準備できることも大きいアドバンテージだ。

安価なIaaS基盤であるHighResponse Cloudでは、XenServerベースのXCP-ngを採用。加えてXenOrchestraによるオーケストレーションが行われており、XenインスタンスのWebベースの管理が可能となっている。同拠点上でのインスタンスの自動バックアップや、異拠点レプリケーションが可能になるため、安価にDRを前提としたよりロバストな環境を実現することができるだろう。

一方、SPARCアーキテクチャプライベートクラウドは、S7に加え、M8プロセッサもラインナップに追加。SPARC M8プロセッサはCPUクロックが5GHzへと向上し、キャッシュ構造の進化、演算器の強化などが行われ、純粋な意味でSPARCプロセッサの集大成とも言える高速なプロセッサと言える。Software in Silicon 第2世代を搭載し、インメモリデータベースや、Java ストリーム処理にさらに適合したDAXと、暗号化支援機能などを持ちつつ、幅広いメモリバンド(1コンピュートノードあたり最大374GBytes/sec)を持つのも特徴だ。

ハイパバイザはOracle VM Server for SPARCを採用。これはLogical Domain(LDOM)という技術が利用されており、x64の仮想化基盤とは設計思想が大きく異なる。アーキテクチャとしては仮想化よりも、ドメイン毎、つまりCPUやメモリリソースを分割、割譲していくことに主眼がおかれているため、それぞれのインスタンスが、これらリソースにおいて互いに影響を及ぼすことがない(ただし、ネットワークとストレージに関しては、コンピュートノード単位で仮想化による共有も可能)。

現実的に言えば、もっとも利用ニーズが多いオンプレミスのSolaris10 SPARC環境のマイグレーションには、S7で十分な性能が出ていた。しかしここにSPARC M8プロセッサが加わることで、システム寿命の長いSPARCのシステムにおいては、既存システムをスケールアップにより性能向上させ、長く使えるシステムへ進化させることに一役買うことになった。Solaris10、11で当たり前のように利用しているコンテナ技術も、仮想インスタンス内で利用することができる。Solaris SPARC環境のオンプレミス代替としてのリフト＆シフトだけでなく、最新のSolaris11を利用する事でモダナイゼーションさせることも期待できるだろう。

ストレージファブリックの進化

どの時代でも、ストレージファブリックに要求されるものは、データの安全性と速度である。実はこの2つは基本的には二律背反するため、基本はどちらかをメインにとらえるしかない。See:テクニカルノート/時空に拡張されるCAP定理：落ちず、速く、確実なサーバをどう作るのか？

プライベートクラウドを支える3-Tier型のストレージにおいては、どうしてもデータの安全性が最重要課題となる。いくら高速でもデータが化けたり消えてしまうのでは、信頼性の置けるシステムが構築できないからだ。しかしながら、昨今のデータ量増加に伴い、よりヘビーなIOにも答える必要がでてきた。IO不足は「遅くなる」のではなく「停止する」事に繋がるためだ。

そこで、安全性能に関しては「自律ストレージ」であることをコンセプトとし、実績のある第3世代のストレージファブリックをベースに、これらの新要求に対応すべく、再設計されたのが6世代目のストレージファブリックとなる。

第6世代目のストレージを、第3世代のストレージファブリックを元に、自律型に再設計したのには意味がある。第4〜5世代のVMware用ストレージファブリックは、VMwareの為のAPIであるVAAIなどに対応したストレージ製品を利用していた。これらのVMware用のストレージ製品は、ハイパバイザとストレージの間でソフトウェアが連携、連動する。これは主に、VMwareのクラスタリングファイルシステムにおいて発生する「ロック」を狭域化するなど、技術的且つ合理的な理由があるし、製品によっては利便性のために用意されているものももちろんある。しかし逆に、連携するということは、そこ由来のインシデント発生時、ハイパバイザだけでなく、ストレージを巻き込む事故になることもある。たとえば、負荷が増えてストレージの臨界点動作の時、その時でのみ起きうる不具合は、復旧困難になりがちなのだ。

一般に、ハイパバイザが専用のクラスタリングファイルシステムを利用する場合、ハイパバイザベンダがファイルシステムの恒常性を担保する必要がある。この場合、ストレージベンダはあくまでブロックレベルのストレージを提供するにすぎない。もしもハイパバイザベンダが提供するクラスタリングファイルシステムに障害が起きた場合、ハイパバイザベンダの管轄範囲となるはずだが、それはローレベルのブロックストレージが「恒常的に正しい」ことが担保されない限りは「クラスタリングファイルシステムの上のファイルが正しく保存されている」と、言い切ることはできない。つまり「そこにあるファイルが正しいかどうか」を保証する為には、ハイパバイザとストレージを提供した2つのベンダの管轄範囲を跨ぐことになる為、障害発生時の問題解決が極めて困難になってしまう。

ファイルレベルストレージの場合、ファイルが正しいかどうかは、ストレージベンダの管轄範囲だけで提供される。したがって障害が発生した場合でも、ストレージベンダが対応する範囲でデータの整合性担保ができるメリットがある。第6世代で再びNFSに戻したのにはこの理由が大きい。NFSでの利用では一般に性能劣化などが考えられるが、ロックは元々ファイルノード単位で狭域でもあるし、IO性能が十分にあれば、これらのマイナスをある程度、カバーできる。

冗長性はダブルパリティを二系統でダブルシャシー型でデータロストの可能性を極力排除した。

自律型であれば、コンフィギュレーションにより、2系統を単なるミラーや、遅延ミラーが可能で、スナップショットによる世代管理、オプション機能ではディザスタリカバリのために異拠点へのレプリケーションなど、ストレージ層だけで独立してデータを守る構造をもつ。臨界点異常が仮に発生したとしても、今の時点のファイルシステムは保持できているため、最悪「停止する」だけでデータは保護できる。

昨今、世界中のクラウドベンダーによるデータ欠損事故はユーザが考えている以上に多く、無視できないレベルに達している。ストレージもソフトウェアで制御される以上、バグが付きものとも言える。特に負荷が臨界点に達する時点でのみ発生するようなバグは発見しづらいため、データ安全性を最大限、深刻に考慮し、あえてハイパバイザソフトウェアスタックとは連動しない、独立型の構造を持ちながら、データ保全に努める設計を採用した。

安全性が高くても速度が十分でなければ、3-Tier型仮想化基盤用ストレージとしては機能しない。

そこでまずは最新世代のEnterprise NVMe SSDを用い、高帯域のストレージインターコネクトに、高いIOPS処理能力を確保した。これにより実測ベースでストレージ内では約4百万IOPS、約18GB/secを超えるリード＆ライトを実現。ストレージサービスのSAN帯域は合計で2x25Gの帯域を持ち、Multi-Chassis Link Aggregationによってコンピュートノードとストレージファブリックが接続されている。コンピュートノードのSAN帯域は2x10Gbps。

実効ベンチマークとしてはVMware上のゲストOS内からでも2.35GBytes/secのリードをマーク。SAN帯域の限界値に近く、IO性能もVMwareハイパバイザ側のドライバ層性能を限界ぎりぎりまで絞りだしている。つまり、このようなベンチマーク中でもストレージファブリックには、IO余剰が持てるほどに十分な性能を持つことを意味する。埋め尽くすことができないレベルのストレージ性能があるからこそ、自律型でレプリケーションが可能になる。

これらはVMware、Solaris、IaaS(High Response Cloud)だけでなく、ユーザネットワークに対しても,ファイルレベルストレージ、ブロックレベルストレージとして提供できるようになったのも特徴だ。これらのストレージを直接、インスタンスから操作できると、現世代の選別したオンプレミスシステム並の性能を出すことができる。

これらはデジタルトランスフォーメーションにおいて、有用なエンジンとなる。

ネットワークファブリックの進化

6世代目はネットワークファブリックの進化も大きい。5Gケータイの帯域需要に加え、エンタープライズ企業では、デジタルトランスフォーメーション(DX)需要の高まりとともに「BCP」も重視されるようになってきたためだ。

まず、ユーザからの出入り口であるPrivate Connectは200M〜最大100Gbpsまでをサポート。国内の4つのリージョン(関東、関西、中部、九州)に対して、直接、InfiniCloudファブリックにレイヤー2で接続することができる。高帯域、低レイテンシで、オンプレミスと変わりない速度と同じIPアドレスで、「最も近いプライベートクラウド」が提供できることになる。

足回りを支える同一データセンター内のネットワークファブリック性能も大幅に強化し、インターコネクトは400Gで接続。Multi-Chassis Link-Aggregationによって1コンピュートノードあたり2x10/25Gの帯域を確保。同一リージョン、異データセンターでも、たとえば2x100Gなど、高帯域で接続することで、同一リージョンであれば統合されたデータセンターのように振る舞うことができるのも特徴だ。

リージョン(関東、中部、関西、九州)間接続であるインターリージョナルファブリックの性能強化も行っている。L2での冗長性の確保や、帯域増強と低レイテンシ化を行い、tagVLANの利用も可能。L3の場合は経路最適を行う事も可能だ。一般に、DRを実現するためには回線コストが問題になるが、これらを手軽に実現できれば、BCP/DRを極めてローコストで実現できることになる。そこで、4つのリージョンを同じように帯域を確保し、プライベートクラウドとあわせてより高性能なリージョン間ネットワークを強化した形となる。

パブリッククラウドとの接続線である「パブリッククラウドリンク」も新サービスとして追加した。昨今のシステムは、オンプレやプライベートクラウドだけで完成することも少なく、パブリッククラウドと連携することによって完成するものも多い。FaaSやAPIなど連携方法も多いため、単なる「アクセスやメンテナンスのための裏線」だけでなく、システム連動のための線としても使われる。プライベートクラウドとパブリッククラウドをインターコネクトで簡単につなぐことで、ハイブリッドクラウドが造り込みやすいよう、リーズナブルなプランを用意することとした。

通常、パブリッククラウドとプライベートクラウドをつなぐ為には、こういったコネクティビティサービスを申し込むだけでなく、ユーザ企業でBGPによるダイナミックルーティングの設定が必要となる。このルータ設置費やルータ設置作業は、ネットワークに詳しくないパブリッククラウドの利用者には敷居が高すぎ、且つ、冗長線、マルチリージョンともなると、難易度が跳ね上がる。そこで、BGPルータをセットとするサービスも用意し、エンジニアリングサービスと組み合わせて販売することが可能となったのも特徴だ。

もちろん、これらを連携するために、ネットワークアプライアンスサービスの拡充も必要となった。従来からのUTMのクラウド利用だけでなく、ロードバランサ、SSLアクセラレータ、WAFなどの機能を統合したADC(アプリケーションデリバリコントローラ)のクラウドサービスも開始。

Internetへの出入り口も強化。東西のIXに直接足を卸し、4つのリージョンから全て、高帯域Internetが利用できるようにしたのも特徴だ。大規模自然災害時において、インターネット接続は重要となる。日本においては東は東京大手町、西は大阪堂島がInternetの中心となり、どちらでもアクセスが可能になる必要があるためだ。

まとめ

5Gケータイや、デジタルトランスフォーメーションなど、第6世代が担うクラウドファブリックは重大となっている。

そして自然災害の多い日本においては、デジタルトランスフォーメーションが進むほど、ディザスタリカバリは重要となり、どうやって待機系に切り替えるかはシミュレーションが必要になるはずだ。

これらは個別に用意することはできるが、実際に事が起きた時に「どうやって切り替えて良いのかわからない」という企業もおおい。InfiniCloudファブリックの特徴はリージョンを「統合」したようにみせ、東でも西でも全く同じように利用できるのが特徴だといえる。

たとえば関東の会社にとって、関西にあるDR用サーバリソースは、普段有効利用されることが少なく、単なる置物のサーバリソースになる傾向がある。企業の情報システム部にとっては必要でありつつも、会社から見て削減されやすく頭の痛い問題だ。もしもこれらが、L2、ワイドバンドかつ低レイテンシ通信ができるならば、全ての拠点のサーバリソースは、通常時から仮想マシン単位で移動、クローン可能になり、かつロードバランサーで分散動作させて有効利用することができる。かつ、データストア(主にデータベースや分散KVS)も、レプリケーションやクローンが可能なので、きちんと障害時に「そのまま動作する」環境を作りやすい。いざディザスタが起きた際は、データストアのマスタ切り替えをするだけですむため、ディザスタ時の情報システム部の負担が大きく減るメリットもある。

このように、5Gケータイ向けの高帯域サービスや、デジタルトランスフォーメーション、4つのリージョンのネットワークは統合されることで、BCP/DRなどにフォーカスを当てたサービスが更に進化した形となった。