Dans l’article précédent, j’ai testé la Streaming Telemetry, nous avons pu découvrir les fondamentaux de la streaming telemetry : pourquoi et comment (via un lab),
Aujourd’hui, nous allons voir un cas client concret : celui de l’Université de Rennes,
L’Université de Rennes en bref
L’Université de Rennes regroupe des composantes de formation (UFR, facultés, écoles, instituts), des pôles de recherche et cinq grandes écoles qui participent à l’élaboration et à la mise en œuvre de la stratégie de l’Université de Rennes : École des hautes études en santé publique (EHESP), École nationale supérieure de chimie de Rennes (ENSCR), École normale supérieure de Rennes (ENS Rennes), Institut national des sciences appliquées de Rennes (INSA Rennes), Sciences Po Rennes.
L’équipe réseau de la DSI gère une partie du réseau de l’Université de Rennes étendu sur toute la Bretagne (6 campus et 2 stations biologiques) :
Depuis 2022, la DSI de l’Université de Rennes a un parc matériel et logiciel quasiment homogène sur les équipements réseau (filaire et Wi-Fi) et un seul constructeur : Cisco, avec la gamme Catalyst 9000.
Quels sont les besoins réseaux de l’Université de Rennes ?
Historiquement, pour surveiller l’état du réseau, la DSI de l’Université de Rennes avait mis en place une supervision croisée entre Cacti, NetXMS et des scripts maison.
Pourquoi vouloir faire évoluer cette supervision ? Roderick PETETIN, Ingénieur réseau à la DSI de l’Université de Rennes, nous l’explique :
“Nous étions plutôt satisfaits de cette infrastructure sauf sur la partie métrologie : nos graphes n’étaient pas assez précis pour certaines situations d’analyse (pics de charge passés sous silence parce que situés entre deux points, moyennage des points trop rapide, etc). Nous avons donc voulu étudier une solution de métrologie plus précise et plus ergonomique que Cacti.”
Ces notions de précision et d’ergonomie ont été traduites en objectifs clairs par la DSI de l’Université de Rennes :
Et devinez quoi 🙂 ? La streaming telemetry permet d’accomplir ces objectifs, Roderick nous le confirme :
“Au vu de nos objectifs, nous avons voulu tester la streaming telemetry qui a déjà fait l’objet de retours d’expérience présentés sur le blog Cisco ou lors de précédentes éditions des JRES. Nos équipements étaient compatibles avec cette technologie et nous étions curieux de voir les résultats que cela pouvait donner.”
Comment l’Université de Rennes à mis en place la streaming telemetry ?
Les objectifs sont clairs et la solution est identifiée : il ne manque plus qu’à mettre la streaming telemetry en place !
1. Configuration des équipements Cisco
Exemple de configuration d’envoi d’une métrique (cpu) sur un switch en IOS-XE :
telemetry ietf subscription 101 encoding encode-kvgpb filter xpath /process-cpu-ios-xe-oper: cpu-usage/cpu-utilization/five-seconds stream yang-push update-policy periodic 1000 receiver ip address 10.60.255.3 57000 protocol grpc-tcp
(Si ces lignes de configuration vous paraissent obscures, pas de panique ! Je vous renvoie vers l’article j’ai testé la Streaming Telemetry, qui explique en détail le fonctionnement de la streaming telemetry).
Pour résumer ces lignes, on déclare un numéro de souscription puis :
- encoding : encodage
- filter : on cible le chemin de ce qu’on veut envoyer (xpath), ici le « cpu utilization »
- stream : sous quelle forme on l’envoie
- update-policy : à quel moment on déclenche l’envoi (ici toutes les 10 secondes – on peut
également envoyer les données sur changement d’état) - receiver : les paramètres du serveur réceptionnant les données (IP, port, protocole)
La question que vous allez sûrement vous poser est : comment trouver le xpath ?
Je vous recommande d’utiliser un outil pour explorer les modèles YANG.
Jérôme DURAND, dans son article J’ai testé: Dial-in telemetry avec NETCONF utilise YANG Suite pour explorer les modèles YANG, et Antoine ORSONI nous explique comment installer l’outil dans son article YANG Suite, l’attente est finie !
2. Mise en place de la stack TIG sur un serveur
Les tests ayant donné plus que satisfaction (dashboards et utilisation simple de Grafana, précision des données, ajout de nouvelles métriques), l’Université de Rennes a décidé de mettre en place une infrastructure de production. Pour recevoir ces données et les exploiter, Roderick a configuré plusieurs briques logicielles : Telegraf, InfluxDB et Grafana sur un même serveur :
- Telegraf : collecte, transforme et ventile les données
- InfluxDB : stocke les données
- Grafana : va interroger InfluxDB et présente les données sous forme de dashboards
Exemple de configuration d’entrée Telegraf (le plugin cisco_telemetry_mdt qui va écouter sur le port 57000) :
[[inputs.cisco_telemetry_mdt]] ## Telemetry transport can be "tcp" or "grpc". TLS is only supported when ## using the grpc transport. transport = "grpc" ## Address and port to host telemetry listener service_address = ":57000" max_msg_size = 12000000 Exemple de configuration de sortie Telegraf (plugin InfluxDB, quelles données on envoie et vers quel bucket (bdd)): [[outputs.influxdb_v2]] urls = ["https://127.0.0.1:8086"] token = "xxx" organization = "UR1" bucket = "UR1_Internal" insecure_skip_verify = true content_encoding = "gzip" namepass = ["internal*", "disk*", "system*", "mem*", "swap*", "diskio*", "cpu* "] alias = "UR1_Internal"
3. Les choix de redondance
Pour répondre à l’objectif de résilience, l’Université de Rennes a choisi d’envoyer les métriques réseaux vers 2 serveurs différents, comme nous l’explique Roderick :
“Pour adresser le plus grand nombre de pannes possibles, nous voulions une machine physique placée sur le même réseau que les équipements et une VM. De cette manière, nous pouvons faire face aux problèmes de routage et aux problèmes de l’infrastructure de virtualisation de serveurs”
Sur les switches, les souscriptions de télémétrie ont été ajoutées à la configuration de base de tous les switches. Donc, dès qu’un switch est connecté au réseau, il commence à envoyer des données aux 2 serveurs :
4. Les choix de données et de stockage
Les statistiques d’interfaces sont envoyées toutes les 10 secondes et la fréquence d’envoi des autres métriques est variable (de 10 secondes à 60 minutes).
Voici les métriques récupérées pour tous les switches :
• Dernier boot
• Serial number
• Version d’OS
• Métriques système (CPU, RAM, températures)
• CDP neighbors
• Taille de la table @MAC
• Stats d’interfaces (trafic, erreurs, broadcast, multicast)
On peut se demander combien de temps l’Université de Rennes conserve ces données ? A nouveau, Roderick nous éclaire :
“Nous gardons ces données brutes pendant 30 jours. Ensuite, nous déclenchons des tâches de « downsizing » qui moyennent ces données par minute, nous les gardons ensuite pendant 1 an.”
Quel est le résultat pour l’Université de Rennes ?
Si on résume, Telegraf reçoit les données, les transforme si besoin (format, sélection selon critères, etc) et les stocke dans des buckets InfluxDB (en fonction de leur origine, de leur format ou du plugin source) :
L’Université de Rennes crée ensuite les dashboards Grafana exploitant ces données. Voici des captures d’écran d’un des dashboards réalisé dans Grafana pour les switches d’accès :
La solution de streaming telemetry répond au besoin de supervision du réseau, avec quelques limites identifiées par Roderick :
- “Trouver le bon modèle et les xpath correspondant à ce qu’on cherche peut être long et fastidieux.”
- “L’apprentissage d’InfluxDB et Grafana a été long et fastidieux (philosophie InfluxDB, langage flux, données temporelles, paramétrage fin de Grafana).”
- “La synchronisation entre la fréquence d’échantillon sur un switch, la fréquence d’envoi et la façon d’afficher ces données dans Grafana peut être compliquée.”
- “Les équipements Cisco de notre parc sont tous capables de faire de la streaming telemetry. Néanmoins, Fortinet (dont nous utilisons les solutions pour nos routeurs/pare-feux) n’a pas implémenté cette fonctionnalité sur ses équipements.”
Quid de l’automatisation du réseau ? Roderick étudie Catalyst Center comme outil d’automatisation et d’assurance réseau, en complément à la solution de streaming telemetry mise en place :
“Nous avions dans l’idée de rationaliser le nombre d’outils utilisés pour la supervision/métrologie réseau mais nous n’avons pas trouvé de moyen efficace de générer des alertes dans InfluxDB ou Grafana (trop de métriques à gérer pour générer les alertes via ces outils). Nous avons donc gardé nos scripts d’alerte maison (shell majoritairement), et nous étudions actuellement la mise en place de Catalyst Center“
Un grand merci à l’Université de Rennes et à Roderick PETETIN pour ce témoignage sur la streaming telemetry ! N’hésitez pas à nous partager d’autres retours d’experience sur les solutions Cisco !
Authors
