und -netzen Monitoring Software-Monitore im Detail Klassifikation von Netzmonitoren

Größe: px
Ab Seite anzeigen:

Download "und -netzen Monitoring Software-Monitore im Detail Klassifikation von Netzmonitoren"

Transkript

1 Performance von Kommunikationssystemen und -netzen 8. Messung der Performance Monitoring Kommunikationsnetz Sensor Transformator Ausgabe Monitor Analysator Weiterverarbeitendes System Performance Klassifikation von Netzmonitoren Software-Monitore im Detail Hardware-Monitore Eigenes Gerät Ohne Verfälschung der Messergebnisse Software-Monitore Programm auf einem (zu vermessenden) System Zusätzliche Last durch Monitoring i Hybrid-Monitore Separates Gerät Durch Software flexibel anpassbar Zwei Klassen Zeitgesteuerte Software-Monitore (sample-driven) Ereignisgesteuerte Software-Monitore (event-driven) Protokollstacks müssen mit Monitoranweisungen versehen werden Mitprotokollieren von Ereignissen Zeitstempel Performance Performance

2 Leistungsüberwachung eine Disziplin des Netzmanagements Instanzen im Netzmanagement FCAPS Failure Management Fehlermanagement Configuration Management Konfigurationsmanagement Accounting Management Abrechnungsmanagement Performance f Management Leistungsmanagement t Security Management Sicherheitsmanagement Bereiche sind nicht strikt voneinander getrennt Einzelne Funktionen können mehreren Bereichen zugeordnet werden Funktionen eines Bereichs sind Grundlage für die Funktionen eines anderen Bereichs Manager Rückmeldung der Ergebnisse; Meldung von Ausnahmesituationen Lesender/schreibender d Zugriff auf Managementinformation; Ausführung von Managementoperationen Agent Performance Performance Das Simple Network Management Protocol SNMP (hier: Version 1) Manager Agent SNMP UDP IP Managementkommunikation GetRequest Get-NextRequest SetRequest GetResponse Trap Netzinfrastruktur (beispielsweise Ethernet) SNMP UDP IP Prinzip: Trap-Directed Polling Informa ation Ein SNMP-Manager fragt in regelmäßigen Abständen die SNMP-Agenten ab ( Polling ) Agenten können einem Manager durch Meldungen ( Traps ) Ausnahmesituationen signalisieren Der SNMP-Manager kann dann die Abfragestrategie entsprechend anpassen Streng zentralisiertes Modell, in dem der Manager die ganze Funktionalität und Verantwortung trägt Manager Agent Agent Agent Agent MIB MIB MIB MIB Steue erung Performance MIB = Management Information Base Performance

3 Structure of Management Information Die Structure of Management Information SMI beinhaltet Regeln zur Definition von Objekten, die Gegenstand des Netzwerkmanagements t sein sollten: Einfache typisierte Variablen Nur objektbasierter, kein objektorientierter Ansatz Basierend auf der Abstract Syntax Notation 1 (ASN.1) Keine komplexe Datenstrukturen maximal zweidimensionale Tabellen Keine durch Managed Objects direkt angebotene Operationen, nur Lesen / Ändern von Managed Objects erlaubt Wichtig: Diese Regeln dürfen nicht von vorgegebenen Managementprotokollen abhängen Performance Objektmodell Structure of Management Information Instanz Internet Managed Object Syntax Access Status Name Eindeutige Identifikation Performance Object Type Macro (SMIv2) Motivation Entferntes Überwachen OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type(syntax) UnitsPart t "MAX-ACCESS" Access "STATUS" Status "DESCRIPTION" Text ReferPart IndexPart DefValPart VALUE NOTATION ::= value(value ObjectName) UnitsPart ::= "UNITS" Text empty Access ::= "not-accessible" "read-only" "read-write" "read-create" Status ::= "current" "deprecated" "obsolete" o oe e END ReferPart ::= "REFERENCE" Text empty IndexPart ::= "INDEX" "{" IndexTypes "}" "AUGMENTS" "{" Entry "}" empty IndexTypes ::= IndexType IndexTypes "," IndexType IndexType ::= "IMPLIED" Index Index Index ::= value(indexobject ObjectName) Entry ::= value(entryobject ObjectName) DefValPart ::= "DEFVAL" "{" value(defval l Syntax) "}" empty -- uses the NVT ASCII character set Text ::= """" string """" END Grundlegendes Ziel: Gewährleistung des optimalen Betriebs eines Netzwerks durch ständige (entfernte) Überwachung So genannte "Business Objectives": Verfügbarkeit & Konnektivität Netzwerk- und Systemausfälle/-fehler fehler freier Zugang eingeschränkter Zugang Leistungsfähigkeit Antwortzeit & Bandbreite Engpässe ("Bottlenecks"), Fehlkonfigurationen, Auslastung,... Anpassungsfähigkeit steigende Anzahl an Benutzern und Netzkomponenten ständige Konfigurationsänderungen Inventarisierung & Abrechnung einheitliches Überwachungskonzept? Performance Performance

4 Remote Network Monitoring (RMON) 1990 Beginn der RMON-Entwicklung in der IETF 1991 RMON1, 1997 RMON2 RMON1 "echter" Internet-Standard mit RFC 2819 (Mai 2000) Grundidee: Sog. Sonden (Engl.: "probe") analysieren den im Netzwerk auftretenden Verkehr, nehmen eine Filterung vor und speichern Informationen zur späteren Auswertung". Jede Sonde besitzt ein/mehrere Netzwerkschnittstellen Paketaufzeichnung im "promiscuous mode" Einsatz von SNMP: Konfiguration + Management der Sonde Aufsetzen von Überwachungsaufträgen Auslesen der gespeicherten Daten + Statistiken Ziele von RMON eigenständige Arbeitsweise der Sonden kein ständiger Kontakt zu Managementstation(en) notwendig Ausfall der Konnektivität zeitweise tolerierbar proaktive Überwachung selbständige, kontinuierliche Überwachung der Leistungsfähigkeit von Geräten/Netzen mittels RMON-Sonden Versenden von Benachrichtigungen Erstellen einer "History" Erkennung von Fehler-/Ausnahmesituationen Definition/Konfiguration von Fehlerzuständen durch Benutzer, Benachrichtigung der Managementstationen Erzielen eines Mehrwerts (value-addedadded data) Filter-/Auswertungsfunktionen Unterstützung mehrerer Manager Performance Performance RMON-Sonden (I) SNMP Managed stand-alone probe dedizierte Hardware-Komponente ausreichend Speicher und Rechenleistung notwendig embedded probe als Software in Gerät integriert evtl. Einfluss auf Leistung der überwachten Komponente hosted Probe: selbst. Hardware-Modul distributed probe Agent SNMP Agent Managed Objects Router Softwarelösung Funktionalität auf verschiedene Komponenten verteilt proprietäres Protokoll zum Einsammeln der Informationen von den überwachten (verteilten) Komponenten Sonde Sonde Managed Objects Performance RMON-Sonden (II) RMON in "geswitchten" Umgebungen: Copy/Diagnostic-Port eines Switches, an dem der gesamte Verkehr mit ausgegeben wird Problem: Ausgabe/Verarbeitung aller Pakete bei hohem Datenaufkommen oftmals zu aufwendig nur fehlerfreie Pakte an Copy-Port weitergeben nicht alle Ports an Copy-Port weiterleiten Analyse nur eines Teils der Pakete (statistical sampling) steerable probe: kann den gesamten Verkehr eines/mehrerer Ports überwachen Überwachung aller Ports mittels RMON1+RMON2 oft zu aufwendig! Sonde Copy Port Server PC PC Switch Performance

5 Grundlegende Überlegungen zur entfernten Überwachung Grundlage: SNMP Manager muss RMON-Agenten beauftragen Agent soll im Auftrag mehrerer Agenten arbeiten können Ablage von Aufrufparametern und Ergebnissen Geeignete Datenstruktur: Tabelle Manager muss beim Agenten neue Zeilen erzeugen können! Spalte Status Status (analog zum RowStatus) Zeile existiert nicht create Request under Creation valid Erstellen von Überwachungsaufträgen Eine Netzüberwachung kann erst dann stattfinden, wenn entsprechende Aufträge in der Sonde konfiguriert sind. a) Kombinierte i Kontroll-/Datentabelle t t gemeinsame Tabelle für Konfigurationsparameter und Ergebnisse b) Getrennte Kontroll-/Datentabelle getrennte Tabellen für Konfiguration und Daten-/Ergebnisspeicherung Index der Kontrolltabelle muss Teil des Index der Datentabelle sein, um Ergebnisse zuordnen zu können Einträge in Datentabelle werden bei Anhalten/Modifikation des Überwachungsauftrages gelöscht Index Control Control Data Data Aktion des Managers Aktion des Agenten invalid Wert kann nur gesetzt werden Wert kann gelesen und gesetzt werden Datentabelle Kontrolltabelle Performance Performance Auftragserteilung Sonden von mehreren Managementstationen nutzbar a) Aufträge aller Managementstationen sind identisch gleichzeitiges iti Auslesen der Ergebnisse unproblematisch b) individueller Auftrag von jeder Managementstation beschränkte Ressourcen der Sonde können zu Konflikten führen: z.b. neue Aufträge nicht möglich, Konkurrenz um Ressourcen, fehlende Freigaben etc. jeder Überwachungsauftrag enthält Identifikator des Auftraggebers sog. "Ownerstring" (in Kontrolltabelle) Aufträge können erkannt und ggf. gelöscht bzw. mit anderen Auftraggebern abgestimmt werden Problem: keine "harten" Kriterien, Kooperation notwendig! Performance RMON-MIB i. W. 19 verschiedene Gruppen von Managementobjekten Definitionen der Objektgruppen über verschiedene Module verteilt iso(1) RMON1-Gruppen org(3) dod(6) RMON2-Gruppen statistics(1) internet(1) t(1) protocoldir(11) history(2) mgmt(2) protocoldist(12) alarm(3) mib(1) addressmap(13) host(4) rmon(16) nlhost(14) hosttopn(5) nlmatrix(15) matrix(6) alhost(16) filter(7) almatrix(17) capture(8) userhistory(18) event(9) probeconfig(19) Schicht 2 Schicht 3 Performance

6 RMON1 Statistics-Gruppe Statistiken über Verkehrs-/Fehlerrate auf MAC-Ebene in Echtzeit standardisiert di i derzeit für Ethernet und Token Ring Berücksichtigung anderer Netztechnologien durch proprietäre MIBs, Abbildung auf Ethernet/Token-Ring-Tabellen oder neue, medienunabhängige i Tabellen realisiert durch kombinierte Kontroll/Datentabelle Überwachungsauftrag für lokale Netzwerkschnittstelle z.b. #Bytes (...StatsOctets), #Pakete (...StatsPkts), #Broadcasts (...StatsBroadcastPkts), #Multicasts (...Stats-MulticastPkts), #Kollisionen (...StatsCollisions) Beispiel:...Index...Source...Octets...Pkts...Coll Owner Status 1 IfIndex Telematik, Phone Valid 2 IfIndex Telematik, Phone valid Performance RMON1 History-Gruppe Aufzeichnung der Daten der Statistics-Gruppe über gegebenes Zeitintervall i Speicherung von "Delta"-Werten " t (wert t+1 -wert t ) Konfiguration: Messintervall (...ControlInterval), max. Anzahl zu speichernder Werte (...BucketsRequested) Ringpuffer mit Werten von max Messintervallen Konflikt mit vorhandenen Ressourcen der Sonde möglich realisiert durch getrennte Kontroll-/Datentabelle...Index...Source BucketsReq...Interval Owner Status 3 IfIndex Tele valid...index...sampleind IntervalStart Octets Pkts Coll 3 1 1d 1h 0m 0s d 1h 1m 0s Performance RMON1 weitere Gruppen (I) alarm(3) + event(9): Überwachung beliebiger Integer-Objekte Erzeugen von Events (interne Ereignisse) bei Überschreiten eines unteren/oberen Grenzwertes Aufzeichnen der Events oder Versenden von SNMP-Traps möglich Bsp: Überwachung des Objektes "ifinerrors" der MIB II host(4): Alarmierung einer Managementstation mittels SNMP-Trap, sobald ein Grenzwert von 1000 Fehlern pro Sekunde überschritten wird Analyse des Verkehrsaufkommens auf Schicht 2 für eine/mehrere e/ e e e Netzwerkschnittstellen e e e automatische Erkennung der beteiligten Hosts Erstellen von Paketstatistiken, sortiert nach MAC-Adressen z.b. ein-/ausgehende Bytes/Pakete, Fehler,... RMON1 weitere Gruppen (II) hosttopn(5): Einschränkung der Host-Gruppe auf vorgegebene Anzahl an Hosts Datentabelle enthält nur die N Spitzenpositionen eines Überwachungsauftrages (N konfigurierbar durch Manager) Startzeitpunkt + Dauer der Überwachung frei wählbar (in Sek.) z.b.: "bestimme die drei Rechner, die von 14:00-14:10 Uhr die größte Netzwerklast erzeugen" z.b.: "bestimme den Rechner, der von 11:15-11:16 Uhr die meisten fehlerhaften Pakete im Netz erzeugt hat" matrix(6): Erstellen von Paketstatistiken für je zwei Kommunikationspartner ausgetauschte Bytes/Pakete, fehlerhafte Pakete Speicherung erfolgt in zwei separaten Tabellen Sortierung Quelle/Ziele oder Ziel/Quelle z.b. "bestimme Datenverkehr von Rechner A nach Rechner B" Performance Performance

7 RMON1 weitere Gruppen (II) filter(7): Definition von Daten- und Statusfiltern: Erkennung von Bitmustern im Paket/Kopf & Fehlerzuständen Test auf Vorhandensein/Nicht-Vorhandensein möglich Position (Offset), ab welcher Überprüfung erfolgen soll nicht zu berücksichtigende ("don't care") Bits Kanal (Channel): Paketstrom, t der ein/mehrere Filter durchläuft Strategien: acceptmatched(1) / acceptfailed(2) Auslösen von Events möglich capture (8): Aufzeichnung von Paketen eines Kanals aufzuzeichnender Paketteil (Länge, Offset, etc.) Göß Größe des Datenteils t kann beim Auslesen angepasst werden kann hohe Speicherbelastung verursachen! RMON2 Gruppen (I) protocoldirectory(11): beschreibt die einer Sonde bekannten Protokolle Beschreibung durch sog. "Encapsulations", z.b. TCP über IP über Ethernet, UDP über IP über MAC,... protocoldistribution(12): Statistiken für ausgewählte Protokolle/Encapsulations einer Netzwerkschnittstelle (#Bytes, #Pakete) unterschiedl. Datentabellen für herkömmliche ( 20 Mbit/s) und Hochgeschwindigkeitsnetze ( 1 Gbit/s) addressmapping(13): Zuordnung MAC-AdresseNetzwerkadresse anhand Überwachung des Netzwerkverkehrs networklayerhost(14): Analyse des Verkehrsaufkommen auf Schicht 3 nach Netzwerkadressen z.b. ein-/ausgehende e Pakete/Bytes, Broadcast/Unicast etc. vgl. Gruppe "host" von RMON1 Performance Performance RMON2 Gruppen (II) networklayerhost(14) Beispiel: hlhostcontroltable: Aufsetzen eines/mehrerer Überwachungsaufträge NlInserts: Anzahl eingefügter Zeilen (Hosts) NlDeletes: Anzahl gelöschter Zeilen (Hosts) DataSource: Netzwerkschnittstelle nlhosttable: Messwerte (Timefilter-Mechanismus) HostControlTable ControlIndex DataSource NlInserts NlDeletes...Owner Status 1 IfIndex Telematik active 2 IfIndex Telematik active nlhosttable ControlIndex TimeMark Address inpkts OutOctets Zeitstempel Performance RMON2 Gruppen (III) networklayermatrix(15): Statistiken über paarw. Kommunikationsbeziehungen (Schicht 3) Sortierung Quelle-Ziel/Ziel-Quelle möglich vgl. Gruppen "matrix"/"topn" von RMON1 applicationlayerhost(16): Statistiken über Protokolle auf Schicht 4 Analyse nach Sender/Empfänger auf Schicht ht 3 z.b. ein-/ausgehende Pakete/Bytes applicationlayermatrix(17): Statistiken über paarw. Kommunikationsbeziehungen (Schicht 4) vgl. Gruppen "matrix"/"topn" von RMON1 userhistory(18): periodische Überwachung/Speicherung beliebiger Objekte probeconfiguration(19): Konfiguration der Sonde (z.b. serielle Schnittstellen, IP-Adressen/Schnittstellen, serielle Verbindungen mittels SLIP, Traps) Performance

8 RMON2 TimeFilter (I) Ziel: Reduktion der SNMP-Nachrichten beim periodischen Auslesen von (Daten-)Tabellen Eine Messung in einer Datentabelle bestehe aus N Zeilen dynamische Anpassung der Größe unterschiedliche Größe der Tabelle zu verschiedenen Zeitpunkten vollständiges Auslesen erzeugt hohes Datenaufkommen nur Lesen der Änderungen beabsichtigt Einsparung an SNMP-Nachrichten: minimal: 0%, maximal: 100 x (Zeilen*Spalten)/(Zeilen*Spalten)+1 % Datenm menge Vollständiges Lesen Lesen der Änderungen Index Value 1 Value 2 Value N Index 1 87 Value 1 10 Value 2 Value 1200 N Zeitpunkt t t t Datenm menge Performance RMON2 TimeFilter (II) Realisierung des TimeFilters durch Erweiterung der Datentabelle: jede Zeile trägt "unsichtbaren" internen Zeitstempel enthält sysuptime zum Zeitpunkt der letzten Änderung zusätzlicher Index "TimeMark" dient als zusätzlicher Parameter für SNMP-Anfragen Datentyp TimeFilter abgeleitet von TimeTicks (Zeit in 1/100s) Zugriff "not-accessible" Datentabelle des Agenten enthält je Messung die Zeilen mit TimeFilter-Index 0 bis T (T=Wert der Zeitstempels) Bsp.: Messung mit Index=1 [nach 10s]: 1000 Zeilen (0, 1, 2,...) Praxis: Agent belegt Ressourcen nur für einzelne Zeile pro Messung TimeMark Index Value 1 Value 2 Value N Zeitstempel Performance RMON2 TimeFilter (III) Ablauf bei Get/GetNext/GetBulk: Agent extrahiert Wert des Timefilters aus Anfrage [Zeitstempel (Zeile) < TimeFilter (Anfrage)] Zeile nicht existent damit werden nur Tabellenzeilen zurückgeliefert, deren Zeitstempel aktueller ist als der TimeFilter der Anfrage! der "unsichtbare" Zeitstempel selbst wird nicht zurückgeliefert! Änderungen vollständig gelesen Timefilter+1 oder Tabellenende Beispiel GetNextReq (...Value1.6000, Null) GetRsp (Table...Value , 5) GetNextReq (...Value1.4550, Null) GetRsp (Table...Value , 66) GetNextReq (...Value , Null) GetRsp (Table...Value , 5) GetNextReq (...Value , Null) GetRsp (Table...Value , 66) TimeMark Index Value 1 Value 2 Value N Zeitstempel Performance RMON2 TimeFilter (IV) Um alle Änderungen in der Datentabelle zu erfassen, muss der Manager folgende Punkte beachten: vor jedem Lesezyklus (=Folge von GetNext-Anfragen) sysuptime des Agenten abfragen/speichern Agent kann maximal Änderungen bis zu diesem Zeitpunkt berücksichtigen beim ersten Lesezyklus TimeFilter=0 nächster äh Lesezyklus: timefiltern+1 = sysuptimen (n=nr. Lesezyklus) Beispiel: TimeMark Index Value 1 Zeitstempel sysuptime=1300 Lesezyklus 1: GetNextReq (...sysuptime.0, Null) GetRsp (...sysuptime.0, 1300) GetNextReq (...Value1.0, Null) GetRsp (...Value1.0.1, 825) GetNextReq (...Value1.0.1, Null) GetRsp (...Value1.0.1, Null, endofmibview) Performance

9 RMON2 TimeFilter (V) TimeMark Index Value 1 Zeitstempel sysuptime=2500 Leszyklus 2: GetNextReq (...sysuptime.0, Null) GetRsp (...sysuptime.0, 2500) GetNextReq (...Value1.1300, 1300 Null) GetRsp (...Value , ) GetNextReq (...Value , Null) GetRsp (...Value , 23) GetNextReq (...Value , Null) GetRsp (...Value , 566) Weitere RMON-Gruppen TOKEN-RING-MIB Erweiterungen der Statistics-Gruppe um Token-Ring- spezifische Objekte SMON-MIB (RFC 2613) Erweiterungen der Statistics-Gruppe für geswitchte Netzwerke TimeMark Index Value 1 Zeitstempel sysuptime=3000 Leszyklus 3: GetNextReq (...sysuptime.0, Null) GetRsp (...sysuptime.0, 3000) GetNextReq (...Value1.2500, Null) GetRsp (...Value , 235) GetNextReq (...Value , Null) GetRsp (...Value , 235) Performance HC-RMON-MIB Erweiterungen der Statistics-Gruppe für Hochleistungsnetze (Zählergrößen) Medienunabhängige Statistik-Gruppe Performance Literatur "RMON Remote Monitoring of SNMP-Managed LANs", D. Perkins, 1999, Prentice Hall, Upper Saddle River, NJ 07458, ISBN "Remote Network Monitoring Management Information Base", RFC 2819, S. Waldbusser, Mai 2000 "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, S. Waldbusser. Januar 1997 "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser, Juni 1999 Performance