コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第16回　1Pbpsのデータセンターネットワークを実現したJupiter（パート4）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第16回　1Pbpsのデータセンターネットワークを実現したJupiter（パート4） (中井悦司) 2017年5月

はじめに

　2015年に公開された論文「Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network」をもとにして、Googleのデータセンターで利用されるネットワーク技術を紹介していきます。前回は、初期の世代にあたるFirehoseのハードウェアアーキテクチャーを紹介しましたが、今回は、その後継世代におけるアーキテクチャーの進化を説明します。

WatchtowerとSaturnのアーキテクチャー

　前回、Firehose 1.1の課題として、ネットワークケーブルの配線が複雑になるという点をあげました。これは、複数のラインカードを納めたシャーシ内部に、ラインカード間のポートを相互接続するバックプレーンが存在しないことが1つの理由です。そこで、次の世代となるWatchtowerでは、8枚のラインカードを収納するシャーシ内部にバックプレーンが用意されました。図1の左下は、3個のスイッチチップを搭載した8枚のラインカードが、バックプレーンで相互接続された状態を示したものになります。

fig01

図1 Watchtowerの外観と内部接続の構成（論文より抜粋）

　それぞれのラインカードは、10G✕16ポートに対応するスイッチチップを3個搭載しており、その内の2個のチップは、8個のポートを外部ポートとして提供しています。つまり、図1の左上にある1つのシャーシは、128個の10Gポートを持つL2スイッチとして動作することになります。さらに、バックプレーンによる内部接続は、すべてのポート間がノンブロッキングで動作するように設計されています。つまり、すべてのポートが同時に10Gbpsの性能で動作することが可能です。
　また、Watchtowerでは、外部接続ポートにSFP+モジュールを採用しており、シャーシ間の接続は、すべてファイバーケーブルを使用するようになりました。配線作業をより簡単にするために、複数の光ファイバーを束ねたファイバーバンドルを採用しています。図1の右は、2本のラックに搭載した計4台のシャーシの様子ですが、Firehose 1.1（前回の図3）に比べて、配線がすっきりしていることがわかります。前述の論文には、ファイバーバンドルを採用することによるコスト削減効果の試算も掲載されています。
　そして、その次の世代となるSaturnでは、ラインカードに搭載するスイッチチップが10G✕24ポートに変更されて、1つのシャーシに12枚のラインカードが搭載可能になりました。1つのシャーシは、288個の10Gポートを外部ポートとして提供しており、バックプレーンによる内部接続は、Watchtowerと同様に、すべてのポート間がノンブロッキングで動作するように設計されています。さらに、Saturnでは、サーバーを接続するToRスイッチのポートも10Gに変更されています。

Jupiterのアーキテクチャー

　さらに次の世代となるJupiterでは、いよいよ、40Gポートに対応するスイッチチップが採用されました。そして、Watchtower、Saturnとの大きな違いとして、モジュール型のハードウェア設計が利用されるようになりました。これは、後述するCentauriシャーシと呼ばれる小型のシャーシを組み合わせることで、さまざまな構成のL2スイッチを実現しようという発想です。一般に、Closトポロジーのネットワークでは、ToRスイッチ、アグリゲーションレイヤー、スパインレイヤーという3階層のネットワークを構成することになりますが、40G対応チップの性能を無駄なく利用するには、それぞれの階層のスイッチを適切に構成する必要があります。モジュール型の設計により、各階層のスイッチを柔軟に構成できるようにすることが目的になります。
　Jupiterが採用した構成は、図2のようになります。左上のCentauriシャーシは、40G✕16ポートに対応したスイッチチップを2個搭載したラインカードを2枚収納することで、合計64個の40Gポートを提供します。シャーシ内にバックプレーンはなく、すべてのポートが外部ポートとして提供されます。また、設定変更により、1つの40GBポートは、4つの10GBポートしても利用できるようになっています。たとえば、ToRスイッチでは、Centauriシャーシをそのままの形で利用します。すべてのポートを10Gに設定して、1つのチップは、48個のサーバーポートと16個の上位接続ポートを提供します。

fig02

図2 Jupiterのモジュール型構成（論文より抜粋）

　次に、ToRスイッチの上位にあるアグリゲーションレイヤーでは、4個のCentauriシャーシを束ねたミドルブロックを利用します。図2の左下にあるように、1つのミドルブロックは、256個の10GBポートをToRスイッチ側に提供して、64個の40GBポートをさらに上位のスパインレイヤーに提供します。そして、図2の右下に示すように、ミドルブロックを8個並べたものが1つのアグリゲーションブロックになります。アグリゲーションレイヤーには、最大で64個のアグリゲーションブロックが並ぶ形になります。最後に、最上位に位置するスパインレイヤーは、複数のスパインブロックを並べて構成します。1つのスパインブロックは、図2の右上のように、6個のCentauriシャーシを束ねた構成になります。1つのスパインブロックで、128個の40GBポートをアグリゲーションレイヤー側に提供します。
　そして、これらのブロックを搭載したラックは、事前にラック内でケーブリングされた状態でデータセンターに搬入されます。図3は、4個のミドルブロックを搭載したラックが2本ならんだ構成で、これでちょうど、1つのアグリゲーションブロックが構成されることになります。これと同様に、スパインブロックについては、1本のラックに2つのスパインブロックを格納した状態が基本構成となります。Jupiterでは、こららのブロックを組み合わせた最大構成において、合計1.3Pbpsのサーバー間トラフィックを転送することが可能になりました。

fig03

図3 2本のラックで1つのアグリゲーションブロックを構成した状態（論文より抜粋）

次回予告

　今回は、Googleのデータセンタースイッチにおける、ハードウェアアーキテクチャーの変化を紹介しました。最後に紹介したJupiterでは、Centaruiシャーシを組み合わせたモジュール型のアーキテクチャーを採用することで、さまざまなブロックを柔軟に構成しながら、メンテナンスコストを低減する工夫がなされており、実用性を考慮した合理性が感じられます。
　パート4まで続いたデータセンターネットワークの話題は、今回で最後になります。次回は、データセンター間を接続するグローバルネットワークに関する話題をお届けしたいと思います。
　なお、2017年6月に開催されるGoogle Cloud Next/Tokyoでは、冒頭の論文の著者でもあり、実際にJupiterの設計に関わったGoogleのソフトウェアエンジニアを招いて、「プリンシパル・ソフトウェアエンジニアが語るGoogleのネットワークインフラ技術」というセッションを実施する予定です。Googleのネットワーク技術に興味のある方は、ぜひご参加ください。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡