Livre blanc sur la télémétrie pilotée par le modèle ASR9K
Contenu
Introduction
Public
Ce livre blanc a pour but d'aider les clients à comprendre rapidement la fonction de télémétrie pilotée par modèle (MDT) en général et comment elle a été mise en oeuvre dans le routeur de services d'agrégation 9000 (ASR9K), y compris quelques directives de conception et des détails de configuration. Il inclut également une prise en compte du déploiement, qui sera utile lors du déploiement de cette fonctionnalité à l'aide d'ASR9K. Dans l'ensemble, ce livre blanc peut être un guide de référence rapide pour tous ceux qui travaillent sur cette fonctionnalité.
Bien que la télémétrie soit introduite en tant que fonctionnalité générique, l'accent est mis sur la mise en oeuvre d'ASR9K ; Par exemple, toutes les fonctionnalités prises en charge par d'autres plates-formes cisco ne sont pas prises en charge par la plate-forme ASR9K et certaines mises en oeuvre de fonctionnalités peuvent être spécifiques à ASR9K.
Présentation succincte de la télémétrie
Pour commencer, en termes simples, la télémétrie est le processus de collecte de données opérationnelles utiles. Selon Wikipedia, la télémétrie est un processus de communication automatisé par lequel les mesures et autres données sont collectées à des points distants ou inaccessibles et transmises à l'équipement de réception pour surveillance. Le mot télémétrique lui-même provient de racines grecques : tele = distant et metron = mesure.
Pour la gestion du réseau, les opérateurs réseau ont une longue histoire de dépendance au protocole SNMP (Simple Network Management Protocol). Bien que SNMP soit largement utilisé pour la surveillance du réseau, il n'a jamais été utilisé pour la configuration, même si la fonctionnalité de configuration avec snmp était toujours présente. Les opérateurs disposent de scripts d'automatisation écrits pour gérer les tâches de configuration quotidiennes, mais les scripts sont difficiles à gérer et difficiles à gérer.
Les opérateurs se sont donc orientés vers la gestion axée sur les modèles de données. La configuration du réseau est basée sur des modèles de données YANG poussés par des protocoles tels que netconf par exemple. Maintenant, simplement pousser la configuration n'implique pas que le service configuré est en cours d'exécution, il doit y avoir un mécanisme qui peut surveiller les données opérationnelles des services en même temps que la configuration. C'est là que se trouvent les modèles de données d'utilisation ; quelle télémétrie utilise pour diffuser des informations hors du périphérique ; aide. Par conséquent, la configuration est pilotée par le modèle de données YANG, de sorte que doit également être la vérification du service ; comme dans le cas de la télémétrie, afin d'avoir le même objet sémantique. Par conséquent, le terme est appelé Télémétrie pilotée par modèle ou Télémétrie de diffusion en continu.
Model Driven Telemetry (MDT) a été introduit dans cXR (IOS XR 32 bits) depuis la version 6.1.1 et permet la collecte et la mesure de données critiques en temps quasi réel, fournissant une réponse rapide à la plupart des problèmes opérationnels du réseau moderne.
Architecture de télémétrie de haut niveau
MDT exploite les modèles de données structurées pris en charge par le périphérique réseau et fournit des données critiques définies dans ces modèles de données. La télémétrie aide les clients à gérer leur réseau multifournisseur à l'aide d'un système, d'un processus et d'applications de gestion de réseau commun, car les données collectées sur le réseau sont basées sur des normes et sont uniformes dans l'ensemble de la mise en oeuvre du fournisseur.
Plutôt que d'attendre la récupération (extraction) des données à partir d'une station de gestion centralisée (généralement SNMP NMS) ; avec MDT, les périphériques réseau envoient proactivement (push) les données de performances relatives aux fonctions vitales du réseau, telles que les informations de transfert de paquets, les statistiques d'erreurs, l'état du système, les ressources de CPU et de mémoire, etc.
Pourquoi la télémétrie ?
La collecte de données à des fins d’analyse et de dépannage a toujours été un aspect important de la surveillance de l’état d’un réseau. Plusieurs mécanismes sont disponibles, tels que SNMP, CLI et Syslog, pour collecter des données à partir d’un réseau. Bien que ces méthodes aient servi le réseau pendant très longtemps mais ne conviennent pas aux réseaux modernes où la demande d'automatisation est fondamentale, les services à grande échelle sont essentiels. Les informations d'intégrité du réseau, les statistiques de trafic et les informations d'infrastructure critiques sont envoyées à une station distante dans NMS, où elles sont utilisées pour améliorer les performances opérationnelles et réduire le temps de dépannage. Un modèle d'extraction comme snmp où un client interroge tous les noeuds du réseau n'est pas efficace. La charge de traitement sur les noeuds réseau augmente lorsqu'il n'y a plus de clients à interroger. Au contraire, un modèle Push peut diffuser en continu des données hors du réseau et en informer le client. La télémétrie active le modèle Push, qui fournit un accès en temps quasi réel aux données de surveillance.
La télémétrie en continu fournit un mécanisme permettant de sélectionner les données d’intérêt à partir des routeurs et de les transmettre dans un format standard à des stations de gestion distantes pour la surveillance. Ce mécanisme permet un réglage précis du réseau basé sur des données en temps réel, ce qui est crucial pour son fonctionnement transparent. La granularité plus fine et la fréquence plus élevée des données disponibles via la télémétrie permettent une meilleure surveillance des performances et donc un meilleur dépannage.
Il permet une utilisation plus efficace de la bande passante sur le réseau, l'utilisation des liaisons, l'évaluation des risques et l'évolutivité. Grâce à la télémétrie en continu, les opérateurs de réseau disposent de données en temps réel plus proches, ce qui contribue à améliorer la prise de décision.
Nécessité de s'éloigner du protocole SNMP
SNMP existe depuis trois décennies et sa manière de fonctionner n'a pas changé pour répondre aux besoins de surveillance des réseaux modernes. Le vrai problème est la vitesse d'exécution du protocole SNMP.
Les trois principaux défis posés par SNMP font en fait partie de son comportement opérationnel fondamental et le protocole SNMP offre donc peu ou pas de marge d'amélioration et la télémétrie couvre les trois éléments intrinsèquement.
- Vitesse d'exécution et nécessité d'une surveillance en temps réel
SNMP utilise les opérations PULL Model - GetBulk / GetNext qui fonctionnent de manière linéaire en traversant les tables d'une colonne à l'autre jusqu'au sol. En outre, plusieurs requêtes sont requises dans le cas de grandes tables qui ne peuvent pas tenir dans un paquet. Il s'agit du plus grand goulot d'étranglement qui entraîne le ralentissement du protocole SNMP et l'envoi de données est souvent dépassé par un certain facteur de temps en quelques minutes. Ce délai n'est tout simplement pas acceptable aux exigences modernes de surveillance du réseau.
MDT (Model Driven Telemetry) utilise le modèle PUSH et est intrinsèquement exempt de la limite ci-dessus car il sait quelles données doivent être envoyées à qui et à quel intervalle. Il n'a besoin que d'une seule recherche pour recueillir des données et utilise des modèles internes prédéfinis pour accélérer les opérations internes, permettant ainsi la livraison de beaucoup plus de données dans un temps considérablement moindre.
- Frais généraux supplémentaires et options d'optimisation insuffisantes
Les données extraites par SNMP sont en fait stockées en tant que structures de données internes et doivent être converties en interne par le noeud. Il s'agit d'un travail supplémentaire en coulisses où le noeud réseau mappe les structures de données internes au format SNMP. Des optimisations internes sont effectuées, mais elles ne sont toujours pas suffisantes.
D'autre part, la télémétrie extrait directement les structures de données internes et effectue un traitement minimal avant d'envoyer ces données, fournissant ainsi les données les plus mises à jour avec le moins de temps et d'effort possible.
- Nature linéaire de la charge de travail
Chaque bureau de vote supplémentaire entraînera une charge de travail supplémentaire sur le noeud, même si nous interrogeons les mêmes données exactes en même temps. Un accès parallèle de la même MIB depuis plusieurs bureaux de vote peut entraîner une réponse plus lente et une utilisation plus élevée du CPU. Cela est particulièrement évident dans le cas des grandes tables, où plusieurs stations accèdent à différentes parties d'une même table MIB.
Par contre, la télémétrie doit extraire des données une fois et répliquer les paquets si les mêmes données sont requises par plusieurs destinations. Push model bat SNMP Pull for Speed & Scale.
Avec MDT, l'approche de la collecte de données change radicalement et ses principes fondamentaux sont répertoriés dans le tableau ci-dessous et comparés aux points clés de la technologie SNMP.
| Protocole de gestion de réseau simple (SNMP) | Télémétrie pilotée par modèle (MDT) |
| Informations non en temps réel |
Informations en temps réel |
| Mauvaise évolutivité |
Hautement évolutif |
| Modèle d'extraction |
Push-Model |
| Non automatisé |
Automatisation prête/modèle de données piloté |
Avantages de la transmission de données télémétriques
Les données de télémétrie en temps réel en continu sont utiles dans les domaines suivants :
Planification des capacités/optimisation du trafic : Lorsque l’utilisation de la bande passante et les pertes de paquets dans un réseau sont fréquemment surveillées, il est plus facile d’ajouter ou de supprimer des liaisons, de rediriger le trafic, de modifier la réglementation, etc. Avec des technologies telles que la réacheminement rapide, le réseau peut basculer vers un nouveau chemin et réacheminer plus rapidement que le mécanisme d'intervalle d'interrogation SNMP. La diffusion de données de télémétrie permet de fournir un temps de réponse rapide pour un trafic plus rapide.
Meilleure visibilité : Permet de détecter et d'éviter rapidement les situations de défaillance qui se produisent après une situation problématique sur le réseau.
Spécifications techniques de télémétrie pilotée par modèle
La section suivante traite des fonctions techniques et des principaux composants de la télémétrie pilotée par le modèle IOS XR (MDT).
Fonctions de télémétrie
Le cadre de télémétrie est organisé en trois blocs fonctionnels distincts et interreliés.
Le premier bloc concerne la représentation des données, c'est-à-dire la façon dont l'analyse ou les mesures de référence des informations sont organisées à bord.
Le deuxième bloc concerne le codage. À chaque intervalle d'échantillonnage, la télémétrie traduit les données de mesure ci-dessus dans un format qui peut être sérialisé sur le fil. Bien sûr, le contrôleur de l'autre extrémité doit être capable de décoder les données afin d'avoir une copie identique des données d'origine envoyées par le périphérique.
Le dernier bloc concerne le transport. Il s'agit de la pile de protocoles utilisée pour transférer des données entre des périphériques.
Le tableau suivant récapitule la structure principale des blocs de construction de télémétrie pilotée par modèle :
| Fonction | Composants |
| Représentation des données |
Modèles de données YANG |
| Codage |
Autodescription GPB/GPB |
| Transport |
TCP/gRPC |
Tableau 3 Blocs de bâtiment de télémétrie
Composants de télémétrie
Avant de comprendre comment fonctionne la télémétrie et les éléments de configuration sous-jacents, il est important de comprendre les différents composants de la télémétrie afin d'évaluer une configuration optimale. La télémétrie repose sur la pile de programmabilité IOS XR, dans laquelle une nouvelle infrastructure fournit les fonctionnalités essentielles pour l'automatisation du réseau.
YANG est récemment devenu une norme pour la modélisation des données, et elle est utilisée par la pile de programmabilité Cisco pour former un ensemble de données structuré qui peut être codé et transporté aussi rapidement que possible sur le réseau. La flexibilité de YANG donne un grand avantage à être également utilisé comme outil de configuration pour les processus d'automatisation. Ces modèles de données sont associés à des formats de codage et des protocoles de transport spécifiques pour faire de MDT une solution complète pour Network Analytics.
Pour la configuration de la télémétrie pilotée par modèle, le modèle de données YANG devient un composant essentiel afin de permettre la diffusion des données nécessaires pour la collecte et l'analyse.
Pile de programmabilité IOS XR
YANG
Yang est défini comme langage “ de modélisation des données utilisé pour modéliser les données de configuration, les données d’état et les notifications pour les protocoles de gestion de réseau ”. En raison de sa nature découplée d'une architecture de langage de programmation classique, YANG peut être mis en oeuvre pour interagir avec une grande variété d'outils.
La structure de données de modélisation YANG est construite autour du concept de modules et de sous-modules qui définit une hiérarchie de données de manière similaire à une arborescence, qui peut être utilisée pour plusieurs opérations, y compris les actions de configuration et la gestion des notifications.
Il existe plusieurs sources de modèles YANG dont les suivantes sont considérées comme primaires :
- Modèles natifs / Spécifiques à Cisco
- OpenConfig
- IETF
Modèles spécifiques à Cisco:: Ces modèles sont également appelés modèles natifs et sont publiés par divers fournisseurs de périphériques, dont Cisco. par exemple, Cisco-IOS-XR-ptp-oper.yang
Modèles OpenConfig : OpenConfig est un groupe de travail informel d’opérateurs de réseau. OpenConfig définit les modèles YANG courants que tous les fournisseurs doivent prendre en charge pour configurer les fonctionnalités critiques. par exemple openconfig-interfaces.yang
Modèles IETF:: IETF définit également quelques modules YANG courants qui décrivent la configuration de base des interfaces, la qualité de service et définissent d'autres types de données courants (tels que Ipv4, IPv6, etc.). par exemple ietf-syslog-types.yang
Cisco prend en charge les modèles Openconfg disponibles. Les fournisseurs convergent vers une méthode normalisée de modélisation des données pour prendre en charge un environnement multifournisseur.
Il existe trois types de modèles Yang :
- Opérationnel
- Configuration
- Action
La télémétrie ne se préoccupe que des modèles Opérationnels Yang qui peuvent être identifiés comme *-oper-*.yang.
YANG est défini dans la RFC 7950 : https://tools.ietf.org/html/rfc7950.
Codage
Le codage (ou ” de sérialisation “) traduit les données (objets, état) dans un format qui peut être transmis sur le réseau. Lorsque le récepteur décode (“ désérialise ”) les données, il dispose d'une copie sémantiquement identique des données d'origine.
Au cours des premières étapes du développement de la télémétrie, le format XML a été initialement considéré comme un format de codage de premier choix en raison de sa structure basée sur les balises. Cependant, le problème avec XML était sa structure de codage non compacte. GPB (Google Protocol Buffers) a finalement été adopté par Cisco car il améliore l'efficacité et la vitesse des opérations de codage.
Il existe deux types de GPB en tant qu'options de codage pour la transmission de données télémétriques :
- Compact GPB
- Auto-description de GPB
La principale différence entre les deux formats de télémétrie GPB est la manière dont ils représentent et codent les clés dans un flux de données de télémétrie.
JSON est un autre schéma d'encodage humain qui est très facile à comprendre et presque n'importe quelle application sera capable de décoder.
Du point de vue du déploiement, il y a peu de avantages et d'inconvénients d'un schéma de codage. La comparaison des différents schémas de codage est donnée dans la section Directives de conception de télémétrie.
Transport
La télémétrie offre trois options possibles pour les protocoles de transport :
- TCP
- gRPC
- UDP
La télémétrie définit également deux modes d'initiation différents afin de démarrer une session entre le noeud et le collecteur :
- Appel sortant
- Composer
La différence entre les deux modes ne concerne que la manière dont la session de transport est établie.
Pendant les sessions de numérotation, le périphérique initie la connexion en envoyant un paquet syn vers le port serveur préconfiguré. Une fois la connexion établie, les flux de données sont immédiatement éloignés du périphérique.
Pour les sessions commutées, le routeur écoute passivement un port tcp en attente d'une connexion serveur.
Cependant, une fois la session établie, le routeur n'est pas interrogé par le serveur lui-même, car le périphérique est toujours responsable des opérations de transmission de données. En effet, le concept d'interrogation des données n'existe même pas dans le MDT.
TCP est, par défaut, la méthode de transport prédéfinie pour la télémétrie, car elle est fiable et très facile à configurer en option.
gRPC est un cadre open source moderne conçu pour fonctionner dans n'importe quel environnement. Il est construit sur HTTP/2 et offre un ensemble de fonctionnalités avancées et riches.
Télémétrie basée sur les cadences et télémétrie basée sur les événements
Les données de l'ensemble de données abonné sont diffusées en continu vers la destination, soit à un intervalle périodique configuré, soit uniquement lorsqu'un événement se produit. Ce comportement est basé sur le fait que MDT est configuré pour la télémétrie basée sur la cadence ou la télémétrie basée sur les événements.
La configuration de la télémétrie basée sur les événements est similaire à la télémétrie basée sur les cadences, avec seulement l'intervalle d'échantillonnage comme différenciateur. La configuration de la valeur de l'intervalle d'exemple sur zéro définit l'abonnement pour la télémétrie basée sur les événements, tandis que la configuration de l'intervalle sur une valeur différente de zéro définit l'abonnement pour la télémétrie basée sur la cadence.
Il est recommandé d'utiliser la télémétrie basée sur les événements pour les événements liés aux changements.
Directives de conception de télémétrie
Comme expliqué, la pile de télémétrie contient de nombreux composants. Voici quelques directives à prendre en compte lors de la mise en oeuvre de la télémétrie sur des périphériques XR.
Comment sélectionner un schéma de codage
Comme indiqué, le codage ou la sérialisation traduit les données (objets, état) dans un format qui peut être transmis sur le réseau. Lorsque le récepteur décode ou désérialise les données, il possède une copie sémantiquement identique des données d'origine.
Les différentes options de codage varient en termes d'efficacité et de facilité d'utilisation des fils.
| Codage | Brève description | Efficacité des câbles | Autres considérations |
| GPB (compact) | Tout binaire (Sauf les valeurs qui sont des chaînes) 2 fois plus rapide et plus complexe (mais pas par rapport au protocole SNMP) |
Élevé | Fichier Proto par modèle |
| GPB - KV (Key-Value Pair) | Touches de chaîne et valeurs binaires (à l'exception des valeurs qui sont des chaînes) 3 fois plus grand, Modèles natifs : Il faut encore des heuristiques pour les noms de clés |
Moyen à faible | Fichier .proto unique pour le décodage |
| JSON | Chaînes de tout : Clés et valeurs | Faible | Amical. Lecture humaine, conviviale et facile à analyser |
GPB-KV donne un bon point de milieu d'équilibre pour le schéma de codage.
En ce qui concerne la longueur du message pour le schéma de codage choisi, voici la comparaison sur le fil.
Comparaison du codage - Longueur du message en octets
Examen de la conception du réseau de transport
Différentes options de codage posent des besoins de bande passante différents. Lors de la télémétrie, l’opérateur réseau doit prendre en charge le provisionnement de bande passante suffisant selon le schéma de codage choisi. Juste pour avoir une bonne idée, en dessous de la consommation de bande passante par comparaison de schémas d'encodage.
Comparaison de la bande passante du réseau
Cisco recommande d'utiliser KV-GPB. Il agit comme un bon milieu entre l'efficacité et la commodité.
Évaluation des options de configuration de télémétrie
Lors de la configuration de la télémétrie pilotée par modèle, l'opérateur doit comprendre tous les composants impliqués dans la télémétrie. Sur la base des options disponibles pour le transport, le codage et la direction de la diffusion en continu comme indiqué ci-dessus, on peut choisir plus loin la combinaison qui convient le mieux à un environnement.
Les quatre principaux composants sont les suivants :
- Transport
- Codage
- Orientation de la session
- Modèles de données YANG
Transport : Comme indiqué, le noeud peut transmettre des données de télémétrie via TCP, UDP ou gRPC via HTTP/2.
Bien que TCP soit le choix préféré pour la simplicité, gRPC offre une fonctionnalité TLS facultative qui peut être considérée comme un avantage supplémentaire du point de vue de la sécurité.
Codage : Le routeur peut fournir des données de télémétrie dans deux versions différentes des tampons de protocole Google : Compacte et autodescripteur GPB.
Compact GPB est le codage le plus efficace, mais nécessite un .proto unique pour chaque modèle YANG qui est diffusé. La GPB autodescription est moins efficace, mais elle utilise un seul fichier .proto pour décoder tous les modèles YANG parce que les clés sont passées sous forme de chaînes dans le .proto.
Direction de la session : Deux options s'offrent à vous pour lancer une session dans le déploiement de télémétrie. Le routeur peut “ un ” de numérotation directe au collecteur ou le collecteur peut “ un ” de numérotation directe au routeur.
YANG est la norme acceptée par le secteur pour la modélisation des données et la pile de programmabilité de Cisco l'utilise également pour former un ensemble de données structuré qui peut être codé et transporté aussi rapidement que possible sur le réseau.
Ces modèles de données, associés à des formats de codage spécifiques et à des protocoles de transport comme nous l'avons vu plus haut, font de Model Driven Telemetry (MDT) une solution complète pour Analytics.
Exemples de configuration de télémétrie
IOS-XR
Séparation de la configuration de numérotation sortant
En mode de numérotation sortante, le routeur est chargé d'initier une session TCP au collecteur et d'envoyer les données spécifiées par le groupe de capteurs dans l'abonnement.
Numérotation à distance par télémétrieDu point de vue de la configuration, la configuration de télémétrie est un processus en trois étapes. Tout d'abord, nous identifions les informations que nous voulons diffuser et capturer sous la configuration du groupe de capteurs. Deuxièmement, nous identifions la destination vers laquelle les informations doivent être diffusées et nous les capturons dans la configuration du groupe de destinations. Troisièmement, nous utilisons les informations identifiées lors des deux étapes précédentes pour configurer l'abonnement réel.
- Définir des groupes de capteurs
- Définir des groupes de destinations
- Définir l'abonnement
Définir des groupes de capteurs
La configuration du groupe de capteurs identifie les informations à diffuser. Le modèle de configuration suivant fournit la configuration requise pour configurer les groupes de capteurs.
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#
L'exemple suivant montre un exemple réel de l'interface de ligne de commande du routeur, où un exemple réel de configuration du groupe de capteurs :
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#
Nous pouvons avoir plusieurs chemins de capteur dans le cadre de la même définition SensorGroup :
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#
Définir des groupes de destinations
La configuration du groupe de destinations identifie la destination vers laquelle les informations doivent être diffusées.
Il comporte trois paramètres clés
- Orientation de la session
- Codage à utiliser
- Protocole de transport à utiliser
Voici un exemple :
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#
Définir l'abonnement
L'abonnement lie les informations du groupe de capteurs et du groupe de destinations en tant que partie finale de la configuration. L'intervalle d'échantillonnage est défini comme faisant partie de l'abonnement.
Voici un exemple :
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#
Exemple de configuration complète
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#
Avantages des appels sortants
- Plus grande flexibilité pour les options de transport.
- Pas besoin d'ouvrir des ports pour le trafic de gestion entrant.
- Anycast & Load-Balancing.
Interruption de configuration de numérotation
En mode d'appel entrant, un collecteur MDT / récepteur / orchestrateur se connecte au routeur et s'abonne dynamiquement à un ou plusieurs chemins de capteur ou abonnements. Le routeur agit en tant que serveur et le client en tant que récepteur.
Une seule session est formée et le routeur transmet les données de télémétrie via la même session. Cet abonnement dynamique se termine lorsque le destinataire annule l'abonnement ou lorsque la session se termine.
Numérotation de télémétrie
Comme le collecteur “ des ” de numérotation au routeur, il n'est pas nécessaire de spécifier chaque destination MDT dans la configuration. Il vous suffit d'activer le service gRPC sur le routeur, de connecter votre client et d'activer dynamiquement l'abonnement de télémétrie que vous souhaitez.
Du point de vue de la configuration, Telemetry Configuration est un processus en trois étapes similaire à celui décrit ci-dessus. Premièrement, nous devons activer gRPC. Deuxièmement, nous identifions la destination vers laquelle les informations doivent être diffusées et nous les capturons dans la configuration du groupe Sesnor. Troisièmement, nous utilisons les informations identifiées lors des deux étapes précédentes pour configurer l'abonnement réel.
- Activer gRPC
- Définir des groupes de capteurs
- Définir l'abonnement
Activer gRPC
Premièrement, nous devons activer le serveur gRPC sur le routeur pour accepter les connexions entrantes du collecteur.
- La plage <port-number> va de 57344 à 57999. Si un numéro de port n'est pas disponible, une erreur s'affiche.
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#
Définir des groupes de capteurs
La configuration du groupe de capteurs identifie les informations à diffuser. Le modèle de configuration suivant fournit la configuration requise pour configurer les groupes de capteurs.
L'exemple suivant montre un exemple réel de l'interface de ligne de commande du routeur, où un exemple réel de configuration du groupe de capteurs
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#
Définir l'abonnement
L'abonnement relie le groupe de capteurs et gRPC en tant que partie finale de la configuration. L'intervalle d'échantillonnage est défini comme faisant partie de l'abonnement.
Le modèle de configuration suivant fournit la configuration requise pour configurer l'abonnement.
L'exemple suivant montre un exemple réel de l'interface de ligne de commande du routeur dans lequel nous créons un abonnement et relions ensemble le groupe de capteurs et le groupe de destinations, ainsi que la définition du taux d'échantillonnage.
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#
Modèle et exemple de configuration complets
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#
Avantages de la numérotation
- Un canal unique pour la configuration et la diffusion en continu
- Port d'écoute sur le routeur/périphérique
- Connexion transitoire
- Actuellement, seul gRPC/gNMI est disponible
Télémétrie basée sur les événements
Dans la télémétrie pilotée par événement, les données de l'ensemble de données abonné ne sont diffusées que lorsqu'un événement se produit.
Configuration de télémétrie basée sur les événements
La configuration de la télémétrie basée sur les événements est similaire à celle de la télémétrie basée sur les cadences, la seule différence dans la configuration de la télémétrie basée sur les événements est celle de l'intervalle d'échantillonnage. La configuration de la valeur de l'intervalle d'exemple sur zéro définit l'abonnement pour la télémétrie basée sur les événements.
Modèle et exemple de configuration complets pour DIAL-OUT
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#
L'exemple suivant illustre un exemple réel de l'interface de ligne de commande du routeur.
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#
Modèle et exemple de configuration complets pour la COMPOSANTE
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#
L'exemple suivant illustre un exemple réel de l'interface de ligne de commande du routeur.
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#
Validation de la télémétrie à l'aide des commandes SHOW
Du point de vue du routeur, nous pouvons vérifier les paramètres configurés pour chaque groupe de capteurs, groupe de destinations et abonnement
// 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#
Pile de collecte de télémétrie
Outre la configuration du routeur, une solution basée sur la télémétrie a nécessité plusieurs composants tels que le collecteur, la base de données et le logiciel de surveillance/analyse. Ces composants peuvent être configurés séparément ou faire partie d'un seul produit complet.
- Un décodeur doit être installé pour prendre les paquets entrants et les transmettre pour plus de stockage.
- Une base de données de séries chronologiques (appelée TSDB) est nécessaire pour stocker les informations en continu.
- Un outil graphique est également nécessaire pour visualiser les données provenant de la base de données interne.
La description détaillée de la pile de collection dépasse le cadre de la description. Cisco Crossworks Health Insights permet une télémétrie automatique dans laquelle les périphériques sont automatiquement configurés par télémétrie et où les tables/schémas sont créés dans une base de données Time Series (TSDB). Il rationalise les frais généraux d'exploitation et de gestion du réseau liés à la collecte et au nettoyage des données, permettant ainsi aux opérateurs de se concentrer sur leurs objectifs commerciaux. L'utilisation d'un collecteur commun pour collecter les données des périphériques réseau via SNMP, CLI et la télémétrie pilotée par modèle permet d'éviter la duplication des données et de réduire la charge sur les périphériques et le réseau.
Considérations relatives au déploiement de la télémétrie dans un réseau
Vous trouverez ci-dessous diverses considérations à prendre en compte lors de l'analyse du déploiement de la télémétrie dans un réseau.
Évolutivité
La télémétrie peut diffuser une quantité considérable de données et il est recommandé d'examiner attentivement les aspects liés à l'évolutivité.
Diffuser uniquement les données requises
Chaque modèle Yang aura plusieurs noeuds Leaf. Il est conseillé d’être précis au sujet de l’information requise et de l’information non requise. Il est recommandé d'explorer les modèles Yang et d'identifier le chemin de données requis par les exemples d'utilisation de télémétrie.
Tenez compte de la quantité de données en continu
La quantité totale de données de télémétrie diffusées devra être prise en compte sur les points suivants :
- Allocation de bande passante au sein du réseau
- QoS
- Performances d'applications/de logiciels supplémentaires comme
- Logiciel de collecte
- Base de données Time Series
- Logiciel d'analyse/visualisation
- L'efficacité du codage (abordée à la section « Directives de conception de télémétrie ») influe directement sur la quantité de données diffusées. Le compacte GPB est recommandé dans la mesure du possible.
- L'intervalle de collecte a un impact direct sur plusieurs aspects, notamment, mais sans s'y limiter, les suivants.
- Utilisation de la bande passante sur le réseau
- Besoins en stockage sur la base de données
- Performances de l'appareil qui diffuse les données en continu
Il est recommandé d'évaluer la fréquence de la collecte en fonction des exigences de la demande.
Dans l'ensemble, il est recommandé de considérer le filtrage des données indésirables à la source ou à la destination comme étant possible. Nous avons la possibilité de filtrer les données indésirables. Le filtrage peut être effectué sur deux niveaux : -
- À la source : périphériques diffusant les données en continu.
- À la destination : le collecteur collecte et normalise les données. (Le filtrage au niveau du collecteur dépasse le cadre de ce document)
L'exemple suivant montre comment filtrer les données uniquement pour les interfaces Hundered Gig dans les chemins des capteurs en appliquant des caractères génériques.
sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface[interface-name='HundredGigE*']/latest/generic-counters
Références
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
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)