JDM アーキテクチャの概要

細分化されたJunos OSアーキテクチャの基本原理は、緊密に束ねられたJunos OSソフトウェアと独自のハードウェアを、ジュニパーネットワークスのハードウェアだけでなく、ホワイトボックスやベアメタルサーバーでも実行できる仮想化コンポーネントに分解(分離)することです。この新しいアーキテクチャでは、Juniper デバイスマネージャー(JDM)は、ソフトウェアコンポーネントを管理する仮想化ルートコンテナです。

JDM は、細分化された Junos OS アーキテクチャにおける唯一のルート コンテナです(複数のルート コンテナが許可されるインダストリ モデルは他にもありますが、細分化された Junos OS アーキテクチャはその一つではありません)。細分化された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)またはコンテナにインストールできます。

• これらのアプリケーションとツールは、一般的なLinuxリポジトリを使用してアップグレードでき、Junos OSのリリースに依存しません。

• モジュール方式では、モジュール内に障害が封じ込められるため、信頼性が向上します。

• コントロールプレーンとデータプレーンは、APIを介して直接プログラムできます。

細分化された Junos OS 仕様には、アーキテクチャ モデルが含まれています。家の建築モデルには、キッチン、屋根、ダイニング ルームを含む方向を含めることができ、さまざまな種類の住居を表すことができます。海辺のコテージから宮殿のような邸宅まで。これらの家はすべて非常に異なって見えますが、それでも基本的な建築モデルに従っており、多くの特徴を共有しています。

同様に、細分化されたJunos OSアーキテクチャモデルの場合、モデルは、単純なCPE(顧客構内機器)から大規模なデータセンターに設置された複雑なスイッチング機器まで、大きく異なるタイプのプラットフォームを対象としていますが、プラットフォームに共通するいくつかの基本的な特性があります。

これらのプラットフォームに共通する特徴は何ですか?細分化されたJunos OSプラットフォームはすべて、3つのレイヤー上に構築されています。これらの層と、考えられるいくつかのコンテンツを 図 3 に示します。

最下層はハードウェア層です。プラットフォームハードウェアには、メモリ(RAM)とディスク容量(SSD)に加えて、管理に使用される外部NICポートを備えたマルチコアCPUが搭載されています。場合によっては、コントロールプレーンとデータプレーンに使用される単一のNICポートがありますが、そのポートを使用して、ユーザートラフィックストリームのパケット転送エンジンと通信することもできます。

プラットフォームのソフトウェア層は、ハードウェア層の上に位置します。すべてのプラットフォーム依存機能はここで実行されます。これらの機能には、さまざまな仮想コンポーネント間のトラフィックをブリッジングするためのソフトウェアスイッチング機能を含めることができます。プラットフォームは Linux またはカーネルベースの仮想マシン(KVM)で実行され、一部のモデルでは、Phone Home エージェントがベンダーまたはサービス プロバイダーのデバイスに接続して自動構成タスクを実行します。Phone Home Agent は、小規模な CPE プラットフォームに特に適しています。

プラットフォームソフトウェア層の上には、カスタマソフトウェア層があり、プラットフォームに依存しないさまざまな機能を実行します。コンポーネントには、仮想SRX デバイス(vSRX仮想ファイアウォール)や Junos コントロールプレーン(JCP)などのジュニパーネットワークスの仮想マシンが含まれる場合があります。JCPはJDMと連携して、ジュニパーネットワークスの専用プラットフォームに似せつつ、はるかに柔軟性の高いデバイスを作成します。この柔軟性の多くは、仮想化ネットワーク機能(VNF)を実装する1つ以上のVNFをサポートする機能からもたらされます。これらのVNFは、NAT(ネットワークアドレス変換)、DNS(特殊ドメイン生成アルゴリズム)サーバー検索など、多くのタイプのタスクで構成されています。

一般に、CPU コアの数は決まっており、ディスク容量は有限です。しかし、仮想環境では、リソースの割り当てと使用はより複雑になります。インターフェイス、ディスク容量、メモリ、コアなどの仮想リソースは、VNFイメージによって決定される時点で実行中のVNF間で分割されます。

物理デバイスを共有する仮想マシン(VM)またはコンテナのいずれであっても、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 など) である。

VNFとコンテナの両方で、数十または数百のVNFが1台の物理サーバーを共有して、ハードウェアの多重化が可能です。これにより、新しいサービスの迅速な導入だけでなく、使用頻度が高い時(延長が使用可能な場合)や物理的なメンテナンス時(移行が可能な場合)のワークロードの拡張や移行も可能になります。

クラウドコンピューティング環境では、VNFを使用して、現代のネットワークのビッグデータを特徴付ける大規模なサーバーファームでの負荷の高い作業を行うのが一般的です。サーバーの仮想化により、さまざまな開発環境、ハードウェアプラットフォーム、またはオペレーティングシステム向けに作成されたアプリケーションを、適切なソフトウェアスイートを実行する汎用ハードウェア上で実行することができます。

VNFは、ハイパーバイザーに依存して物理環境を管理し、特定の時間に実行中のVNF間でリソースを割り当てます。一般的なハイパーバイザーには、Xen、KVM、VMWare ESXiなどがありますが、他にも多くのハイパーバイザーがあります。VNFはハイパーバイザー上のユーザースペースで実行され、VMアプリケーションのオペレーティングシステムの完全な実装が含まれます。たとえば、C++ 言語で記述され、Microsoft Windows オペレーティング システムでコンパイルおよび実行されるアプリケーションは、ハイパーバイザーを使用して Linux オペレーティング システムで実行できます。この場合、Windows はゲスト OS です。

ハイパーバイザーは、VNFのハードウェアのエミュレートされたビューをゲストオペレーティングシステムに提供します。メモリのディスク容量などの他のリソースの中でも、ハイパーバイザーは、異なるVMのエンドポイントが異なるサーバーまたはホストに存在する場合(一般的な状況)、ネットワークインターフェイスカード(NIC)の仮想化ビューを提供します。ハイパーバイザーは物理NICを管理し、仮想化されたインターフェイスのみをVNFに公開します。

また、ハイパーバイザーは仮想スイッチ環境も実行しており、VLANフレームレイヤーのVNFが、同じボックス内または(仮想)ネットワークを介してパケットを交換できます。

VNFの最大の利点は、ほとんどのアプリケーションをハイパーバイザー環境に簡単に移植でき、変更なしで適切に動作できることです。

最大の欠点は、VNF全体の機能がドメインネームシステム(DNS)などの単純なサービスを提供することであっても、ゲストオペレーティングシステムのリソースを大量に消費するオーバーヘッドには、オペレーティングシステムの完全なバージョンが含まれていなければならないことが多いことです。

コンテナはVNFとは異なり、仮想環境で独立したタスクとして実行することを目的に構築されています。コンテナは、VNFのようにOS全体をコンテナ化しません。コンテナーはさまざまな方法でコーディングおよびバンドルできますが、保守と拡張が簡単な標準コンテナーを構築する方法もあります。標準コンテナは、でたらめに作成されたコンテナよりもはるかにオープンです。

標準Linuxコンテナは、標準コンテナと呼ばれるソフトウェア配信の単位を定義します。標準コンテナーは、ゲスト オペレーティング システム全体をカプセル化する代わりに、アプリケーションと、アプリケーションが実行するようにプログラムされているタスクを実行するために必要な依存関係のみをカプセル化します。この 1 つのランタイム要素は変更できますが、拡張機能に必要な追加の依存関係を含めるためにコンテナーを再構築する必要があります。コンテナの全体的なアーキテクチャを 図5に示します。

コンテナーは、ハイパーバイザーではなく、ホスト OS カーネルで実行されます。コンテナアーキテクチャでは、コンテナエンジンを使用して基盤となるプラットフォームを管理します。VNFを引き続き実行したい場合は、コンテナでハイパーバイザーとゲストOS環境全体をパッケージ化することもできます。

標準コンテナには次のものが含まれます。

• 構成ファイル。

• 一連の標準操作。

• 実行環境。

コンテナという名前は、世界中で商品を輸送するために使用される輸送用コンテナから借用されています。輸送用コンテナは、コンテナを処理するために特別に構築された機器によって積み込み、ラベル付け、積み重ね、吊り上げ、および積み降ろしができる標準的な配送単位です。中に何が入っていても、コンテナは標準的な方法で扱うことができ、各コンテナには他のコンテナでは使用できない独自のユーザースペースがあります。Dockerは、物理サーバー上でコンテナを実行するための一般的なコンテナ管理システムですが、DrawbridgeやRocketなどの代替手段を検討することもできます。

各コンテナには仮想インターフェイスが割り当てられます。Dockerなどのコンテナ管理システムには、複数の仮想インターフェイスと物理NICを接続する仮想イーサネットブリッジが含まれています。コンテナ内の設定変数と環境変数によって、どのコンテナが相互に通信できるか、どのコンテナが外部ネットワークを使用できるかなどが決まります。通常、外部ネットワークは NAT で実現されますが、コンテナは多くの場合、同じネットワーク アドレス空間を使用するため、他の方法もあります。

コンテナの最大の利点は、デバイスにロードして、VNFよりもはるかに高速に実行できることです。また、コンテナはリソースの使用を控えめに行います。同じハードウェア上で、VNFよりも多くのコンテナを実行できます。これは、コンテナーが完全なゲスト オペレーティング システムやブート時間を必要としないためです。コンテナの読み込みと実行は、数十秒ではなく、数ミリ秒で完了します。ただし、コンテナの最大の欠点は、VNFがネイティブな状態で実行できるのに対し、コンテナは何らかの標準または一般的な実装に準拠するように特別に記述する必要があることです。

virtio を使用するか、適切なハードウェアとシングルルート I/O 仮想化 (SR-IOV) を使用して、Linux ベースの仮想化デバイスとネットワーク機能仮想化 (NFV) モジュール間の通信を有効にすることができます。それぞれの方法には異なる特徴があります。

• Virtio の使用状況を理解する
• SR-IOV の使用状況について
• Virtio と SR-IOV の比較