これを読んでいる人は、オープンネットワークの革命は本物だ！ということに同意していることでしょう。  私は最近、OCP Global Summit と Linux Foundation ONE Summit に出席しましたが、そこでは確かに電光が輝いていました。  コミュニティの規模は劇的に拡大し、日々新しいユーザーやベンダーを惹きつけています。

Hedgehog は、モダンなクラウドネイティブワークロードに対応したフルオープンソースの NOS (SONiC) を使用したネットワークファブリックをが構築することができます。 NOS (SONiCSONiCのエコシステムで起こっていることについて話すと、最も多い反応は "Cumulus Networksがやろうとしたことではありませんか？"というものです。

"オープン・ネットワーキング "は新しいものではありません。  ネットワーク業界のこの分野に詳しい人なら、Cumulus Networks という会社の躍進をご存じのことでしょう。

ロケットタートルの登場

Cumulusは、スターダムにのし上がったものの、業界が必要としていた "真の革命 "を起こすことはできませんでした。

Cumulus は、全てのサーバーインフラはすでに専用のオペレーティングシステム から Linux に移行しているという考えに基づいて、会社全体の戦略を行っていました。  サーバー管理者は何千ものデバイスを管理することが可能なツール (Ansible/Chef/Puppet) を持っていましたが、ネットワークオペレータは不便な CLI ベースの石器時代のツールセットに縛られており、その結果、より多くのデバイスを管理するための専門知識を高めることができませんでした。  そこで Cumulus は、ホワイトボックスハードウェアで動作する汎用ディストリビューション (Debian) をベースにした、Linux ベースのネットワークオペレーティングシステム (NOS) の作成に着手しました。  

ホワイトボックススイッチも当時はやや新しかった。 世界最大の顧客（主にハイパースケーラー）は、Broadcom、Marvell、MellanoxのASICを搭載したODM（Original Device Manufacturers）から汎用スイッチを購入していました。 当時、シスコは自社製品の多くにブロードコムのTrident 2を使用していたため、Cumulusは、ASICを適切にプログラムするソフトウェアを入手できれば、同じレベルのスループットを約束することができた。 エーシック のハードウエアです。

とにかく、そういう計画だったんです。  このコンセプトには多くの反響がありました。当時、ネットワーク管理者は、高価なライセンス、顧客が1/10の価格で購入できるものと同じである非常識な価格の専用SFPオプティカル、ボックスの「チャーン」（新しいプラットフォームがリリースされた後、あるプラットフォームを廃止すること）などで不満だらけでした。  ある有名なアナリストは、Cumulus とホワイトボックススイッチが大手ベンダーに対して存亡の危機であるとまで言っています。 この予測は、顧客がLinuxのbashプロンプトのためなら喜んでCLIを手放すということに基づいています。

さて、Cumulusは軌道に乗り、確かに多くの顧客を獲得しましたが、それぞれの顧客を獲得するのはとてつもなく大変なことだったのです。  2000年から2010年にかけて、多くのベンダーが面白い販売戦略をとっていました。  その一つが"Turn It On"と名付けられたマーケティング・販売キャンペーンです。基本的にSEは、顧客に可能な限りすべての機能をオンにさせるよう指示されました。そうすれば、将来の販売においてロックインを生み出すことができるからです。  あるデバイスのコンフィグを別のベンダーのシンタックスに簡単に変換することはできません。なぜなら、いくつかの機能は別のベンダーには存在しないものだからです。  これらの機能の中には、確かに素晴らしいものもあれば、単なるお荷物になってしまうものもありました。  顧客にとっては、自分たちのコンフィグがどんどん自分たちだけのものになっていくことは、あまり重要ではありませんでした。  この取り組みが功を奏し、当時の多くの顧客はRFP/RFQに要件として独占的な機能を挙げていたのです。

顧客を獲得するために、Cumulus社はCisco社やArista社と機能面での競争を繰り広げました。  基本的に彼らは、市場が求める機能をすべて追加しようとしたのです。  これらの機能の中には、間違いなく必要とされるものもあれば、そうでないものもありました。  しかし、Cumulus 社の課題は、Cisco のスイッチにできることを、Linux のデバイスにさせなければならないということでした。  Linux はサーバーのオペレーティングシステムとして設計されているので、ネットワークのベストプラクティスにはあまり気を配っていませんでした。  だから、ネットワークに必要な様々な機能がなかったり、正常に機能しなかったりしました。  それでは、大きな問題と Cumulus がどのようにこれらの問題を解決したかを見てみましょう。

オープン・ネットワーキングへのCumulusの貢献

スイッチASICアクセラレーション - switchd & SAI

Linuxはもともとイーサネットスイッチを管理するために設計されたものではありません。 TCAMやフローテーブルをプログラミングして管理するためのデーモンやサービスもなかった。 サーバー管理者は、変更を加えた数秒後に新しいフローがNICにプログラムされることに抵抗はありませんでした。 しかし、データセンター・ネットワーキングではどうでしょう。 数秒は永遠です。 そこでCumulusはswitchdという新しいデーモンを作り、ハードウェアとASICの処理を担当させました。 これは、当時の顧客にとってまったく新しいコンセプトでした。 残念ながら、Cumulusは、この特定のコードのビットをプロプライエタリでクローズドソースに保つという戦略的決定を下しました。 スイッチング・ハードウェア上でCumulusが動作するためにはswitchdが必要であるため、この結果、「オープン・ネットワーキング」と「オープン・ソース」という奇妙なマーケティング上の区別が生まれた。 ほらね、 Cumulus Linux は「オープンネットワーキング」、つまり、この新しい分解されたハードウェア/ソフトウェアモデルを消費させるものでしたが、完全なオープンソースではありませんでした。 Switchdは、ユーザーがライセンスキーを入力しないと正しく機能しませんでした。 あった サイ が存在すれば、Cumulus社にはオープンソース化する選択肢がもっとあったはずですが、やはりタイミングが重要なのでしょう。

しかし、これは本当に素晴らしいアイデアで、現在私たちがSONiCで使っている、複数のハードウェアプラットフォームをサポートするSAI（Switch Abstraction Interface）の前身となるものでした。

レイヤ3ルーティング - QuaggaがFRRになる

Linuxは常に必要不可欠なルーティングスタックを欠いていました。  当時は静的ルート、独占的で高価なルーターソフトウェア、あるいはQuaggaと呼ばれる奇妙なソフトウェアパッケージなど、選択肢も限られていました。  最初に誰かが "Quagga "と言ったのを聞いたとき、誰もが “一体これはなんなんだよ！"のような怒りの瞬間があったことを覚えています。  なんとも奇妙な名前でしょう？  Quaggaは、19世紀に狩猟によって絶滅してしまったシマウマの一種です。  それが伏線になっているのかもしれない。 とにかく、Quagga（哀愁を帯びた馬のほうではなく、ネットワーク関連のほう）は BGP やOSPFを含むルーティングプロトコルデーモンのスイート製品です。  Cumulusの前、Quaggaはほとんど実験的なものでした。  それは多くのバグを持ち、まったくスケールしませんでした。  BGP愛好家のためのドアノブがたくさん欠落していました。  CumulusはQuaggaの改良を始め、そのすべての変更を、奇妙なバージョン管理方法を用いる一人のメンテナンス要員に託しました。  これには膨大なエンジニアリングが必要でした。  FIBとTCAMのルートスケーリング制限を実際に決定することは非常に難しいです。そして、もしあなたがデバイスのプロダクトマネージャーで一つのデバイスだけでなく、複数のASIC、CPU、SerDes、ポートブロック、光学系にまたがって管理するとしたらどうでしょうか？ 

そんなのおかしいでしょ？  しかし実際、Cumulusはこの複雑さを克服し、自動化する決意をもって前進しました。  時が経つにつれ、Quaggaのパフォーマンスはかなり信頼できるものになり、現在ではグローバルなルーティングテーブル全体の取り込みをサポートするためにスケールアップすることが明らかになっています。  私たちは、FRRがインターネットテーブルを扱えることを知っていますし、それは本当に複雑で厄介なものです。  しかし、オリジナルのメンテナンス担当者が変更を統合するスピードに問題があったため、Cumulus社は最終的にQuaggaをフォークしてFree Range Routing (FRR) という新しいプロジェクトにすることを決定しました。  このプロジェクトは現在、最も広く展開され使用されているオープンソースルーティングスイートで、AzureやAWSのような大規模なクラウドで動作しています。

クールなアイディアが正当に評価される

Cumulusがネットワークの民主化を示した例の中で、私が最も気に入っているものの1つは、 BGP Unnumbered です。  そうです、これは「大手ベンダー」が作ったものではないことをご存知ですか？  Cumulus は BGP Unnumbered の実装を設計し、磨き上げ、推進し、そして誰もがその傑作をコピーできるようにしたのです。  コピーはお世辞の最も良い形でしょう？  他のベンダーは、一夜にしてこのシンプルな手法を自社のNOSに実装しました。

基本的に、Cumulus はデータセンター向けに最適化されたLinuxネットワークを構築していました。

Linux ネットワークインターフェース管理 - ifupdown がアップグレード

前述のように、linuxはスイッチOSとして設計されていません。linuxのネイティブネットワークコマンドで1つのポートに変更を加えようとすると、それは痛いほど明らかでした。  基本的に、ポートの設定を変更したり、ポートをバウンスしたりしようとすると、本質的にサーバ上のすべてのポートを一度にバウンスすることになります。  しかし、48ポートのスイッチでインターフェイスをバウンスさせ、全てのポートがダウンすることを想像してみてください。  これはLinuxにかなり根付いた技術設計で、これを変更するには膨大な労力が必要でした。  Cumulus は最終的に ifupdown2 をリリースし、それをアップストリームして誰もが彼らの成果物を得られるようにし、今ではポート管理の新しい機能をオープンネットワークのコミュニティ全体が享受できるようになったのです。

自動化・プログラマビリティ - CLIからAnsibleへ

Cumulus は発売当初、CLI や API を提供しませんでした。  CLI は無用の長物で、データセンターのファブリックスイッチの管理に CLI を使うべきではないという考えを持っていました。  そこで Cumulus は率先してネットワークを自動化するための最初の本格的な Ansible プレイブックを作成しました。そして、Cisco は Nexus 9k のための Ansible ツールを作成するサードパーティの開発者を獲得し素早く "me too" を実行していました。  実際、DevOps ファーストのアプローチは非常に先進的で、業界をよりプログラマブルなモデルへと加速させることになりました。

これは、収入の少ないスタートアップ企業にとっては、大幅に開発費と技術的負債を解決することになります。  この結末をすでにご存知の方もいらっしゃると思いますが...。

2020年、NvidiaはCumulus Networksを買収しました。これはMellanoxを買収した直後でした。  当時、CumulusはBroadcomとMellanoxという2大ASICベンダーをサポートしていました。  買収が発表された直後、BroadcomはCumulusのBroadcom SDKへのアクセスを取り消し、CumulusによるBroadcom ASICのサポートは事実上終了してしまったのです。  非公式な推定値ですが、Cumulusの顧客の90％がBroadcom ASIC (Dell、Edgecoreなどとして販売されたもの) を使用していたそうです。  Cumulusのマルチベンダー機能は終了し、現在CumulusはNvidiaのネットワークポートフォリオの一部となっており、AI/MLワークロードとストレージネットワーキング向けに個別の最適化が施されています。

Let's Hear It For Cumulus!

私は、Cumulus が全精力を傾けて業界の壁を壊し、その過程で自分たちの首が折れてしまったのだとお伝えしたい。  つまり、Cumulus はオープンソースとオープンネットワークのコミュニティのために信じられないほどの前進をしましたが、そうすることであまりにも多くのリソース（開発コストと時間）を投入したため、単なる linux NOS を超えて効果的に差別化することができなくなったということなのです。  Cumulus は私たちが現在取り組んでいる革命を最初に起こしましたが、市場は分散型モデルを採用するにはあまりにも遅れていました。  彼らは、誰もが望んでいた業界の破壊者とまではいきませんでしたが、多くのレガシー・ビジネスモデルを破壊しました。そして、現在多くのベンダーがまだまだこの新しくなった現状への対応に苦慮しています。

そこで早速ですが、コミュニティを代表して、Cumulus社と、ネットワーク技術の発展に貢献したすべての従業員に、心からの感謝を捧げたいと思います。

今日では何が変わったのでしょうか？

Cumulus は、自社の技術を市場の主要な変化へとうまく結びつけることができませんでした。CLI の代わりに bashを使い、Cisco T2 の代わりに whitebox T2 を使うというだけでは、企業が NOC と監視システムをすべて更新し、CCIE保持者 をすべて linux の専門家に置き換える動機付けとしては十分ではありませんでした。移行を生み出すには十分ではなかったのです。それよりも、それに付随する大きな移行を模索するべきだったのです。

SONiCには圧倒的な勢いがあります。  モダンなアプリケーションのように自動化できるように設計されています。  Hedgehog は、Kubernetes プラットフォームの優れた点をすべて SONiC ネットワーキングに導入することに取り組んでいます。  これは現在、データセンターのネットワークファブリックとエッジアプリケーションホスティングプラットフォームを含みますが、いつかキャンパス、WAN、その他のデプロイメントモデルに拡張する予定です。  これほど大規模な貢献コミュニティを持つオープンソース NOS は他になく、主要ベンダーがすべて SONiC をサポートしているため、近い将来、SONiC が新規ビルドの大半の標準 NOS となることが予想されます。  SONiCの採用はまさに「今」なのです。

それではまた次回まで…