6G.6Gs.6Gt.ハイブリッドクラウドの片翼とは？

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

特徴

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

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

x64アーキテクチャ	論理コア合計（Threads）	メモリバンド合計最大値	メモリ搭載(GB)	シリーズ
Xeon Silver(Skylake-SP)	32	230GBytes/sec	96	6G
Xeon Silver(Skylake-SP)	40	230GBytes/sec	192	6G
Xeon Gold(Skylake-SP)	64	256GBytes/sec	384	6G
Xeon Gold(Skylake-SP)	88	256GBytes/sec	768	6G
Xeon Silver(Cascade lake refresh)	48	230GBytes/sec	192GB	6Gs
Xeon Silver(Cascade lake refresh)	48	230GBytes/sec	384GB	6Gs
Xeon Gold(Cascade lake refresh)	80	256GBytes/sec	768GB	6Gs
Xeon Gold(Cascade lake refresh)	96	280GBytes/sec	1.5TB	6Gs
Xeon Silver(Icelake-SP)	24	341GBytes/sec	512GB	6Gt
Xeon Silver(Icelake-SP)	40	341GBytes/sec	1024GB	6Gt
EPYC(Genoa)	32	460GB/sec	384GB	6Gt
EPYC(Genoa)	32	920GB/sec	768GB	6Gt
EPYC(Genoa)	64	920GB/sec	1536GB	6Gt
SPARC S7-2	128	307GBytes/sec	256/512GB	6G/6Gs/6Gt
SPARC T8-1	256	187GBytes/sec	512/1024GB	6G/6Gs/6Gt
SPARC T8-2	512	374GBytes/sec	1024/2048GB	6G/6Gs/6Gt

利用中のCPUモデル

x64アーキテクチャ	周波数(GHz)	2nd Cache(MB)	3rdCache(MB)	Core	メモリバンド	TDP	6G	6Gs	6Gt
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		✓
Xeon Silver 4310	2.1	12.50	18	12(24)	8 x DDR4-2667	120W			✓
Xeon Silver 4316	2.3	25	30	20(40)	8 x DDR4-2667	150W			✓
EPYC 9124	3.0	16	64	16(32)	12 x DDR5-4800	200W			✓
EPYC 9334	2.7	32	128	32(64)	12 x DDR5-4800	210W			✓
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インフラストラクチャに対する性能向上の期待に応えたものだ。

CPU

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

また6Gt(サードエディッション)より、AMD EPYCを採用。当社としては2G以来のAMD CPUの導入となる。EPYCはIntelとほぼ同じ命令群を持ちつつ、コア数も然る事ながら、PCI Expressバスが増え、Inter Connected Storageの接続本数に有利だと考えられたためだ。

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

参照≫Techストーリー/西川善司の「InfiniCloudのサーバーの中身、見せてもらえます？」/第1回 サーバのCPUとメモリ帯域編

ハイパバイザ

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

オープンソースベースのIaaS基盤であるHigh Response Private Cloudでは、XenServerベースのXCP-ngを採用。加えてXenOrchestraによるオーケストレーションが行われており、XenインスタンスのWebベースの管理が可能となっている。同拠点上でのインスタンスの自動バックアップや、異拠点レプリケーションが可能になるため、安価にDRを前提としたよりロバストな環境を実現することができるためだ。6GtではさらにXCP-ngの速度チューニングを行う。主な最適化ポイントは2つ、Dom0の仮想化層に対してCPUを多く割当て、ボトルネックを解消した形だ。

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

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

ストレージ

どの時代でも、ストレージファブリックに要求されるものは、データの安全性と速度である。実はこの2つは基本的には二律背反するため、基本はどちらかをメインにとらえるしかない。

参考≫テクニカルノート/CAP定理を時間と空間に拡張する「落ちず、速く、信頼できるサービスをどう作るのか？」

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

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

第6世代に再び自社製のストレージに変更し、「自律型ストレージ」再設計したのには理由がある。

第4〜5世代のVMware用ストレージは、VMwareの為のAPIであるVAAIなどに対応したストレージ製品を利用していた。これらのVMware用のストレージ製品は、ハイパバイザとストレージの間でソフトウェアが連携、連動、これは、VMwareのクラスタリングファイルシステムにおいて発生する「ロック」を狭域化するなど、技術的かつ合理的な理由があるためだ。もちろん、製品によっては利便性のために用意されている機能もある。

しかしハイパバイザと連携するということは、ハイパバイザに由来するクラスタリングファイルシステムの問題も連動しやすい。負荷が増えてストレージの臨界点動作の時、その時でのみ起きうる不具合は、復旧困難になりがちだ。これはデータロストという致命的な事故にも繋がる。

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

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

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

自律型であれば、コンフィギュレーションにより、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)だけでなく、ユーザネットワークに対しても,ファイルレベルストレージ、ブロックレベルストレージとして提供できるようになったのも特徴だ。これらのストレージを直接、インスタンスから操作できると、現世代の選別したオンプレミスシステム並の性能を出すことができる。

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

参照≫Techストーリー/西川善司の「InfiniCloudのサーバーの中身、見せてもらえます？」/第2回ストレージ編

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

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の中心となり、どちらでもアクセスが可能になる必要があるためだ。

参照≫Techストーリー/西川善司の「InfiniCloudのサーバーの中身、見せてもらえます？」/第3回ネットワーク編

まとめ

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

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

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

たとえば関東の会社にとって、関西にあるDR用サーバリソースは、普段有効利用されることが少なく、単なる置物のサーバリソースになる傾向がある。企業の情報システム部にとっては必要でありつつも、会社から見て削減されやすく頭の痛い問題だ。もしもこれらが、L2、ワイドバンド、低レイテンシ通信ができるならば、全ての拠点のサーバリソースは、通常時から仮想マシン単位で移動、クローン可能になり、ロードバランサーで分散動作させて有効利用することができる。

データストア(主にデータベースや分散KVS)も、レプリケーションやクローンが可能なので、きちんと障害時に「そのまま動作する」環境を作りやすい。いざディザスタが起きた際は、データストアのマスタ切り替えをするだけですむため、ディザスタ時の情報システム部の負担が大きく減るメリットもある。

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