VMホストの概要(Junos OS)

プラットフォームの仮想化

ホストOSとKVM(またはハイパーバイザー)で構成される中間層の導入によるプラットフォームの仮想化。

• Junos OS の複数のインスタンスの同時実行をサポートします。

• サードパーティ製ソフトウェアを直接実行できるようになります。

ハードウェア支援準仮想化ゲスト Junos OS

デフォルトのパフォーマンスおよび機能とともに、プラットフォーム仮想化のメリットをユーザーに提供します。準仮想化とは、基盤となるハードウェアコンポーネントに類似したソフトウェアコンポーネントがVM内に配置され、ハイパーバイザーと対話して多くの操作を実行する仮想化技術です。完全仮想化とは対照的に、この手法では VM での仮想化のオーバーヘッドが軽減されます。

管理フレームワークとして機能するゲストJunos OS

構成、シャーシ制御、ホストOSとの通信、ユーザーインターフェイスコマンドの実行は、ゲストJunos OSによって管理されます。

ストレージのパーティショニングと冗長性

内蔵ソリッド ステート ドライブ(SSD)は、ルーティングエンジンを動作させるためのブート メディアとして使用されます。USBストレージやネットワークブートなどの追加オプションは、インストールとリカバリの目的で利用できます。50 GB SSD 2台セットは、ルーティングエンジンの通常の機能に使用できます。ルーティングエンジンでは、両方のSSDが機能している必要があります。ストレージ パーティショニングは、ルーティングエンジンのデバッグ、新規インストール、SSD 交換に重要です。

2台のSSDのうち、1台はプライマリSSDとして動作し、もう1台はバックアップSSDとして動作します。プライマリSSDでは、現在のセットと代替(または以前の)セットの2セットのソフトウェアブートイメージを使用できます。システムは現在のセットからブートしますが、代替セットには以前のバージョンのソフトウェア ブート イメージが含まれています。ソフトウェアのアップグレード後、新しいバージョンのソフトウェアが代替セットで利用可能になります。アップグレード後にデバイスを再起動すると、代替セットが新しい現在のセットになり、古いバージョンのソフトウェア イメージが保持されている現在のセットが代替セットになります。 request vmhost software rollback コマンドを使用して、代替セットに切り替えることができます。ソフトウェアのアップグレードまたはロールバックが実行されるまで、システムはディスク上の同じイメージのセットから起動するようにプログラムされています。

両方のSSDは、ホストブートパーティション、ルートパーティション、およびゲストイメージストレージ用のパーティションを提供するためにパーティション化されています。ホストブートパーティションには、OS、Linuxカーネル、およびRAMファイルシステムの起動を担当するソフトウェアであるブートローダーが含まれています。ルートパーティションには、ホストOSのルートファイルシステムが含まれています。

図 2 は、SSD のパーティション分割を示しています。

各SSDパーティションには、完全に機能するホストソフトウェアのセットが複数含まれています。プライマリSSDで起動に失敗した場合、ルーターは代替SSDで使用可能なスナップショットを使用して起動できます。このスナップショットは、新規インストールまたは request vmhost snapshot コマンドを使用して生成できます。

Junos OS リリース 18.1R1以降、MX240、MX480、MX960、MX2010、MX2020、PTX5000のルーティングエンジンはセキュアブートをサポートしています。

Junos OS リリース 18.2R1 以降、MX2008 のルーティングエンジンはセキュア ブートをサポートしています。

セキュアブートをサポートするルーティングエンジンは、RAMとSSDの両方がそれぞれ128GBと2x200GBにアップグレードされています。SSDのサイズが大きくなると、コアファイルとログファイルのストレージが容易になります。

以下の表は、各ルーティングエンジンのSSDサイズに関する情報を示しています:

表2:ルーティングエンジンのSSDサイズ

デバイス	ルーティングエンジンのモデル番号	SSDサイズ
ACX5448	RE-ACX-5448	2x100GB
EX9204、EX9208、およびEX9214	EX9200-RE2	2x64GB
MX204	RE-S-1600x8	2x50GB
MX240、MX480、およびMX960	RE-S-2200X6-64G-S	2x50GB
	RE-S-X6-64G-LT	2x50GB
	RE-S-X6-128G-S	2x200GB
MX2008	REMX2008-X8-64G-LT	2x100GB
	REMX2008-X8-128G-S	2x200GB
MX2010およびMX2020	RE-MX2K-X8-64G	2x100GB
	RE-MX2K-X8-64G-LT	2x100GB
	RE-MX2K-X8-128G-S	2x200GB
MX10003	RE-S-1600x8	2x50GB
MX10008 MX10004	JNP10K-RE1、JNP10K-RE1-LT、JNP10K-RE1-128	2x200GB
PTX3000	RCBPTX	2x64GB
PTX5000	RE-PTX-X8-64G	2x64GB
PTX10002-60C	RE-PTX10002-60C	2x50GB
QFX10002-60C	RE-QFX10002-60C	2x50GB
SRX5000	SRX5K-RE3	2x128GB

show vmhost hardwareコマンドを使用して、増加したRAMサイズ、SSDサイズ、およびその他のハードウェア情報を表示できます。

次の図は、コア・ファイルおよびログ・ファイルのストレージを増やすためのホストのパーティションを示しています。 図 3 は、200 GB の SSD を搭載した MX240、MX480、MX960、MX2008、PTX5000 ルーターのホストのパーティションを示しています。サイズ 56 GB の仮想ディスクは、VM パーティションからゲストに var-config.disk として割り当てられます。このディスクの現在のサイズは 15 GB です。

図 4 は、ゲスト VM のストレージ割り当てを示しています。

手記：

50GB SSD搭載のルーティングエンジンの場合、ホストパーティションはそのまま残ります。

図 5 と図 6 は、それぞれ MX2010 ルーターと MX2020 ルーターのホスト パーティション テーブルとゲスト VM のストレージ割り当てを示しています。

サイズ 32 GB の仮想ディスクは、VM パーティションからゲスト Junos OS に var-config.disk として割り当てられます。

/var サイズの拡張を実装するには、SSD の再フォーマットが必要です。アップグレードは、次のいずれかの方法で実装できます。

• SSD ディスク 2 からのインストール - バックアップ ディスク(SSD ディスク 2)からホスト OS を起動し、junos-vmhost-install-x.tgz イメージをインストールします。

• USBからのインストール

NTPとタイムゾーン

日付とタイムゾーンは、管理ゲストJunos OSからホストOSに同期されます。そのため、Junos OSとホストOSのシステムログファイルのタイムスタンプは同期されます。

自動リカバリー

自動回復(自動回復)機能は、次の機能を提供します。

• システム起動中にディスクパーティションの破損を検出し、パーティションを自動的に回復しようとする

• システム起動中に Junos OS 設定の破損を検出し、設定の自動回復を試みることで、運用と管理が中断されないようにする。

• システム起動中に Junos OS ライセンスの破損を検出し、ライセンスの自動リカバリーを試みる。

リカバリのプロセス中、ホストOSはプライマリディスクで使用可能なイメージからJunos VMを起動しようとします。ただし、Junos VMの起動に失敗した場合、ホストOSは、ホストOSイメージとバックアップディスクで利用可能なJunos OSイメージのスナップショットからJunos VMの起動を試みます( request vmhost snapshot が最後に実行された操作である場合)。バックアップ ディスクにスナップショットが含まれていない場合、ホストOSは、 request vmhost upgrade が最後に実行された操作であれば、プライマリディスクの代替セットで使用可能なソフトウェアからJunos VMの起動を試みます。

自動リカバリ機能は、ゲスト OS で既定で有効になっています。自動回復を無効にする必要がある場合 (たとえば、デバッグのエラー状態を調べる場合) は、次のコマンドを使用します。

user@host> set vmhost no-auto-recovery

再起動と電源オフの処理

request vmhost rebootコマンドを使用して、ルーティングエンジンを再起動できます。このコマンドは、ゲストJunos OSとホストOSの両方をリブートすることで、ルーティングエンジンをリブートします。しかしながら、さまざまな理由でルーティングエンジンの再起動がトリガーされることがあります。ホストOSの再起動をトリガーするイベントまたは理由は、ゲストOSの再起動をトリガーするイベントまたは理由とは異なります。

ゲストOSの再起動は、Junos OSのみが再起動され、ホストOSが稼働していることを意味します。以下は、ゲスト OS の再起動をトリガーするいくつかの理由です。

• パニックによる再起動

• VJUNOS reboot—シャットダウン後のゲスト OS の再起動。

• ホストからの VJUNOS watchdog—エミュレートされたウォッチドッグ タイマーの期限が切れたため、ゲストが再起動

ホストOSの再起動は、ホストOSとゲストOS(ここではJunos OS)の両方が再起動されることを意味します。以下は、ホストOSとゲストOSの再起動をトリガーするいくつかの理由です。

• ハイパーバイザーの再起動

• 電源の再投入または電源障害

• 例外のため再起動します。

• リセットボタンリセット:フロントパネルのリセットボタンを押すことでトリガーされるリブート。

• サーマル・シャットダウン

• ウォッチドッグ—PCH ウォッチドッグ タイマーの期限が切れたため、再起動します

再起動の理由は、 show chassis routing-engine コマンドまたは show vmhost uptime コマンドで確認できます。

例えば：

ルーティングエンジンの起動が完了し、ルーターの電源を再度オフにする必要がある場合は、 request vmhost power-off コマンドを実行します。ルーティングエンジンを再起動する場合は、 request vmhost reboot コマンドを使用します。