... [ Informatik und Master-Seminar SS2004] ... [ Inhaltsverzeichnis ] ... [ zurück ] ... [ weiter ]
Der Ausbau von Telekommunikationsnetzen in den 80er Jahren führte sehr schnell zu einer großen Problematik. Hersteller von Telekommunikationsprodukten hatten alle eigene individuelle, proprietäre Management-Schnittstellen, die nur über das Hersteller Operation Support System angesprochen werden konnten. Die Konsequenz war, dass sich das Telekommunikationsunternehmen entweder für ein heterogenes Netzwerk (multi-suplier) entscheiden musste, wobei jeder Mitarbeiter die entsprechenden Schnittstellen erlernen musste, oder für die Alternative, alle Produkte von einem Hersteller zu verwenden. Somit war die Anpassung an jedes Netzwerkmanagement mühselig und zeitintensiv. Um diesen Umstand zu verbessern, versuchte die ITU-T entsprechende Standard Schnittstellen für Management Systeme zu kreieren und fasste die Konzepte und Spezifikationen in der Netzwerk Management Architektur Recommendation X.700 und X.701 zusammen. Dabei wurde das primäre Ziel eines Telekommunikationsmanagementsystems als die Kontrolle, Koordination und Überwachung eines Verteilten Systems formuliert. Dabei orientierte man sich an der OSI-Managementarchitektur und erweiterte diese um Belange des Telekommunikationsmanagements. TMN-Systeme folgen somit einer Standardisierung des Managements und bilden eine Architektur, die sowohl dem Netzbetreiber als auch dem Dienstanbieter ein flexibles Ressourcenmanagement ermöglicht.
Das Grundprinzip eines TMN-Systems ist ein physisch getrenntes Netz, um die Netzwerkelemente und Dienste über ein herstellerneutrales Protokoll zu administrieren. Durch die physische Trennung soll eine Unabhängigkeit gegenüber der Netzlast bestehen und damit die bestehenden Ressourcen schonen sowie eine schnelle Abfrage der Elemente garantieren. Die funktionalen Bereiche eines TMN-Systems gliedern sich in :
Beim Fehlermanagement geht es um das Entdecken, Analysieren und Korrigieren von anormalen Vorgängen. Unter Konfigurationsmanagement versteht man das Kontrollieren und Aufzeichnen des Status von konfigurierbaren Elementen. Abrechnungsmanagement umfasst das Gebühren- und Kostenmanagement. Das Leistungsmanagement kontrolliert die Performance des Netzwerkes in Bezug auf Durchsatzraten und Antwortgeschwindigkeiten. Der fünfte Bereich steht für die Kontrolle und Verwaltung der Netzzugangskontrolle.
Die TMN-Technologien sind Implementierungen des Object Modelled Network Managements (OMNM). Die Idee von OMNM ist es jede managebare Ressource als ein Management Objekt (MO) zu repräsentieren, das alle relevanten Daten und Verhalten zusammenfasst. MOs enthalten alle Daten, die für die Management Kommunikation relevant sind. Ein Objekt beschreibt ein abstraktes Gebilde, auf dem eine Komponente im Datennetz dargestellt wird. Dieses abstrakte Gebilde kann über eine Vielzahl an Attributen (Parametern) verfügen. Eine Managementfunktion ist somit immer eine Folge parametrisierter Operationen auf einem Objekt. Eine managebare Einheit erscheint dem Management System als eine Kollektion an MOs und das Management System speichert die Referenz auf die zu managenden Ressource in Bezug auf die MOs. Diese Kollektion wird auch als Management Information Base (MIB) bezeichnet, die einem objektorientierten Aufbau mit Benutzung von Einkapselung, Klassenhierarchie und Vererbung folgt. Die MIB stellt MOs in Form eines Managementinformationsbaums (MIT) dar. Ein MO enthält folgende Einträge :
MOs genügen den Konzepten Einkapselung, Vererbung und Polymorphie. Die ISO hat ein MO unter dem Namen root definiert, von der alle MO-Klassendefinitionen abzuleiten sind. MOs mit Gemeinsamkeiten werden zu einer MO-Klasse zusammengefasst.
Beispiele für MOs :
Die meisten Managementtechnologien basieren heute auf dem OMNM-Ansatz und teilen sich eine Vielzahl von Standardmethoden wie
In den heutigen Implementierungen wird eine Manager-Agenten-Technik verwendet. Ein Agent stellt die Kommunikation mit den Netzwerkelementen her. Er arbeitet also direkt auf dem Netzwerkknoten und verwaltet eine Anzahl von Netzwerkelementen. Dabei nimmt er Anfragen von einem Manager entgegen, der einmalig oder zyklisch die Agenten kontaktiert und die Informationen verwertet bzw. weiterleitet. Während Agenten häufig als Daemonen realisiert sind, müssen Manager flexibel und modular aufgebaut sein, um eine Kommunikation mit allen Agenten in einem Netz zu ermöglichen.
Als Voraussetzung für eine Manager-Agenten-Kommunikation ist ein gemeinsames Wissen über die Management Information Base (MIB) erforderlich. Dieses Wissen ist als Shared Management Knowledge (SMK) auf beiden Seiten vorhanden. Dadurch ist es sogar möglich, dass Manager und Agenten ihre Rollen tauschen. Zum Austausch von Informationen wird das Common Management Information Protokoll (CMIP) verwendet.
Abbildung 11: Manager-Agent-Beziehung
Jeder Netzwerkknoten wird von einem Agenten-Prozess überwacht. Dabei beantwortet der Agent Anfragen des Managers. Dazu sendet der Manager ihm zunächst einen Request mit einer Informationsanforderung und der Agent prüft dann, ob der Manager überhaupt berechtigt ist, von ihm eine Antwort zu erhalten. Wenn dies der Fall ist, wird die Information von dem Node ausgelesen und an den Manager als Response zurückgesendet. Der Manager hat also keinen direkten Zugriff auf die Ressourcen. Eine Realisierung dieses OMNM-basierten Netzwerkmanagementsystems findet sich z.B. in dem Simple Network Management Protocol (SNMP) wieder.
Bei SNMP handelt es sich um ein Protokoll, welches die Kommunikation zwischen Manager und Agenten spezifiziert und damit eine verteilte Managementarchitektur definiert. Das Protokoll ist ein Client-Server-Modell, wobei die Agenten auf den Netzwerkkomponenten als Server laufen und der Manager als Client die Anfragen stellt. SNMP enthält ein standardisiertes Modell für die Daten und den Zugriff darauf, unabhängig welches System im Hintergrund läuft. Dabei bestimmt die Architektur, welche Daten ein Gerät unter welchen Namen vorhalten muss und mit welcher Syntax die Werte und Zustände beschrieben sind. Die Kommunikation läuft bei SNMP über das verbindungs- und quittungslose User Datagramm Protocol (UDP) und erfolgt dabei defaultmäßig auf Port 161. Neben der eigentlichen Abfrage der Agenten durch die Manager (Polling) können die Agenten auch selbstständig im Zuge von Trap-Funktionen dem Manager unaufgefordert Informationen über besondere Vorkommnisse zusenden. SNMP definiert vier Funktionen zur Abfrage von Netzwerkelementen :
Die Get-Funktion liest aus einer Instanz eines gemanagten Objektes einen Variablenwert aus. Mit Get-Next wird analog der nächste Wert ausgelesen. Die Set-Funktion ermöglicht es, Variablenwerte zu setzen und damit einen Schreibzugriff auszuführen. Die vierte Funktion wird als Trap-Funktion bezeichnet und wird genutzt, um einem Managementprozess unaufgefordert mitzuteilen, dass ein speziell definierter Fall eingetreten ist. Diese vier Befehle reichen bereits aus, um eine Managementarchitektur mit minimalistischem Ansatz zu realisieren und sind als eine Folge parametrisierter Operationen auf einem Objekt zu verstehen. Die Daten wie Routingtabellen, Temperaturwerte oder Auslastung werden in einer Management Information Base zusammen mit ihrer Bedeutung, den erlaubten Operationen und dem Wertebereich verwaltet und als Management Information Tree dargestellt. MIBs werden bei SNMP mit Hilfe einer abstrakten Syntax Notation (ASN.1) definiert. In dem Baum werden alle Objekte hierarchisch angeordnet und über einen Object Identifier (OID) referenziert. Die Wurzeln, in dem die verschiedensten Objekte global eindeutig referenziert sind, werden von der ISO sowie der ITU verwaltet. Unterbäume können separat delegiert werden und es ist möglich, eigene Unterbäume zu definieren und so z.B. eigene MITs einzuhängen. Der Aufbau ähnelt dem Domain Name System (DNS), jedoch mit dem Unterschied, dass es keine automatisierte Abfrage gibt.
Abbildung 12: Management Information Tree
Die Wurzel des Baumes ist root, von dort folgen die Organisationen ISO und CCIT (heute ITU). Jeder Knoten lässt sich über den Namen oder über die binäre Darstellung ansprechen. Der Knoten private, in dem eigene Objekte angehängt werden können, ließe sich also entweder über {root iso(3) org(3) dod(6) internet(1) private(4)} respektive /iso/org/dod/internet/private/ oder 1.1.3.6.1.4 ansprechen. Unter private befindet sich weiter ein Knoten enterprises, in den Hersteller ihre MIBs einhängen können.
Abbildung 13: individuelle Einträge in dem Knoten „enterprises“
Ein managebares Objekt besteht aus fünf Feldern :
Um nun z.B. ein System zu beschreiben, lässt sich das Objekt sysDescr in /iso/org/dod/internet/mgmt/mib-2/system/ verwenden, welches folgendem Aufbau folgt :
cat mib.txt | grep sysDescr
sysDescr OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the entity. This value should
include the full name and version identification of the
system's hardware type, software operating-system, and
networking software."
::= { system 1 }
Mit dem Wissen lassen sich dann entsprechende Abfragen durchführen :
Neben der Versionsangabe (-v 2c) und der Zieladresse wird hier dem Agenten, der in diesem Beispiel als Daemon auf einem Linuxsystem läuft, ein Community-String (-c public) übergeben. Dieser dient der Authentifizierung des Managers gegenüber dem Agenten, der diesen mit seiner Konfiguration vergleicht. Der Community-String vereint hier Benutzernamen und Passwort in einem einzelnen String. Aufgrund der unverschlüsselten Übertragung ist diese Authentifizierung jedoch nicht als sicher einzustufen. Natürlich lässt sich die Abfrage auch im Binärformat stellen :snmpget -v 2c -c public 192.168.2.7 system.sysDescr.0SNMPv2-MIB::sysDescr.0 = STRING: Linux networkserver 2.4.22-xfs #1 SMP Fr Okt 3 20:36:25 CEST 2003 i586
Um diese Werte zu ändern, benutzt man analog zu snmpget snmpset mit der zusätzlichen Angabe des Attributtyps (OCTET STRING) und dessen Wert.snmpget -v 2c -c public 192.168.2.7 .1.3.6.1.2.1.1.1.0SNMPv2-MIB::sysDescr.0 = STRING: Linux networkserver 2.4.22-xfs #1 SMP Fr Okt 3 20:36:25 CEST 2003 i586
snmpset -v 2c -c public 192.168.2.7 system.sysContact.0 s "Max Mustermann, Deutschland"
Um sich den kompletten Baum des Zielsystems anzusehen, wird der
Befehl snmpwalk verwendet.
snmpwalk -v 2c 192.168.2.7 -c public
Um sich einen Überblick über den Paketverkehr und die
offenen Sockets zu machen, bietet sich der Befehl snmpnetstat an.
Anzeige aller aktiven Sockets :
snmpnetstat -v 2c -c public -a 192.168.2.7
SNMP lässt sich zur Verwaltung sämtlicher Netzwerkelemente
nutzen. In der folgenden Abbildung kommt es in der
Vermittlungsstation zu einer Störung bei der Vermittlung von
Anrufsanforderungen.
Abbildung 15: Abfrage eines Netzelementes
Um den Fehler zu analysieren, kann nun der Manager den Agenten nach dem aktuellen Loginhalt fragen. Dieser referenziert das entsprechende Objekt in der MIB und liest den String-Wert aus und liefert ihn an den Manager zurück. Dieser kann nun neue Routen setzen oder weitere Abfragen stellen.
... [ Informatik und Master-Seminar SS2004] ... [ Inhaltsverzeichnis ] ... [ zurück ] ... [ weiter ] ... [ oben ]