NETCONF または Junos XML プロトコルを使用した一時的な設定データのコミットと同期

エフェメラルデータベースは、NETCONFとJunos XMLプロトコルのクライアントアプリケーションが、候補の設定データベースにデータをコミットする場合よりも大幅に高いスループットで、Junosデバイス上での設定変更を同時にロードしてコミットできるようにする代替設定データベースです。クライアントアプリケーションは、一時的な設定データベースのオープンインスタンスに設定データをコミットして、デバイス上のアクティブな設定の一部にすることができます。デバイス上の一時的な設定データをコミットすると、デバイスのアクティブな設定は、静的設定データベースと一時的な設定データベースのマージされたビューになります。

クライアントアプリケーションが一時的なインスタンスをコミットした後、デバイスは設定データを一時的なデータベースにマージします。影響を受けるシステム プロセスは、構成を解析し、一時的なデータをアクティブな構成のデータとマージします。静的構成データベースと一時構成データベースに矛盾するステートメントがある場合、データは特定の優先順位付けルールに従ってマージされます。データベースの優先順位は、高いものから低いものへと、次のとおりです。

1. 一時的な構成データベースのユーザー定義インスタンス内のステートメント。

   ユーザー定義の一時インスタンスが複数ある場合、優先度は、インスタンスが [edit system configuration-database ephemeral] 階層レベルで設定されている順序 (優先度の高いものから低いものへ) によって決まります。

2. デフォルトの一時データベースインスタンス内のステートメント。

3. 静的構成データベース内のステートメント。

アクティブなデバイス設定は、静的設定データベースとエフェメラル設定データベースをマージしたビューです。ただし、 show configuration operational mode コマンドを使用して CLI で設定を表示すると、出力には一時的な設定データは含まれません。CLI では、 show ephemeral-configuration コマンドのバリエーションを使用して、一時データベースの特定のインスタンスのデータを表示したり、静的構成データベースと一時構成データベースのマージされたビューを表示したりできます。

クライアントアプリケーションは、一時的な設定データベースのオープンインスタンスに設定データをコミットして、デバイス上のアクティブな設定の一部にすることができます。設定をコミットするには、Junos XML プロトコル セッションで <commit-configuration/> 操作を使用するか、NETCONF セッションで <commit-configuration/> または <commit/> 操作を使用します。

Junos XML プロトコルのセッションでは、クライアントアプリケーションは、(候補の構成の場合と同様に) <commit-configuration/> タグを <rpc> タグ要素で囲むことによって、一時的な設定データベースのオープンインスタンスに設定データをコミットします。

Junos XML プロトコル サーバーは、 <rpc-reply>、 <commit-results>、および <routing-engine> タグ要素でコミット操作の結果を報告します。コミット操作が成功した場合、 <routing-engine> タグ要素は、 <commit-success/> タグと、ターゲットルーティングエンジンを指定する <name> タグ要素を囲みます。

NETCONF セッションでは、クライアント アプリケーションは、(候補コンフィギュレーションの場合と同様に) <commit/> タグまたは <commit-configuration/> タグを <rpc> タグ要素で囲むことによって、一時的な設定データベースのオープン インスタンスに設定データをコミットします。

NETCONF サーバーは、<rpc-reply> タグ要素に <ok/> タグを返すことで、コミット操作が成功したことを確認します。

コミット操作が失敗した場合、NETCONF サーバは失敗の理由を説明する <rpc-reply> 要素と <rpc-error> 子要素を返します。

エフェメラルデータベースでサポートされているコミット操作の唯一のバリアントは、 エフェメラルインスタンスの同期の概要で説明されているように、設定を同期することです。

デュアル ルーティング エンジン デバイスとバーチャル シャーシ システムは、一時インスタンスでコミット操作を発行しても、一時的な設定データを自動的に同期しません。エフェメラルインスタンス内のデータをコミットごとまたはセッションごとに同期することも、インスタンスをコミットするたびにデータを同期するようにエフェメラルインスタンスを設定することもできます。環境によって、データが同期される場所が決まります。次に例を示します。

• デュアルルーティングエンジンを搭載したデバイスでは、デバイスはエフェメラルインスタンスをバックアップルーティングエンジンに同期させます。

• MXシリーズの仮想シャーシは、バックアップデバイスのプライマリルーティングエンジンにのみエフェメラルインスタンスを同期させます。

• EXシリーズの仮想シャーシは、エフェメラルインスタンスをすべてのメンバースイッチに同期させます。

エフェメラルインスタンスの同期手順については、以下のセクションを参照してください。

• 一時的な設定データを同期するための GRES 対応デバイスの設定方法

• コミットごとにエフェメラルインスタンスを同期する方法

• セッションごとにエフェメラルインスタンスを同期する方法

• コミット時にエフェメラルインスタンスを自動的に同期する方法

• エフェメラル データベースのフェールオーバー構成の同期を構成する方法

デフォルトでは、エフェメラル コミット モデルはコミット同期操作を非同期的に実行します。NETCONFまたはJunos XMLプロトコルサーバーは、ローカルルーティングエンジンで設定をコミットしてから、リモートルーティングエンジンまたはバーチャルシャーシメンバーで設定をコミットします。要求元のルーティング エンジンは、一時的な設定をコミットし、他のルーティング エンジンまたはバーチャル シャーシ メンバーが最初に設定を同期してコミットするのを待たずに、コミット完了通知を出力します。

サポートされているデバイスでは、コミット同期操作に同期コミット モデルを使用するように一時データベースを構成することもできます。同期コミット操作は、非同期コミット操作よりも低速ですが、信頼性に優れています。同期モデルを使用するには、静的構成データベースの[edit system configuration-database ephemeral]階層レベルで commit-synchronize-model synchronous ステートメントを設定します。

一時インスタンスを同期すると、Junos XML プロトコルサーバーは、ローカルルーティングエンジンのコミット操作の結果を <rpc-reply>、 <commit-results>、および <routing-engine> タグ要素で報告します。コミット操作が成功した場合、 <routing-engine> タグ要素は、 <commit-success/> タグと、ターゲット ルーティング エンジンを指定する <name> タグ要素を囲みます。

サーバー応答には、データベースで使用されるコミット同期モデルに依存する追加のタグが含まれます。

• エフェメラルデータベースが同期モデルを使用する場合、サーバー応答には、他のルーティングエンジンでのコミット操作用の2番目の <routing-engine> 要素が含まれます。

• エフェメラルデータベースが非同期モデルを使用している場合、サーバーには <commit-synchronize-server-success> タグ要素が含まれます。これは、同期操作が他のルーティングエンジンまたはバーチャルシャーシメンバーでスケジュールされていることを示し、操作が完了するまでに必要な推定時間を秒単位で提供します。

例えば：

同期コミット同期操作の RPC 応答は、他のルーティング エンジンまたはバーチャル シャーシ メンバーでのコミット操作の成功または失敗を示します。デバイスが特定のファシリティと重大度レベルのイベントをログに記録するように設定されている場合、デバイスは非同期コミット同期操作の成功または失敗をシステム ログ ファイルに記録します。さまざまな一時データベースイベントと、それらをログに記録するために必要な機能レベルと重大度レベルについては、 システムログエクスプローラー を参照してください。

同様に、NETCONF セッションでは、サーバーは <rpc-reply> タグ要素に <ok/> タグを返すことで、コミット操作が成功したことを確認します。デバイスの構成によっては、同期コミット同期操作の <commit-results> 要素または非同期コミット同期操作の <commit-synchronize-server-success> 要素も応答に含まれる場合があります。例えば：

デフォルトでは、エフェメラルデータベースはコミット同期操作を非同期で実行し、グレースフルルーティングエンジンスイッチオーバー(GRES)を有効にした場合、エフェメラル設定データをバックアップルーティングエンジンまたは他のバーチャルシャーシメンバーに同期させません。エフェメラルデータベースが非同期コミット同期モデルを使用する場合、 allow-commit-synchronize-with-gres ステートメントを設定して、GRES 対応デバイスがコミット同期操作を実行できるようにする必要があります。

または、サポートされているデバイスでは、代わりに、同期コミット モデルを使用してコミット同期操作を実行するように一時的なデータベースを構成できます。同期コミット操作は、非同期コミット操作よりも低速ですが、信頼性に優れています。GRES が有効になっているデバイスでは、同期コミットモデルの使用を推奨します。

一時的な設定データを同期するように GRES が設定されているデバイスを有効にするには:

ルーティングエンジンまたはバーチャルシャーシメンバー間で、そのインスタンスでの所定のコミット操作に対して、エフェメラルインスタンスを同期させることができます。

コミットごとにエフェメラルインスタンスを同期するには:

ルーティングエンジンまたはバーチャルシャーシメンバー間で、エフェメラルインスタンスが開いている間(大まかにセッションと呼びます)に実行されたすべてのコミット操作について、エフェメラルインスタンスを同期させることができます。これをNETCONFやJunos XMLプロトコルのセッションと混同しないでください。セッションごとにインスタンスを同期すると、複数のロードおよびコミット操作を実行し、各コミット操作がインスタンスを閉じるまで自動的に同期されるようにすることができます。

インスタンスが開いている間に実行されたすべてのコミット操作のエフェメラルインスタンスを同期するには:

Junos OSリリース22.1R1以降を実行しているデバイスおよびJunos OS Evolvedを実行しているデバイスでは、インスタンスをコミットするたびにルーティングエンジンまたはバーチャルシャーシメンバー間で設定を同期するように、エフェメラルインスタンスを設定できます。

インスタンスをコミットするたびに同期するようにエフェメラルインスタンスを設定するには:

MXシリーズのバーチャルシャーシおよびデュアルルーティングエンジンデバイスは、エフェメラルデータベースのフェイルオーバー設定同期をサポートしています。これにより、ルーティングエンジンのスイッチオーバーが発生した場合に、ルーティングエンジン間で設定データベースを同期させることができます。これは、静的設定データベースの[edit system]階層レベルで commit synchronize ステートメントを設定すると実現されます。

静的設定データベースに commit synchronize ステートメントを設定すると、次のような影響があります。

• デバイスは、コミット操作中に、その静的設定データベースをバックアップのルーティング エンジンまたは MX バーチャル シャーシのバックアップ デバイスに同期させます。

  手記：

  静的設定データベースに commit synchronize ステートメントを設定しても、静的設定データベースをコミットするとき、またはインスタンスをコミットするときに、エフェメラル インスタンスはバックアップ デバイスに同期されません。

• Junos OS リリース 20.2R1 以降、バックアップ ルーティング エンジンと MX バーチャル シャーシ バックアップ デバイスは、プライマリ デバイスとの同期時に、静的設定データベースとエフェメラル設定データベースの両方を同期させます。以前のリリースでは、バックアップ ルーティング エンジンはスタティック コンフィギュレーション データベースのみを同期します。

  手記：

  フェイルオーバー同期の場合、バックアップ ルーティング エンジンと MX バーチャル シャーシ バックアップ デバイスは、バックアップ デバイスとプライマリ デバイスの両方が同じソフトウェア バージョンを実行している場合にのみ、一時的な設定データベースをプライマリ デバイスと同期します。

プライマリおよびバックアップルーティングエンジンで commit synchronize ステートメントを設定すると、バックアップルーティングエンジンは、以下のシナリオでその設定をプライマリルーティングエンジンと同期させます。

• バックアップ ルーティング エンジンが削除され、再挿入されます。

• バックアップ ルーティング エンジンが再起動されます。

• デバイスは、グレースフルルーティングエンジンスイッチオーバーを実行します

• 役割が手動で変更される

• commit synchronize ステートメントが設定された新しいバックアップ ルーティング エンジンが挿入されます

デュアルルーティングエンジンシステムでは、バックアップルーティングエンジンがその設定データベースをプライマリルーティングエンジンと同期させます。MX シリーズの仮想シャーシでは、バックアップ デバイス上のプライマリ ルーティング エンジンが、その設定データベースをプライマリ デバイス上のプライマリ ルーティング エンジンと同期させます。

サポートされているデバイスでJunos OSリリース20.2R1以降を実行しているデバイス、またはJunos OS Evolvedを実行しているデバイスで、静的データベースと一時データベースの両方でフェイルオーバー構成の同期を有効にするには: