プライベートクラウドのジェネレーション(世代)について - JUSTPLAYER インターネットサービス

Top / サービス一覧 / プライベートクラウドのジェネレーション(世代)について

Private Cloud Generation(世代)について

ジャストプレイヤーの提供するプライベートクラウドサービスは、2002年にレンタルサーバ、2007年にSolarisベースのクラウドサービスを開始して以来、進化を続けています。下記は、その技術背景資料です。

  • プライベートクラウド以前
  • 1G(第1世代)
  • 2G(第2世代)
  • 3G(第3世代)
  • 4G(第4世代)
  • 5G(第5世代)
  • 6G(第6世代)・現行世代
  • 6GS(現行世代)

プライベートクラウドより前の世代について

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

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

まず、データベースはMySQLかPostgreSQLの共有であり、やはりUNIXユーザによる隔離で、リソース制限はつけられない。
コンテンツやプログラムはFTPという暗号化されない方法でアップロード。当時からSFTPなどの必需性は叫ばれていたが、使いやすいWindowsクライアントがなかったり、SFTP自体が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を搭載した小型サーバを並べた方がラック効率が高いため、その導入は何度も検討されていた。

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

1G(第1世代)

利用されたCPUモデル

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

x64アーキテクチャ周波数(GHz)2ndCache(MB)HyperTransportCoreTDP
Opteron 260HE1.61 x21GHz255
Opteron 2802.41 x21GHz285

概要

ジャストプレイヤーの記念すべきプライベートクラウドの第1弾は、「クラウド」や「VPS」という名前がまだ存在する前のサービスであったことから、専用サーバサービス延長上の「Phase2Server Lite」(フェイズツーサーバーライト)シリーズとしてサービスされていた。

CPUにAMD Opteron K8 revE(Italy)を搭載。
同時期のIntel CPUよりも消費電力が少なく、かつDual Coreプロセッサをいち早く搭載したことにより、Dual Socketマシンなら合計4コアを実現することも採用のポイントだった。マルチプロセッサアーキテクチャも、SMPではなくccNUMAを採用することで、1物理CPUあたりのメモリバンドが6.4GBytes/sec、1コンピューティングノードあたり12.8GBytes/secと高性能であった。
しかしながら、CPUの仮想化支援機能やメモリバンド幅はまだ十分なものとは言えず、ハイパバイザ方式では性能劣化が無視できない。また、カーネルを全ての仮想マシンで確保するためには、メモリも不足しがちとなる。そこで、カーネルを単一にするプロセスパーティショニングの一種である、コンテナ型技術を採用することに決定。

コンテナ型技術は、現在はDockerなどで数多く使われるメジャーな機能だが、当時はFreeBSDのjail、Linuxでは実装の一部としてOpenVZなどがあるだけで、リソースの制限機能が少なかった。そこで、コンテナ型ながらリソースの制限機能の実装や高い隔離性を実現した、Sun Solaris 10のSolaris Container(zone)を採用。Sun Solarisへはいち早くこの機能が採用され、実績も伴っていた。

他にも、このジェネレーションで導入された技術は、共有ストレージ。

Solaris ZFSとNFSv3を利用し、仮想サーバのイメージをNFS上に格納した。コンテナの技術特質上、ライブマイグレーションはできないが、オフラインマイグレーションができる当社独自のDimentionPlusという仮想化支援ソフトウェアをリリース。コンテナはconductorと言われる管理システムにより、管理された。

2G(第2世代)

利用されたCPUモデル

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

x64アーキテクチャ周波数(GHz)2nd Cache(MB)HyperTransportCoreTDP
Opteron 2344 HE1.721GHz468
Opteron 2350221GHz495

概要

プライベートクラウドの第2世代では、まずは従来のSolaris Zoneを用いたDimensionPlusを線形進化。

これが「Solaris x64VPS」という名前でサービスインすることとなる。

Solaris系OSのOpenSolarisに変更し、USBメモリで起動する、Zone可動専用の独自ブートパッケージに変更することで、コストダウンを計る。

一方、このジェネレーションで導入された技術は、VMware vSphere ESXi。コンテナのリソース効率が良いとしても、Solarisだけでシステム全てを構築するには無理もあり、他OSが必要となる。ハイパバイザを使う場合、カーネルがゲストOSでそれぞれ異なるために、複数のOSを織り交ぜて使う事ができるが、それには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が無い場合、これらはハイパバイザが入れ替えをしないとならないため、メモリアクセスの度にボトルネックが発生してしまい性能劣化が著しくなる。NPTがあればハードウェア内の処理だ。

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

搭載メモリ数は8Gと16GBモデルが採用。ストレージは、2.5inchのSAS HDDをRAIDのみだった。

3G(第3世代)

特徴

  • Intel Xeon Nehalem世代を採用。
    • CPU世代をコアアーキテクチャプロセサに一新
    • 64ビットに最適化し、よりハイパバイザに向いたCPUラインナップに変更された
    • CPUスレッド数(論理コア)は16
    • 搭載メモリは24GB/48GB/96GBをラインナップ。メモリバンドは51GBytes/sec
  • Oracle SPARCを用いたSolaris SPARC クラウドをサービス開始
    • CPU世代はSPARC T4。CPUスレッド数(論理コア)は64、あるいは128
    • 搭載メモリは128GB。メモリバンドは34〜68GBytes/sec
  • ストレージファブリックの強化
    • HDD+SSDのハイブリッドストレージ化
  • ネットワークファブリックの強化
    • インターコネクトを20G。サービス用に1Gx2
    • 広域でのL2レベルのリージョン間接続(関東・中部・関西)サービスに対応
    • ユーザ拠点との間にフレッツ網を用いたL2接続線の用意

利用されたCPUモデル

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

x64アーキテクチャ周波数(GHz)2nd Cache(KB)3rd Cache(MB)Core(Threads)メモリTDP
L55202.26256 x484(8)DDR3-1066 x360
SPARCアーキテクチャ周波数(GHz)2nd Cache(KB)3rd Cache(MB)Core(Threads)メモリTDP
SPARC T42.85128 x1248(64)DDR3-1066 x460

概要

第3世代のプライベートクラウドファブリックのコンセプトは、「ディザスタリカバリ」を命題としている。3-11の東日本大震災以後、ディザスタリカバリが企業の中で本格的に考えらるようになった。それ以前は、「このデータセンターが破壊される程の天災があるなら仕方が無い」と言うような見方も多かったが、3-11以降、たとえ大きな天災が起きたとしても、企業は、元の仕事に復帰する社会的責任を感じるようになっていった。そこで、地理的に離れた2つの拠点をどうにかして共同して動作させるインフラストラクチャの構築が課題となっていた。

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までをラインナップした。

仮想化技術は第2世代から継承しながら、VMware vSphereによるLinuxやWindowsマシンの提供。ディザスタリカバリを考え、VMwareではVMware層でのReplicationをしVMware Site Recovery Managerで管理。Solarisでは、ストレージ層でのレプリケーション機能(当社DimensionPlusプロジェクトで開発されたもの)を利用し、異拠点にデータを転送するメカニズムを持った。

また、Solaris 11のリリースと共にSolaris Zonesを採用。当社が米Oracle社とSolaris/SPARC等のプラチナカスタマープログラム(後に、カスタマーアドバイザリボード)の契約締結を行ったこともあり、その後、継続的に技術的なフィードバックが行われることとなる。

一方、ユーザからの問い合わせの多かった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に搭載された。

SPARC Solarisの仮想化機能では、Intel版のSolaris VPSと同じく当社製のDimensionPlusによるZoneの提供に加え、SPARCならではのロジカルドメイン機能、LDOM(後のOracle VM Server for SPARC)を採用。LDOMはCPUのオーバーコミットもなく、あくまで論理コアやメモリを固定的に割り振るため、リソースの配分に厳格となるため、常に一定の性能をコミットしやすい。

ネットワークファブリックは、10Gbpsx2の20GbpsでスタッキングされたNetwork Switchが用いられ冗長化。サービスネットワークではLAG(リンクアグリゲーション)を用い、1Gbps x 2で冗長化。

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

ユーザのオフィスとの間もNTTフレッツ網を用いたL2での接続線のサービス化。事実上オフィスのLANをそのままのIP空間で延伸できるため、オンプレ機器と当社プライベートクラウドとの通信にも用いられ、オフィス内サーバのP2V(物理から仮想サーバに移設すること)にも役立つこととなった。

ストレージエリアネットワークでも1Gbps x2のLAGを採用。IP-SANとしてiSCSIが選択。ストレージサーバではSolaris ZFSを用い、当社製のDimensionPlus独自のレプリケーションエンジンや、異拠点転送のための枠組みなどを用意。初期はHDDをメインとしながらも、第3世代後半では、Solaris ZFSの機能を用いたキャッシュ(L2ARC、SLOG)にSSDを用いる、ハイブリッドストレージとなっていた。

4G(第4世代)

特徴

4G
  • Intel Xeon SandyBridge/IvyBridge世代を搭載。
    • Intel XeonのCPU世代が一新。第2世代コアアーキテクチャプロセサへ。
    • AVX命令を装備し、より効率良く並列ベクタ演算が可能になった。
    • メモリがDDR3になり、メモリバンドは、42GBytes/sec(1CPU) 〜 120GBytes/sec(2CPU)強化。スレッド数のラインナップは4/24/40/48論理コアまでラインナップ。
    • 搭載メモリは、8GB/32GB/64GB/128GB/256GB。
  • SPARC S7 世代を搭載。
    • Oracle SPARCのCPU世代が一新。
    • メモリコントローラをプロセサに内蔵。DDR4-2400メモリを利用し、メモリバンドは153.6Gbytes/sec。
    • Software in Silicon機能として、シリコンセキュアドメモリ、暗号化アクセラレーション、インメモリDB用にDAX機能を持つ。
  • ストレージファブリックを強化
    • フルSSD化によるIO高速化
    • SANにMPxIOを用い20Gネットワーク化
  • ネットワークファブリックを強化
    • ハードウェアアクセラレーション付きのUTMサービスの開始。
 

利用されたCPUモデル

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

x64アーキテクチャ周波数(GHz)ターボブースト(GHz)3rd Cache(MB)Core(Threads)メモリTDP
E5-26302.32.8156(12)DDR3-1333 x495
E5-2620 v22.12.6156(12)
DDR3-1866 x480
E5-2670 v22.53.32510(20)DDR3-1866 x4115
E5-2690 v233.62510(20)DDR3-1866 x4130
E5-2695 v22.43.23012(24)DDR3-1866 x4115
SPARCアーキテクチャ周波数(GHz)L2 Cache3rd Cache(MB)Core(Threads)メモリTDP
SPARC S74.27I: 512KB+D:1MB168(64)DDR4-2400 x4115

概要

第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に割り振る方が良い可能性もある。

第4世代のプライベートクラウド用ストレージファブリックでは、フル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ファームウェアによる問題や、寿命管理の難しさや応答劣化の管理の難しさを伴った。

これに伴い、ストレージエリアネットワークは高速化が余儀なくされる。Solaris Private Cloudでは、第三世代で開発されたストレージファブリックをベースに10Gbps x2の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つとなっている。

5G(第5世代)

特徴

  • Intel Xeon Haswell Refresh/Broadwell世代を搭載。
    • メモリがDDR4となり、メモリバンドが120〜137GBytes/sまで強化。
    • スレッド数ラインナップは、24/32/40論理コア。
    • 搭載メモリは、128GB/256GB。

利用されたCPUモデル

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

x64アーキテクチャ周波数(GHz)ターボブースト(GHz)3rd Cache(MB)Core(Threads)メモリバンドTDP
E5-2620 v32.43.2156(12)DDR4-1866 x485
E5-2630 v32.43.2208(16)DDR4-1866 x485
E5-2630 v42.23.12510(20)DDR4-2133 x485

概要

第5世代のプライベートクラウドファブリックは、x64アーキテクチャのクラウド用にXeon Haswell Refresh/Broadwell世代を搭載。メモリバンドがコンピュートノードあたり120〜136GBytes/s。CPUラインナップは24/32/40論理コア。搭載メモリは128GB/256GB。

x64アーキテクチャCPUとしてはメジャーアップデートとなる。CPUにL2-TLBを搭載されたため、プロセス数が多いコンテナ型システムに有用ではないかと考えられた。コンテナ型システムは、1つのカーネル上に多量のプロセスが走ることで、メモリのマイナーフォールト(TLBのメモリの入れ替え)が発生しやすいが、L2-TLBがその速度向上に寄与すると考えられた。コンテナを直接マルチテナントとしてユーザに引き渡すサービスはすでになくなっていたが、ハイパバイザ上のゲストマシンの上に、コンテナを設定することは増え始めたため、この性能向上を期待した。

当社のデータセンタインフラストラクチャ部門ではこのCPUは歓迎された。第4世代に比べ消費電力が少なく、活躍した第4世代の性能を、価格以外の全ての面で上回るったからだ。ユーザが乗り換えることを希望していたが、第4世代との併売が続いたこともあり、コストパフォーマンスの高さから継続して第4世代のサーバが好まれた。そのため、残念ながら人気は奮わない形となり、当社での2020年時点での稼働台数は最も少ない。

6G(第6世代)〜現行世代〜

VMware Private CloudSolaris Xeon Private Cloudで提供中。

特徴

  • Intel Xeon Scalable Processor(Skylake SP)を採用。x64アーキテクチャサービス用
    • Intel XeonのCPU世代を一新。32論理コア以上のスレッド数と、幅広いメモリバンド(最大230GBytes/sec)
    • AVX-512などの、科学技術シミュレーションや、AI・画像処理に秀でた拡張命令群を装備
    • Xeon Silverモデル(32/40論理コア)と、Xeon Gold(64/88論理コア)を用意
    • メモリラインナップは96GB/192GB/384GB/768GB
  • Oracle SPARC M8 Processor を採用。Solaris SPARC Private Cloud用
    • リファインされたCPU。256論理コアのスレッド数と、幅広いメモリバンド(最大307GB/sec)
    • 第2世代Software in Silicon。暗号化、データベースアクセラレーション、Javaのストリーム処理が高速に動作
  • ストレージファブリックの強化
    • Enterprise NVMe SSDを本格採用
    • NFSv4.1の採用。新しくリファインした自律型ストレージの採用
  • ネットワークファブリックの強化
    • 同一データセンター内のインターコネクトを400Gbpsに強化
    • リージョン(関東・中部・関西)間の冗長化された通信網。低レイテンシ、ワイドバンド通信の実現
    • ロードバランサー機能、SSLアクセラレータ機能、WAF機能をハードウェアもつADC(アプリケーションデリバリコントローラ)サービスの開始

ラインナップ

x64アーキテクチャ論理コア合計(Threads)メモリバンド合計最大値メモリ搭載(GB)
Xeon Silver32230GBytes/sec96
Xeon Silver40230GBytes/sec192
Xeon Gold64256GBytes/sec384
Xeon Gold88256GBytes/sec768
SPARC T8-1256307GBytes/sec1024
SPARC T8-2512614GBytes/sec2048

利用中のCPUモデル

x64アーキテクチャ周波数(GHz)2nd Cache(MB)3rdCache(MB)CoreメモリバンドTDP
Xeon Silver 41102.18 × 1118 (16)6 × DDR4-240085 W
Xeon Silver 41142.210 × 113.7510 (20)6 × DDR4-240085 W
Xeon Gold 61302.116 × 12216 (32)6 × DDR4-2666125 W
Xeon Gold 61522.122 × 130.2522 (44)6 × DDR4-2666140 W
SPARCアーキテクチャ周波数(GHz)2nd Cache3rdCache(MB)CoreメモリバンドTDP
SPARC M85.0632 × (I: 128KB+ D: 256KB)6432 (256)374GBytes/sec-

概要

第6世代のプライベートクラウドファブリックのコンセプトは、5Gケータイ利用時のサービス高速化ニーズを睨み、「プライベートクラウドのIaaSは、パブリッククラウドのIaaSより、原則として高速でなくてはならない」という命題のもとに設計されている。

第6世代のx64アーキテクチャプライベートクラウドはCPU世代を一新。Intel Xeon Scalable Processor(Skylake SP)を採用。AVX-512などの、科学技術シミュレーションや、AI・画像処理に秀でた拡張命令群を装備しただけでなく、幅広いメモリバンド(1コンピュートノードあたり230GBytes/sec 〜 256GBytes/sec)を提供。

メモリバンドの違いはデータベースなどの処理速度向上にも貢献している。CPUラインナップは、Xeon Silverで32/40論理コア、Xeon Goldで64/88論理コア。メモリラインナップも96GB/192GB/384GB/768GBと、大量かつ大容量メモリの仮想マシン収容を可能とした。

一方、SPARCアーキテクチャプライベートクラウドもCPU世代が一新。SPARC M8 Procesorを搭載。Software in Silicon 第2世代を搭載し、インメモリデータベースや、Java ストリーム処理にさらに適合したDAXと、暗号化支援機能などを持ちつつ、幅広いメモリバンド(1コンピュートノードあたり最大307GBytes/sec)を持つ。

第6世代ストレージファブリックでは、昨今のデータ量増加によるヘビーIOニーズに対応すべく、新たに第三世代のストレージファブリックをベースに再設計され、フルNVMe SSDによる高いIOPS処理能力と転送バンドを確保。実測ベースで数百万IOPS、10GB/secを超えるリードライト速度を確保しているが、ストレージ的には限界性能が見えていない。つまり、通常の利用ニーズでは負荷が不足してベンチマークしきれない程、性能は飛躍している。VMware上のゲストOS内のLinuxからのベンチマークでは、2GBytes/secの読み書き速度を測定するなど、コンピュートノードのSANネットワークバンドを簡単に埋め尽くすことができる高い性能を実現した。

ストレージエリアネットワークは冗長経路を保つ必要があるため、VMware Private Cloud用には NFS v4.1マルチセッショニング、SolarisにはMPxIOを採用。ストレージ側アップリンクで50Gbps、コンピュートノード側で20/50Gbps。 自律型ストレージで、1時間に1度のスナップショットを取得して2週間保持。チェイン・レプリケーションを行う機能を持ち、ディザスタリカバリのために、地理的に離れた異拠点に同期するための機能も持つ。 これらの機能は、昨今のデータを人質に取るランサムウェア「Emotet」などのからの防御にも役立つ。

第3世代のストレージファブリックを元に、自律型に再設計したのには意味がある。第4、5世代のストレージファブリックでは、VMwareではVAAIなどに対応した特化型ストレージを用意していた。これらのストレージは利便性や合理性がありつつも、ソフトウェアスタックが大きく連携、連動することで、逆に、そこ由来のインシデント発生時に復旧が困難になりがちで、ソフトのバグに巻き込まれやすいという問題をはらんでいた。昨今、世界中のクラウドベンダーによるデータ欠損事故はユーザが考えている以上に多く、無視できないレベルに達している。ストレージもソフトウェアで制御される以上、バグが付きものとも言える。そこでデータ安全性を深刻に考慮し、あえてハイパバイザソフトウェアスタックとは連動しない、独立型の構造を持ちながら、データ保全に努める設計を採用した。

第6世代ではネットワークファブリックの進化も大きい。5Gケータイの帯域需要が大きく影響すると考えられたためだ。

まずは同一データセンター内のネットワークファブリック性能を大幅に強化しインターコネクトを400Gで接続。1コンピュートノードあたり20/50Gの帯域を確保。さらにリージョン(関東・中部・関西)間通信インターコネクトの帯域増強と低レイテンシ化。注目すべきは中部リージョンを準関東リージョンと位置づけ、日本のインターネットの中心とも言える東京大手町のIX(インターネットエクスチェンジ)から、中部リージョンのプライベートクラウドに低レイテンシ高帯域で接続。このことで安価な中部リージョンのデータセンターで、大容量でコストパフォーマンスの良いプライベートクラウドを実現した。この地理的距離によるレイテンシは、概ね大抵のパブリッククラウドの日本イーストリージョン内のサーバへの到達時間より短くなっている。

これらの同一データセンター内を越えた、リージョン内通信、リージョン間通信は完全に経路冗長化。L2でそれぞれのリージョンを高速に接続することができるようになった。このことで「Unified DR Private Cloud Fabric (統合された関東・中部・関西のプライベートクラウド)」のコンセプトが生まれ、更に1歩進んだ異拠点データセンター間の連携が可能となっている。

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

それにはネットワークアプライアンスサービスの拡充も必要となるため、ロードバランサ、SSLアクセラレータ、WAFなどの機能を統合したADC(アプリケーションデリバリコントローラ)のサービス提供も開始した。

このように、来たるべき5Gケータイ向けサービスなどにフォーカスを当て、高速でレスポンス速度の高いサービスを実現しつつも、エンタープライズ利用でより使いやすいプライベートクラウドファブリックが構築された。

6GS(現行世代)

High Response Private Cloudで提供中。

特徴

  • Intel Xeon Scalable Processor 第2世代(Cascade Lake Refresh)を搭載
    • CPUのスレッド数が強化されたセカンドエディッション
  • 少メモリ環境である96GBメモリモデルを廃止し、192GBモデル/384GB/768GB/1.5TBモデルをラインナップ
    • 192/384GBモデルではXeon Silver(合計48論理コア)、768GB/1.5TBではXeon Gold(合計80/96論理コア)を採用
  • High Performance Cloudでは、内蔵ディスクにNVMeモデルをラインナップに追加
  • パブリッククラウドと閉域接続するパブリッククラウドリンクをサービス開始

ラインナップ

x64アーキテクチャ論理コア合計(Threads)メモリバンド合計最大値メモリ搭載(GB)
Xeon Silver48230GBytes/sec192GB
Xeon Silver48230GBytes/sec384GB
Xeon Gold80256GBytes/sec768GB
Xeon Gold96280GBytes/sec1.5TB

利用中のCPUモデル

x64アーキテクチャ周波数(GHz)2nd Cache(MB)3rdCache(MB)CoreメモリバンドTDP(W)
Xeon Silver 42142.21216.58 (16)6 × DDR4-240085
Xeon Gold 5218R2.12027.520 (40) 6 × DDR4-2667125
Xeon Gold 6240R2.42435.7524 (48)6 x DDR4-2933165

概要

第6世代セカンドエディッションのプライベートクラウドファブリックのコンセプトは、「ハイブリッドクラウド化ための最適解」という命題のもとに設計されている。

まずは、十分すぎるほど高速であった第6世代を、コストパフォーマンス面を中心に徹底的にリファイン。

CPUはIntel Xeon Scalable Processor 第2世代(Cascade Lake Refresh)を採用。メモリバンドは115GBytes/s 〜 140GBytes/sに強化され、CPUラインナップもXeon Silverモデルで合計48論理コア、Xeon Goldモデルで合計80/96論理コアと線形進化。メモリラインナップは、少メモリ環境である96GBモデルを廃止し、192GB/384GB/768GB/1.5TBと大容量化。性能向上だけでなく料金プランも見直し、「少ない利用量ならパブリッククラウド、量が増えたらプライベート」になるよう、最適化されている。

ストレージファブリックなどは第6世代を踏襲。

ネットワークファブリックには、パブリッククラウドリンクという新サービスを追加。プライベートクラウドとパブリッククラウドをインターコネクトで簡単につなぐことで、ハイブリッドクラウドがやりやすいように、リーズナブルなプランを用意した。通常、パブリッククラウドとプライベートクラウドをつなぐ為には、こういったコネクティビティサービスを申し込むだけでなく、BGPルーティングによるダイナミックルーティングが必要となる。このルータ設置費やルータ設置作業がネットワークに詳しくないパブリッククラウド利用者には敷居が高いため、安易に申し込みができるサービスを拡充した。

クラウド型リモートVPNサービス xen-orchestra.html 採用情報 TeraCLOUD 清水エスパルス
Oracle GOLD Partner

ジャストプレイヤーはオラクル認定ゴールドパートナーです。
SPARCをはじめ、オラクル社の製品を用いたクラウド環境の構築、運用をサポートします。


JUSTPLAYER.NE.JP

https://justplayer.ne.jp/

info@justplayer.com

ジャストプレイヤー株式会社
JUSTPLAYER Co.,Ltd.
静岡県静岡市葵区上石町2-4 河村上石町ビル 1F
tel/050-3801-5987 fax/054-251-1757