Google Jupiter's MEMS based OCS

Takao Setaka @twtko

障害ドメインの分離は当然コントローラとOCSだけではなく、アグリゲーションブロックについても同様です。各アグリゲーションブロックは4つに分離された障害ドメインごとのOCSに均等に接続されます。添付画像はアグリゲーションブロックの一部と概念図です（ApolloはJupiterに対するOCS展開計画名）。 pic.twitter.com/Qrd0J5bqFp

拡大

Takao Setaka @twtko

この図でOrion ControllerにIBR-Cと書かれているのは、Inter-Block Router-Centralの略です。Orion Controllerはアグリゲーションブロック間の転送パスを計算し、直接接続と1ホップ接続を組み合わせてブロック間のルーティングアドバタイズメントを動的に調整することで到達性と性能要件を達成します。 pic.twitter.com/pwZ0v9M4uE

拡大

Takao Setaka @twtko

この図でOCSが"Orion DCNI"となっているのはOCSブロックをData Center Network Interconnectionと読んでいるからです。OCSはL1でトポロジーを制御していますが、アグリゲーションブロックはOpenFlowベースの独自拡張L2転送という話もありますが、私は柔軟性のあるL3でトラフィック制御していると予想。 pic.twitter.com/PgfXGXlTVn

拡大

Takao Setaka @twtko

"Apollo serves as the backbone of all of our datacenter networks, having been in production for nearly a decade in support of all of the datacenter use cases outlined above." ってサラッと書かれていて衝撃的。OCSの展開と実装は最近の話ではなく、10年近くの実運用に基づく、と。ﾏﾁﾞｶ

Takao Setaka @twtko

なお、Mission Apollo はデータセンター規模でOCSとそれに付随する光サーキュレータおよびWDM光トランシーバの展開計画名です。これらの物理的側面については以下で公開されている論文"Mission Apollo: Landing Optical Circuit Switching at Datacenter Scale"が詳しいです。 arxiv.org/abs/2208.10041

Takao Setaka @twtko

OCSを組み込んだ直接接続Fabricでは、新規アグリゲーションブロックの追加時や大幅なブロック間通信量の変化に対してはTopology Engineeringで対応します。この際、再構成をなるべく短時間で実施しつつ削減されてしまう帯域を最小に抑える組合せ計算はNP困難であるため因数分解近似値が利用されます。 pic.twitter.com/rS0rafG25Q

拡大

Takao Setaka @twtko

Jupiterのコントロールプレーン Orion は、スループットと効率を最大化することを目的として、Topology Engineering (ToE) とTraffic Engineering (TE) を組合せた制御を行います。論理パスとして可能な限り直接パスを利用することを目指しており、Jupiterにおける直接パスは60%、平均パス長1.4です。 pic.twitter.com/LRaeORb4SE

拡大

Takao Setaka @twtko

OCSは従来のSpineに対する管理との親和性のために管理InterfaceとしてOpenFlowが実装されており、2つのポート間の接続を双方向の2つのフローとしてプログラムすることで定義しています。 match {IN_PORT 1} instructions {APPLY: OUT_PORT 2} match {IN_PORT 2} instructions {APPLY: OUT_PORT 1}

Takao Setaka @twtko

OCSはコントローラとの接続性を失った場合、最後にプログラムされたクロスコネクト状態を維持する様になっています。これにより最適化の度合いは下がっても全体の接続帯域は確保されます。コントローラとの接続が復旧すると、自動的に最新のIntentに基づいて構成が適用されます。やはり定義はIntent。

Takao Setaka @twtko

OCSはMEMSを用いて電気的に経路を制御しているため、電源障害時には論理リンクは切断されます。電源を4系統に区分することで重大な電力問題が発生しても25%以上の損失が発生しない様に設計されており、それを超える障害はFabric全体が影響を受ける事態でありFrontのLBでFabricごと排除される想定です。

Takao Setaka @twtko

コントロールプレーンであるOrionはFabric全体のあるべき論理トポロジーとそれを実現するためのL2/L3の構成を管理していますが、OCSが関与するのはL2までです。L1デバイスであるOCSがL2を意識するのは、直接接続と1ホップする関節接続の組合せでL2としての帯域が決定される仕組みとなっている為です。

Takao Setaka @twtko

OCSにおけるTraffic Engineeringにおいて直接接続に加えて1ホップを許容している点は、通信の柔軟性と帯域のバーストへの耐性を高める上で重要です。4の帯域を持つA-B-Cの接続においてA-B間の通信が2→4となった場合、(a)ではA-B間は100%になりますが1ホップ有の(b)では25%以上の余裕が確保されます。 pic.twitter.com/8o9w0TrWI5

拡大

Takao Setaka @twtko

AとBは200Gbps, Cは100Gbpsに対応しており各Blockが500ポートずつ相互接続に利用できる場合、単純に相互に250ポートずつ接続するとA-B間は50TbpsとなりA-B要件を満たしません。この場合Topology EngineeringでA-B間に300ポートを振り分け、さらにTraffic EngineeringでA-C間通信を構成して対処します。 pic.twitter.com/AFhkdD2zDs

拡大

Takao Setaka @twtko

この"Google Cloud Infrastructure Innovation"という短い動画の0:24〜で手の上に載せられているシリコンって、たぶんOCSに入っているMEMSだと思います。さりげなーく。 youtube.com/watch?v=xudl_j…

拡大

Takao Setaka @twtko

論文におけるこの部分のタイトルは"Live Fabric Rewiring"。物理的なFabricの拡張には物理作業が必然的に伴いますが、同時に必ず必要となる論理的な構成変更の部分について、帯域影響を最小化しつつ構成変更に対応する制御をソフトウェア化できた点がOCS導入における最大の成果といえるかと思います。 pic.twitter.com/tVFW2JzsfJ

拡大

Takao Setaka @twtko

私が昼にTweetし続けている #Google のデータセンターを支える Optical Circuit Switch こと OCS についてのTweetシリーズですが、スケジュール投稿している都合でThreadになっていなくて訳がわからん、という方も多いかと思いましたので、togetter まとめを公開しました。 togetter.com/li/1948321

Takao Setaka @twtko

#Google データセンターを支えるOCSの技術解説については、Cloud Solutions Architectの中井さん @enakai00 がCTC教育サービスのコラムで連載されている「グーグルを支えるテクノロジー」の第136回〜でもわかりやすく紹介されていますので、是非合わせてご覧ください。 school.ctc-g.co.jp/columns/nakai2/

Takao Setaka @twtko

JupiterのSDNコントロールプレーンであるOrionは、2段階でルーティングを処理することで分散と高可用性を実現しています。First Levelは各Orionドメイン内のルーティング制御、Second LevelはOrionドメイン間のルーティング制御です。各アグリゲーションブロックは1つのOrionドメインに含まれます。 pic.twitter.com/gmsPc1ock7

拡大

Takao Setaka @twtko

Orionドメイン内のルーティングはRouting Engine (RE)によって制御され、アグリゲーションブロック内の接続に加えてアグリゲーションブロック外との接続を制御します。実処理としてはアグリゲーションブロック内のOCSを4つのドメインに分割しそれぞれを管理するコントロールプレーンを分散しています。 pic.twitter.com/bL7L5woWHt

拡大

拡大

Takao Setaka @twtko

First LevelのREに対して、Second Levelではアグリゲーションブロック間のルーティングを制御するInter-Block Router-Central (IBR-C)がブロック間の最適な転送パスを計算した上でルーティングアドバタイズメントを調整する事でブロック間の到達可能性を確立させています。こちらも4分割されています。 pic.twitter.com/eLhcFCjn5K

拡大

拡大

Takao Setaka @twtko

First LevelのREと、Second LevelのIBR-Cは、それぞれ独立してアグリゲーションブロック内と間のルーティングを制御していますが、これらはDCNIとして4つの独立したコントローラで制御されています。これにより、全体としての帯域最適化の度合いは多少犠牲としていますが、障害影響を1/4に制限します。 pic.twitter.com/Ihh0QbJris

拡大

拡大

Takao Setaka @twtko

OCSの冗長性は電力系統の分離に至るまで考慮されており、建物レベルの重大な電力問題が発生した場合においても1/4の影響で抑えられる様に設計されています。それよりも大規模な障害ではサーバやストレージ等にも影響が生じていることが想定され、ファブリックレベルでの可用性確保に意味はありません。

Takao Setaka @twtko

Clos Fabricの場合はSpineを経由するECMPで経路分散されますが、OCSを用いたDirectconnect Fabricで最短パスのみで経路制御を行うと、n個のブロック間において最悪パターンでn:1のオーバーサブスクリプションが発生してしまいます。そのためDirectconnect Fabricにおいては非最短パス転送が必要です。 pic.twitter.com/g1XpKqkVRH

拡大

Takao Setaka @twtko

ブロック間の通信が概ね均一となるランダム状態の場合は、最短パス転送のみでオーバーサブスクリプション率を1:1に近づけることが可能ですが、需要の動的な変化に対応するためにはTopology Engineeringだけでの対処では困難な為、非最短パス転送を組み合わせることでブロック間の帯域調整が必要です。 pic.twitter.com/rHvTAcBllj

拡大

Takao Setaka @twtko

非最短パス転送を組み入れることは一見非効率に見えますが、ここでは有用なケースを4つ紹介します。1つ目は、単純にブロック間の需要がブロック間に構成済のダイレクトパス容量を超えるケースです。これは③のケースが該当します。この場合はダイレクトパスと1ホップパスを併用して帯域を確保します。 pic.twitter.com/Iv06E40HQO

拡大