NETCONF 및 YANG API 오케스트레이션
가이드게시됨
2023-07-07
릴리스 4.2
소개
본 문서의 목적
이 문서에서는 Control Center NETCONF & YANG API를 통해 Paragon Active Assurance를 네트워크 서비스 오케스트레이터와 통합하는 방법을 설명합니다. 실습 전amp가상 테스트 에이전트 생성 및 배포, 테스트 및 모니터 실행, 이러한 활동의 결과 검색 등 관련된 주요 작업에 대한 파일이 제공됩니다.
이 문서에서는 무료로 사용 가능한 Python NETCONF 클라이언트 ncclient가 오케스트레이터 역할로 사용됩니다.
컨벤션
이 문서에서는 다음 약어가 사용됩니다.
약어 | 의미 |
CLI | 명령줄 인터페이스 |
EM | 엘리먼트 매니저 |
ES | 두 번째 오류 |
국회의원 | MEG(유지 관리 엔터티 그룹) 끝점(ITU-T Y.1731 정의) 또는 유지 관리 끝점(Cisco 정의) |
네트워크 가상화 | 네트워크 기능 가상화 |
NFVO | 네트워크 기능 가상화 조정자 |
(주)엔에스디 | 네트워크 서비스 설명자 |
한국어: | 원격 프로시저 호출 |
한모금 | 세션 개시 프로토콜 |
SLA | 서비스 수준 계약 |
S-VNFM | 특별 VNF 관리자 |
가상 네트워크 | 가상 네트워크 기능 |
vTA | 가상 테스트 에이전트 |
이전 버전과의 호환성에 대한 참고 사항
NETCONF & YANG API 버전 2.35.4/2.36.0에서는 NETCONF 표준을 준수하기 위해 특정 요청의 유효성 검사가 더욱 엄격해졌습니다. 이는 이 가이드의 이전 버전을 기반으로 하는 클라이언트 코드가 이제 거부될 수 있음을 의미합니다.
예를 들어ample, 이전 Python ex에서amp파일 코드에는 네임스페이스 속성이 제공되지 않았습니다. 이제 ConfD 리소스를 수정할 때마다 요청 XML에 네임스페이스를 제공해야 합니다.
전제 조건 및 준비
ConfD 설치
ConfD(Tail-f의 제품)는 Paragon Active Assurance 시스템과 NETCONF 간의 중개자로 사용됩니다. ConfD는 Paragon Active Assurance 구성 및 운영 데이터를 NETCONF 및 YANG API에 연결합니다.
설치 안내서에 설명된 대로 ConfD는 제어 센터 소프트웨어와 함께 설치되어야 합니다.
ConfD가 실행 중인지 확인
ConfD가 실행 중인지 확인하려면 다음 명령을 실행하십시오.
SSH -s @localhost -p 830 netconf
ConfD가 포트 830에서 응답하는지 확인합니다. 명령에서, netconf 사용자 create에 정의된 대로입니다.
설치 가이드의 ConfD 설치 섹션에 있는 명령입니다. 동일한 명령으로 정의된 비밀번호를 제공하십시오.
출력에 제어 센터 모듈이 포함되어 있는지 확인합니다. 출력에는 다음과 같은 줄이 포함되어야 합니다.
http://ncc.netrounds.com?module=netrounds-ncc&개정=2017-06-15
구성 데이터베이스를 제어 센터와 동기화
마지막으로 NETCONF를 통해 구성 데이터베이스를 업데이트해야 합니다. 여기서는 ncclient(NETCONF 클라이언트)라는 Python 라이브러리를 사용하여 이를 수행합니다. 그러나 NETCONF/YANG 프로토콜을 사용하는 한 다른 프로그래밍 언어로 작업을 수행할 수도 있습니다.
ncclient의 역할은 NETCONF/YANG API를 호스팅하는 ConfD 서버에 대한 클라이언트 역할을 하는 것입니다.
이름이 "ncc"로 시작하기는 하지만 ncclient는 Control Center(이전의 "Netrounds Control Center")와 어떤 방식으로도 관련이 없다는 점을 지적할 가치가 있습니다.
ncclient를 설치하는 방법은 다음과 같습니다.
- 소프트웨어를 다운로드하세요 https://github.com/ncclient/ncclient.
- 다음 명령을 실행하세요: pip install ncclient
이제 다음과 같이 동기화를 수행할 수 있습니다. 이 작업은 제어 센터 서버 자체가 아닌 별도의 컴퓨터에서 수행해야 한다는 점에 유의하세요.
#
# 메모:
# 이 스크립트는 NCC 서버에서 실행되는 ConfD에 대한 클라이언트 역할을 합니다.
# 통신을 위해 NETCONF/YANG API를 사용합니다.
메모: 이 절차는 NETCONF와 별도로 Test Agent를 설치하고 등록할 때마다 필요합니다. "이상" 섹션의 참고 사항을 참조하십시오.view 자세한 내용은 17페이지의 테스트 에이전트 오케스트레이션”을 참조하십시오.
여러 NETCONF 제어 Paragon 활성 보증 계정 설정
아래 단계는 설치 가이드의 "ConfD 설치" 섹션에서 이러한 방식으로 구성된 계정 외에 NETCONF에서 제어할 추가 Paragon Active Assurance 계정을 설정하려는 경우에만 필요합니다.
각 계정에 대해 다음을 수행하십시오.
- 제어 센터에서 계정에 로그인하고 계정 > 권한으로 이동합니다.
- 사용자 추가 “confd@netrounds.com"하고 초대 버튼을 클릭하여 GUI에서 이 ConfD 사용자 관리자 권한을 부여합니다.
- 4페이지의 "구성 데이터베이스와 제어 센터 동기화" 섹션에 설명된 대로 구성 데이터베이스를 제어 센터와 동기화합니다.
이제 동일한 ConfD 사용자로 여러 Paragon Active Assurance 계정을 제어할 수 있습니다.
메모: ConfD를 통해 Paragon Active Assurance 계정 제어를 시작한 후에는 다음을 통해 이 계정을 변경해서는 안 됩니다. web "config"인 Paragon Active Assurance 기능과 관련된 GUI(9페이지의 "Paragon Active Assurance에서 지원되는 기능" 장 참조) 그렇게 하면 동기화가 손실됩니다.
NETCONF 오케스트레이션 API 소개
위에view
타사 NFVO 또는 서비스 오케스트레이터는 일반적으로 Control Center API를 사용하여 테스트 및 모니터링 세션을 시작하는 구성 요소입니다. 또한 이 오케스트레이터는 테스트 에이전트 활동에서 집계된 측정 결과를 검색합니다. 성능 KPI는 타사 성능 관리 시스템에서 검색할 수 있으며, 제어 센터에 설정된 임계값 위반에 의해 트리거된 이벤트는 타사 결함 관리 시스템으로 전송될 수 있습니다.
요약하자면, 아래 그림은 Paragon Active Assurance가 OSS 환경에서 다른 타사 시스템과 상호 작용하는 방식을 보여줍니다.
- NFVO/서비스 오케스트레이터: VNF Manager에게 vTA를 배포하고 Paragon Active Assurance를 서비스 체인에 구성하도록 지시합니다. 서비스가 활성화되면 오케스트레이터는 제어 센터에 대한 API를 사용하여 서비스 활성화 테스트를 트리거하고 통과/실패 결과를 검색합니다. 테스트가 통과되면 오케스트레이터는 제어 센터에 대한 API를 사용하여 서비스의 활성 모니터링을 시작합니다. 모니터링의 KPI는 오케스트레이터 또는 별도의 성과 관리 플랫폼에 의해 지속적으로 검색됩니다.
- 제어 센터: NFVO 또는 서비스 오케스트레이터의 지시에 따라 vTA를 배포, 확장 및 종료합니다.
- 성과 관리 시스템 또는 서비스 품질 관리 시스템: Control Center API를 통해 활성 모니터링에서 KPI를 읽습니다.
- 오류 관리 시스템: SLA를 위반한 경우 제어 센터로부터 NETCONF, SNMP 또는 이메일 알림을 받습니다.
Paragon Active Assurance의 개념 정의
- 테스트 에이전트: Paragon Active Assurance 시스템에서 측정(테스트 및 모니터용)을 수행하는 구성 요소입니다. 테스트 에이전트는 실제 네트워크 트래픽을 생성, 수신 및 분석하는 기능을 갖춘 소프트웨어로 구성됩니다.
- 이 문서에서 설명하는 테스트 에이전트의 종류는 하이퍼바이저에 배포된 VNF(가상 네트워크 기능)인 vTA(가상 테스트 에이전트)입니다. 다른 유형의 테스트 에이전트도 존재합니다.
- Paragon Active Assurance에는 테스트와 모니터라는 두 가지 기본 측정 유형이 있습니다.
- 테스트: 테스트는 하나 또는 여러 단계로 구성되며 각 단계에는 지정된 유한 기간이 있습니다. 단계는 순차적으로 실행됩니다. 각 단계에는 여러 작업을 동시에 실행하는 작업이 포함될 수 있습니다.
- 모니터: 모니터는 지정된 기간이 없지만 무기한 실행됩니다. 테스트 단계와 마찬가지로 모니터는 여러 동시 작업을 실행할 수 있습니다.
- 템플릿: Paragon Active Assurance가 오케스트레이터에 의해 제어되는 경우 테스트 및 모니터는 항상 테스트 또는 모니터가 정의된 템플릿을 통해 실행됩니다. 매개변수 설정은 런타임 시 템플릿에 대한 입력으로 전달될 수 있습니다.
자동화를 위한 워크플로우
디자인 타임
디자인 타임에 Paragon Active Assurance에서 테스트 및 모니터용 템플릿을 생성하여 측정을 준비합니다. 이를 수행하는 방법은 15페이지의 "테스트 및 모니터링 템플릿" 장에서 설명됩니다.
실행 시간
런타임 시 장치를 설정하고 실제 측정을 수행합니다.
- 오버view 모두의 전amp주어진 파일은 "Ex" 장에 나와 있습니다.ampNETCONF 및 YANG API를 통한 Paragon Active Assurance 제어”(15페이지) 섹션을 참조하세요.
- 테스트 에이전트를 배포하고 구성하는 방법은 "Ex" 장에서 설명합니다.amp파일: 테스트 에이전트”(16페이지).
- TW 등의 재고 품목을 가져오는 방법AMP 반사경 및 IPTV 채널은 "Ex" 장에서 다루어집니다.amp파일: 인벤토리 항목”(29페이지).
- 알람을 구성하는 방법은 "Ex" 장에 설명되어 있습니다.amp파일: 알람”(35페이지).
- NETCONF를 통해 Paragon Active Assurance 템플릿을 실행하여 테스트 및 모니터를 실행하는 방법은 "Ex" 장에 설명되어 있습니다.amples: 테스트”(43페이지) 및 “Examp파일: 모니터”(54페이지).
Paragon Active Assurance에서 지원되는 기능
Paragon Active Assurance의 모든 테스트 및 모니터 유형은 템플릿을 사용하여 생성하고 실행할 수 있습니다. 이를 수행하는 방법은 앱 내 도움말의 "테스트 및 모니터" > "템플릿 만들기"에 설명되어 있습니다.
Paragon Active Assurance 계정 생성은 현재 지원되지 않습니다. 그러나 사용자에 대해 하나 이상의 사전 정의된 계정이 설정됩니다.
아래 표에서는 이번 릴리스에서 사용할 수 있는 Paragon Active Assurance의 기능과 이러한 기능이 YANG에 어떻게 표시되는지 자세히 설명합니다.
YANG 구성요소의 설명
편의를 위해 여기에는 기능 테이블에서 참조된 YANG 구성에 대한 정의가 제공됩니다.
- Config(config=true): 시스템을 한 상태에서 다른 상태로 변환하는 데 필요한 구성 데이터입니다.
- 상태(config=false): 상태 데이터: 읽기 전용 상태 정보, 수집된 통계 등 구성 데이터가 아닌 시스템의 추가 데이터입니다.
- RPC: NETCONF 프로토콜 내에서 사용되는 원격 프로시저 호출입니다.
- 알림: NETCONF 서버에서 NETCONF 클라이언트로 전송되는 이벤트 알림입니다.
오케스트레이션에 사용할 수 있는 Paragon Active Assurance 기능 표
자원: 모니터링
YANG 경로:/accounts/account/monitors
특징 | 하위 기능 | 양 구성 |
모니터 생성/수정/삭제 | 모니터 템플릿 기반 | 구성 |
모니터 시작/중지 | – | 구성 |
모니터 템플릿 | 입력이 포함된 기존 모니터 템플릿 나열 | 상태 |
NETCONF 알림 | 알람 상태가 변경됨 | 공고 |
결과 모니터링 | 최상위 수준에 대한 SLA/ES 카운터(%) 작업 수준에 대한 SLA/ES 카운터(%) |
상태 |
테스트(아래 리소스: 테스트 비교)와 달리 모니터는 RPC로 시작되지 않고 모니터 구성을 커밋하여 시작됩니다.
자원: 테스트
YANG 경로: /accounts/account/tests
특징 | 하위 기능 | 양 구성 |
테스트 시작 | 테스트 템플릿 기반 | 한국어: |
테스트 관리 | 상태와 함께 테스트 나열 | 상태 |
테스트 템플릿 | 입력이 포함된 기존 테스트 템플릿 나열 | 상태 |
NETCONF 알림 | 테스트 상태가 변경됨 | 공고 |
테스트 결과 | 테스트 단계 상태 가져오기(통과, 실패, 오류 등) | 상태 |
자원: 테스트 에이전트
YANG 경로:
- /accounts/account/test-agents(구성)
- /accounts/account/registered-test-agents(주)
/accounts/account/test-agents 아래의 테스트 에이전트는 계정에 구성되어 있는 에이전트입니다. 이러한 테스트 에이전트만 오케스트레이터가 NETCONF를 통해 테스트 및 모니터에서 구성하고 사용할 수 있습니다.
테스트 에이전트를 구성하고 계정에 등록하면 테스트 에이전트가 /accounts/account/registered-test-agents 아래에 표시됩니다. NETCONF에서 "get" 명령을 사용하여 등록된 모든 테스트 에이전트를 찾을 수 있습니다(Ex 장 비교).amp파일: 테스트 에이전트).
/accounts/account/registered-test-agents에서 아직 구성되지 않은 테스트 에이전트를 찾을 수도 있습니다. 이러한 테스트 에이전트를 사용하려면 먼저 구성해야 합니다.
오케스트레이션 시나리오에서는 일반적으로 NETCONF를 통해 Paragon Active Assurance 계정의 모든 구성을 수행하는 것이 좋습니다. 이렇게 하면 테스트 에이전트와 등록된 테스트 에이전트가 갈라지지 않습니다.
특징 | 하위 기능 | 양 구성 |
서버에 테스트 에이전트 사전 생성 | – | 구성 |
오프라인 테스트 에이전트 구성 | (제어 센터는 테스트 에이전트에 구성을 푸시합니다. 온라인이 되면) |
구성 |
기존/외부 구성 테스트 에이전트 사용 | 테스트/모니터링에 사용 | 구성 |
인터페이스 구성 | 구성 | |
상태 가져오기 | 상태 | |
테스트 에이전트 구성(테스트 어플라이언스에만 해당) | NTP 구성 | 구성 |
브리지 구성 | 구성 | |
VLAN 인터페이스 구성 | 구성 | |
SSH 키 구성 | 구성 | |
IPv6 | 구성 | |
유틸리티 | 재부팅 | 한국어: |
업데이트 | 한국어: | |
NETCONF 알림 | 온라인 상태가 변경됨 | 공고 |
상태 | 시스템 상태 확인(가동 시간, 메모리 사용량, 로드 평균, 버전) |
상태 |
자원: 재고
YANG 경로: /accounts/account/twamp-반사경
지원되는 NETCONF 기능
아래 표는 Paragon Active Assurance 오케스트레이션 목적으로 사용되는 NETCONF 기능을 설명하는 IETF RFC를 나타냅니다.
- ietf-netconf.yang
- IETF RFC 6241, 네트워크 구성 프로토콜(NETCONF), https://tools.ietf.org/html/rfc6241
- 지원되는 유일한 오류 처리 방법은 오류 시 롤백입니다.
- 지원되는 유일한 데이터 저장소는 쓰기 가능 실행입니다.
- ietf-netconf-notifications.yang
- IETF RFC 5277, NETCONF 이벤트 알림, https://tools.ietf.org/html/rfc5277
테스트 및 모니터링 템플릿
테스트 및 모니터 유형에 대한 템플릿은 Paragon Active Assurance 프런트엔드 사용자 인터페이스를 통해 수동으로 설정해야 합니다. 이를 수행하는 방법은 앱 내 도움말의 "테스트 및 모니터" > "템플릿 만들기"에 설명되어 있습니다.
ExampNETCONF 및 YANG API를 통한 Paragon Active Assurance 제어 파일
다음 장에서는 15페이지의 "테스트 및 모니터 템플릿" 장에 제공된 지침에 따라 적합한 테스트 및 모니터 템플릿이 정의되었다고 가정합니다.
Ex에 사용되는 도구amp레
모든 전amp이후 장의 파일은 다음과 같은 무료 도구를 사용하여 구성되었습니다.
- Pang: YANG 모델을 시각화하고 찾아보는 데 사용됩니다.
- 에서 이용 가능 https://github.com/mbj4668/pyang (git에서 복제하고 python setup.py install을 실행합니다).
- Python NETCONF 클라이언트 "ncclient": NETCONF를 사용하여 제어 센터와 통신하는 데 사용됩니다.
- https://github.com/ncclient/ncclient에서 사용 가능합니다(pip install ncclient 실행).
netrounds-ncc.yang 데이터 모델은 설치 가이드에 따라 ConfD가 설치되면 /opt/netrounds-confd에서 찾을 수 있습니다.
위에view 주요 수행업무
(다음에는 몇 가지 추가 작업도 예시되어 있습니다.)
- 16페이지의 "새 테스트 에이전트 생성 및 배포"
- 29페이지의 "인벤토리 항목(예: 반사경) 만들기"
- 35페이지의 "알람 템플릿 설정 및 알람 전송 위치"
- 45페이지의 “테스트 생성 및 실행”
- 50페이지의 "테스트 결과 검색"
- 60페이지의 "모니터 시작(알람 설정 포함)"
- 67페이지의 "모니터에 대한 SLA 상태 검색"
- “함께 작업 tags71페이지
Examples: 테스트 에이전트
위에view 테스트 에이전트 오케스트레이션
Paragon Active Assurance의 테스트 에이전트는 오케스트레이션의 맥락에서 "구성"으로 간주됩니다. 이는 테스트 에이전트의 생성, 제어 및 삭제가 Paragon Active Assurance GUI가 아닌 오케스트레이터 및 NETCONF를 통해 수행되어야 함을 의미합니다.
중요: NETCONF & YANG API를 통해 먼저 테스트 에이전트를 생성하지 않고 기술자가 테스트 에이전트를 설치하고 제어 센터에 등록한 경우 테스트 에이전트가 구성 데이터베이스에 존재하지 않으며 시스템이 동기화되지 않습니다. 이 경우 ConfD가 테스트 에이전트를 인식하려면 4페이지의 "구성 데이터베이스를 제어 센터와 동기화" 섹션에 설명된 대로 제어 센터와 새로운 동기화를 수행해야 합니다.
따라서 vTA(가상 테스트 에이전트)의 오케스트레이션은 다음 단계에 따라 수행되어야 합니다.
- 제어 센터에 대한 NETCONF 및 YANG 인터페이스를 사용하여 인터페이스 구성을 포함하여 가상 테스트 에이전트를 생성합니다. 테스트 에이전트의 이름은 고유 키가 됩니다.
- 가상화 플랫폼에 vTA를 배포합니다. 테스트 에이전트 > 설치 아래의 온라인 도움말 지침을 따르세요. vTA가 제어 센터에 연결할 수 있도록 하는 기본 인터페이스 구성과 인증을 위한 자격 증명은 cloud-init 사용자 데이터를 사용하여 vTA에 제공됩니다.
vTA가 부팅되면 암호화된 OpenVPN 연결을 사용하여 제어 센터에 자동으로 연결됩니다. 이제 vTA의 test-agent-statuschange 매개변수 값이 "online"으로 변경되었으므로 NETCONF 알림이 전송됩니다.
메모: vTA의 이름은 제어 센터의 식별자이므로 이 이름은 1페이지의 "17단계"에서 제어 센터에 정의된 이름과 동일해야 합니다. - vTA가 제어 센터에 연결되고 인증되면 인터페이스 구성이 vTA에 푸시됩니다. 이는 제어 센터에서 vTA가 생성될 때 1페이지의 "17단계"에서 제공되는 인터페이스 구성입니다.
- vTA가 해당 목적을 달성한 후 vTA를 삭제합니다.
새 테스트 에이전트 생성 및 배포
먼저 제어 센터에 대한 NETCONF 및 YANG 인터페이스를 사용하여 테스트 에이전트를 생성해야 합니다. 이러한 방식으로 테스트 에이전트가 생성되면 제어 센터와의 동기화가 필요하지 않습니다.
테스트 에이전트의 YANG 모델은 아래와 같습니다. 명령의 출력으로 얻습니다.
pyang -f tree netrounds-ncc.yang
전체 YANG 모델은 81페이지의 "부록: 전체 YANG 모델의 트리 구조"에 나와 있으며, 여기에는 이 문서와 현재 문서의 다른 YANG 모델 그림에 사용된 규칙을 설명하는 범례도 포함되어 있습니다.
우리는 다음 단계를 진행하며 이에 대한 자세한 내용은 다음과 같습니다.
- 처음에는 Paragon Active Assurance 계정 "데모"의 인벤토리에 테스트 에이전트가 없습니다.
- ncclient를 사용하여 "vta1"이라는 테스트 에이전트가 생성됩니다. 이 시간에tag즉, 실제 테스트 에이전트가 아직 존재하지 않습니다(즉, 아직 시작되지 않았습니다).
- 테스트 에이전트는 OpenStack에 배포됩니다. (해당 플랫폼에서의 배포는 여기에서 여러 가지 가능성 중 하나로 선택되었습니다.)
- 테스트 에이전트는 Control Center 계정 “demo”에 연결되어 이제 사용할 준비가 되었습니다.
1단계: 처음에는 "데모" 계정에 테스트 에이전트가 없습니다. 제어 센터 GUI에서 아래 스크린샷을 참조하세요.2단계: Python NETCONF 클라이언트 "ncclient"를 사용하여 제어 센터에서 테스트 에이전트가 생성됩니다. 다음은 DHCP 주소가 있는 하나의 물리적 인터페이스가 있는 테스트 에이전트를 생성하기 위한 ncclient 코드입니다.
argparse 가져오기
ncclient 가져오기 관리자에서
파서 = argparse.ArgumentParser(description='테스트 에이전트 생성 테스트')
parser.add_argument('–host', help='ConfD가 발견된 호스트 이름', 필수=True)
parser.add_argument('–port', help='ConfD에 연결할 포트', 필수=True)
parser.add_argument('–username', help='ConfD에 연결하기 위한 사용자 이름', 필수=True)
parser.add_argument('–password', help='ConfD 계정의 비밀번호', 필수=True)
parser.add_argument('–netrounds-account', help='NCC 계정의 짧은 이름', 필수=True)
parser.add_argument('–test-agent-name', help='테스트 에이전트 이름', 필수=True)
인수 = 파서.파싱_인수()
Manager.connect(호스트=args.host, 포트=args.port, 사용자 이름=args.username,
비밀번호=args.password, hostkey_verify=False)를 m으로 지정:
# 제어 센터에서 테스트 에이전트 생성
xml = “””
) m.edit_config(target='running', config=xml) 인쇄
메모: Manager.connect(…) 이전 코드는 후속 ex에서 생략됩니다.amp코드 조각.
eth0에는 NTP 서버가 구성되어 있으며 eth0은 관리 인터페이스(즉, Control Center에 연결하는 인터페이스)이기도 합니다.
테스트 에이전트 애플리케이션은 현재 인터페이스 구성을 허용하지 않습니다. 이러한 이유로 버전 2.34.0부터는 YANG 스키마에서 인터페이스 구성을 생략할 수 있습니다. 따라서 이 경우 해당 XML은 근본적으로 단순화됩니다.테스트 에이전트가 생성되면 구성 데이터베이스와 제어 센터에 존재합니다. 테스트 에이전트 "vta1"을 보여주는 테스트 에이전트 인벤토리의 아래 스크린샷을 참조하세요.
3단계: 이제 OpenStack에 테스트 에이전트 “vta1”을 배포할 시간입니다.
테스트 에이전트는 cloud-init 사용자 데이터를 사용하여 제어 센터에 연결하는 방법에 대한 정보를 검색합니다. 특히 사용자 데이터 텍스트는 file 다음 내용이 있습니다(#cloud-config 및 netrounds_test_agent 행이 있어야 하며 나머지 행은 들여쓰기되어야 함).
자세한 내용은 OpenStack에서 가상 테스트 에이전트를 배포하는 방법 문서를 참조하세요.
테스트 에이전트가 배포되고 제어 센터에 연결되면 구성이 제어 센터에서 테스트 에이전트로 푸시됩니다.
4단계: 테스트 에이전트는 이제 제어 센터에서 온라인 상태이며 해당 구성을 얻었습니다. 테스트 에이전트를 테스트 및 모니터링에 사용할 준비가 되었습니다. 다음 섹션을 참조하세요.
- 45페이지의 "테스트 시작"
- 60페이지의 "모니터 시작"
Paragon Active Assurance 계정에 테스트 에이전트 나열
아래는 예입니다ample ncclient Paragon Active Assurance 계정의 테스트 에이전트를 나열하기 위한 Python 코드:
이 코드를 실행하면 아래와 같은 출력이 표시됩니다.
테스트 에이전트 삭제
테스트가 완료된 후 일부 사용 사례에서는 테스트 에이전트를 삭제하는 것이 관련될 수 있습니다.
다음은 ncclient로 이 작업을 수행하는 방법을 보여주는 코드 조각입니다.
NETCONF 알림
아래에서는 간단한 예를 제시합니다.amp제어 센터에서 들어오는 모든 NETCONF 알림을 수신하기 위한 파일 스크립트입니다. 이러한 알림은 테스트 에이전트가 오프라인 상태가 되거나 사용자가 시작한 테스트가 완료되는 등 특정 이벤트가 발생할 때마다 전송됩니다. 알림에 포함된 정보를 기반으로 사용자는 오케스트레이터에서 자동화된 후속 작업을 할당할 수 있습니다.
위 스크립트가 실행되면 NC 클라이언트는 수신된 알림을 구조화된 XML로 표시합니다. 전 애인을 만나보세요amp아래 파일 출력에는 테스트 에이전트가 예기치 않게 오프라인 상태가 되는 것을 보여줍니다.
2017-02-03T15:09:55.939156+00:00</eventTime>
<test-agent-status-change xmlns=’http://ncc.netrounds.com'>
데모
HW1
오프라인
Examples: 인벤토리 아이템
TW 등 재고 품목 생성(가져오기) 및 관리AMP 반사경 및 Y.1731 MEP는 테스트 에이전트와 유사한 방식으로 수행됩니다. 다음은 NETCONF & YANG API를 통해 Paragon Active Assurance에서 해당 엔터티를 정의하고 정의된 항목 목록을 검색하기 위한 XML 및 NETCONF 코드입니다.
TW 만들기AMP 반사기
Y.1731 MEP 만들기
IPTV 채널 생성
핑 호스트 생성
SIP 계정 만들기
재고 품목 검색
다음은 계정에 정의된 모든 인벤토리 항목을 검색하기 위한 Python 코드입니다. (문서에서 일부 반복을 피하기 위해 모든 유형의 인벤토리 항목을 한 번에 가져옵니다. 당연히 아래 계정의 일부 줄을 생략하여 인벤토리 항목의 하위 집합을 가져올 수 있습니다.)
이 코드를 실행하면 아래와 같은 출력이 표시됩니다.
Examp레: 알람
알람 템플릿 및 관련 항목(SNMP 관리자, 알람 이메일 목록)은 인벤토리 항목과 유사한 방식으로 생성 및 관리됩니다. 이 장에는 NETCONF & YANG API를 통해 Paragon Active Assurance에서 해당 엔터티를 정의하고 정의된 항목 목록을 검색하기 위한 XML 및 NETCONF 코드가 포함되어 있습니다.
알람 이메일 목록
알람 이메일 목록 생성
모든 알람 이메일 목록 검색
SNMP 관리자
SNMP 관리자 생성
모든 SNMP 관리자 검색
경보 템플릿
경보 템플릿 생성
모든 경보 템플릿 검색
Examp파일: SSH 키
NETCONF & YANG API를 통해 테스트 에이전트에 SSH 공개 키를 추가할 수 있습니다. 해당 개인 키를 사용하면 SSH를 통해 테스트 에이전트에 로그인할 수 있습니다.
SSH 키에 사용 가능한 작업의 전체 목록은 다음과 같습니다.
- SSH 키 추가
- SSH 키 수정
- SSH 키 검사
- SSH 키 나열
- SSH 키를 삭제합니다.
아래에는 추가 및 삭제 작업이 예시되어 있습니다.

SSH 키 삭제
SSH 키를 삭제하려면 다음 명령을 사용하십시오.
Examp레: 테스트
여기서는 17페이지의 "새 테스트 에이전트 생성 및 배포" 섹션에 따라 테스트 에이전트(테스트에 필요한 만큼)가 생성되었다고 가정합니다.
테스트를 위한 YANG 모델 경로
목 | YANG 모델 경로: /accounts/account/tests … |
테스트 | /. |
테스트[ID] | /시험 |
id | /테스트/ID |
이름 | /테스트/이름 |
상태 | /테스트/상태 |
시작 시간 | /테스트/시작 시간 |
종말 | /테스트/종료 시간 |
보고서-url | /시험 보고서-url |
단계 | /테스트/단계 |
단계[ID] | /테스트/단계/단계 |
이름 | /테스트/단계/단계/이름 |
id | /테스트/단계/단계/ID |
시작 시간 | /테스트/단계/단계/시작 시간 |
종말 | /테스트/단계/단계/종료 시간 |
상태 | /테스트/단계/단계/상태 |
상태 메시지 | /테스트/단계/단계/상태 메시지 |
템플릿 | /템플릿 |
템플릿[이름] | /템플릿/템플릿 |
이름 | /템플릿/템플릿/이름 |
설명 | /템플릿/템플릿/설명 |
매개변수 | /템플릿/템플릿/매개변수 |
매개변수[키] | /템플릿/템플릿/매개변수/매개변수 |
열쇠 | /템플릿/템플릿/매개변수/매개변수/키 |
유형 | /템플릿/템플릿/매개변수/매개변수/유형 |
테스트 오케스트레이션을 위한 전제 조건
- NC 클라이언트를 사용하여 NETCONF를 통해 테스트를 시작하려면 먼저 앱 내 도움말의 "테스트 및 모니터" > "템플릿 생성"에 자세히 설명된 대로 제어 센터 GUI를 사용하여 테스트 템플릿을 구축해야 합니다. 해당 템플릿에 "템플릿 입력"으로 지정된 모든 필드는 테스트 템플릿 시작을 조정할 때 XML의 매개변수로 필요합니다.
- Paragon Active Assurance에서 테스트를 실행하는 것은 오케스트레이션의 맥락에서 "상태"로 간주됩니다. 상태 데이터는 구성 데이터베이스에 저장되지 않는 쓰기 불가능한 데이터입니다.view 이는 기본적으로 제어 센터 GUI의 테스트 또는 템플릿을 변경해도 제어 센터와 구성 데이터베이스 간에 동기화 관련 문제가 발생하지 않음을 의미합니다.
- 신고를 받으러-URL 테스트 보고서에서 바로 제어 센터를 확인해야 합니다. URL 올바르게 구성되었습니다. 이 작업은 다음에서 수행됩니다. file /opt/netrounds-confd/settings.py. 기본적으로 제어 센터 호스트 이름은 소켓.gethostname()을 사용하여 검색됩니다. 아래를 참조하세요. 올바른 결과가 나오지 않으면 호스트 이름(또는 전체 이름)을 설정해야 합니다. URL) 수동으로 file.
# URL 슬래시 없이 제어 센터를 표시합니다.
# 이건 예를 위한 거야amp테스트 보고서에 사용된 파일-url.
HOSTNAME = 소켓.gethostname()
네트워크_URL = 'https://%s' % 호스트 이름
테스트 시작
17페이지의 "새 테스트 에이전트 생성 및 배포" 섹션에 설명된 대로 pang -f tree netrounds-ncc.yang 명령을 실행합니다.
YANG 모델을 출력하기 위해 /opt/netrounds-confd/ 디렉토리에서. 이 모델에서 NC 클라이언트를 사용하여 테스트를 시작하기 위한 RPC는 다음과 같습니다.
설명은 해당 섹션을 참조하세요. 81페이지의 "범례" 부록에 나와 있습니다.
다음 단계는 다음과 같습니다.
- 테스트 에이전트가 Paragon Active Assurance 계정에 등록되었지만 아직 테스트가 시작되지 않았습니다.
- 필수 입력 매개변수는 실행될 테스트 템플릿에서 식별됩니다.
- ncclient를 사용하여 60초 HTTP 테스트가 시작됩니다.
단계 1: 처음에는 Paragon Active Assurance 계정에서 테스트가 시작되지 않았습니다. 제어 센터 GUI에서 아래 스크린샷을 참조하세요.
단계 2: 이 예제에서 테스트를 시작하는 데 사용할 템플릿amp파일은 HTTP 테스트 템플릿입니다. 두 개의 필수 입력 필드(클라이언트 및 URL) 이는 제어 센터 GUI에서 템플릿을 구축할 때 지정했습니다.
NETCONF 관리자(ncclient)가 구성 데이터베이스와 통신하는 XML 구성에서 이러한 매개변수를 정의합니다.
3단계: ncclient를 사용하여 HTTP 테스트가 시작됩니다.
아래는 예입니다ampHTTP 테스트 템플릿에 필요한 구성 정보와 매개변수가 지정된 파일 코드입니다. 템플릿이 구축된 방식에 따라 여기의 세부정보가 다를 수 있습니다.
각 매개변수에 대해 속성을 제공해야 합니다. 키는 매개변수의 키와 동일합니다.
제어 센터의 변수 이름. 다음과 같이 변수 이름을 검사할 수 있습니다.
- 사이드바에서 테스트를 클릭하고 새 테스트 시퀀스를 선택합니다.
- 내 템플릿을 클릭합니다.
- 관심 있는 템플릿 아래의 편집 링크를 클릭하세요.
- 오른쪽 상단에 있는 입력 편집 버튼을 클릭하세요.
우리의 전amp파일이며 기본적으로 변수 이름은 제어 센터에 표시되는 표시 이름의 소문자 버전입니다(“url"대"URL", 등.). 그러나 제어 센터 GUI에서는 변수 이름을 원하는 대로 바꿀 수 있습니다.
키 외에도 각 매개변수에는 해당 유형이 지정되어야 합니다. 예를 들어amp르, 에 대한 URL.
다시 해야 한다는 점에 유의하세요.view 유형에 대한 전체 정보를 얻으려면 완전한 YANG 모델을 사용하십시오. 테스트 에이전트 인터페이스의 경우 유형은 다음에서 알 수 있듯이 더 복잡한 구조를 갖습니다. 아래 코드에서.
이제 ncclient를 사용하여 스크립트를 실행할 수 있습니다. 모든 것이 정확하다고 가정하면 테스트가 시작되고 제어 센터에 실행이 표시됩니다.테스트가 성공적으로 시작되면 Control Center는 테스트 ID로 응답합니다. 이 전에서ample, 테스트 ID는 3입니다.
테스트 ID는 다음에서도 확인할 수 있습니다. URL 제어 센터 GUI에서 테스트합니다. 이 전에서amp르, 그거 URL https://host/demo/testing/3/입니다.
테스트 결과 검색
테스트 결과를 검색하는 가장 간단한 방법은 테스트 ID를 가리키는 것입니다.
다음은 ID = 3인 위 HTTP 테스트의 결과를 가져오기 위한 Python 코드입니다.
매니저와 함께. m으로 연결(host=args.host, port=args.port, 사용자 이름=args.username,password=args.password, hostkey_verify=False):
출력은 다음과 같습니다.
테스트 템플릿 내보내기 및 가져오기
테스트 템플릿은 JSON 형식으로 내보내고 해당 형식으로 제어 센터로 다시 가져올 수 있습니다. 이는 다른 제어 센터 설치에서 테스트 템플릿을 사용하려는 경우에 유용합니다. (템플릿의 초기 생성은 제어 센터 GUI를 통해 가장 잘 처리됩니다.)
다음은 내보내기 및 가져오기를 수행하는 코드입니다.
테스트 템플릿 내보내기
# 응답에서 json 구성을 가져옵니다.
루트 = ET.fromstring(response._raw)
json_config = 루트[0].text
json_config 인쇄
템플릿은 json_config 개체에 포함되어 있습니다.
테스트 템플릿 가져오기
테스트 템플릿이 포함된 JSON 구성 개체를 다음과 같이 제어 센터로 다시 가져올 수 있습니다.
Examp파일: 모니터
이 섹션에서는 17페이지의 "새 테스트 에이전트 생성 및 배포" 섹션에 따라 테스트 에이전트(모니터에 필요한 만큼)가 생성되었다고 가정합니다.
모니터용 YANG 모델 경로
목 | YANG 모델 경로: /accounts/account/monitors … |
모니터 | /. |
모니터[이름] | /감시 장치 |
이름 | /모니터/이름 |
설명 | /모니터/설명 |
시작했다 | /모니터/시작됨 |
주형 | /모니터/템플릿 |
알람 구성 | /모니터/alarm-configs |
목 | YANG 모델 경로: /accounts/account/monitors/monitor/alarm-configs … |
알람 구성[식별자] | /알람-구성 |
식별자 | /alarm-config/식별자 |
주형 | /alarm-config/템플릿 |
이메일 | /alarm-config/이메일 |
SNMP를 | /alarm-config/snmp |
매우 심각한 | /alarm-config/thr-es-중요 |
임계값-클리어 | /alarm-config/thr-es-중요-클리어 |
전공 | /alarm-config/thr-es-major |
주요 클리어 | /alarm-config/thr-es-major-clear |
미성년자 | /alarm-config/thr-es-minor |
thr-es-minor-clear | /alarm-config/thr-es-minor-clear |
경고 | /alarm-config/thr-es-경고 |
경고-해제 | /alarm-config/thr-es-warning-clear |
데이터 심각도 없음 | /alarm-config/no-data-심각도 |
데이터 없음 시간 초과 | /alarm-config/no-data-timeout |
행동 | /alarm-config/액션 |
창 크기 | /alarm-config/window-size |
간격 | /알람-구성/간격 |
한 번만 보내기 | /alarm-config/send-only-once |
스트림당 snmp 트랩 | /alarm-config/snmp-trap-per-stream |
목 | YANG 모델 경로: /accounts/account/monitors … |
매개변수 | /모니터/매개변수 |
목 | YANG 모델 경로: /accounts/account/monitors/monitor/parameters … |
매개변수[키] | /매개변수 |
열쇠 | /매개변수/키 |
(값 유형) | /매개변수 |
:(정수) | /매개변수 |
정수 | /매개변수/정수 |
:(뜨다) | /매개변수 |
뜨다 | /매개변수/부동 |
:(끈) | /매개변수 |
목 | YANG 모델 경로: /accounts/account/monitors/monitor/parameters … |
끈 | /매개변수/문자열 |
:(테스트 에이전트 인터페이스) | /매개변수 |
테스트 에이전트 인터페이스 | /매개변수/테스트 에이전트-인터페이스 |
test-agent-interface[1페이지의 "58" | /매개변수/테스트 에이전트-인터페이스/ |
계정 | /매개변수/테스트-에이전트-인터페이스/테스트-에이전트-인터페이스/계정 |
테스트 에이전트 | /매개변수/테스트-에이전트-인터페이스/테스트-에이전트-인터페이스/테스트-에이전트 |
인터페이스 | /매개변수/테스트-에이전트-인터페이스/테스트-에이전트-인터페이스/인터페이스 |
IP 버전 | /매개변수/테스트-에이전트-인터페이스/테스트-에이전트-인터페이스/ip-버전 |
:(twamp-반사경) | /매개변수 |
twamp-반사경 | /매개변수/twamp-반사경 |
twamp-반사체[이름] | /매개변수/twamp-반사경/twamp-반사기 |
이름 | /매개변수/twamp-반사경/twamp-반사체/이름 |
:(y1731-meps) | /매개변수 |
y1731-meps | /매개변수/y1731-meps |
y1731-mep[이름] | /매개변수/y1731-meps/y1731-mep |
이름 | /매개변수/y1731-meps/y1731-mep/이름 |
:(sip-계정) | /매개변수 |
한 모금 계좌 | /매개변수/sip-계정 |
sip-계정[2페이지의 "58"] | /매개변수/sip-계정/sip-계정 |
계정 | /매개변수/sip-계정/sip-계정/계정 |
테스트 에이전트 | /매개변수/sip-계정/sip-계정/테스트-에이전트 |
인터페이스 | /매개변수/sip-계정/sip-계정/인터페이스 |
한 모금 주소 | /매개변수/sip-계정/sip-계정/sip-주소 |
:(iptv 채널) | /매개변수 |
IPTV 채널 | /매개변수/iptv-채널 |
IPTV 채널[이름] | /매개변수/iptv-채널/iptv-채널 |
이름 | /매개변수/iptv-채널/iptv-채널/이름 |
- 계정 테스트 에이전트 인터페이스
- 계정 테스트 에이전트 인터페이스 sip 주소
목 | YANG 모델 경로: /accounts/account/monitors … |
상태 | /모니터/상태 |
마지막 15분 | /monitor/status/마지막-15분 |
상태 | /모니터/상태/지난 15분/상태 |
상태-가치 | /모니터/상태/마지막-15분/상태-값 |
지난 시간 | /모니터/상태/지난 시간 |
상태 | /모니터/상태/지난 시간/상태 |
상태-가치 | /모니터/상태/지난 시간/상태-값 |
지난 24시간 | /모니터/상태/지난 24시간 |
상태 | /모니터/상태/지난 24시간/상태 |
상태-가치 | /모니터/상태/지난 24시간/상태-값 |
템플릿 | /템플릿 |
템플릿[이름] | /템플릿/템플릿 |
이름 | /템플릿/템플릿/이름 |
설명 | /템플릿/템플릿/설명 |
매개변수 | /템플릿/템플릿/매개변수 |
매개변수[키] | /템플릿/템플릿/매개변수/매개변수 |
열쇠 | /템플릿/템플릿/매개변수/매개변수/키 |
유형 | /템플릿/템플릿/매개변수/매개변수/유형 |
모니터 오케스트레이션을 위한 전제 조건
ncclient를 사용하여 NETCONF를 통해 모니터를 시작하려면 앱 내 도움말의 "테스트 및 모니터" > "템플릿 생성"에 설명된 대로 제어 센터 GUI에서 모니터 템플릿을 구축해야 합니다. 해당 템플릿에서 "템플릿 입력"으로 지정된 모든 필드는 템플릿 시작을 조정할 때 XML의 매개변수로 필요합니다.
모니터 템플릿에서 입력 매개변수 가져오기
아래에는 두 개의 템플릿이 표시됩니다. 첫 번째는 두 개의 테스트 에이전트 인터페이스 간의 UDP 모니터링을 위한 것이고, 두 번째는 단일 테스트 에이전트 인터페이스를 사용하는 HTTP를 위한 것입니다.
템플릿의 입력 매개변수를 찾으려면 템플릿을 나타내는 상자를 클릭하세요. HTTP 템플릿의 경우 매개변수는 다음과 같습니다.
모니터를 시작할 때 다음 단계에서 이러한 매개변수를 정의해야 합니다.
모니터 시작
17페이지의 "새 테스트 에이전트 생성 및 배포" 섹션에서 정의하고 배포한 테스트 에이전트를 사용하면 아래와 같이 "HTTP" 템플릿에서 모니터를 시작할 수 있습니다.
각 매개변수에 대해 속성을 제공해야 합니다. 키는 제어 센터의 매개변수 변수 이름과 동일합니다. 다음과 같이 변수 이름을 검사할 수 있습니다.
- 사이드바에서 모니터링을 클릭하고 새 모니터를 선택합니다.
- 내 템플릿을 클릭합니다.
- 관심 있는 템플릿 아래의 편집 링크를 클릭하세요.
- 오른쪽 상단에 있는 입력 편집 버튼을 클릭하세요.
우리의 전amp파일이며 기본적으로 변수 이름은 제어 센터에 표시되는 표시 이름의 소문자 버전입니다(“url"대"URL", 등.). 그러나 제어 센터 GUI에서는 변수 이름을 원하는 대로 바꿀 수 있습니다.
키 외에도 각 매개변수에는 해당 유형이 지정되어야 합니다. 예를 들어amp르, 에 대한 URL. 매개변수 유형에 대한 전체 정보는 YANG 모델에서 찾을 수 있습니다. 테스트 에이전트 인터페이스의 경우 유형은 아래 코드에서 알 수 있듯이 더 복잡한 구조를 갖습니다.
예전에는amp다음 파일에는 모니터와 관련된 알람이 없습니다. 예를 들어amp알람과 관련된 파일을 보려면 62페이지의 "알람과 함께 모니터 시작" 섹션으로 이동하십시오.
알람으로 모니터 시작
경보를 모니터와 연결하려면 정의된 경보 템플릿을 가리키거나 모니터를 생성할 때 전체 경보 구성을 제공할 수 있습니다. 우리는 전 애인 하나를 줄 것이다amp아래의 각 접근 방식에 대해 설명합니다.
경보 템플릿을 지정하여 모니터 경보 설정
알람 템플릿을 사용하려면 해당 ID를 알아야 합니다. 이를 위해 먼저 39페이지의 "모든 경보 템플릿 검색" 섹션에 설명된 대로 모든 경보 템플릿을 검색하고 관련 템플릿의 이름을 기록해 두십시오. 그런 다음 해당 템플릿을 다음과 같이 참조할 수 있습니다.
직접 구성하여 모니터 알람 설정y
또는 모니터를 생성할 때 경보 템플릿을 참조하지 않고 전체 구성을 제공하여 모니터에 대한 경보를 설정할 수 있습니다. 이는 다음 예와 같이 수행됩니다.amp르.
실행 중인 모니터 검색
현재 실행 중인 모든 모니터를 검색하려면 다음 스크립트를 실행하세요.
매니저와 함께. connect(host=args.host, port=args.port, 사용자 이름=args.사용자 이름, 비밀번호=args.password, hostkey_verify=False)를 m으로 사용:
출력은 아래와 같이 실행 중인 모든 모니터의 목록입니다.
모니터의 SLA 상태 검색
모니터의 SLA 상태를 검색하는 방법은 다음과 같습니다. 이 전에서amp파일에서는 지난 15분, 지난 24시간, 지난 XNUMX시간의 세 가지 간격으로 모니터 "네트워크 품질"에 대한 SLA 상태를 검색합니다.
출력은 다음과 같습니다.
NETCONF 알림
모니터에 대한 NETCONF 알림은 SLA 위반으로 인해 트리거됩니다. 이는 모니터의 SLA가 기본적으로 지난 15분 동안 지정된 기간 내에 SLA 임계값("양호" 또는 "허용") 아래로 떨어질 때 발생합니다. SLA 위반 알림은 문제로 인해 서비스가 영향을 받은 후에 빠르게 표시되는 반면, SLA 상태는 15분 후에 추가 위반이 발생하지 않는 경우에만 "양호"로 되돌아갑니다.
시간 창은 SLA_STATUS_WINDOW(초 단위 값) 설정을 편집하여 변경할 수 있습니다. /etc/netrounds/netrounds.conf.
모니터 템플릿 내보내기 및 가져오기
이는 테스트 템플릿과 정확히 동일한 방식으로 수행됩니다. 52페이지의 "테스트 템플릿 내보내기 및 가져오기" 섹션을 비교하십시오. 아래 코드 조각은 모니터용 템플릿을 내보내고 가져오는 방법을 보여줍니다.
모니터 템플릿 내보내기
모니터 템플릿 가져오기
Tags Paragon Active Assurance에 정의된 내용은 다음에 적용될 수 있습니다.
- 모니터
- 모니터 템플릿
- 테스트 에이전트
- TWAMP 반사경
- 핑 호스트.
예를 들어amp르, 당신은 할 수 있습니다 tag 같은 모니터 tag 모니터를 실행할 테스트 에이전트의 하위 집합으로 사용됩니다. 이 기능은 정의된 모니터와 템플릿 수가 많은 경우 특히 유용합니다.
모니터에 대해 SNMP 트랩이 포함된 경보를 설정한 경우 SNMP 트랩도 동일한 방식으로 할당됩니다. tags 모니터로(있는 경우)
생성 Tags
아래에서는 tag XML에 정의된 이름과 색상을 사용합니다.tag> 하부 구조.
할당 Tag
할당하려면 tag 리소스에 새 리소스로 추가tag> 아래 요소tags> 해당 리소스에 대한 요소입니다.
할당하는 방법은 다음과 같습니다. tag 테스트 에이전트에게:
할당하려면 tag TW로AMP 반사경에서 다음을 수행하십시오.
할당 tag 모니터에 대한 처리도 유사하게 처리됩니다.
또는 기존 tag 리소스를 생성할 때 다음을 포함하여 이러한 리소스 유형 중 하나에 추가합니다.tags> 다음을 포함하는 요소 tag 문제의.
업데이트 중 Tag
기존 업데이트 tag 새로운 속성을 사용하는 것은 tag:
할당 해제 Tag
할당을 취소하려면 tag 리소스에서 nc:Operation=”delete” 속성을tag> 리소스에 속하는 요소입니다. 아래에서는 할당을 해제합니다. tag 모니터에서.
삭제 Tag
삭제하려면 tag Control Center에서 완전히 nc:Operation=”delete” 속성이 다시 사용되지만 이번에는 tag 자체, 아래에 정의됨 .
문제 해결
문제: Orchestrator와 Paragon Active Assurance가 동기화되지 않음
오케스트레이터와 Paragon Active Assurance는 예를 들어 동기화되지 않을 수 있습니다.amp파일은 Control Center GUI에서 구성이 변경된 경우 또는 구성 적용에 실패하여 이전 상태로 롤백하는 데 실패한 경우입니다.
롤백이 실패한 경우 NETCONF 서버는 더 이상 구성 변경을 허용하지 않습니다. 다시 동기화될 때까지 구성이 잠겨 있다는 오류 메시지로 응답합니다. 다시 동기화하고 구성 변경 사항을 잠금 해제하려면 제어 센터의 모든 구성을 구성 데이터베이스로 동기화하는 rpc sync-from-ncc 명령을 실행해야 합니다.
메모: 그만큼 confd@netrounds.com 모든 것을 성공적으로 동기화하려면 사용자(또는 구성된 모든 항목)에게 수퍼유저 권한이 있어야 합니다. 이는 ncc user-update 명령을 사용하여 수행할 수 있습니다. confd@netrounds.com –is-superuser 사용자가 슈퍼유저가 아닌 경우 모든 항목을 동기화할 수는 없지만 처리할 수 있는 항목은 모두 동기화했다는 경고가 표시됩니다.
메모: 오케스트레이터가 구성도 저장하는 경우 요청된 구성(오케스트레이터가 제어 센터에 있을 것으로 예상하는 구성)이 적용되지 않았으므로 해당 구성도 다시 동기화해야 합니다.
문제: 지원되지 않는 리소스로 인해 초기 동기화(sync-from-ncc)가 실패했습니다.
제어 센터 GUI에서 구성이 생성된 계정에서 rpc sync-from-ncc를 실행하려고 하면 계정에 지원되지 않는 리소스가 포함되어 있으면 문제가 발생할 수 있습니다. 빈 계정으로 시작하고 NETCONF를 통해 모든 구성을 수행하는 것이 좋습니다. 그렇지 않고 리소스 충돌 문제가 발생하면 계정에서 충돌하는 리소스를 제거해야 합니다.
문제: ncclient.Operations.rpc.RPCError로 인해 NETCONF 명령이 실패합니다. 애플리케이션 통신 실패
NETCONF 서버는 제어 센터가 다시 시작되는 경우 제어 센터 서버에 대한 연결을 자동으로 복원하지 않습니다. 제어 센터에 대한 연결을 복원하려면 NETCONF 프로세스를 다시 시작하십시오. sudo systemctl restart netrounds-confd
테스트 에이전트 애플리케이션 및 테스트 에이전트 어플라이언스에 대한 참고 사항
ConfD의 테스트 에이전트 애플리케이션
테스트 에이전트 중에서 (최신) 테스트 에이전트 애플리케이션은 (이전) 테스트 에이전트 어플라이언스와 약간 다르게 작동합니다.
테스트 에이전트 애플리케이션은 현재 인터페이스 구성을 지원하지 않습니다. 따라서 YANG 스키마를 사용하면 이러한 테스트 에이전트에 대해 빈 인터페이스 구성을 지정할 수 있습니다. 예제는 23페이지의 "이 구절"을 참조하세요.amp르.
sync-from-ncc 명령을 사용하여 ConfD 데이터베이스를 제어 센터와 동기화할 때 인터페이스 구성을 빈 상태로 유지하고 제어 센터에 있는 구성으로 덮어쓰지 않기를 원합니다. 따라서 테스트 에이전트 애플리케이션으로 작업할 때 해당 명령과 함께 특수 플래그 –without_interface_config를 사용해야 합니다.
테스트 에이전트 어플라이언스에 대한 빈 인터페이스 구성
위에서 언급한 것처럼 테스트 에이전트 애플리케이션은 인터페이스 구성을 지원하지 않으므로 YANG 스키마에서 인터페이스를 생략할 수 있습니다.
그러나 Test Agent Appliance에서 인터페이스 구성을 생략하려는 사용 사례도 있습니다. 전 애인amp이 파일은 cloud-init를 사용하여 테스트 에이전트를 가동하고 테스트 에이전트가 온라인 상태가 될 때 ConfD가 이를 덮어쓰도록 하는 대신 인터페이스 구성을 사용하려는 오케스트레이션 시나리오일 수 있습니다.
정의되지 않은 인터페이스와 관련된 YANG 스키마 변경
이제 빈 인터페이스 구성이 허용되므로(버전 2.34.0부터) 테스트 또는 모니터의 일부로 실행되는 작업에 대한 입력으로 인터페이스 이름을 지정할 수 있습니다.
테스트 에이전트 응용 프로그램을 사용하려면 ConfD에 인터페이스 이름이 정의되어 있지 않으므로 이는 필요합니다. 그러나 이는 실수로 존재하지 않는 인터페이스를 사용하도록 테스트 또는 모니터를 구성하는 경우 문제가 발생할 수 있음을 의미합니다. 그러니 이 점을 유의하시기 바랍니다.
ConfD에서 생성된 테스트 에이전트 등록 시 제한 사항
REST 또는 NETCONF/YANG API를 통해 테스트 에이전트를 생성할 때 테스트 에이전트 어플라이언스 또는 테스트 에이전트 애플리케이션 유형이 무엇인지 미리 알 수 없습니다. 이는 테스트 에이전트가 등록된 후에만 명확해집니다.
테스트 에이전트가 등록되고 이러한 구체적인 유형 중 하나로 전환되면 이를 다른 유형의 테스트 에이전트로 다시 등록할 수 없습니다. 즉, 먼저 테스트 에이전트 어플라이언스로 등록한 다음 테스트 에이전트 애플리케이션으로 다시 등록하거나 그 반대의 경우도 허용되지 않습니다. 다른 유형의 테스트 에이전트가 필요한 경우 새 테스트 에이전트를 만들어야 합니다.
부록: 전체 YANG 모델의 트리 구조
이 부록의 81페이지 "범례" 섹션에서는 pyang -f tree 명령으로 생성된 YANG 모델 트리 구조의 구문을 설명합니다.
82페이지의 "YANG 모델 트리 구조" 섹션에서는 netrounds-ncc.yang에 적용된 해당 명령의 출력을 제공합니다. 이 출력의 일부는 문서의 다른 곳에 재현됩니다.
전설
YANG 모델 트리 구조
Juniper Networks, Juniper Networks 로고, Juniper 및 Junos는 미국 및 기타 국가에서 Juniper Networks, Inc.의 등록 상표입니다. 다른 모든 상표, 서비스 마크, 등록 상표 또는 등록 서비스 마크는 해당 소유자의 재산입니다. Juniper Networks는 이 문서의 부정확성에 대해 책임을 지지 않습니다. Juniper Networks는 통지 없이 이 간행물을 변경, 수정, 이전 또는 기타 방식으로 개정할 권리를 보유합니다. 저작권 © 2023 Juniper Networks, Inc. 모든 권리 보유.
문서 / 리소스
![]() |
주니퍼 네트웍스 NETCONF 및 YANG API 소프트웨어 [PDF 파일] 사용자 가이드 NETCONF YANG API 소프트웨어, YANG API 소프트웨어, API 소프트웨어, 소프트웨어 |