AUF DIESER SEITE
Übersicht über die Junos Telemetry Interface
Da die Anzahl der Objekte im Netzwerk und die von ihnen generierten Metriken gestiegen sind, haben herkömmliche Modelle wie SNMP, die zur Erstellung von Betriebsstatistiken zur Überwachung des Zustands eines Netzwerks verwendet wurden, die Skalierung und Effizienz von Netzwerkelementen einschränkungen. Das sogenannte Pull-Modell von SNMP und die CLI, das eine zusätzliche Verarbeitung erfordert, um das Netzwerkelement regelmäßig abzufragen, schränkt direkt die Skalierung ein.
Das Junos Telemetry Interface (JTI) überwindet diese Grenzen, indem es sich auf ein sogenanntes Push-Modell verlässt, um Daten asynchron zu liefern, wodurch Polling überflüssig wird. Eine Anfrage zum Senden von Daten wird einmal von einer Managementstation gesendet, um regelmäßige Updates zu streamen. Dadurch ist JTI hoch skalierbar und kann die Überwachung von Tausenden von Objekten in einem Netzwerk unterstützen.
Junos Telemetry Interface wurde in Junos OS Version 15.1F3 eingeführt, auf Routern der MX-Serie mit Schnittstellen, die auf MPC1 bis MPC6E konfiguriert sind, und auf Routern der PTX-Serie mit Schnittstellen, die auf FPC3 konfiguriert sind. Ab Junos OS Version 15.1F5 wird Junos Telemetry Interface auch auf MPC7E, MPC8E und MPC9E auf Routern der MX-Serie unterstützt.
Ab Junos OS Version 16.1R3 werden auch FPC1, FPC2 und duale Routing-Engines auf Routern der PTX-Serie unterstützt.
Ab Junos OS Version 17.2R1 werden auch QFX10002-, QFX10008- und QFX10016-Switches, QFX5200-Switches sowie PTX1000- und PTX10008-Router unterstützt. QFX5200 Swtiches unterstützen nur gRPC-Sensoren.
Ab Junos OS Version 17.3R1 werden auch QFX5110-Switches, EX4600-, EX4600-VC- und EX9200-Switches und das Routing and Control Board (RCB) auf PTX3000 Routern unterstützt. QFX5110-Switches unterstützen nur gRPC-Sensoren.
Ab Junos OS Version 17.4R1 werden PTX10016-Router und virtuelle Router der MX-Serie (vMX) unterstützt.
Ab Junos OS Version 18.2R1 werden auch PTX10002-Router unterstützt.
Telemetriesensoren und Datenmodelle
Mit der Junos Telemetry Interface können Sie Sensoren bereitstellen, um Daten für verschiedene Systemressourcen zu erfassen und zu exportieren, z. B. für physische Schnittstellen und Firewall-Filter. Es werden zwei Datenmodelle unterstützt, von denen jedes eine andere Transportart verwendet:
Ein offenes und erweiterbares Datenmodell, das von Juniper Networks definiert wurde. Daten werden als strukturierte Nachrichten mit Google-Protokollpuffern (gpb) generiert. Die Dateien, die die einzelnen
.protoNachrichten definieren, werden auf der Website von Juniper Networks veröffentlicht. Native Sensoren exportieren Mithilfe des User Datagram Protocol (UDP) Daten in der Nähe der Quelle, z. B. der Linecard oder der Netzwerkverarbeitungseinheit (NPU). Da dieses Modell über eine verteilte Architektur verfügt, lässt es sich problemlos skalieren.Ein OpenConfig-Datenmodell, das Daten als gpb-Nachrichten in einem universellen Schlüssel-/Wertformat generiert. OpenConfig für Junos OS, das Sie herunterladen müssen, unterstützt die YANG-Datenmodelle. gRPC Remote Procedure Calls (gRPC) werden verwendet, um Sensoren bereitzustellen und Telemetriedaten zu abonnieren und zu empfangen. gRPC basiert auf TCP und unterstützt SSL-Verschlüsselung, gilt also als sicher und zuverlässig. Wenn auf Ihrem Gerät von Juniper Networks eine Version von Junos OS mit dem aktualisierten FreeBSD-Kernel ausgeführt wird, müssen Sie für dieses Modell das Junos Network Agent-Paket herunterladen, das auf der Routing-Engine ausgeführt wird und Schnittstellen zur Verwaltung von gRPC-Abonnements bereitstellt. Bei anderen Versionen von Junos OS sind die Funktionen des Netzwerkagenten in die Software eingebettet. Ab Junos OS Version 18.2R1 können OpenConfig-basierte Routing-Engine (RE)-Sensoren Daten als gpb strukturierte Nachrichten über UDP streamen.
Verwendung und Vorteile
Eine primäre Funktion der Junos Telemetry Interface ist die Leistungsüberwachung. Das Streaming von Daten an ein Leistungsmanagementsystem ermöglicht es Netzwerkadministratoren, Trends bei der Verbindungs- und Knotenauslastung zu messen und Probleme wie Netzwerküberlastung in Echtzeit zu beheben.
In einer typischen Bereitstellung streamt das Netzwerkelement oder Gerät doppelte Daten an zwei Zielserver, die als Leistungsmanagementsystem-Systemsammler fungieren. Das Streaming von Daten an zwei Datensammler sorgt für Redundanz. In Abbildung 1 finden Sie eine Veranschaulichung, wie die Leistungsmanagementsystemsammler Daten anfordern und wie das Gerät Daten streamt. Das Gerät stellt Sensoren bereit, um Daten über Befehlszeilenschnittstelle (CLI), Konfiguration über NETCONF oder gRPC-Abonnementanrufe zu erfassen und zu exportieren. Die Datensammler fordern Daten an, indem sie ein Telemetrieabonnement starten. Die Daten werden nur einmal angefordert und in regelmäßigen Abständen gestreamt.
Ab Junos OS Version 18.1R1 ist ein neuer Sensor verfügbar, mit dem Syslog-Daten an Netzwerktelemetriesammsysteme gestreamt werden können. Mit dem Sensor /junos/events/ und einem Exportprofil mit einer reporting-rate 0 können Sie jetzt Ereignisdaten zusammen mit statistischen Daten an Ihre Telemetrieerfassungssysteme streamen.
Andere Anwendungen des Junos Telemetry Interface umfassen die Bereitstellung von Echtzeitdaten zur Unterstützung der Synchronisierung des Betriebszustands zwischen einem Netzwerkelement und einem externen Controller, wie z. B. dem Northstar Controller, der die Erstellung von Traffic-Engineering-Pfaden im gesamten Netzwerk automatisiert. Der NorthStar-Controller kann Telemetriedaten zu bestimmten Netzwerkelementen abonnieren, z. B. LSP-Statistiken (Label-Switched Path).