JDM アーキテクチャの概要
サービスのJunos OS
これまで、多くのネットワーク機器のベンダーは、ソフトウェアを専用のハードウェアに縛り付け、バンドルとパッケージ化されたソフトウェアとハードウェアの組み合わせを顧客に販売しています。しかし、Junos OSアーキテクチャが異なったJunos OSにより、ジュニパーネットワークデバイスは、クラウド指向で、オープンで、より柔軟な実装シナリオに依存するネットワークに対応しています。
Junos OS アーキテクチャの切り離しの基本原理は、緊密に縛られたJunos OS ソフトウェアと独自のハードウェアの組み合わせ(切り離し)を仮想化されたコンポーネントに組み込み、ジュニパーネットワークス ハードウェアだけでなく、ホワイト ボックスやベアメタル サーバー上でも実行できる可能性があるという問題です。この新しいアーキテクチャでは、ジュニパー Manager(JDM)は、ソフトウェア コンポーネントを管理する仮想化されたルート コンテナです。
JDM は、Junos OS Junos OS アーキテクチャの中で唯一のルート コンテナです(他の業界モデルでは複数のルート コンテナを許可できますが、この場合、この 1 つのルート コンテナは 1 つではありません)。この方法のJunos OSは、単一 ルート モデル です。JDM の主な機能の 1 つは、プラットフォーム上の変更やアクティビティが基盤となるホスト OS(通常は Linux)に影響を与えるのを防ぐことです。JDM は、ルート エンティティとして、このタスクに適しています。JDM のもう 1 つの主な機能は、デバイスのハードウェアを従来の Junos OS ベースの物理システムと可能な限り同じにすることです。これには何らかの根本機能も必要です。
図 1 は 、JDM がアーキテクチャ全体で占める重要な位置を示しています。
VNF は、完全に仮想化されたネットワーク環境をサポートするために必要なすべてのコンポーネントを統合した製品です。VNF は、その焦点としてネットワークを最適化します。
JDM によって以下が可能に:
ライフ サイクル中のゲスト仮想ネットワーク機能(VFS)の管理。
サードパーティー製モジュールのインストール。
VNF サービス チェーンの形成。
ゲスト VNF イメージの管理(バイナリ ファイル)。
システム インベントリとリソース使用率の制御。
基本的なアーキテクチャには、通常の Linux プラットフォーム ハードウェア ポートパケット転送エンジン実装されている点に注意してください。これにより、汎用プラットフォームのベアジュニパーネットワークス データ プレーンハードウェアとの統合が向上します。
このアーキテクチャのJunos OSにより、JDM はファイアウォールや仮想ファイアウォール(ネットワーク アドレス変換)機能などのNATできます。その他の VFS やコンテナを JDM と統合すると、ネイティブ Linux アプリケーションジュニパーネットワークスサードパーティ製品を統合して使用することができます。この図 2 は、このアーキテクチャのJunos OS構造 を示しています。
さまざまなプラットフォームで基本的なネットワーク アーキテクチャをJunos OS方法は複数あります。詳細は大きく異なります。このトピックでは、アーキテクチャ全体について説明します。
固定仮想化なソフトウェア プロセスは、プロセス間通信の領域でいくつかの課題を生み出しています。たとえば、複数のデバイスを持つ VNF NAT同じデバイス上でコンテナとして実行されているファイアウォールとどう機能しますか?結局のところ、デバイス全体に1個または2個の外部イーサネット ポートしか存在しませんが、プロセスは依然としてデバイスの内部です。その 1 つのメリットは、これらの仮想化プロセス間のインターフェイスは、SXE ポートなどの、多くの場合、 自身で仮想化されるという事実です。つまり、プロセス間、プロセスとホストOSとの間、そしてホストOSと別のプロセスの間で、プロセス間で、MACレイヤー ブリッジのタイプを直接設定できます。これにより、トラフィックがデバイスに入り込み、デバイスから出た場合のサービス チェインがサポートされます。
JDM は、ユーザーに使い慣れたJunos OS CLIを提供し、基礎となる Linux カーネルとのすべてのやり取りを処理して、ユーザーが使用しているデバイスの「外観とジュニパーネットワークス維持します。
この方法を使ってこの方法を分Junos OS例を示します。
システム全体をサーバー・プラットフォームの管理と同様に管理できます。
顧客は、仮想マシン(VM)またはコンテナに、Chef、Wiireshark、Quagga などのサードパーティー製のアプリケーション、ツール、サービスをインストールできます。
これらのアプリケーションやツールは、一般的な Linux リポジトリを使用してアップグレードできるうえ、個別のJunos OSです。
モジュール内に障害が含まれているため、モジュール性によって信頼性が向上します。
制御プレーンとデータ プレーンは、API を使用して直接プログラミングできます。
物理コンポーネントと仮想コンポーネントについて
NFV(ネットワーク機能Junos OS仮想化)環境の場合、デバイス コンポーネントは物理コンポーネントか仮想コンポーネントになります。物理と仮想の違いは、インターフェイス(ポート)、パケットまたはフレームがデバイスを通過するパス、CPU コアやディスク容量などのその他の側面に適用できます。
この仕様のJunos OSには、アーキテクチャ モデルが含まれています。家のアーキテクチャ モデルには、設備、作り付け場所、食堂などへの道案内や、さまざまな種類の住宅の表現が可能です。大別した家から分別した大家までですこれらの住宅はすべて非常に異なって見えるが、それでも基本的なアーキテクチャ モデルに従い、多くの特性を共有している。
同様に、Junos OS アーキテクチャ モデルを切り離した場合、このモデルは単純な CPE(顧客構内機器)から大規模なデータ センターに設置された複雑なスイッチング機器まで、さまざまな種類のプラットフォームに対応しますが、プラットフォームが共有する基本的な特性があります。
これらのプラットフォームは、どのような特性を共有していますか?すべてのプラットフォームのJunos OSは3つのレイヤーで構築されています。これらのレイヤーと、考えられるコンテンツを図 3 に示します。
の構造を変Junos OS
最も下のレイヤーはハードウェア レイヤーです。プラットフォームハードウェアには、メモリ(RAM)とディスク容量(SSD)の他に、管理に外部電源ポートを備NIC CPU を搭載しています。場合によっては、制御および データ プレーン に 1 つの NIC ポートが使用されますが、そのポートはユーザー トラフィック ストリームの パケット転送エンジン との通信にも使用できます。
プラットフォーム ソフトウェア レイヤーは、ハードウェア レイヤーの上に表示されます。プラットフォームに依存する機能はすべてここで実行されます。これらの機能には、さまざまな仮想コンポーネントのソフトウェア スイッチング機能を使用して、それらの間でトラフィックをブリッジできます。プラットフォームは Linux またはカーネルベースの仮想マシン(KVM)で実行され、一部のモデルでは、電話ホーム エージェントがベンダーまたはサービス プロバイダ のデバイスに問い合わせ、自動設定タスクを実行します。電話ホーム エージェントは、小規模な CPE プラットフォームに特に好まれます。
プラットフォーム ソフトウェア レイヤーよりも上は顧客のソフトウェア レイヤーで、さまざまなプラットフォームに依存しない機能を実行します。コンポーネントの一部は、ジュニパーネットワークス SRX デバイス(vSRX)や Junos コントロール プレーン(仮想マシン)など、仮想JCP。このJCP JDM と動作し、デバイスが専用の ジュニパーネットワークス プラットフォームに似ているだけでなく、柔軟性が高いプラットフォームにできます。このような柔軟性の多くが、仮想ネットワーク機能(VNF)を実装する 1 つ以上の VNF をサポートする能力に帰帰しています。これらの VFS は、ネットワーク アドレス変換(NAT)、特殊なドメイン名システム(DNS)サーバーのルックアップなど、さまざまなタイプのタスクで構成されています。
通常、CPU コアの数は固定され、ディスク容量は有限です。しかし、仮想環境では、リソースの割り当てと使用が複雑になります。インターフェイス、ディスク容量、メモリ、コアなどの仮想リソースは、VNFイメージによって決定された時点で実行されているVNFの間で削除されます。
多くの場合、物理デバイスを共有する仮想マシン(VM)でもコンテナでも、VFS は相互に通信するために必要です。パケットまたはフレームは、物理インターフェイス(ポート)を通じてデバイスに入り、初期 VNF に配信されます。トラフィック フローを何らかの処理の後で、VNF がトラフィックを別の VNF に渡す(そう設定されている場合)、トラフィックが物理デバイスから離れる前に別の VNF にトラフィックが渡されます。これらの VFS は、データ プレーンを通過するサービス チェーンを形成します。
VMまたはコンテナが分離されているVIFは、どのようにトラフィックを1つの仮想マシンまたはコンテナに渡すのでしょうか。サービス チェーンは、トラフィックを物理インターフェイスから 1 つ以上の内部仮想インターフェイスに渡す設定されています。そのため、各 VM またはコンテナに関連付けられた仮想 NIC が、デバイス内の 仮想スイッチ またはブリッジ機能によって接続されます。物理インターフェイスと仮想インターフェイス間の通信を可能にするこの一般的な関係を図 4 に示します。
さまざまなプラットフォームの種類があるこの一般的なモデルでは、データは物理 NIC のポートを通って入り、宛先 MAC アドレス に基づいて、仮想スイッチ 機能を介して仮想マシン1から仮想 NIC 1 にブリッジされます。トラフィックは、物理ポートに渡され、デバイスから出るまで、設定された別の仮想インターフェイスを介して仮想マシン2以上のVFSにブリッジすることもできます。
設定の目的で、これらのインターフェイスは ge-0/0/0 や fxp0 などの使い慣れた名称や、sxe0 や hsxe0 などの新しい指定で使用されている場合があります。現実のポート があるかもしれませんが、内部ポート(sxe0 など)、デバイスを動作させるのに必要な完全な仮想構成要素(hsxe0 など)も用意されています。
VM のJunos OSの違い
クラウド コンピューティングでは、エンドユーザーのサーバー機能と、大規模なデータ センター全体や複数のデータ センター間に散らばったエンドポイントを接続するために必要なネットワーク機能の両方について、仮想環境でアプリケーションを実行できます。アプリケーションとネットワーク機能は、VFS(仮想化ネットワーク機能)によって実装できます。これら 2 種類のパッケージにはどのような違いがありますか。また、誰かが 1 種類または他のタイプを使用する理由について説明します。
VFS とコンテナの両方で、数十または数百の VFS でハードウェアを多重化し、1 つの物理サーバーを共有できます。これにより、新しいサービスの迅速な導入だけでなく、(拡張が可能な場合)重い使用時や物理的な保守(移行が可能な場合)におけるワークロードの拡張と移行が可能になります。
一般的クラウド コンピューティング環境では、最新のネットワークのビッグ データを特徴付ける大規模なサーバー ファームでの負荷の高い作業に VFS を採用するのが一般的です。サーバー 仮想化、さまざまな開発環境、ハードウェア プラットフォーム、オペレーティング システム用に作成されたアプリケーションを、適切なソフトウェア スイートを実行する汎用ハードウェア上で実行できます。
VFS は、物理環境を管理し、任意の時点で実行されている VFS 間にリソースを割り当てるには、ハイパーバイザーに依存しています。一般的なハイパーバイザーには、Xen、KVM、VMWare ESXiが含まれますが、他にも多くのハイパーバイザーがあります。VFS はハイパーバイザー上のユーザー スペースで実行され、VM アプリケーションのオペレーティング システムの完全実装が可能です。たとえば、C++ 言語で記述され、Microsoft Windows オペレーティング システムで準拠して実行されているアプリケーションは、ハイパーバイザーを使用して Linux オペレーティング システム上で実行できます。この場合、Windowsはゲストオペレーティングシステムです。
ハイパーバイザーは、VFSのハードウェアをエミュレートしてゲストオペレーティングシステムを提供します。メモリのディスク容量などのその他のリソースの中でも、ハイパーバイザーは、異なる仮想マシンのエンドポイントが異なるサーバーやホストに存在する場合(一般的な状況)のネットワーク・インタフェース・カード(NIC)の仮想化ビューを提供します。ハイパーバイザーは物理 NIC を管理し、仮想化されたインターフェイスのみを VFS に公開します。
ハイパーバイザーは 仮想スイッチ 環境を実行します。これにより、VLAN フレーム レイヤーの VFS で同じボックス内または(仮想)ネットワークを使用してパケットを交換できます。
VFS の最大の利点は、ほとんどのアプリケーションをハイパーバイザー環境に簡単に移植して、修正せずに適切に実行できるにあるというのです。
最大の欠点は、多くの場合、ゲスト オペレーティング システムに対するリソースの多いオーバーヘッドに、VNF 全体がドメイン名システム(DNS)などのシンプルなサービスを提供する場合でも、オペレーティング システムの完全なバージョンを含める必要がある点です。
コンテナは VFS とは異なり、仮想環境で独立したタスクとして実行専用に構築されています。コンテナは、VFS のようにオペレーティング システム全体をバンドルする必要があります。コンテナのコード化とバンドルはさまざまな方法で実行できますが、保守と拡張が容易な標準コンテナを構築する方法もあります。標準的なコンテナは、無計画な方法で作成されたコンテナよりもはるかにオープンです。
標準 Linux コンテナは、標準コンテナと呼ばれるソフトウェア配信のユニットを定義します。標準コンテナは、ゲストオペレーティングシステム全体をカプセル化する代わりに、アプリケーションと、アプリケーションが実行するためにプログラムされたタスクの実行に必要な依存関係のみをカプセル化します。この単一のランタイム要素は変更できますが、拡張機能に必要な依存関係を追加できるようコンテナを再構築する必要があります。コンテナ全体のアーキテクチャを図 5 に示します。
コンテナはホストOSカーネル上で実行され、ハイパーバイザーでは実行されません。コンテナ アーキテクチャはコンテナ エンジンを使用して、基盤となるプラットフォームを管理します。VFS を実行したい場合は、コンテナで完全なハイパーバイザー環境とゲスト OS 環境をパッケージ化できます。
標準コンテナには次のものが含まれます。
設定ファイル。
一連の標準運用。
実行環境。
名前の コンテナ は、世界中の商品の輸送に使用される輸送コンテナから借りた名前です。輸送用コンテナは、コンテナを扱う専用に構築された機器によるロード、ラベルの付け、積み重ね、持ち上げ、および装備を解除できる標準的な配送ユニットです。どのような内部でも、コンテナは標準的な方法で処理できます。また、各コンテナには、他のコンテナでは使用できない独自のユーザー スペースがあります。 Docker は、 物理サーバー上でコンテナを実行する人気の高いコンテナ管理システムですが、Drawbridge や Rocket などの選択肢として検討する必要があります。
各コンテナには仮想インターフェイスが割り当てられます。Docker などのコンテナ管理システムには、複数の仮想インターフェイスと物理インターフェイスを接続する仮想イーサネット ブリッジNIC。コンテナの設定と環境変数によって、相互に通信できるコンテナ、外部ネットワークを使用できるコンテナなどが決されます。外部ネットワークは通常、仮想ネットワークでNAT実行しますが、コンテナは多くの場合、同じネットワーク アドレス 空間を使用します。
コンテナの最大の利点は、デバイスに読み込み、実行する速度が VFS よりもはるかに速いという問題です。コンテナは、リソースを細かめに使用し、同じハードウェア上で VFS よりも多くのコンテナを実行できます。コンテナはゲストオペレーティングシステムや起動時間を完全に必要としていないためです。コンテナは数十秒ではなくミリ秒で読み込み、実行できます。しかしコンテナの最大の欠点は、VFS がネイティブの状態で実行されるのに対し、一部の標準実装や一般的な実装に準拠するために、コンテナを記述する必要がある点です。
Virtio および SR-IOV の使用状況
Virtio を使用するか、適切なハードウェアおよび SR-IOV(single-root I/O 仮想化)を使用して、Linux ベースの仮想化デバイスとネットワーク機能仮想化(NFV)モジュール間の通信を可能にします。各方法には、それぞれ異なる特徴があります。
Virtioの使用状況を理解する
物理デバイスを仮想化すると、物理NICインターフェイスと外部物理スイッチ、仮想NICインターフェイスと内部仮想スイッチの両方が共存します。そのため、個々のメモリとディスク容量、CPU サイクルを持つデバイス内で分離された VNFS が互いに通信を試みる場合、使用している複数のポート、MAC アドレス、IP アドレスは問題になります。virtio ライブラリを使用すると、分離された仮想機能間のトラフィック フローがよりシンプルかつ容易になります。
Virtio は、標準的な Linux libvirt ライブラリの一部であり、有用な 仮想化 機能を提供し、通常は Linux のほとんどのバージョンに含まれています。Virtio は、VNF 間の通信に対するソフトウェア専用のアプローチです。Virtio は、個々の仮想プロセスを接続する方法を提供します。Virtio はバンドルされた性質を持ち、Linux を実行するどのデバイスでも virtio を使用できます。
Virtio により、VFS とコンテナはシンプルな内部ブリッジを使用してトラフィックの送受信を可能にできます。トラフィックは、外部ブリッジを通って到着および残す場合でも可能です。外部ブリッジは、ブリッジの一端上の仮想化された内部 NIC インターフェイスと、ブリッジのもう一方の端の物理外部 NIC インターフェイスを使用して、パケットとフレームを送受信します。内部ブリッジには複数のタイプがあります。これらのタイプは、ホスト OS の仮想化された内部スイッチ機能を介してブリッジ接続することで、2 つの仮想化された内部 NIC インターフェイスをリンクします。Virtio の全体的なアーキテクチャを図 6 に示します。
図 6 は 、ホスト OS を実行している単一の物理サーバー NIC カードを使用したサーバー デバイスの内部構造を示しています(デバイスの外部カバーは示されません)。ホスト OS には、virtio で実装仮想スイッチまたはブリッジが含されています。OS 上では、複数の仮想マシンが virtio を介して通信する仮想 NIC を採用しています。複数の仮想マシンが実行されています。この図には1~Nの番号が付けられています。標準的な「点点ドット」表記は、図に示されていない仮想マシンおよび NIC の可能性を示しています。点線は、virtio を使用するデータ パスの可能性を示しています。デバイスで送信されるトラフィックは、物理インターフェイスとポートを通NIC注意してください。
図 6 はまた 、内部ブリッジを通ってデバイスを行きき渡るトラフィックも示しています。バーチャル マシン 1 は、仮想化された内部インターフェイスとインターフェイスNIC外部インターフェイスとリンクNICします。バーチャル マシン 2 および仮想マシン N は、ホスト OS の内部ブリッジを介して内部仮想 NIC にリンクします。 これらのインターフェイスには、VLAN ラベルが関連付けられている場合または内部インターフェイス名が付けられている場合があります。VFS 間のこの内部ブリッジを越えて送信されたフレームは、デバイスを離れる必要は決してない。ホスト OS 内でのブリッジ(および仮想化スイッチ機能)の位置に注意してください。 デバイスでのシンプルなブリッジングの使用に注意してください。これらのブリッジは、通常の Linux コマンド または 複数の設定ステートメントCLI使用して設定できます。スクリプトを使用して、プロセスを自動化できます。
Virtio は、ディスク仮想化デバイス ドライバーの標準です。仮想環境で実行中を確認する必要があるのは、ゲスト デバイス ドライバー (仮想化機能のデバイス ドライバー)のみです。これらのドライバーはハイパーバイザーと連携し、仮想機能は複雑化した場合の見返りとしてパフォーマンス上のメリットを得えます。Virtioは、Xenの仮想化デバイスドライバー(Xenでの実行を迅速化するためにゲストに追加されたドライバー)と構造的に似ていますが、そうではありません。VMWare のゲスト ツールも virtio に似ています。
トラフィックの多くが、仮想化された内部ブリッジ上で、ホスト OS CPU に集中している(より明確に)集中している点に注意してください。そのため、ホスト CPU は、デバイスの拡張に合って適切に機能する必要があります。
SR-IOV の使用状況について
物理デバイスを仮想化すると、NIC(物理ネットワーク インターフェイス カード)インターフェイスと外部物理スイッチ、仮想 NIC インターフェイスと内部仮想スイッチの両方が共存します。そのため、分離された VM(仮想マシン)またはデバイス内のコンテナが、それぞれ独自のメモリとディスク容量、CPU サイクルを持つ場合、相互に通信を試み、使用している複数のポート、MAC アドレス、IP アドレスは課題になります。
SR-IOV は仮想化機能の概念を物理環境にNIC。 1枚の物理カードは物理ポートごとに最大16のパーティションNIC上位レイヤーで実行される仮想機能に対応します。これらの仮想機能間の通信は、通常、個々の仮想デバイスを持つデバイス間の通信NIC、ブリッジで処理されるのと同じ方法で処理されます。SR-IOV には、SR-IOV NIC スイッチの作成、削除、列挙、照会のための標準的な方法と、設定できるよりも標準的なパラメーターが含まれています。
SR-IOVの単一ルート部分は、ネットワークの主な部分が実際に 1 NICしているという事実を指します。SR-IOV 対応スイッチはNICのイーサネット ポートで、すべてのネットワーク カードと同じ物理ビットバイビット機能を提供します。
ただし、SR-IOV はいくつかの仮想機能も提供します。これは、入出力タスクを処理するシンプルなキューによって実行されます。デバイス上で実行されている各 VNF は、これらの NIC パーティションの 1 つにマッピングされ、VNF 自体が他のハードウェア リソースNICアクセスできます。またNICレイヤー 2 のソーサー機能も備え、フレームをトラフィック キューに分類します。パケットは、ハイパーバイザーを完全にバイパスして、ネットワーク仮想機能とVMのメモリ間で直接、またはVMのメモリに直接移動されます。SR-IOV 運用におけるNICの役割を図 7 に示します。
ハイパーバイザーは依然として仮想ネットワーク機能へのVFSの割り当てや物理カードの管理には関与しますが、パケット内部のデータ転送には関与しません。VNF と VNF 間の通信は、仮想サーバー 1、NIC NIC 2、仮想インターフェイス N によってNIC注意してください。また、すべての仮想機能およびソーサーを追跡して VFS と外部デバイス ポート間のトラフィックを追跡するサービス スイッチ(図をNIC)も表示されます。
SR-IOV をサポートする機能は、プラットフォーム ハードウェア、特に NIC ハードウェア、データ転送に SR を採用する VFS またはコンテナのソフトウェアに依存します。パーティション可能な NIC と必要な内部ブリッジングは高価になる傾向があります。その理由から、この使用は小型デバイスのコストを大幅に増加する可能性があります。VFS やコンテナの書き換えも簡単な作業ではありません。
Virtio と SR-IOV の比較
Virtio は、標準的な libvirt ライブラリの一部であり、仮想化の機能を提供し、通常は Linux のほとんどのバージョンに含まれています。Virtio はソフトウェア専用のアプローチを採用しています。SR-IOV は、特定の方法で特別なハードウェアを記述したソフトウェアを必要とします。つまり、シンプルなデバイスを使用した場合でもコストが増加します。
通常、virtio を迅速かつ簡単に使用できます。Libvirt は Linux ディストリビューションの一部であり、ブリッジを確立するためのコマンドについては十分に理解されています。ただし、virtio はホスト OS のパフォーマンスのすべての負担を負います。通常は、VFS 間のすべてのトラフィックをデバイスとの間でブリッジ接続します。
一般的に、SR-IOV は低遅延で CPU 使用率を低減します。要するに、仮想デバイス以外のデバイス のパフォーマンスもほとんどネイティブです。しかし、VNF はデバイス間の移行は複雑です。VNF は 1 つのマシン上のリソースのNICによって異なっています。また、VNF の転送状態は、SR-IOV スイッチに組み込みのレイヤー 2 スイッチにNIC。このため、転送ルールはハードウェアにコード化され、変更できないことが多く、転送に関する柔軟性がかなりなくなるのです。
VIRTIO のサポートはほぼユニバーサルですが、SR-IOV のサポートはハードウェアやプラットフォームによってNICによって異なります。このジュニパーネットワークス NFX250 ネットワーク サービス プラットフォーム SR-IOV 機能をサポートし、物理インターフェイスポートごとに 16 NICできます。
特定の VNF は、virtio または SR-IOV、またはサポートされている場合は両方の方法を同時に使用できます。
Virtio は、仮想デバイスと NFV モジュール間の接続を確立するために推奨される方法です。