設定をコミットする
commit設定モードコマンドにより、デバイス設定の変更を設定データベースに保存し、デバイス上の設定を有効にすることができます。
コンフィギュレーションのコミット・モデル
デバイスの設定はコミットモデルを使用して保存されます。-候補の設定は必要に応じて変更され、システムにコミットされます。コンフィギュレーションがコミットされると、デバイスはコンフィギュレーションのシンタックス・エラーをチェックし、エラーが見つからなければ、コンフィギュレーションを 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番目のルーティングエンジンにコンフィギュレーションを伝播します。
設定を同期するには、
commit synchronizeCLIコマンドを使用します。ルーティングエンジンの1つがロックされている場合、同期に失敗します。コンフィギュレーション・ファイルがロックされているために同期に失敗した場合は、commit synchronize forceコマンドを使用することができます。このコマンドはロックを無効にし、コンフィギュレーション・ファイルを同期させます。-
分散:マルチシャーシデバイスのルーティングプレーン全体に設定を伝搬します。配信は自動的に行われます。配信処理を制御するためのユーザー・コマンドはありません。コンフィギュレーションの配信中にコンフィギュレーションがロックされた場合、ロックされたコンフィギュレーションは配信されたコンフィギュレーション・ファイルを受け取らないため、同期に失敗します。設定の前にロックを解除し、ルーティングプレーンを再同期する必要があります。
注:マルチシャーシ・プラットフォームで
commit synchronize forceCLIコマンドを使用する場合、コンフィギュレーション・ファイルの強制同期がルーティングプレーン全体のコンフィギュレーション・ファイルの配信には影響しません。コマンドを発行したデバイスから離れたデバイス上で、コンフィギュレーション・ファイルがロックされている場合、離れたデバイスでの同期に失敗します。ロックを解除して、synchronizationコマンドを再発行する必要があります。注:Junos OS Evolvedは、以下の
commit設定オプションをサポートしていません。-
fast-synchronize -
peers -
peer-synchronize -
commit-synchronize-server
-
デバイス設定をコミットする
デバイス設定の変更を設定データベースに保存し、デバイス上で設定を有効にするには、 commit 設定モードコマンドを使用します。 commit コマンドは、どの階層レベルからでも発行できます。
[edit]
user@host# commit
commit complete
[edit]
user@host#
commitコマンドを入力すると、まずコンフィギュレーションにシンタックスエラー(commit check)がないかチェックされます。その後、構文が正しければ、コンフィギュレーションが有効になり、現在動作しているデバイスのコンフィギュレーションとなります。
ルーターでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップルーティングエンジンでコミット操作を実行することはお勧めしません。
設定コミットは、以下のいずれかの理由で失敗することがあります。
-
コンフィギュレーションに不正な構文が含まれているため、コミット・チェックに失敗します。
-
コミットしようとしている候補コンフィギュレーションは、700MBより大きくなります。
-
configure exclusiveコマンドを入力したユーザーによって設定がロックされています。
設定に構文エラーが含まれている場合、エラーの場所を示すメッセージが表示され、設定は有効になりません。エラーメッセージの形式は以下の通りです:
[editedit-path] ‘offending-statement;’error-message
例えば：
[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
設定を再実行する前に、エラーを修正する必要があります。エラーが発生した階層レベルに素早く戻るには、エラーの1行目からパスをコピーし、 [edit] 階層レベルの設定モード プロンプトに貼り付けます。
コミットされていない候補のコンフィギュレーション・ファイルは 、/var/rundb/juniper.dbです。デフォルトでは、ファイルのサイズは設定データベースのデフォルトの最大サイズに制限されます。 show system configuration database usage コマンドを発行することで、ディスク上のデータベースサイズと最大データベースサイズを確認できます。また、 run file list /var/rundb detail コマンドを発行して、設定モードからファイルのサイズを表示することもできます。候補構成が最大データベースサイズを超える場合、コミットは失敗し、メッセージ configuration database size limit exceededが表示されます。このエラーに対処するには、次のことを行います。
-
このステートメントをサポートするデバイス上で、
[edit system configuration-database]階層レベルでextend-sizeステートメントを設定することで、設定データベースの最大サイズを増やすことができます。変更を有効にするには、デバイスを再起動する必要があります。 -
ワイルドカードを使用したコンフィギュレーション・グループを作成したり、ファイアウォール・フィルタでより限定的なマッチ・ポリシーを定義することで、コンフィギュレーションを簡素化し、ファイル・サイズを小さくすることができます。
設定をコミットし、必要に応じて再起動した後、 show system configuration database usage コマンドを発行することで、ディスク上のデータベースサイズまたは最大データベースサイズの更新を確認できます。
[edit interfaces]階層レベルでの設定変更に対して表示されるCLIコミット時の警告は削除され、システムログメッセージとして記録されます。
これは、以下の階層レベルのVRRP設定にも適用されます。
-
[edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address] -
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]
設定をコミットすると、現在の形式で設定全体がコミットされます。
-
デバイスで グレースフルルーティングエンジンスイッチオーバー が有効になっている場合、バックアップルーティングエンジン上でコミット操作を実行することはお勧めしません。
-
re0:mgmt-0などの管理インタフェースまたは内部インタフェースとxe-0/0/1などの外部物理インタフェースに同じIPアドレスを設定すると、GRES(Graceful ルーティングエンジン Switchover)を有効にした場合、プライベートインタフェースとパブリックインタフェースに同じアドレスが見つかったという適切なコミットエラーメッセージがCLIに表示されます。このような場合、アドレスが重複している2つのインターフェイスに一意のIPアドレスを割り当てる必要があります。
複数のユーザーがソフトウェアを設定する場合のコミット操作
最大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 モードで行った変更をコミットできます。
コミットの準備とアクティベーションの概要
コミットプロセスは、2つのステップで完了できます。二段階のコミット機能により、複数のデバイスを設定し、同時に設定を有効にすることができます。二段階のコミットでは、コミットがシステム上で有効になる明確な時間枠が設定されます。コミットの準備後にコミット・モードに入ることができますが、コミットがアクティベーションを保留しているというメッセージが表示されます。
最初のステップである準備段階では、コミットが検証され、必要なファイルを含む新しいデータベースが生成されます。設定に構文エラーが含まれている場合は、適切なエラーメッセージが表示され、設定は準備されません。準備段階で障害が発生した場合は、エラーメッセージが表示されます commit check-out failed。
第 2 のステップであるアクティベーションステージでは、事前に準備された設定がアクティブになります。次に、準備した設定をクリアする必要がある場合は、 clear system commit prepared コマンドを使用してクリアできます。保留中のコミットのクリアに成功すると、ログメッセージが作成されます。
準備段階とアクティベーション段階の間の設定変更は実行しないことをお勧めします。
タイムクリティカルなコミットでは、シングルステップのプロセスよりも、二段階コミットプロセスのほうが優れています。シングルステップのプロセスでは、デバイス上の既存の設定に応じて準備時間が変わる可能性があります。二段階のプロセスでは、複雑な準備作業をより効率的に処理することができます。
設定キャッシュの準備や設定のアクティブ化を行うための、設定コマンドが用意されています。新しい設定でデバイスを準備し、必要なタイミングでアクティブ化することができます。
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>
2 つのステップでデバイスの設定をコミットします。準備とアクティベーション
コミットプロセスは、2つのステップで完了できます。これにより、複数のデバイスを設定でき、設定を同時にアクティブ化できます。準備段階と呼ばれる最初のステップでは、コミットが検証され、必要なファイルとともに新しいデータベースが生成されます。設定に構文エラーが含まれている場合は、適切なエラーメッセージが表示され、設定は準備されません。第 2 段階は、起動段階と呼ばれ、事前に準備されたコンフィギュレーションが起動され、現在の動作可能なデバイス コンフィギュレーションとなる。
設定を準備するには:
準備された設定を有効にするには:
commit activateコマンドを使用する[edit] user@host#
commit activateメッセージ
commit completeが表示されます。起動したシステム構成を確認するには、次のコマンドを使用します。
user@host>
show configuration system scriptslanguage python;
commit activate発行後にshow system commitおよびshow system commit revision detailコマンドの出力を確認するには、以下のコマンドを発行します。
user@host> show system commit
0 2018-07-12 22:54:46 PDT by user via cli commit activate
user@host> show system commit revision detail
Revision: re0-1499925285-2214
User : user
Client : cli
Time : 2018-07-12 22:54:46 PDT
Comment : commit activate
確認を伴ってデバイス設定を有効にする
現在の候補構成をコミットする場合、コミットを恒久的なものにするための明示的な確認を要求することができます。これは、設定変更が正しく機能し、デバイスへのアクセスが妨げられないことを確認したい場合に便利です。変更によってアクセスができなくなったり、その他のエラーが発生した場合、ロールバック確認タイムアウトが経過した後、デバイスは自動的に以前の設定に戻り、アクセスが回復します。この機能を自動ロールバックといいます。
現在の候補設定をコミットしますが、コミットを恒久的なものにするために明示的な確認を必要とする場合は、 commit confirmed 設定モードコマンドを使用します。
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
user@host#
変更が正しく機能することを確認したら、commit confirmedコマンドから 10 分以内に commit または commit check コマンドを入力することで、新しい設定を有効な状態に維持できます。例えば：
[edit]
user@host# commit check
configuration check succeeds
一定時間(デフォルトでは 10 分)以内にコミットが確認されない場合、オペレーティングシステムは自動的に以前の設定にロールバックし、ログインしているすべてのユーザーにブロードキャストメッセージが送信されます。
commit confirmed コマンドの後にロールバックがスケジュールされているタイミングを表示するには、show system commit コマンドを入力します。例えば：
user@host>show system commit
0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
commitコマンドと同様に、commit confirmedコマンドは設定構文を検証し、エラーを報告します。エラーがなければ、設定が一時的にアクティブ化され(デフォルトでは 10 分)、デバイス上で実行を開始します。
を確認する
新しい設定を確認する前に時間の長さを変更するには、コマンドを発行する際に分数を指定します。
[edit]
user@host# commit confirmed minutes
commit complete
[edit]
user@host#
[edit private]設定モードでcommit confirmedコマンドを使用することもできます。
コミット操作のスケジュール
候補の設定をいつアクティブにするかをスケジュールできます。デバイスの設定変更を保存し、将来の時刻にまたは再起動時にデバイス上で設定を有効にするには、commit at設定モードコマンドを使用し、[edit]階層レベルでrebootまたは将来の時刻を指定します。
[edit]
user@host # commit at string
string 設定変更を有効にする reboot または将来の時刻です。時間を 2 つの形式で指定できます。
hh:mm[:ss]形式の時間値(時、分、場合によっては秒)—指定された時刻に設定をコミットします。これは、commit at設定モードコマンドが発行された日の午後 11 時 59 分 59 秒より前の将来である必要があります。hh値には 24 時間制を使用します。たとえば、04:30:00は午前 4:30:00、は午後 8:00 です20:00。時間は、ルーターの時計とタイムゾーンの設定を基準にして解釈されます。yyyy-mm-dd hh:mm[:ss]形式の日付と時刻の値(年、月、日付、時間、分、オプションで秒)—指定された日時に設定をコミットします。commit atコマンドを発行した後でなければなりません。hh値には 24 時間制を使用します。たとえば、2018-08-2112:30:00は 2018 年 8 月 21 日の午後 12:30 です。時間は、ルーターの時計とタイムゾーンの設定を基準にして解釈されます。
string値を引用符(" ")で囲みます。例えば、commit at "18:00:00"です。日付と時刻については、両方の値を同じ引用符で囲みます。例えばcommit at "2018-03-10 14:00:00".
コミットチェックは、 commit at 設定モードコマンドを発行するとすぐに実行されます。チェックの結果が成功した場合、現在のユーザーは設定モードからログアウトされ、設定データは読み取り専用の状態になります。スケジュールされたコミットが完了するまで、他のコミットは実行できません。
設定変更が有効になる前にデバイスソフトウェアが故障すると、設定変更はすべて失われます。
request system rebootコマンドを発行した後にcommit at 設定コマンドを入力することはできません。
将来的な特定の時間にコミット操作をスケジュールすると、 request system reboot コマンドを入力できなくなります。
スケジュールされたコミットが保留されているときは、設定をコミットできません。 clear コマンドでスケジュールされた設定をキャンセルする方法については、 CLIエクスプローラーを参照してください。
デバイスでグレースフルルーティングエンジンスイッチオーバーが有効になっている場合、バックアップルーティングエンジン上でコミット操作を実行することはお勧めしません。
コミット プロセスを監視する
デバイス設定コミットプロセスを監視するには、commitコマンドを使用したパイプの後にdisplay detailコマンドを使用します。
user@host# commit | display detail
例えば：
[edit]
user@host# commit | display detail2021-10-08 10:33:42.619908 PDT: Obtaining lock for commit
2021-10-08 10:42:36.341266 PDT: Obtaining lock for commit
2021-10-08 10:42:36.343401 PDT: updating commit revision
2021-10-08 10:42:36.343639 PDT: UI extensions feature is not configured
2021-10-08 10:42:36.343718 PDT: UI change-notification feature is not configured
2021-10-08 10:42:36.343877 PDT: Started running translation script
2021-10-08 10:42:36.398596 PDT: No delta input for translation
2021-10-08 10:42:36.398679 PDT: Finished running translation script
2021-10-08 10:42:36.398904 PDT: start loading commit script changes
2021-10-08 10:42:36.398944 PDT: no commit script changes
2021-10-08 10:42:36.399006 PDT: no transient commit script changes
2021-10-08 10:42:36.399046 PDT: finished loading commit script changes
2021-10-08 10:42:36.399091 PDT: No translation output from the scripts
2021-10-08 10:42:36.400007 PDT: building groups inheritance path proportional in
candidate db
2021-10-08 10:42:36.400074 PDT: finished groups inheritance path
2021-10-08 10:42:36.400112 PDT: copying juniper.db to juniper.data+
2021-10-08 10:42:36.402278 PDT: finished copying juniper.db to juniper.data+
2021-10-08 10:42:36.402357 PDT: exporting juniper.conf
2021-10-08 10:42:36.404504 PDT: expanding interface-ranges
2021-10-08 10:42:36.404566 PDT: finished expanding interface-ranges
2021-10-08 10:42:36.404598 PDT: setup foreign files
2021-10-08 10:42:36.411776 PDT: propagating foreign files
2021-10-08 10:42:36.411824 PDT: Sending constraint check command to evaluate con
straints
2021-10-08 10:42:36.580667 PDT: constraints passed in mustd - not checking const
raints in propagation
2021-10-08 10:42:36.586908 PDT: complete foreign files
2021-10-08 10:42:36.663944 PDT: Forking child for configd-streamer operation
2021-10-08 10:42:36.666585 PDT: dropping unchanged foreign files
2021-10-08 10:42:36.666768 PDT: start ffp propagate
2021-10-08 10:42:36.855945 PDT: propagate stp-portid-ffp
2021-10-08 10:42:37.120224 PDT: propagate stp-portid-ffp done
2021-10-08 10:42:37.120447 PDT: propagate interface-alias-ffp
2021-10-08 10:42:37.464777 PDT: propagate interface-alias-ffp done
2021-10-08 10:42:37.467692 PDT: finish ffp propagate
2021-10-08 10:42:37.467826 PDT: Sending command to evaluate validation hooks
2021-10-08 10:42:37.471143 PDT: daemons checking new configuration
2021-10-08 10:42:37.761146 PDT: Collecting status of mustd hooks validation, sta
tus 0
2021-10-08 10:42:37.761273 PDT: commit wrapup...
2021-10-08 10:42:37.761519 PDT: Checking status of configd-streamer child before
ffp activate
2021-10-08 10:42:37.761562 PDT: ev.ops+ file generated successfully
2021-10-08 10:42:37.761635 PDT: start ffp activate
2021-10-08 10:42:37.938324 PDT: activate stp-portid-ffp
2021-10-08 10:42:38.181781 PDT: activate stp-portid-ffp done
2021-10-08 10:42:38.181953 PDT: activate interface-alias-ffp
2021-10-08 10:42:38.373063 PDT: activate interface-alias-ffp done
2021-10-08 10:42:38.373125 PDT: activate hostname-ffp
2021-10-08 10:42:38.731220 PDT: activate hostname-ffp done
2021-10-08 10:42:38.731575 PDT: activate configd-ffp
2021-10-08 10:42:38.904529 PDT: activate configd-ffp done
2021-10-08 10:42:38.906425 PDT: activating '/var/etc/cosd.conf'
2021-10-08 10:42:38.906598 PDT: activating '/var/etc/pam.conf'
2021-10-08 10:42:38.906716 PDT: activating '/var/etc/pam_radius.conf'
2021-10-08 10:42:38.983913 PDT: activating '/var/etc/pam_tacplus.conf'
2021-10-08 10:42:38.984100 PDT: activating '/var/etc/issue'
2021-10-08 10:42:38.984202 PDT: activating '/var/etc/certs'
2021-10-08 10:42:38.991939 PDT: activating '/var/etc/motd'
2021-10-08 10:42:38.992178 PDT: activating '/var/etc/max-db-size-cfg'
2021-10-08 10:42:38.992267 PDT: activating '/var/etc/subs-mgmt-cfg'
2021-10-08 10:42:38.992342 PDT: activating '/var/etc/nc_notification'
2021-10-08 10:42:38.992464 PDT: activating '/var/etc/ephinst.conf'
2021-10-08 10:42:38.992557 PDT: activating '/var/etc/config-apps.txt'
2021-10-08 10:42:38.992674 PDT: executing foreign_commands
2021-10-08 10:42:38.992722 PDT: /bin/sh /etc/rc.ui ui_setup_users (sh)
2021-10-08 10:42:39.24126 PDT: not executing commit in cli_sysctl
2021-10-08 10:42:39.24234 PDT: finish ffp activate
2021-10-08 10:42:39.24278 PDT: db_groups_info_clear start
2021-10-08 10:42:39.419569 PDT: db_groups_info_clear done
2021-10-08 10:42:39.419653 PDT: activating '/var/rundb/juniper.data'
2021-10-08 10:42:40.14698 PDT: Rotate backup configs
2021-10-08 10:42:40.142039 PDT: ssync begins
2021-10-08 10:42:40.566324 PDT: ssync ends
2021-10-08 10:42:40.566392 PDT: ssync begins
2021-10-08 10:42:40.807541 PDT: ssync ends
2021-10-08 10:42:40.807608 PDT: notifying daemons of new configuration
2021-10-08 10:42:40.807804 PDT: ssync begins
2021-10-08 10:42:40.924440 PDT: ssync ends
2021-10-08 10:42:40.924630 PDT: mgd tracing: disabled
2021-10-08 10:42:40.924684 PDT: New database revision 're0-1633714956-29' and ol
d database revision 're0-1633714422-28'
2021-10-08 10:42:40.924709 PDT: commit complete
commit complete
コミットされた設定を説明するコメントを追加する
コミットされた設定に対する変更点を説明するコメントを含めることができます。そのためには、 commit comment ステートメントを含めます。コメントは512文字まで可能で、1行で入力する必要があります。
[edit]
user@host# commit comment comment-string
comment-string はコメントの本文です。
commit check コマンドにコメントを含めることはできません。
commitコマンドにコメントを追加するには、commitコマンドの後にcommentステートメントを含めます。
[edit]
user@host# commit comment "add user joe"
commit complete
[edit]
user@host#
commit confirmedコマンドにコメントを追加するには、commit confirmedコマンドの後にcommentステートメントを含めます。
[edit]
user@host# commit confirmed comment "add customer to port 27"
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
[edit]
user@host#
これらのコミットコメントを表示するには、 show system commit 運用モードコマンドを発行します。
[edit private]設定モードでcommit confirmedコマンドを使用することもできます。
Junos OS リリース 24.2R1 以降、Junos OS では、コミット要求ごとにコメントの発行が必須になります。これは、コミット時に複数のユーザーまたは管理者が行った変更を追跡するのに役立ちます。
commitコマンドは、comment引数なしでは実行されません。
各コミット要求に対してコメントの追加をユーザーに強制するには、[edit system commit]階層レベルでforce-commit-logオプションを設定します。
バッチコミットの概要
バッチコミットは、異なるCLIセッションまたはユーザーからの複数の設定編集を集約またはマージし、バッチコミットキューに追加します。デバイス上で動作するバッチコミットサーバーは、バッチコミットキューから1つ以上のジョブを受け取り、設定変更を共有設定データベースに適用した後、1回のコミット操作で設定変更をコミットします。
ユーザーが指定したバッチの優先順位や、バッチジョブが追加された時刻に基づいて、コミットサーバーがバッチの優先順位を決定します。1 つのバッチコミットが完了すると、次の設定変更のセットが集約され、バッチコミット操作の次のセッションのためにバッチキューにロードされます。バッチは、キューディレクトリーにコミットエントリーが残らなくなるまで作成されます。
すべてのコミットが独立して順次コミットされる通常のコミット操作と比較して、バッチコミットは、複数の小さな設定編集を 1 回のコミット操作でコミットすることにより、時間とシステムリソースを節約します。
バッチコミットは、 [edit batch] 設定モードから実行されます。コミットサーバーのプロパティは、 [edit system commit server] 階層レベルで設定できます。
集約とエラー処理
集約されたジョブの 1 つにロード時間エラーが発生した場合、エラーが発生したコミットジョブは破棄され、残りのジョブが集約されてコミットされます。
例えば、5 つのコミットジョブ(commit-1、 commit-2、 commit-3、 commit-4、 commit-5)が集約されていて、 commit-3 読み込み中にエラーが発生した場合、 commit-3 が破棄され、 commit-1、 commit-2、 commit-4、 commit-5 が集約されてコミットされます。
2 つ以上のジョブを集約してコミットする際に、コミット操作中にエラーが発生した場合、集約は破棄され、それらの各ジョブは通常のコミット操作と同様に個別にコミットされます。
例えば、5つのコミットジョブ(commit-1、 commit-2、 commit-3、 commit-4、 commit-5)が集約され、 commit-3が原因でコミットエラーが発生した場合、集約は破棄され、 commit-1、 commit-2、 commit-3、 commit-4、 commit-5 が個別にコミットされ、CLIは commit-3のコミットエラーを報告します。
例:バッチ コミット サーバーのプロパティを設定する
この例では、バッチ コミット サーバーのプロパティを設定して、バッチ コミット操作を管理する方法を示します。
概要
[edit system commit server]階層レベルでサーバーのプロパティを設定することで、コミットサーバーによるバッチコミットキューの処理方法を制御できます。これにより、1つのバッチコミットに集約またはマージされるコミットジョブの数、キューに追加できるジョブの最大数、バッチコミットエラーログを保持する日数、2つのバッチコミットの間隔、バッチコミット操作のトレース操作を制御することができます。
設定
CLIクイックコンフィグレーション
この例のセクションをすばやく設定するには、次のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更してから、コマンドを [edit] 階層レベルのCLIにコピー アンド ペーストします。コミット サーバーのプロパティは、通常の [edit] モードと [edit batch] モードのどちらからでも設定できます。
デバイスR0
set system commit server maximum-aggregate-pool 4set system commit server maximum-entries 500set system commit server commit-interval 5set system commit server days-to-keep-error-logs 30set system commit server traceoptions file commitd_novset system commit server traceoptions flag all
コミット サーバーのプロパティの設定
ステップバイステップの手順
-
(オプション)1 回のコミット操作で集約またはマージするコミット トランザクションの数を設定します。
maximum-aggregate-poolのデフォルト値は5です。注:maximum-aggregate-poolを1に設定すると、各ジョブが個別にコミットされます。この例では、コミット トランザクションの数が
4に設定されており、コミット操作が開始される前に 4 つの異なるコミット ジョブが 1 つのコミットに集約されることを示しています。[edit system commit server]user@R0#set maximum-aggregate-pool 4 -
(オプション)バッチで許可されるジョブの最大数を設定します。
これにより、キューに追加されるコミット ジョブの数が制限されます。
[edit system commit server]user@R0#set maximum-entries 500注:maximum-entriesを1に設定した場合、コミットサーバーは複数のジョブをキューに追加できず、複数のジョブをコミットしようとするとCLIに適切なメッセージが表示されます。 -
(オプション)次のバッチ コミット操作を開始するまでの待機時間(秒単位)を設定します。
[edit system commit server]user@R0#set commit-interval 5 -
(オプション)エラーログを保存する日数を設定します。
デフォルト値は
30日です。[edit system commit server]user@R0#set days-to-keep-error-logs 30 -
(オプション)バッチ コミット イベントをログに記録するトレース操作を設定します。
この例では、バッチ コミット イベントのログを取るためのファイル名は
commitd_novで、すべての traceoption フラグが設定されています。[edit system commit server]user@R0#set traceoptions commitd_novuser@R0#set traceoptions flag all
結果
設定モードから、 show system commit server コマンドを入力して設定を確認します。出力に意図した設定が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@R0# show system commit server
maximum-aggregate-pool 4;
maximum-entries 500;
commit-interval 5;
days-to-keep-error-logs 30;
traceoptions {
file commitd_nov;
flag all;
}
バッチ設定モードからの設定のコミット
ステップバイステップの手順
[edit batch]モードから設定をコミットするには、次のいずれかを実行します。
-
デバイスにログインし、
commitを入力します。[edit batch]user@R0#commitAdded to commit queue request-id: 1000 -
バッチ コミット ジョブに高い優先度を割り当てるには、
priorityオプションを付けてcommitコマンドを発行します。[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001 -
キュー内の他のコミット ジョブと構成の変更を集約せずにコミットするには、
atomicオプションを付けてcommitコマンドを発行します。[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002 -
キュー内の他のコミット ジョブと設定変更を集約せず、コミット ジョブに高い優先度を発行するには、
atomic priorityオプションを付けてcommitコマンドを発行します。[edit batch]user@R0#commit atomic priorityAdded to commit queue request-id: 1003
検証
設定が正常に機能していることを確認します。
バッチ コミット サーバーの状態を確認する
目的
バッチ コミット サーバーの状態を確認します。
アクション
user@R0> show system commit server
Commit server status : Not running
デフォルトでは、コミットサーバーのステータスは Not runningです。コミット サーバーは、バッチ コミット ジョブがキューに追加された場合にのみ実行を開始します。
バッチ コミット ジョブがキューに追加されると、コミット サーバーのステータスが Running に変更されます。
user@R0> show system commit server
Commit server status : Running
Jobs in process:
1003 1004 1005
意味
Jobs in processフィールドには、処理中のジョブのコミットIDが表示されます。
バッチ コミット ステータスの確認
目的
コミット サーバーのキューで、バッチ コミットの状況を確認します。
アクション
user@R0> show system commit server queue
Pending commits:
Id: 1005
Last Modified: Tue Nov 1 23:56:43 2018
Completed commits:
Id: 1000
Last Modified: Tue Nov 1 22:46:43 2018
Status: Successfully committed 1000
Id: 1002
Last Modified: Tue Nov 1 22:50:35 2018
Status: Successfully committed 1002
Id: 1004
Last Modified: Tue Nov 1 22:51:48 2018
Status: Successfully committed 1004
Id: 1007
Last Modified: Wed Nov 2 01:08:04 2018
Status: Successfully committed 1007
Id: 1009
Last Modified: Wed Nov 2 01:16:45 2018
Status: Successfully committed 1009
Id: 1010
Last Modified: Wed Nov 2 01:19:25 2018
Status: Successfully committed 1010
Id: 1011
Last Modified: Wed Nov 2 01:28:16 2018
Status: Successfully committed 1011
Error commits:
Id: 1008
Last Modified: Wed Nov 2 01:08:18 2018
Status: Error while commiting 1008
意味
Pending commits コミットキューに追加されていますが、まだコミットされていないコミットジョブを表示します。 Completed commits 成功したコミットジョブのリストを表示します。 Error commits は、エラーにより失敗したコミットです。
バッチ コミット ジョブのパッチ ファイルを表示する
目的
各コミット ジョブのタイム スタンプ、パッチ ファイル、ステータスを表示します。パッチ ファイルは、バッチ コミット キューに追加される各コミット操作で発生する設定変更を示します。
アクション
-
show system commit server queue patchコマンドを使用すると、すべてのコミット操作のパッチが表示されます。user@R0>
show system commit server queue patchPending commits: none Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit groups] re1 { ... } + GRP-DHCP-POOL-NOACCESS { + access { + address-assignment { + pool <*> { + family inet { + dhcp-attributes { + maximum-lease-time 300; + grace-period 300; + domain-name verizon.net; + name-server { + 4.4.4.1; + 4.4.4.2; + } + } + } + } + } + } + } Id: 1002 Last Modified: Tue Nov 1 22:50:35 2018 Status: Successfully committed 1002 Patch: [edit] + snmp { + community abc; + } Id: 1010 Last Modified: Wed Nov 2 01:19:25 2018 Status: Successfully committed 1010 Patch: [edit system syslog] file test { ... } + file j { + any any; + } Error commits: Id: 1008 Last Modified: Wed Nov 2 01:08:18 2018 Status: Error while commiting 1008 Patch: [edit system] + radius-server { + 10.1.1.1 port 222; + }出力には、各コミット ジョブ ID の設定変更が表示されます。
-
特定のコミット ジョブ ID のパッチを表示するには、
show system commit server queue patch id <id-number>コマンドを発行します。user@R0>
show system commit server queue patch id 1000Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit system] + radius-server { + 192.168.69.162 secret teH.bTc/RVbPM; + 192.168.64.10 secret teH.bTc/RVbPM; + 192.168.60.52 secret teH.bTc/RVbPM; + 192.168.60.55 secret teH.bTc/RVbPM; + 192.168.4.240 secret teH.bTc/RVbPM; + }
意味
出力には、コミット ジョブ用に作成されたパッチが表示されます。 + 記号または - 記号は、特定のコミット ジョブに対する設定の変更を示します。
バッチ コミット操作のトレース ファイルを表示する
目的
バッチ コミット操作のトレース ファイルを表示します。トレース ファイルはトラブルシューティングのために使用することができます。
アクション
-
ログ ファイルのすべてのエントリーを表示するには、
file show /var/log/<filename>コマンドを使用します。user@R0>
file show/var/log/commitd_novバッチコミットのコミットサーバーイベントログなどが出力されます。
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:46:43 pausing after commit for 0 seconds ... Nov 1 22:46:43 Done working on queue ... Nov 1 22:47:17 maximum-aggregate-pool = 5 Nov 1 22:47:17 maximum-entries= 0 Nov 1 22:47:17 asynchronous-prompt = no Nov 1 22:47:17 commit-interval = 0 Nov 1 22:47:17 days-to-keep-error-logs = -1 ... Nov 1 22:47:17 Added to commit queue request-id: 1001 Nov 1 22:47:17 Commit server status=running Nov 1 22:47:17 No need to pause ... Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:47:18 doing rollback ...
-
成功したバッチ コミット操作のログ エントリーのみを表示するには、
| match committedパイプ オプションを付けてfile show /var/log/<filename>コマンドを発行します。出力には、コミット操作に成功したバッチ コミット ジョブ ID が表示されます。
user@R0>
file show/var/log/commitd_nov | match committedNov 1 22:46:43 Successfully committed 1000 Nov 1 22:50:35 Successfully committed 1002 Nov 1 22:51:48 Successfully committed 1004 Nov 2 01:08:04 Successfully committed 1007 Nov 2 01:16:45 Successfully committed 1009 Nov 2 01:19:25 Successfully committed 1010 Nov 2 01:28:16 Successfully committed 1011 -
失敗したバッチ コミット操作のログ エントリーのみを表示するには、
| match “Error while”パイプ オプションを付けてfile show /var/log/<filename>コマンドを発行します。失敗したコミット操作のコミット ジョブ ID が出力されます。
user@R0>
file show/var/log/commitd_nov | match “Error while”Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:51:10 Error while commiting 1003 Nov 1 22:52:15 Error while commiting 1005 ... -
コミット サーバー イベントのログ エントリーのみを表示するには、
file show /var/log/<filename>コマンドを| match “commit server”パイプ オプション付きで実行します。コミット サーバーのイベント ログが出力されます。
user@R0>
file show/var/log/commitd_nov | match “commit server”Nov 1 22:46:39 Commit server status=running Nov 1 22:46:39 Commit server jobs=1000 Nov 1 22:46:43 Commit server status=not running Nov 1 22:46:43 Commit server jobs= Nov 1 22:47:17 Commit server status=running Nov 1 22:47:18 Commit server jobs=1001 Nov 1 22:47:18 2 errors reported by commit server Nov 1 22:47:18 Commit server status=not running Nov 1 22:47:18 Commit server jobs= Nov 1 22:50:31 Commit server status=running Nov 1 22:50:31 Commit server jobs=1002 Nov 1 22:50:35 Commit server status=not running Nov 1 22:50:35 Commit server jobs= Nov 1 22:51:09 Commit server status=running Nov 1 22:51:10 Commit server jobs=1003 Nov 1 22:51:10 2 errors reported by commit server Nov 1 22:51:10 Commit server status=not running ...
コミットされた設定を代替ブートドライブにバックアップします
設定をコミットし、正常に動作していることを確認したら、 request system snapshot コマンドを発行して、新しいソフトウェアを /altconfig ファイルシステムにバックアップする必要があります。 request system snapshot コマンドを発行しない場合、代替ブートドライブの構成はプライマリー ブート ドライブの構成と同期していません。
request system snapshotコマンドは、ルートファイルシステムを/altrootにバックアップし、/configを/altconfigにバックアップします。ルートファイルシステムと/configファイルシステムはルーターのフラッシュドライブ上にあり、/altrootファイルシステムと/altconfigファイルシステムはルーターのハードディスクにあります(利用可能な場合)。
request system snapshotコマンドを発行すると、実行中のソフトウェアとバックアップコピーが同一になるため、以前のバージョンに戻すことはできません。