RMON: Remote Monitoring

Kommentieren Drucken
Teil 64 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

SNMP lässt in seiner Basis-Version einige Fragen offen. Eine direkte Überwachung von Endgeräten ist durch die damit verbundene hohe Polling-Rate praktisch nicht durchführbar. Die vielen Überwachungspunkte können von den herkömmlichen NMS nicht gehandhabt werden. Hier hilft RMON.

SNMP fehlt die vor allem Möglichkeit der Analyse von Kommunikationsbeziehungen (Kommunikations-Partner, eingesetzte Protokolle, Datenströme). Wir möchten den Zustand eines Netzes (Auslastung, logische Fehler, Protokoll-Fehler) besser bewerten können und die entsprechende Information archivieren (was war am um los?). RMON (Remote Monitoring) ist eine Antwort auf diese Problembereiche. Eine RMON-Probe sitzt an interessierenden Stellen eines Netzwerks und speichert Online-Werte bzw. Werte, die sie selbst berechnet hat. Die Werte sind in der RMON-MIB spezifiziert und werden dort in 9 Funktionsgruppen eingeteilt. Durch diese Definition sind RMON-Probes herstellerneutral und können theoretisch gemischt werden. Der Standard definiert allerdings keine RMON-Anwendungen, so dass diese herstellerspezifisch bleiben. Auch reicht leider die Abdeckung einer RMON-Funktionsgruppe aus, um ein Produkt RMON-Probe zu nennen. RMON ist ein unverzichtbarer Bestandteil jeder Netzwerk-Management-Lösung, unabhängig von der Realisierung über Hubs, Bridges/Router, Probes oder PC-Software. Die Applikationen muss der Anwender heute oft noch selbst schreiben, das kann sich allerdings schnell ändern.

LAN-Monitore alter Bauart, wie LAN-Analyser oder Probes haben mit ganz wenigen Ausnahmen nur die Möglichkeit, den Datenverkehr auf einem LAN-Segment zu überwachen. Sie haben einen eingeschränkten Funktionsumfang, sind auf keinen Fall kompatibel untereinander und dadurch letztlich teuer. Die Bereitstellung einer Analyse-Funktion als Software-Modul wie unter Novell NMS selig ist heute noch als Ausnahme zu bezeichnen. Die meisten Analysatoren sind Zwitterwesen aus Oszilloskopen und Notebooks.

RMON definiert die nächste, der fortgeschrittenen LAN-Technik angepasste Generation von Netzwerk-Monitoren und ist auch dem Erfolg beim Anwender nach zu urteilen, wichtigste Erweiterung der klassischen SNMP-Umgebung. RMON kommt natürlich auch vom IETF (RFC 1271) und ist dadurch herstellerunabhängig. RMON definiert eine Remote Monitoring MIB, die die MIB-2 um wesentliche Informationen über das Netzwerk erweitert und liefert damit einen Standard für den Verkehr zwischen einer SNMP-NMS und einem remote Monitor. Also wird ein Client/Server-Modell benutzt. Die RMON-Agenten sind nicht starr, sondern programmierbar und können z. B. dynamische Variable erzeugen oder Aktionen starten. Bislang war ein LAN-Monitor und damit seine Ergebnisse völlig isoliert vom »Rest« des Netzwerk-Managements. Die Integration durch RMON in ein NMS liefert eine bessere Präsentation der Daten, was vor allem die Gesamtübersicht anbetrifft. Für den Preis eines einzigen klassischen Analysators lassen sich im Allgemeinen mehrere RMON-Probes installieren, man kann also mit weniger Kapitaleinsatz mehr überwachen. Die Integration von RMON-Lösungen und Ergebnissen der RMON Analysen in die einheitliche Benutzerschnittstelle einer Management-Plattform erlaubt das zügige Arbeiten mit dieser Umgebung und unter der Voraussetzung eines ordentlichen Plattform APIs, wie es eigentlich bei allen Markenprodukten gegeben ist, auch eine systematische Übergabe der Ergebnisse an andere Anwendungen. Mögliche Funktionsbereiche von RMON sind:

  • erweiterte Error-Counter bei der Paketanalyse,
  • konfigurierbare Filter zum Sammeln und Analysieren von Paketen,
  • konfigurierbare historische Trendanalyse,
  • Verkehrsmatrix,
  • Definition von Alarmen und Events (Log und SNMP-Trap).

Zum Basiskonzept gehört, dass die RMON-Agenten voll in das SNMP-Modell eingegliedert sind und keinen erheblichen Aufwand bei der Implementierung mit sich ziehen, sondern als kleine Software-Päckchen in dedizierten Geräten (Net-Probes), nichtdedizierten Geräten (Soft-Probe z. B. in einem PC) sowie infrastrukturellen Geräten im Netz wie Hubs, Router oder Brücken installiert werden können. Die Anwendung, die die von den Probes gelieferten Daten auswertet, sitzt meist auf der SNMP-NMS. Ziele bei der Entwicklung von RMON waren:

  • Umfassendes Monitoring und Erweiterung der ansonsten mit SNMP abfragbaren Daten,
  • Multivendor-Fähigkeit durch den SNMP-Rahmen,
  • Erweitertes Management für Systeme, die nicht SNMP-fähig sind,
  • Proxy Management durch lokales Sammeln von Daten und Weiterleitung auf Anforderung,
  • Anwendbarkeit auf unterschiedliche Medien (Ethernet, Token Ring, FDDI, WAN, mittlerweile ATM),
  • Möglichkeit der Bedienung mehrerer NMS durch eine Probe,
  • sinnvolle Leistung durch geeignete Voraussetzungen in der Datenstruktur.

Der an der RMON-Spezifikation wesentliche Teil, die RMON-MIB, ist als Subtree-16 in die MIB-II integriert und in 9 Gruppen unterteilt, die unter Berücksichtigung von Abhängigkeiten jedoch optional sind. Möchte man allerdings nur ein einziges Objekt der Gruppe nutzen, muss die gesamte Gruppe implementiert sein. Auch RMON ist in Bewegung, da der Standard zunächst primär für Ethernet-Netze entwickelt wurde und andere Systeme erst mit der Zeit berücksichtigt wurden/werden. Dadurch sind verschiedene Einzelheiten zunächst etwas auf Ethernet fixiert, was aber nicht den Ausschluss weiterer Systeme zu bedeuten hat.

Die Statistics Group ist für die an einem Netz üblicherweise anfallenden Daten der unteren Schichten zuständig, allgemein immer Pakete oder einzelne Bytes, bei Ethernet zudem z. B. Broadcasts, Multicasts, Kollisionen, verlorengegangene Pakete usf. Es gibt für alle Fälle einen 32-Bit-Zähler. Die Statistics Group hat aber auch ein paar eigenständige Funktionen. So können z. B. die Längenverteilung von Paketen berechnet und Fehler bestimmter Typen aufgezählt werden (zu kleine Pakete, zu große Pakete, Fragmente, Jabber, erfolgreiche Anordnung von Sendern mit dem Algorithmus zur Kollisionssteuerung (Alignment).

Die History Group ist eine unmittelbare Ergänzung der Statistics Group, weil sie alle von dieser erzeugten Daten außer der Längenverteilung sammelt. Die Stichprobenintervalle und die Anzahl der Stichproben insgesamt können vom Benutzer frei definiert werden und sind nur durch die Betriebsmittel des Agenten beschränkt. Hat der Agent nur einen kleinen Speicher, kann er nicht allzu viele Stichproben sammeln. Hat er als Gast in einem Multitasking-PC nur selten Zutritt zur CPU, wird er keine ganz kurzen Intervalle realisieren können. Üblich sind heute oft Stichproben mit Intervallen zwischen 30 Sekunden und 30 Minuten.

Die Alarm Gruppe implementiert einen Mechanismus zur Definition von Schwellwerten, bei deren Verletzung ein Alarm generiert wird. Jeder im Agent geführte Counter kann hierzu herangezogen werden und man definiert einen Alarm durch die Angabe von Variable, Stichprobenintervall und Schwellwert. Es gibt mehrere Alternativen für Schwellwerte, absolute und Delta-Schwellwerte sowie fallende und steigende Schwellwerte. Letztere benutzt man dann, wenn man Alarme bei geringen Schwankungen vermeiden möchte. Ein Alarm wird nur dann generiert, wenn der Wert eindeutig in eine Richtung »ausbricht«. Voraussetzung für die Alarm-Gruppe ist die Implementierung der Event-Gruppe.

Die Host-Gruppe sammelt statistische Daten zu jedem Host im Segment, wie Pakete, gesendete und empfangene Bytes, Broadcasts, Multicasts oder Errors beim Senden. Die Host-Gruppe orientiert sich dabei an MAC-Adressen. Man definiert üblicherweise eine gewissen Anzahl von Hosts vor und parametrisiert sie bis zu einem gewissen Grad, unbekannte Hosts werden mit ihrer MAC-Adresse aufgenommen. Die gesammelte Datenmenge ist wiederum abhängig von den Möglichkeiten des Agenten. Bei Überlauf des zu Verfügung stehenden Speichers werden die ältesten Daten einfach gelöscht.

Die Host TopN-Gruppe greift auf die Daten der Host-Gruppe zu und liefert sozusagen sortierte Statistiken. Die ausgewählten Daten und die Dauer des Tests sind definierbar. Während eines Tests werden nur die ausgewählten Daten registriert. Man könnte die Funktionen der Host TopN-Gruppe natürlich auch auf der NMS laufen lassen. Die Auslagerung in die Agenten senkt jedoch die Netzlast und die Last auf der NMS. Voraussetzung ist die Implementierung der Host-Gruppe.

Die Matrix-Gruppe erstellt eine Verkehrsmatrix der Kommunikation zwischen den angeschlossenen Endgeräten mit den MAC-Layer-Adressen als Grundlage. Die ermittelten Daten, wie Pakete, Errors, Bytes, können nach Quell- und Zieladressen sortiert werden. Man kann mit den Ergebnissen dieser Gruppe das Netzdesign optimieren, z. B. durch Bestimmung des optimalen Standortes eines Servers.

Die Filter Gruppe gibt dem Netz-Administrator Instrumente, ohne die er im allgemeinen nicht auszukommen glaubt: das Setzen von Filtern zur Auswahl bestimmter Pakete auf dem Netz. Man kann nach beliebigen Bitmustern filtern, aber auch z. B. nach Status (gültig, Error usw.). Die Filter können mit einfachen Operatoren verknüpft werden (AND, OR, NOT, EXOR, =, =/=), so dass letztlich die Filter Gruppe den Aufbau von Protokoll-Analysator-Anwendungen auf der NMS ermöglicht. Dies ist ein ganz großer Vorzug von RMON, vor allem, wenn man sich die Preise für herkömmliche Analysatoren ansieht.

Die Packet Capture Group ist eine Erweiterung der Filter-Gruppe und ermöglicht eine flexible Definition sog. Trace-Puffer, die nach Vorgabe der aktuell gesetzten Filter gefüllt werden. Definierbar sind die Größe der Puffer, das Verhalten bei gefülltem Puffer und die Anzahl der zu speichernden Bytes eines Paketes. Voraussetzung ist die Implementierung der Filter Gruppe.

Die Event Group ist eine Erweiterung fast aller anderen Gruppen und unterstützt die Definition von »Events« die durch eine vorher definierte Bedingung in der RMON MIB hervorgerufen werden, also z. B. fallende/steigende Schwellwerte in der Alarm-Gruppe oder die Filterung eines bestimmten Paketes in der Filter-Gruppe. Mögliche Aktionen sind Aufzeichnen als Log (enthält Zeitstempel und Beschreibung des Events) oder Senden eines SNMP-Traps.

Die RMON-Gruppen erzeugen letztlich einen Haufen von Tabellen. Der Nutzwert einer RMON-Implementierung hängt also völlig davon ab, wie die Anwendungen auf den Netzwerk-Management Plattformen und die Administratoren mit den Tabellen und ihren Werten umgehen.

Wegen der Randbedingungen von SNMP ist RMON auf solche Netze beschränkt, bei denen der Verkehr zwischen Netz-Management-Station und RMON-Probe mittels TCP/IP möglich ist. Anwendungen zur Protokollanalyse erkennen jedoch auch andere Protokollstacks, so dass RMON auch in Netzen mit gemischten Protokollstacks eingesetzt werden kann, nur TCP/IP muss eben dabei sein.

RMON ist ein Werkzeug zur Datensammlung und hat wie alle derartige Werkzeuge das Problem, dass es schnell des Guten zuviel werden kann. Wenn man z. B. einen Switch mit einem starken RMON-Agenten ausrüstet, der alle Ethernet-Gruppen beherrscht und darüber hinaus genügend Rechen- und Speicherkapazität besitzt und alle diese Informationen zur NMS schickt, kann es passieren, dass der Netzwerkanschluss der NMS sitzt, erheblich belastet wird. Gleiches gilt aber auch für den Administrator, der mit der Flut der Informationen nichts Rechtes mehr anfangen kann. Überspitzt gesagt, muss man RMON als Datensammeltool noch um ein Tool zur Datenreduktion erweitern. Das Problem an sich ist nicht neu: in einem SNA-Kontrollzentrum liefen früher auf Dutzenden Bildschirmen sekündlich auch wesentlich mehr Nachrichten ein, als die Administratoren Augen haben. Man behilft sich oft mit der Intuition erfahrener Operatoren beim Herausfischen des Wesentlichen. Dies ist bei LANs aber nicht empfehlenswert.

RMON profitiert natürlich von anderen Entwicklungsbereichen in SNMP. So vereinfacht z. B. der Bulk-Transfer in SNMP2 die Kommunikation zwischen Probes und NMS erheblich. Die 9 RMON-Gruppen wurden vor allem im Hinblick auf Ethernet-Netze entworfen. Naheliegende Erweiterung war also vor allem die schnelle Definition von RMON Token Ring Subgroups.

Entsprechend den Arbeiten zu SNMP II gab es auch Arbeiten an einer RMON II MIB. Eine neue Spezifikationsmethode für Management-Information wurde hier zum Standard für die Kontrolle und Konfiguration aller SNMP RMON-Probes in einem Multivendor-Netzwerk. Die sog. Aspen-MIB, die von HP und Axon entwickelt wurde, spezifiziert Prozeduren für die Fernkonfiguration von Probe Parametern einschl. IP-Adressen, vordefinierten Gateways und Trap-Zielen in einer Mehrplattformumgebung. Die MIB definiert des weiteren vier Sicherheitsstufen für den bislang in keinster Weise gesicherten Zugang zu einer Probe und spezifiziert eine Standardmethode für eine serielle Schnittstelle einer Probe, wenn Out-of-Band-Management benutzt werden soll.

« Teil 63: Netzwerk-Management StandardsTeil 65: SNMP Versionen 2 und 3 »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.