3G.第3世代 震災からDRへ！

3G(第3世代、2012年〜)

特徴

利用されたCPUモデル

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

x64アーキテクチャ	周波数（GHz）	2nd Cache（KB）	3rd Cache（MB）	Core（Threads）	メモリ	TDP
L5520	2.26	256 x4	8	4（8）	DDR3-1066 x3	60
SPARCアーキテクチャ	周波数（GHz）	2nd Cache（KB）	3rd Cache（MB）	Core（Threads）	メモリ	TDP
SPARC T4	2.85	128 x12	4	8（64）	DDR3-1066 x4	60

---

概要

第3世代のプライベートクラウドファブリックのコンセプトは、「ディザスタリカバリ」を命題としている。

3-11の東日本大震災以後、ディザスタリカバリが企業の中で本格的に考えられるようになったためだ。それ以前は、「このデータセンターが破壊される程の天災があるなら仕方が無い」と言うような意見も多かったが、3-11以降、たとえ大きな天災が起きたとしても、企業は、元の仕事に復帰する社会的責任を感じるようになっていった。

そこで、地理的に離れた2つの拠点をどうにかして共同して動作させるインフラストラクチャの構築が課題となっていた。

第3世代より、当社のクラウドファブリックは、コンピューティング、ストレージだけでなく、広域ネットワークに対する投資を大きくすることになる。当社の技術の主力である「コンピューティング(ハイパバイザ)」「ストレージ」、これに加えて3つのパーツである「ネットワーク」が揃うきっかけは、東日本大震災が契機となっている。

CPUの進化

コンピューティングノードではx64プロセサだけでなく、SPARCプロセサもサポートした。

x64アーキテクチャのプライベートクラウドの第3世代は、Intel Xeon Nehalem世代を搭載したモデルを採用。Intel Xeonを再び採用し、CPU世代がインテルコアアーキテクチャプロセサに一新。インテルXeonシリーズでは初めてメモリコントローラを内蔵し、マルチプロセサがSMP型からccNUMA型に変更、命令セットにもNPT（intel EPT）の実装も行われた。いくつかのフィーチャーでAMDに比べ採用が遅れたものの、消費電力単位のCPU性能の大幅な向上、x64命令セット（64bit）の本格的サポート、Hyper-Threadingの強化、メモリバス幅の強化（25GBytes/s）など、あらゆる意味で進化された本命のCPUであると言えた。

CPUスレッド数は16論理コア。搭載メモリを24GB/48GB、最終的には96GBまでをラインナップした。

SPARCアーキテクチャのSolarisクラウドサービスは、ユーザからのリクセスが多かったためスタート。

CPUには、Oracle SPARC T4を採用。SPARCはSun時代より、T1プロセサ、T2プロセサと進化を遂げていたが、その設計思想はマルチコア×CMT(Chipped Multi Threading)で論理コア数を64と増やし、当時のx64アーキテクチャCPUよりもかなりの並列性能を高めていた。しかし並列度は増すものの、SPARC T1/T2プロセサは単一スレッドの動作速度は奮わなかったため、アプリケーションのチューニングが難しいCPUとなってしまう。そこでT4ではシングルスレッド性能の性能向上にも力を注がれ、キャッシュの最適化をはじめ、Oracle/Sun SPARCシリーズで初めてアウトオブオーダー実行などを採用する。さらに、クリティカルスレッドオプティマイゼーションという機能を持ち、特定のスレッドがCPUコアのフル性能が必要になる場合は、自動的に1コアに与える機能などが実装された(※一般に、CMTのような論理コアは、演算器などがコア毎に実装されている為、それらが空いているときでないと並列度があがらない) 。また、暗号化支援機能もCPUに搭載されている。

ハイパバイザ

仮想化技術は第2世代を継承しながら、VMware vSphereによるLinuxやWindowsマシンの提供。

OpenSolarisのコンテナサービスは、Solaris 11のリリースと共にSolaris Zonesへ変更。これは当社が、OpenSolarisの独自のディストリビューションを作る際に様々なRFE(Request for Enchantment)やバグ報告を行ったことから、米Oracle社とSolaris SPARC等のプラチナカスタマープログラム(後に、カスタマーアドバイザリボード)の契約締結を行った経緯がある。その後も継続的に技術的なフィードバックが行われ、また結果的に当社からのRFEの大半は受け入れられたこともあって、このときからOpenSolarisをカスタマイズするのではなく、Solaris 11をベースにストレージOSとしてのディストリビューションを作成することになった(※Solaris 11にはOpenSolaris由来のdistro constという機能があり、Solaris 11ベースの派生OSを作る事ができる。もちろんOSライセンスは必要)。

SPARC Solarisの仮想化機能では、Intel版のSolaris VPSと同じく当社製のDimensionPlusによるZoneの提供もできたが、SPARC顧客はライブマイグレーション機能等の要求もあり、ロジカルドメイン(LDOM)、後のOracle VM Server for SPARCを採用した。LDOMは厳密には仮想化ではなく、(ロジカル)パーティショニングだ。

そのためCPUのオーバーコミットもなくあくまで論理コアやメモリを固定的に割り振るため、リソースの配分に厳格となり、常に一定の性能をコミットしやすい。ただしCPUはTシリーズがCMTを持っているため、見方によってはハードウェアでオーバーコミットを1Coreで8Threadsまで許可しているとも言える。

またデバイスIOの仮想化と、仮想マシンを制御するコントロールドメインを分離できるため、x86-64のハイパバイザと異なり、たとえゲストドメインのワークロードのどれかがバーストしたとしても、デバイス仮想化層にてCPU飽和が起きてもコントロールドメインには影響が起きないメリットがある(※ただし、この実装方式は、検討されたものの実際には3Gでは行われず、x86-64のXenとほぼ同じ「コントロールドメイン＝IOドメイン」の実装となっていた。これらが分離されるのはSR-IOVが実装され、ゲストOSがiSCSIブートができるようになる6Gfからとなる)。

ストレージ

ストレージは第1世代からのSolarisのZFSを用いたストレージを継承し、Solaris 11にリファクタリングされた。また、ストレージに初めてSSDが投入。とはいえ、ZFSのL2ARC、Separate Logの為であり、本格的なSSD導入ではなく、当時、言われた所謂ハイブリッドストレージとなる。ストレージ層でのレプリケーション機能(当社DimensionPlusプロジェクトで開発されたもの)を利用し、ZFSを用いて異拠点にデータを転送するメカニズムを実装した。これが現在のEnterprise Storage、Backup Storageのストレージレプリケーション機能に繋がっていく。 

参考≫サポート情報/マニュアル/Storage/ZFSの特徴

参考≫テクニカルノート/スナップショットとは？(StorageやPrivate CloudのSnapshot)

参考≫テクニカルノート/Snapshot Replicationとは

この時期のSSDは、まだエンタープライズ用で利用されることが少なく、主にデスクトップで利用されていたため、この時点ではSATA SSDが使われ、寿命管理を行いながら常に壊れても良い状態を作っていた。しかしSATAモデルであるが故にSAS Expander経由のアクセスでは4xレーンのうち1つがSATAディスクによるコマンドのタイムアウト飽和を起こしがちとなり、SAS HDDの速度律速を招いてしまう問題もあった。

ストレージエリアネットワークは、2x1GbpsのLAGを採用し、3-TierではIP-SANとして初めてiSCSIが採用されていくが、VMwareではvmfsのSCSI2 LUN Lock問題と相まって速度性能が伸びなかった(※この件に関しては4世代目に後述)。

ネットワーク

データセンターネットワークはスタッキングされた1GのNetwork Switchが用いられ、2x1GbpsのLAG(リンクアグリゲーション)を用いシャシーを冗長化。

ディザスタリカバリの為に必須となる広域のネットワークファブリックでは、L2レベルのリージョン間通信に対応。リージョンも関東、中部、関西リージョンに増設。それぞれの間でL2での接続ができるため、特定リージョンのゲストOSを別のリージョンに持って行き、動作させることも可能としたため、ディザスタリカバリ基板の大きな礎となった。

ユーザとのアクセス線も、NTTフレッツ網内のIPv6 L2 VPNを用いたサービスをスタート。これは現在のクラウドコネクトに繋がる。事実上オフィスのLANをそのままのIP空間で延伸できるため、オンプレ機器とプライベートクラウドとの通信をシームレスに行う事ができ、オフィス内サーバのP2V(物理から仮想サーバに移設すること)にも役立つこととなった。

ディザスタリカバリ

お客様の「データを守る」ことをは当社の起業理念のValuesとして定めされているように、データを守るという考え方は、ストレージの組み方にも影響を与えてきた。この世代からネットワークが組み込まれるため、これらはより強固となっていく。

データを守るためにはストレージはもちろんのこと一貫性(consistency)が必要であるし、RPO、RTOの定義を行い、DRで動作させる為の枠組みも必要だ。また広域ネットワークも必要となる。

参考≫ 技術資料・ホワイトペーパー/適切な「RPO」（目標復旧時点）と、「RTO」（目標復旧時間）とは

VMwareではVMware層でのReplicationを行う為、VMware Site Recovery Managerで管理。その他のサービスでは、ストレージ層によるレプリケーションを行うことにより、DRを実現した。