구성 커밋
commit 구성 모드 명령으로 디바이스 구성 변경을 구성 데이터베이스에 저장하고 디바이스에서 구성을 활성화할 수 있습니다.
구성을 위한 커밋 모델
디바이스 구성은 커밋 모델을 사용하여 저장됩니다. 후보 구성은 원하는 대로 수정된 다음 시스템으로 커밋됩니다. 구성이 커밋되면 디바이스는 구문 오류 구성을 확인하고, 오류가 없으면 구성은 juniper.conf.gz(으)로 저장 및 활성화됩니다. 이전 활성 구성 파일은 첫 번째 rollback 구성 파일(juniper.conf.1.gz)로 저장되고, 다른 rollback 구성 파일은 1만큼 증가합니다. 예를 들어 juniper.conf.1.gz은(는) juniper.conf.2.gz(으)로 증가하여 두 번째 rollback 구성 파일이 됩니다. 디바이스는 시스템에 저장된 rollback 구성을 최대 49개(1~49)를 가질 수 있습니다.
디바이스에서 현재 구성 파일과 첫 3개의 rollback 파일(juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3)은 /config 디렉터리에 있습니다. (4부터 49까지의 나머지 rollback 파일은 /var/db/config에 위치합니다.)
복구 구성 파일 rescue.conf.gz이(가) 존재하면, 이 파일도 /config 디렉터리에 있습니다. 공장 기본 파일은 /etc/config 디렉터리에 있습니다.
디바이스 내 라우팅 엔진 사이 구성을 전파하는 데 사용되는 두 가지 메커니즘이 있습니다:
동기화: 동일한 디바이스 섀시 내에서 하나의 라우팅 엔진에서 두 번째 라우팅 엔진으로 구성을 전파합니다.
구성을 동기화하려면
commit synchronizeCLI 명령을 사용합니다. 라우팅 엔진 중 하나가 잠기면, 동기화는 실패합니다. 잠긴 구성 파일 때문에 동기화가 실패하면,commit synchronize force명령을 사용할 수 있습니다. 이 명령은 잠금을 재정의하고 구성 파일을 동기화합니다.배포: 다중 디바이스 내 라우팅 플레인에서 구성을 전파합니다. 배포는 자동으로 발생합니다. 배포 프로세스를 제어할 수 있는 사용자 명령은 없습니다. 구성을 배포하는 동안 구성이 잠기면, 그 잠긴 구성은 배포된 구성 파일을 수신하지 않으므로 동기화가 실패합니다. 구성 전에 잠금을 제거하고 라우팅 플레인을 재동기화해야 합니다.
주:다중 섀시 플랫폼에서
commit synchronize forceCLI 명령을 사용할 때, 구성 파일의 강제 동기화는 라우팅 플레인의 구성 파일 배포에 영향을 주지 않습니다. 구성 파일이 명령이 내려진 디바이스에서 멀리 떨어진 디바이스에 잠겨있다면, 이 떨어져 있는 디바이스에서의 동기화는 실패합니다. 잠금을 제거하고synchronization명령을 다시 내려야 합니다.
참조
디바이스 구성 커밋
디바이스 구성 변경 사항을 구성 데이터베이스에 저장하고 디바이스에서 구성을 활성화하려면 commit 구성 모드 명령을 사용합니다. 모든 계층 수준에서 commit 명령을 실행할 수 있습니다.
[edit]
user@host# commit
commit complete
[edit]
user@host#
commit 명령을 입력하면 먼저 구성에 구문 오류가 있는지 확인합니다(commit check). 그런 다음, 구문이 정확하면 구성이 활성화되고 현재 작동하는 디바이스 구성이 됩니다.
라우터에서 GRES(Graceful Routing Engine Switchover)가 활성화되면, 백업 라우팅 엔진에서 커밋 작업을 수행하지 않는 것이 좋습니다.
구성 커밋은 다음과 같은 이유로 실패할 수 있습니다.
구성에 잘못된 구문이 포함되어 있어 커밋 검사에 실패합니다.
커밋하려는 후보 구성이 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
구성을 다시 커밋하기 전에 오류를 수정해야 합니다. 오류가 있는 계층 수준으로 신속하게 돌아가려면, 오류 첫 번째 라인에서 경로를 복사하여 [edit] 계층 수준의 구성 모드 프롬프트에 붙여넣습니다.
커밋되지 않은 후보 구성 파일은 /var/rundb/juniper.db입니다. 이 파일은 700MB로 제한됩니다. configuration database size limit exceeded 메시지에서 커밋이 실패하면 run file list /var/rundb detail 명령을 입력하여 구성 모드에서 파일 크기를 확인합니다. 와일드카드로 구성 그룹을 만들거나 방화벽 필터에서 덜 구체적인 일치 정책을 정의하여 구성을 단순화하고 파일 크기를 줄일 수 있습니다.
[edit interfaces] 계층 수준에서 구성 변경 사항에 표시되는 CLI commit-time 경고가 삭제되고 시스템 로그 메시지로 로그됩니다.
또한 이것은 다음 계층 수준의 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]
구성을 커밋할 때 전체 구성을 현재 형식으로 커밋합니다.
디바이스에서 GRES(Graceful Routing Engine Switchover)가 활성화되면, 백업 라우팅 엔진에서 커밋 작업을 수행하지 않는 것이 좋습니다.
-
관리 인터페이스 또는 내부 인터페이스(예:
fxp0및 외부의 물리적 인터페이스(예:ge-0/0/1)에 동일한 IP 주소를 구성하는 경우, GRES(Graceful Routing Engine Switchover)가 활성화되면 CLI는 프라이빗 및 공용 인터페이스에서 동일한 주소가 발견되었다는 적절한 커밋 오류 메시지를 표시합니다. 이러한 경우 중복 주소가 있는 두 인터페이스에 고유한 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 모드에 들어간다고 가정합니다. 사용자 X는 사용자 Y가 로그인하기 전에 변경 사항을 입력한 경우에도 구성에 대한 변경 사항을 커밋할 수 없습니다. 사용자 Y가 configure exclusive 모드를 종료하면, 사용자 X가 configure private 또는 configure 모드에서 변경한 사항을 커밋할 수 있습니다.
커밋 준비 및 활성화 개요
커밋 프로세스는 두 단계로 완료할 수 있습니다. 2단계 커밋 기능을 사용하면 여러 장치를 구성하는 동시에 구성을 활성화할 수 있습니다. 2단계 커밋은 커밋이 시스템에서 유효할 수 있는 결정적인 시간 창을 제공합니다. 커밋이 준비된 후 커밋 모드로 전환할 수 있지만 커밋이 활성화 보류 중이라는 메시지가 표시됩니다.
준비 단계인 첫 번째 단계에서 커밋이 검증되고 필요한 파일이 포함된 새 데이터베이스가 생성됩니다. 구성에 구문 오류가 있으면 해당 오류 메시지가 표시되고 구성이 준비되지 않았습니다. 준비 단계에서 실패하면 오류 메시지 commit check-out failed이(가) 표시됩니다.
두 번째 단계인 활성화 단계에서, 미리 준비된 구성이 활성화됩니다. 다음으로, 준비된 구성을 지워야 할 경우 clear system commit prepared 명령을 사용하여 지울 수 있습니다. 보류 중인 커밋을 성공적으로 지울 때 로그 메시지가 생성됩니다.
준비 단계와 활성화 단계 사이에는 커밋 작업을 수행할 수 없습니다.
2단계 커밋 프로세스는 time-critical 커밋의 단일 단계 프로세스보다 우수합니다. 단일 단계 프로세스에서 준비 시간은 장치의 기존 구성에 따라 달라질 수 있습니다. 2단계 과정에서는 복잡한 준비 작업이 더 효율적으로 처리됩니다.
구성 캐시를 준비하고 구성을 활성화할 수 있는 구성 명령이 제공됩니다. 새 구성으로 장치를 준비하고 원하는 시간에 활성화할 수 있습니다.
commit prepare 명령은 구성을 검증하고, commit activate 명령은 구성을 활성화합니다. 명령은 다음 구성 옵션을 갖습니다.
-
and-quit -
no-synchronize -
peers-synchronize -
synchronize
commit prepare 및 commit activate 명령은 비공개, 배타적 및 공유 커밋에만 사용할 수 있습니다. 이 명령은 동적 및 사용 후 삭제 모드에 적용할 수 없습니다. 이 기능은 다중 섀시 장치에 적용 가능하지만 배치 커밋에는 적용되지 않습니다.
NETCONF(Network Configuration Protocol)를 사용하여 이 기능을 지원하기 위해 다음과 같은 새로운 원격 절차 호출(RPC)이 제공됩니다.
-
<commit-configuration>< prepare/></commit-configuration> -
<commit-configuration><activate/></commit-configuration> -
<clear-system-commit><prepared/></clear-system-commit>
-
MX 시리즈 가상 섀시 설정에서 다음 사항이 적용됩니다.
commit prepare이(가) 하나의 라우팅 엔진에서 발행된 후 전환되면 전환 명령이 발행된 라우팅 엔진이 재부팅됩니다. 따라서 준비된 캐시는 해당 라우팅 엔진에서 지워집니다. -
MX 시리즈 가상 섀시 설정에서는 VC Primary에서만
clear system commit prepared명령을 실행하는 것이 좋습니다.
두 단계로 디바이스 구성 커밋: 준비 및 활성화
커밋 프로세스는 두 단계로 완료할 수 있습니다. 이렇게 하면 여러 디바이스를 구성할 수 있으며 구성을 동시에 활성화할 수 있습니다. 준비 단계로 알려진 첫 번째 단계에서 커밋이 검증되고 필요한 파일과 함께 새 데이터베이스가 생성됩니다. 구성에 구문 오류가 있으면 해당 오류 메시지가 표시되고 구성이 준비되지 않았습니다. 활성화 단계라고 불리는 두 번째 단계에서, 미리 준비된 구성이 활성화되고 현재의 작동 디바이스 구성이 된다.
구성을 준비하려면,
준비된 구성을 활성화하려면,
commit activate명령 사용[edit] user@host#
commit activatecommit 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 또는 향후 시간입니다. 두 형식으로 시간을 지정할 수 있습니다:
형식
hh:mm[:ss](시, 분, 그리고 선택 가능한 초)의 시간 값-지정한 시간에 구성을 커밋합니다. 미래이지만commit at구성 모드 명령을 내린 당일의 11:59:59 PM 이전이어야 합니다.hh값에 24시간 시간을 사용합니다. 예를 들어04:30:00은(는) 4:30:00 AM,20:00은(는) 8:00 PM입니다. 시간은 라우터의 클럭 및 시간대 설정에 대해 해석됩니다.형식
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 Explorer에서 확인하십시오.
GRES(Graceful Routing Engine Switchover)가 디바이스에서 작동할 때, 백업 라우팅 엔진에서 커밋 운영을 수행하는 것을 권장하지 않습니다.
커밋 프로세스 모니터링
디바이스 구성 커밋 프로세스를 모니터링하려면, commit 명령의 파이프 다음 display detail 명령을 사용하십시오:
user@host# commit | display detail
예:
[edit]
user@host# commit | display detail
2018-09-22 15:39:39 PDT: exporting juniper.conf
2018-09-22 15:39:39 PDT: setup foreign files
2018-09-22 15:39:39 PDT: propagating foreign files
2018-09-22 15:39:39 PDT: complete foreign files
2018-09-22 15:39:40 PDT: copying configuration to juniper.data+
2018-09-22 15:39:40 PDT: dropping unchanged foreign files
2018-09-22 15:39:40 PDT: daemons checking new configuration
2018-09-22 15:39:41 PDT: commit wrapup...
2018-09-22 15:39:42 PDT: activating '/var/etc/ntp.conf'
2018-09-22 15:39:42 PDT: activating '/var/etc/kmd.conf'
2018-09-22 15:39:42 PDT: activating '/var/db/juniper.data'
2018-09-22 15:39:42 PDT: notifying daemons of new configuration
2018-09-22 15:39:42 PDT: signaling 'Firewall daemon', pid 24567, signal 1,
status 0
2018-09-22 15:39:42 PDT: signaling 'Interface daemon', pid 24568, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'Routing protocol daemon', pid 25679,
signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'MIB2 daemon', pid 24549, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'NTP daemon', pid 37863, signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'Sonet APS daemon', pid 24551, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'VRRP daemon', pid 24552, signal 1,
status 0
2018-09-22 15:39:43 PDT: signaling 'PFE daemon', pid 2316, signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'Traffic sampling control daemon', pid 24553
signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'IPsec Key Management daemon', pid
24556, signal 1, status 0
2018-09-22 15:39:43 PDT: signaling 'Forwarding UDP daemon', pid 2320,
signal 1, status 0
commit complete
커밋된 구성을 설명하는 코멘트를 추가합니다
커밋된 구성에 대한 변경을 설명하는 코멘트를 포함할 수 있습니다. 이를 위해 commit comment 문을 포함합니다. 코멘트는 최대 512바이트이며, 한 줄에 입력해야 합니다.
[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 명령을 사용할 수도 있습니다.
일괄 커밋 개요
일괄 커밋은 여러 CLI 세션이나 사용자가 수행한 다수의 구성 편집을 어그리게이션 또는 병합하여 하나의 일괄 커밋 대기열에 추가합니다. 디바이스에서 실행되는 일괄 커밋 서버는 일괄 커밋 대기열에서 한 개 이상의 작업을 가져와 공유되는 구성 데이터베이스에 구성 변경 사항을 적용한 다음 하나의 커밋 작업에서 이러한 구성 변경 사항을 커밋합니다.
일괄 작업은 사용자가 지정한 우선 순위 또는 일괄 작업이 추가되는 시간을 기반으로 커밋 서버가 우선 순위를 지정합니다. 한 개의 일괄 커밋이 완료되면 다음 세트의 구성 변경 사항이 어그리게이션되어 일괄 커밋 작업의 다음 세션을 위한 일괄 작업 대기열에 로드됩니다. 일괄 작업은 대기열 디렉터리에 남은 커밋 항목이 없을 때까지 생성됩니다.
모든 커밋을 하나씩 순차적으로 수행하는 일반적인 커밋 작업과 비교할 때 일괄 커밋은 다수의 작은 구성 편집을 하나의 커밋 작업으로 수행하기 때문에 시간과 시스템 리소스가 절약됩니다.
일괄 커밋은 [edit batch] 구성 모드에서 수행됩니다. 커밋 서버 속성은 [edit system commit server] 계층 수준에서 구성할 수 있습니다.
어그리게이션 및 오류 처리
어그리게이션된 작업 중 하나에서 로드 시간 오류가 발생할 경우, 오류가 발생한 커밋 작업은 폐기되고 나머지 작업은 어그리게이션 및 커밋됩니다.
예를 들어, 다섯 개의 커밋 작업(commit-1, commit-2, commit-3, commit-4 및 commit-5)이 어그리게이션되는데 로드하는 중에 commit-3에 오류가 발생하면 commit-3은 폐기되고 commit-1, commit-2, commit-4 및 commit-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 커밋 오류를 보고합니다.
예: 일괄 커밋 서버 속성 구성
이 예에서는 일괄 커밋 서버 속성을 구성하여 일괄 커밋 작업을 관리하는 방법을 보여줍니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
-
MX 시리즈 5G 유니버설 라우팅 플랫폼
개요
[edit system commit server] 계층 수준에서 서버 속성을 구성하면 커밋 서버로 일괄 커밋 대기열이 처리되는 방식을 제어하실 수 있습니다. 이를 통해 하나의 일괄 커밋에 어그리게이션 또는 병합할 커밋 작업의 수, 대기열에 추가할 수 있는 최대 작업 수, 일괄 커밋 오류 로그를 보관하는 일 수, 두 개 일괄 커밋 간의 간격, 일괄 커밋 작업에 대한 추적 작업 등을 모두 제어하실 수 있습니다.
구성
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
커밋 서버 속성 구성
단계별 절차
-
(옵션) 한 개의 커밋 작업에서 어그리게이션 또는 병합할 커밋 트랜잭션의 수를 구성합니다.
maximum-aggregate-pool에 대한 기본값은5입니다.주:maximum-aggregate-pool값을1로 설정할 경우, 각 커밋 작업이 하나씩 수행됩니다.이 예에서는 커밋 트랜잭션의 수가
4로 설정되어 커밋 작업이 시작되기 전에 네 개의 커밋 작업이 하나의 커밋으로 어그리게이션됩니다.[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이며, all traceoption flag가 설정되었습니다.[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 -
일괄 커밋 작업에 더 높은 우선 순위를 지정하려면
commit명령을 실행할 때priority옵션을 함께 사용합니다.[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001 -
구성 변경 사항을 대기열의 다른 커밋 작업과 어그리게이션하지 않고 구성을 커밋하려면
commit명령을 실행할 때atomic옵션을 함께 사용합니다.[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002 -
구성 변경 사항을 대기열의 다른 커밋 작업과 어그리게이션하지 않고 해당 커밋 작업에 더 높은 우선 순위를 지정하여 구성을 커밋하려면
commit명령을 실행할 때atomic priority옵션을 함께 사용합니다.[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 ...
-
성공한 일괄 커밋 작업의 로그 항목만 보려면
file show /var/log/<filename>명령을 실행할 때| match committed파이프 옵션을 함께 사용합니다.출력 결과에 성공한 커밋 작업에 대한 일괄 커밋 작업 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 -
실패한 일괄 커밋 작업의 로그 항목만 보려면
file show /var/log/<filename>명령을 실행할 때| match “Error while”파이프 옵션을 함께 사용합니다.출력 결과에 실패한 커밋 작업에 대한 커밋 작업 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 명령을 내린 후에는 소프트웨어의 실행 및 백업 사본이 동일하므로 소프트웨어의 이전 버전으로 돌아갈 수 없습니다.