Junos OS EvolvedとJunos OSの主な違い

システムの違い

Junos OS Evolvedにおける システム の概念は、Junos OSとは異なります。Junos OSは、ルーティングエンジン中心のモデルを採用しています。 ここで、システム は通常、ルーティングエンジンを指します。しかしながら、Junos OS Evolvedは ノードベースモデルを採用しており、 システムは ルーティングエンジン、フレキシブルPICコンセントレータ(FPC)などを含むすべてのノードを指します。Junos OS Evolvedでは、 ノード とはLinuxカーネルおよびJunos OS Evolvedアプリケーションを実行できる任意のコンポーネントであり、すべてのノードがコンピューティングノードと見なされます。

運用への影響

Junos OS Evolvedでは、ノードごとに多くのアクションを実行できます。CLI コマンドを使用して、個々のノードの情報を表示したり、操作を要求したりできます。

関連するCLIコマンド

• show system nodes — システム内のすべてのノードのリストを表示します。

• show node ( reboot | statistics ) node-name — 特定のノードに関する情報を表示します。

• show system applications <node node-name> — すべてのノードまたは特定のノードのアプリケーション概要情報を表示します。

• show system core-dumps <node node-name> — すべてのノードまたは特定のノードのシステム・コア・ファイルを表示します。

• show system errors active- システム エラー情報を表示するには、 show chassis errors active コマンドの代わりにこのコマンドを使用します。

• show system processes <node node-name> <detail> - すべてのノードまたは特定のノードのプロセス情報を表示します。

• show system storage node ( re0 | re1 | fpc0 | fpc1 | ...) — 特定のノードの空きディスク領域を表示します。

• show version node ( all | node-name ) — すべてのノードまたは特定のノードのソフトウェア・バージョン情報を表示します。

• request node ( halt | offline | online | power-off/on | reboot ) node-name — 特定のノードに対する操作を要求します。

• request system reboot — Junos OS Evolvedでは、このコマンドはすべてのノードを再起動します。

ソフトウェアの構造と用途

Junos OS Evolvedは、自己完結型のアプリケーションとして実行されるプロセスを備えた分散型Linux OSとして機能します。すべてのJunos OS Evolvedプロセスは、アプリケーションとして実行されます。すべてのJunos OS Evolvedアプリケーションは、サービスユニットを使用して systemd プロセスによって管理されます。アプリケーションは独立したサービスとして実行されます。他のアプリケーションに影響を与えることなく、アプリケーションを個別に再起動できるため、障害の分離が実現します。ほとんどのアプリケーションは、中央データベースに格納される状態を公開および使用します。

運用への影響

Junos OS Evolvedでは、多くの高可用性機能はノード単位ではなくアプリケーション単位で導入されています。迅速なフェイルオーバーのためにフルタイムバックアップを実行するアプリケーションもあれば、障害発生時に新しいノードで再起動するアプリケーションもあります。

関連するCLIコマンド

• show system applications <node node-name> — すべてのノードまたは特定のノードのアプリケーション概要情報を表示します。

• restart process — Junos OSでは、このコマンドは特定のプロセスを再起動します。Junos OS Evolvedでは、同じコマンドが、コマンドが発行されたのと同じノード上の特定のアプリケーション(プロセス)を再起動します。

• request system application restart app application node node — このコマンドは Junos OS Evolved に固有で、特定のノードで特定のアプリケーションを再起動します。

状態モデル

Junos OS Evolvedは、分散型ステートインフラストラクチャを使用しています。アプリケーションは、ノード全体に分散される分散データストア(DDS)と呼ばれる状態データベースに格納される状態オブジェクトをパブリッシュまたはサブスクライブします。これに対し、Junos OS プロセスは状態を内部に格納し、カーネルを介して他のプロセスと状態情報や状態の変化を交換します。Junos OS Evolvedの状態モデルは非同期であり、トランスポート層では結果整合性を保ち、状態にアクセスする際のアプリケーション層では因果関係の一貫性を保ちます。つまり、Junos OS Evolvedでプロセスを再起動しても、DDSから状態情報を取得できるため、情報が失われることはありません。

運用への影響

Junos OS Evolved状態モデルは、最も遅いコンポーネントの更新を待つ必要がないため、パフォーマンスが速くなります。アプリケーションは、他のすべてのプロセスが最初に更新を完了するのを待たずに、システム状態から読み取りと書き込みを行います。アプリケーションが再始動すると、アプリケーションが別のノードで生成された場合でも、状態は保持され、新しいインスタンスによって DDS から取得されます。

ソフトウェア管理

Junos OS Evolvedにソフトウェアイメージをインストールするたびに、以前のソフトウェアイメージと設定が自動的に保持されます。Junos OS Evolvedは、ソフトウェアイメージを /soft ディレクトリに保存します。ソフトウェアの各バージョンは異なる領域に保存されるため、ソフトウェアパッケージのインストールがシステムにインストールされている他のソフトウェアバージョンに影響を与えません。Junos OSでは、2つのソフトウェアバージョンをデバイスにインストールできますが、Junos OS Evolvedでは、容量が許す限り多くのソフトウェアイメージを保存できます。ただし、システム上に保持するソフトウェアのバージョンは 5 つまでにすることをお勧めします。

インストールが成功すると、インストールパッケージによって既存のソフトウェアが完全に再インストールされます。以前のバージョンの設定ファイルや、セキュアシェルやホストキーなどの同様の情報は保持されます。ソフトウェア パッケージのインストール後にシステムを再起動すると、システム内のすべてのルーティング エンジンと FPC が新しいバージョンのソフトウェアを実行します。

運用への影響

Junos OS Evolvedは、システム内のすべてのルーティングエンジンとFPCが同じソフトウェアバージョンを実行していることを保証します。プライマリ ルーティングエンジンにソフトウェア イメージをインストールすると、ルーティング エンジンがオンラインでシステムの一部であれば、システムは両方のルーティング エンジンに新しいバージョンのソフトウェアをインストールします。ステートメントが system auto-sw-sync enable に設定されていない場合、ソフトウェア バージョンの異なるルーティングエンジンをシステムに挿入していない場合、ルーティングエンジンはシステムの外部に保持され、システムはソフトウェア不一致アラームを生成します。

新しいソフトウェア イメージをインストールすると、以前のソフトウェア パッケージが別の領域に保存され、必要に応じて手動でロールバックできます。Junos OS Evolvedでは、現在の構成ファイルまたは代替イメージが最後に実行されていたときの設定スナップショットを使用して、代替イメージにロールバックできます。

関連するCLIコマンド

• show system software list — Junos OS Evolvedで、各ノードに現在インストールされているイメージを表示します。

• show system storage — 使用可能なストレージ容量を表示します。Junos OS Evolvedでは、 /soft、 /var、 /data ディレクトリにイメージを追加するには、容量が90%未満である必要があります。

• request system software delete — 古い画像をクリーンアップします。Junos OS Evolvedリリース20.1R1以降では、システムからISOイメージを削除するには、 request system storage cleanup コマンドの代わりにこのコマンドを使用します。

• request system snapshot — デバイスの実行に現在使用されているファイルのスナップショットを作成し、そのファイルを代替のソリッド・ステート・ドライブ(SSD)にコピーします。スナップショットには、 /soft、 /config、および /root ディレクトリの完全な内容、ユーザーデータのコピー、および /var ディレクトリの内容 ( /var/core、 /var/external、 /var/log、 および /var/tmp ディレクトリを除く) が含まれます。

• request system software rollback reboot <package-name> <with-old-snapshot-config> — すべてのルーティングエンジンとFPCを別のソフトウェアバージョンにロールバックし、再起動します。ロールバック ソフトウェア イメージに対応する保存済み設定を使用するには、with-old-snapshot-config オプションを含めます。

• request system software sync ( all-versions | current | rollback ) — プライマリルーティングエンジンから他のノードにソフトウェアと設定を同期させ、他のノードを再起動します。

• set system auto-sw-sync enable — 新しく追加されたルーティングエンジンのソフトウェアバージョンがシステムの他の部分と異なる場合、プライマリルーティングエンジンから新しく追加されたルーティングエンジンにソフトウェアと設定を自動的に同期させ、再起動します。

管理インターフェイス

Junos OS Evolvedでは、管理インターフェイスの名前は、ルーティングエンジンノードごとに複数の管理ポートに対応するように変更されています。

運用への影響

Junos OS Evolvedの管理インターフェイスは、Junos OSと同じ名前(fxp0、 em0、 me0)を使用しません。Junos OS Evolvedの管理インターフェイス名の形式は、 device-name:type-portです。たとえば、 re0:mgmt-0、 re0:mgmt-1、 re1:mgmt-0、 re1:mgmt-1 などです。

show interfaces出力には、デュアルルーティングエンジンシステムの両方のルーティングエンジンからの管理イーサネットインターフェイスを含む、すべてのインターフェイスのステータスが表示されます。

システム ホスト名

Junos OS Evolvedでは、システムのホスト名の後には、 -re0 や -re1などの対応するルーティングエンジン番号が付加されます。

運用への影響

Junos OS Evolvedでは、host-nameステートメントを指定すると、指定したhostnameに現在のルーティングエンジン名が付加されます。たとえば、ルーティングエンジン 0 では、ホスト名を my-host-re0 に設定しますset system host-name my-host。また、%s文字を使用して、ルーティングエンジン名を置き換える場所を指定することもできます。たとえば、ルーティングエンジン 1 では、set system host-name %s_my_host はホスト名を re1_my-host に設定します。

関連するCLIコマンド

• set system host-name hostname

ルーティングエンジンファイアウォールフィルター

Junos OSでは、物理インターフェイスとルーティングエンジン間のローカルパケットのフローを制御するために、ループバックインターフェイスの入力または出力にステートレスファイアウォールフィルターを適用できます。ループバック インターフェイス(lo0)は、ルーティングエンジンへのインターフェイスであり、データパケットを伝送しません。Junos OS では、ループバック インターフェイスに適用されるフィルターは、ネットワーク制御トラフィックと管理トラフィックの両方に適用されます。

一方、Junos OS Evolvedは、ローカルパケットのフローを制御するために、ネットワーク制御トラフィック(ループバックトラフィック)用と管理トラフィック用の2つの異なるフィルターをサポートしています。したがって、ループバック インターフェイスに適用されるフィルターは、ネットワーク制御トラフィックにのみ適用されます。また、管理インターフェイスに個別にフィルターを適用することで、管理トラフィックに対してより厳格なフィルターを設定することもできます。

運用への影響

Junos OS Evolvedでは、ループバックインターフェイスに適用されるファイアウォールフィルターは、ネットワーク制御トラフィックにのみ適用されます。管理トラフィックをフィルタリングするには、管理インターフェイスにファイアウォールフィルターを明示的に適用する必要があります。Junos OS Evolvedでは、管理フィルタリングは、Linuxカーネルが提供するフレームワークであるNetfilterに基づくルーティングエンジンフィルターを使用します。その結果、特定の一致とアクションのみがサポートされます。 表 1 は、Junos OS Evolved フィルター アプリケーションの概要を示しています。

Junos OS Evolvedネットワークスタック

Junos OS EvolvedはネイティブLinux上で動作します。Linuxがインターフェイスやルートデータなど、要求されたネットワークトポロジー情報を表示する方法と、Junos OSがこの情報を表示する方法には、いくつかの違いがあります。Junos OS Evolved CLIは、これらの違いを克服するために設計されています。そのため、ネットワーク操作、特にルーティング インスタンスの指定が必要な操作では、シェル コマンドではなく CLI コマンドを使用することをお勧めします。

Junos OS Evolved を使用しているときに Linux シェルで操作を実行する必要がある場合は、次のルーティング インスタンス(VRF(仮想ルーティングおよび転送インスタンス)とも呼ばれる)について知っておく必要があります。

• default— mgmt_junos ルーティング インスタンスを設定しない限り、デフォルトでWANトラフィックと管理トラフィックの両方を処理します。
• mgmt_junos—このルーティング インスタンスを設定すると、管理ポートが独自のルーティング インスタンスに配置され、管理トラフィックがルーティングエンジンWANトラフィックから分離されます。

• iri- コントロール プレーン トラフィック(ノード間通信)を処理します。Junos OS Evolved CLIでは、これは __juniper_private1__ ルーティング インスタンスに相当します。

運用への影響

Junos OS Evolved シェルでは、 chvrf (VRF の変更)ユーティリティを使用して、特定のルーティング インスタンスまたは VRF のコンテキストでコマンドを実行できます。例えば：

[vrf:none] user@host:~$ chvrf -JU default ping 172.16.1.1
[vrf:none] user@host:~$ chvrf -JU iri ping fpc1
[vrf:none] user@host:~$ chvrf -JU mgmt_junos ping 198.51.100.1 
[vrf:none] user@host:~$ chvrf -JU iri ssh re1

システムロギング

Junos OS Evolvedでは、各ノードには、システムジャーナルを取得およびフィルタリングするためのインターフェイスである標準の journalctl ツールがあります。システムログメッセージは、システムジャーナルから解析されます。 relay-eventd プロセスはすべてのノードで実行し、システムジャーナルから(syslog設定に基づいて)イベント、および異なるアプリケーションからエラーメッセージを取得して、 master-eventd プロセスに転送します。 master-eventd プロセスはプライマリルーティングエンジンで実行され、ログメッセージとエラーをディスクに書き込みます。

システムログエクスプローラアプリケーションを使用して、異なるリリースでシステムログメッセージを表示または比較します。

運用への影響

Junos OS Evolvedでは、バックアップルーティングエンジンに messages ファイルはありません。すべてのバックアップルーティングエンジンログは、プライマリルーティングエンジンノード上の messages ファイルにあります。

システム ログ メッセージの形式

デフォルトでは、Junos OS Evolvedは、システムログメッセージのホスト名の後にノード名を追加します。Junos OSはサポートしていません。このアクションによりJunos OS EvolvedシステムログメッセージはRFC5424に準拠した状態が保たれます。しかしながら、監視システムによってはJunos OS Evolvedホスト名が正しく識別されない場合もあります。ホスト名とノード名の組み合わせがインベントリ内のホスト名と一致しないからです。

運用への影響

監視システムがJunos OS Evolvedホスト名を正しく識別しない場合は、 set system syslog alternate-format 設定モードコマンドを発行する必要があります。このコマンドは、Junos OS Evolvedシステムログメッセージのフォーマットを変更します。ノード名が、ホスト名の後に追加されるのではなく、メッセージ内のプロセス名の前に追加されるようになり、監視システムがホスト名を正しく識別できるようになります。

トレース アーキテクチャ

Junos OS Evolvedでは、新しいトレースアーキテクチャを採用しています。実行中のすべてのアプリケーションは、同じアプリケーションの複数のインスタンスが独自のトレース情報を持つことで、トレース情報を作成します。Junos OS Evolved trace-relay および trace-writer アプリケーションは、トレース情報を調整します。 trace-relay アプリケーションはローカル ノードで実行され、各アプリケーションとメモリ バッファーを共有します。Junos OS Evolvedアプリケーションがメモリに書き込むと、 trace-relay アプリケーションはメモリから直接データを読み取り、 trace-writer アプリケーションに送信します。 trace-writer アプリケーションは、各ルーティングエンジンノードで実行されます。 trace-relay アプリケーションから送信されたトレース情報を受け取り、それを Common Trace Format (CTF) で適切なファイルに書き込みます。

運用への影響

Junos OSでは、トレースしたい特定の階層レベルで traceoptions ステートメントを設定することで、トレース操作を有効にします。一方、Junos OS Evolvedは、アプリケーションベースのモデルを採用しているため、トレースメッセージはアプリケーションごとに記録、表示、設定されます。そのため、Junos OS Evolvedは、Junos OSがサポートする多くの階層レベルで traceoptions ステートメントをサポートしていません。ただし、 [edit protocols] の下など、一部の階層レベルでは、トレース メッセージを有効にするために traceoptions ステートメントを設定する必要があります。

Junos OS では、多くの階層レベルでグローバル トレース操作がデフォルトで無効になっていますが、一部のプロセスでは、重要なイベントのトレース メッセージをデフォルトで記録します。対照的に、Junos OS Evolvedで実行されているすべてのアプリケーションは、デフォルトで info レベルでトレース情報を作成します。

Junos OS Evolvedでは、トレースファイルを直接表示することはなく、トレースが破損する可能性があるため、 /var/log/traces ディレクトリにあるトレースファイルを追加、編集、または削除しないでください。代わりに、 show trace application application-name node node-name コマンドを使用して、トレース ファイルに格納されているトレース メッセージを読み取り、デコードします。

関連するCLIコマンド

• show trace application application-name node node-name — トレース ファイルの読み取りとデコード。

• clear trace — トレース ファイルを手動でクリーンアップします。

• set system trace application — トレース・メッセージの構成をアプリケーション・レベルで変更します。