設定をコミット

デバイスのコンフィギュレーションは、コミットモデルを使用して保存されます。－コンフィギュレーションの候補は、必要に応じて修正され、システムにコミットされます。コンフィギュレーションがコミットされると、デバイスはコンフィギュレーションのシンタックス・エラーをチェックします。エラーが見つからなければ、コンフィギュレーションをとしてそのまま保存し、アクティベートjuniper.conf.gzします。以前アクティブだったコンフィギュレーション・ファイルは、最初のロールバック・コンフィギュレーション・ファイル（juniper.conf.1.gz）として保存され、他のロールバック・コンフィギュレーション・ファイルは1つ増分されます。例えば、juniper.conf.1.gzは、juniper.conf.2.gzに増分され、2番目のロールバック・コンフィギュレーション・ファイルになります。システム上、デバイスに保存できるロールバック・コンフィギュレーションは最大49個（1～49の番号）です。

デバイス上では、現在のコンフィギュレーション・ファイルと最初の3つのロールバック・ファイル(juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3)がというディレクト/configリに配置されています。（残りのロールバック・ファイル4から49は、/var/db/configに格納されています。）

リカバリー・コンフィギュレーション・ファイルがrescue.conf.gz存在する場合、このファイルもというディレクト/configリに配置されます。工場出荷時のファイルは、この/etc/configというディレクトリにあります。

デバイス内のルーティング・エンジン間でコンフィギュレーションを伝達するために、2つのメカニズムが使用されます：

• 同期：あるルーティング・エンジンから、同じデバイス・シャーシ内の2番目のルーティング・エンジンにコンフィギュレーションを伝播させます。

  コンフィギュレーションを同期させるには、というCcommit synchronizeLIコマンドを使用します。ルーティング・エンジンの1つがロックされている場合、同期に失敗します。コンフィギュレーション・ファイルがロックされているために同期に失敗した場合、commit synchronize forceというコマンドを使用することができます。このコマンドはロックを無効にし、コンフィギュレーション・ファイルを同期させます。

• 配信：マルチシャーシ・デバイスのルーティング・プレーン全体にコンフィギュレーションを伝搬します。配信は自動的に行われます。配信処理を制御するためのユーザー・コマンドは用意されていません。コンフィギュレーションの配信中にコンフィギュレーションがロックされた場合、ロックされたコンフィギュレーションは配信されたコンフィギュレーション・ファイルを受け取らないため、同期に失敗します。コンフィギュレーションの前にロックを解除し，ルーティング・プレーンを再同期させる必要があります。

  注:

  マルチシャーシ・プラットフォームでcommit synchronize forceというCLIコマンドを使用する場合，コンフィギュレーション・ファイルの強制同期がルーティング・プレーン全体のコンフィギュレーション・ファイルの配信に影響することはありません。コマンドを発行したデバイスから離れたデバイス上で、コンフィギュレーション・ファイルがロックされている場合、離れたデバイスでの同期に失敗します。ロックを解除して、synchronizationというコマンドを再発行する必要があります。

デバイス・コンフィギュレーションの変更をコンフィグレーション・データベースに保存し、デバイス上でコンフィグレーションを有効にするには、commitというコンフィギュレーション・モード・コマンドを使用します。どの階層からでもコマcommitンドを発行することができます：

commitというコマンドを入力すると、まずコンフィギュレーションにシンタックスエラー（commit check）がないかチェックされます。その後、シンタックスが正しければ、コンフィギュレーションが有効になり、現在動作しているデバイスのコンフィギュレーションとなります。

コンフィギュレーション・コミットは、以下のいずれかの理由で失敗することがあります：

• コンフィギュレーションに不正なシンタックスが含まれているため、コミット・チェックに失敗します。

• コミットしようとしている候補コンフィギュレーションは、700MBより大きくなります。

• というコマconfigure exclusiveンドを入力したユーザーによってコンフィギュレーションがロックされています。

コンフィギュレーションにシンタックス・エラーが含まれている場合、エラーのロケーションを示すメッセージが表示され、コンフィギュレーションは有効になりません。エラーメッセージの形式は以下の通りです：

たとえば、以下のように表示されます。

コンフィギュレーションを再実行する前に、エラーを修正する必要があります。エラーが発生した階層レベルに素早く戻るには、エラーの1行目からパスをコピーし、そのパスをという階[edit]層レベルのコンフィギュレーション・モード・プロンプトに貼り付けてください。

コミットされていない、候補のコンフィギュレーション・ファイルは、/var/rundb/juniper.dbです。700MBに制限されています。コミットに失敗してconfiguration database size limit exceededというメッセージが表示された場合は、コンフィギュレーション・モードからrun file list /var/rundb detailというコマンドを入力してファイル・サイズを確認します。ワイルドカードを使用したコンフィギュレーション・グループを作成したり、ファイアウォール・フィルタでより限定的なマッチ・ポリシーを定義することで、コンフィギュレーションを簡素化し、ファイル・サイズを小さくすることができます。

コンフィギュレーションをコミットすると、現在の形式でコンフィギュレーション全体がコミットされます。

最大 32 人のユーザーが同時に設定モードで設定を変更することができます。すべてのユーザーが行ったすべての変更は、設定を編集している全員に表示されます。set、edit、deleteなどの設定を変更するコマンドの最後にユーザーが Enter キーを押すとすぐに変更が表示されます。

設定を編集しているユーザーのいずれかがcommitコマンドを発行すると、CLI はすべてのユーザーによるすべての変更をチェックして有効にします。

そのconfigure privateコマンドで設定モードに入ると、各ユーザーはプライベートな候補設定を持ち、他のユーザーとは多少独立して編集することができます。設定をコミットすると、CLI は自己の変更のみをコミットします。他のユーザーが変更をコミットした後に自分の設定のコピーを同期させるには、設定モードでそのupdateコマンドを実行します。また、コミット操作は、すべてのプライベート候補の設定を更新します。例えば、ユーザー X とユーザー Y がともにconfigure privateモードで、ユーザー X が設定変更をコミットしたとします。ユーザー Y が後続のコミット操作を行い、新しい設定を表示した場合、ユーザー Y が見る新しい設定には、ユーザー X が行った変更が含まれています。

そのconfigure exclusiveコマンドで設定モードに入ると、設定モードにいる限り、候補の設定がロックされます。これにより、他のユーザーの干渉を受けずに変更を行うことができます。他のユーザーは設定モードに入ったり出たりすることはできますが、設定をコミットすることはできません。これは、そのconfigure exclusiveコマンドを入力する前に、他のユーザーが設定モードに入っていても同様です。例えば、ユーザー X がすでにconfigure privateまたはconfigureモードに入っているとします。その後、ユーザー Y がそのconfigure exclusiveモードに入ったとします。ユーザー Y がログインする前にユーザー X が設定変更を入力したとしても、ユーザー X は設定変更をコミットできません。ユーザー Y がconfigure exclusiveモードを終了すると、ユーザー X はconfigure privateモードやconfigureモードで行った変更をコミットすることができます。

タイムクリティカルなコミットでは、シングルステップのプロセスよりも、二段階コミットプロセスのほうが優れています。シングルステップのプロセスでは、デバイス上の既存の設定に応じて、準備時間が変わる可能性があります。二段階のプロセスでは、複雑な準備作業をより効率的に処理することができます。

設定キャッシュの準備や設定のアクティブ化を行うための、設定コマンドが用意されています。新しい設定でデバイスを準備し、必要なタイミングでアクティブ化することができます。

このcommit prepareコマンドでは、設定を検証し、そのcommit activateコマンドが設定をアクティブ化します。コマンドには、以下の設定オプションがあります：

• and-quit

• no-synchronize

• peers-synchronize

• synchronize

このcommit prepareおよびコマcommit activateンドは、プライベート、排他的および共有の各コミットでのみ利用可能です。このコマンドは、動的および一時的なモードでは適用されません。この機能は、マルチシャーシのデバイスに適用できますが、バッチコミットには適用できません。

ネットワーク設定プロトコル（NETCONF）を使用したこの機能をサポートするために、以下の新しいリモートプロシージャコール（RPC）が提供されます：

• <commit-configuration>< prepare/></commit-configuration>

• <commit-configuration><activate/></commit-configuration>

• <clear-system-commit><prepared/></clear-system-commit>

バッチコミットは、異なる CLI セッションまたはユーザーによる複数の設定編集を集約またはマージし、バッチコミットキューに追加します。デバイス上で動作するバッチコミットサーバーは、バッチコミットキューから 1 つまたは複数のジョブを受け取り、設定変更を共有設定データベースに適用した後、1 回のコミット操作で設定変更をコミットします。

ユーザーが指定したバッチの優先順位や、バッチジョブが追加された時刻に基づいて、コミットサーバーがバッチの優先順位を決定します。1 つのバッチコミットが完了した場合、次の設定変更のセットが集約され、バッチコミット操作の次のセッションのために、バッチキューに装備されます。バッチは、キューディレクトリーにコミットエントリーが残らなくなるまで作成されます。

すべてのコミットが独立して順次コミットされる通常のコミット操作と比較して、バッチコミットは、複数の小さな設定編集を 1 回のコミット操作でコミットすることにより、時間とシステムリソースを節約します。

その[edit batch]設定モードからバッチコミットが実行されます。コミットサーバーのプロパティは、その階[edit system commit server]層レベルで設定できます。

この例では、バッチ コミット サーバーのプロパティを設定し、バッチ コミット操作を管理する方法を示します。