Google Jupiter's MEMS based OCS

Takao Setaka @twtko

#Google のデータセンターネットワーク基盤であるJupiterが、OCSの導入によってClosアーキテクチャから直接接続アーキテクチャのへと進化している件について、のんびりと公開論文をもとにTweetしていきますが、まずはBlogが日本語抄訳されていますのでこちらをお読み下さい。 cloud.google.com/blog/ja/topics… twitter.com/twtko/status/1…

Takao Setaka @twtko

DCネットワークを少しばかり齧ったことのある身として、このBlog記事とリンクされた論文の中で紹介されている "Optical Circuit Switching" は魔改造どころの話ではなく、そうきますか！的な超技術です。これについては来週じっくりとコメントTweetしていきたいなと思います。 cloud.google.com/blog/topics/sy…

2022-09-02 08:18:00

Takao Setaka @twtko

まず #Google Jupiterにおける今回の進化の何がエグいかといえば、Clos FabricにおけるSpineが抱える各種問題を解決するために、光回路のL1スイッチであるOCSを社内開発して既に実サービス環境に本格展開してしまっている、ということが公開されたことです。論文はこちら。 research.google/pubs/pub51587/ pic.twitter.com/6eIOvqfgHp

拡大

Takao Setaka @twtko

ClosファブリックにおけるSpineの最大の問題は何か、それはSpineがFabricの性能を決めてしまう点です。DC規模でネットワークを構成する場合においてサーバラックやその集約スイッチは順次導入されていきますが、Spineを初期構成時に必要分展開してしまった場合、それが性能上限を決定してしまいます。 pic.twitter.com/bUpw8iSmhF

拡大

Takao Setaka @twtko

たとえばJupiterの場合はサーバラックのToRを束ねるアグリゲーションスイッチをSpineに接続しますが、新規アグリゲーションスイッチが100Gbpsに対応していてもSpineが40Gbpsにしか対応していなければ、結局仕様上の最大帯域性能は発揮できないこととなってしまいます。つまり順次増強に対応しづらい。 pic.twitter.com/ZAGebTe4LV

拡大

Takao Setaka @twtko

なのであれば、そもそも制約を作ってしまうSpineスイッチなど使わずにアグリゲーションスイッチ同士を直接L1接続してしまえばいいんじゃね？というぶっ飛んだ発想に基づく仕組みが、今回のOCSです。パッチパネルと違い、電気的に接続を更新できるため、L1ですが論理的な接続制御が可能な点が利点です。 pic.twitter.com/aXXH1I0bWQ

拡大

Takao Setaka @twtko

そこがムッチャ頭良いと思ったポイントの一つで今後Tweetする予定もあるけど回答しちゃうと、L1なのでスイッチにはケーブル抜き差しされるのと同じなので、そんなに頻繁には物理トポロジーは変更していなくて、1ホップ接続（別のアグリゲーションスイッチを経由する）も許容することで制御しています。 twitter.com/kazunori_279/s…

Kazunori Sato @kazunori_279

@twtko 論文読まずに質問で恐縮ですが、OCSって切り替え遅延がms単位ですよね。そのスピードで間に合うものなのでしょうか？

2022-09-09 15:21:55

Takao Setaka @twtko

OCSを利用することのメリットは単にSpineの性能制約を回避できるだけではなく、OCS自体は単に光制御をしているだけのため、複数世代の混在に対応できる点です。もちろん、光波長グリッドに互換性が必要なため、WDMトランシーバーもCWDM4に仕様を合わせて開発して組み合わせて利用する徹底ぶりです。 pic.twitter.com/iwpF9jYAJr

拡大

Takao Setaka @twtko

OCS, WDM光トランシーバに加えて、3つ目のハードウェアコンポーネントが光サーキュレーターです。これをスイッチとOCSの間に挟み込む事で光信号を双方向リンクに置き換え、ファイバの本数とOCSのフロントポート数を半減させてしまう徹底ぶりです。パッシブデバイスなのでこれも複数世代に対応します。 pic.twitter.com/wDJWdGw8Sh

拡大

Takao Setaka @twtko

Jupiterではサーバラック単位でToRが配置され、アグリゲーションブロックスイッチがToRを集約します。実際にはアグリゲーションスイッチは2段構成の複数スイッチ構成となっている為、ここにClos Fabricが残っており今回SpineからOCSへと置き換えられたのはSuper Spine的な階層と言えるかもしれません。 pic.twitter.com/M77MD54pzF

拡大

Takao Setaka @twtko

大規模だからこそOCSの導入によるアグリゲーションブロック間の直接接続が成り立つと思う点が、このUplinkポート数です。シラッと書いてありますが、アグリゲーションブロックあたり512ものUplinkで接続されています。これだけの数のUplinkがあるからこそ、OCSを介して直接接続し合う構成が可能です。 pic.twitter.com/1NsPFAtJTy

拡大

Takao Setaka @twtko

サーバとネットワークとDC建屋の更新スピードはそれぞれ異なります。OCSの導入は複数世代で異速度のアグリゲーションブロックの混在利用を前提としており、CWDM4トランシーバと光サーキュレータによってコストと配線数を最小限する上、OCSとの接続配線数も随時増強とし初期コストを最小化しています。 pic.twitter.com/cOms81ZW2i

拡大

Takao Setaka @twtko

アグリゲーションブロックのUplink接続数を段階的に増強するのであれば、OCSも最初から全台配置する必要はありません。また、光サーキュレータはパッシブデバイスで電力を消費せず、OCSも光信号のL1接続のみでスイッチングもルーティングも行わないため、デバイスとしての消費電力は非常に小さいです。 pic.twitter.com/3Ypii5DtMr

拡大

Takao Setaka @twtko

SpineをOCSに置き換えることで論理的にはアグリゲーションブロック間の直接接続となりますが、パッチパネルではなくOCSが間に挟まることでアグリゲーションブロック間の接続数は必要帯域によってソフトウェア的に変更が可能です。これによりアグリゲーションブロック増設時の物理作業も最小限です。 pic.twitter.com/yaHS9tLem5

拡大

Takao Setaka @twtko

JupiterのOCS導入に際して素晴らしいと思った点が、③の図のように直接パスと1ホップパスを組み合わせたトラフィックエンジニアリングを実装している点です。通信量の少ないアグリゲーションブロックを経由するパスを含めることで配線変更を最小化し、かつ異世代間接続を最小化して無駄を減らせます。 pic.twitter.com/250TscZduY

拡大

Takao Setaka @twtko

⑥の場合、AとBは100Gbps、CとDは200Gbpsに対応していますが、OCSを介する接続はL1なのでA-C間やB-D間の接続は100Gbpsになってしまいます。この場合、A-D間やB-C間にも接続を増やすよりも、1ホップすることを許容するほうが全体としての帯域利用効率は高まる場合があります。素晴らしい設計思想です。 pic.twitter.com/ZvT7l5qH8c

拡大

Takao Setaka @twtko

Jupiterが直接接続と1ホップ接続を組み合わせたトラフィックエンジニアリングを行う理由は、トラフィック需要は常に変化し続けるため不確実性があるからです。OCSは通信をフレームやパケットとして転送するのではなく光信号として中継制御をしているので、高頻度での接続トポロジの変更はできません。 pic.twitter.com/4Jcgi9wlQE

拡大

Takao Setaka @twtko

②と③では、OCSを通じたリンク構成は変更されていませんが、A / B / C 間の帯域要件が変化しています。この変化に対して、OCSを用いているJupiterではアグリゲーションブロック間の論理接続を変更するのではなく、より帯域を必要とするA-C間の通信の一部をA-B-Cと1ホップにすることで対応しています。 pic.twitter.com/OdPIXlCLSk

拡大

Takao Setaka @twtko

JupiterではOCSの導入と合わせて一気にClos接続から直接接続へと更新したわけではありません。まずは単純にSpineとアグリゲーションブロックの間にOCSを配置する構成変更から始まっています。この構成でもSpineへの接続数を制御できるメリットがありますが、だったらSpine要らなくね？という展開です。 pic.twitter.com/qMZ3Pj5pUn

拡大

Takao Setaka @twtko

ちなみにSpineとアグリゲーションブロック間にOCSを挟み込むモチベーションは、Spine増設時に既存の配線を差し替える手間がかからないことです。Spineを増設する際にもアグリゲーションブロックを増設する際にも増設分に対する追加配線は必要ですが、既存配線はOCSで接続を切り替えるだけで済みます。 pic.twitter.com/rZoUT0pbOE

拡大

Takao Setaka @twtko

OCSを用いたアグリゲーションブロック間の直接接続ファブリックでは、OCSで接続パスを切り替える"Topology Engineering"と、アグリゲーションブロック間の論理接続経路を直接接続と1ホップ接続の組み合わせで論理制御する"Traffic Engineering"の組み合わせでControlerからSoftware制御されています。 pic.twitter.com/iEeYZ65ARp

拡大

Takao Setaka @twtko

アグリゲーションブロック間の接続をOCSで切り替えるTopology Engineering制御は一旦通信をドレインした上で行う必要があるため、新規アグリゲーションスイッチの追加時や、アグリゲーションブロック間の通信量が大きく変化した際等に低頻度で実行されます。可能な限り最小限とする事が望ましいです。 pic.twitter.com/E4q5F9BZss

拡大

Takao Setaka @twtko

OCSによる切り替えは全体の帯域を一定割合以上確保しつつ実施するために段階的な切り替えが行われます。この図はAとBの2つからCとDを追加して4つのアグリゲーションブロックへと切り替えていく段階の例ですが、ステップ数を最小化しつつもあらゆる時点で全体帯域の80%以上が確保されています。ザ数学。 pic.twitter.com/b3uT3r51VR

拡大

Takao Setaka @twtko

DCネットワークからSpineを排除するメリットとしては、①構成要素の最小化（OCSは故障要素が少ない）、②遅延（ホップ数）の最小化、③Spineコストと消費電力の削減（OCSはL1制御なのでパケット処理不要）、④複数世代アグリゲーションブロックの収容に対応（長期利用）等、様々な利点があります。 pic.twitter.com/UFSOWIkX6n

拡大

Takao Setaka @twtko

OCSは専用ラックに搭載され、各ラックには8台ずつOCSが収容されます。増設は必ずこのラック単位とすることで、Fiberの引き回し作業をラック範囲に限定し工数を削減しています。各アグリゲーションブロックから各OCSへは均等に接続する様に配線することで、障害時の影響度合いの偏りを排除しています。 pic.twitter.com/RSaZc0WXiP

拡大

Takao Setaka @twtko

OCSは"Orion Controller"と呼ばれるコントローラによって制御されており、障害等の影響範囲を限定するためにコントローラと制御対象のOCSの組み合わせは4つの障害ドメインに分離されています。これにより、複数の障害ドメインを同時に構成変更しない限り、問題発生時に最大25%以上の帯域を失いません。 pic.twitter.com/XNO6qPkM1n

拡大