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