コラム

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

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

CTC 教育サービス

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

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

はじめに

　2015年に公開された論文「Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network」をもとにして、Googleのデータセンターで利用されるネットワーク技術を紹介していきます。今回は、ネットワークスイッチの物理構成を中心とした、ハードウェアアーキテクチャーを解説します。

Firehoseのアーキテクチャー

　前述の論文では、第13回の図1に示した、5つの世代のネットワークスイッチが紹介されています。その中でも、最初の世代にあたるFirehose 1.0は、サーバーハードウェアを用いて実装したとの記述があります。これまで、ネットワークスイッチを独自設計した経験がなかったため、サーバーハードウェアの設計経験を活かして、まずは実験的に、サーバーハードウェアのPCIボード上にスイッチチップを搭載した構成を試したそうです。しかしながら、ハードウェアの故障率や再起動にかかる時間、あるいは、サーバー間の配線の複雑化など、さまざまな問題に直面することになり、結局、Firehose 1.0は本番環境で利用されることはありませんでした。

　Firehose 1.0の経験を踏まえて、次の世代となるFirehose 1.1では、複数のネットワークポートとポート間でのパケットスイッチングを行うスイッチチップを搭載したラインカードを独自に設計しました。それぞれのラインカードは、PCI経由で外部から制御できるようになっており、6枚のラインカードを収容可能なシャーシと、これらのラインカードを制御するためのシングルボードコンピュータの設計も行ったそうです。図1は、実際のラインカードと6枚のラインカードを収めたシャーシの写真になります。

fig01

図1 Firehose 1.1のラインカードとシャーシ（論文より抜粋）

　そして、これらのラインカードのポートを相互接続することで、図2に示した、Closトポロジーのネットワークを構成します。図2に含まれる、それぞれの四角が1つのラインカードに対応します。最下段のToRスイッチは、2枚のラインカードがペアで構成されており、それぞれのラインカードは、サーバーを接続する1Gのポートが48個、ペアとなるスイッチと相互接続する10Gのポートが2個、そして、上位のスイッチと接続する10Gのポートが2個という構成です。ToRスイッチよりも上位にあるスイッチを構成するラインカードは、10Gのポートを8個持っており、上位と下位のそれぞれとの接続に4ポートずつ使用します。

fig02

図2 Firehose 1.1のClosトポロジー（論文より抜粋）

Firehoseの課題

　Firehose 1.1の課題の1つは、ネットワークケーブルの配線でした。シャーシ内部には、ポート間を内部接続するバックプレーンが無かったため、すべてのポートをCX4ケーブル（10G対応のカッパーケーブル）で相互接続する必要がありました（図3）。しかしながら、CX4ケーブルは太くて取り回しが難しく、最大14メートルという長さの制限があります。特に、サーバーラックに設置したToRスイッチと別のラックに収納された上位スイッチの間に、適切にケーブルを敷設するのは困難でした。そこで、メタルの端子をファイバーに変換するコンバーターを取り付けた、専用のファイバーケーブルを特別に用意したそうです。図3の右下は、専用のファイバーケーブル（左）と通常のCX4ケーブル（右）を比較した写真になります。

fig03

図3 Firehose 1.1のケーブリングの様子（論文より抜粋）

　このFirehose 1.1は、実際に本番環境への導入が行われました。この際、実績のないテクノロジーを導入するリスクを鑑みて、問題発生時の影響を最小限に留めるための工夫も行われました。図4のように、既存のルーターとFirehose 1.1を並列に配置して、クラスター外部との通信はルーターを経由して行い、クラスター内の通信のみをFirehose 1.1に流します。そして、Firehose 1.1に致命的な問題が発生した場合は、ToRスイッチの設定を変更することで、すべての通信をルーター経由で行うように切り替える仕組みを用意しました。一種の「緊急切り替えボタン」を用意したというわけです。

fig04

図4 Firehose 1.1とルーター装置を並列配置した構成（論文より抜粋）

次回予告

　今回は、Googleが独自設計したデータセンタースイッチの中でも、初期の世代にあたる、Firehose 1.0/1.1のハードウェアアーキテクチャーを紹介しました。もしかしたら、予想外にシンプルな仕組みに感じられたかも知れません。そこには、自分たちの利用用途に特化して、本当に必要な機能をストレートに実装することで、高いコストパフォーマンスを実現しようという思想があるのかも知れません。次回は、Firehose 1.0/1.1の後継となる、Watchtower、Saturn、そして、Jupiterへと至る、ハードウェアアーキテクチャーの進化を紹介したいと思います。

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