ネットワーク市場（私たちは企業について話している）はずっと保守的です。 支配的な企業がいくつかあり、残りはすべてあります。 各ベンダーには、独自のOS、非常に愛されて大事なバグの独自のセット、それらを回避する通常の方法、独自のコマンドラインがあります（ただし、一部は単一のCLIと組み合わされています）。 すべてが私のものです。
少し前に、市場には開発を加速するためのLinuxがないとの意見がありました。
サーバーはOSの有無にかかわらず購入できます。アプリケーションの要件に合わせて構成を選択したり、OSの任意のディストリビューションを選択したり、独自に構築したりできます。 この選択肢は豊富であり、これにより、多くのインターネット企業の成功の基盤となった新しいビジネスモデルを開発することができました。 多くのソフトウェア開発が登場し、サーバーハードウェアを最適化するためにOpen Computeプロジェクトが開始されました
そして、ネットワーク機器で何が起こったのですか？ スイッチは20年近く前にどのように管理されていましたか？
何も変わっていません
何年も経ちますが、変化はありません。 はい、現在はOpenFlowとSDNへの動きが始まっていますが、ネットワークベンダーはオープンなものの名前でクローズドなオプションを提供し続けています。 多くのベンダーはLinuxベースのオペレーティングシステムを開発していますが、Linuxだけを使用している人はいません。
2010年には、BigSwitch NetworksとCumulus Networksの2つのスタートアップが設立され、そのようなソリューションの開発に従事しました。 2012年、Pica8が参加しました。
ネットワークOS
このパスに沿った明らかな問題は、各スイッチが独自のブートローダーを持つことができるため、特定のスイッチおよび複雑なインストール方法のイメージを作成する必要があることです。
複雑なインストール方法
この制限を回避するために、 Open Network Installation Environment（ONIE）が開発されました。 実際、これはプリインストールされたマイクロLinuxであり、最初の起動時に、本格的なネットワークOS（NOS）をインストールするためのソースを探しています。
このアプローチの利点：
- ネットワークOSをインストールするための環境。
- スイッチ管理の自動化。
- Linuxサーバーとしてのスイッチの管理。
スイッチの互換性
2番目に重要な現代のトレンドは、以前にサードパーティの終了としてマークされていたマトリックスを操作するためのSDKの公開です。 Mellanox Open Ethernet 、 Broadcom OF-DPA SDK 、Intelは、ソースでONSとツールを公開すると脅しています。
大衆に広がる
ユビキタスなFacebookがなければ、ONIEはOpen Computeプロジェクトに与えられ、真にオープンなネットワークインフラストラクチャを開発しました。 この原則は、Facebookが従来のベンダーに支払うことを許可していません。 :)
いくつかの企業がすでにスイッチを作成し、 Networking / SpecsAndDesignsで仕様を公開しています
ソフトウェア部分は忘れられていません：
一般的な考え方
OCPの一部として、Open Network Linuxプロジェクトが開始されました。これに基づいて、さまざまなスイッチ用の既製のディストリビューションを構築することが提案されています。 面白いことに、ONLはマトリックスを初期化しないため、パケット処理を直接サポートしていません。 制御部のみ：
ただし、SDKを公開すると、ディストリビューションを自分で構築できます。 必要なパッケージを追加するだけです。
その結果、スイッチからのマトリックスドライバーを使用してサーバーを作成する必要があります。
未来のスイッチ
コントロールプレーンの選択
最新のスイッチの大部分はPowerPCプロセッサで動作し、一部はx86で動作し、MIPSやARMが好きな人もいます。 一部の開発では、プロセッサ、NOSディストリビューション、および利用可能なアプリケーションから選択できるように、プロセッサを別のカードに配置することが既に提案されています。
未来
Facebookはじっとしているわけではなく、OCP Stage IIと呼ばれるモジュラースイッチの概念をすでに提案しています。
コントロールプレーンは、グループハグファミリのマイクロサーバー（Intel、AMD、ARMから選択）に基づいて作成されており、スイッチ管理を単一のFBシステムに統合できます。 OSを直接管理することに加えて、サーバーと同じ方法でスイッチのハードウェアステータスを監視することが可能になりました。 温度、電圧、ファンの状態-すべてが通常の方法で表示されます。 一般に、一部のユーザーは指を指摘しませんが、複雑なスイッチとサーバー管理システムを同時に発明しますが、他のユーザーはスイッチをサーバーレベルに簡素化します。
FBOSSと呼ばれるソフトウェア部分は、サーバーと統合されています。 マトリックスの管理は抽象化のレベルを通過し、ネットワークは別のサービスとして管理できます。 すべての管理者が突然ネットワーク管理者になりました:)
この例はメーカーによって取り上げられる可能性が高く、将来的にはより多くのモジュール設計が見られるでしょう。
私たちの参加
我慢しないことに決め、ONIE環境がプリインストールされたベアメタルスイッチの形で利用できる多くのモデルを作成しました。
リストには以下が含まれます。
Eos 220-48x 1G Base-T、4x 10G SFP +、デュアル電源。 サポートされているCumulus Linux、Open Network Linux、BigSwitch Switch Light、Pica8
Eos 400-48x 10G SFP +、4x 40G QSFP +、デュアル電源。 Cumulus Linux、Open Network Linux、BigSwitch Switch Light、Pica8がサポートされています。
Eos 420-48個の10G SFP +、6個の40G QSFP +、デュアル電源。 Cumulus Linux、Open Network Linux、BigSwitch Switch Lightがサポートされています。
Eos 520-32x 40G QSFP +、デュアル電源。 Cumulus Linuxでサポートされています。
そして、それはEos 410iスイッチをカウントしていません-48x 10G SFP +、4x 40G QSFP +、デュアル電源。 Intel ONSのみがサポートされていますが、非常に柔軟なマトリックスです。 すぐにソースとツールの入手可能性を発表できることを願っています。
