一時的な設定データベースを理解する
一時的なデータベースは、Junos OSおよびJunos OS Evolvedを実行するデバイスで設定更新を実行するための高速なプログラムインターフェイスを提供する代替の設定データベースです。一時的なデータベースにより、Juniper Extension Toolkit(JET)アプリケーションと NETCONF および Junos XML 管理プロトコル クライアント アプリケーションは、デバイスに対する設定変更を同時に読み込み、コミットでき、候補の構成データベースにデータをコミットする場合よりも大幅に高いスループットを実現できます。
以下のセクションでは、一時的な設定データベースのさまざまな側面について説明します。
一時的な設定データベースのメリット
- 一時的なデータベースの個別のインスタンスにデータを読み込み、コミットすることで、複数のクライアントアプリケーションがデバイスを同時に設定できるようにします。
- 迅速なコミット時間を必要とする動的な環境で、迅速なプロビジョニングと迅速な設定変更が可能
一時的な設定データベースの概要
Junos デバイスを管理する場合、デバイスの設定に推奨される最も一般的な方法は、永続的(静的)な設定データベースに対応する候補の設定を変更してコミットすることです。標準的なコミット操作は、設定グループ、マクロ、コミットスクリプトを処理します。は、コミットチェックを実行して、設定の構文とセマンティクスを検証します。コミットされた設定のコピーを保存します。標準のコミット モデルは、設定エラーを防ぎ、以前にコミットされた設定にロールバックできるため、堅牢です。ただし、場合によっては、コミット操作にかなりの時間とデバイス リソースが消費される場合があります。
JET アプリケーション、NETCONF、Junos XML プロトコル クライアント アプリケーションも一時的なデータベースを構成できます。一時的なデータベースは、候補の構成データベースと他のクライアント アプリケーションの構成レイヤーの両方から分離された構成レイヤーを提供する代替の構成データベースです。一時的なコミットモデルにより、Junosデバイスは、複数のクライアントからの変更をコミットしてマージし、受験者の構成データベースにデータをコミットする場合よりも大幅に高いスループットでコミットを実行できます。したがって、一時的なデータベースは、大規模なデータ センターなど、迅速なプロビジョニングや迅速な設定変更が必要な動的な環境に有利です。
一時的なデータベースに対するコミット操作は、静的データベースに必要な同じ検証の対象ではないため、静的データベースに対する同じ操作よりも短い時間で済みます。その結果、一時的なコミット モデルは、標準的なコミット モデルよりもパフォーマンスが高くなりますが、標準モデルに存在するより堅牢な機能の一部を犠牲にしています。一時的なコミット モデルには、以下の制限があります。
-
構成データ構文は検証されますが、構成データセマンティックは検証されません。
-
一時的な設定データベースのサポートされていない設定ステートメントで説明されているように、特定の設定ステートメントはサポートされていません。
-
設定グループとインターフェイス範囲は処理されません。
-
マクロ、コミット スクリプト、および変換スクリプトは処理されません。
-
一時的なコンフィギュレーションの以前のバージョンはアーカイブされません。
-
一時的な設定データは、再起動しても持続しません。
-
OpenConfig や YANG パッケージなど、Junos スキーマの再構築を必要とするパッケージをインストールしても、一時的な設定データは持続しません。
-
標準 show コマンドを使用すると、通常の設定では一時的な設定データは表示されません。
一時的な設定データベースを使用する場合は、無効な設定データをコミットすると一時的なデータベースが破損する可能性があり、Junos プロセスが再起動したり、クラッシュしたりしてシステムやネットワークが中断する可能性があるため、注意してください。
Junosデバイスは、一時的なデータベースにコミットされた設定データのシンタックス(セマンティクス)や制約は検証しません。たとえば、設定が未定義のルーティングポリシーを参照している場合、設定は構文的に正しいかもしれませんが、セマンティックに正しくありません。この場合、標準コミット モデルではコミット エラーが生成されますが、一時的なコミット モデルは生成されません。したがって、一時的なデータベースにコミットする前に、すべての設定データを検証する必要があります。無効な設定データや望ましくないネットワーク中断が発生する設定データをコミットした場合、データベースから問題のあるデータを削除する必要があります。また、必要に応じてデバイスを再起動して、一時的な設定データをすべて削除する必要があります。
一時的な設定データベースには、設定データに加えて内部バージョン情報が格納されます。その結果、一時的な構成データベースのサイズは、同じ設定データの静的構成データベースよりも常に大きく、追加、変更、削除など、一時的なデータベースの操作の大半は、データベースのサイズを大きくします。
一時的な構成データベースを使用する場合、静的構成データベースに対するコミット操作に時間がかかる場合があります。静的構成データと一時的な構成データをマージするには追加の操作を実行する必要があるためです。
一時的なデータベース インスタンス
Junosデバイスは、デフォルトの一時的なデータベースインスタンスを自動的に有効にするとともに、一時的な設定データベースのユーザー定義インスタンスを有効にする機能を提供します。JET アプリケーションと NETCONF および Junos XML プロトコル クライアント アプリケーションは、同時にデータを読み込み、一時的なデータベースの個別のインスタンスにコミットできます。アクティブなデバイス構成は、静的および一時的な構成データベースの統合ビューです。
Junos OSリリース18.2R1以降、Junos OSは一時的な設定データベースの最大7つのユーザー定義インスタンスの設定をサポートしています。以前のリリースでは、最大8つのユーザー定義インスタンスを設定できます。Junos OS Evolvedは、8つのユーザー定義インスタンスの設定をサポートしています。
一時的なデータベース インスタンスは、2 つ以上の SDN コントローラが同時に設定データを同じデバイスにプッシュする場合など、複数のクライアント アプリケーションでデバイス設定を同時に更新する必要がある場合に便利です。標準コミット モデルでは、1 つのコントローラーが候補構成に排他的ロックを付ける可能性があるため、もう一方のコントローラーでは変更できません。個別の一時的なインスタンスを使用することで、コントローラは変更を同時に導入できます。
アプリケーションは、静的な設定データベースに加えて、異なる一時的なデータベース インスタンスに同時にデータを読み込み、コミットできます。ただし、デバイスはコミットを順次処理します。その結果、処理順序に応じて、特定のデータベースへのコミットが遅れる場合があります。
Junos プロセスは、静的構成データベースと一時的な構成データベースの両方から構成データを読み取ります。1 つ以上の一時的なデータベース インスタンスが使用され、データが競合している場合、優先順位の高いデータベース内のステートメントは、優先度の低いデータベース内のステートメントを上書きします。データベースの優先度は、最大から最小までを以下の通りです。
-
一時的な設定データベースのユーザー定義インスタンス内のステートメント。
複数のユーザー定義一時的なインスタンスがある場合、優先度は、優先度が最高から最も低い順に実行され、 階層レベルで
[edit system configuration-database ephemeral]インスタンスが設定された順序によって決定されます。 -
デフォルトの一時的なデータベースインスタンスのステートメント。
-
静的な設定データベース内のステートメント。
以下の設定を検討してください。
system {
configuration-database {
ephemeral {
instance 1;
instance 2;
}
}
}
図 1 は、一時的なデータベース インスタンスと静的(コミット)設定データベースの優先度の順序を示しています。この例では、一時的なデータベース インスタンス 1 の優先度が最も高く、次に一時的なデータベース インスタンス 2、次にデフォルトの一時的なデータベース インスタンス、最後に静的構成データベースが続きます。
一時的なデータベースの一般的なコミット モデル
JET アプリケーションと NETCONF および Junos XML プロトコル クライアント アプリケーションは、一時的な設定データベースを変更できます。JET アプリケーションは、ロード操作とコミット操作のペアとして構成要求を送信する必要があります。NETCONF および Junos XML プロトコル クライアント アプリケーションは、コミット操作を実行する前に複数の負荷操作を実行できます。
無効な設定データをコミットすると、Junosプロセスが再起動したり、システムやネットワークが中断したりする可能性があるため、すべての設定データを一時的なデータベースに読み込んでデバイス上でコミットする前に、すべての設定データを検証する必要があります。
クライアント アプリケーションは、一時的なデータベースの異なるインスタンスにデータを同時に読み込み、コミットできます。異なる一時的なインスタンスに対して同時に発行されたコミットは、デバイスによってキューに入れ、シリアルに処理されます。クライアントがセッションから切断された場合、デバイスは一時的なインスタンスでコミットされていない設定変更を破棄しますが、そのクライアントによって一時的なインスタンスにすでにコミットされている設定データには影響はありません。
一時的なインスタンスをコミットすると、システムは一時的な設定データの構文を検証しますが、セマンティックは検証しません。コミットが完了すると、デバイスは影響を受けるシステム プロセスに通知します。プロセスは更新された設定を読み取り、一時的なデータベース インスタンスで説明されている優先順位付けのルールに従って 一時的なデータをアクティブなコンフィギュレーションにマージします。アクティブなデバイス構成は、静的および一時的な構成データベースの統合ビューです。
一時的なデータベースのコミット時間は、2つのオペレーティングシステムのアーキテクチャ上の違いにより、Junos OSを実行するデバイスよりもJunos OS Evolvedを実行しているデバイスよりもわずかに長くなります。
一時的な設定データベースのインスタンスのコミットと同期の詳細については、 NETCONF または Junos XML プロトコルを使用した一時的な設定データのコミットと同期を参照してください。
高可用性機能を使用するデバイスでの一時的なデータベースの使用
高可用性 とは、ネットワーク通信に冗長性と信頼性を提供するハードウェアおよびソフトウェア コンポーネントのことです。バーチャル シャーシを使用する MX シリーズ ルーターでは、冗長ルーティング エンジン、グレースフル ルーティング エンジン スイッチオーバー(GRES)、ノンストップ アクティブ ルーティング(NSR)、シャーシ間の冗長性など、高可用性機能を使用するシステムで一時的なデータベースを使用する前に考慮すべきいくつかの動作や注意点があります。以下のセクションでは、これらの動作について説明し、さまざまな一時的なデータベース コミット 同期モデルがこれらの動作に影響を与える方法について概要を説明します。
- 一時的なデータベース コミット同期モデルについて
- 冗長ルーティング エンジン
- グレースフル ルーティング エンジン スイッチオーバー(GRES)
- ノンストップ アクティブ ルーティング(NSR)
- MXシリーズバーチャルシャーシ
一時的なデータベース コミット同期モデルについて
標準的なコミット モデルとは異なり、既定の一時的なコミット モデルはコミット同期操作を非同期で実行します。要求するルーティングエンジンは一時的な設定をコミットし、他のルーティングエンジンが最初に設定を同期してコミットするのを待つことなく、コミット完了通知を発行します。高可用性機能を使用するデバイスでは、フェイルオーバーの場合にプライマリおよびバックアップのルーティング エンジンを同期する必要があります。ただし、非同期コミット同期操作を中断して一時的な設定を他のルーティング エンジンに同期できない場合があります。
Junos OSリリース21.1R1以降を実行するデバイスとJunos OS Evolvedを実行しているデバイスでは、静的設定データベースと同様に、同期コミットモデルを使用してコミット同期操作を実行するように一時的なデータベースを設定できます。同期コミット モデルでは、以下を実行します。
- プライマリ ルーティング エンジンは、一時的なインスタンスの最初のコミット操作を開始します。
- コミット操作中の特定のポイントで、プライマリ ルーティング エンジンがバックアップ ルーティング エンジンでコミットを開始します。
- バックアップルーティングエンジンが設定に正常にコミットした場合、プライマリルーティングエンジンはコミット操作を続行します。バックアップルーティングエンジンのコミットに失敗した場合、プライマリルーティングエンジンもコミットに失敗します。
同期コミット操作は非同期コミット操作よりも遅くなりますが、ルーティング エンジン間で一時的な設定を同期する方が優れた保証を提供します。同期コミット モデルでは、高可用性機能も使用するデバイスで一時的なデータベースをより信頼性の高い方法で使用できます。
静的設定データベースの場合と同様に、同期コミット同期同期モデルを使用している場合でも、デバイスがバックアップ ルーティング エンジンで更新された一時的な設定をコミットしても、プライマリ ルーティング エンジンのコミットを完了できず、設定が同期されないというまれな状況が発生する可能性があります。
一時的な設定データベースの同期コミット同期モデルを有効にするには、 commit-synchronize-model synchronous 静的設定データベースの 階層レベルで [edit system configuration-database ephemeral] ステートメントを設定します。
Junos OSリリース20.2R1以降を実行するデバイスとJunos OS Evolvedを実行しているデバイスは、一時的なデータベースのフェイルオーバー設定同期もサポートしています。フェイルオーバー同期を設定し、バックアップのルーティング エンジンがプライマリ ルーティング エンジンと同期する場合(たとえば、新しく挿入した場合、オンラインに戻す場合、またはロールの変更時に)、静的な設定データベースと一時的な設定データベースの両方を同期します。以前のJunos OSリリースでは、バックアップのルーティングエンジンは静的な設定データベースのみを同期します。フェイルオーバー同期を有効にするには、静的構成 commit synchronize データベースの [edit system] 階層レベルで ステートメントを設定します。
Junos OSリリース21.1R1以降を実行するデバイスとJunos OS Evolvedを実行しているデバイスでは、コミットが操作を同期し、フェイルオーバーが一時的な設定データをロードオーバーライド操作ではなく負荷更新操作を使用して他のルーティングエンジンに同期します。デバイスは、負荷更新操作を使用して、アップデート中に変更されたステートメントに対応する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 リリース 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リリース20.4以前では、プライマリルーティングエンジンで一時的なインスタンスを更新すると、バックアップルーティングエンジンの変更が一時的なインスタンスの完全な設定を上書きし、最新のインスタンスに置き換えます。Junos OSリリース20.1以前では、新しい設定がバックアップルーティングエンジンに適用されると、Junos OSはその一時的なインスタンスにステートメントを持つすべてのシステムプロセスに通知します。Junos OS リリース 20.2R1 以降、一時的なデータベースの動作が強化されました。一時的なインスタンスがプライマリルーティングエンジンとバックアップルーティングエンジンの間で既に同期されており、プライマリルーティングエンジン上の一時的なインスタンスを更新する場合、Junos OSは、バックアップルーティングエンジンに変更をコミットしたときに、一時的なインスタンス設定の変更部分に対応するプロセスのみを通知します。Junos OS リリース 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 シリーズバーチャル シャーシ上の一時的なインスタンスをコミットして同期すると、モデルが同期されます。
-
バーチャル シャーシ プライマリ デバイスは構文を検証し、プライマリ ルーティング エンジンで一時的なインスタンスをコミットします。
-
コミットが成功した場合、プライマリ デバイスはバックアップ デバイスに一時的なインスタンスを同期するよう通知します。
-
バックアップ デバイスは、プライマリ ルーティング エンジンでのみ一時的なインスタンスをコミットします。コミット操作に失敗した場合、バックアップ デバイスはメッセージをシステム ログ ファイルに記録しますが、プライマリ デバイスには通知しません。
同期コミット同期同期モデルを使用するように設定された MX シリーズ仮想シャーシ上の一時的なインスタンスをコミットして同期する場合。
-
バーチャル シャーシ プライマリ デバイスは、プライマリ ルーティング エンジンで一時的なインスタンスのコミットを開始します。
-
コミット操作の特定のポイントで、プライマリデバイスはバックアップデバイスのプライマリルーティングエンジンでコミットを開始します。
-
バックアップ デバイスが設定を正常にコミットした場合、プライマリ デバイスはコミット操作を続行します。バックアップデバイスが設定のコミットに失敗した場合、プライマリデバイスもコミットに失敗します。
前述のように、一時的なデータベースに非同期コミット同期モデルを使用すると、プライマリ デバイスでコミットは成功しても、バックアップ デバイスでは失敗します。同期コミット同期同期モデルを使用する場合、まれな状況を除き、両方のプライマリ ルーティング エンジンのコミットに成功または失敗します。
MXシリーズバーチャルシャーシは、一時的なデータベースのフェイルオーバー設定同期をサポートします。静的設定データベースの 階層レベルで ステートメントをcommit synchronize[edit system]設定し、バーチャルシャーシバックアップデバイスのプライマリルーティングエンジンが、例えば再起動後にバーチャルシャーシプライマリデバイス上のプライマリルーティングエンジンと同期する場合、そのステートメントは静的構成データベースと一時的な設定データベースの両方を同期します。
一時的なデータベースのベスト プラクティス
一時的な設定データベースにより、複数のアプリケーションで同時に設定変更を迅速に行うことができます。一時的な設定データベースは静的構成データベースと同じ保護手段を使用しないため、一時的なデータベースの使用方法を慎重に検討する必要があります。これらのベスト プラクティスに従って、パフォーマンスを最適化し、一時的な設定データベースを使用する際に潜在的な問題を回避することをお勧めします。
コミット頻度を調整
一時的なデータベースは、より迅速なコミットのために設計されています。ただし、頻繁にコミットすると、設定を消費するアプリケーションがコミット操作の速度に追いつかない場合、問題が発生する可能性があります。そのため、デバイスの運用状態が以前のコミットからの変更を反映した後にのみ、次の変更セットをコミットすることをお勧めします。
たとえば、頻繁に迅速なコミットを実行した場合、Junos プロセスが以前の更新を読み取る前に、デバイスが外部ファイルに保存している特定の設定データが上書きされる可能性があります。Junos プロセスが重要な更新を見逃した場合、デバイスやネットワークが予期しない動作を示す可能性があります。
データ整合性の確保
一時的なデータベースにデータをコミットしても、Junosデバイスは設定データセマンティックを検証しません。そのため、データ整合性を確保するために、設定を読み込んでコミットする前に、さらに手順を実行する必要があります。常に以下を推奨します。
-
データベースに読み込む前に設定データを検証する
-
関連する設定ステートメントを単一のデータベースに統合
一時的なデータベースに読み込む前に、すべての設定データを検証する必要があります。構文とセマンティクスの両方を検証する静的データベースを使用して、設定データを事前に検証することをお勧めします。
さらに、関連する設定データを常に 1 つのデータベースに読み込む必要があります。関連するまたは依存する設定データを同じデータベースに追加することで、コミット操作中にデバイスが関連ステートメントを検出して処理できるようになります。例えば、静的構成データベースまたは一時的な設定データベースでファイアウォールフィルターを定義する場合、同じ設定データベース内のインターフェイスにフィルターのアプリケーションを設定する必要があります。
これに対して、静的データベースにいくつかのステートメントを設定し、一時的なデータベースに関連または依存ステートメントを設定するとします。静的データベースをコミットすると、システムはそのデータベース内でのみデータを検証します。システムは一時的なデータベース内の依存構成を識別できず、検証が失敗し、コミットが失敗する可能性があります。
拡張された設定の統合
スケーリングされた設定は、複数のデータベースに分散するのではなく、1 つの一時的なデータベース インスタンスに読み込むことをお勧めします。拡張構成には、例えば、以下の大規模リストが含まれる場合があります。
-
ポリシー オプション
-
プレフィックスリスト
-
Vlan
-
ファイアウォール フィルター
トップレベルの設定階層を単一のデータベースに制限すると、内部の最適化により、Junos プロセスで設定をより効率的に使用できるようになります。または、複数のデータベースに構成を分散させる場合、Junos プロセスはマージされた構成のビューを解析する必要があります。一般的には、より多くのリソースと処理時間が必要になります。
[edit system] ステートメントを
commit synchronize設定し、バックアップルーティングエンジンがプライマリルーティングエンジンと同期する場合(たとえば、新しく挿入された場合、オンラインに戻された場合、ロールの変更中など)、静的な設定データベースと一時的な設定データベースの両方が同期されます。