エフェメラル構成データベースについて

エフェメラルデータベースコミット同期モデルの理解

エフェメラル設定データベースには、コミット同期操作中にルーティングエンジンまたはバーチャルシャーシメンバー間でエフェメラル設定データを同期するための2つのモデルがあります。

• 非同期 (デフォルト)

• 同期

標準のコミット モデルとは異なり、デフォルトのエフェメラル コミット モデルは、コミット同期操作を非同期的に実行します。要求元のルーティング エンジンは、一時的な設定をコミットし、他のルーティング エンジンが最初に設定を同期してコミットするのを待たずに、コミット完了通知を出力します。高可用性機能を使用するデバイスでは、フェイルオーバー時にプライマリとバックアップのルーティングエンジンを同期させる必要があります。ただし、非同期のコミット同期操作が中断され、一時的な設定を他のルーティングエンジンに同期できない場合があります。

Junos OSリリース21.1R1以降を実行しているデバイスおよびJunos OS Evolvedを実行しているデバイスでは、静的設定データベースで使用されるモデルと同様に、コミット同期操作に同期コミットモデルを使用するようにエフェメラルデータベースを設定できます。

デュアル ルーティング エンジンまたは MX シリーズ バーチャル シャーシ環境では、同期コミット モデルは次のように機能します。

1. プライマリ ルーティング エンジンは、エフェメラル インスタンスの初期コミット操作を開始します。
2. コミット操作中の特定の時点で、プライマリ ルーティング エンジンはバックアップ ルーティング エンジンでコミットを開始します。
3. バックアップ ルーティング エンジンが設定を正常にコミットした場合、プライマリ ルーティング エンジンはコミット操作を続行します。バックアップ ルーティング エンジンでコミットが失敗した場合、プライマリ ルーティング エンジンもコミットに失敗します。

手記：

EX シリーズのバーチャル シャーシが同期コミット モデルを使用する場合、プライマリ ルーティング エンジン ロールのメンバー スイッチが、最初に他のメンバーに対して同時にコミット操作を開始します。EX シリーズの仮想シャーシは多くのメンバーを持つことができるため、プライマリ スイッチは、別のメンバーでコミットに失敗した場合でも、コミット操作を続行します。

同期コミット操作は非同期コミット操作よりも低速ですが、ルーティング エンジン全体およびバーチャル シャーシ メンバー間でエフェメラル設定が同期されることが保証されます。したがって、同期コミット モデルでは、高可用性機能も使用するデバイス上で、より高い信頼性で一時的なデータベースを使用できます。

手記：

静的設定データベースの場合と同様に、同期コミット同期モデルを使用しても、まれにデバイスがバックアップのルーティング エンジンで更新された一時的な設定をコミットしても、プライマリ ルーティング エンジンではコミットを完了できず、設定が同期しなくなる場合があります。

一時的な設定データベースで同期コミット同期モデルを有効にするには、静的設定データベースの[edit system configuration-database ephemeral]階層レベルで commit-synchronize-model synchronous ステートメントを設定します。

Junos OSリリース20.2R1以降を実行しているデバイスやJunos OS Evolvedを実行しているデバイスも、一時データベースのフェイルオーバー設定同期をサポートしています。フェイルオーバー同期を設定し、バックアップのルーティングエンジンがプライマリルーティングエンジンと同期する場合(例えば、プライマリルーティングエンジンが新しく挿入されたとき、オンラインに戻ったとき、または役割の変更中に)、その静的設定データベースとエフェメラル設定データベースの両方が同期されます。以前のJunos OSリリースでは、バックアップ ルーティング エンジンは静的設定データベースのみを同期します。フェイルオーバー同期を有効にするには、静的構成データベースの[edit system]階層レベルで commit synchronize ステートメントを設定します。

手記：

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

Junos OSリリース21.1R1以降を実行するデバイスとJunos OS Evolvedを実行しているデバイスでは、コミット同期操作とフェイルオーバー同期操作の両方が、負荷オーバーライド操作の代わりに負荷更新操作を使用して、一時的な設定データを他のルーティングエンジンに同期します。load update操作を使用することで、デバイスはアップデート中に変更されたステートメントに対応するJunosプロセスにのみ通知する必要があるため、ネットワークへの中断を最小限に抑えることができます。

冗長ルーティングエンジン

デュアルルーティングエンジンシステムは、一時データベースの設定をサポートします。ただし、エフェメラル コミット モデルでは、コミット操作中にエフェメラル設定データがバックアップ ルーティング エンジンに自動的に同期されることはありません。クライアントアプリケーションは、コミットごとまたはセッションごとにエフェメラルインスタンス内のデータを同期することも、インスタンスがコミットされるたびにデータを自動的に同期するようにエフェメラルインスタンスを構成することもできます。詳細については、 NETCONF または Junos XML プロトコルを使用した一時的な設定データのコミットと同期を参照してください。

手記：

マルチシャーシ環境では、一時的な設定データベースを他のルーティングエンジンに同期させることはサポートされていません。

クライアントアプリケーションがエフェメラルインスタンスでデータをコミットし、バックアップルーティングエンジンに同期すると、デフォルトでは、エフェメラルデータベースはコミット同期操作を非同期的に実行します。コミット同期操作に同期コミットモデルを使用するように一時データベースを設定できます。さらに、デュアルルーティングエンジンデバイスは、Junos OSリリース20.2R1以降、エフェメラルデータベースのフェイルオーバー設定同期もサポートしています。詳細については、「 エフェメラル データベース コミット同期モデルについて」を参照してください。

グレースフル ルーティング エンジン スイッチオーバー(GRES)

グレースフル ルーティング エンジン スイッチオーバーにより、冗長ルーティング エンジンを搭載したデバイスは、1 つのルーティング エンジンに障害が発生した場合でも、パケットの転送を継続できます。GRES では、スイッチオーバーが発生する前に、プライマリとバックアップのルーティング エンジンが設定と特定の状態情報を同期させる必要があります。

既定では、エフェメラル データベースはコミット同期操作を非同期的に実行します。Junos OSリリース21.1R1以降を実行しているサポート対象デバイスおよびJunos OS Evolvedを実行しているデバイスでは、 エフェメラルデータベースコミット同期モデルについての説明に従って、同期コミットモデルを使用してコミット同期操作を実行するようにエフェメラルデータベースを設定できます。コミット時間に厳密な要件がないデバイスでは、GRES が有効になっているデバイスで同期コミットモデルを使用することを推奨します。同期コミット操作は非同期コミット操作よりも低速ですが、ルーティング エンジン間でエフェメラル構成を同期させる保証が高くなります。したがって、このコミットモデルでは、GRES が有効になっているデバイス上で信頼性の高い一時的なデータベースを使用できます。

手記：

Junos OS Evolvedを実行するデュアルルーティングエンジンデバイスは、デフォルトでGRESを有効にします。

GRES が有効になっているデバイスでは、非同期コミット同期モデルでエフェメラルデータベースを使用することはお勧め しません 。状況によっては、スイッチオーバーが発生したときにプライマリルーティングエンジンとバックアップルーティングエンジン間でエフェメラルデータベースが同期されないことがあるからです。例えば、突然の停電によってコミット同期操作が中断された場合、バックアップとプライマリのルーティングエンジンはエフェメラルデータベースを同期しないことがあります。さらに、Junos OS Release 20.1以前を実行しているデバイスでは、バックアップルーティングエンジンがその設定をプライマリルーティングエンジンと同期させるときに、一時的な設定データベースは同期されません。そのため、たとえばバックアップのルーティング エンジンが再起動すると、一時的な設定データが削除されますが、このデータは再起動しても保持されず、オンラインになったときにデータベースが自動的に同期し直すことはありません。その結果、スイッチオーバーが発生したときに、バックアップとプライマリルーティングエンジンの間でエフェメラルデータベースが同期されない可能性があります。

GRES が有効で、エフェメラルデータベースが非同期コミットモデル(デフォルト)を使用している場合、エフェメラル設定データをバックアップルーティングエンジンに同期させるために、デバイスを明示的に設定する必要があります。同期を有効にするには、静的構成データベースの[edit system configuration-database ephemeral]階層レベルで allow-commit-synchronize-with-gres ステートメントを構成します。GRES が有効で、allow-commit-synchronize-with-gres ステートメントを設定していない場合、非同期コミットモデルを使用するデバイスは、そのインスタンスでコミット同期操作をリクエストしても、エフェメラルインスタンスをバックアップルーティングエンジンに同期しません。

ノンストップ アクティブ ルーティング(NSR)

既定では、エフェメラル データベースはコミット同期操作を非同期的に実行します。Junos OSリリース21.1R1以降を実行しているサポート対象デバイスおよびJunos OS Evolvedを実行しているデバイスでは、 エフェメラルデータベースコミット同期モデルについての説明に従って、同期コミットモデルを使用してコミット同期操作を実行するようにエフェメラルデータベースを設定できます。ノンストップ アクティブ ルーティング(NSR)が有効になっているデバイスでは、同期コミット モデルを使用することをお勧めします。同期コミット操作は非同期コミット操作よりも低速ですが、ルーティング エンジン間でエフェメラル構成を同期させる保証が高くなります。したがって、このコミットモデルでは、NSRが有効になっているデバイス上でより高い信頼性で一時的なデータベースを使用できます。

NSRが有効になっているデバイスで非同期コミット同期モデルとともに一時データベースを使用することは、特定の注意点があるため、お勧め しません 。デュアルルーティングエンジンを使用する展開では、プライマリルーティングエンジン上の一時インスタンスに対するコミット同期操作は、バックアップルーティングエンジン上で非同期コミットになります。コンフィギュレーションの更新プロセスでデバイスがルーティングプロトコルプロセス(rpd)に通知すると、バックアップルーティングエンジンでのコミットが非同期であるため、システムが望ましくない動作をする可能性があります。

エフェメラルインスタンスがバックアップルーティングエンジンに同期されたときに通知されるプロセスは、Junos OSのリリースによって異なります。Junos OS Release 20.4以前では、プライマリルーティングエンジンでエフェメラルインスタンスを更新すると、バックアップルーティングエンジンの変更によってエフェメラルインスタンスの設定全体が上書きされ、最新のインスタンスに置き換えられます。Junos OS リリース 20.1 以前では、バックアップのルーティングエンジンに新しい設定が適用されると、Junos OS はその一時的なインスタンスにステートメントを持つすべてのシステムプロセスに通知します。Junos OS Release 20.2R1 以降、一時データベースの動作が強化されました。プライマリとバックアップのルーティングエンジン間でエフェメラルインスタンスがすでに同期されている場合、プライマリルーティングエンジンでエフェメラルインスタンスを更新した場合、Junos OSはバックアップルーティングエンジンで変更をコミットしたときにのみ、エフェメラルインスタンス設定の変更された部分に対応するプロセスにのみ通知します。Junos OS Release 21.1R1以降、デバイスは、負荷オーバーライド操作ではなく、負荷更新操作を使用してエフェメラルインスタンスをバックアップルーティングエンジンに同期させるため、変更されたステートメントに対応するプロセスにのみ通知します。

手記：

一時的なデータベースを使用するアプリケーションは、ルーティングプロトコルプロセスと対話する場合にのみ、このNSR状況で影響を受けます。たとえば、SmartWall Threat Defense Director(SmartWall TDD)は、一時的なデータベースを介してファイアウォールプロセス(dfwd)とのみ対話するため、この場合は影響を受けません。

MXシリーズバーチャルシャーシ

Junos OSリリース20.2R1以降、MXシリーズバーチャルシャーシは、エフェメラルデータベースの設定をサポートしています。エフェメラルインスタンスの設定およびコミットは、バーチャルシャーシプライマリデバイスのプライマリルーティングエンジンでのみ可能です。

MX シリーズの仮想シャーシは、コミット操作中に一時的な設定データを自動的に同期しません。デュアルルーティングエンジンシステムと同様に、コミットごとまたはセッションごとにエフェメラルインスタンス内のデータを同期したり、インスタンスがコミットされるたびにデータを自動的に同期するようにエフェメラルインスタンスを設定することができます。エフェメラルデータは、プライマリデバイス上のプライマリルーティングエンジンからバックアップデバイス上のプライマリルーティングエンジンにのみ同期されます。

手記：

MXシリーズバーチャルシャーシは、いかなる状況においても、プライマリルーティングエンジンから各バーチャルシャーシメンバーのバックアップルーティングエンジンに一時的な設定データを同期させません。

MXシリーズのバーチャルシャーシには、GRESが設定されている必要があります。同期コミット同期モデルを使用するようにエフェメラルデータベースを設定すると、コミット同期操作をリクエストすると、デバイスはエフェメラルインスタンスを他のルーティングエンジンに同期させます。ただし、エフェメラル データベースで非同期コミット同期モデル(デフォルト)を使用している場合、静的構成データベースで allow-commit-synchronize-with-gres ステートメントを明示的に設定して、同期を有効にする必要があります。エ フェメラルデータベースコミットモデルの詳細については、エフェメラルデータベースコミット同期モデル についてを参照してください。

非同期コミット同期モデルを使用するMXシリーズ仮想シャーシ上で、一時インスタンスをコミットして同期する場合:

1. バーチャルシャーシプライマリデバイスは、設定構文を検証し、プライマリルーティングエンジンにエフェメラルインスタンスをコミットします。

2. コミットが成功すると、プライマリデバイスはバックアップデバイスにエフェメラルインスタンスを同期するように通知します。

3. バックアップ デバイスは、プライマリ ルーティング エンジンでのみエフェメラル インスタンスをコミットします。コミット操作が失敗した場合、バックアップ デバイスはシステム ログ ファイルにメッセージを記録しますが、プライマリ デバイスには通知しません。

同期コミット同期モデルを使用するように設定されたMXシリーズ仮想シャーシ上で、エフェメラルインスタンスをコミットして同期する場合:

1. バーチャルシャーシのプライマリデバイスは、プライマリルーティングエンジン上でエフェメラルインスタンスのコミットを開始します。

2. コミット操作のある時点で、プライマリ デバイスはバックアップ デバイスのプライマリ ルーティング エンジンでコミットを開始します。

3. バックアップ デバイスが設定を正常にコミットすると、プライマリ デバイスはコミット操作に進みます。バックアップ デバイスが設定のコミットに失敗した場合、プライマリ デバイスもコミットに失敗します。

説明したように、一時データベースで非同期コミット同期モデルを使用すると、プライマリ デバイスではコミットが成功しても、バックアップ デバイスでは失敗する可能性があります。同期コミット同期モデルを使用する場合、まれな状況を除き、両方のプライマリ ルーティング エンジンでコミットが成功または失敗します。

MXシリーズバーチャルシャーシは、一時データベースのフェイルオーバー設定同期をサポートします。静的設定データベースの[edit system]階層レベルで commit synchronize ステートメントを設定し、バーチャル シャーシ バックアップ デバイス上のプライマリ ルーティング エンジンがバーチャル シャーシ プライマリ デバイス上のプライマリ ルーティング エンジンと同期する場合(再起動後など)、その静的設定データベースとエフェメラル設定データベースの両方が同期します。

手記：

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

EXシリーズバーチャルシャーシ

EXシリーズバーチャルシャーシは、一時的な設定データベースをサポートします。エフェメラルインスタンスの設定およびコミットは、プライマリルーティングエンジンロールのメンバースイッチでのみ可能です。Junos OSリリース23.4R1以降、EXシリーズのバーチャルシャーシメンバー間でエフェメラルデータベースを同期できます。

EX シリーズのバーチャル シャーシは、コミット操作中に一時的な設定データを自動的に同期しません。エフェメラルインスタンス内のデータをコミットごとまたはセッションごとに同期することも、インスタンスがコミットされるたびにデータを自動的に同期するようにエフェメラルインスタンスを設定することもできます。

EXシリーズバーチャルシャーシにGRESを設定することで、プライマリルーティングエンジンに障害が発生した場合でも、バーチャルシャーシでパケットの転送を継続することができます。同期コミット同期モデルを使用するように一時データベースを構成すると、コミット同期操作が要求されると、デバイスは一時インスタンスを他のメンバーと同期します。ただし、エフェメラルデータベースが非同期コミット同期モデル(デフォルト)を使用し、GRES が設定されている場合、静的設定データベースで allow-commit-synchronize-with-gres ステートメントを明示的に設定して、同期を有効にする必要があります。

非同期コミット同期モデルを使用するEXシリーズ仮想シャーシ上で、一時インスタンスをコミットして同期する場合:

1. プライマリ ルーティング エンジン ロールのメンバー スイッチは、設定構文を検証し、エフェメラル インスタンスをコミットします。

2. コミットが成功すると、プライマリデバイスから commit-syncd プロセスに通知され、各メンバースイッチでコミットが順番に開始されます。

3. 各メンバースイッチは、一時的なインスタンスをコミットします。いずれかのメンバーでコミット操作が失敗しても、他のメンバーのコミット操作には影響しません。

同期コミット同期モデルを使用するように設定されたEXシリーズ仮想シャーシ上で、一時インスタンスをコミットして同期する場合:

1. プライマリ ルーティング エンジン ロールのメンバー スイッチは、すべてのメンバー スイッチで同時にコミットを開始します。

2. 各メンバースイッチは、一時インスタンスをコミットし、プライマリスイッチに通知します。いずれかのメンバーでコミット操作が失敗しても、他のメンバーのコミット操作には影響しません。

3. すべてのメンバースイッチから応答を受信した後、プライマリスイッチは一時インスタンスをコミットします。

このように、非同期モデルでは、プライマリスイッチは commit-syncd プロセスに依存して、各メンバースイッチでコミットを順次開始します。何らかの理由で commit-syncd プロセスが失敗すると、一部のコミットが開始されない可能性があります。同期コミット モデルでは、プライマリ スイッチがすべてのメンバー スイッチ上で直接かつ並列にコミットを開始します。したがって、一般に、同期コミット モデルは非同期コミット モデルよりも信頼性が高くなります。いずれの場合も、1 つのメンバーでコミットが失敗しても、他のメンバーのコミットに影響を与えたり、妨げたりすることはありません。

さらに、同期コミット モデルでは、プライマリ スイッチは、コミットが発生するたびに各メンバーのコミットの進行状況を表示します。非同期モデルでは、コミットはバックグラウンドで行われるため、この場合、プライマリデバイスはコミット結果のみを記録します。

コミット頻度の調整

エフェメラルデータベースは、より高速なコミットのために設計されています。ただし、コミットの頻度が高すぎると、構成を使用するアプリケーションがコミット操作の速度に追いつかない場合に問題が発生する可能性があります。そのため、デバイスの運用状態に前回のコミットでの変更が反映された後にのみ、次の変更セットをコミットすることを推奨します。

例えば、頻繁に迅速なコミットを実行すると、Junosプロセスが以前のアップデートを読み取る前に、外部ファイルに保存されている特定の設定データをデバイスが上書きする可能性があります。Junosプロセスが重要なアップデートを見逃した場合、デバイスまたはネットワークで予測不能な動作が発生する可能性があります。

データ整合性の確保

Junosデバイスは、一時的なデータベースにデータをコミットするときに、設定データのセマンティクスを検証しません。そのため、設定を読み込んでコミットする前に、データの整合性を確保するために追加の手順を実行する必要があります。常に次のことをお勧めします。

• データベースにロードする前に構成データを検証する

• 関連する構成ステートメントを 1 つのデータベースに統合

エフェメラルデータベースにロードする前に、すべての構成データを検証する必要があります。構文とセマンティクスの両方を検証する静的データベースを使用して、構成データを事前検証することをお勧めします。

さらに、関連する構成データを常に 1 つのデータベースに読み込む必要があります。同じデータベースに関連または依存する設定データを追加することで、デバイスはコミット操作中に関連するステートメントを確実に検出して処理することができます。例えば、静的設定データベースまたは一時的な設定データベースでファイアウォールフィルターを定義する場合、同じ設定データベース内のインターフェイスにフィルターの適用を設定する必要があります。

対照的に、静的データベースでは一部のステートメントを設定し、一時データベースでは関連ステートメントまたは依存ステートメントを設定するとします。静的データベースをコミットすると、システムはそのデータベース内のデータのみを検証します。システムが一時データベース内の依存構成を識別しない場合があり、検証、ひいてはコミットが失敗する可能性があります。

拡張構成の統合

スケーリングされた構成は、複数のデータベースに分散するのではなく、単一の一時的なデータベースインスタンスにロードすることをお勧めします。拡張された構成には、たとえば、次の大規模なリストが含まれる場合があります。

• ポリシーのオプション

• プレフィックスリスト

• VLAN

• ファイアウォールフィルター

最上位の構成階層を単一のデータベースに制限すると、内部最適化により、Junos プロセスが構成をより効率的に使用できるようになります。また、構成を複数のデータベースに分散させる場合、Junosプロセスは構成のマージされたビューを解析する必要があり、通常、より多くのリソースと処理時間が必要になります。