ASR9K 모델 기반 텔레메트리 백서
목차
소개
대상
이 백서는 고객이 일반적으로 MDT(Model Driven Telemetry) 기능에 대한 빠른 이해 및 일부 설계 지침 및 컨피그레이션 세부사항을 포함하여 Aggregation Services Router 9000(ASR9K)에서 구현된 방식에 대한 이해를 돕기 위해 작성되었습니다.또한 ASR9K를 사용하여 이 기능을 구축하는 데 도움이 되는 구축 고려 사항도 포함되어 있습니다.전반적으로 이 백서는 이 기능에 대해 작업하는 모든 사용자를 위한 빠른 참조 설명서가 될 수 있습니다.
텔레메트리는 일반 기능으로 소개되지만 ASR9K 구현에 중점을 둡니다.예를 들어, 다른 cisco 플랫폼에서 지원하는 모든 기능이 ASR9K 플랫폼에서 지원되지는 않으며 일부 기능 구현은 ASR9K에만 해당될 수 있습니다.
텔레메트리 개요
간단히 말해, 텔레메트리는 유용한 운영 데이터의 수집 프로세스로서 시작됩니다.Wikipedia에 따르면, 텔레메트리는 원격 또는 액세스 불가능한 지점에서 측정과 기타 데이터를 수집하고 모니터링을 위해 수신 장치로 전송되는 자동화된 통신 프로세스입니다.텔레메트리 단어 자체는 그리스어 루트에서 파생됩니다.tele = remote, metron = measure입니다.
네트워크 관리에서 네트워크 운영자는 SNMP(Simple Network Management Protocol)에 의존하는 오랜 역사를 가지고 있습니다. SNMP는 네트워크 모니터링에 널리 채택되어 있지만, snmp를 사용한 컨피그레이션 기능이 항상 존재하는 경우에도 컨피그레이션에 사용되지 않았습니다.운영자들은 일상적인 구성 작업을 처리하기 위해 작성된 자동화 스크립트를 가지고 있지만, 스크립트는 이러한 작업에 어렵고 관리하기 어렵습니다.
따라서 운영자는 데이터 모델 기반 관리로 이동했습니다.네트워크 컨피그레이션은 netconf와 같은 프로토콜에서 푸시되는 YANG 데이터 모델을 기반으로 합니다.이제 컨피그레이션을 푸시하면 구성된 서비스가 실행 중임을 의미하지는 않습니다. 컨피그레이션과 동시에 서비스 운영 데이터를 모니터링할 수 있는 메커니즘이 있어야 합니다.여기서 운영 데이터 모델이정보를 디바이스에서 푸시하는 데 사용하는 텔레메트리,도움이 됩니다.따라서 컨피그레이션은 YANG 데이터 모델 기반이므로 서비스 확인도 필요합니다.Telemetry의 경우와 마찬가지로 동일한 개체 의미적 특성을 가지려면따라서 이 용어는 모델 중심 텔레메트리 또는 스트리밍 텔레메트리를 지칭합니다.
MDT(Model Driven Telemetry)는 릴리스 6.1.1 이후 cXR(32비트 IOS XR)에 도입되었으며, 중요한 데이터를 거의 실시간으로 수집하여 측정할 수 있으므로 최신 네트워크의 운영 문제 대부분을 신속하게 해결할 수 있습니다.
하이 레벨 텔레메트리 아키텍처
MDT는 네트워킹 디바이스에서 지원하는 정형 데이터 모델을 활용하며 이러한 데이터 모델에 정의된 중요한 데이터를 제공합니다.텔레메트리는 네트워크에서 수집한 데이터가 표준 기반이며 벤더 구현 전반에 걸쳐 동일하기 때문에 하나의 공통 네트워크 관리 시스템, 프로세스 및 애플리케이션을 사용하여 멀티벤더 네트워크를 관리할 수 있도록 지원합니다.
중앙 집중식 관리 스테이션(일반적으로 SNMP NMS)에서 데이터 검색(pull)을 기다리는 대신,MDT를 사용하면 네트워크 디바이스가 패킷 전달 정보, 오류 통계, 시스템 상태, CPU 및 메모리 리소스 등 네트워크 중요 기능과 관련된 능동적으로 전송(푸시) 성능 데이터를 전송할 수 있습니다.
텔레메트리를 선택해야 하는 이유
분석 및 문제 해결을 위해 데이터를 수집하는 것은 네트워크 상태를 모니터링하는 데 있어 항상 중요한 측면이었습니다.SNMP, CLI 및 Syslog와 같은 여러 메커니즘을 통해 네트워크에서 데이터를 수집할 수 있습니다.이러한 방법은 네트워크를 매우 오랫동안 사용했지만 자동화에 대한 수요가 있는 현대 네트워크에는 적합하지 않지만, 규모에 맞는 서비스는 기본적입니다.네트워크 상태 정보, 트래픽 통계 및 중요 인프라 정보는 NMS의 원격 스테이션으로 전송되며, 원격 스테이션은 운영 성능을 향상시키고 문제 해결 시간을 단축하는 데 사용됩니다.클라이언트가 모든 네트워크 노드를 폴링하는 snmp와 같은 풀 모델은 효율적이지 않습니다.폴링할 클라이언트가 더 없을 때 네트워크 노드에서 처리 로드가 증가합니다.반면 푸시 모델에는 네트워크에서 데이터를 지속적으로 스트리밍하고 클라이언트에 알리는 기능이 있습니다.텔레메트리는 푸시 모델을 활성화하여 모니터링 데이터에 거의 실시간으로 액세스할 수 있습니다.
스트리밍 텔레메트리는 라우터에서 원하는 데이터를 선택하고 표준 형식으로 원격 관리 스테이션으로 전송하여 모니터링할 수 있는 메커니즘을 제공합니다.이 메커니즘은 원활한 운영을 위해 실시간 데이터를 기반으로 네트워크를 세부적으로 조정할 수 있도록 합니다.텔레메트리를 통해 사용할 수 있는 데이터의 세분화 및 빈도가 높을수록 성능 모니터링이 향상되므로 문제 해결이 향상됩니다.
네트워크, 링크 활용, 위험 평가 및 확장성의 서비스 효율적인 대역폭 활용을 지원합니다.스트리밍 텔레메트리를 사용하면 의사 결정을 개선하는 데 도움이 되는 네트워크 운영자의 요청에 따라 거의 실시간에 가까운 데이터를 사용할 수 있습니다.
SNMP에서 벗어나야 하는 필요성
SNMP는 30년 동안 존재해 왔으며, SNMP의 작동 방식은 최신 네트워크의 모니터링 요구 사항에 부합하기 위해 변하지 않았습니다.실제 문제는 SNMP 실행 속도입니다.
SNMP가 제기하는 세 가지 주요 과제는 사실상 기본적인 운영 동작의 일부이므로 SNMP는 개선의 여지가 거의/전혀 없으며, 텔레메트리를 통해 세 가지 문제를 근본적으로 해결할 수 있습니다.
- 실행 속도 및 실시간 모니터링 필요
SNMP는 테이블을 한 열에서 다른 열로 이동하여 선형 방식으로 작동하는 PULL 모델 - GetBulk / GetNext 작업을 사용합니다.또한 하나의 패킷에 들어갈 수 없는 큰 테이블의 경우 여러 요청이 필요합니다. 이는 SNMP의 속도가 느려지는 가장 큰 병목 현상이며 전송 중인 데이터는 몇 분 만에 특정 시간 요인으로 인해 오래된 경우가 많습니다.이러한 지연은 최신 네트워크 모니터링 요구 사항에 적합하지 않습니다.
MDT(Model Driven Telemetry)는 PUSH 모델을 사용하며, 어떤 데이터가 누구에게 어떤 간격으로 전송될지 알 수 있기 때문에 위에 나열된 제한에서 본질적으로 자유롭습니다.데이터를 수집하기 위해 하나의 조회만 필요하며, 내부 작업 속도를 매우 빠르게 하기 위해 사전 구축된 내부 템플릿을 사용하므로 훨씬 짧은 시간 내에 훨씬 더 많은 데이터를 제공할 수 있습니다.
- 추가 간접비 및 최적화 옵션 부족
SNMP에서 가져오는 데이터는 실제로 내부 데이터 구조로 저장되며 노드에 의해 내부적으로 변환되어야 합니다.이는 네트워크 노드가 내부 데이터 구조를 SNMP 형식으로 매핑하는 백그라운드에서 수행되는 추가 작업입니다.내부 최적화가 수행되었지만 아직 충분하지 않습니다.
반면, 텔레메트리는 내부 데이터 구조를 직접 추출하고 이 데이터를 전송하기 전에 최소한의 처리를 수행하므로 가장 업데이트된 데이터를 가장 적은 시간과 노력으로 제공합니다.
- 워크로드의 선형 특성
모든 추가 폴링 스테이션은 동일한 데이터를 동시에 폴링하는 경우에도 노드에서 추가 작업 로드를 발생시킵니다. 여러 폴링 스테이션에서 동일한 MIB를 병렬 액세스하면 응답이 느려지고 CPU 사용률이 높아집니다.이는 특히 여러 스테이션이 동일한 MIB 테이블의 서로 다른 부분에 액세스하는 대형 테이블의 경우 두드러집니다.
반면 원격 분석은 데이터를 한 번 끌어와 여러 대상에 동일한 데이터가 필요한 경우 패킷을 복제해야 합니다. 푸시 모델은 속도 및 확장을 위해 SNMP Pull을 능가합니다.
MDT를 사용하면 데이터 수집 접근 방식이 근본적으로 변화하고 그 기본 원칙이 아래 표에 나와 있으며 SNMP 기술 핵심 요점과 비교됩니다.
| SNMP(Simple Network Management Protocol) | 모델 기반 텔레메트리(MDT) |
| 비실시간 정보 |
실시간 정보 |
| 확장성이 떨어짐 |
뛰어난 확장성 |
| 풀모델 |
푸시 모델 |
| 자동화되지 않음 |
자동화 지원/데이터 모델 기반 |
스트리밍 텔레메트리의 이점
스트리밍된 실시간 텔레메트리 데이터는 다음과 같은 경우에 유용합니다.
용량 계획/트래픽 최적화:네트워크에서 대역폭 사용률 및 패킷 삭제를 자주 모니터링할 경우 링크를 추가 또는 제거하고, 트래픽을 재다이렉트하고, 폴리싱을 수정하는 등의 작업을 쉽게 수행할 수 있습니다.빠른 경로 재지정과 같은 기술을 통해 네트워크는 새로운 경로로 전환하고 SNMP 폴링 간격 메커니즘보다 빠르게 다시 라우팅할 수 있습니다.스트리밍 텔레메트리 데이터는 빠른 트래픽 응답에 도움이 됩니다.
향상된 가시성:네트워크에서 문제가 발생한 상태 이후에 발생하는 장애 상황을 신속하게 탐지하고 방지하는 데 도움이 됩니다.
모델 기반 텔레메트리 기술 사양
다음 섹션에서는 MDT라는 IOS XR Model Driven Telemetry의 주요 구성 요소와 기술 기능을 다룹니다.
텔레메트리 기능
텔레메트리 프레임워크는 서로 다른 세 가지 기능 블록으로 구성됩니다.
첫 번째 블록은 데이터 표현에 대한 것으로, 이는 정보를 참조하는 분석 또는 측정이 보드에 구성되는 방법입니다.
두 번째 블록은 인코딩에 대한 것입니다.샘플 간격마다 텔레메트리는 위의 측정 데이터를 전선에 걸쳐 직렬화할 수 있는 형식으로 변환합니다.물론, 디바이스에서 전송한 원본 데이터의 동일한 복사본을 보유하려면 다른 쪽 끝에 있는 컨트롤러가 데이터를 디코딩할 수 있어야 합니다.
마지막 블록은 전송에 관한 것입니다.디바이스 간에 데이터를 전송하는 데 사용되는 프로토콜 스택입니다.
다음 표에는 모델 기반 텔레메트리 구성 요소의 기본 구조가 요약되어 있습니다.
| 함수 | 구성 요소 |
| 데이터 표현 |
YANG 데이터 모델 |
| 인코딩 |
GPB / GPB 자체 설명 |
| 전송 |
TCP/gRPC |
표 3 텔레메트리 구성 요소
텔레메트리 구성 요소
텔레메트리 및 기본 구성 요소의 작동 방식을 이해하려면 최적의 설정을 평가하기 위해 텔레메트리의 여러 구성 요소를 이해하는 것이 중요합니다.텔레메트리는 IOS XR 프로그래밍 기능 스택을 기반으로 하며, 새로운 인프라 프레임워크는 네트워크 자동화에 필수적인 기능을 제공합니다.
YANG은 최근 데이터 모델링의 표준이 되었으며, Cisco 프로그래밍 스택에서 네트워크 상에서 최대한 신속하게 인코딩하고 전송할 수 있는 정형 데이터 세트를 형성하는 데 사용됩니다.YANG의 유연성은 자동화 프로세스를 위한 구성 툴로도 사용할 수 있는 큰 이점을 제공합니다.이러한 데이터 모델은 특정 인코딩 형식 및 전송 프로토콜과 결합되어 MDT를 Network Analytics를 위한 완전한 솔루션으로 만듭니다.
모델 기반 텔레메트리 설정의 경우 YANG 데이터 모델은 수집 및 분석에 필요한 데이터 스트리밍을 활성화하기 위해 중요한 구성 요소가 됩니다.
IOS XR 프로그래밍 기능 스택
양
Yang은 "네트워크 관리 프로토콜에 대한 컨피그레이션 데이터, 상태 데이터 및 알림을 모델링하는 데 사용되는 데이터 모델링 언어"로 정의됩니다. YANG은 일반적인 프로그래밍 언어 아키텍처로부터 분리된 특성 때문에 다양한 툴과 상호 작용하기 위해 구현될 수 있습니다.
YANG 모델링 데이터 구조는 모듈과 하위 모듈의 개념을 기반으로 구축되며, 이러한 개념은 구성 작업 및 알림 처리를 비롯한 여러 작업에 사용할 수 있습니다.
사용 가능한 YANG 모델의 출처는 여러 가지이며, 이 중 세 가지 중 세 가지는 기본 모델로 간주됩니다.
- 기본 모델/Cisco 관련
- 구성 열기
- IETF
Cisco별 모델:이러한 모델은 네이티브 모델이라고도 하며 Cisco를 비롯한 다양한 디바이스 벤더에 의해 게시됩니다. 예: Cisco-IOS-XR-ptp-oper.yang
OpenConfig 모델: OpenConfig는 네트워크 운영자의 비공식적인 작업 그룹입니다.OpenConfig는 모든 공급업체가 미션 크리티컬 기능을 구성하기 위해 지원해야 하는 공통 YANG 모델을 정의합니다. 예: openconfig-interfaces.yang
IETF 모델:또한 IETF는 인터페이스, QOS에 대한 기본 컨피그레이션을 설명하고 다른 일반적인 데이터 유형(예: Ipv4, IPv6 등)을 정의하는 몇 가지 일반적인 YANG 모듈을 정의합니다. 예: ietf-syslog-types.yang
Cisco는 사용 가능한 Openconfig 모델을 지원합니다. 공급업체는 멀티벤더 환경을 지원하기 위해 표준화된 데이터 모델링 방식으로 통합하고 있습니다.
양형 모델은 세 가지 유형으로 있다.
- 운영
- 구성
- 작업
텔레메트리는 *-oper-*.yang으로 식별될 수 있는 운영 Yang 모델만 다룹니다.
YANG은 RFC 7950에 정의되어 있습니다.https://tools.ietf.org/html/rfc7950
인코딩
인코딩(또는 "serialization")은 데이터(객체, 상태)를 네트워크를 통해 전송할 수 있는 형식으로 변환합니다.수신자가 데이터를 디코딩할 때("디직렬화") 원본 데이터의 의미상 동일한 복사본이 있습니다.
텔레메트리의 초기 개발 단계에서 XML은 처음에 태그 기반 구조 때문에 첫 번째 인코딩 형식으로 간주되었습니다.그러나 XML의 문제는 비압축 구조였습니다.GPB(Google Protocol Buffers)는 인코딩 작업의 효율성과 속도를 개선하여 Cisco에서 마침내 채택했습니다.
텔레메트리 스트리밍에는 두 가지 유형의 GPB가 인코딩 옵션으로 제공됩니다.
- 컴팩트 GPB
- 자체 설명 GPB
두 GPB 텔레메트리 형식의 주요 차이점은 데이터의 텔레메트리 스트림 내에서 키를 나타내고 인코딩하는 방법입니다.
JSON은 이해하기 쉽고 거의 모든 애플리케이션에서 디코딩할 수 있는 또 다른 사용자 친화적인 인코딩 스키마입니다.
구축 측면에서는 인코딩 스키마에 대한 장단점이 거의 없습니다.다양한 인코딩 스키마에 대한 비교는 Telemetry Design Guidelines 섹션에 나와 있습니다.
전송
텔레메트리는 전송 프로토콜에 대해 세 가지 선택 가능한 옵션을 제공합니다.
- TCP
- gRPC
- UDP
또한 텔레메트리는 노드와 컬렉터 간의 세션을 시작하기 위해 두 가지 다른 시작 모드를 정의합니다.
- 전화 걸기
- 전화 접속
두 모드의 차이점은 전송 세션이 설정된 방법에만 적용됩니다.
다이얼 아웃 세션 중에 디바이스는 사전 구성된 서버 포트에 syn 패킷을 전송하여 연결을 시작합니다.연결이 설정되면 데이터 스트림은 디바이스에서 즉시 푸시됩니다.
전화 접속 세션의 경우 라우터는 서버 연결을 기다리는 tcp 포트를 수동적으로 수신합니다.
그러나 세션이 설정되면 디바이스가 여전히 데이터 푸시 작업을 담당하므로 라우터가 서버 자체에서 폴링되지 않습니다.MDT에서는 실제로 데이터 폴링의 개념이 존재하지 않습니다.
TCP는 신뢰할 수 있고 옵션으로 구성하기 매우 쉽기 때문에 기본적으로 텔레메트리를 위한 미리 정의된 전송 방법입니다.
gRPC는 모든 환경에서 실행되도록 설계된 최신 오픈 소스 프레임워크입니다.HTTP/2를 기반으로 구축되며, 다양한 고급 기능을 제공합니다.
Cadence 기반 텔레메트리 vs 이벤트 기반 텔레메트리
가입한 데이터 집합의 데이터는 구성된 주기적 간격으로 또는 이벤트가 발생한 경우에만 대상으로 스트리밍됩니다.이 동작은 MDT가 cadence 기반 텔레메트리 또는 이벤트 기반 텔레메트리를 위해 구성되었는지 여부에 따라 달라집니다.
이벤트 기반 텔레메트리의 컨피그레이션은 cadence 기반 텔레메트리(Telemetry)와 유사하며 샘플 간격만 차별화 요소로 사용합니다.샘플 간격 값을 0으로 구성하면 이벤트 기반 텔레메트리 서브스크립션이 설정되고, 0이 아닌 값으로 컨피그레이션을 수행하면 cadence 기반 텔레메트리의 서브스크립션이 설정됩니다.
변경 관련 이벤트에 이벤트 중심 텔레메트리를 사용하는 것이 좋습니다.
텔레메트리 설계 지침
설명했듯이 텔레메트리 스택에는 많은 구성 요소가 있으며, XR 디바이스에 텔레메트리를 구현하는 동안 고려해야 할 몇 가지 지침이 있습니다.
인코딩 스키마 선택 방법
앞에서 설명한 대로 인코딩 또는 serialization은 데이터(객체, 상태)를 네트워크를 통해 전송할 수 있는 형식으로 변환합니다.수신자가 데이터를 디코딩하거나 역직렬화하면 원본 데이터의 의미상 동일한 복사본이 있습니다.
다양한 인코딩 옵션은 유선 효율성과 사용 편의성에 따라 다릅니다.
| 인코딩 | 간략한 설명 | 유선 방식의 효율성 | 기타 고려 사항 |
| GPB(컴팩트) | Everything 이진 (문자열 값 제외) 2배의 속도, 운영 복잡도(SNMP에 상대적으로 아님) |
높음 | 모델당 Proto 파일 |
| GPB - KV(키-값 쌍) | 문자열 키 및 이진 값 (문자열 값 제외) 3배 더 큰 기본 모델:키 이름에 대한 휴리스틱이 필요합니다. |
중간 ~ 낮음 | 해독용 단일 .proto 파일 |
| JSON | 모든 문자열:키 및 값 | 낮음 | 친근함.사람이 읽을 수 있고, 애플리케이션에 적합하며, 쉽게 구문 분석할 수 있음 |
GPB-KV는 스키마 인코딩을 위한 좋은 균형 중간 지점을 제공합니다.
선택한 인코딩 스키마에 대한 메시지 길이와 관련해서, 전선의 비교는 아래와 같습니다.
인코딩 비교 - 메시지 길이(바이트)
전송 네트워크 설계 고려 사항
다른 인코딩 옵션은 대역폭 요구 사항에 따라 다릅니다.텔레메트리를 고려하면서 네트워크 운영자는 선택한 인코딩 스키마에 따라 충분한 대역폭 프로비저닝을 처리해야 합니다.적절한 아이디어를 얻기 위해 인코딩 스키마 비교당 대역폭 소모량 미만입니다.
네트워크 대역폭 비교
KV-GPB를 사용하는 것이 좋습니다.효율성과 편의성 사이에서 좋은 중간지점 역할을 합니다.
텔레메트리 구성 옵션 평가
모델 기반 텔레메트리를 구성하는 동안 운영자는 텔레메트리에 포함된 모든 다른 구성 요소를 이해해야 합니다.전송, 인코딩 및 스트리밍 방향에 사용할 수 있는 옵션을 기반으로, 위에 자세히 설명되어 있듯이, 환경에 더 잘 맞는 조합을 더 선택할 수 있습니다.
4가지 핵심 구성 요소는
- 전송
- 인코딩
- 세션 방향
- YANG 데이터 모델
전송: 앞서 말한 대로, 노드는 TCP, UDP 또는 gRPC over HTTP/2를 사용하여 텔레메트리 데이터를 전달할 수 있습니다.
TCP가 간소화를 위해 선호되는 선택이지만, gRPC는 보안 측면에서 추가적인 이점으로 간주될 수 있는 선택적 TLS 기능을 제공합니다.
인코딩: 라우터는 Google Protocol Buffers의 두 가지 다른 유형으로 텔레메트리 데이터를 제공할 수 있습니다.컴팩트한 자체 설명 GPB.
Compact GPB는 가장 효율적인 인코딩이지만 스트리밍되는 각 YANG 모델에 대해 고유한 .proto가 필요합니다.자체 설명 GPB는 덜 효율적이지만 모든 YANG 모델을 디코딩하는 데 단일 .proto 파일을 사용합니다. 이 키는 .proto에서 문자열로 전달되기 때문입니다.
세션 방향: 텔레메트리 구축에서 세션을 시작하는 옵션에는 두 가지가 있습니다.라우터는 컬렉터에 "다이얼아웃"할 수 있으며 컬렉터는 라우터에 "다이얼인"할 수 있습니다.
YANG은 데이터 모델링의 표준이며 Cisco 프로그래밍 스택은 이를 사용하여 네트워크를 통해 최대한 신속하게 인코딩하고 전송할 수 있는 구조화된 데이터 세트를 형성합니다.
이러한 데이터 모델은 위에서 설명한 특정 인코딩 형식 및 전송 프로토콜과 결합되어 MDT(Model Driven Telemetry)가 분석을 위한 완벽한 솔루션입니다.
텔레메트리 컨피그레이션 예
IOS-XR
다이얼아웃 컨피그레이션 분리
Dial-Out 모드에서는 라우터가 컬렉터에 TCP 세션을 시작하고 서브스크립션의 센서 그룹에서 지정한 데이터를 전송합니다.
텔레메트리 다이얼아웃컨피그레이션의 관점에서 텔레메트리 컨피그레이션은 3단계 프로세스입니다.먼저, Sensor Group 컨피그레이션에서 스트리밍할 정보를 식별하고 캡처합니다.둘째, 정보를 스트리밍해야 하는 대상을 식별하여 Destination Group 컨피그레이션에서 캡처합니다.세 번째로, 이전 2단계에서 확인된 정보를 사용하여 실제 서브스크립션을 구성합니다.
- 센서 그룹 정의
- 대상 그룹 정의
- 구독 정의
센서 그룹 정의
센서 그룹 컨피그레이션은 스트리밍할 정보를 식별합니다.다음 컨피그레이션 템플릿은 센서 그룹을 구성하는 데 필요한 컨피그레이션을 제공합니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
다음 예는 실제 센서 그룹 컨피그레이션의 예가 있는 라우터 CLI의 실제 예를 보여줍니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
동일한 SensorGroup 정의의 일부로서 여러 Sensor 경로를 가질 수 있습니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
대상 그룹 정의
대상 그룹 컨피그레이션은 정보를 스트리밍할 대상을 식별합니다.
세 가지 핵심 매개변수가 있습니다.
- 세션 방향
- 사용할 인코딩
- 사용할 전송 프로토콜
다음은 예입니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)# destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)# address family ipv4 10.1.1.1 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
구독 정의
서브스크립션은 Sensor-Group 및 Destination-Group 정보를 컨피그레이션의 최종 부분으로 결합합니다.샘플 간격은 서브스크립션의 일부로 정의됩니다.
다음은 예입니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
전체 구성 예
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
Dial-Out의 장점
- 전송 옵션을 위한 폭넓은 유연성.
- 인바운드 관리 트래픽을 위해 포트를 열 필요가 없습니다.
- 애니캐스트 및 로드 밸런싱.
전화 접속 구성 분리
다이얼 인 모드에서는 MDT 컬렉터/수신기/오케스트레이터가 라우터에 전화를 걸어 하나 이상의 센서 경로 또는 서브스크립션에 동적으로 가입합니다.라우터는 서버 및 클라이언트 역할을 하며 수신기로 작동합니다.
단일 세션만 구성되고 라우터는 동일한 세션을 통해 텔레메트리 데이터를 스트리밍합니다.이 동적 서브스크립션은 수신자가 서브스크립션을 취소하거나 세션이 종료될 때 종료됩니다.
텔레메트리 전화 접속
컬렉터가 라우터에 "dials-in"되므로 컨피그레이션에서 각 MDT 대상을 지정할 필요가 없습니다.라우터에서 gRPC 서비스를 활성화하고 클라이언트를 연결하고 원하는 텔레메트리 서브스크립션을 동적으로 활성화하기만 하면 됩니다.
컨피그레이션의 관점에서 텔레메트리 컨피그레이션은 위에서 설명한 것과 유사한 3단계 프로세스입니다.먼저 gRPC를 활성화해야 합니다.둘째, 정보를 스트리밍해야 하는 대상을 식별하여 세션 그룹 컨피그레이션에서 캡처합니다.세 번째로, 이전 2단계에서 확인된 정보를 사용하여 실제 서브스크립션을 구성합니다.
- gRPC 사용
- 센서 그룹 정의
- 구독 정의
gRPC 사용
먼저, 컬렉터에서 수신되는 연결을 수락하려면 라우터에서 gRPC 서버를 활성화해야 합니다.
- <port-number> 범위는 57344~57999입니다. 포트 번호를 사용할 수 없으면 오류가 표시됩니다.
RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)#commit RP/0/RP0/CPU0:XR(config-grpc)#end RP/0/RP0/CPU0:XR#
센서 그룹 정의
센서 그룹 컨피그레이션은 스트리밍할 정보를 식별합니다.다음 컨피그레이션 템플릿은 센서 그룹을 구성하는 데 필요한 컨피그레이션을 제공합니다.
다음 예는 라우터 CLI의 실제 예를 보여줍니다. 여기서 센서 그룹 컨피그레이션의 실제 예는
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path openconfig-interfaces:interfaces/interface RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# commit RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# end RP/0/RP0/CPU0:XR#
구독 정의
서브스크립션은 Sensor-Group 및 gRPC를 컨피그레이션의 최종 부분으로 결합합니다.샘플 간격은 서브스크립션의 일부로 정의됩니다.
다음 컨피그레이션 템플릿은 서브스크립션을 구성하는 데 필요한 컨피그레이션을 제공합니다.
다음 예는 서브스크립션을 생성하고 Sensor-Group 및 Destination-Group을 바인딩하는 라우터 CLI의 실제 예와 샘플 속도를 정의하는 방법을 보여줍니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
구성 템플릿 완료 및 예
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 30000 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
다이얼인의 장점
- 구성 및 스트리밍을 위한 단일 채널
- 라우터/디바이스의 수신 포트
- 임시 연결
- 현재 gRPC/gNMI만 사용 가능
이벤트 중심 텔레메트리
Event driven Telemetry(이벤트 중심 텔레메트리)에서는 이벤트가 발생할 때만 가입한 데이터 집합의 데이터가 스트리밍됩니다.
이벤트 중심 텔레메트리 구성
이벤트 기반 텔레메트리의 컨피그레이션은 cadence 기반 텔레메트리 컨피그레이션과 비슷하며, 이벤트 기반 텔레메트리 컨피그레이션의 유일한 차이점은 샘플 간격의 컨피그레이션입니다.샘플 간격 값을 0으로 구성하면 이벤트 기반 텔레메트리에 대한 서브스크립션이 설정됩니다.
전체 구성 템플릿 및 다이얼 아웃 예
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group <Sensor-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path <Sensor-Path> RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group <Destination-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 <Destination-IP> port <Destination-Port> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding <Encoding-Type> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol <Transport-Protocol> RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription <Subscription-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0> RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id <Destination-Group-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
다음 예는 라우터 CLI의 실제 예를 보여줍니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#conf RP/0/RP0/CPU0:XR(config)# RP/0/RP0/CPU0:XR(config)#telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#sensor-group SensorGroup101 RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)# sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters RP/0/RP0/CPU0:XR(config-model-driven-snsr-grp)#destination-group DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-dest)#address family ipv4 10.1.1.2 port 5432 RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#encoding self-describing-gpb RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#protocol tcp RP/0/RP0/CPU0:XR(config-model-driven-dest-addr)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0 RP/0/RP0/CPU0:XR(config-model-driven-subs)#destination-id DestGroup101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
전체 구성 템플릿 및 DIAL-IN의 예
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port <port-number> RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription <Subscription-Name> RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id <Sensor-Group-Name> sample-interval <0> RP/0/RP0/CPU0:XR(config-model-driven-subs)#commit RP/0/RP0/CPU0:XR(config-model-driven-subs)#end RP/0/RP0/CPU0:XR#
다음 예는 라우터 CLI의 실제 예를 보여줍니다.
RP/0/RP0/CPU0:XR# RP/0/RP0/CPU0:XR#config RP/0/RP0/CPU0:XR(config)# grpc RP/0/RP0/CPU0:XR(config-grpc)#port 57890 RP/0/RP0/CPU0:XR(config-grpc)telemetry model-driven RP/0/RP0/CPU0:XR(config-model-driven)#subscription Subscription101 RP/0/RP0/CPU0:XR(config-model-driven-subs)#sensor-group-id SensorGroup101 sample-interval 0 RP/0/RP0/CPU0:XR(config-model-driven-subs)# commit RP/0/RP0/CPU0:XR(config-model-driven-subs)# end RP/0/RP0/CPU0:XR#
SHOW 명령으로 텔레메트리 검증
라우터 관점에서 각 센서 그룹, 대상 그룹 및 서브스크립션에 대해 구성된 매개변수를 확인할 수 있습니다
// ALL CONFIGURED SUBSCRIPTIONS
RP/0/RP0/CPU0:XR#show telemetry model-driven subscription
Subscription: Subscription101 State: ACTIVE
-------------
Sensor groups:
Id Interval(ms) State
SensorGroup101 30000 Resolved
Destination Groups:
Id Encoding Transport State Port IP
DestGroup101 self-describing-gpb tcp Active 5432 172.16.128.3
// DETAILS ON A PARTICULAR SUBSCRIPTION
RP/0/RP0/CPU0:XR#show telemetry model-driven subscription Subscription101
Subscription: Subscription101
-------------
State: ACTIVE
Sensor groups:
Id: SensorGroup101
Sample Interval: 30000 ms
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
Destination Groups:
Group Id: DestGroup101
Destination IP: 172.16.128.3
Destination Port: 5432
Encoding: self-describing-gpb
Transport: tcp
State: Active
Total bytes sent: 4893
Total packets sent: 1
Last Sent time: 2019-11-01 10:04:11.2378949664 +0000
Collection Groups:
------------------
Id: 1
Sample Interval: 30000 ms
Encoding: self-describing-gpb
Num of collection: 5
Collection time: Min: 6 ms Max: 29 ms
Total time: Min: 6 ms Avg: 12 ms Max: 29 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
Last Collection Start:2019-11-01 10:06:11.2499000664 +0000
Last Collection End: 2019-11-01 10:06:11.2499006664 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
RP/0/RP0/CPU0:XR#
// ALL CONFIGURED DESTINATIONS
RP/0/RP0/CPU0:XR#show telemetry model-driven destination
Group Id IP Port Encoding Transport State
-----------------------------------------------------------------------------
DestGroup101 172.16.128.3 5432 self-describing-gpb tcp Active
RP/0/RP0/CPU0:XR#
// PARTICULAR DESTINATION
RP/0/RP0/CPU0:XR#show telemetry model-driven destination DestGroup101
Destination Group: DestGroup101
-----------------
Destination IP: 172.16.128.3
Destination Port: 5432
State: Active
Encoding: self-describing-gpb
Transport: tcp
Total bytes sent: 83181
Total packets sent: 17
Last Sent time: 2019-11-01 10:12:11.2859133664 +0000
Collection Groups:
------------------
Id: 1
Sample Interval: 30000 ms
Encoding: self-describing-gpb
Num of collection: 17
Collection time: Min: 5 ms Max: 29 ms
Total time: Min: 6 ms Max: 29 ms Avg: 10 ms
Total Deferred: 0
Total Send Errors: 0
Total Send Drops: 0
Total Other Errors: 0
Last Collection Start:2019-11-01 10:12:11.2859128664 +0000
Last Collection End: 2019-11-01 10:12:11.2859134664 +0000
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
RP/0/RP0/CPU0:XR#
// ALL CONFIGURED SENSOR GROUPS
RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group
Sensor Group Id:SensorGroup101
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
// PARTICULAR SENSOR GROUPS
RP/0/RP0/CPU0:XR#show telemetry model-driven sensor-group SensorGroup101
Sensor Group Id:SensorGroup101
Sensor Path: Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters
Sensor Path State: Resolved
RP/0/RP0/CPU0:XR#
텔레메트리 수집 스택
라우터 컨피그레이션 외에도 텔레메트리 기반 솔루션은 컬렉터, 데이터베이스, 모니터링/분석 소프트웨어와 같은 여러 구성 요소를 필요로 했습니다.이러한 구성 요소는 별도로 구성할 수도 있고 하나의 포괄적인 제품에 포함될 수도 있습니다.
- 인바운드 패킷을 가져와서 추가 스토리지를 위해 전달하려면 디코더를 설치해야 합니다.
- 스트리밍 정보를 저장하려면 Time Series 데이터베이스(TSDB)가 필요합니다.
- 내부 데이터베이스에서 가져온 데이터를 시각화하는 데 그래픽 도구도 필요합니다.
수집 스택을 자세히 설명하는 것은 범위를 벗어납니다.Cisco Crossworks Health Insights는 원격 분석 컨피그레이션으로 디바이스가 자동으로 프로비저닝되고 테이블/스키마가 TSDB(Time Series Database)에 생성되는 제로 터치 텔레메트리를 허용합니다. 또한 데이터 수집 및 정리 작업의 운영 및 네트워크 관리 오버헤드를 간소화하여 운영자가 비즈니스 목표에 집중할 수 있도록 합니다.SNMP, CLI 및 모델 기반 텔레메트리를 통해 네트워크 디바이스 데이터를 수집하기 위한 공통 컬렉터의 활용으로 데이터 중복을 방지하고 디바이스 및 네트워크의 로드를 줄일 수 있습니다.
네트워크의 텔레메트리 구축 고려 사항
다음은 네트워크의 텔레메트리 구축을 분석하는 동안 고려해야 할 다양한 사항입니다.
확장
텔레메트리는 상당한 양의 데이터를 스트리밍할 수 있으며 확장성 측면을 신중하게 고려하는 것이 좋습니다.
필요한 데이터만 스트리밍
각 Yang 모델에는 여러 leaf 노드가 있습니다.필요한 정보와 필요 없는 정보에 대해 구체적으로 설명하는 것이 좋습니다.Yang 모델을 살펴보고 텔레메트리 활용 사례에 필요한 데이터 경로를 식별하는 것이 좋습니다.
스트리밍 데이터의 양 고려
스트리밍되는 텔레메트리 데이터의 총 양은 다음 사항에 대해 고려해야 합니다.
- 네트워크 내 대역폭 할당
- QoS
- 다음과 같은 추가 애플리케이션/소프트웨어의 성능
- 컬렉터 소프트웨어
- Time Series 데이터베이스
- 분석/시각화 소프트웨어
- 인코딩 효율성("텔레메트리 설계 지침" 섹션에서 설명)은 스트리밍되는 데이터의 양에 직접적인 영향을 미칩니다.실행 가능한 경우 GPB를 압축하는 것이 좋습니다.
- 수집 간격은 다음을 비롯한 여러 측면에 직접적인 영향을 미칩니다.
- 네트워크의 대역폭 사용률
- 데이터베이스의 스토리지 요구 사항
- 데이터를 스트리밍하는 장치의 성능
응용 프로그램 요구 사항에 따라 컬렉션의 빈도를 평가하는 것이 좋습니다.
전반적으로 소스 또는 대상에서 원치 않는 데이터를 실행 가능한 것으로 필터링하는 것이 좋습니다.원치 않는 데이터를 필터링할 수 있는 옵션이 있습니다.필터링은 두 가지 레벨에서 수행할 수 있습니다.-
- At the Source - 디바이스가 데이터를 스트리밍합니다.
- Destination(대상) - 컬렉터가 데이터를 수집하고 정규화합니다.(컬렉터에서 필터링하는 것은 이 문서의 범위를 벗어남)
다음 예에서는 와일드카드를 적용하여 센서 경로 내의 헌금된 Gig 인터페이스에 대해서만 필터링되는 데이터를 보여줍니다.
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']/latest/generic-counters
참조
https://blogs.cisco.com/sp/the-limits-of-snmp
https://blogs.cisco.com/sp/why-you-should-care-about-model-driven-telemetry
https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/telemetry/b-telemetry-cg-asr9000-61x.html
피드백