Sdn

[SDNコントローラー分析1] ONOSアーキテクチャの概要



Onos Architecture Overview



ONOSの設計目標

ONOSは、OSGIテクノロジーを使用してサブプロジェクトを管理するSDNコントローラーオープンソースプロジェクトです。初期設計では、いくつかの目標が明確でした。

  • コードのモジュール性：新しい独立したユニットとしての新しい機能の導入をサポートします
  • 機能は構成可能です：起動時または実行時に関係なく、動的なロードおよびアンロード機能をサポートします
  • プロトコルに依存しない：アプリケーションを特定のプロトコルライブラリや実装にバインドする必要はありません

モジュール式の実現：ONOSプロジェクトはサブプロジェクトのグループで構成され、各プロジェクトには独自のソースコードツリーがあり、独立して構築できます。このため、ONOSのソースコードは、MavenのカスケードされたPOMファイル編成の使用を容易にするために階層的に編成されています。各サブプロジェクトには独自のpom.xmlファイルとディレクトリがあり、sub-pom.xmlファイルは親Pomファイルの共有依存関係と構成を継承するため、無関係のサブプロジェクトから独立してビルドできます。ルートディレクトリには、完全なプロジェクトとそのすべてのモジュールを構築するために使用される最上位のPOMファイルが含まれています。



機能を構成できます。ONOSはOSGIフレームワークとしてKarafを使用します。 Karafは、実行時の動的モジュール読み込みと起動時の依存関係の解決に加えて、次の機能もサポートしています。

  • 安全なAPIインターフェースを開発するための標準JAX-RSAPIの使用をサポートする
  • 一元化されたカスタム設定のバンドルのセットとして機能を定義することをサポート
  • サードパーティの依存関係を含む、コードパッケージの厳密なセマンティックバージョン宣言があります
  • ローカルおよびリモートのSSHコンソールログインをサポートする、拡張が容易なコマンドラインフレームワークがあります。
  • さまざまなログレベルのサポートレコード

プロトコルとは関係なく、ONOSは次の部分に分かれています。



  • ネットワークと相互作用するプロトコル認識モジュール
  • プロトコルに依存しないシステムコア、ネットワークステータス情報の追跡と提供
  • Coreが提供するシステム情報に基づいて消費および動作するアプリケーション

上記の各レイヤーは階層化アーキテクチャであり、ネットワーク指向のモジュールはサウスバウンド（プロバイダー）APIを介してコアと対話し、コアはノースバウンド（コンシューマー）APIを介してアプリケーションと対話します。サウスバウンドAPIは、ネットワークステータス情報をコアに渡すためのプロトコルに依存しない手段を定義し、コアはネットワーク指向のモジュールを介してネットワークデバイスと対話します。ノースバウンドAPIは、アプリケーションにネットワークコンポーネントと属性を記述する抽象化を提供し、ポリシーに基づいて必要なアクションを定義できるようにします。

画像

システムコンポーネント

サービスは機能ユニットであり、垂直スライスを作成するためのソフトウェアスタックとして異なるレイヤーにある複数のコンポーネントで構成されます。サービスを構成するコンポーネントのコレクションをサブシステムと呼びます。



ONOSは、さまざまなサブシステムを定義しています。

  • 機器サブシステム-インフラストラクチャ機器の在庫を管理します。
  • リンクサブシステム-インフラストラクチャリンクのインベントリを管理します。
  • ホストサブシステム-端末ホストのインベントリとネットワーク上のその場所を管理します。
  • トポロジサブシステム-ネットワークダイアグラムビューの時系列のスナップショットを管理します。
  • パスサブシステムは、最新のトポロジマップスナップショットを使用して、インフラストラクチャ機器またはエンドステーションのホスト間のパスを計算/検出します。
  • FlowRuleサブシステム-基本機器にインストールされている一致/アクションフローエントリと統計フローを管理します。
  • パケットサブシステム-アプリケーションがネットワークデバイスから受信したデータパケットを監視し、1つ以上のネットワークデバイスを介してデータパケットをネットワークに送信できるようにします。

次の図は、現在ONOSに含まれているさまざまなサブシステムを示しています。
画像

サブシステム構造

各サブシステムのコンポーネントが存在する3つの主要なレベルは、Javaによって実装された1つ以上のインターフェースによって識別できます。
次の図は、サブシステムコンポーネント間の関係の概要を示しています。図の上部と下部の点線は、それぞれ北と南のAPIによって作成されたレイヤー間の境界を示しています。
画像

プロバイダー
スタックの最下層はプロバイダーコンポーネントです。プロバイダーインターフェイスは、プロトコル固有のライブラリを介して基盤となるデバイスと通信し、プロバイダーサービスインターフェイスを介してコアと対話します。
プロトコル認識プロバイダーは、さまざまな制御および構成プロトコルを使用してネットワーク環境と対話し、サービス固有の認識データをコアに提供する責任があります。プロバイダーは、他のサブシステムからデータを収集し、それらをサービス固有のデータに変換することもできます。
プロバイダーは、Coreから制御コマンドアプリケーションを受け入れ、適切なネットワークプロトコル固有の方法でそれらをネットワークに適用する必要がある場合もあります。これらは、プロバイダーインターフェイスを介してプロバイダーコンポーネントに送信されます。

プロバイダーID
プロバイダーは特定のプロバイダーIDに関連しています。 provideridの主な目的は、プロバイダーファミリーの外部IDを提供することです。これにより、プロバイダーがロード/アンロードされた後でも、デバイスやその他のエンティティモデルがプロバイダーに関連付けられたままになります。
ProvideridはURIスキーム名を持っており、プロバイダー自体にアクセスしなくても、別のプロバイダーの自宅のデバイスとの緩いペアリングを可能にします。

複数のプロバイダー
サブシステムは、複数のプロバイダーに関連付けることができます。この場合、プロバイダーはプライマリまたは子会社として指定されます。メインプロバイダーはサービスに関連付けられたエンティティを所有し、補助プロバイダーはその情報をオーバーレイとして使用して情報を提供します。上書きによって基になる情報と競合する場合、このメソッドはメインプロバイダーを優先します。デバイスサブシステムは、複数のプロバイダーをサポートするサービスの1つです。

マネージャー
Managerは、コアに存在するコンポーネントです。プロバイダーから情報を受け取り、それをアプリケーションやその他のサービスに提供します。それはいくつかのインターフェースを公開します：

  • ノースバウンドサービスインターフェイスアプリケーションまたはその他のコアコンポーネントは、このインターフェイスを介してネットワークステータスの特定の側面について学習できます。
  • AdminServiceインターフェースは、管理者コマンドを使用してネットワークまたはシステムの状態に適用されます。
  • サウスバウンドProviderRegistryインターフェースプロバイダーは、このインターフェースを介してマネージャーに登録し、それを介してマネージャーと対話できます。
  • サウスバウンドProviderServiceインターフェイスは登録済みプロバイダーに提供されます

Managerサービスインターフェイスのコンシューマーは、サービス情報を同期的に照会することも、イベントリスナーとして非同期的に機能することもできます（たとえば、listenerserviceインターフェイスを使用して、監視対象のイベントを登録し、関連するEventListenerインターフェイスを実装します）。

お店
ストアの特定の実装は、コアのマネージャーと強い相関関係があります。ストアは、インデックスを作成し、永続化し、マネージャーが受信した情報と同期する必要があります。これには、分散されたONOSの複数のインスタンス間の一貫性が含まれます。性別と堅牢性の保証、

応用
アプリケーションは、AdminServiceおよびServiceインターフェースを介してManagerによって集約された情報を消費および操作します。このアプリケーションには、Webブラウザでのネットワークトポロジの表示やネットワークトラフィックのパスの設定など、さまざまな機能があります。

アプリケーションID
各アプリケーションには一意のアプリケーションIDがあり、アプリケーション関連のコンテキスト（IntentやFlowRuleなどのタスクと目標）を追跡するために使用されます。有効なIDを取得するには、アプリケーションを登録する必要があります。CoreServiceに移動し、逆ドメイン名解決のために名前を登録します（例：org.onlab.onos.fwd）。

イベントと説明
ONOSで配布される2つの基本的な情報単位は、イベントと説明です。サービスと同様に、イベントと説明は特定のネットワーク要素と概念に関連付けられています。作成後は両方とも変更されません。

説明
説明は、サウスバウンドAPIの要素に関する情報を渡すために使用されます。たとえば、HostDescriptionには、ホストのMACアドレスとIPアドレス、ネットワーク内の場所情報（VLAN IDとデバイス/ポート接続ポイント）が含まれます。説明は通常、1つ以上のモデルオブジェクトで構成されます。

イベント
Managerは、Eventを使用して、ネットワークの変更についてリスナーに通知し、Storeを介して分散設定で関連するピアに通知します。イベントは、イベントタイプとオブジェクトモデルで構成されるサブジェクトで構成されます。たとえば、デバイスイベントは、デバイス（テーマ）が検出された（device_added）、失われた（device_removed）、または何らかの方法で変更された（device_updated）ことをdevicelistenersに通知できます。

イベントディスパッチ
イベントは、マネージャーの入力に基づいてストアによって生成されます。生成されると、イベントはstoredelegateインターフェースを介して関心のあるオーディエンスに配信され、イベント配信サービスが最終的に呼び出されます。基本的に、Store Delegateはイベントをストアから取り出し、イベント配信サービスは、イベントが関心のあるリスナーによってのみ受信されるようにします。それらが相互作用する方法により、これら2つのコンポーネントはManagerに存在し、そこでManagerは特定の実装用のstoredelegateを提供します。

イベントリスナー
イベントリスナーは、EventListenerインターフェイスを実装するコンポーネントです。 EventListenerのサブインターフェイスは、監視するイベントのタイプに応じてさらに分類されます。典型的なイベントリスナー実装モードは、イベントリスナーをマネージャーまたはアプリケーションの内部クラスとして使用し、そこから対応するサービスが受信したイベントから呼び出されます。これにより、イベント処理ロジックがサブシステムの外部に公開されるのを制限します。

画像

ネットワーク表現
モデルオブジェクトは、さまざまなネットワーク要素と属性を表すONOSプロトコルに依存しない方法です。イベントは、これらの表現を本体として持っています。これらの表現は、コアが説明から見つけた情報から構築されます。