Evaluierung des Systemmanagement in IT basierten TV

Transcrição

Tobias Lausberg: Evaluierung des Systemmanagement in IT basierten TV Produktionsumgebungen unter
Anwendung des SNMP
Fachhochschule Wiesbaden
University of Applied Sciences
„Evaluierung des Systemmanagement in IT basierten TV
Produktionsumgebungen unter Anwendung des Simple
Network Management Protocol“
vorgelegt von: Tobias Lausberg
am : 10.Dezember 2004
Referent : Prof. Dr.-Ing. Martin Plantholt (FH Wiesbaden)
Korreferent : Dipl.-Ing (FH) Friedrich Gierlinger (IRT München)
Fachbereich 03
Elektrotechnik
Studiengang
Fernsehtechnik und
elektronische Medien
I
Anwendung des SNMP
Ich versichere hiermit, diese Diplomarbeit selbständig angefertigt zu haben sowie, dass alle verwendeten Quellen und Hilfsmittel in der Arbeit angegeben sind.
Der Einsicht in diese Diplomarbeit und der Ausleihe eines Exemplares
stimme ich zu / stimme ich nicht zu*.
—————————————————
( Ort / Datum )
———————————————————————
( Unterschrift Studentin / Student )
Nur von der Betreuerin / von dem Betreuer auszufüllen :
Gegen die Einsicht in diese Diplomarbeit und gegen die Ausleihe eines Exemplars
wird / kein* Einspruch erhoben.
——————————————————————————
( Unterschrift Betreuerin / Betreuer )
Begründung ( bei Einspruch ) :
———————————————————————————————————————————
———————————————————————————————————————————
———————————————————————————————————————————
———————————————————————————————————————————
* : Nichtzutreffendes bitte streichen.
II
Anwendung des SNMP
Abstract:
The IT is coming to the broadcast with all its power. A new infrastructure for the
TV broadcast technology will be the result. To keep the new technology running a
maximum of control and monitoring must be achieved. Finding ways to guaranty
the reliability and functionality of the IT technology is essential.
The Simple Network Management Protocol (SNMP) is an interface of the IT to
control and monitor IT Networks. This thesis is about the possibilities of using this
SNMP for control and monitoring tasks in a TV broadcast environment. In the
beginning there will be a discussion about the protocol and its possibilities by the
RFC standards. In the following part some requirements of a control and monitoring
system in the IT-based broadcast are collected.
Based on this knowledge a test environment is built in which some control and
monitoring applications are evaluated. These applications are products from typical
IT and broadcast companies. The evaluation will show the differences between the
capabilities of the broadcast and the IT solutions for control and monitoring in the
IT based broadcast environment.
By analysing the functionality of the former mentioned application some points will
be presented to improve the functionality of the control and monitoring based on
SNMP.
Kurzfassung:
Die IT findet immer grössere Verwendung im Bereich der profesionellen
Broadcastumgebung. Resultat dieser Entwicklung ist eine Veränderung der
technische Infrastruktur der TV Produktionsumgebung. Die Überwachung und
Kontrolle dieser Infrastruktur ist ein wesentlicher Aspekt. Es müssen Wege
gefunden werden, diese veränderte Infrastruktur zuverlässig zu betreiben.
Das Simple Network Management Protocol (SNMP) ist eine Schnittstelle der IT, um
IT Netzwerke zu überwachen und zu kontrollieren. Diese Arbeit beschäftigt sich mit
den Möglichkeiten, SNMP für die Überwachung und Kontrolle der IT basierten TV
Produktionsumgebung zu nutzen.
Zu Beginn werden der SNMP Standard und die Möglichkeiten aus dieser
Standardisierung dargestellt. Des Weiteren werden einige Anforderungen an ein
Überwachungs- und Kontrollsystem in der IT basierten TV Produktionsumgebung
genannt.
Ausgehend von diesen Betrachtungen werden Control und Monitoring
Anwendungen basierend auf SNMP beurteilt. Diese Beurteilung ermöglicht einen
Vergleich zwischen den Lösungen der IT Hersteller und denen der Broadcast
Hersteller.
Durch diese Beurteilung werden einige Punkte erkennbar, die eine Verbesserung der
Kontrolle und Überwachung mittels SNMP in der IT basierten
Produktionsumgebung ermöglichen.
i
Anwendung des SNMP
Danksagung:
Danken möchte ich Herrn Gierlinger und Herrn Hubbes für die engagierte
Betreuung dieser Arbeit. Ebenso gebührt mein Dank den Mitarbeitern der Abteilung
Produktionssysteme Fernsehen des Institutes für Rundfunktechnik in München.
Meinen Mitbewohnern und Freunden möchte ich danken für die Unterstützung und
Aufmunterung während dieser Arbeit.
Herrn Prof.Dr.-Ing. Plantholt danke ich für die Unterstützung im Vorfeld dieser
Arbeit.
Besonderen Dank gebührt Jochen Renner für die sicherlich mühevollen Stunden des
Korrekturlesens.
Zu guter Letzt möchte ich meinen Eltern und meiner Familie danken, die mir das
Studium und damit auch diese Diplomarbeit erst ermöglicht haben.
ii
Anwendung des SNMP
Inhaltsverzeichnis:
Kurzfassung..................................................................................................................i
Abbildungsverzeichnis ................................................................................................v
Tabellenverzeichnis...................................................................................................vii
Akronyme..................................................................................................................vii
1. Einleitung und Aufgabenstellung ........................................................................1
2. Grundlagen des SNMP Management..................................................................3
2.1. Das Managementkonzept mittels SNMP .............................................................3
2.2. Unterlagerte Dienste – Der Transport von SNMP ...............................................6
2.3. Die Management Information Base-MIB ............................................................7
2.4. Der Aufbau der Managementinformationen ........................................................9
2.5. Die standardisierten Versionen des SNMP ........................................................10
2.5.1. Die SNMP Version 1 ...................................................................................10
2.5.2. Die SNMP Version 2 ...................................................................................11
2.5.3. Die SNMP Version 3, ..................................................................................11
2.6. Die Datensicherheit des SNMP..........................................................................15
3. Voraussetzungen für eine Integration von SNMP in die TV Produktion......19
3.1. Anforderungen an einzelne Komponenten durch SNMP...................................19
3.1.1. Der Standardisierungsprozess von broadcastspezifischen MIB Modulen ...20
3.1.2. Die aktuelle Situation der MIB Implementierung........................................22
3.2. Möglichkeiten der Einbindung von Geräten ohne SNMP Unterstützung..........22
3.3. Die Nachrüstung des SNMP – Dienstes durch zusätzliche Software ................24
3.4. Die Überwachung von Software mittels SNMP ................................................25
4. Aufgaben des Managements in der TV Produktion ........................................26
4.1. Kriterien des Systemmanagement......................................................................27
4.2. Aufgaben des Agenten der Einzelkomponenten in der Produktion ...................30
4.3. Aufgaben des Managers der Managementstation in der Produktion .................30
4.4. Aufgaben der Systemmanagement – Applikation: ............................................31
4.5. Bestehende Systemmanagementlösungen..........................................................34
4.5.1. Eine Auswahl von Systemmanagement-Applikationen...............................35
5. Die Testbedingungen für Management-Applikationen ...................................37
5.1. Die Testumgebung für das Systemmanagement ................................................37
5.2. Die Geräte der Testumgebung und ihre Möglichkeiten .....................................40
5.2.1. Der Audio and Video Delay Corrector 100 (AVDC) ..................................40
5.2.2. Der Profile XP Media Platform PVS 1000 ..................................................43
5.2.3. Der Digital Video Quality Analyser (DVQ) ................................................49
iii
Anwendung des SNMP
6. Die Inbetriebnahme von ausgewählten Managementapplikationen ..............54
6.1. Die Installierung des Network Node Manager von HP-Openview....................54
6.1.1. Die Erkennung und Darstellung des Netzwerkes.........................................55
6.1.2. Zuverlässigkeit der Netzerkennung..............................................................58
6.1.3. Das Grundlayout ..........................................................................................58
6.1.4. Die Anpassung der Darstellung an das Broadcastumfeld ............................59
6.1.5. Standard-Tools zur Analyse von Managementdaten ...................................60
6.1.6. Das Error-Mapping des Node Managers......................................................65
6.1.7. Die Einbindung von Broadcastkomponenten...............................................67
6.1.7.1. Die vereinfachte Softwarestruktur des Node Managers.........................69
6.1.7.2. Die Nutzung der offenen Softwarestruktur ............................................70
6.1.8. Das Controlling und Monitoring der Testkomponenten ..............................72
6.1.9. Beurteilung des Node Managers zum Einsatz in der TV-Produktion..........75
6.2. Die Management-Applikation NetCentral von Grass Valley ............................78
6.2.1. Die Installation der Managementstation ......................................................79
6.2.2. Die Erkennung der Netzkomponenten .........................................................80
6.2.3. Die Funktionalität der NetCentral Managementstation ...............................81
6.2.3.1. Das Monitoring der Komponenten.........................................................82
6.2.3.2. Das Error – Handling von NetCentral....................................................83
6.2.3.3. Weitere Funktionalitäten........................................................................84
6.2.4. Beurteilung der NetCentral Managementstation..........................................85
6.3. Die Applikation RollCall und RollMap .............................................................87
6.3.1. Die Monitoring – Möglichkeiten durch RollMap ........................................88
6.3.2. Die RollMap Software als Proxy .................................................................88
6.3.3. Die Schwächen von RollCall/RollMap........................................................89
7. Zusammenfassung und Ausblick .......................................................................90
7.1. Zusammenfassung..............................................................................................90
7.2. Ausblick .............................................................................................................91
ANHANG .................................................................................................................. A
Literaturverzeichnis................................................................................................. L
iv
Anwendung des SNMP
Abbildungsverzeichnis:
Abbildung 1 : Die Aufgabe des Control und Monitoring in der IT basierten
Fernsehproduktion...............................................................................1
Abbildung 2 : Grundaufbau des SNMP Management ..............................................4
Abbildung 3 : SNMP und das TCP/IP Modell..........................................................6
Abbildung 4 : Der MIB Baum ..................................................................................7
Abbildung 5 : ASN.1 in der Anschauung [9]............................................................9
Abbildung 6 : SNMPv3 Entity (basierend auf [14]) ...............................................12
Abbildung 7 : SNMPv3 Nachrichtenformat [20]....................................................14
Abbildung 8 : Der Inhalt einer SNMP Nachricht ([3], S.355) ................................15
Abbildung 9 : Sicherheit durch SNMP Version 3 und Tunnelprotokolle...............17
Abbildung 10 : Framework der geplanten Broadcast-MIB [26] ...............................21
Abbildung 11 : Erster Vorschlag für die Standardisierung einer MIB für das PlayOut [26] .............................................................................................21
Abbildung 12 : Nutzung des ARC als SNMP Proxy Agent......................................24
Abbildung 13 : Kriterien für ein Systemmanagement ..............................................26
Abbildung 14 : Beispiel für die Aufgabe des Systemmanagements in der TV
Produktion .........................................................................................28
Abbildung 15 : SNMP Manager und die Managementapplikation...........................31
Abbildung 16 : Muster der Hierarchiegliederung für die Managementapplikation..32
Abbildung 17 : Die Struktur des Testnetzwerks .......................................................37
Abbildung 18 : SAN-Architektur in der IT basierten TV Produktion ......................38
Abbildung 19 : Das Konfigurationsnetz ...................................................................39
Abbildung 20 : Ein Überblick über das Testsegment des Hausnetzes......................40
Abbildung 21 : AVDC 100 Wasserzeichentechnik ..................................................41
Abbildung 22 : Positionen der Untergruppen in der AVDC MIB (Screenshot von
Programm MG-Soft MIB Browser, Anhang CD\MG-Soft) .............42
Abbildung 23 : Signalblockplan des Profile XP .......................................................44
Abbildung 24 : Die Broadcast MIB Module des Profile XP (Screenshot von
Programm MG-Soft MIB Browser, Anhang CD\MG-Soft) .............45
Abbildung 25 : Einsatzgebiet des DVQ im Play-Out [37]........................................49
Abbildung 26 : Das MIB Modul des DVQ (Screenshot von Programm MG-Soft
MIB Browser, Anhang CD\MG-Soft)...............................................50
Abbildung 27 : DVQ MIB Repräsentation aller Programme innerhalb des
Transportstroms.................................................................................51
Abbildung 28 : Netzwerkdarstellung der Openview-Applikation (Screenshots aus
der Testinstallation)...........................................................................55
Abbildung 29 : Datenaufkommen durch den Node Manager pro Komponente
(basierend auf der Darstellung des MGSoft MIB Browsers)............57
Abbildung 30 : Darstellung der Netzkomponenten durch Openview (Screenshots aus
der Testinstallation)...........................................................................59
Abbildung 31 : Nachvollziehbarkeit der geografischen Position der Komponenten
im System (Screenshots aus der Testinstallation) .............................60
v
Anwendung des SNMP
Abbildung 32 : Der MIB Browser (Screenshot aus der Testinstallation) .................61
Abbildung 33 : Datenaustausch durch den Collector (Mitschnitt durch Ethereal, file
„netztest-2-er lang“ Paket) ................................................................62
Abbildung 34 : Darstellung der gemessenen Datenraten des DVQ durch den
Grapher des Node Manager (Screenshot aus der Testinstallation) ...63
Abbildung 35 : Datenrepräsentation durch den Application Builder am Beispiel des
Profile XP (Screenshot aus der Testinstallation) ..............................63
Abbildung 36 : Beispiel für den Aufruf externer Programme zur Auswertung von
Managementdaten (Screenshot aus der Testinstallation)..................64
Abbildung 37 : Verarbeitungspfad von eingehenden Trapsendungen (basierend auf
Screenshots aus der Testinstallation) ................................................65
Abbildung 38 : Definitionen neue Symboltypen (Screenshot aus der Testinstallation)
...........................................................................................................68
Abbildung 39 : Menudarstellung der Komponentenintegration (Screenshot aus der
Testinstallation).................................................................................69
Abbildung 40 : Modularer Aufbau der Node Manager Applikation.........................70
Abbildung 41 : Ablaufplan der DVQ Messwertkonvertierung durch messung.exe
(Anhang D-3) ....................................................................................71
Abbildung 42 : Die DVQ-Repräsentation auf der GUI (basierend auf Screenshots
aus der Testinstallation) ....................................................................72
Abbildung 43 : Umsetzung des Controlling und Monitoring des AVDC100
innerhalb des Node Managers (basierend auf Screenshots der
Testinstallation).................................................................................74
Abbildung 44 : Die Integration der Überwachung des Profile XP in der GUI des
Node Managers (basierend auf Screenshots aus der Testinstallation)
...........................................................................................................75
Abbildung 45 : Die Softwarearchitektur des NetCentral Managementsystems (vgl.
[42], S.18)..........................................................................................78
Abbildung 46 : Das Schema des Ablaufes von SNMP Abfragen in NetCentral am
Beispiel der Pollingverfahren (vgl. [42] S.157) ................................81
Abbildung 47 : Die Darstellung der Komponenten im GUI der NetCentralApplikation (Screenshot aus der Testinstallation) ............................82
Abbildung 48 : Die Darstellung der MIB Daten des Profile XP der Untergruppe
pvsCardCage (basierend auf Screenshots aus der Testinstallation) ..83
Abbildung 49 : Die Fehlerverarbeitung von NetCentral (basierend auf Screenshots
aus der Testinstallation) ....................................................................84
Abbildung 50 : Der Testaufbau für die RollCall/RollMap-Managementstation ......87
Abbildung 51 : Die grafische Einbindung der überwachten Komponenten. Links:
reelle Komponentennachbildung; Rechts: Darstellung des
Signalpfades (Screenshot aus der Testinstallation)...........................88
Abbildung 52 : Ablaufplan der Datei sendereinstellung.c (Verzeichnis „zusätzliche
Programme NNM/
BIN_cygwin_home_administrator\DVQ\measurement“)................... J
Abbildung 53 : Ablaufplan der Datei tsprog.c (Verzeichnis „zusätzliche Programme
NNM/ BIN_cygwin_home_administrator\DVQ\TSProg“) ............... K
vi
Anwendung des SNMP
Tabellenverzeichnis:
Tabelle 1 : ASN.1 Macros zur Definition der MIB Struktur ....................................9
Tabelle 2 : Datentypen innerhalb des SNMP Modells [15] ....................................10
Tabelle 3 : Überwachungsbereiche der definierten Traps des Profile XP ..............48
Tabelle 4 : Messparameter des DVQ ......................................................................52
Tabelle 5 : Messwerte des DVQ .............................................................................52
Tabelle 6 : RFC Standards der SNMPv1 ................................................................. A
Tabelle 9 : Trapsendungen der AVDC100 MIB ..................................................... D
Tabelle 10 : Die Variablen der Trapsendungen der DVQ MIB ................................. E
Akronyme
AES
API
ARF
ARP
ASCII
ASN.1
AVDC100
BER
CMIP
DAB
DDP
DVB-T
ECS
GPI
GUI
HTML
IANA
ICMP
IETF
IP
IPsec
IPX
ISO
ISO-IEC
Audio Engineering Society
Application Programming Interface
Application Registration File
Address Resolution Protocol
American Standard Code for Information Interchange
Abstract Syntax Notation One
Audio Video Delay Corrector, Messgerät der Firma Tektronix
Basic Encoding Rules
Common Management Information Protocol
Digital Audio Broadcasting
Datagram Delivery Protocol
Digital Video Broadcasting–Terrestrial
Event Correlation Service
General Purpose Interface
Graphical User Interface
Hypertext Markup Language
Internet Assigned Numbers Authority
Internet Control Message Protocol
Internet Engineering Task Force
Internet Protocol
Internet Protocol Security
Internetwork Packet Exchange
International Organization for Standardisation
International Organization of Standardization–International
vii
Anwendung des SNMP
IT
ITU
KPV
MD5
MIB
MPEG
MXF
OID
OSI
PCI
PDU
RAID
RFC
SAN
SAW
SCPI
SDI
SDTI
SHA
SMI
SMPTE
SNMP
SQL
TCP
TS
UDP
URL
VNC
VPN
Electrotechnical Commision
Informationstechnologie
International Telecommunication Union
Konferenz für Programmverbreitung
Message Digest Algorithm
Management Information Base
Motion Picture Experts Group
Material eXchange Format
Object Identifier
Open Systems Interconnection
Peripheral Component Interconnect
Protocol Data Unit
Redundant Array of Independent Disks
Request for Comments
Storage Area Network
Sendeabwicklung
Standard Commands for Programmable Instruments
Serial Digital Interface
Serial Data Transport Interface
Secure Hash Algorithm
Structure of Management Information
Society of Motion Picture and Television Engineers
Simple Network Management Protocol
Structured Query Language
Transmission Control Protocol
Transportstrom
User Datagram Protocol
Uniform Resource Locator
Virtual Network Computing
Virtual Private Networks
viii
Anwendung des SNMP
1. Einleitung und Aufgabenstellung
Die Infrastruktur und somit die gesamte fernsehtechnische Produktion steht vor
einem generelle Umbruch. Der rasante Fortschritt in den Bereichen der IT erobert
den Broadcast Markt. Der Umstieg von altbewährter analoger Technologie hin zu
der vernetzten IT basierten Fernsehproduktion ist im vollen Gang und teilweise
sogar schon Realität.
Die große Chance beim Umstieg auf IT basierte Technologie liegt in der extremen
Vereinfachung der Arbeitsabläufe. Die Effizienz der Produktionsabläufe wird
immer höher. Im Gegensatz dazu sinkt die Anzahl des nötigen Fachpersonals. Um
dieser Entwicklung Nachhaltigkeit zu sichern, muss die neue Technologie fehlerfrei
funktionieren.
Abbildung 1 : Die Aufgabe des Control und Monitoring in der IT basierten Fernsehproduktion
Bisherige
Mechanismen
zur
Überwachung
und
Kontrolle
der
Broadcastkomponenten basierten meist auf proprietären Schnittstellen. Da der
Umgebung der IT basierten Produktion heterogene Strukturen mit unterschiedlichen
Herstellern und Technologien zugrunde liegt, sind jedoch offene und standardisierte
Schnittstellen gefragt. Eine solche Schnittstelle bietet den Zugriff auf alle
Komponenten eines Produktionssystems (Abbildung 1). Dieser Zugriff erlaubt die
Überwachung der Funktion der jeweiligen Komponenten.
Auf der Suche nach neuen Wegen zur messtechnischen Überwachung der
Produktionsplattform können Erkenntnisse aus der IT eine Hilfestellung geben. Das
Simple Network Management Protokoll (SNMP) bietet auf dem Gebiet des
Systemmanagement der IT Industrie einen etablierten Standard. SNMP stellt somit
eine Möglichkeit für eine standardisierte Überwachungsschnittstelle dar.
1
Anwendung des SNMP
Aufgabe dieser Arbeit ist die praktische und theoretische Beurteilung, ob und in
welcher Form SNMP in einer IT basierten Produktionsumgebung zum Einsatz
kommen kann.
Zu einer solchen Beurteilung bedarf es Kriterien, die von den Anwendungen der
Technologie innerhalb der Produktionsumgebungen bestimmt werden. Ausgehend
davon wird eine Testumgebung für Management-Applikationen basierend auf
SNMP geschaffen. Hierbei werden Komponenten mit SNMP Funktionalität
bezüglich ihrer Implementierung analysiert.
Diese Umgebung bildet eine Plattform zur Analyse und Beurteilung von SNMP
Management-Applikationen sowohl aus der IT als auch der Broadcastindustrie.
Durch diese Arbeiten entsteht zum einen eine Testplattform, zum anderen geben die
Untersuchungen Aufschluss über die Fähigkeiten des SNMP für die
Fernsehproduktion. IT und Broadcast Management-Applikationen werden dabei
vergleichend dargestellt.
2
Anwendung des SNMP
2. Grundlagen des SNMP Management
Erste Überlegungen hin zu einem Netzwerkmanagement entstanden in der IT
Industrie 1987. Die International Organization for Standardisation (ISO) verfolgte
einen Ansatz, der auf dem OSI (Open Systems Interconnection) Modell basierte.
Hieraus entwickelte sich ein Konzept, das den Namen CMIP (Common
Management Information Protocol) trug. CMIP setzte sich in der Industrie
allerdings nie durch. Grund hierfür war der hohe Aufwand, der bei einer
Implementierung von CMIP nötig wurde. Diese Lösung wird allgemein als zu
komplex angesehen.
Mehr Aussicht auf Erfolg hatte eine Standardisierungsinitiative der IETF (Internet
Engineering Task Force). Zeitgleich zur ISO und CMIP Idee entstand eine
Arbeitsgruppe für das Simple Network Management Protocol (SNMP). Die Vorteile
dieses Ansatzes lagen in der einfachen Struktur von SNMP. Im Mai 1990 lagen die
ersten Normungen von SNMP Version 1 vor, welche in RFC (Request for
Comments) 1155, 1156, 1157 standardisiert wurden. Schnell fanden diese Ansätze
in der Industrie Interesse. Heute hat sich SNMP als Grundlage für fast alle
Systemmanagementlösungen in der IT durchgesetzt.
Im Laufe der Jahre wurde das SNMP Version 1 weiterentwickelt und um wichtige
Punkte ergänzt. Mit Version 2 (1992) und Version 3 (1999) wurden auftretende
Schwachstellen beseitigt. Anhang A-1 gibt einen Überblick über die aktuellen
Standards aller SNMP Versionen.
2.1. Das Managementkonzept mittels SNMP
Ziel des Managements mittels SNMP ist es, eine komplexe Netzwerkinfrastruktur
mit allen enthaltenen Komponenten und deren Eigenschaften zu überwachen und zu
kontrollieren.
Um ein Management zu ermöglichen, müssen die Komponenten Informationen über
deren Status und aktuelle Funktion austauschen können.
Kommunikationspartner sind dabei der SNMP Manager und SNMP Agent. Beide
stehen in einer Client-Server Beziehung zueinander. Der Client ist der aktive Teil
der Kommunikation und fragt beim Server Informationen an. Der Server reagiert
mit einer Antwort. Welche Rolle der SNMP Agent oder Manager dabei einnimmt,
wird durch die jeweilige Kommunikationssituation vorgegeben.
Der
Manager
ist
im
Sinne
der Kommunikation
ein
zentraler
Kommunikationsknoten, der fähig ist, Verbindungen zu allen Komponenten eines
Managementsystems aufzubauen. Er ist die Managementzentrale im System mit der
Anbindung an eine Applikation zur Handhabung des Managements. Die Gesamtheit
von Manager und Applikation wird im Verlauf als Managementstation beschrieben.
Der SNMP Agent ist der Kommunikationspartner auf Seiten der einzelnen
Komponenten. Dieser ist eine Softwareinstanz, die auf den jeweiligen Komponenten
implementiert ist.
Der Datenaustausch zwischen
Kommunikationsszenarien.
Manager
und
Agent
folgt
einfachen
§ Der Manager (Client) kann Werte der Agentenkomponente
abfragen. Dazu stehen durch SNMP mehrere Kommandos bereit
3
Anwendung des SNMP
(u.a. get, getnext, walk). Der Agent (Server) antwortet (response)
mit dem angefragten Wert oder einer Fehlermeldung.
§ Über ein „set“ Kommando ist es dem Manager (Client) möglich,
Werte in einer Agentenkomponente aktiv zu verändert. Der Agent
(Server) antwortet mit einer Bestätigung des veränderten Wertes.
§ Die bisherigen Abläufe werden von der Managementstation
initialisiert. Darüber hinaus kann ein Agent (Client) spontane
Nachrichten an eine Managementstation (Server) versenden. Diese
Nachrichten werden Traps genannt und sind als Fehlermeldung oder
Alarmschrei einer Komponente zu verstehen.
Der Inhalt der Kommunikation sind Managementobjekte. Diese beschreiben die
Funktion und Parameter der Komponenten. Neben allgemeinen Informationen über
die Art der Komponente werden komponentenspezifische Werte durch Objekte
beschrieben. Im Falle eines Videomessgerätes können dies einzelne Messwerte oder
Parameter zur Durchführung einer Messung sein.
Einzelne Komponenten bestehen aus einer Vielzahl von Managementobjekten. Die
Summe der Objekte bildet das Datenmodell der Management Information Base
(MIB). In der Agentenimplementierung wird die MIB in einer Datenbank verwaltet.
Die Werte der einzelnen Objekte werden durch den Agenten innerhalb der
Komponente nachgefragt und permanent aktualisiert.
Internet(1)
directory(1)
Internet(1)
directory(1)
Mgmt(2)
Experimental(3)
mib2(1)
system(1)
Ifnumber(1)
sysDescr(1)
sysObjectID(2)
sysUpTime(3)
sysContact(4)
sysName(5)
sysLocation(6)
sysService(7)
IRT(19831)
Experimental(3)
mib2(1)
Private(4)
enterprises(1)
Interfaces(2) ...
Mgmt(2)
system(1)
Hersteller 1
Interfaces(2) ...
Ifnumber(1)
Hersteller 1
sysDescr(1)
sysObjectID(2)
sysUpTime(3)
sysContact(4)
sysName(5)
sysLocation(6)
sysService(7)
ifTable(2)
ifEntry(1)
Private(4)
enterprises(1)
IRT(19831)
ifTable(2)
ifEntry(1)
ifIndex(1)
ifDescr(2)
ifIndex(1)
ifDescr(2)
Abbildung 2 : Grundaufbau des SNMP Management
In den meisten Netzwerken sowohl der IT als auch des Broadcastbereichs sind
Komponenten integriert, die von unterschiedlichen Herstellern stammen.
Maßgeblich für den Erfolg der Kommunikation zwischen Managementstation und
Komponenten unterschiedlicher Hersteller ist die Kompatibilität der Informationen.
Die jeweilige MIB mit ihren Objekten wird in der Abstract Syntax Notation One
(ASN.1) beschreiben. Somit ist die Datenrepräsentation innerhalb des SNMP
Modells Hersteller übergreifend genormt.
Anhand der Abbildung 2 lässt sich der Ablauf eines SNMP Management
anschaulich beschreiben.
Mehrere Netzwerkkomponenten mit Agentenimplementierung sind über ein
Netzwerk an eine Managementstation angeschlossen. Die Betriebsparameter der
4
Anwendung des SNMP
einzelnen Komponenten sind in der individuellen MIB Datenbank hinterlegt. Die
einzelnen Parameter werden durch MIB Objekte für alle Komponenten in ASN.1
codiert. Sie stehen somit der Kommunikation mit der Managementstation zur
Verfügung. Über SNMP hat die Managementstation nun Zugriff auf die relevanten
Werte der Komponenten. Kommt es in der Komponente zu einem Fehler, sendet
diese eine Trapnachricht zur Alarmierung der Managementstation.
Bei der Komponentenüberwachung kommen zwei Verfahren zum Einsatz. Beim
Polling fragt der Manager zyklisch Werte der Komponenten ab und überwacht somit
Änderungen dieser. Je nach Wichtigkeit muss ein Zeitintervall für die Wiederholung
angegeben werden. Dieses Verfahren birgt Gefahren in der resultierenden hohen
Netzlast. Das zweite Verfahren verlässt sich auf die Trapsendungen der
Komponenten zur Erkennung von Fehlern.
Ideal zur Überwachung ist eine wohl überlegte Mischung aus Trap und Polling
Verfahren ([1], Kapitel 3.2.1).
Die Auswertung der Managementdaten erfolgt über eine Managementapplikation.
Diese greift auf den SNMP Manager zu, um diese Daten zu erfassen. Die
Applikation ist das Werkzeug der Überwachung. Sie muss es ermöglichen, die
SNMP Managerschnittstelle für alle SNMP Komponenten des Netzwerkes zu
nutzen.
5
Anwendung des SNMP
2.2. Unterlagerte Dienste – Der Transport von SNMP
Das Management Konzept von SNMP ermöglicht die Überwachung und Kontrolle
von komponentenspezifischen Werten. Dabei übernimmt SNMP die Aufgabe,
Struktur und Inhalt der Managementkommunikation festzulegen. Zur Übertragung
der festgelegten Informationen nutzt SNMP die TCP/IP Technik. Eine Einordnung
in das OSI Referenzmodel führt zu der Darstellung in Abbildung 3. SNMP nimmt
einen Platz in der Anwendungsschicht ein.
Abbildung 3 : SNMP und das TCP/IP Modell
Die SNMP Nachrichten werden in die Pakete der unterlagerten Schichtdienste
einsortiert. Auf Transportebene wird meist UDP genutzt. Dabei werden genormte
Portnummern [2] verwendet. Der Empfang der SNMP Anfragen und Bestätigungen
erfolgt über Port 161. Traps werden über Port 162 empfangen.
Der nachfolgende IP Dienst sorgt für die Zustellung der Pakete in allen IPtauglichen Netzwerken. Der Einsatz von SNMP ist über die gesamte heterogene ITNetzwerktechnologie möglich.
Eine vermeintliche Schwachstelle im Transportmechanismus ist die Nutzung von
UDP. Dieser Dienst gibt keine Garantie, dass gesendete Informationen tatsächlich
empfangen werden. Bei der Versendung von Traps durch den SNMP Agenten wird
der Empfang nicht bestätigt. Geht dieser bei der Übertragung verloren, erreicht die
Fehlermeldung die Managementstation nicht. Gerade in weit verzweigten
Netzwerken über eine größere Distanz kann dies der Fall sein.
Bei Anfragen der Managementstation erwartet der SNMP Manager eine Antwort. In
diesem Fall tritt kein Problem auf.
Neben UDP sieht der SNMP Standard weitere Transportmechanismen vor. RFC
3430 beschreibt TCP als Transportprotokoll. In der Praxis kommt TCP allerdings
selten zum Einsatz.
Zudem ermöglicht RFC 3417 den Einsatz von SNMP über das Internetwork Packet
Exchange (IPX) Protokoll und über das Datagram Delivery Protokoll (DDP).
6
Anwendung des SNMP
2.3. Die Management Information Base-MIB
Inhalt der Managementkommunikation sind die Managementobjekte. Ein solches
Objekt repräsentiert eine Ressource einer Komponente des Netzwerks. Die
Beschreibung aller Managementobjekte erfolgt in der MIB Struktur. Die MIB gibt
dabei die Semantik und Syntax der Objekte an, die eine Komponente beinhaltet.
Zudem werden die Trapsendungen definiert. Die Beschreibungssprache der
gesamten MIB Struktur ist ASN.1.
Die Zuweisung der reellen Werte einer Komponente, die so beschrieben werden, ist
nicht festgelegt. Dies liegt in den Händen der Hersteller der Komponenten. Die MIB
dient der Beschreibung der Funktionalität einzelner Komponenten.
Der MIB Aufbau gleicht einer Baumstruktur, die sich von einem Ursprung (root) bis
zum jeweiligen Objekt nachvollziehen lässt. Die Beschreibung einzelner Objekte
erfolgt durch numerisches Aneinanderreihen der jeweiligen Kennziffer der
Knotenpunkte auf dem Weg vom root bis zum entsprechenden Objekt. Die so
entstehende Zahlenreihe wird Objekt Identifikator (OID) genannt. Das Schema der
MIB zeigt Abbildung 4. Nach diesem Muster lassen sich alle Objekte innerhalb
dieser Baumstruktur eindeutig definieren.
Abbildung 4 : Der MIB Baum
Ein Beispiel für die Beschreibung eines Objektes über seinen OID ist:
OID (sysUpTime) = .1.3.6.1.2.1.1.3 (siehe Abb.4)
Dieses Objekt ist Teil der „system“ Untergruppe. Weitere Objekte dieser
Untergruppe sind: eine Textbeschreibung des Systems (sysDscr), ein Verweis auf
den Hersteller (sysObjectID), die Zeit, die das Gerät seit der letzten Reinitialisierung
7
Anwendung des SNMP
in Betrieb ist (sysUpTime), der Name einer Kontaktperson (sysContact), der Name
des Gerätes, eine Beschreibung des physikalischen Standortes (sysLocation) und
eine Beschreibung des Services, welches das Gerät nach dem ISO Schichtmodel
unterstützt.
Einige Objekte müssen in Komponenten implementiert sein, da sie vom SNMP
Standard benutzt werden. Eines dieser Pflichtobjekte ist die SysUpTime. Das SNMP
Modell sieht innerhalb mancher Protocol Data Units (PDU) Felder für Zeitstempel
vor, welche aus diesem Objekt gebildet werden. Beispiel hierfür sind die TrapSendungen ab Version 2 des SNMP ([3], S.364). Ein Fehlen dieser Werte führt zu
einem Fehler in der Paketgenerierung.
Die Standard MIB für alle Geräte, die über SNMP zu managen sein sollen, ist die
MIB2, spezifiziert in RFC 1213. Die MIB2 ist eine Erweiterung der MIB1, welche
nicht genügend Objekte für ausreichendes Management vorsah. Sie bildet den
Grundvorrat an Managementobjekten für einzelne Komponenten.
Die system-Untergruppe der MIB2 sollte auf jeden Fall in jeder SNMP-fähigen
Komponente vorhanden sein, und zwar aus dem Grund, weil die meisten
Anwendungen auf Basis von SNMP auf diese Werte zurückgreifen, um diese zu
identifizieren.
Die weiteren Gruppen der MIB2 (interface, at, ip, icmp, tcp, udp, egp, transmission,
snmp) spezifizieren die charakteristischen Werte der Schichten des TCP/IP Modells.
Soweit ein Gerät die entsprechenden Schichten bedient, müssen diese Gruppen
ebenfalls implementiert sein. Die jeweiligen Objekte dieser Untergruppen können
nachgelesen werden ([3], S.196-238).
Eine Stärke des SNMP liegt in seiner offenen Struktur. Es ist möglich, jedes
erdenkliche Gerät über SNMP zu managen. Dazu bedarf es spezieller MIB Module
mit den entsprechenden Objekten, welche die Geräteparameter abbilden. Im MIB
Tree wurde ein Platzhalter geschaffen, der es Herstellern ermöglicht, eigene MIB zu
definieren. Unterhalb des private.enterprises Zweiges (OID 1.3.6.1.4.1) kann sich
jeder Hersteller einen MIB Zweig reservieren. In diesen Hersteller spezifischen MIB
werden die Objekte beschrieben, die die MIB2 nicht abdeckt.
Die Vergabe der Nummern unterhalb des enterprise-Zweiges übernimmt die IANA.
Beantragen kann man eine Nummer unter www.iana.org. Das Institut für
Rundfunktechnik hat die Nummer 19381 zugeteilt bekommen. Unterhalb der OID
1.3.4.1.4.1.19381 kann das IRT eigene MIB Objekt definieren. Die weitere Struktur
unterhalb der Herstellernummer ist nicht reglementiert.
MIB Gruppen und Objekte unterhalb des MIB2 Zweiges sind dagegen
standardisierte Festlegungen. Diese MIB Module sind nicht mehr zu verändern.
Mittlerweile gibt es eine Unmenge dieser unter dem MIB2 Zweig folgenden
Module. Eine Übersicht gibt [4].
Die bisherige Standardisierung der MIB resultiert aus den Bedürfnissen der IT. In
der Vielzahl der MIB Module sind bereits einige Festlegungen getroffen, die auch
für den Broadcastbereich relevant sind. Einige dieser Module sind:
Ethernet – MIB [5],
FDDI – MIB [6],
8
Anwendung des SNMP
ATM – MIB [7],
FibreChannel – MIB [8]
Diese können ein Management der entsprechenden Netzwerktechnologien
gewährleisten.
2.4. Der Aufbau der Managementinformationen
RFC 2578 legt die Abtract Syntax Notation One (ASN.1) als Beschreibungssprache
für das gesamte SNMP-Framework fest. Die aktuell gültige Struktur für
Managementinformationen (SMI) ist die Version zwei.
Die Aufgabe von ASN.1 ist es, die Datenstrukturen, die SNMP benötigt, zu
beschreiben. Die Baumstruktur der MIB, sowie alle zu managenden Objekte und
auch die Kommando PDUs werden in der Sprache ASN.1 ausgedrückt.
ASN.1 beschreibt, wie gewisse Strukturen aussehen müssen. Wie dieses dann
letztlich von Herstellern in den Geräten umgesetzt wird, ist nicht vorgeschrieben.
ASN.1 fungiert als Dolmetscher für das SNMP Modell, um Geräte unterschiedlicher
interner Kommunikation integrieren zu können (Abbildung 5).
Abbildung 5 : ASN.1 in der Anschauung [9]
Eine zusammengehörende Datenmenge, die mit ASN.1 zu beschreiben ist, wird in
Form von Modulen definiert. RFC 2578 beschreibt einige MACROS (siehe Tabelle
1), die ein sprachliches Korsett für ASN.1 Module vorgeben.
ASN.1 MACRO TYP
Aufgabe des MACROS
MODULE-IDENTITY
Beschreibung der OID-Struktur eines
MIB Moduls
Definition
des
Inhalt
einer
Objektbeschreibung
Beschreibung
der
möglichen
Trapsendungen einer Komponente
OBJECT-TYPE
NOTIFICATION-TYPE
Tabelle 1 : ASN.1 Macros zur Definition der MIB Struktur
Die einzelnen Objekte einer MIB sind repräsentativ für reelle Werte einer
Komponente. Die Festlegung, um welche Art von Wert es sich handelt, ob
Textnachricht oder Zahlenwert, geben die Datentypen. SNMP beschränkt die zur
Verfügung stehenden Datentypen auf die in Tabelle 2 dargestellten.
9
Anwendung des SNMP
SNMP Typ
Integer
Octet String
ipAddress
Counter
Gauge
Timeticks
Unsigned
Table
Beschreibung
Positiver oder negativer Zähler ganzer Zahlen
Byte String (z.B. ASCI – Text)
IP Adresse einer Komponente
Nur aufsteigender positiver Zähler ganzer Zahlen
Steigender und fallender positiver Zähler ganzer
Zahlen
Positiver Zeitzähler der Hunderstelsekunden
Positive ganze Zahl
Ermöglicht die Beschreibung von Objekten in
Tabellenform
Tabelle 2 : Datentypen innerhalb des SNMP Modells [15]
Neben der Datentypenbeschreibung enthält das ASN.1 Schema eine Klassifizierung
der Zugriffsrechte auf das einzelne Objekt. Die Rechte „not-accessible“,
„accessible-for-notify“, „read-only“, „read-write“ und „read-create” können
zugeordnet werden. Einen detaillierten Einblick in ASN.1 gibt [10].
Nachdem alle Informationen des SNMP Modells durch ASN.1 beschrieben sind,
werden diese gemäß Basic Encoding Rules (BER) codiert ([11], ab S.122).
Anschließend greifen die untergelagerten Schichten auf die codierten Daten zu und
verarbeiten diese. ASN.1 stellt somit eine Abstraktionsebene dar, die ein
gemeinsames Datenmodell für SNMP bietet. Unabhängig von der
Datenrepräsentation innerhalb der Komponenten.
Anhang A-2 beschreibt exemplarisch den Aufbau des AVDC 100 MIB Moduls
durch ASN.1.
2.5. Die standardisierten Versionen des SNMP
Die Entwicklung der SNMP Standards brachte drei Versionen hervor. Im Folgenden
werden die einzelnen Versionen kurz besprochen. Schwachpunkte und
Anforderungen an die Folgeversion werden genannt.
2.5.1. Die SNMP Version 1
Die erste SNMP Version bietet die grundlegenden Strukturen des Managements.
Die Abfrage und Krontrolle von spezifischen Werten einer Komponente ist mit
dieser Version möglich. Die wichtigsten RFC der SNMP Version 1 sind in Anhang
A-1 zu finden.
Allerdings beinhaltet diese Version einige Schwachstellen, die durch die
nachfolgenden Versionen behoben werden sollten.
§ Die erste Version definiert lediglich fünf Grundoperationen ([1], S.20-27).
Get, Get-next, Set, Response und Trap erfordern für jede Datenmitteilung
eine eigenen Sendung. Sammelmitteilungen von mehreren Objektwerten
sind nicht vorgesehen. Hieraus resultiert eine unnötig hohe Netzbelastung.
10
Anwendung des SNMP
§ Eine weitere Schwachstelle der Version 1 liegt in der starren, dezentralen
Struktur des Managements. Das Management beruht auf der Client-Server
Kommunikation eines Managers mit einem Agenten ([1], S.4). Ein
hierarchisches Management mit der Kommunikation zwischen zwei
Managern ist nicht möglich.
§ Die Syntax der Version 1 umfasst eine zu kleine Anzahl von MIB Variablen
und Datentypen.
2.5.2. Die SNMP Version 2
Erweiterungen durch die SNMP Version 2 nahmen sich dieser Schwachstellen an.
Es entstand eine überarbeitete Version, die ergänzend zu SNMPv1 zu sehen ist.
§ Version 2 erleichtert das Auslesen größerer Datenmengen durch die
Definierung neuer Kommunikationskommandos [12]. Der GetbulkRequest
erlaubt das Auslesen mehrerer Werte innerhalb einer Abfrage. Somit steigt
die Effizienz der Abfragen.
§ Die dezentrale Struktur des Managements wurde durch die Manager-zuManager Kommunikation aufgelöst. Darin ist festgelegt, dass Komponenten
in einer dualen Rolle als Agent und Manager agieren können ([13], S.2,
übernommen in [14] S.4). Der Informationsaustausch zwischen Managern
unterschiedlicher Netzwerke wird ermöglicht. Zudem entstand ein neues
Kommunikationskommando. Der InformRequest leitet eingehende
Trapsendungen an Manager einer höheren Hierarchiestufe weiter [12].
§ Die syntaktische Erweiterung des SNMP Modells durch die Version 2 stellt
die größte Änderung dar [15]. Es wurden neue ASN.1 Macro Typen
geschaffen [16]. Diese enthalten detailliertere Informationen zur
Beschreibung der Objekte und Traps (Traps werden ab Version 2
Notification genannt).
- Die Definition neuer Datentypen stellt einen größeren Wertebereich für
Objekte bereit [15]. Zudem entstand die Möglichkeit, Tabellenstrukturen
in den MIB Modulen zu integrieren.
- Die MIB Spezifikation wurden durch neue Module ergänzt. Es entstand
die MIB2 als erweiterbare Struktur [17].
Anhang A-1 gibt einen Überblick der relevanten Standards der Version 2.
Die meisten Komponenten und Managementstationen basieren derzeit auf SNMPv1
und SNMPv2. Allerdings bleiben speziell im Bereich der Sicherheit der
Managementdaten einige Anforderungen durch diese Versionen unberücksichtigt
(siehe Die Datensicherheit des SNMP 2.6).
2.5.3. Die SNMP Version 3,
erweitet das Management um drei wichtige Dienste: Authentifizierung,
Geheimhaltung und Zugriffskontrolle. Um diese Dienste flexibel anbieten zu
können, führt Version 3 eine modular aufgebaute Entity ein. Eine Entity ist die
Gesamtheit aller in einem Agenten oder Manager auftretenden Prozesse. Sie
beschreibt in welcher Weise mit SNMP Nachrichten verfahren werden soll.
11
Anwendung des SNMP
Bei der Kommunikation von Manager und Agent sollte die Identität des Senders
garantiert werden. Zeitzähler in der Übertragung können manuelle Veränderungen
von Paketen, bspw. durch Sniffer Attacken, aufdecken. Diese Aufgabe übernimmt
der Authentifizierungsdienst. Er stellt sicher, dass eingehende Daten auch wirklich
das sind, was sie vorgeben.
Der Dienst der Geheimhaltung integriert einen Verschlüsselungsmechanismus in die
Managementnachricht. Der Standard schlägt die Verschlüsselungsalgorithmen MD5
(Message Digest Algorithm) und SHA (Secure Hash Algorithm) vor, lässt aber
andere Algorithmen zu ([18], S.3).
Der Zugriff auf Teile der Ressourcen eines Agenten soll eingeschränkt werden
können. Eine Einstufung, welcher Manager auf welche Daten eines Agenten
zugreifen kann, ist die primäre Aufgabe des Dienstes der Zugriffskontrolle [19].
Der bereits erwähnte modulare Aufbau der Version 3 Entity gestaltet sich nach
Abbildung 6. Jede Entity beinhaltet eine SNMP Engine. Diese Engine führt
diejenigen Funktionen aus, die zum Senden und Empfangen von SNMP
Nachrichten, zu deren Authentifizierung und Verschlüsselung notwendig sind,
sowie die Regelung der Zugriffskontrolle. Diese Funktionen werden als Dienste für
eine oder mehrere Manager Applications angeboten. Die Applications und die
Engine bilden gemeinsam die Entity.
Der modulare Aufbau bietet einige Vorteile. Die Rolle einer Entity wird von den
Modulen bestimmt, die in ihr implementiert sind. Neue Entwicklungen im SNMP
Modell können somit als neue Entity Module durchgesetzt werden. Eine Version 4
des SNMP soll somit umgangen werden.
Abbildung 6 : SNMPv3 Entity (basierend auf [14])
Entity Module der Application können von den Herstellern der Agenten oder
Managern je nach Bedarf implementiert werden. Die Engine kann ebenfalls durch
12
Anwendung des SNMP
neue Module nach Bedarf ergänzt oder verändert werden. Denkbar ist die
Einführung neuer Sicherheitsmodelle.
Die Standardisierung der Version 3 beschreibt folgende Module einer SNMP Engine
([14], S.17):
Der Dispatcher erlaubt die Verarbeitung von Nachrichten unterschiedlicher SNMP
Versionen. Die Forderung nach Abwärtskompatibilität der Versionen verlangt dies.
Er ist zuständig SNMP PDUs von den Applications abzunehmen und an den
Transportdienst weiterzuleiten. Zudem nimmt er Pakete von der Transportschicht
auf und gibt die PDU an die entsprechende Application weiter. Eine weitere
Funktion des Dispatchers ist die Weiterleitung ein- und ausgehender PDUs an das
Message Processing Subsystem.
Das Message Processing Subsystem ist zuständig für das Vorbereiten von
Nachrichten für den Sendevorgang und es packt Daten eingehender Nachrichten
aus. Der Message Header wird von diesem Subsystem ausgewertet.
Die Authentifizierung und Geheimhaltung werden vom Security Subsystem-Dienst
angeboten. Dieses Modul kann mehrere Sicherheitsmechanismen beinhalten.
Der Dienst der Zugriffskontrolle wird durch das Access Control Subsystem
dargestellt. Dieser Dienst prüft Zugriffsrechte. Zum Einsatz kommt er bei setAbfragen und bei der Generierung von Traps.
Diese Module stellen Dienste für die Applikationsmodule zur Verfügung. Diese
Applications unterscheiden sich in Agenten und Manager Entities. Eine Agent
Entity beinhaltet die Applications Command Responder und Notification Generator.
Die Entity eines Managers besteht grundlegend aus dem Command Generator und
dem Notification Receiver. Weitere Applikationsmodule können zusätzlich
eingebunden werden. Ein Beispiel für eine optionale Applikation ist der Proxy
Forwarder. Er spielt eine wichtige Rolle bei der Kompatibilität der verschiedenen
SNMP Versionen. Ein Proxy Forwarder leitet SNMP Nachrichten weiter.
Eingehende Nachrichten der Version 1 können durch die Entity in Version 3
konvertiert werden. Ein System mit Forwarder Application kann Bereiche von
Version 1 und 2 mit neuen Bereichen der Version 3 verbinden.
Diese Applications verarbeiten die PDU der SNMP Nachrichten. Sie greifen auf die
jeweils implementierten MIB Module zu und werten die Nachrichten entsprechend
aus. Notification Applications reagieren auf eingehende Version 2 Traps und
InformRequests. Command Applikationen versorgen die restlichen Kommandos des
SNMP Modells.
Die eben skizzierten Module der SNMPv3 Entity erzwingen eine Änderung der
Nachrichtenformate. Die Module fügen den Paketen bei ihrem Weg durch die Entity
neue Felder hinzu, die den entsprechenden Dienst gewährleisten. Der Weg eines
Paketes durch die Entity ist in Abbildung 6 rot dargestellt. Die grundsätzliche
Struktur der Kommandos durch die SNMPv2 PDUs wird beibehalten.
13
Anwendung des SNMP
Abbildung 7 : SNMPv3 Nachrichtenformat [20]
Durch die zusätzlichen Sicherheitskriterien der Version drei entsteht eine
Nachrichtenstruktur, welche in Abbildung 7 dargestellt ist.
Ein wesentlicher Aspekt innerhalb der unterschiedlichen Versionen des SNMP ist
die Abwärtskompatibilität. Agenten können Kommandos älterer Versionen
verarbeiten [21].
14
Anwendung des SNMP
2.6. Die Datensicherheit des SNMP
Managementdaten der MIB Module einzelner Komponenten beinhalten äußerst
wichtige Informationen. Konfigurationen und somit die Funktionalität von SNMP
gesteuerten Geräten sind über den SNMP Dienst abrufbar, teilweise sogar komplett
zu verändern. Die Manipulation solcher Daten von Dritten kann äußerst negative
Folgen haben.
Ein Play-out Center einer Sendeanstalt wird mittels SNMP kontrolliert und
überwacht. Die Multiplexer der DVB-T Signalstrecke lassen sich über SNMP
konfigurieren. Hat ein unberechtigter Dritter Zugriff auf diese Werte, ist es möglich,
das gesamte Play-out lahm zu legen oder umzukonfigurieren. Solche Daten müssen
unzugänglich sein und durch entsprechende Sicherheitsvorkehrungen geschützt
werden.
Abbildung 8 : Der Inhalt einer SNMP Nachricht ([3], S.355)
In der aktuellen Situation der SNMP Implementierung werden meist die Standards
der Version 1 und 2 verwendet. Die Sicherheitsproblematik dieser Versionen wird
durch das Beispiel eines Kommandopaketes (Abbildung 8) deutlich.
Der Community String ist eine ASCII Zeichenkette. Diese ist Bestandteil des SNMP
Nachrichtenpaketes. Innerhalb der Verarbeitung des Paketes durch den Manager
oder Agenten dient dieser als „Passwort“. Stimmt der Community String mit der
Konfiguration in der Empfangskomponente überein, wird das Paket angenommen.
Falls er nicht übereinstimmt, wird das Paket als nicht autorisiert verworfen.
Die Übertragung eines Paketes der SNMP Versionen 1 und 2 erfolgt unverschlüsselt
im Klartext. Einfache Spionagesoftware kann diese Pakete aus öffentlichen
Netzwerken herausfiltern. Somit sind die Daten und der Community String leicht
zugänglich. Der unerlaubte Zugriff auf Managementdaten ist möglich.
Der Mitschnitt einer SNMP Nachricht durch eine Spionagesoftware (Ethereal)1
liefert die folgende Darstellung.
1
Spionage-Software Ethereal Version 0.10.6 im Anhang auf CD zu finden
15
Anwendung des SNMP
*********************************************************************************
Version: 2C (1)
Community: PUBLIC
PDU type: RESPONSE (2)
Request Id: 0x00008966
Error Status: NO ERROR (0)
Error Index: 0
Object identifier 1: 1.3.6.1.2.1.1.3.0 (iso.3.6.1.2.1.1.3.0)
Value: Timeticks: (18581821) 2 days, 3:36:58.21
Object identifier 2: 1.3.6.1.4.1.2566.3.2.1.5.4.0 (iso.3.6.1.4.1.2566.3.2.1.5.4.0)
Value: STRING: "72,72"
Value: INTEGER: 38014000
*********************************************************************************
Diese Daten beruhen auf dem folgenden Klartext. Der Community String
„PUBLIC“ ist eindeutig zu erkennen.
*******************************************************************************°*
0000 00 02 b3 98 b6 df 00 90 b8 04 02 12 08 00 45 00 ........ ......E.
0010 00 be e9 b4 00 00 40 11 09 bd c0 a8 02 b6 c0 a8 ......@. ........
0020 02 b7 00 a1 0d 58 00 aa 00 00 30 81 9f 02 01 01 .....X.. ..0.....
0030 04 06 50 55 42 4c 49 43 a2 81 91 02 03 00 89 66 ..PUBLIC .......f
0040 02 01 00 02 01 00 30 81 83 30 10 06 08 2b 06 01 ......0. .0...+..
0050 02 01 01 03 00 43 04 01 1b 89 3d 30 16 06 0d 2b .....C.. ..=0...+
0060 06 01 04 01 94 06 03 02 01 05 04 00 04 05 37 32 ........ ......72
0070 2c 37 32 30 15 06 0d 2b 06 01 04 01 94 06 03 02 ,720...+ ........
0080 01 05 12 00 02 04 02 44 0c 30 30 14 06 0d 2b 06 .......D .00...+.
0090 01 04 01 94 06 03 02 01 05 13 00 02 03 34 ea e0 ........ .....4..
00a0 30 14 06 0d 2b 06 01 04 01 94 06 03 02 01 05 14 0...+... ........
00b0 00 02 03 02 07 88 30 14 06 0d 2b 06 01 04 01 94 ......0. ..+.....
00c0 06 03 02 01 05 06 00 02 03 34 ea e0
........ .4..
*********************************************************************************
Ohne den Einsatz von zusätzlichen Sicherheitsmechanismen sind die Versionen 1
und 2 in öffentlichen Netzwerken nicht zu empfehlen. Um die Managementdaten
der Versionen 1 und 2 bei der Übertragung zu sichern, bestehen mehrere
Möglichkeiten.
Zum einen lässt sich der gesamte SNMP Datenverkehr in physikalisch getrennte
Netzwerke verlagern. Die Daten können somit nicht außerhalb des
Managementnetzwerkes erfasst werden. Dies ist die sicherste Methode. Allerdings
müsste für diese Art des outband-Managements eine eigene Netzwerkinfrastruktur
errichtet werden. Aus Kostengründen ist dies ungünstig. Zudem muss berücksichtigt
werden, dass viele Komponenten mit nur einer Netzwerkschnittstelle ausgerüstet
sind. Über diese werden neben dem Management auch die eigentlichen
Komponentenfunktionen ausgeführt.
Eine andere Möglichkeit ist die Einrichtung gesicherter Datenkanäle für den
Transport von Managementdaten in öffentlichen Netzwerken. Die Lösung hierfür
bietet die Einrichtung von Virtual Private Networks (VPN).
Eine VPN Verbindung (VPN Tunnel genannt) ist eine statische Punkt-zu-Punkt
Verbindung in IP Netzwerken. Die Nutzdaten der Kommunikation über eine solche
16
Anwendung des SNMP
Verbindung werden verschlüsselt. Realisiert wird eine solche Verbindung mittels
Tunnelprotokollen. Einige dieser Protokolle sind L2TP (Layer 2 Tunneling
Protocol), PPTP (Point-to-Point Tunneling Protocol) und IPsec (IP Security).
IPsec ist als standardisiertes Protokoll (RFC 2401 bis 2409) integraler Bestandteil
der IPv6. Ein Einsatz in der aktuellen IPv4 ist möglich. IPsec bietet Dienste zur
Verschlüsselung und Authentifizierung der Nutzdaten eines IP Paketes, somit auch
der SNMP Daten [22]. Zur Anwendung kommen dabei die gleichen
Verschlüsselungsalgorithmen (SHA oder MD5) wie bei der SNMP Version 3. Die
Nutzung von IPsec für die SNMP Version 1 und 2 erfüllt die gleichen
Sicherheitsanforderungen wie SNMP Version 3. Der Sicherheitsaspekt wird
lediglich durch eine andere Netzwerkschicht (IP Netzwerkschicht) erfüllt.
Ein VPN Tunnel kann zwei Netzwerkkomponenten (Host-zu-Host), eine
Netzkomponente und ein Netzwerksegment (Host-zu-Gateway) oder zwei
Netzwerksegmente (Gateway-zu-Gateway) verbinden. An jedem Ende des
Verbindungstunnels muss eine entsprechende VPN-Software installiert und
konfiguriert sein. Dabei stellt ein VPN-Client eine Verbindung zum VPN-Server her
und baut den gesicherten Übertragungskanal auf. Auf diese Weise lassen sich
Netzwerkkomponenten der Versionen 1 und 2 mit Lösung der
Sicherheitsproblematik in ein Managementsystem integrieren. Allerdings bedeutet
ein VPN zusätzlichen Konfigurationsaufwand.
Bei der Sicherung von Managementdaten während des Transports ergeben sich
hierdurch zwei Lösungsansätze (siehe Abbildung 9). Zum einen SNMP Version 3.
Diese
Technologie
bietet
Datensicherheit
über
den
gesamten
Managementdatenverkehr aller Komponenten.
Abbildung 9 : Sicherheit durch SNMP Version 3 und Tunnelprotokolle
Der zweite Ansatz nutzt Tunnelprotokolle (IPsec). Die Sicherheit dieser
Übertragung beschränkt sich auf die errichtete VPN Verbindung. Einzelne Punktzu-Punkt Datenkanäle können auf diese Weise geschützt werden. Die Übertragung
von Managementdaten über ein öffentliches Backbone-Netzwerk kann so gesichert
werden.
Ein Vergleich der Sicherheitsmechanismen von SNMP Version 1 und 2 über Ipsec
und SNMP Version 3 zeigt ([23], Kapitel 3.4). Die Ergebnisse dieser Arbeit sehen
sogar einige Vorteile in der Nutzung von IPsec als Sicherheitsmechanismus für
SNMP. Einer der Vorteile ist die geringere Belastung des Netzwerkes ([23], S.61).
Zudem zeigt die Arbeit [23], dass Tunnelprotokolle für die Absicherung von SNMP
Daten der Versionen 1 und 2 genutzt werden können.
17
Anwendung des SNMP
Bei der Einführung von SNMP in die Produktionsumgebung sollte auf die
Sicherheit der SNMP Version 3 gesetzt werden. Sie gewährleistet umfassende
Sicherheitsmechanismen über die gesamte Managementkommunikation. Einzelne
unsichere Verbindungen zu Komponenten älterer SNMP Versionen oder die
Überbrückung von öffentlichen Backbone Netzen kann durch VPN Verbindungen
zusätzlich gesichert werden.
Die Verwendung von SNMP Version 3 und VPN gemeinsam bietet doppelte
Sicherheit. Im Hinblick auf Diskussionen über die tatsächliche Sicherheit der
Verschlüsselungsalgorithmen [24] ist dies eine notwendige Sicherheitsstrategie.
18
Anwendung des SNMP
3. Voraussetzungen für eine Integration von SNMP in die TV Produktion
Die Infrastruktur der heutigen TV Produktion wird sich dem IT Szenario immer
mehr annähern. Netzwerktechniken wie Fibre Chanel und Fast Ethernet werden
bereits heute in der Produktion als Transportwege eingesetzt. Weitere
Entwicklungen in Datenaustauschformaten wie MXF (Material eXchange Format)
werden diesen Trend hin zu einer vollständig digitalen und IT basierten TV
Produktion unterstützen. Der Weg zu einem vernetzten Produktionsumfeld ist
bereits absehbar. Es wird nur noch eine Frage der Zeit sein, wann der vollständige
Umstieg auf die vernetzte Produktionsumgebung vollzogen ist.
Dieser Umstieg wird die Produktionsbereiche Archiv, Redaktion, Produktion,
Editing, Senderegie und auch die jeweiligen Sendewege betreffen. Der Charakter
der jeweiligen Geräte in diesen Produktionszweigen wird sich ebenfalls maßgeblich
ändern, um die neuen Anforderungen zu erfüllen. Will man Komponenten in ein
Control und Monitoring mittels SNMP integrieren, müssen diese dem SNMP
Standard konform eingerichtet werden. Jedes einzelne Gerät muss seiner SNMP
Tauglichkeit nach überprüft werden.
3.1. Anforderungen an einzelne Komponenten durch SNMP
Ein SNMP fähiges Gerät besitzt eine Agentenimplementierung und eine
Repräsentation der Gerätefunktionalität durch die in den Agenten integrierten MIB
Module. Grundvoraussetzung ist die IP-Netzwerkfähigkeit der Komponente.
Um den SNMP Dienst eines Gerätes zu nutzen, muss der Geräteagent dem
jeweiligen IP Netzwerk entsprechend konfiguriert werden. Die Vorgehensweise ist
herstellerabhängig. Jedoch gibt es Parameter, die in jedem SNMP fähigen Gerät
einstellbar sein müssen:
-
Die IP-Adresse des Rechners, von dem SNMP Anfragen gestattet sind, muss
angegeben werden (meist die Managementstation).
Zudem sollen Zugriffsrechte (read, read+write) auf den Agenten vergeben
werden.
Festlegung der Zieladresse von Trapsendungen
Angabe des Community Strings (siehe 2.6)
Nur wenn Community String, IP Adresse und Zugriffsrechte für einen
Kommunikationspfad zwischen Gerät und Managementstation korrekt konfiguriert
sind, kann es zu einem Datenaustausch kommen.
Häufig bieten Agentenimplementierungen die Möglichkeiten an, mehrere
Empfänger zu konfigurieren. Die Einbindung in mehrere Managementstationen ist
möglich.
Diese Konfigurationsvoraussetzungen gelten für die SNMP Versionen 1 und 2. Eine
Aufstockung der Agenten zu Version 3 des SNMP ist empfehlenswert.
Eine Erweiterung der Agentenfunktionalität kann durch Installation eines
Firmwareupdates erreichet werden. Testkonfigurationen von Broadcastagenten
haben gezeigt, dass die SNMP Funktionalitäten mit der Zeit in den Geräten ergänzt
wurden. Firmwareversionen früherer Generationen unterstützten nur den SNMP
Datenaustausch. Spätere Versionen ergänzten die Agentenfunktionalität durch
19
Anwendung des SNMP
Festlegung des Trapsendepfades oder die Konfigurationsmöglichkeit von mehreren
Kommunikationspfaden.
Aus diesem Grund ist es empfehlenswert, vor jeder Agentenkonfiguration zu
überprüfen, ob die aktuelle Firmware auch dem neusten Stand entspricht.
Neben diesen grundlegenden Voraussetzungen für Geräte mit SNMP Funktionalität
ist die in dem Gerät integrierte MIB zu betrachten. Werte, die nicht in den Objekten
der MIB eines Gerätes implementiert sind, können auch nicht über die SNMP
Kommandos abgefragt oder kontrolliert werden. Funktionen, die ein Gerät in einem
Managementsystem erfüllen soll, müssen in der MIB zu finden sein.
Die IT hat in der MIB Struktur der Objektidentifier mit der MIB2 Gruppe eine
Standardvereinbarung, getroffen welche Objekte in jeden Fall in Agenten zu
implementieren sind. Diese Standardvereinbarungen sind verbindlich. Ein Gerät mit
der Funktionalität, IP Pakete zu empfangen und zu senden, muss die MIB2
Untergruppe „ip“ implementiert haben.
Eine ähnliche Vereinbarung für Geräte der Broadcastindustrie gibt es derzeit nicht.
Wünschenswert wäre eine standardisierte Untergruppe im MIB Baum für
Broadcastkomponenten. Erste Bemühungen in diesem Bereich finden statt.
Allerdings ist noch kein verbindlicher Broadcast-MIB Standard auf dem Weg.
3.1.1. Der Standardisierungsprozess von broadcastspezifischen MIB
Modulen
Die Notwendigkeit einer standardisierten MIB für Komponenten des
Broadcastbereiches ist erkannt. Einige Hersteller und Rundfunkanstalten arbeiten an
Vorschlägen zur Spezifizierung der einzelnen Bereiche. Die Konferenz
Programmverbreitung (KPV) hat die Arbeitsgruppe „Public MIB“ ins Leben
gerufen, um eine Standardisierung auf den Weg zu bringen.
Auch einige Hersteller starten Bemühungen, einen SNMP MIB Standard zu
definieren [25].
Aus einer ersten Sondierung der „Public MIB“ Gruppe entstand eine MIB Struktur,
die als Vorlage für eine generelle Broadcast-MIB dienen soll (Abbildung 10).
20
Anwendung des SNMP
*******************************************************************
irt
broadcast
transmitter
operational
maintenance
baseband
multiplexer
production
server
camera
mixer
storage
measurement
networking
OBJECT IDENTIFIER ::= { enterprises
OBJECT IDENTIFIER ::= { irt
OBJECT IDENTIFIER ::= { broadcast
OBJECT IDENTIFIER ::= { transmitter
OBJECT IDENTIFIER ::= { transmitter
OBJECT IDENTIFIER ::= { broadcast
OBJECT IDENTIFIER ::= { baseband
OBJECT IDENTIFIER ::= { production
19831}
1}
1}
1}
2}
2}
1}
2}
1}
2}
3}
4}
3}
4}
*******************************************************************
Abbildung 10 : Framework der geplanten Broadcast-MIB [26]
Diese Struktur soll nach und nach mit Standards gefüllt werden. Im Rahmen des
ersten Standardisierungsprojektes wurde das Themenfeld der DVB-T und DAB
Sender untersucht. Unter der OID 1.3.6.1.4.1.19831.1.1.1 entstand ein Vorschlag,
der als Standard für DVB-T und DAB Sender verwendet werden soll.
Zur Verifizierung der notwendigen Objekte der MIB wurden die technischen
Richtlinien TR 5/1.0, Teil 2 (Remote Control Systems), TR 5/1.1 (Reserve
Systeme), TR 5/6 (DAB-Sender) und TR 5/9 (DVB-T Sender) verwendet.
Dies führte zu einem MIB Aufbau, der die unterschiedlichen Sendertypen für DAB
und DVB-T widerspiegelt (Abbildung 11).
Abbildung 11 : Erster Vorschlag für die Standardisierung einer MIB für das Play-Out [26]
21
Anwendung des SNMP
Der wichtigste Punkt bei der MIB Standardisierung ist die Verifizierung der
relevanten Objekte. Pflichtenhefte und Standards der SMPTE, ITU oder ISO-IEC
dienen dabei als Orientierung.
Bei der Umsetzung der Standards ist der Ursprung des SNMP Modells nicht zu
vergessen. Die Untergruppen, besonders die system-Gruppe, müssen
Berücksichtigung finden. Gleiches gilt für die interface-Untergruppe sowie je nach
Vorkommen für weitere Untergruppen.
Zudem sollte überlegt werden, inwieweit IT untypische Infrastrukturen durch SNMP
mit abgedeckt werden sollen. Analog zu den Standardisierungen von IP, TCP in der
MIB2 Gruppe könnte es sinnvoll sein, SDI und SDTI MIBs zu spezifizieren. Diese
Module könnten es ermöglichen, Parameter über die Studiosignale abzufragen und
somit Diagnosehilfe bei Störungen zu bieten.
Darüber hinaus ist es sinnvoll, eine eigene Statusgruppe in einer Broadcast-MIB zu
berücksichtigen. Komponenten innerhalb eines Produktionssystems haben
unterschiedliche Statuswerte innerhalb des Produktionsworkflows. ONAir, OnAir
Bypass, standby, Preroll, off, Havarie on, je nach aktuellem Status im Workflow
können Werte des Systems unterschiedliche Wichtigkeit besitzen. Eine Komponente
ONAir hat eine höhere aktuelle Relevanz als im standby Status.
Die Auskunft über den Status innerhalb eines Produktionsprozesses kann helfen, die
Relevanz der Komponente abfragbar zu machen. Eine Applikation könnte diese
Werte permanent abfragen und somit Informationen über die Zusammensetzung des
Workflowpfades gewinnen, diesen sogar dynamisch in seiner GUI anpassen.
3.1.2. Die aktuelle Situation der MIB Implementierung
Derzeit basieren die meisten SNMP fähigen Komponenten auf MIB Modulen, die
jeder Hersteller getrennt und speziell für die eigene Produktpalette entwickelt und
integriert. File Server unterschiedlicher Hersteller verwalten unterschiedliche MIB
Module und verursachen somit unterschiedliche Repräsentationen im SNMP
Management Modell. Ein Management dieser einzelnen Komponenten ist somit
möglich. Allerdings erfordert dies eine für jedes Gerät unterschiedliche und somit
uneinheitliche Darstellung im Managementsystem. Ein Vergleich von
Managementdaten zwischen Geräten gleicher Funktionalität in der Produktion, aber
verschiedener Hersteller, ist auf diese Weise schwer zu erreichen.
Um ein Gerät in ein Managementsystem zu integrieren, muss die MIB des Gerätes
bekannt sein. Erfahrungen zeigen, dass MIB Module bei den Herstellern gezielt
angefragt werden müssen. Meist ist sie in der Dokumentation der Geräte nicht
vorhanden.
3.2. Möglichkeiten der Einbindung von Geräten ohne SNMP
Unterstützung
Weist ein Gerät eine SNMP Agenten Implementierung und die dazugehörige
Netzwerktauglichkeit auf, so ist es in ein Managementsystem zu integrieren. In
heutigen Produktionsumgebungen sind allerdings einige Geräte zu finden, die diese
Anforderungen nicht erfüllen. Es gibt Möglichkeiten, auch solche Komponenten für
ein SNMP Management nachzurüsten. Diese mögliche Nachrüstung kann mit Hilfe
22
Anwendung des SNMP
von Proxy Agenten erfolgen. Diese sind Stellvertreter für ein nicht SNMP fähiges
Gerät.
Der Proxyagent greift auf zu überwachende Werte eines Gerätes zu und transferiert
diese Daten in das SNMP Modell.
Bei der Integration von Geräten ohne SNMP Unterstützung müssen folgende Fragen
geklärt werden:
- Welche Werte sollen von einem Gerät in einem Managementsystem
erfassbar sein?
- Wie können diese Werte vom Proxy Agenten erfasst werden?
Eine mögliche Lösung bieten Rack-Monitoring Systeme (RMS). Diese RMS
sensieren Schnittstellen an den zu implementierenden Geräten und erfassen auf
diese Weise Status- und Fehlermeldungen.
Die Sendeanstalt „Rundfunk Berlin Bandenburg“ (RBB) hat bei der Einführung
eines Stör- und Fehlermanagementsystems solche Proxy-Agenten implementiert.
Die folgenden Ausführungen sollen beschreiben, wie Geräte ohne SNMP
Funktionalität in ein SNMP basiertes Managementsystem integriert werden können.
Es gibt verschiedene Hersteller, die Produkte mit Proxy Agenten anbieten.
Gemeinsam ist diesen, dass sie Parameter an Geräten abgreifen können und diese in
SNMP Nachrichten an ein Systemmanagement weiterleiten. Unterschiede treten in
der möglichen Anzahl der Überwachungsschnittstellen und in deren strukturellem
Aufbau auf.
Einige dieser RMS sind:
- Computer Multi Control-Top Concept (CMC-TC) System; dieses Produkt
stammt von der Firma Rittal GmbH & Co.KG.
- Falcon Management System, eine Lösung des Unternehmens RLE
Technologies
- Cabine Control System 20 (CCS 20) der Firma Schroff GmbH
- Active RAK Controller der Firma APW Electronics Ltd. [27]
Der Active RAK Controller (ARC) bietet eine ausreichende Funktionalität für die
Integration von Broadcastgeräten. Bei der Installation innerhalb des RBB wurde er
eingesetzt. Die Sensoren des ARC können Umgebungsbedingungen wie Temperatur
und Luftfeuchtigkeit erfassen. Zudem können Betriebszustände, etwa
Schwankungen von Spannungswerten, überwacht werden [27].
Viele Broadcastgeräte bieten Anschlussmöglichkeiten, die es erlauben,
Statusinformationen über externe Schnittstellen abzufragen. Diese Schnittstellen
können BNC, Sub-D 15-pol Buchsen, Klemmkontakte oder weitere physikalische
Kontakte sein. Die gewünschten Statusinformationen können an den Kontakten
dieser Schnittstellen abgegriffen werden.
Im Falle der Systemeinführung des RBB wurden auf diese Weise verschiedene
Kreuzschienentypen, Sendeablaufmischer und weitere Geräte der Produktion in ein
SNMP System integriert.
Der ARC muss nach dem Anschluss der Schnittstellen, die es zu überwachen gilt,
noch für das SNMP Management konfiguriert werden. Neben den allgemeinen
Netzwerkparametern müssen die SNMP Parameter gesetzt werden. Die
Einstellungen können über eine Telnet-Verbindung oder über eine serielle
23
Anwendung des SNMP
Schnittstelle (COM) vorgenommen werden. Somit ist das gesamte System über ein
Netzwerk konfigurierbar.
Die Beurteilung der abgegriffenen Werte innerhalb des ARC erfolgt durch die
Nutzung von Filtern. Diese Filter überprüfen den eingehenden Wert anhand von frei
definierbaren Schwellwerten. Es ist möglich, mehrere Eingangswerte untereinander
in Abhängigkeit zu setzen. Erkennt der Filter das Überschreiten eines Wertes, gibt er
eine Trapsendung an die konfigurierte Empfänger IP Adresse (siehe Abbildung 12).
Abbildung 12 : Nutzung des ARC als SNMP Proxy Agent2
Alle Einstellungen am ARC werden zusätzlich in einem MIB Modul abgelegt. Die
MIB ermöglicht ebenfalls den Zugriff auf einzelne Werte der Konfiguration und auf
Werte an den Eingangsschnittstellen. Somit können über das SNMP Management
jederzeit alle Parameter des ARC-Proxy Systems abgefragt werden.
Eine Lösung mit Hilfe der RMS bietet eine einfache Möglichkeit der SNMP
Überwachung von Geräten, die die Grundvoraussetzungen des SNMP nicht erfüllen.
Eine Eingliederung solcher Geräte kann allerdings nur erfolgen, falls an diesem
Gerät entsprechende Hardwareschnittstellen zur Verfügung stehen. Ist dies nicht der
Fall, bleibt nur die Möglichkeit, die gewünschten Überwachungswerte durch
zusätzlich in die Geräte integrierte Elektronik zu erhalten. Der entstehende Aufwand
ist in solch einem Fall sehr groß.
3.3. Die Nachrüstung des SNMP – Dienstes durch zusätzliche Software
In einigen Fällen kann eine Nachrüstung eines SNMP Dienstes für einzelne
Komponenten möglich sein. In solch einem Fall muss eine Agentensoftware
entwickelt werden. Diese muss auf relevante Werte der Komponente zugreifen
können. Voraussetzung für eine nachträgliche SNMP Integration sind ausreichende
Ressourcen der Komponente selber und die IP-Netzwerkfähigkeit.
Eine Nachrüstung ist Aufgabe der Hersteller der Komponenten. Eine geringfügige
Anpassung an die Bedürfnisse eines speziellen Systems lässt sich jedoch in einigen
Fällen unabhängig vom Hersteller durchführen. Denkbar ist die Nutzung einer Trap2
Teile der Abbildung 12 basieren auf [27]
24
Anwendung des SNMP
Anwendung, die bei speziellen Ereignissen eigene Traps generiert und an eine
Managerapplikation weiterleitet. Solche Möglichkeiten bieten sich hauptsächlich für
Komponenten mit zugreifbarem Betriebssystem wie etwa Windows oder Unix
basierte Komponenten.
Beispiel für eine nachträgliche SNMP Integration ist der DVQ Analyser der Firma
Rhode&Schwarz. Dort wurde basierend auf dem Befehlssatz SCPI eine
Agentenimplementierung eingeführt. Nach und nach wurden die Funktionalitäten
des SNMP Dienstes durch neue Firmwareversionen ergänzt (siehe 5.2.3).
3.4. Die Überwachung von Software mittels SNMP
Ein bisher nicht berücksichtigter Aspekt im SNMP Management ist die
Überwachung der Software einer Komponente. Im IT Bereich existieren
Agentenimplementierungen, die Werte einer Anwendersoftware beinhalten. Sowohl
die Abfrage von Softwaredaten, als auch die Alarmierung mittels Trap bei Fehlern
in der Applikation sind denkbar.
Ein Beispiel für die Überwachung einer Anwendung ist die RollMap Software
Version 1.7 von Snell&Wilcox. Von dieser Software wird später noch die Rede sein
(siehe 6.3.2). Sie beinhaltet eine Agentenimplementierung, die auf Werte der
Applikation zugreift und bei Änderungen der Parameter einen Trap an eine
übergeordnete Managementstation sendet.
Im Bereich der IT gibt es einige MIB Spezifikationen, die das Management von
Applikationen ermöglichen sollen. Einige dieser Spezifikationen sind:
-
Application Performance Measurement MIB [28]
Application Management MIB [29]
Über SNMP ist es möglich, sowohl die Hardware einer Komponente, als auch die
Software Prozesse, die auf ihr laufen, zu überwachen.
25
Anwendung des SNMP
4. Aufgaben des Managements in der TV Produktion
Management bedeutet die Führung und Überwachung von Geschäftsprozessen [30].
Dabei ist es die Aufgabe des Managements, diese Prozesse zu überwachen, zu
steuern und zu verwalten. Die Optimierung dieser Prozesse ist das Ziel des
Managements.
In der TV Produktion bedeutet dies, eine Gewährleistung des technischen Betriebs
aller Komponenten des Produktionsprozesses. Dazu gehören die Überwachung der
einzelnen Geräte und deren Verhältnisse zueinander. Eine Überwachung der
Geräteverbindungen ist ebenfalls Bestandteil des Managements.
Die Sendeanstalten betreiben einen hohen technischen Aufwand, um ein
professionelles Fernsehprogramm zu produzieren. Die technische Infrastruktur wird
dabei immer komplexer. Fehlerereignisse innerhalb des Systems lassen sich immer
schwerer lokalisieren und beheben. Dies kann zu schwerwiegenden
Produktionsausfällen führen. Aus diesem Grund müssen Wege gefunden werden,
solche Fehlerereignisse rechtzeitig zu erkennen. Im Idealfall bevor sie einen Effekt
auf den Produktionsprozess haben. Die Minimalanforderung muss allerdings eine
rechtzeitige Reaktion mit entsprechenden Havarieszenarien sein.
Um dies sicherzustellen, müssen alle Komponenten der TV Produktion auf ihre
Funktionalität gemäß ihren Aufgaben im Workflow überwacht werden. Die
Sicherstellung dieser Funktionalität ist Ziel und Sinn eines Systemmanagements.
Abbildung 13 : Kriterien für ein Systemmanagement
Die Umsetzung eines solchen Systems lässt sich als Alarm- und Frühwarnsystem
beschreiben. Dabei werden für den Systemablauf wichtige Geräteparameter
überwacht. Die Auswahl solcher charakteristischen Werte ist abhängig von den im
System befindlichen Komponenten. Dies bedarf einer Einzelfallbetrachtung für
jedes zu implementierende System. Generell lassen sich Kategorien erfassen, die für
solch ein Systemmanagement zwingend notwendig sind.
26
Anwendung des SNMP
4.1. Kriterien des Systemmanagement
Die vorangegangenen Überlegungen führen zu einigen Kriterien, die ein
Systemmanagement erfüllen sollte:
Fehlererkennung:
Kommt es in einer Komponente des Systems zu einem unregulären Verhalten, muss
dieses sofort erkannt und an eine zentrale Stelle weitergeleitet werden.
Fehlerpriorität:
Je größer das zu überwachende System ist, umso mehr Fehler können auftreten.
Dabei ist nicht jedes Fehlerereignis von gleicher Bedeutung für den
Produktionsbetrieb. Eine Einstufung der Fehler nach deren Auswirkungen auf das
Gesamtsystem ist unabdingbar. Fällt beispielsweise ein Video Server im
Sendebetrieb aus, so ist diese Nachricht von hoher Priorität. Der Ausfall
beispielsweise eines Messgerätes kann dagegen von geringerer Bedeutung sein.
Fehlerursache:
Die Nachricht eines aufgetretenen Fehlers muss Rückschlüsse auf die Ursache des
Ereignisses geben, aufgrund dessen der Fehler verursacht wurde. Es reicht nicht
mitzuteilen, dass etwas passiert ist.
Fehlermitteilung:
Ein Systemmanagement muss Möglichkeiten der Darstellung eines Fehlers und
deren Ursache sowie dessen Ort innerhalb des Systems bereitstellen. Es sollte
vielfältige Darstellungsformen geben. In Frage kommen Textmitteilungen auf
Arbeitskonsolen, e-mail Verteiler, SMS-Verteilungsmechanismen und weitere
Nachrichtensysteme.
Fehlerbehebung:
Neben der Übermittlung der Fehlerinformationen an das Managementsystem
müssen Mechanismen vorhanden sein, die eine Behebung des Fehlers ermöglichen.
Es sollten Behebungsvorschläge gemacht werden. Diese sind von den Fachkräften
vor Ort durchzuführen. In speziellen Fällen sollte eine automatische Reaktion des
Systems die Ursache des Fehlers beheben können.
Fehlerdokumentation:
Alle auftretenden Fehlerinformationen müssen für Statistik und Analyse des
Fehleraufkommens auch nach Behebung des Fehlers verfügbar sein. Die
Archivierung der bearbeiteten Fehlermeldung sollte nach Priorität und zeitlichem
Auftreten erfolgen.
Diese Kriterien beschreiben den Ablauf einer Fehlermeldung und dessen
Bearbeitung innerhalb eines Systemmanagement basierend auf SNMP. Abbildung
13 zeigt bereits, wie ein Managementsystem mit Fehlerereignissen verfahren sollte.
Anhand eines Beispiels wird nun dieser Ablaufplan näher beschrieben. Dies soll
zeigen, wie ein Systemmanagement für die TV Produktion umgesetzt werden sollte,
und welche Aufgaben es übernimmt.
Die Umgebung dieses Beispiels sei der Produktionsbereich der Sendeabwicklung
(SAW). In Abbildung 14 sind nur diejenigen Komponenten abgebildet, die zur
Veranschaulichung benötigt werden.
27
Anwendung des SNMP
Abbildung 14 : Beispiel für die Aufgabe des Systemmanagements in der TV Produktion
Der Video Server spielt eine Sendung ab, welche über die Sendekreuzschiene in den
Playout und anschließend direkt auf Sendung geht. Alle Komponenten dieser
Sendeabwicklung sind in ein Systemmanagement eingebunden und werden
permanent überwacht.
Während der Ausstrahlung des Sendesignals eines Video Servers kommt es zu
einem Systemfehler. Dieser hat zur Folge, dass das Sendesignal nicht mehr am
Ausgang des Servers anliegt. Ein Sendeausfall wäre das Resultat. An dieser Stelle
kommt das Systemmanagement zum Einsatz. Der Managementagent des Servers
erkennt den aufgetretenen Fehler und sendet eine Nachricht (Trap) an die
Managementkonsole. Hierbei gilt es zu beobachten, wie schnell die
Fehlererkennung des Systemmanagements ist und wie lange es dauert, bis eine
entsprechende Reaktion auf dieses Ereignis wirkt.
Diese Nachricht muss Informationen darüber enthalten, welches Gerät einen Fehler
aufweist, wo dieses Gerät im System zu finden ist, was für ein Fehler aufgetreten ist,
wie dieser Fehler zustande kam. Trifft die Nachricht bei der Steuerung des
Systemmanagements ein, muss diese unverzüglich ausgewertet werden. Die
Einstufung der Nachricht bezüglich ihrer Dringlichkeit steht zunächst im
Vordergrund. Hier sollten einige Kategorien vorhanden sein, die solch eine
Abstufung ermöglichen.
Die weitere Auswertung der Fehlernachricht sollte die Ursache des Fehlers klären.
Dazu können direkte Textinformationen aus der Nachricht selber dienen. Diese
Ursache sollte so genau spezifiziert werden, dass eine Behebung des
Fehlerzustandes möglich wird.
Im Falle des Video Servers beinhaltet die Nachricht die Fehlerinformation, dass der
Ausgangspuffer des Interfaces überläuft. Die Managementsteuerung stuft diese
Nachricht als sehr kritisch ein, da ein Sendeausfall die Folge wäre. Der nächste
Schritt ist die Mitteilung dieses Fehlers an eine Stelle, welche mit der
Fehlerbehandlung beginnen muss. Die Mitteilung sollte alle nötigen Informationen
28
Anwendung des SNMP
der Fehlernachricht aufweisen. Empfänger der Mitteilung können Mitarbeiter des
Systemservice sein. Diese müssen anhand der Mitteilung in der Lage sein, den
Systemfehler zu beheben.
Ein Systemmanagement sollte in der Lage sein, gewisse Fehler eigenständig
beheben zu können. Nach Auswertung der Fehlernachricht ist eine automatische
Reaktion des Managements vorstellbar. Im Beispiel aus Abbildung 14 gilt es einen
Sendeausfall zu verhindern. Das Systemmanagement ist so konfiguriert, dass es eine
automatische Fehlerbehebung vornimmt. Sie gibt einem Havariezuspieler den
Befehl zu starten. Anschließend schaltet das Managementsystem die Kreuzschiene
und gibt den Havariepfad zur Ausstrahlung frei.
Eine weitere wichtige Aufgabe des Managements ist die Dokumentation von
Fehlerereignissen. Jeder eingehende Alarm muss auch nach der Bearbeitung durch
einen Mitarbeiter oder das Management nachvollziehbar bleiben. Es muss auch
unterscheidbar sein, ob eine Alarmmeldung bereits bearbeitet ist oder nicht.
Neben den Kriterien des Fehlermanagement gibt es noch weitere Anforderungen,
die ein Systemmanagement übernehmen sollte:
Statistische Netzüberwachung:
Die Möglichkeit, Statistiken über die Produktionssystemeigenschaften zu führen, ist
ebenfalls zu berücksichtigen. Durch permanente Abfragen von Statusinformationen
über charakteristische Werte eines Systems können Auslastungsinformationen
gesammelt werden. Eine Untersuchung solcher Daten kann dazu beitragen, den
Workflow innerhalb einer Produktionskette zu optimieren.
Zentrale Managementkonsole:
Die Einführung eines Managementsystems in der Fernsehproduktion muss die
Effektivität des Gesamtsystems steigern. Die Kontrolle des Managementsystems
sollte keinen zusätzlichen Mitarbeiter binden. Es sollte viel mehr im Hintergrund
laufen und nur dann, wenn es zu Fehlern kommt, aktiv genutzt werden. Es sollte von
einem Arbeitsrechner bedient und betrieben werden können.
Erweiterbarkeit:
Eine weitere Möglichkeit, die Effizienz innerhalb einer Produktion zu steigern, ist
die
Zusammenfassung
möglichst
vieler
Teilgebiete
zu
einem
Gesamtmanagementsystem. Eine Zusammenfassung der Gebiete Archiv, Redaktion,
Produktion, Editing und Senderegie liegt auf der Hand. Eine Nutzung von SNMP als
Managementschnittstelle ermöglicht allerdings auch den Zusammenschluss von
traditioneller Informationstechnologie und Broadcasttechnologie. Switches, Router
oder Hostrechner lassen sich mittels SNMP ebenso überwachen, wie
broadcastspezifische Messgeräte, File Server oder Kreuzschienen.
Um diesen Zusammenschluss, der von vielen Sendeanstalten gesucht wird, zu
ermöglichen, ist auf eine Erweiterbarkeit der Systemmanagementlösung zu achten.
Neue Komponenten und Teilnetze sollten einfach integriert werden können. Auch
zusätzliche Funktionalitäten sollten erweiterbar sein.
Diese Anforderungen sollen in einem Systemmanagement realisiert werden. Bei der
Nutzung von SNMP als Managementschnittstelle bedarf es einer Verteilung dieser
Anforderungen auf die Modellkomponenten Agent, Manager und Applikation.
29
Anwendung des SNMP
4.2. Aufgaben des Agenten der Einzelkomponenten in der Produktion
Eine Aufgabe des Agenten liegt in der Erkennung eines Fehlerzustands. Er
überwacht charakteristische Werte des speziellen Gerätes. Erkennt der Agent einen
Fehlerzustand, sendet er eine Trap-Nachricht an die konfigurierte
Managementstation. Welche Fehlerzustände überwacht werden, ist in seiner MIB
festgelegt; ebenso der Aufbau dieser Nachricht und der Inhalt dieser. Welche
Informationen innerhalb der Trapsendung mitgeteilt werden, liegt an der
Implementierung des Agenten durch den Hersteller.
Ein Systemmanagement ist von dieser Trapimplementierung der Hersteller
abhängig. Nur solche Fehlerereignisse können erfasst werden, die durch Traps
definiert sind. Dabei ist man auf die sinnvolle Implementierung der Trapnachrichten
durch die Hersteller angewiesen.
Eine nachträgliche Konfiguration der Trapmitteilungen ist in den meisten Fällen
nicht ohne Herstellerunterstützung möglich.
Eine weitere Aufgabe des Agenten ist die Antwort auf SNMP Anfragen der
Managementstation. Der Agent verwaltet alle in dem Gerät unterstützten MIB
Module. Erfolgt eine Anfrage eines autorisierten Rechners, antwortet der Agent
entsprechend. Anfragen können dem Zweck dienen, Informationen des Gerätes für
Statistiken abzurufen oder direkte Aktivitäten des Gerätes zu erfassen. Aktuelle
Messwerte eines Messgerätes sind ein Beispiel für solche Statusabfragen.
Der SNMP Standard ermöglicht durch das „set“ Kommando eine Fernsteuerbarkeit
des Gerätes über das Managementsystem. Der Agent greift also in die Funktionalität
des Gerätes mit ein.
4.3. Aufgaben des Managers der Managementstation in der Produktion
Die Managementstation ist die Anlaufstelle für die gesamte SNMP Kommunikation
des Netzwerkes. Der SNMP Manager stellt auf dieser Seite die Kommunikation
sicher. Zudem muss er alle im Netzwerk vorkommenden MIB Module kennen.
Die durch SNMP transportierten Daten werden in der Managementstation an eine
höher liegende Softwarestruktur weitergeleitet (siehe Abbildung 15). Diese
Softwarestruktur bietet neben einer GUI (Graphical User Interface) alle weiteren
Funktionalitäten, um SNMP für eine Systemmanagementanwendung nutzen zu
können.
Als Bindeglied zwischen Anwendung und SNMP Manager dient dabei eine SNMP
API. Bei der Programmierung von Managementanwendungen können
unterschiedliche API zum Einsatz kommen. Einige dieser Programmierschnittstellen
sind:
- WinSNMP3 ist die SNMP API der Windows Betriebssysteme
- SNMP Research International Inc.4 ist eine Plattform unabhängige SNMP
API
- Net-snmp5 ist eine Softwareumgebung zur Erzeugung von eigenständigen
SNMP Lösungen
3
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/snmp/snmp/winsnmp_api.asp
http://www.snmp.com/products/alphaprod.html
5
www.net-snmp.sourceforge.net/
4
30
Anwendung des SNMP
Abbildung 15 : SNMP Manager und die Managementapplikation
4.4. Aufgaben der Systemmanagement – Applikation:
Die Management-Applikation setzt auf den SNMP Manager der Managementstation
auf (Abbildung 15). Die Applikation kommuniziert über den Manager mit den
Komponenten. Sie bildet die Schnittstelle zwischen SNMP Management und
Systemadministrator oder Ingenieur vom Dienst. Sie muss die Anforderungen des
gesamten Systemmanagements abbilden.
In der täglichen Arbeit ist die Systemmanagement-Applikation das Instrument, mit
dem Überwachungs- (Monitoring) und Kontrollaufgaben (Control) bearbeitet
werden. Aus diesem Grund müssen ergonomische Aspekte wie Übersichtlichkeit
und Handhabungsfreundlichkeit durch die GUI der Systemmanagement-Applikation
berücksichtigt werden.
Weitere Anforderungen an eine Management-Applikation lassen sich in
verschiedene Teile gliedern:
Monitoring:
Die Umgebung zukünftiger TV Produktionsplattformen wird eine Verbindung aus
traditioneller Broadcasttechnologie und Informationstechnologie darstellen.
Applikationen eines Systemmanagement müssen in der Lage sein, Daten beider
Technologien zu erfassen.
Wichtig für die Bedienung der Applikation ist die grafische Repräsentation des zu
überwachenden Systems. Es müssen alle Komponenten sowie deren Verbindung
untereinander darstellbar sein. Eine Nachbildung der reellen Standortverteilung des
Netzes durch die Applikation ist wünschenswert. So lassen sich einzelne Geräte
schneller in einem unter Umständen weit verteilten Netz lokalisieren. Zudem bietet
dies ergonomische Vorteile. Eine Einbindung von Gebäude-, Stadtplänen und
Landkarten hilft Konfigurationsparameter wie Standort oder Erreichbarkeit schnell
31
Anwendung des SNMP
zu vermitteln. Eine hierarchische Struktur der Benutzeroberfläche kann diese
Informationen unterstützen. Vorstellbar ist eine Darstellungsstruktur, bei der
innerhalb eines Produktionshauses eine Managementkonsole für die gesamte
technische Überwachung zuständig ist. Der zuständige Systemadministrator erhält
eine allgemeine Darstellung der einzelnen Produktionsstätten im Haus (Abbildung
16).
Abbildung 16 : Muster der Hierarchiegliederung für die Managementapplikation6
Eine hierarchische Gliederung muss es ermöglichen, die einzelnen Komponenten
der jeweiligen Produktionsumgebung über beispielsweise eine Raumdarstellung bis
hin zu den einzelnen Geräten darzustellen. In der Darstellung der einzelnen Geräte
sollten Statusinformationen abrufbar sein.
Die wichtigste Aufgabe eines Managementsystems liegt in der Erkennung von
Fehlern. Neben den bereits erwähnten Fehlerkriterien ist es eine wesentliche
Aufgabe einer Applikation, diese Fehler auf einer Konsole klar sichtbar zu machen.
Ein Mitarbeiter muss sofort mitbekommen, dass ein Fehler aufgetreten ist.
Blinkende Signalisierungen, sich öffnende Fenster auf einem Arbeitsrechner, Tonoder Sprachmitteilungen müssen in der Applikation den jeweiligen Prioritäten
entsprechend konfigurierbar sein. Zudem müssen Informationen über den Fehlertyp
direkt abrufbar sein und eventuelle Lösungen angeboten werden. Im Idealfall sollte
die Applikation durch automatische Reaktion auf den Fehler reagieren können.
6
Teile der Abbildung 16 basieren auf einer Grafik von „http://www.chemie.tumuenchen.de/common/grafik/chemiew1.gif“
32
Anwendung des SNMP
Das Nachvollziehen des Fehlerursprungs auf einer hierarchischen GUI kann helfen,
Fehler schneller einzugrenzen und zu beheben.
Controlling:
Neben der Darstellung eines zu überwachenden Systems muss die Applikation ein
Eingreifen in einzelne Funktionen der Komponenten ermöglichen. Ein Controlling
erlaubt eine aktive Beeinflussung der Systemcharakteristik. In der GeräteHierarchieebene (Abbildung 16) sollten die wichtigsten Gerätefunktionen nicht nur
abgefragt werden können. Das Set Kommando des SNMP erlaubt die Veränderung
einzelner Gerätewerte. Im GUI der Applikation ist eine Nachbildung der
Einstellungsparameter sinnvoll. Eine Fernsteuerbarkeit ist denkbar.
Vorteil einer solchen Controllingfunktion ist die schnelle Reaktionsmöglichkeit
eines Anwenders auf Änderungen im System.
Die Fernsteuerbarkeit eines Gerätes mittels SNMP wird durch die MIB
Implementierung begrenzt. Nur Funktionalitäten, die in Objekten mit WRITE Status
implementiert werden, sind hierfür nutzbar.
Eine direkte Einbindung von Controlling-Funktionalität in die GUI der
Managementapplikation stößt schnell an seine Grenzen. Umfangreiche
Komponenten können in ihrem MIB Modul weit über 1000 einzelne Objekte
enthalten. Möchte man solch eine Komponente umfassend darstellen, entstehen sehr
viele Darstellungsebenen, die für einen Anwender schnell unübersichtlich werden.
Ein „Plug-In“ Mechanismus für komplexe Komponenten erscheint sinnvoll.
Entweder kann dies durch Oberflächen gelöst werden, die von den Herstellern oder
Produktionshäusern speziell für die Applikation entwickelt werden, oder über
Querverweise, die innerhalb der Software zum Beispiel VNC- oder Telnet-Dienste
abrufen.
Schnelle Reaktionsfähigkeit:
Bei der Erkennung von Fehlerzuständen spielt die Verzögerung zwischen
Fehlererkennung
und
Fehlermitteilung
eine
wesentliche
Rolle.
Managementinformationen sollten in Echtzeit übertragen und über die Applikation
dargestellt werden. Bei zu großen Verzögerungen besteht die Gefahr,
Systemreaktionen nicht rechtzeitig ausführen zu können.
Offene Struktur:
In Sendeanstalten besteht die technische Infrastruktur aus Komponenten
unterschiedlicher Hersteller. Eine Systemmanagement-Applikation muss alle diese
Komponenten herstellerunabhängig erfassen. Diese Forderung nach einer offenen
Struktur
ist
maßgebend
für
eine
Anwendung
innerhalb
einer
Fernsehproduktionsumgebung.
Die Applikation muss es ermöglichen, entweder durch eine offene API oder durch
direkte Einbindung von Komponenten in der GUI diese Offenheit bereit zu stellen.
33
Anwendung des SNMP
Statistik:
Eine Analyse von langfristig im Managementsystem gesammelter Daten ist eine
weitere Anforderung an die Applikation. Es sollten alle im System enthaltenen
Objekte dokumentierbar sein.
Für das Management wichtige Werte sollten in einer Datenbank abgelegt werden
können. Die Applikation sollte Möglichkeiten der Darstellung dieser Daten
bereitstellen. Tabellen, Diagramme und Anzeigen sollten inhaltlich frei
konfigurierbar und über das GUI aufrufbar sein.
Web-based Management:
Denkbar ist ein Szenario, in dem ein Mitarbeiter im Haus unterwegs ist und
Informationen von der Managementstation benötigt. An einem entfernten Rechner
könnte er über das Netzwerk mit der Managementstation Kontakt aufnehmen und
die gewünschten Informationen abfragen. Um diese Funktionalität zu ermöglichen,
muss die Applikation eine Web-based Management Strategie unterstützen.
Um zu verhindern, dass diese Web-based Dienste von Fremden genutzt werden
können, bedarf es einer ausreichenden Sicherheitsstrategie. Die Zugriffsrechte auf
die Daten der Managementstation müssen hierarchisch verteilt werden können.
Fehlerkorrelation:
Bei der Bearbeitung von Fehlermeldungen durch die Managementsoftware muss es
möglich sein, eingehende Fehlerereignisse untereinander in Beziehung zu setzen.
Ein Zusammentreffen mehrerer Fehlermeldungen kann ein Anzeichen für ein
Fehlerereignis sein, welches nicht durch die einzelnen Trapsendungen beschrieben
wird.
Die Anforderungen der Abschnitte 3 und 4 sollen als Beurteilungskriterium für
Systemmanagement-Applikationen dienen.
4.5. Bestehende Systemmanagementlösungen
Sowohl Hersteller aus dem Bereich der Informationstechnik als auch der
Broadcastindustrie haben Lösungen für Systemmanagement auf Basis des SNMP
entwickelt.
Bereits 1990 gab es Bemühungen im informationstechnischen Bereich, SNMP als
Standard des Systemmanagements zu entwickeln. Erste Produkte entstanden bereits
während der Standardisierungsphase von SNMP. Systemmanagementprodukte der
IT haben sich seit dem weiterentwickelt und hatten genügend Zeit im Markt
ausreichend getestet zu werden.
In der Broadcastindustrie gewann das Thema SNMP erst in den letzten Jahren an
Bedeutung. Monitoring- und Control-Anwendungen, die die Funktionalität von
SNMP nutzen, sind neueren Datums. Eine ausreichende Testphase in der Praxis
können diese Produkte meist nicht aufweisen.
Systemmanagementprodukte der Broadcasthersteller und der IT müssen bezüglich
ihren Möglichkeiten untersucht und vergleichend betrachtet werden. Dieser
34
Anwendung des SNMP
Vergleich soll Aufschluss über die Einsatzmöglichkeiten der Produkte in der
vernetzten Produktionsumgebung geben.
Zunächst muss die Frage geklärt werden, welche Anwendungen gibt es aus diesen
beiden Bereichen.
4.5.1. Eine Auswahl von Systemmanagement-Applikationen
Zunächst wird ein Blick auf Systemmanagement-Applikationen der IT geworfen.
Unter www.snmplink.org ist ein kleiner aber durchaus repräsentativer Überblick der
Management Applikationen der IT zu finden. Bei der Suche nach SNMPApplikationen wird man schnell fündig. Allerdings gibt es nur einen kleinen Kreis
von professionellen Systemmanagementprodukten, die für einen Einsatz in der TV
Produktion in Frage kommen.
IBM Tivoli Netview: [31]
Die Software IBM Tivoli Enterprise Console aus dem Hause IBM ist eine Systemund Netzwerkmanagementlösung für Anforderungen von Mittelstands- und
Grossunternehmen. Eine modulare Softwarearchitektur bietet eine flexible
Anpassung des Managements an spezifische Anforderungen. Das Grundgerüst bietet
das Netview-Programm. Dieses kann durch zusätzliche Produkte der Tivolifamilie
erweitert werden. Die so entstehende Anwendung deckt unter anderem die Gebiete
der
Netzwerkkontrolle,
Inventarisierung,
Softwareverteilung
und
Benutzerverwaltung ab.
Das Unternehmen Tivoli ist seit 1996 Tochterfirma des IBM Konzerns. Auf dem
Gebiet des System- und Netzwerkmanagement ist Tivoli mit seiner Produktpalette
zu den Marktführern der IT zu zählen.
Hewlett Packard – Openview Network Node Manager: [32]
Hewlett Packard ist auf dem Markt für Systemmanagementapplikationen mit seinem
Produkt Openview Network Node Manager vertreten. Es zählt in der IT zu den
Produkten mit der größten Verbreitung. Openview setzt ebenfalls auf eine offene
Softwarestruktur.
Einige Sendeanstalten nutzen in ihrer IT Abteilung bereits Openview. Die Software
und das nötige Know-how sind also in einigen Fällen vorhanden. Aus diesem Grund
wird Openview später verwendet, um exemplarisch die Möglichkeiten einer
Systemmanagementanwendung aus der IT aufzuzeigen.
Neben diesen beiden Produkten gibt es noch weitere Applikationen, die bei einer
Darstellung des Systemmanagementangebotes aus der IT nicht unerwähnt bleiben
dürfen:
-
Das Unternehmen Computer Associates mit seinem Produkt „Unicenter“
[33]
BMC Software, Inc. bietet die Managementplattform PATROL®
35
Anwendung des SNMP
Die Broadcastindustrie bietet ebenfalls eine immer größer werdenden Palette von
Systemmanagement-Applikationen an. Die verschiedenen Hersteller erweitern die
Funktionalität ihrer Applikationen fortlaufend.
NetCentral von Thomson Grass Valley:
Die
Netcentral
Software
[34]
stellt
die
Managementlösung
für
Broadcastkomponenten des Unternehmens Thomson Grass Valley. Mit dieser
Software soll es möglich werden, Broadcast Equipment über IP Netze zu
überwachen. Diese Applikation ist grundsätzlich auf das Management von
Komponenten der Grass Valley Produktpalette ausgelegt. Neue Versionen der
Software sollen allerdings Komponenten von fremden Herstellern integrieren
können.
Der Datenaustausch von Komponente zu Managementstation basiert auf SNMP.
NetCentral wird als Beispiel für SNMP basierte Management Applikationen aus der
Broadcastindustrie betrachtet.
Harris Broadcast Manager von Harris Corporation:
Harris Corporation ist ein Unternehmen aus den Vereinigten Staaten
(www.broadcast.harris.com) mit umfangreichen Geschäftsfeldern auf dem Gebiet
der Kommunikationstechnik. Im Sektor der Broadcastindustrie wurde die
Managementlösung Harris Broadcast Manager (HBM) eingeführt. Auch diese
Applikation basiert auf dem SNMP Management Modell. Das Management umfasst
Komponenten der Harris Produktpalette sowie Möglichkeiten zur Integration von
Drittherstellern.
RollSNMP/RollCall/RollMap von Snell&Wilcox:
Auch aus dem Hause Snell&Wilcox Electronic Consultants Ltd. existiert ein Ansatz
für Control und Monitoring-Lösungen. RollCall und RollMap sind aufeinander
abgestimmte Softwaremodule. Sie ermöglichen die Überwachung und Steuerung
von Broadcastkomponenten in einer RS422/RS485 Umgebung. RollMap ist dabei
die graphische Oberfläche zur Steuerung der Managementfunktionen. Durch die
Erweiterung mit RollSNMP sollen auch Komponenten mittels SNMP in das
Management eingebunden werden können.
Openbroadcast von dimetis:
Eine weitere Lösung für die Problemstellungen des Controlling und Monitoring
entspringt dem Hause Dimetis [35]. Das Unternehmen stellt mit der Produktpalette
OpenPlatform Möglichkeiten bereit, Broadcastumgebungen in ein SNMP basiertes
Management zu integrieren. Dimetis entwickelt dabei für spezielle Szenarien
eigenen Applikationen.
36
Anwendung des SNMP
5. Die Testbedingungen für Management-Applikationen
Aus der vorigen Aufzählung von Systemmanagement-Applikationen werden einige
in einem Testnetzwerk installiert. Im Rahmen dieser Installation wird gezeigt, was
diese Applikationen leisten können und wo Schwierigkeiten aufgetreten sind.
Bei den Testinstallationen werden einzelne Broadcastkomponenten in die
Überwachung und Kontrolle der Management-Applikation eingebunden. Die
Überwachung eines kompletten Produktionsumfeldes durch diese Applikationen
kann nicht simuliert werden.
5.1. Die Testumgebung für das Systemmanagement
Abbildung 17 : Die Struktur des Testnetzwerks
Bei der Auswahl eines geeigneten Testnetzes wurde besonderer Wert auf die
Koexistenz von IT und Broadcasttechnologie gelegt. Neben einigen typischen
Broadcastgeräten kommen in den Netzen ebenfalls PC’s und Druckergeräte vor. Zur
Darstellung der Möglichkeiten der Applikationen standen 2 Netzwerke zur
Verfügung. Die genutzten Segmente innerhalb dieser Netze sind in Abbildung 17 rot
hinterlegt.
Das Hausnetz des IRT unterteilt sich in mehrere Netzwerksegmente (Abbildung 17).
Neben den physikalischen Netzwerksegmenten 1, 2 und 4 besteht diese Netzstruktur
aus weiteren virtuellen Netzwerken. Im Rahmen der Testinstallationen wird das
physikalische Netzwerk genutzt.
Die gesamte Verbindungsstruktur dieses statischen Intranets ist durch Switches
realisiert. Die Verbindung des Intranets zu den Außennetzen des WWW oder des
Hybnet wird durch einen zentralen Router mit nachfolgender Firewall ermöglicht.
Das zweite Testnetzwerk ist in einer SAN-Struktur integriert. Es ist physikalisch
vom Hausnetz getrennt und dient als Konfigurationsnetzwerk für die SANKomponenten.
37
Anwendung des SNMP
Das Konfigurationsnetz des Storage-Area-Network (SAN):
Ein SAN ist ein Speichernetzwerk. Es erlaubt den schnellen Austausch von großen
Datenmengen.
Ein
SAN
Netzwerk
verknüpft
unterschiedliche
Datenspeichersysteme zu einem gemeinsamen zentralen Massenspeicher.
Die Massenspeicher untereinander werden durch Fibre Channel (FC) Verbindungen
miteinander vernetzt. Die Verbindungen der Speicher zu den vorgelagerten Servern
sind ebenfalls durch Fibre Channel realisiert. Die Server agieren als Gateway
zwischen FC und nachfolgender Netzwerktechnologie.
In der digitalen Fernsehproduktion sind SAN Netzwerke nach dem Beispiel in
Abbildung 18 bereits im Einsatz.
Abbildung 18 : SAN-Architektur in der IT basierten TV Produktion
Das Konfigurationsnetzwerk der SAN-Komponenten ist durch Fast Ethernet
realisiert. Sämtliche Komponenten sind über dieses Netzwerk des IP Segments
192.168.212.* miteinander verbunden. In diese Struktur wurde das SNMP Test
Device AVDC 100 eingebunden. Darüber hinaus besitzen die SAN-Server sowie
der FC Switch SNMP Funktionalität.
Innerhalb dieses Netzwerkes werden lediglich wenige Konfigurationsdaten
ausgetauscht. Der Datentransfer einer Management Applikation kann in diesem
Netzwerk analysiert werden. Dies beinhaltet SNMP Daten und andere
Kommunikationsprotokolle, die eine Applikation nutzt.
Einzelne Komponenten des SAN sind neben den Schnittstellen für das
Konfigurationsnetz und das Fibre Channel noch mit einer Netzwerkverbindung zum
Hausnetz ausgestattet. Die SAN-Server 1 und 2 sind in das Hausnetzsegment
192.168.1.* eingebunden.
Den Aufbau dieses Testnetzes beschreibt Abbildung 19.
38
Anwendung des SNMP
Abbildung 19 : Das Konfigurationsnetz
Das IRT Hausnetz:
Es ist eine heterogene Umgebung, in der unterschiedliche Netzwerkkomponenten
eingebunden sind. Neben herkömmlichen IT Devices, wie Druckern und
Arbeitsrechnern, finden sich einige Broadcastgeräte mit einem Anschluss an das
Hausnetz. Die einzelnen Broadcastkomponenten bilden keine schlüsselfertige
Produktionsumgebung. Eher ist dieses Netz als ein Zusammenschluss verschiedener
voneinander unabhängiger Komponenten zu sehen. Die Überwachung eines
kompletten Workflows einer Produktion ist in diesem Netz nicht möglich.
Das Hausnetz ist ein gutes Beispiel für mit der Zeit gewachsene IT-Strukturen
innerhalb eines Unternehmens und für die Technologiesymbiose zwischen IT und
Broadcast innerhalb eines Fernsehproduktionshauses. Für die Beurteilung von
Management-Applikationen in größeren Strukturen ist dies eine passende
Umgebung. Abbildung 20 gibt einen Überblick dieser Netzstruktur.
In diese Netzstruktur werden ausgewählte SNMP-fähige Broadcastkomponenten
eingegliedert und über die zu beurteilende Applikation in ein Management
integriert. Diese Komponenten sind der Video Server PVS 1000 von Grass Valley
[36] und das Analysegerät DVQ von Rohde&Schwarz [37].
39
Anwendung des SNMP
Abbildung 20 : Ein Überblick über das Testsegment des Hausnetzes
Beide Geräte sind in eine voneinander getrennte Produktionsumgebung
eingegliedert. Der Profile XP ist ein Video Server in einem im Aufbau befindlichen
digitalen Produktionsstudio. Er ist im Netzsegment 192.168.1.* installiert. Das DVQ
ist in eine Empfangskette von digitalen Fernsehtransportströmen integriert. Er
gehört dem Netzsegment 192.168.2.* an.
Die Verbindung dieser Testnetze mit dem Rechner, auf welchem die
Systemmanagementapplikationen installiert werden, wurde durch jeweils eigene
Netzwerkkarten und Verbindungen zu unterschiedlichen Switches realisiert.
5.2. Die Geräte der Testumgebung und ihre Möglichkeiten
Die oben aufgeführten Testumgebungen beinhalten Geräte mit SNMP
Funktionalität. Einige davon werden über die Testnetzwerke in SystemmanagementApplikationen eingebunden. Bevor eine Integration in ein Systemmanagement
erfolgen kann, muss die Funktion der Geräte und ihre Arbeitsweise diskutiert
werden.
Die MIB Module der Testkomponenten sind über die Anleitung in Anhang B-2 zu
finden.
5.2.1. Der Audio and Video Delay Corrector 100 (AVDC)
Der AVDC 100 ist ein Gerät der Firma Tektronix. Die Aufgabe des AVDC 100 ist
die Überwachung und Behebung von zeitlichen Verzögerungen (Delay) zwischen
Audio- und Videosignal des SDI Signalstroms. Die Nutzung des Gerätes in der
Signalkette der TV-Produktion behebt sowohl statische als auch variable auftretende
Lippensynchronisierungsfehler innerhalb des Fernsehsignals. Der Video-Audio
Delay
resultiert
in
der
Fernsehproduktion
aus
unterschiedlichen
Signalverarbeitungswegen der beiden Signale.
40
Anwendung des SNMP
Der AVDC fügt dem SDI Video-Signal ein digitales Wasserzeichen hinzu. Dieses
Wasserzeichen erlaubt eine Aussage über den zeitlichen Bezug von Video- und
Audio-Signal. Hat ein AVDC dieses Wasserzeichen einmal in ein Videosignal
eingefügt, kann ein Delay durch einen weiteren AVDC jederzeit behoben werden.
Die Bearbeitung zur Synchronisierung erfolgt im AVDC automatisch und in
Echtzeit. Abbildung 21 zeigt die Grundzüge dieser Delay-Korrekturtechnik.
Abbildung 21 : AVDC 100 Wasserzeichentechnik
Für
die
Behebung
von
Lippensynchronisierungsfehlern
in
einem
Produktionssignalpfad sind zwei AVDC nötig. Der erste wird im Encoder Modus
betrieben und fügt dem Videosignal das Wasserzeichen hinzu. Der zweite mit der
Einstellung Decoder liest dieses und prüft, ob ein Zeitversatz aufgetreten ist und
behebt diesen.
Der AVDC ist über eine Ethernetschnittstelle in ein Netzwerk integrierbar. Über
diese Schnittstelle kann der in diesem Gerät integrierte SNMP Dienst angesprochen
werden. Die Implementierung unterstützt die SNMP Versionen 1 und 2.
MIB Module des AVDC 100:
Die Funktionalität des Gerätes ist über das MIB Modul ADVC100-MIB (Anhang A2) im SNMP Dienst abgebildet. Weitere MIB-Module, beispielsweise die MIB2
Gruppe, sind nicht implementiert. Der Objektidentifikator des AVDC Moduls lautet
1.3.6.1.4.1.128.5.1.6.*. Die Untergruppen platzieren sich den Vereinbarungen des
MIB Baums entsprechend unterhalb dieser Zahlenkennung (Abbildung 22).
Datentypen:
Das MIB Modul nutzt die vier Datentypen Object-Type, IpAddress, Trap-Type und
DisplayString. Diese vier sind durch den SNMP-Standard in den jeweiligen RFC
definiert. Eigene Datentypen werden nicht spezifiziert.
Die einzelnen Objekte:
Das AVDC MIB Modul beinhaltet die Gruppen mode, status, config sowie einige
Trapdefinitionen. Innerhalb dieser Gruppen bilden die MIB Objekte die gleichen
Bedienmöglichkeiten ab, die am Gerät selber vorgenommen werden können. Eine
genaue Zusammenstellung der einzelnen MIB Objekte, der definierten
Trapsendungen und deren Bedeutung sind im Anhang B-1 zu finden.
Für die Einbindung des AVDC 100 in ein SNMP Managementsystem ist eine
genaue Beschreibung des MIB Moduls notwendig. An dieser Stelle wird nun ein
kurzer Blick auf die einzelnen MIB Gruppen geworfen. Bei der Analyse ist
41
Anwendung des SNMP
zwischen Objekten mit Monitoring und Controlling Funktionalität zu unterscheiden.
Hieraus ergeben sich die konkreten Anforderungen des AVDC an eine
Systemmanagementstation.
Abbildung 22 : Positionen der Untergruppen in der AVDC MIB (Screenshot von Programm MG-Soft
MIB Browser, Anhang CD\MG-Soft)
Monitoring:
Zur Überwachung der Funktionen des Gerätes sollten durch die MonitoringMöglichkeiten der Applikation die folgenden MIB Objekte darstellbar sein.
In der Status-Gruppe werden Statusinformationen über SDI, AES, TimcodeReceiver sowie den SDI Deserializer angezeigt. Das mesasuredAudiodelay Objekt
(OID 1.3.6.1.4.1.128.5.1.6.2.13) gibt den Messwert des A/V Delays an, welcher
aktuell im Decoder Modus gemessen wird. Das currentAudioDelay-Objekt (OID
1.3.6.1.4.1.128.5.1.6.2.12) zeigt den Zeitwert an, mit dem das SDI/AES Signal
zeitlich korrigiert wird. Alle Objekte dieser Gruppe können lediglich ausgelesen
werden. Für ein Monitoring ist dies ausreichend.
Controlling:
Die Kontrolle und Konfiguration des Gerätes wird durch die folgenden MIB
Objekte möglich.
Die mode Gruppe ermöglicht, je nach Position des Gerätes im Signalweg der
Produktion, die Einstellung des Modus. Es werden drei Modi unterstützt: Decoder,
Encoder und Bypass.
42
Anwendung des SNMP
Die restlichen Gruppen geben Auskunft über die Funktion des Gerätes. Sie
überwachen den Betrieb. Die config Gruppe ist in die Untergruppen encoder,
decoder, network, remote control, serial port und allsettings unterteilt. Alle Objekte
dieser Gruppen sind mit Lese- und Schreib-Zugriffsrechten versehen. Durch diese
Objekte wird der AVDC über SNMP konfigurierbar. Sie bilden die ControllingMöglichkeiten des Gerätes durch eine Managementstation.
In der encoder Gruppe können Einstellungen vorgenommen werden, die bei der
Erzeugung des Wasserzeichens notwendig sind. Die decoder Gruppe konfiguriert
das Verhalten des AVDC bei der Korrektur auftretender A/V Delays.
Die network Gruppe beinhaltet alle Einstellungen, die für eine Kommunikation
mittels Netzwerkverbindung notwendig sind. Unter anderem die IP und Gateway
Adresse sowie die Subnetmask werden hier abruf- und einstellbar.
Für den SNMP Dienst ist die remote control Gruppe sehr wichtig. In ihr werden
Community String und Trap-Adresse eingestellt. Im Falle des AVDC lassen sich
lediglich Grossbuchstaben für den Community String anwenden.
Die Gruppe serial port ermöglicht es Einstellungen an der RS-232 Schnittstelle
vorzunehmen. Durch die allsettings Gruppe lassen sich vorgenommen Einstellungen
speichern.
Problemspezifische Anforderungen:
In der AVDC-MIB werden 8 Trapsendungen festgelegt. Die Auslöseereignisse
dieser Traps sind fest definiert. Sie melden sobald sich Parameter des SDI Signals
oder der Wasserzeichengenerierung ändern. Eine Beschreibung dieser Traps ist in
Anhang B-1 zu finden. Die Messwerte des A/V Delays lösen keinen Trap aus. Auch
ist der AVDC nicht in der Lage, Messungen dieses Delays über längere Zeit zu
speichern. Bei der Sendung eines Traps kann es allerdings interessant sein, wie sich
diese Messwerte einige Zeit vor dem Fehlerereignis verhalten haben. Solch eine
Aufgabe kann die Managementstation übernehmen, die Messwerte über einen
längeren Zeitraum sammelt und bei Fehlerereignissen abrufbar macht.
Auch der Inhalt der Sendungen ist nicht einstellbar. Das Systemmanagement muss
sich bei der Erkennung von Fehlzuständen des Gerätes auf diese Sendungen
verlassen.
Eine Analyse der im Gerät implementierten MIB Module ergibt ein Control und
Monitoring Konzept für die Integration in ein Systemmanagement. Daneben
ergeben sich weitere Aufgaben aus dem Betrieb des Gerätes, wie im Falle des
AVDC die Langzeitmesswertanalyse. Eine ähnliche Vorgehensweise muss für jedes
Gerät vollzogen werden, welches in ein Systemmanagement integriert werden soll.
5.2.2. Der Profile XP Media Platform PVS 1000
Der Profile XP ist ein Produkt aus dem Hause Thomson Grass Valley. Im Bereich
der professionellen Broadcasthersteller gehört Grass Valley zu den etablierten
Anbietern.
Die Profile XP Plattform [36] ist ein System zur Speicherung und Bearbeitung von
digitalen Video- und Tonsignalen für den professionellen Rundfunkbetrieb. Seine
Möglichkeiten reichen von einem digitalen Plattenrecorder bis zur Einbindung als
Video Server in ein großes Broadcastnetzwerk.
43
Anwendung des SNMP
Der Aufbau des Profile XP unterteilt sich in drei Blöcke. Abbildung 23 zeigt diese
einzelnen Blöcke und deren Anbindung an das Gesamtsystem des Profile XP. Die
einzelnen Blöcke sind über einen internen PCI Bus miteinander verbunden.
Abbildung 23 : Signalblockplan des Profile XP7
Den ersten Block bildet das Echtzeitsystem. Es kontrolliert alle Ein- und Ausgänge
des Profile und regelt die Signalverarbeitung der Video-, Audio- und TimecodeDaten. Die Kontrolle über dieses Echtzeitsystem übernimmt das
Applikationssystem. Dies ist der zweite Block und basiert auf Windows NT
Anwendungen.
Der dritte Block stellt den Speicher für Video-, Audio- und Timecodedaten zur
Verfügung. Eine erweiterbare RAID Level 3 Plattenanordnung und Fibre Channel
Anbindungen garantieren den Play-in und Play-out auf das Speichersystem.
MIB Module des Profile XP:
Der Profile XP beinhaltet einen SNMP Agentendienst. Über die
Ethernetschnittstelle des Applikationssystems ist dieser über die SNMP Versionen 1
und 2 ansprechbar. Der SNMP Dienst verwaltet verschiedene MIB Module. Die
MIB2 Gruppe ist mit den Untergruppen system, interface, at, ip, icmp, tcp und udp
implementiert. Diese Untergruppen dokumentieren den Datenaustausch der
Netzwerkschnittstelle des Applikationssystems. Mit der Funktion der Komponente
als Video Server haben diese nichts zu tun.
Die Funktionen des Video Servers werden über zusätzliche Module dargestellt. Die
Grass Valley MIB Module gvgRegistration, gvgVideoStorage, gvgElementMIB
sind für die Server der Profile XP Familie vorgesehen [B-2]. Der OID’s der Grass
Valley MIB Module sind unter dem enterprise Zweig der Nummer 4947 abgelegt.
7
Abbildung 23 basiert auf [44] S.30
44
Anwendung des SNMP
Die gvgRegistration Gruppe bildet das strukturelle Grundgerüst aller Grass Valley
MIB Module. In diese Struktur werden dann die jeweiligen Gruppen der
gvgVideoStorage- und gvgElement-MIB eingebunden. Abbildung 24 zeigt den MIB
Aufbau des Profile XP PVS 1000 mit den jeweiligen Untergruppen.
Abbildung 24 : Die Broadcast MIB Module des Profile XP (Screenshot von Programm MG-Soft
MIB Browser, Anhang CD\MG-Soft)
Die vom Profile XP unterstützten MIB Module sind sehr umfangreich. Bei der
Integration dieser Module in ein Systemmanagement ist es von großer Bedeutung,
Inhalt und Aufgabenbereich der einzelnen Untergruppen herauszustellen. Eine
Betrachtung der einzelnen Untergruppen bezüglich Monitoring und Controlling ist
notwendig.
Hilfreich bei einer Aufteilung der Objekte nach Controlling und Monitoring
Aspekten ist wieder die Beachtung der Zugriffsrechte der einzelnen Objekte. Die
gvgElement-MIB ist für die Überwachung der Signaleingänge verantwortlich.
Ändert sich der Signalstatus an einem Eingang des Profile XP, wird ein Trap
gesendet. Die Objekte dieser MIB dokumentieren den aktuellen Status der
Eingangssignale.
Eine genaue Betrachtung der MIB Module des Profile XP wird nun am Beispiel des
gvgVideoStorage Moduls erfolgen.
45
Anwendung des SNMP
Datentypen:
Insgesamt nutzt die Profile-MIB sieben unterschiedliche Datentypen aus der
SNMP–Standardisierung, dies sind Integer32, Timeticks, Gauge32, ipAddress,
DisplayString, PhysAddress. Aus der gvgRegistration–MIB kommt der Datentyp
gvgVideoStorage hinzu. Dieser bildet im MIB Baum den Knotenpunkt, unter
welchem diese MIB abgelegt wird.
Monitoring des Profile XP:
Aufgrund der Größe der MIB Module des Profile XP werden an dieser Stelle
lediglich die MIB Untergruppen genannt, die Monitoring Eigenschaften beinhalten.
In Abbildung 24 sind diese Gruppen blau gekennzeichnet. Für eine genaue
Beschreibung der einzelnen Objekte dieser Untergruppen wird auf die MIB
Beschreibung im Anhang B-2 verwiesen.
Die erste Untergruppe mit Monitoring–Funktionalität ist die pvsGeneral-Gruppe
(OID 1.3.6.1.4.1.4947.2.2.2.1.*). Generelle Informationen über den Profile, wie
beispielsweise die installierte Softwareversion, können in dieser Gruppe abgefragt
werden.
Die pvsVersion-Untergruppe gibt Auskunft über die Aktualität des vorhandenen
MIB-Moduls, welches implementiert ist.
pvsFaultIndicators ist eine Untergruppe, in der Statusinformationen über
Fehlzustände im Profile XP abrufbar sind. Die Abfrage des Wertes der Status LED
am Frontgehäuse des Profile ist möglich.
Die pvsCardCage-Untergruppe (OID 1.3.6.1.4.1.4947.2.2.2.2.*) enthält eine
Tabelle, in der sämtliche am PCI Bus angeschlossenen Boards aufgeführt werden.
Zusätzlich enthält die Tabelle einige Statuswerte der einzelnen Boards. Kommt es
zu Fehlzuständen in einem der Boards, werden Informationen darüber in dieser
Tabelle hinterlegt. Die durch SNMP erkennbaren Fehlzustände sind in der MIB von
Zeile 840 bis 1220 beschrieben.
Die pvsSubSystems-Untergruppe (OID 1.3.6.1.4.1.4947.2.2.2.3.*) repräsentiert
detaillierte Informationen der einzelnen Teilsysteme innerhalb des Blockplans (siehe
Abbildung 23). Die Objekte dieser Untergruppe geben Aufschluss über den Zustand
der Teilsysteme.
Das Medienspeichersystem des Profile XP ist in der Untergruppe pvsVideoStorage
erreichbar. Die Gruppe pvsRaid listet die Anzahl der Raid Gehäuse auf. In drei
Tabellen dieser Gruppe werden die einzelnen Plattenspeicher in der RAID
Anordnung mit einigen Statusinformationen angegeben.
Informationen über den verfügbaren Speicherplatz innerhalb der Speicheranordnung
gibt die pvsFileSystem-Gruppe.
Konfigurationsparameter der Video-Netzwerkschnittstellen sind in der Untergruppe
pvsVideoNetwork hinterlegt. Die IP Einstellungen der Netwerkkarten können in
der Tabelle unterhalb der pvsVnIp-Gruppe abgerufen werden. Zudem werden in der
pvsVnIfTable Statistiken über die Aktivität der jeweiligen Schnittstellen gesammelt.
Das Objekt pvsOutFrames (OID: 1.3.6.1.4.1.4947.2.2.2.3.2.2.1.7) zählt
beispielsweise alle ausgehenden Frames des Interfaces.
46
Anwendung des SNMP
Der SDI/SDTI Eingang wird mittels pvsVideo-Gruppe überwacht. Eine Tabelle
zeigt an, ob ein SDI Signal an den Anschlüssen des Profiles anliegt und welche
Informationen (SDI-Audio, VITC) der SDI-Strom beinhaltet.
Eine ähnliche Überwachung des Audiosignaleingangs erfolgt durch die pvsAudioGruppe.
Die zeitliche Synchronisation der Signalverarbeitung übernimmt das Realtime
system board (siehe Abbildung 23). Informationen über die LTC oder Genlock
Eingänge werden in der pvsTimingReference-Gruppe dargestellt. Das
pvsTrVideoMode Objekt (OID: 1.3.6.1.4.1.4947.2.2.2.3.5.1) zeigt den
Videostandard an, welcher bei der Wiedergabe oder Aufnahme verwendet wird,
beispielsweise der PAL Standart mit 625 Zeilen bei 25 Hz Bildwiederholfrequenz.
Der Status der Stromversorgung des Profile XP kann über die pvsPowerSupplyGruppe abgefragt werden. Informationen über die einzelnen Netzteile werden in
Tabellenform hinterlegt.
Aktuelle Umgebungswerte sind über die pvsThermal-Gruppe abrufbar.
Temperaturwerte innerhalb des Gehäuses und der Status der Lüftung sind die
Inhalte dieser Gruppe.
Die letzte Untergruppe ist die pvsSystemDisk. In ihr wird der Status der Systemdisk
des Applikationssystems dargestellt.
Controlling des Profile XP:
Ein ähnliches Vorgehen soll nun auch bei der Analyse der Controlling Objekte des
gvgVideoStorage MIB Moduls angewandt werden. In der Abbildung 24 werden
diese Objekte rot umrahmt. Aus der Betrachtung ergeben sich die Werte, die durch
das Controlling einer Systemmanagement-Applikation erfasst werden können.
pvsGpiOutput ist eine Untergruppe des gvgVideoStorage MIB Moduls. Sie
ermöglicht Einstellungen der GPI8 (General Purpose Interface) Schnittstelle. In der
untergliederten Tabelle kann so jeder GPI Anschluss konfiguriert werden.
In der pvsTrapResendCfg-Untergruppe ist die Konfiguration der Trapsendungen
hinterlegt. Parameter über die Sendehäufigkeit und den Intervall zwischen den
Sendungen sind einstellbar.
Die Überwachung des freien Speicherplatzes auf dem Medienspeichersystem ist
eine wichtige Aufgabe. Die Untergruppe pvsVsFileSystem beinhaltet das Objekt
pvsFsCapacitythreshold (OID 1.3.6.1.4.1.4947.2.2.2.3.1.2.5). Erreicht der belegte
Speicher die Prozentangabe dieses Objektes, wird ein Trap gesendet.
Die Untergruppe pvsTemperature ermöglicht die freie Wahl von Temperaturwerten,
bei denen Traps wegen Überhitzungsgefahr des Profile XP gesendet werden.
Zu beachten bleibt bei diesen Controlling Funktionalitäten, dass erst nach einem
kompletten Systemreboot Änderungen der Einstellungen übernommen werden. Der
8
General Purpose Interface; nichtstandardisierte Schnittstelle zur Überwachung medientechnischer
Komponenten
47
Anwendung des SNMP
Systemreboot kann nicht durch SNMP ausgelöst werden. Die Nutzung von anderen
Diensten zur Gewährleistung des Controllings ist notwendig.
Der Profile ist eine Komponente, die innerhalb der Produktion Empfänger oder
Sender von Audio und Video Material ist. Bei normalem Betrieb ist von Seiten des
Managements kein Einschreiten erforderlich. Die Monitoring und Controlling
Aspekte der Punkte zuvor dienen als Information über die Zusammensetzung und
generelle Funktion des Video Servers.
Von größerem Gewicht ist für solch eine Komponente die Umsetzung der
Fehlererkennung und Behebung. Hierfür spezifizieren die MIB Module des Profile
XP zehn verschiedene Trapsendungen. Abgesehen von den Traps der
Temperaturüberwachung und des Lüfterstatus, die von konfigurierbaren
Schwellwerten initialisiert werden, sind Auslösungsereignisse fest definiert.
Die Traps der Profile XP MIB decken einen weiten Bereich der Funktionalität der
Komponente ab. Tabelle 3 belegt dies.
Trap
Bereich der
Bereiche sonstiger
Überwachung nach
Überwachung
dem
Blockschaltbild
(Abbildung 23 )
pvsModeChange
Betriebsart
des
Applikationssystems
pvsBoardStatusChange
Alle Komponenten
am PCI Bus (in Abb.
23 weis hinterlegt)
pvsTempStatusChange
Temperaturüberwachung
als
Schutz
vor
Überhitzung des Profile
XP
pvsFanStatusChange
Sicherstellung
der
Lüfterfunktionalität
pvsPowerSupplyStatusChange
Sicherstellung
der
Stromversorgung
pvsDriveModuleStatusChange
Überwachung
des
Speichers
mit
pvsRaidChassisStatusChange
sämtlichen
RAID
pvsRaidControllerStatusChange
Parametern
pvsStorageCapacityStatusChange
pvsSystemDriveFailure
Überwachung
der
Systemdisk
des
Applikationssystems
Tabelle 3 : Überwachungsbereiche der definierten Traps des Profile XP
48
Anwendung des SNMP
5.2.3. Der Digital Video Quality Analyser (DVQ)
Der DVQ ist ein Analysegerät aus dem Hause Rohde&Schwarz. Es ermöglicht die
Analyse von DCT codierten Bilddaten innerhalb eines MPEG2-Transportstroms.
Zudem bietet der DVQ die Möglichkeit ITU-R 601 Signale zu untersuchen. Das
Analyseverfahren liefert dabei Messwerte, die den subjektiven Eindruck der
Bildqualität in einer objektiven Skala darstellt. Diese Skala reicht von 100
(exzellente Bildqualität) bis 0 (schlechte Bildqualität) und orientiert sich an der
Wahrnehmung einer realen Personentestgruppe.
Die Analyse erfolgt in Echtzeit und gewährleistet die Überwachung des gesamten
Transportstroms (TS) sowie einzelnen Programmen innerhalb dessen.
Die Aufgabe dieses Gerätes in der TV-Produktion liegt in der Qualitätsüberwachung
ein- und ausgehender TS-Signale. Sowohl vor als auch nach dem TS-Multiplexer
kann er zum Einsatz kommen. Abbildung 25 gibt einen Überblick über die
Einsatzgebiete des DVQ.
Abbildung 25 : Einsatzgebiet des DVQ im Play-Out [37]
Der DVQ besitzt zwei Schnittstellen zur Fernsteuerung über ein Netzwerk. Die RS232 und Ethernet Schnittstellen erlauben die Kommunikation mit dem DVQ über
die SCPI-Befehlssprache. Der SNMP Dienst wurde nachträglich in den DVQ
integriert. Dieser greift auf dieselben Befehlssätze wie SCPI zu. Die EthernetSchnittstelle macht den SNMP Dienst über TCP/IP Netzwerke zugänglich. Version
1 des SNMP wird unterstützt.
Der SNMP Dienst wurde im DVQ nach und nach implementiert und mit
fortschreitender Firmwareversion in seiner Funktionalität erweitert. Bei den
Testinstallationen wurde die aktuellste Firmwareversion 3.10 verwendet.
MIB Module:
Die MIB2 Gruppe wurde in der SNMP Implementierung des DVQ berücksichtigt.
Die Untergruppen system (OID 1.3.6.1.2.1.1) und snmp (OID 1.3.6.1.2.1.11)
werden unterstützt. Die Funktionalität des DVQ wird im Modul DVQ-MIB
abgebildet. Unterhalb der OID 1.3.6.1.4.1.2566.3.2.1 gliedern sich 11 Untergruppen
(siehe Abbildung 26).
49
Anwendung des SNMP
Abbildung 26 : Das MIB Modul des DVQ (Screenshot von Programm MG-Soft MIB Browser,
Anhang CD\MG-Soft)
Datentypen:
Hauptsächlich werden in der DVQ-MIB die Datentypen Integer und Octet String
verwendet. Zusätzlich sind 60 weitere zusammengesetzte Datentypen definiert. Die
meisten Objekte sind somit durch spezielle Datentypen repräsentiert. Daten wie
beispielsweise die Messwerte des DVQ werden in Strings übermittelt. Das Objekt
readMeasDetailsDvql (OID 1.3.6.1.4.1.2566.3.2.1.5.4.0) beschreibt den Messwert
der Qualitätsmessung. Der zusammengesetzte Datentyp dieses Objektes ist
String255 und entspricht einem Octet String der Länge 255 Byte. Die Messwerte
werden in der Form
<aktueller Messwert>,<minimaler Messwert> (Bsp.: 87,87)
mittels SNMP übertragen. Bei einer Auswertung solcher Daten muss diese
besondere Datenrepräsentation berücksichtigt werden.
Control und Monitoring:
Die Komplexität dieses Messgerätes ist mit 383 MIB Objekten hoch. Die komplette
Darstellung der Eigenschaften des DVQ über die GUI einer SystemmanagementApplikation ist nicht sinnvoll. Zur Konfiguration und Fernbedienbarkeit der
gesamten Komponente sollte auf spezielle Software zurückgegriffen werden.
Denkbar ist ein externes Programm, welches über die Oberfläche der ManagementApplikation aufgerufen werden kann.
Einzelne Problemstellungen sollten allerdings über eine Management-Applikation
direkt behandelbar sein. Für den DVQ Analysator ergibt sich ein einfaches Szenario,
welches über die Oberfläche der Applikation zu bedienen und zu überwachen ist.
♦ Der DVQ untersucht einen digitalen Transportstrom nach auftretenden
Fehlern. Informationen über den Transportstrom und dessen Inhalt sollten
abrufbar sein.
50
Anwendung des SNMP
Relevant für die Analyse des TS ist es zu wissen, welche Programme im Strom
enthalten sind. Das Objekt readArrayProg (OID 1.3.6.1.4.1.2566.3.2.1.5.15)
beschreibt einen String, der die Kennnummern aller enthaltenen Programme des TS
liefert. Diese Nummern können über die Untergruppe readArrProg (OID
1.3.6.1.4.1.2566.3.2.1.5.16) der Textbezeichnung des Programms zugeordnet
werden. Abbildung 27 zeigt ein Beispiel.
Abbildung 27 : DVQ MIB Repräsentation aller Programme innerhalb des Transportstroms
Die Untergruppe readTsInfo (OID: 1.3.6.1.4.1.2566.3.2.1.5.22.*) liefert wichtige
Daten über Parameter des Transportstroms. Bildwechselfrequenz, Auflösung des
Bildinhaltes oder Art der MPEG-Codierung sind einige dieser abrufbaren Parameter.
♦ Da es sich beim DVQ um ein Messgerät handelt, ist es sinnvoll, Messungen
von der Systemmanagement-Applikation aus durchführen zu können. Zudem
sollten die wichtigsten Einstellungen zu einzelnen Messungen konfigurierbar
sein.
Der DVQ ermöglicht eine Vielzahl von Messungen. Die folgende Betrachtung
orientiert sich an dem Messszenario, einzelne Programme des TS der
Bildqualitätsanalyse zu unterziehen. Das Objekt senseControl (OID:
1.3.6.1.4.1.2566.3.2.1.6.1) ermöglicht die Einstellung des TS-Decoders. Dabei kann
dieser ein einzelnes Programm decodieren (prog), alle Programme des TS
alternierend decodieren (scan) oder eine spezielle PID Kennung herausfiltern (spid).
Soll eine Analysemessung eines einzelnen Programms erfolgen, ist das Objekt
senseProgram (OID: 1.3.6.1.4.1.2566.3.2.1.6.2) auf die entsprechende Kennzahl des
Programms zu setzen.
Die wichtigsten Parameter, die es vor einer Messung einzustellen gilt, sind in
Tabelle 4 aufgelistet.
Objekt (OID
1.3.6.1.4.1.2566.3.2.1.*)
confMeasDetControlMode
(OID *.4.13)
confMeasDetControlTime
(OID *.4.14)
Bedeutung
Messung läuft entweder
kontinuierlich oder
entsprechend der
Zeiteinstellung unter
confMeasDetControlTime
Zeitliche Dauer der Messung
im Messmodus "once"
51
mögliche Werte
cont oder once
10 Einstellungen von 5
Sekunden bis 5 Stunden
Anwendung des SNMP
confMeasDetPar (OID *.4.7)
confMeasDetDisp (OID *.4.8)
confMeasCont (OID *.4.15.*)
setzt den Modus der
Qualitätsmessung;
gewichtet liefert einen
Messwert für die
Bildqualitätsbeurteilung des
gesamten Signals;
ungewichtet liefert drei
Qualitätsmesswerte für die
Signalkomponenten
Luminanz, Cr, Cb
Art der Darstellung der
Messwerte am Display des
Gerätes
gewichtet oder
ungewichtet
numeric, bargraph,
histgram, longtime
histgram
Untergruppe mit Objekten zum Start, Stop, Fortsetzen
der Messung; oder Anzeigen des Messstatus
Tabelle 4 : Messparameter des DVQ
♦ Die Aufzeichnung der relevanten Messwerte über einen längeren Zeitraum
hinweg stellt die maßgeblichste Anforderung an ein Systemmanagement im
Monitoring und Controlling dar. Kommt es zu einer Fehlermeldung, sollten
die Messwerte aus Tabelle 5 schnell zugänglich sein.
Objekt (OID
1.3.6.1.4.1.2566.3.2.1.*)
Bedeutung
readMeasDetailsBitrate (OID
*.5.6)
Datenrate des ausgewählten Programms
innerhalb des Transportstroms
readTsBitrate (OID *.5.18)
Datenrate des gesamten Transportstroms
readVideoBitrate (OID *.5.19)
Datenrate der Videoinformation innerhalb des
ausgewählten Programms
readAudioBitrate (OID *.5.20)
Datenrate der Audioinformation innerhalb des
ausgewählten Programms
readMeasDetailsDvql (OID *.5.4)
Messwert der Qualitätsanalyse
Tabelle 5 : Messwerte des DVQ
Der DVQ kann drei unterschiedliche Trapnachrichten verschicken. Kommt es in
dem analysierten TS zu Fehlern, wird der tsAlarmTrap initialisiert. Gleiches gilt für
Fehlerereignisse bei der Analyse von ITU-R 601 Signalen. Mit den Traps werden
Audio- und Videoparameter überwacht. Als Auslöseereignisse dienen dabei
Schwellwerte, die innerhalb der MIB aufrufbar und konfigurierbar sind. Diese
Schwellwerte sind in der MIB Untergruppe config ab den Objekten unterhalb des
OID 1.3.6.1.4.1.2566.3.2.1.4.24 beschrieben.
Neben diesen frei wählbaren Schwellwertgrenzen zur Erzeugung von Traps sind
auch einige nicht konfigurierbare Auslöseereignisse vorgesehen. Das Objekt
tsAlarmTrapEventType
(OID
1.3.6.1.4.1.2566.3.2.1.11.100.1.2)
bzw.
ituAlarmTrapEventType (OID *.100.2.2) beschreibt alle möglichen Fehlerursachen.
52
Anwendung des SNMP
Neben diesen beiden Traps ist eine weitere Alarmmeldung definiert. Kommt es in
der SCPI Befehlsverarbeitung zu Problemen, wird der srqEvent Trap gesendet.
Die PDU der Traps beinhaltet mehrere Objekte, die Zusatzinformationen zum
Fehlerereignis liefern. Eine Auflistung dieser Objekte der jeweilige Traps ist im
Anhang B-3 zu finden.
53
Anwendung des SNMP
6. Die Inbetriebnahme von ausgewählten Managementapplikationen
Vor der Inbetriebnahme einer Applikation sollten einige Vorüberlegungen gemacht
werden:
-
Welche Komponenten sollen in ein Management eingegliedert werden? Je
nach Umgebung und Workflow der Produktion ergeben sich hier
individuelle Szenarien.
Wie sind diese Komponenten durch SNMP repräsentiert?
Welche Objekte der SNMP Repräsentation sind relevant für ein
Management?
Welche Fehlermeldungen kann eine Komponente erzeugen?
Welche Priorität hat die jeweilige Fehlermeldung für das Gesamtsystem?
Die Beantwortung dieser Frage liegt in der Analyse der MIB Module einer jeden
Komponente. Wie solche Analysen vollzogen werden können, ist in Kapitel 5.2
dargestellt.
6.1. Die Installierung des Network Node Manager von HP-Openview
Dieses Produkt ist spezialisiert auf das Management von traditionellen IT
Infrastrukturen. Serverrechner, Router, Drucker oder Hostrechner sowie deren
Verbindungen können vom Node Manager überwacht werden. Bei der
Testinstallation wurde die Version 6.31 des Node Managers verwendet. Eine spätere
Erweiterung auf die Version 7.01 erfolgte ohne Schwierigkeiten, sodass alle
Funktionalitäten übernommen werden konnten.
Die Applikation wird dabei auf einen Server-Rechner installiert. Openview
unterstützt die Betriebssysteme Solaris, HP-UX und Windows.
Bevor die eigentliche Installation der Applikationssoftware gelingen kann, müssen
noch für die spätere Funktion wichtige Dienste auf dem Managementstationsrechner
installiert werden.
Für eine Windows Umgebung sind dies:
-
Der TCP/IP Dienst
Der Microsoft SNMP Agent (SNMP Dienst)
Internet Information Server (IIS) Version 4.0 oder höher
Web Browser
Microsoft data access components (MDAC)
Die Managementstation muss vor der Installierung Administrator Rechte innerhalb
des zu managenden Netzwerks besitzen.
Die eigentliche Installierung des Programms kann nach der Erfüllung dieser
Vorbedingungen problemlos durchgeführt werden.
Vor der Inbetriebnahme der Applikation sollten alle SNMP unterstützenden
Komponenten des Netzwerkes auf den Managementrechner konfiguriert werden.
Die Vergabe der Community Strings sollte vorab feststehen.
54
Anwendung des SNMP
6.1.1. Die Erkennung und Darstellung des Netzwerkes
Nach der Installierung startet der Autodiscovery Prozess der Openview Applikation.
Dieser Prozess durchforstet das Netzwerk und fragt dabei alle im Netzwerk
vorhanden IP Adressen ab. Aus diesen Adressen und zusätzlichen Informationen aus
weiteren Abfragen entsteht in der GUI des Node Managers eine logische Abbildung
der Netzwerkstruktur ([38], S.62). Diese wird in mehrhierarchischen Maps
dargestellt (siehe Abbildung 28).
Abbildung 28 :
Testinstallation)
Netzwerkdarstellung
der
Openview-Applikation
(Screenshots
aus
der
Ein Klasse C Netzwerk der Adressierung 192.168.n.h wird in die
Netzwerksegmente n unterteilt. Jedes dieser Segmente erhält eine neue Map, auf
welcher alle Komponenten h dieses Segmentes dargestellt werden.
Der Netzwerkerkennungsprozess nutzt verschiedene Netzwerkprototolle, um an
Informationen zu gelangen, die für die Konstruktion der Netzdarstellung notwendig
sind. Zum Einsatz kommen dabei neben SNMP die Protokolle TCP, ARP und ICMP
sowie IPX9.
Die einzelnen Abfragen sind in unterschiedliche Polling-Verfahren unterteilt.
Das Configuration Polling: Diese Polling-Art beschreibt SNMP Abfragen von
Netzwerkkomponenten mit Agentenimplementierung. Dabei werden einige
Objektwerte der MIB2 Gruppe angefordert. Zu diesen Objektwerten gehört die
system-Untergruppe (OID 1.3.6.1.2.1.1.*), einige Objekte des ifTable der interfacesUntergruppe (OID 1.3.6.1.2.1.2.2.*), sowie einige Objekte aus der ip-Untergruppe
(OID 1.3.6.1.2.1.4.*). Die Antworten der einzelnen Netzkomponenten werden in
einer Datenbank hinterlegt und Eigenschaften zugeordnet.
9
Der Mode Manager ist auch in der Lage das Internet Package eXchange, ein Protokoll entwickelt
von der Firma Novel, zum Netzdiscovery zu nutzen, in der weiteren Ausführung wird auf diese
Protokollform nicht näher eingegangen
55
Anwendung des SNMP
Besondere Bedeutung hat dabei die system-Untergruppe. Das Objekt sysObjectID
(OID 1.3.6.1.2.1.1.2) beschreibt die OID-Kennung des komponentenspezifischen
MIB Moduls einer Netzkomponente. Eine Auswertung dieses Objektwertes gibt
Aufschluss über die Art des Gerätes.
Das DVQ beispielsweise wird im SNMP Model durch das MIB Modul der Kennung
1.3.6.1.4.1.2566.3.2 eindeutig beschreiben. Diese Kennung ist im sysObjectID
hinterlegt. Erhält der Pollingprozess diesen Wert als Antwort auf die sysObjectIDAnfrage, erkennt dieser, dass es sich bei dieser Komponente um einen DVQ handelt.
Diese Information wird zusammen mit den Informationen aus den anderen Abfragen
gespeichert und zur Visualisierung dieser Komponente genutzt.
Zusätzlich zu den Informationen, die aus den SNMP Anfragen gewonnen werden,
nutzt der Node Manager TCP, um eventuell vorhandene Netzdienste zu erfassen.
Dabei werden spezielle Ports angefragt. Im Falle der Version 6.31 sind dies die
Portnummern 80 (http), 135 (epmap) 111 (sunrpc), 37907 (nicht spezifiziert) und
280 (http-Management).
Bei einem Einsatz des Node Managers als Managementstation eines größeren
Netzwerks mit Firewalls und Zugriffsbeschränkungen ist dies zu beachten.
Discovery Polling: Zur Erkennung des Netzwerkes werden die Datenverbindungen
zwischen den Netzwerkkomponenten ausfindig gemacht. Dazu fragt dieses Polling
alle Komponenten nach deren ARP-Cache Einträge ab. Realisiert wird dies durch
die SNMP Abfrage der Tabelle ipNetToMediaTable (OID 1.3.6.1.2.1.4.22.*) der ipUntergruppe. In dieser Tabelle sind die Verbindungen aufgeführt, die die jeweilige
Komponente nutzt. Der Node Manager kommt somit zu Informationen über die im
Netzwerk befindlichen Komponenten und kann deren Verbindungsstatus zueinander
rekonstruieren.
Status Polling: Die vorigen Polling Mechanismen sind für die
Informationsbeschaffung über die Eigenschaften des Netzwerkes und der einzelnen
Komponenten darin verantwortlich. Das Status Polling dagegen fragt den aktuellen
Zustand der Komponenten ab. Es pollt alle zuvor erkannten Komponenteninterfaces
mittels ICMP an. Durch diese Abfrage wird überprüft, ob das jeweilige Interface
überhaupt noch aktiv ist.
Topology Polling: Auch diese Abfrageform wird über SNMP realisiert. Hierbei
werden spezielle MIB Module, bspw. von Bridges (RFC 1493) abgefragt. ([38],
S.193)
Die auf diese Weise gesammelten Daten werden in Datenbanken hinterlegt ([38],
S.68) aus denen die Openview Applikation die Netzwerkdarstellung gewinnt. Es
zeigt sich, dass gerade zu Beginn des Autodiscovery Prozesses ein hoher
Datenaustausch zwischen Netzwerk und Management-Applikation stattfindet.
Abbildung 29 verdeutlicht, dass diese Polling-Verfahren viele Daten zyklisch aus
einem Netzwerk anfordern. Je nach Menge der Komponenten des Netzwerks
ergeben sich große Datenmengen. Somit stellt sich die Frage nach der Netzbelastung
durch die Applikation.
56
Anwendung des SNMP
Abbildung 29 : Datenaufkommen durch den Node Manager pro Komponente (basierend auf der
Darstellung des MGSoft MIB Browsers)
Um das Datenaufkommen und somit die Netzbelastung kontrollieren zu können,
lassen sich die Wiederholintervalle der einzelnen Polling-Verfahren konfigurieren.
Generell kann man davon ausgehen, dass die meisten Komponenten innerhalb eines
Netzes selten umkonfiguriert werden. Ist das Netzwerk einmal erfasst, können die
Configuration, Discovery und Topology Polling Intervalle größer gewählt werden.
Im Gegensatz dazu steht das Status Polling. Je nach Wichtigkeit der Komponente
muss sichergestellt werden, dass diese noch erreichbar ist. Entsprechend gering ist
dieser Intervall zu wählen.
Für die Darstellung der Netzlast wurden die folgenden Polling-Intervalle
konfiguriert:
♦ Topologie polling interval: 5 h (Default 4 h)
♦ Configuration polling interval: 1 h (Default 1 day)
♦ Status polling: 1 min (15 min)
♦ Discovery polling interval: 30 min (orientiert sich an
der Häufigkeit neu entdeckter Komponenten)
Die Wahl der Polling Intervalle orientiert sich an den Default-Werten. Um ein
wenig mehr Netzlast zu erzeugen als nötig wäre, wurden diese Defaultwerte
unterboten.
57
Anwendung des SNMP
Es zeigt sich, dass mit zunehmender Anzahl der durch den Node Manager erfassten
Komponenten die Netzlast steigt. Allerdings bleibt die Netzbelastung durch die
Pollingverfahren gering. In den Testnetzwerken bleibt diese Last in den Spitzen im
Bereich von 10 kBit/s (siehe Anhang C-1). Schwierigkeiten durch diese Netzlast
können demzufolge nur in Netzwerkteilen mit geringer Kapazität auftauchen. Im
Bereich des Fast Ethernet ist diese Netzlast hingegen zu vernachlässigen.
Zu Problemen mit der Netzauslastung kann es lediglich kommen, falls die
Pollingintervalle stark verkürzt werden. Der Status Poll ist ein Beispiel hierfür. Die
Intervalle dieser Abfrage sollten so klein wie möglich gewählt werden, um Interface
Ausfälle schnell erkennen zu können. Eine große Anzahl von Komponenten führt zu
einer permanenten Beanspruchung der Netzressourcen durch ICMP. Anhang C-1
zeigt die zunehmende Netzbelastung durch ICMP mit steigender Netzgröße.
Obwohl im 1-er Segment lediglich 20 Komponenten mehr zu überwachen sind,
steigt die Netzbelastung durch ICMP deutlich im Vergleich zum 212-er Segment.
Neben einer überlegten Einstellung der Pollingintervalle können im Node Manager
Filter eingesetzt werden. Solch ein Einsatz ermöglicht den Ausschluss einzelner
Teile eines Netzwerks aus dem Managementsystem und erlaubt zusätzlich eine
Reduzierung der Netzlasten. Die Konfiguration dieser Filter erfolgt mittels einfacher
ASCII Textfiles im Verzeichnisbaum des Openview Installationsordners.
Der unten beschriebene Filter Delsegvier_MF soll als Beispiel dienen und sortiert
die Komponenten mit den aufgezählten IP Adressen aus der Node Manager
Darstellung heraus.
Delsegvier_MF "Filter für die Segmente 1,2 <mit Ausnahme> und SAN" {(!("IP Address"
~ 192.168.4.*) && !("IP Address" ~ 192.168.2.1-181) && !("IP Address" ~ 192.168.1.8095)) || (isNetwork || isSegment)}
Informationen über mögliche Filter und deren Konfiguration gibt das Openview
Manual Scalability and Distribution in Kapitel 2.
6.1.2. Zuverlässigkeit der Netzerkennung
Die automatische Netzwerkerkennung basiert auf der Kommunikation der
Managementstation mit SNMP-fähigen Komponenten im Netzwerk. Je mehr
Komponenten eines Systems die MIB Untergruppen der Pollingverfahren
unterstützen (Abbildung 29), je lückenloser wird das Netzwerk erkannt.
Bei den Testinstallationen kam es vor, dass einzelne Komponenten nicht durch den
automatischen Prozess ausfindig gemacht wurden. Zu begründen ist dies mit der
geringen Anzahl von Komponenten in der Testumgebung mit SNMP
Implementierung der nötigen MIB-Untergruppen.
Falls bekannt ist, welche Komponenten nicht erfasst wurden, besteht die
Möglichkeit diese nachträglich aufzunehmen. Auf den Discovery Prozess sollte
demnach nicht „blind“ vertraut werden.
6.1.3. Das Grundlayout
Nach der Erfassung des Netzwerkes durch die Pollingverfahren ergibt sich auf der
GUI des Node Managers eine Default-Map nach Beispiel der Abbildung 28. In der
Node-Level Hierarchie werden alle erkannten Komponenten dargestellt. Dabei
58
Anwendung des SNMP
erfolgt die Darstellung der Symbole nach den Informationen aus den SNMP PollingAbfragen.
Generell wird jede Komponente einem Hintergrund zugewiesen. Dieser Hintergrund
kann je nach Status farblich verändert werden und dient somit als visueller Indikator
für den Zustand einer Komponente. Welcher Zustand durch welche Farbe
ausgedrückt wird, zeigt Abbildung 30.
Für den Fall, dass eine Komponente einen SNMP Agenten mit entsprechender
Implementierung der MIB2 Untergruppen besitzt, kommt eine erweiterte
Darstellung in frage. Zusätzlich zum Statushintergrund können solche Komponenten
durch charakteristische Bilder symbolisiert werden.
Abbildung 30 : Darstellung der Netzkomponenten durch Openview (Screenshots aus der
Testinstallation)
Die Node Manager Software gibt einige Symboltypen für die gängigsten IT
Komponenten vor. Änderungen an diesen können vorgenommen werden. Neue
Symbole können ebenfalls erstellt werden.
6.1.4. Die Anpassung der Darstellung an das Broadcastumfeld
Die Default Map ist der Grundstamm, aus welcher sich je nach Anforderung die
gewünschte grafische Netzwerkrepräsentation erstellen lässt. Für die einzelnen
Bereiche einer Produktion lassen sich spezielle Maps bilden, in denen nur die für
diesen Bereich relevante Technik überwacht wird. Die Unterteilung in
unterschiedliche Maps wird durch die gleiche Filterfile-Syntax (siehe 6.1.1) wie
bereits erwähnt erreicht.
Anhand von Hintergrundgrafiken der einzelnen Maps lässt sich eine geografische
Nachvollziehbarkeit der Netzstruktur erreichen (Abbildung 31). Diese
Hintergrundgrafiken werden ausschließlich im gif-Format (Graphics Interchange
Format) unterstützt.
59
Anwendung des SNMP
Abbildung 31 : Nachvollziehbarkeit der geografischen Position der Komponenten im System
(Screenshots aus der Testinstallation)
Neben solch einer geografischen Einteilung ist es ebenfalls denkbar, einen
Signalwegeplan
als
Hintergrundbild
zu
verwenden.
Die
einzelnen
Komponentensymbole werden durch Drag&Drop an die jeweilige Position gebracht.
Der Zugang zu den einzelnen Darstellungsebenen erfolgt intuitiv durch
Doppelklicken auf das entsprechende Symbol.
6.1.5. Standard-Tools zur Analyse von Managementdaten
Eine der zentralen Aufgaben der Managementstation ist es, Daten über einzelne
Komponenten abrufbar und auswertbar zu machen. Diese Anforderung erfüllt der
Node Manager durch eigene Tools. Sie stellen einen großen Teil der MonitoringFähigkeiten der Applikation dar.
Der Zugriff auf diese erfolgt über die Systemleiste der GUI oder über „executable
Objects“ innerhalb einer Darstellungsebene.
60
Anwendung des SNMP
Der MIB Loader:
Für die Integration neuer Komponenten in eine Managementstation wird es nötig,
die jeweiligen MIB Module in der Station verfügbar zu machen. Die
Managementstation kann nur Komponenten managen, dessen MIB Implementierung
bekannt ist.
Der Node Manager sieht für diese Aufgabenstellung einen MIB Loader vor. Dieser
lädt die jeweiligen Module in die Datenbank der Applikation und definiert damit die
darin enthaltenen Objekte für die Datenverarbeitung der Managementstation.
Auch eine nachträgliche Anpassung der Datendarstellung innerhalb des MIB
Moduls ist somit möglich. Beispiel hierfür ist das Objekt ConfMeasContState (OID
1.3.6.1.4.1.2566.3.2.1.4.15.1). Dieses zeigt an, ob der DVQ momentan eine
Messung durchführt. Der Integerwert „1“ beschreibt eine aktuell laufende Messung.
Dieser „1“ wird die Enumeration „start“ zugeordnet. Anstatt der wenig informativen
„1“ erscheint bei einer Abfrage dieses Wertes „start“.
Der MIB Browser:
Eine generelle Abfrage von einzelnen MIB Objekten oder das Auslesen einzelner
MIB Tabellen wird durch den MIB Browser (Abbildung 32) möglich. Nachdem alle
erforderlichen MIB Module geladen wurden, werden diese Objekte über den
Browser abrufbar.
Abbildung 32 : Der MIB Browser (Screenshot aus der Testinstallation)
Die Baumstruktur aller Komponenten Module ist über den Browser nachvollziehbar.
Neben der Abfrage erlaubt der Browser das Setzen von Objektwerten. Da der
Browser die komplette Objektvielfalt des Managementsystems anzeigt, wird er als
Konfigurationsoberfläche schnell unübersichtlich. Eher geeignet ist er als
Kontrollmöglichkeit der MIB Modul Implementierung der einzelnen Komponenten.
Besonders bei der Einrichtung der Komponenten innerhalb der Managementstation
ist der Browser ein hilfreiches Instrument.
61
Anwendung des SNMP
Der Data Collector:
Durch dieses Tool können SNMP Daten längerfristig gesammelt, abgerufen und
verglichen werden. Dabei lassen sich einzelne Objekte in einem frei definierbaren
Intervall von ausgewählten Komponenten abfragen. Die Abfrageergebnisse werden
in einer Datenbank gespeichert und über die darstellenden Managementtools des
Node Managers abrufbar. Die Untergrenze des Abfrageintervalls liegt bei 1
Sekunde.
Alle der Managementstation bekannten Objekte können mittels Kollektor über einen
längerfristigen Zeitraum gesammelt werden. Bei solchen Abfragen kommt es
schnell
zu
großen
Datenmengen.
Um
eine
Überlastung
der
Managementspeicherressourcen zu vermeiden, lassen sich Datenbanken einrichten,
die solche Daten extern speichern.
Neben der reinen Datensammlung lassen sich die gesammelten Daten auf einen
Schwellwert überprüfen. Übersteigt oder unterschreitet ein gesammelter Wert den
Schwellwert, wird ein spezieller Alarm zur Signalisierung der Schwellwertprüfung
erzeugt. Dieser Alarm wird in der gleichen Weise wie eingehende Trapsendungen
durch den Node Manager bearbeitet. Nur die Datentypen Counter, Gauge, Integer,
IpAddress, Counter64 und TimeTicks werden durch den Schwellwertvergleich
unterstützt ([38], S. 422).
Somit lassen sich auch Werte in einem Managementsystem überwachen, die nicht
über Trapdefinitionen in einem MIB Modul kontrolliert werden. Durch den
minimalen Abfrageintervall von einer Sekunde ist dieser Überwachung allerdings
eine Grenze gesetzt.
Die SNMP Anfrage durch den Kollektor beinhaltet einen Abruf des sysUpTimeObjektes (Abbildung 33). Anschließend folgt die „get“-Aufforderung an die
spezifischen Objekte, die es zu erfassen gilt. Voraussetzung für die Nutzung des
Kollektors ist demzufolge eine Implementierung des sysUpTime-Objektes in der
jeweiligen Komponente.
Abbildung 33 : Datenaustausch durch den Collector (Mitschnitt durch Ethereal, file „netztest-2-er
lang“ Paket)
Der Grapher:
Die Visualisierung von SNMP Daten, entweder längerfristig gesammelt oder
spontan aufgerufen, kann mittels Grapher erfolgen. Dabei werden die Daten in
einem Liniendiagramm über eine Zeitachse dargestellt (Abbildung 34). Die Werte
der Zeitachse werden durch die Managementstation erzeugt.
62
Anwendung des SNMP
Die Skalierung der Daten innerhalb des Grapher kann durch Parameterübergabe
beim Aufruf oder direkt über die Menüleiste vorgenommen werden. Die zur
Verfügung stehenden Skalierungsparameter sind in 10-er Potenzen bis zum Faktor
10000 beschränkt. Zu große Unterschiede in der Wertigkeit einzelner Objektwerte
können unter Umständen nicht ausgeglichen werden.
Nur Objekte eines numerischen Datentyps können durch den Grapher dargestellt
werden.
Abbildung 34 : Darstellung der gemessenen Datenraten des DVQ durch den Grapher des Node
Manager (Screenshot aus der Testinstallation)
Der Application Builder:
Ein weiteres Tool zur Auswertung von Managementdaten des Gesamtsystems
beschränkt sich auf die Darstellung in Tabellenform. Mit Hilfe des Application
Builder lassen sich Objekte zusammentragen, die auf Anfrage in einer speziellen
Fensterform der Applikation angezeigt werden (Abbildung 35).
Abbildung 35 : Datenrepräsentation durch den Application Builder am Beispiel des Profile XP
(Screenshot aus der Testinstallation)
Der Aufruf der festgelegten Werteabfrage kann über eigens angelegte Menüs in der
Menüleiste der GUI gestartet werden oder über Objekte auf einer Map abgerufen
werden.
63
Anwendung des SNMP
Report Presenter:
Eine weitere wichtige Funktionalität der Openview Managementstation ist die
Generierung von Reporten. Dabei sammelt die Applikationssoftware SNMP Daten,
um diese per e-mail in Berichtform regelmäßig zu versenden ([39], S. 93).
Welche Komponenten und welche Daten in den Bericht übernommen werden, kann
definiert werden. Zusätzlich gibt es einige Berichtvorlagen, wie beispielsweise eine
Inventurliste mit allen im System befindlichen Komponenten und Statistiken über
deren Status innerhalb einer gewissen Zeit.
Webinterface:
In den Node Manager ist ein Web-Server Dienst integriert. Er erlaubt den Zugriff
auf einige Managementdaten von einem entfernten Rechner aus. Allerdings können
dem Webinterface der Managementstation nur Monitoring Eigenschaften
zugeschrieben werden.
Über das Webinterface kann ein Blick auf die jeweilige Map geworfen werden.
Somit auch auf die Statusanzeigen der einzelnen Komponenten. Weitere
Monitoringfunktionalitäten stecken in der Nutzung des Alarmbrowsers sowie des
MIB Browsers.
Die Version 7.01 des Node Managers zeigt eine graphisch verbesserte
Webinterfaceimplementierung. Zudem stehen ausführlichere Monitoring
Funktionalitäten zur Verfügung.
Neben den Standard-Tools sind über die GUI noch weitere Analysemöglichkeiten
zur Netzwerküberwachung abrufbar. Der Node Manager befasst sich hauptsächlich
mit Netzwerkstrukturen der IT. Aus diesem Grund beinhaltet die GUI der
Standardinstallation einige Verweise zu Informationen wie Datenrate, Durchsatz
oder Auslastung eines Netzwerkinterfaces (Abbildung 36). Die Berechnung dieser
Werte erfolgt über die exe-Datei „ovexprguru“. Durch die Konfiguration von
Textfiles innerhalb des Verzeichnisbaums der Node Manager Software wird diese
exe-Datei in der GUI anwendbar. Auch einige Perl Scipt Dateien stehen für die
Auswertung von SNMP Daten zur Verfügung.
Abbildung 36 : Beispiel für den Aufruf externer Programme zur Auswertung von Managementdaten
(Screenshot aus der Testinstallation)
64
Anwendung des SNMP
6.1.6. Das Error-Mapping des Node Managers
Für die Verarbeitung von eingehenden Trapsendungen sieht der Node Manager
einen speziellen Verarbeitungspfad vor. Erhält der Manager eine Alarmmeldung
einer Komponente, wird diese in einem Alarmfenster (Abb. 37) angezeigt.
Abbildung 37 : Verarbeitungspfad von eingehenden Trapsendungen (basierend auf Screenshots aus
der Testinstallation)
Dabei werden die Trap Meldungen in unterschiedliche Kategorien eingeteilt. Die
Prioritäten der Alarme werden durch die Statusfarben aus Abbildung 30 visualisiert.
Die Prioritäten „warning, normal, minor, major und critical“ können dargestellt
werden.
Das Alarmfenster dient als erster Indikator für eingegangene Traps. Die Anwahl
einer Kategorie öffnet einen Alarmbrowser, in dem der Inhalt der Trapsendung
angezeigt werden kann. Neben Informationen über Senderkomponente und
Eingangszeit können die Alarme bestätigt werden und sind somit aus der
Darstellung des Alarmfensters genommen.
Bei Doppelklick auf eine der Trapbeschreibungen des Alarmbrowsers öffnet sich die
Mapdarstellung, auf welcher die Absenderkomponente dargestellt ist.
Es besteht die Möglichkeit Traps aus diesem Verarbeitungspfad auszuschließen. Die
eleganteste Methode ist die Kombination mit Map-Filtern. Über das
Befehlszeilenkommando „xnmevents –FilterByMap“ finden nur die Trapsendungen
Aufmerksamkeit, die auf der entsprechenden Map dargestellt werden.
Zudem können Traps aus dem Verarbeitungspfad ausgeschlossen werden, indem
entsprechende Trapsendungen nicht konfiguriert werden.
Die weiteren Stationen des Trapverarbeitungspfades lassen sich für jeden einzelnen
Trap
separat
konfigurieren.
Voraussetzung
hierfür
ist,
dass
das
komponentenspezifische MIB Modul mit der jeweiligen Trapdefinition geladen
65
Anwendung des SNMP
wurde. Die Konfigurierung der einzelnen Traps wird im „Event Configurator“
vorgenommen. Hier können auch neue Kategorien für das Alarmfenster geschaffen
werden.
Fehlerbeschreibung:
Der „Event Configurator“ gibt eine Aufstellung der einzelnen Trapsendungen. Die
Priorität jedes Traps und die Kategorie, in welcher er erscheinen soll, sind
einstellbar. Die textliche Beschreibung der Fehlermeldung innerhalb des
Alarmbrowsers wird hier festgelegt. Für die Beschreibung stehen alle übermittelten
Objektwerte der Trapsendung zur Verfügung. Über Parameter werden diese im
„Event Configurator“ abrufbar.
Ein Beispiel: „Fehlermeldung von $A --- Übermittelte Fehlerinformation $1-$2-$3“
Dieser Eintrag generiert eine Fehlermitteilung, bei der mit $A der Name
Sendekomponente und mit $1-3 die übermittelten Objektwerte des Traps in
String eingebunden werden. Es stehen einige solcher Parametervorgaben
Verfügung ([38], S. 411). Der erzeugte String wird im Alarmbrowser
Beschreibung des Fehlers dargestellt.
der
den
zur
als
Pop-Up Window:
Zur Hervorhebung eines Trapempfanges lassen sich Pop-Up Fenster generieren.
Trifft eine Sendung ein, öffnet sich auf der Managementkonsole ein Fenster. Der
Inhalt dieses Fensters ist eine Textnachricht. Diese lässt sich entsprechend des
Stringbeispiels definieren.
Automatic Action:
Ähnliches gilt für die Erzeugung von „Automatic Action“. Hierdurch können
Reaktionen auf eingehende Fehlermeldungen erzeugt werden. Der Aufruf von
externen Programmen, exe-files oder bat-Dateien ist unter anderem möglich.
Der Aufruf von speziell angefertigter Software zur Fehlerbehebung ist denkbar. Ein
e-mail oder pager-Programm zur Weiterleitung der Fehlermitteilung kann
implementiert werden. Auch Befehlsstapeldateien mit direkten SNMP set-Reaktion
lassen sich einrichten. Dabei können die Parameterübergaben an die jeweiligen
Programme genutzt werden.
Die Konfigurierung einer e-mail Sendung bei Eingang eines Traps soll die
Einrichtung der „Automatic Action“ verdeutlichen. Der Inhalt der DVQTrapsendung liegt diesem Konfigurationsbeispiel zu Grunde. Als e-mail
Sendesoftware wurde mailto 1.6 (Anhang D-3) verwendet.
Der Aufruf eines separaten Programms innerhalb des „Event Configurator“ muss
zuvor in der Verzeichnisstruktur der Openview-Software beschrieben werden. In
einer Textdatei (conf/trustedCmds.conf) wird das Quellverzeichnis des
auszuführenden Programms beschrieben. In dem konkreten Fall wäre dies
„mail=D:/openview_pro/bin/mailto/mail.bat“
Die Zuordnung “mail” beschreibt die Aufrufbezeichnung innerhalb des Event
Configurators. Die mail.bat Datei sendet bei einem Aufruf eine E-mail mit dem
Inhalt, der dem bat-Aufruf als Parameter übergeben wird. Dieser Aufruf mit den
Parameterübergaben wird im „Automatic Action“-Feld des DVQ Traps eingetragen.
66
Anwendung des SNMP
Ein Eintrag der Form:
„mail -- Fehler in Komponente $1 -- Messung in Programm $9 -- Grund $4 -Fehlermesswert $5 -- Dauer des Fehlers $6ms“
liefert den Mailinhalt
„-- Fehler in Komponente ROHDE&SCHWARZ,DVQ,0,03.10 -- Messung in
Programm 28014 -- Grund dvqlw_limit -- Fehlermesswert 72 – Dauer des Fehlers
800ms“.
Trapweiterleitung:
Einzelne Traps können durch Angabe der IP Adresse an andere Managementrechner
weitergeleitet werden. Probleme treten allerdings auf, falls die Empfangsstation
keine Node Manager Software installiert hat. Die Weiterleitung der
Trapinformationen geschieht mittels TCP ([40], S.63) und ist folglich keine SNMP
Standardfehlersendung.
6.1.7. Die Einbindung von Broadcastkomponenten
Nach der Standardinstallation des Node Managers stehen ausreichende
Funktionalitäten bereit, Komponenten von traditionellen IT Strukturen zu
überwachen. Broadcastkomponenten mit IP Netzwerkschnittstelle lassen sich
erfassen und nach ihrer Netzwerkerreichbarkeit überwachen. Die geographische
Nachvollziehbarkeit über den Standort der Komponente ist ebenfalls gegeben.
Je nach SNMP Implementierung lassen sie sich in das Managementsystem
integrieren. Diese Integration wird nun anhand des DVQ Analysers beispielhaft
beschrieben. Das Integrationsszenario unter 5.2.3 dient dabei als Vorlage.
Die symbolhafte Darstellung neuer Komponenten auf den Maps lässt sich anpassen.
Die Definierung neuer Symbole erfolgt durch die Konfigurierung spezieller ASCII
Files innerhalb der Node Manager Verzeichnisstruktur.
Die Zuordnung, welche Komponente durch welches Symbol ausgedrückt wird,
geschieht durch die Auswertung des sysObjectID Objektes durch das PollingVerfahren. Der Eintrag
1.3.6.1.4.1.2566.3.2:TVDevice:DVQ
# rohde & schwarz DVQ
in der Datei „oid_to_sym“ (Verzeichnisordner HOME\conf) verweist auf zwei
Definitionsdateitypen, in denen das Symbol beschrieben wird. Eine ist im Ordner
„symbols“ hinterlegt. Diese beschreibt die Form des Hintergrundbildes und verweist
auf das zu verwendende Vordergrundbild. Zudem werden dem Symbol
Eigenschaften (Capabilities) übergeben, die den Zugriff auf Funktionen in der GUI
regeln. Der zweite Typ gibt das entsprechende Vordergrundbild im Pixmapformat
an.
Auf diese Weise lassen sich je nach Komponente neue Symbolvisualisierungen
definieren. Abbildung 38 zeigt die Symbolbeispiele für DVQ und AVDC100. Die
notwendigen Dateieinträge zur Definierung sind in Anhang D-1 zu finden.
67
Anwendung des SNMP
Abbildung 38 : Definitionen neue Symboltypen (Screenshot aus der Testinstallation)
Die auf diese Weise geschaffenen Objekte auf den Maps sind der Ausgangspunkt
für die weitere Integration der Broadcastkomponenten. Die Objekte können in
unterschiedlicher Art definiert werden.
Zum einen in ausführender Art, dabei können bei Anwahl des Symbols die oben
beschriebenen Tools (6.1.5) benutzt werden, um Daten der Komponente anzuzeigen,
oder eigene Programme aufgerufen werden. Der Aufruf von VNC (Virtual Network
Computing) Diensten und Webdiensten ist möglich.
Die Symbole können zum anderen so konfiguriert werden, dass sie bei Anwahl eine
neue Submap öffnen, die je nach Anforderung mit neuen Symbolen ausführender
Funktionalität eingerichtet wird. Der Anzahl an Hierarchiestufen ist keine Grenze
gesetzt.
Der Schlüssel für die Einbindung der Controlling und Monitoring-Szenarien der
Komponenten sind die Registration Files in der Verzeichnisstruktur. In ihnen wird
definiert, welche Dienste oder Zusatzapplikationen innerhalb der GUI abrufbar sind.
Der Aufbau dieser ARF (Application Registration Files) gliedert sich hauptsächlich
in die Teile „menu“ und „action“. Im Sektor „menu“ wird eine Menustruktur
aufgebaut, die in der Systemleiste der GUI angezeigt wird (Abbildung 39).
Innerhalb dieser Struktur werden „actions“ angegeben, die bei Anwahl des
entsprechenden Menupunktes ausgeführt werden.
Die erwähnten „actions“ beschreiben die exe, bat oder sonstige ausführende Dateien
und bestimmen, welche Symbole diese aufrufen können. Ein Auszug aus dem ARF
der Testimplementierung des DVQ ist in Anhang D-2 zu finden.
Die Standardtools des Node Managers erlauben die Umsetzung der MonitoringSzenarien unter Punkt 5.2.3. Alle Werte der einzelnen Objekte lassen sich über den
Application Builder abrufen. Auch die längerfristige Aufzeichnung dieser Werte
durch den Data Collector erfolgt problemlos.
68
Anwendung des SNMP
Abbildung 39 : Menudarstellung der Komponentenintegration (Screenshot aus der Testinstallation)
Die Aufzeichnung von Messwerten und die Darstellung dieser sollten über den
Grapher erfolgen. Relevante Messwerte sind im Messszenario die Datenraten und
die Qualitätsbeurteilung. Die Datenraten sind vom Datentyp Integer und über den
Grapher darstellbar (Abbildung 34). Der Wert der Qualitätsbeurteilung wird im
String Datentyp übermittelt und ist somit nicht über den Grapher zu visualisieren.
Für diese Anforderung muss ein eigenes Tool entwickelt werden.
Ein weiteres Monitoringproblem tritt in der Darstellung der im TS vorhandenen
Programme auf. Es lässt sich zwar anzeigen, welche Programme enthalten sind,
allerdings erfolgt die Repräsentation in wenig aussagekräftigen Zahlenfolgen der
Art
„28041,28042,28006,28011,28014,28016,28007,28013,28012,28008,28015,28009,
28017“. Eine Zuordnung der einzelnen Zahlen zu den Sendernamen erfolgt durch
ein anderes MIB Objekt. Um diese Information darzustellen, muss ein set-get
Kommunikationsaustausch zwischen Management-Station und DVQ stattfinden.
Die angebotenen Tools des Node Managers können diese Anforderung nicht
erfüllen. Auch hier muss ein separates Programm entwickelt werden.
Auch die Controllingszenarien lassen sich nicht ohne weiteres über den Node
Manager verwirklichen. Controlling bedeutet im SNMP Modell das Setzen von MIB
Objektwerten. Der Node Manager stellt lediglich den Browser mit set-Funktionalität
bereit. Die Handhabung des Browsers für eine schnelle und automatische
Bearbeitung von „set“ Befehlen ist ungenügend. Für den Bereich der „set“ Befehle
muss ebenfalls eine zusätzliche Anwendung implementiert werden.
Zur Umsetzung dieser zu ergänzenden Anforderungen ist es notwendig, ein
Verständnis über den Aufbau der Node Manager Software zu gewinnen.
6.1.7.1. Die vereinfachte Softwarestruktur des Node Managers
Die Implementierung der Node Manager Software folgt dem Grundsatz einer
offenen Software Struktur. Alle Prozesse können separat mittels Shell Kommandos
oder Konfiguration entsprechender ASCII Textfiles angesprochen werden. Eine
Zusammenstellung der Prozesse gibt ([38], S. 507).
Für die Lösung der oben genannten Probleme bei der Integration des DVQ ist es
nötig, einen Zugriff auf den SNMP Dienst zu erhalten. An dieser Stelle ist der
modulare Aufbau der Software von Bedeutung. Alle SNMP Kommandos werden
innerhalb der Openview Struktur durch eigene exe-Dateien nutzbar. Durch
69
Anwendung des SNMP
Parameterübergabe kann somit jeder Wert des Managementsystems über diese
Dateien abgerufen (snmpget) oder gesetzt (snmpset) werden.
Diese Kommandos lassen sich in eigene Programme einbinden, um Daten zu
erfassen und zu bearbeiten. Durch die ARF werden diese in der GUI abrufbar
(Abbildung 40).
Abbildung 40 : Modularer Aufbau der Node Manager Applikation
6.1.7.2. Die Nutzung der offenen Softwarestruktur
Zur Realisierung der problemspezifischen Programme wurde eine Cygwin
Umgebung10 [41] genutzt. Diese erlaubt die Nutzung von Source Code sowohl für
Windows- als auch für Linuxsysteme. Die Programme wurden in C unter
Verwendung der POSIX (Portable Operating System Interface for Unix) Bibliothek
verfasst.
In Abbildung 41 wird der schemenhafte Aufbau eines solchen Programms
beschrieben. Das Beispiel entspricht der Lösung der Messwertkonvertierung des
DVQ durch das Programm „messung.c“ (Anhang D-3). Hierbei werden die
Messwerte durch den SNMP Dienst des Node Managers erfragt. Anschließend wird
der gesendete String bearbeitet, um den eigentlichen Messwert zu erhalten. Dieser
wird an eine Excel Tabelle weitergeleitet und dort fortlaufend dargestellt.
Diese Zusatzanwendung erreicht zwei bis drei Werteabfragen pro Sekunde und
unterbietet damit den minimalen Pollingintervall der Node Manager Applikation.
10
UNIX Programmierumgebung für Windows Systeme, inklusiv eines C Compilers
70
Anwendung des SNMP
Abbildung 41 : Ablaufplan der DVQ Messwertkonvertierung durch messung.exe (Anhang D-3)
Eine ähnliche Vorgehensweise wurde bei den Problemstellungen der TSProgrammauswertung vorgenommen (Programm tsprog.c im Anhang D-3). Die
Contollingszenarien wurden ebenfalls realisiert. Ein Beispiel hierfür zeigt
„sendereinstellung.c“ (Anhang D-3). Alle weiteren Programme, die das Setzen von
MIB–Objekten beabsichtigen, wurden nach dem gleichen Prinzip verfasst. Sowohl
für den AVDC100 als auch für den DVQ.
Die zusätzlichen Programme wurden durch ARF der GUI zugänglich gemacht. Die
ARF rufen Batch Dateien auf, welche auf die jeweiligen Programme verweisen.
Dadurch ist es möglich, jederzeit die Funktionalität der zusätzlichen Programme zu
erweitern oder umzukonfigurieren.
Diese Beispiele zeigen, dass es möglich ist, eigene SNMP Anwendungen zu
kreieren und diese über den Node Manager abrufbar zu machen. Dabei kann auf die
Node Manager Software zugegriffen werden.
71
Anwendung des SNMP
Alle Anforderungen der Testgeräte wurden über solche zusätzlichen Programme
erfüllt. Eine Zusammenstellung dieser Programme für AVDC100, DVQ und
ProfileXP sind im Anhang D-3 zu finden.
6.1.8. Das Controlling und Monitoring der Testkomponenten
Die beschriebenen Möglichkeiten dieser Applikation wurden auf die
Testkomponenten angewendet. Für jede Testkomponente entstand eine eigene
Repräsentation auf der GUI des Node Managers. Eine Darstellung, welche
Möglichkeiten nach der jeweiligen Einrichtung in die GUI verfügbar und welche
Schwierigkeiten bei den einzelnen Komponenten aufgetreten sind, folgt nun.
Der DVQ-Analyser:
Das Testszenario des DVQ wurde erfolgreich in die Node Manager Applikation
integriert. Sowohl Monitoring als auch Controlling Funktionalität sind abrufbar. Um
einige Daten längerfristig dokumentieren zu können, kam der Data Collector zum
Einsatz.
Die Darstellung orientiert sich an der Menüführung des Gerätes selber, Abbildung
42 verdeutlicht dies.
Abbildung 42 : Die DVQ-Repräsentation auf der GUI (basierend auf Screenshots aus der
Testinstallation)
Es zeigt sich, dass Geräte mit hoher Komplexität mit der angewandten Methode der
Menünachbildung nicht umfassend zu integrieren sind. Die Darstellung wird schnell
unübersichtlich. Sinnvoller für solche Komponenten ist der Aufruf autarker
Anwendungen, die die Steuerung dieser Komponenten ermöglicht.
72
Anwendung des SNMP
Der DVQ Analyser ist ein Beispiel für Komponenten, die nachträglich mit SNMP
ausgerüstet wurden. Der SNMP Dienst bedient sich hierbei der SCPIBefehlssprache. Jedes SNMP Kommando wird durch ein SCPI-Äquivalent
bearbeitet. Auf diese Weise entstehen für einige Objektwerte uncharakteristische
Datentypen. Objekten mit eindeutig numerischer Datentypencharakteristik, wie
beispielsweise Messwerte, sollten auch numerische Datentypen zugeordnet werden.
Ist dies nicht der Fall, führt dies zu einem erheblichen Mehraufwand bei der
Integration in ein Managementsystem.
Hieraus folgt, dass bei der Planung und Analyse von MIB Modulen einzelner
Komponenten auf die Datentypenrepräsentation zu achten ist. Zu viele eigene
Datentypen stellen ein Problem bei der Auswertung solcher Managementdaten dar.
Die vom DVQ gesendeten Traps folgen bei allen Fehlerereignissen dem gleichen
Aufbau. Die Informationen über die Art des aufgetretenen Fehlers werden durch die
Übermittlung von Objektwerten innerhalb des Traps geliefert. Im Falle der
Transportstromanalyse sind 30 unterschiedliche Ursachen möglich. Somit empfängt
der Node Manager bei allen Fehlern den gleichen Trap. Eine unterschiedliche
Bearbeitung der Traps bezüglich deren Ursache bietet die Standardversion des Node
Managers nicht. Dazu ist ein Tool nötig, das den Inhalt der Trapsendungen
untersucht und entsprechend dem Inhalt unterschiedliche Reaktionen auslöst.
Dieses Tool kann durch ein C oder Perl Programm als „automatic action“
konfiguriert werden.
Der Fehlergrund wird innerhalb des DVQ-Traps als vierter Parameter ($4) dem
Error-Mapping (siehe 6.1.6) übergeben. Dieser Parameter wird an das AnalyseProgramm weitergeleitet und ausgewertet. Bei entsprechendem Inhalt ruft das
Programm weitere Reaktionen hervor. Die Einrichtung einer solchen Zusatzfunktion
erfolgt nach dem gleichen Schema wie die Einrichtung der e-mail Sendung zuvor.
Der AVDC100:
Ausgangspunkt für die Integration des AVDC100 in das Managementsystem des
Node Managers ist die Mapdarstellung des Konfigurationsnetzes (Abbildung 43).
Neben dem AVDC enthält diese Umgebung weitere Komponenten wie den Fibre
Chanel Switch. Dieser bietet ein Webinterface, um das Gerät zu konfigurieren und
zu kontrollieren. Dieses kann über die GUI aufgerufen werden. Die
Parametrisierung der Switch-Traps durch den Node Manager bietet einen
Grundstock für die Überwachung dieser Komponente.
73
Anwendung des SNMP
Abbildung 43 : Umsetzung des Controlling und Monitoring des AVDC100 innerhalb des Node
Managers (basierend auf Screenshots der Testinstallation)
Der AVDC ist durch unterschiedliche Submaps in der GUI integriert. Die AVDCMIB stellt eine exakte Nachbildung der Menuführung dar. Die jeweiligen Submaps
orientieren sich an dieser Menuführung und ermöglichen die vollständige
Controlling Funktionalität des AVDC. Die zusätzlichen Programme zur Kontrolle
der Einstellungen entsprechen dem Schema der Datei „sendereinstellung.c“.
Durch die Monitoring-Tools der Applikation lassen sich alle Werte des AVDC
darstellen und visualisieren.
Eine Forderung nach längerfristiger Dokumentation von Werten des AVDC kann
nicht erfüllt werden. Der DataCollector scheitert bei dem Versuch Daten dieser
Komponente zu erfragen. Grund hierfür ist die fehlende MIB2-Implementierung im
AVDC. Der Collector erhält keinen Wert nach einer Anfrage der sysUpTime und
bricht die Datenkollektion ab. Eine solche Dokumentation muss erneut durch eine
externe Softwarelösung erreicht werden.
Der AVDC ist somit ein Beispiel für Broadcastkomponenten mit unzureichender
Berücksichtigung des SNMP Standards. Es genügt nicht, lediglich das
komponentenspezifische Modul zu implementieren.
Der Profile XP:
Die MIB Implementierung des Profile XP erlaubt eine geringe ControllingFunktionalität. Die Integration in der GUI führt aus diesem Grund lediglich die
Monitoring Anforderungen aus. Alle Objektwerte dieser Komponente können
problemlos dargestellt und gespeichert werden. Abbildung 35 zeigt die Darstellung
der Werte der pvsCardCage-Untergruppe.
74
Anwendung des SNMP
Die tatsächliche Bedienung des Profile XP kann über eine VNC-Verbindung zur
grafischen Oberfläche des Applikationssystems ermöglicht werden. Der Aufruf des
VNC Dienstes erfolgt dabei auf der Submap des Profile XP (Abbildung 44).
Entscheidender für das Management des Video Servers ist die Einbindung der Traps
in das Error-Mapping des Node Managers.
Abbildung 44 : Die Integration der Überwachung des Profile XP in der GUI des Node Managers
(basierend auf Screenshots aus der Testinstallation)
Die Einrichtung von Fehlermitteilung und Erkennung des Node Managers hilft alle
eingehenden Fehlermeldungen zu signalisieren. Entsprechende Reaktionen können
eingerichtet werden.
6.1.9. Beurteilung des Node Managers zum Einsatz in der TVProduktion
Der Node Manager ist eine äußerst komplexe Management-Applikation mit vielen
Möglichkeiten. Das Management von herkömmlichen IT Strukturen muss durch
seine weite Verbreitung in diesem Bereich als gut bezeichnet werden. Die offene
Struktur der Software ermöglicht eine individuelle Gestaltung eines jeden Systems.
Der Integrationsaufwand für Broadcastkomponenten ist allerdings recht hoch, jede
einzelne muss separat betrachtet und eingerichtet werden. Für Komponenten des
gleichen Typs lassen sich „element Manager“ entwickeln. Sie enthalten die
notwendigen Änderungen und Zusätze der Verzeichnisstruktur des Node Managers
zur Integration solcher Komponententypen.
Die beschriebenen Anpassungen der Testkomponenten sind ein Beispiel für solche
„element Manager“. Somit muss für baugleiche Komponenten der
Integrationsaufwand nur einmalig erfolgen.
Die Überwachung von einzelnen Komponenten eines Systems ist möglich.
Voraussetzung hierfür ist die ausreichende SNMP Funktionalität mit
Implementierungen der MIB2 Gruppe.
Broadcastkomponenten lassen sich als Einzelsysteme erfassen und je nach
Anforderung
gemäß
der
SNMP
Implementierung
integrieren.
Die
broadcastspezifischen Signalwege, beispielsweise SDI oder SDTI, sind nicht durch
75
Anwendung des SNMP
MIB Spezifizierungen abgedeckt. Eine Auswertung dieser Transportverbindungen
kann also nicht erfolgen. Die meisten restlichen Transportverbindungen sind durch
MIB Standards spezifiziert. Voraussetzung für eine Integration der
broadcastspezifischen Transportwege ist die Standardisierung einer entsprechenden
MIB und die Implementierung dieser MIB in möglichst vielen Komponenten.
Einige Probleme müssen mit Rücksicht auf die speziellen Anforderungen des
Broadcast erwähnt werden.
Im Laufe der Testinstallationen und im späteren Betrieb kam es zu einigen
Systemabstürzen der Node Manager Software. Bedingt war dies hauptsächlich durch
die Langsamkeit des Testrechners. Da dieser den Minimalanforderungen jedoch
entsprach, bleibt ein Verweis auf die nicht immer perfekte Systemzuverlässigkeit.
Gleiches gilt für die Schnelligkeit der Systemreaktionen. Gegebene SNMP Abfragen
wurden in den meisten Fällen ohne erkennbare Verzögerung abgewickelt. Die
Bearbeitungszeit wird hauptsächlich durch die Übertragungsgeschwindigkeit des
Transportweges bestimmt. In einigen Fällen kam es jedoch zu Verzögerungszeiten
von bis zu einer Minute und mehr. Bedingt ist dies durch die Verarbeitung der
Abfrage innerhalb der Node Manager Software bei hoher Beanspruchung der
Applikation.
Zur weiteren Beurteilung der Applikation dienen die Vorüberlegungen der
Abschnitte 4.1 und 4.4.
Die Anforderungen bezüglich des Fehlermanagements können durch den Node
Manager erfüllt werden. Der gesamte Ablauf der Fehlerbehandlung lässt sich
individuell konfigurieren. Allerdings tauchen des Öfteren Schwierigkeiten mit der
Systemstabilität des Error-Mappings auf. Dies äußert sich in Systemabstürzen des
Alarmbrowsers.
Die statistische Netzüberwachung kann mittels Datenkollektor oder Reporter Tool
des Node Managers ermöglicht werden. Allerdings hält das Reporter Tool nur eine
begrenzte Auswahl von Reporten bereit. Diese beschränken sich auf die statistische
Überwachung von charakteristischen Werten von IP Netzwerken. Neue
Reportvorlagen mit komponentenspezifischen Werten bedürfen zusätzlicher
Programmierarbeit.
Die Forderung nach einer zentralen Managementkonsole wird durch den Node
Manager zufrieden stellend erfüllt. Ein komplettes Netzwerk lässt sich mittels einer
Konsole überwachen. Ist das Node Manager System eingerichtet, kann es ohne
weitere Wartung betrieben werden. Ein Problem an dieser Stelle bilden die
Systemabstürze. Im Betrieb ist auf eine fachmännische Betreuung nicht zu
verzichten.
Eine eindeutige Stärke des Node Managers ist seine offene Managementstruktur.
Sie ermöglicht die Integration jeder SNMP-fähigen Komponente und deren
Management im Rahmen der MIB Implementierung. Sinnvoll ist es allerdings, nur
Komponenten zu integrieren, die sich möglichst exakt an den SNMP Standard
halten. Konkret bedeutet dies die Berücksichtigung der MIB2 Gruppen und die
sinnvolle Umsetzung der spezifischen MIB Module.
Eine Zusammenführung der Überwachung von IT- und Broadcastkomponenten ist
vorstellbar.
76
Anwendung des SNMP
Das Monitoring orientiert sich am logischen Aufbau eines Netzwerkes, den IP
Adressen. Anhand dieser entstehen unterschiedliche Hierarchie-Ebenen. Die
Darstellung der Netzwerke richtet sich hauptsächlich nach den einzelnen IP
Segmenten. Eine Produktionsumgebung sollte so konfiguriert sein, dass die
einzelnen Bereiche der Produktion einem eigenen Segment zugeordnet sind. Nur so
profitiert man von der Darstellung durch den Node Manager und den Möglichkeiten
der geographischen Nachvollziehbarkeit.
Die Darstellungsmöglichkeiten der einzelnen Komponenten innerhalb der GUI sind
vielfältig. Die Objekte können mit vielfältigen Funktionen verknüpft werden. Daten
der Komponenten können angezeigt werden. Eine dynamische Darstellungsform
von Managementdaten wie etwa blinkende Signalisierungen ist allerdings nicht
vorhanden.
Controlling-Funktionalität steht ursprünglich nicht zur Verfügung. Der Aufruf von
zusätzlichen Programmen (VNC), Webinterfaces einzelner Komponenten oder das
Setzen von Werten innerhalb des Systems müssen zusätzlich entwickelt werden. Der
Aufwand hierfür ist allerdings als gering einzustufen.
Die Entwicklung von umfangreicheren Controllingszenarien, wie beispielsweise die
DVQ-Messung, ist möglich, jedoch entsprechend aufwendig. Ähnliches gilt für die
Lösung problemspezifischer Anforderungen. Die offene Struktur ermöglicht
Lösungsansätze für vielseitige Problemstellungen. Die ausführliche Dokumentation
hilft bei der Lösungsfindung. Der Aufwand bleibt allerdings hoch.
Das Webinterface der Node Manager Applikation erlaubt den Zugriff auf einige
Daten des Managers. Informationen über alle eingegangenen Traps und über
einzelne Komponenten können abgerufen werden. Probleme entstehen allerdings
häufig durch die Systemstabilität des Webinterfaces der Applikation.
Fehlerkorrelation ist eine äußerst wichtige Anforderung. Nur so kann gewährleistet
werden, dass auch alle Fehlermeldung korrekt eingestuft werden können. Diese
Anforderung erfüllt der Node Manager durch das Event Correlation System (ECS)
([38], S.359).
Die Konfigurierung des ECS ist mit einigem Aufwand verbunden. An dieser Stelle
ist die Unterstützung von Fachleuten erforderlich.
Prinzipiell bietet der Node Manager alle Funktionalitäten für einen Einsatz im
Produktionsumfeld. Voraussetzung ist die entsprechende MIB Implementierung in
den Komponenten. Allerdings ist eine Anpassung der Software an einige
Anforderungen nötig. Die oben aufgeführten Schwierigkeiten sollten gelöst werden.
Der Node Manager bietet keine „schlüsselfertige“ Lösung für ein SNMP
Management. Die Anpassung an die jeweiligen Umgebungen bedarf einiger
Programmierarbeit. Allerdings lässt die Software viel Spielraum für nachträgliche
Anpassungen und zusätzliche Funktionen.
77
Anwendung des SNMP
6.2. Die Management-Applikation NetCentral von Grass Valley
Die Thomson Grass Valley Gruppe bietet für das Controlling und Monitoring des
Produktionsumfeldes die Applikation NetCentral. Diese basiert auf dem
Management mittels SNMP. Die Entwicklung dieser Applikation brachte bereits
einige Versionen hervor. Diese wurden mit fortschreitenden Versionen in ihrer
Funktionalität erweitert. Das Grundkonzept der Software Architektur blieb jedoch
gleich.
Die derzeit aktuellste Version 4.0.2.2 wurde in die Testumgebung integriert.
Der Aufbau der NetCentral Managementstation gestaltet sich nach einer
Client/Server Architektur (siehe Abbildung 45). Die Server-Software bildet das
Herz der Anwendung. Alle Funktionen der Applikation werden durch sie
ausgeführt. Die Darstellung der Managementinformationen übernimmt der Client.
Durch diese Architektur ist es möglich, die Managementstation zentral auf einem
Managementrechner zu betreiben. Aber auch die Installation von ClientÜberwachungskonsolen innerhalb eines Netzwerkes ist denkbar. Der Zugriff der
Clientsoftware auf die Funktionalität des Managementservers wird über die
Verteilung von Rechten geregelt. NetCentral hält die drei Zugriffsgruppen User,
Technician und Administrator bereit. Die Rechte der einzelnen Gruppen können in
einem gewissen Rahmen frei verteilt werden.
Abbildung 45 : Die Softwarearchitektur des NetCentral Managementsystems (vgl. [42], S.18)
Die Kommunikation der Server Software mit den Komponenten entspricht dem
SNMP Modell der Versionen 1 und 2.
Ausschlaggebend für die Integration von Komponenten in das NetCentral
Management ist die Struktur der Server Software. Sie besteht aus den Teilen Device
Provider, Action Provider und Database.
Anhand des Device Providers wird der proprietäre Ansatz der NetCentral Software
deutlich. Jede Komponente, die mittels SNMP überwacht werden soll, benötigt
einen Device Provider. Dieser ist eine separate Softwarekomponente, die zusätzlich
zur Serversoftware installiert werden muss. Der Provider agiert dabei wie ein
„Fenster“, durch welches die Kernsoftware von NetCentral mit den jeweiligen
Komponenten mittels SNMP kommuniziert ([42], S. 19). Diese Provider werden für
einige Komponenten der Grass Valley Produkt Palette angeboten. Eine
78
Anwendung des SNMP
Zusammenstellung der zur Verfügung stehenden Provider gibt ([43], ab S. 3). Die
Programmierung der Provider Software übernimmt die Grass Valley Gruppe.
Durch die Device Provider werden die Möglichkeiten der Überwachung stark
limitiert. Es ist mit NetCentral aus diesem Grund nicht möglich, jede SNMP-fähige
Komponente zu integrieren. Für die Testumgebung bedeutet dies, dass lediglich der
Profile XP in das Management von NetCentral übernommen werden kann.
Der Ausweg aus dieser gravierenden Beschränkung könnte ein „generic Device
Provider“ sein. Dieser wird von Seiten Grass Valleys derzeit entwickelt. Dieser soll
ein offenes Provider Modul sein, welches für jede SNMP-fähige Komponente
individuell angepasst werden kann.
Diese Erweiterung würde die ursprünglich proprietäre Lösung in eine offene
Struktur wandeln. Zudem stehen bereits einige Device Provider zur Verfügung, die
eine weitere Betrachtung der NetCentral Applikation rechtfertigen.
Der action Provider definiert die möglichen Reaktionen, die NetCentral ausführen
kann. Zum Einsatz kommen diese bei Empfang und Auswertung der eingehenden
Fehlermeldungen. Jede auszuführende Reaktion wird dabei vom entsprechenden
Provider bearbeitet. NetCentral stehen dabei folgende Reaktionsmöglichkeiten zur
Verfügung:
-
Aufruf einer URL11
Versendung einer e-mail; entwender direkt oder nach Zeitplan
Abspielen eines Audiofiles
Ausführung eines seperaten Programms; mit Übergabe der Trapparameter
LED12 Anzeige
Generierung eines Peep-Tons
Triggerung eines GPI13-Ausgangs; nur bei einigen Komponenten möglich
(Profile XP)
Zur Speicherung der relevanten Informationen nutzt NetCentral eine SQL
(Structured Query Language) Datenbank. In dieser werden die eingegangenen
Fehlermeldungen, die daraufhin ausgeführten Aktionen dokumentiert. Zudem
werden hier Informationen über die Einstellungen und die Repräsentation der
Komponenten auf der GUI der Client Software hinterlegt.
6.2.1. Die Installation der Managementstation
NetCentral nutzt die Betriebssysteme Windows XP und 2000. Für die verwendete
NetCentral Version muss das entsprechende Betriebsystem in der US-Sprachversion
installiert sein. Die Anforderungen an das Rechnersystem der Managementstation
werden mit mindestens 2 GHz Taktfrequenz und 1 GByte RAM angegeben.
Daneben müssen einige zusätzliche Dienste installiert werden. Der Internet
Information Server 4.0 und der SNMP Dienst müssen konfiguriert sein. Zudem
liefert das NetCentral Softwarepaket eine SQL-basierte MSDE14 Datenbank mit.
Diese muss zusätzlich installiert werden.
11
Uniform Ressource Locator; Adresskonvention von www–Seiten
Light emitting diode; in diesem Fall die Anzeige an der Frontplatte des Profile XP
13
General Purpose Interface; nicht standardisierte Schnittstelle zur Überwachung medientechnischer
Komponenten
14
Microsoft Desktop Engine; SQL Server Datenbank
12
79
Anwendung des SNMP
Die Client/Server Struktur von NetCentral basiert auf .NET15 Technologie von
Microsoft, dementsprechend werden .NET Komponenten bei der Installation mit
überspielt.
Bei der Einführung von NetCentral als Control und Monitoring System bindet man
sich ausschließlich an Microsoft Betriebssysteme.
6.2.2. Die Erkennung der Netzkomponenten
Der Schlüssel für die Erkennung von Komponenten der Produktionsumgebung ist
der Device Provider. Nach der Installation der NetCentral Managementstation
müssen die Provider der zu überwachenden Komponenten installiert werden.
Anhand der geladenen Provider erfolgen die Netzwerk erkennenden Polling
Verfahren.
NetCentral nutzt zwei Verfahren, um Netzwerkkomponenten zu erkennen. Das
Autodiscovery-Verfahren fragt einen bestimmten IP Segmentbereich nach MIB
Modulen ab. Das Heartbeat-Verfahren überprüft die Erreichbarkeit der detektierten
Komponenten. Neben diesen automatischen Erkennungsverfahren können
Komponenten manuell in NetCentral integriert werden.
Am Beispiel des Profile XP lassen sich diese einzelnen Verfahren anschaulich
beschreiben (Abbildung 46).
Bevor der Autodiscovery Prozess beginnen kann, muss der IP Adressbereich
bestimmt werden, in dem nach Komponenten zu suchen ist. Eine Zeitangabe gibt
vor, wie lange NetCentral auf die Antwort einer Komponente warten soll.
Im Falle des Profile XP erfolgt durch den Discovery Prozess eine Aufforderung an
den Device Provider des Profile. Dieser generiert mittels SNMP Schnittstelle eine
SNMP Anfrage auf einen spezifischen MIB Wert des Profile (z.B. das Objekt
pvsModel mit der OID 1.3.6.1.4.1.4749.2.2.2.1.7.0). Diese Anfrage wird für jede IP
Adresse des vordefinierten Bereiches wiederholt. Antwortet eine Komponenten mit
einem SNMP Response, wird der IP Adresse die Komponente Profile XP
zugeordnet.
Auch das Heartbeat Polling erfolgt nach dem gleichen Schema. Dabei werden feste
Zeitintervalle bestimmt, in denen der Heartbeat Prozess alle erkannten
Komponenten anfragt. Die Intervalle zwischen den Anfragen liegen im Bereich bis
60 Sekunden. Die Heartbeatabfrage ist dabei ebenfalls eine SNMP Anfrage des
jeweiligen Device Providers auf spezifische MIB Objekte. Antwortet die
Komponente nicht auf die Anfrage, wird ein Alarm generiert.
15
Microsoft Framework zur Programmierung von Netzwerk-Applikationen
[http://msdn.microsoft.com/netframework/programming/fundamentals/default.aspx?pull=/library/enus/dnguinet/html/drguinet0_update.asp]
80
Anwendung des SNMP
Abbildung 46 : Das Schema des Ablaufes von SNMP Abfragen in NetCentral am Beispiel der
Pollingverfahren (vgl. [42] S.157)
Aus Abbildung 46 wird deutlich wie NetCentral den SNMP Datenaustausch
ermöglicht. Die Kernsoftware erteilt dem entsprechenden Device Provider einen
SNMP Auftrag. Dieser wird speziell von jedem Provider individuell bearbeitet. Die
tatsächliche SNMP Anfrage wird von dem externen NetCentral SNMP Service
([42], S. 157) abgewickelt. Die Kommunikation zwischen SNMP Service und
Kernsoftware erfolgt in einem speziellen NetCentral Paketformat über eine Named
Pipe16.
Die Abfragen der Erkennungsprozesse werden demzufolge von den Device
Providern vorgegeben. Inhalt dieser Abfragen sind Objekte der spezifischen MIB
Module der einzelnen Komponenten. Die Managementapplikation ist somit
maßgeschneidert auf eine Auswahl von Komponenten.
Nach der Installation und Ausführung der Netzerkennungsmechanismen entsteht
eine schlüsselfertige Überwachungsanwendung für Komponenten mit Device
Provider. Eine Anpassung des Managements dieser Komponenten ist nicht möglich.
Die Funktionalität von NetCentral kann nicht eigenständig erweitert werden.
6.2.3. Die Funktionalität der NetCentral Managementstation
Die Handhabung der Managementstation durch den Anwender erfolgt über die
Client-Anbindung der GUI an die Server Software. Informationen über die
Darstellung der einzelnen Komponenten und über deren Möglichkeiten innerhalb
des Managements werden über diese Verbindung ausgetauscht. Dabei stehen dem
Anwender einige Funktionalitäten zur Verfügung, diese werden im Folgenden kurz
beschrieben.
16
Kommunikationskanal zwischen zwei unterschiedlichen Softwareprozessen durch File
Descriptoren
81
Anwendung des SNMP
6.2.3.1. Das Monitoring der Komponenten
Die erste Betrachtung gilt dem Monitoring der Komponenten durch die Applikation.
Die über Device Provider in die Applikation integrierten Komponenten werden in
einer Baumverzeichnisstruktur (Abbildung 47) hinterlegt. Die einzelnen
Komponenten lassen sich mittels drag&drop in neu angelegte Verzeichnisordner
kopieren. Beispiel für solch einen Ordner ist der Studio1_RackView Ordner.
Innerhalb dessen sind alle detektierten Komponenten dieses Racks zu finden. Der
Profile XP ist Teil dieses Ordners.
Somit lassen sich je nach räumlicher Verteilung der Produktionsmittel
unterschiedliche Ordner einrichten.
Jedem Ordner wird dabei eine Visualisierung zugeordnet. Diese basieren auf
einfachen HTML Dateien. Die reelle Umgebung oder der Signalverarbeitungspfad
der Komponenten können durch Hintergrundgrafiken beschrieben werden. Die
enthaltenen Komponenten werden innerhalb der NetCentral GUI durch „active
drawings“ beschrieben. Dies sind grafische Repräsentationen der Komponenten. Bei
Eingang einer Fehlermeldung ändern diese ihre farbliche Hinterlegung. In
Abbildung 47 ist solch eine Änderung am Beispiel des Profile XP zu erkennen.
Abbildung 47 : Die Darstellung der Komponenten im GUI der NetCentral-Applikation (Screenshot
aus der Testinstallation)
Die Darstellung der Komponenten durch HTML Dateien erlaubt eine freie
Gestaltung des Monitoring. Möglich ist die Einbindung von Links zu VNCVerbindungen oder Web-Interfaces von Komponenten. Zusätzliche Programme oder
individuelle Gestaltungen sind hierdurch ebenfalls vorstellbar.
Die Darstellung der MIB Objektwerte innerhalb der NetCentral Oberfläche ist fest
vorgegeben. Diese ist durch den Device Provider definiert und kann nicht verändert
werden. Ausgangspunkt für die Darstellung der Daten ist der Verweis in der
Baumstruktur (Abbildung 48). Die eigentliche Datendarstellung erfolgt in Tabellen
oder speziellen Grafiken, je nach vorheriger Definition durch die NetCentral
Software.
82
Anwendung des SNMP
Abbildung 48 : Die Darstellung der MIB Daten des Profile XP der Untergruppe pvsCardCage
(basierend auf Screenshots aus der Testinstallation)
Die beschriebene Monitoring Funktionalität ist über die Darstellungsebene
„Facility“ (siehe Abbildung 47) abrufbar. Die weiteren Darstellungsebenen dienen
der Auswertung und Dokumentation von SNMP Daten. Die Anzeigen der einzelnen
Darstellungsebenen orientiert sich an dem Ordner oder der Komponenten in der
Verzeichnisstruktur, der angewählt ist.
6.2.3.2. Das Error – Handling von NetCentral
Fehlermeldungen werden durch den externen SNMP Dienst erkannt und an die
NetCentral Server Software weitergeleitet. Die eingehenden Trapsendungen werden
daraufhin in der Datenbank dokumentiert und mit den Einstellungen des Device
Providers verglichen. Falls eine Reaktion auf die Trapsendung konfiguriert ist, führt
der entsprechende action Provider diese aus.
Bei der Einstufung der Alarme stehen die drei Kategorien critical, warning und
informational zur Verfügung. Die Zuordnung der Trapsendungen zu den Kategorien
ist durch die Device Provider vorgegeben. Einstellbar ist dagegen die Reaktion der
einzelnen Traps. Über die Verzeichnisstruktur lässt sich jeder Trap einer
Komponente individuell durch einen action Provider konfigurieren. Welche
Trapsendungen auf diese Weise konfiguriert wurden, ist in der Darstellungsebene
„Actions“ dokumentiert.
Bei der Darstellung und Auswertung der Fehlermeldungen stehen zwei Formen zur
Verfügung (Abbildung 49). Die Ebene „Messages“ dokumentiert alle eingegangen
Fehlermeldungen; diese können bestätigt werden. Zudem enthält die Darstellung
vorgegebene Ratschläge zur Fehlerbehandlung und die Möglichkeit, Kommentare
zu jedem Alarm hinzuzufügen.
83
Anwendung des SNMP
Die Darstellungsebene „Graphs“ beschreibt eine Fehlerstatistik. Alle eingegangenen
Traps werden in Diagrammform entsprechend der Komponente und Fehlerkategorie
dokumentiert.
Abbildung 49 : Die Fehlerverarbeitung von NetCentral (basierend auf Screenshots aus der
Testinstallation)
Abgesehen von der Definition der Reaktionen auf eingehende Traps ist die gesamte
Trapverarbeitung vordefiniert. Eine weitere Konfiguration ist nicht möglich.
Zudem traten einige Schwierigkeiten auf, eingehende Alarmmeldungen auf der GUI
schnell erkennen und zuordnen zu können. Neben den Darstellungsebenen stehen
weitere Fehlersignalisierungen zur Verfügung, eine farbliche Hinterlegung des
NetCentral-Symbols in der Windows System Tray17 ist die deutlichste. Dies ändert
jedoch nichts an den genannten Schwierigkeiten.
Zur Lösung dieser Schwierigkeit sollten action Provider konfiguriert werden, die
eine direkte Anzeige von Fehlerart, Ursprung und Behebung unterstützen. Die
Ausführung zusätzlicher Programme ist hierfür notwendig.
6.2.3.3. Weitere Funktionalitäten
Je nach Device Provider stehen über die GUI der NetCentral Konsole weitere
Funktionalitäten bereit. In der Profile Implementierung lassen sich über eine ftp18
Verbindung einige log-Files auf die Managementstation übertragen. Dies erleichtert
die Fehlerbehandlung.
Für weitere Komponenten stellen die Device Provider spezielle Funktionalitäten
bereit. Diese lassen sich nicht generell bestimmen. Jede Komponente kann durch
ihren Device Provider zusätzliche Möglichkeiten abdecken.
17
18
Signalisierung von laufenden Programmen in der Windows Symbolleiste
File Transfer Protocol; IP Dienst zum Datentransfer
84
Anwendung des SNMP
6.2.4. Beurteilung der NetCentral Managementstation
Die Beurteilungskriterien aus den Punkten 4.1 und 4.4 helfen bei der Einschätzung
der Funktionalität dieser Management Applikation. Aus dieser Beurteilung ergeben
sich Vorschläge zur Erweiterung der Funktionalität der Anwendung.
Das Fehlermanagement von NetCentral folgt einem komplett vorgefertigten Weg.
Die Konfiguration der Fehlerbehandlung erlaubt eine gewisse
Zuordnung.
Bestimmbar ist die Art der Reaktion auf Alarme und ob diese überhaupt verarbeitet
werden sollen. Auf diese Weise können alle Alarmmeldungen bearbeitet werden.
Eine Schwierigkeit ist die Erkennung von eingehenden Traps. Hilfreich wäre an
dieser Stelle eine zusätzliche Fensterfunktion mit einer permanenten Fehleranzeige
der einzelnen Ordner. Als Vorlage könnte das Alarmfenster der Openview
Applikation dienen.
Einen Mechanismus zur Behandlung von Fehlerkorrelationen sieht NetCentral nicht
vor.
Im Bereich der statistischen Netzüberwachung wird eine Schwachstelle der
NetCentral Software deutlich. Die einzige Dokumentation gilt der Darstellung der
Fehlerstatistik. Die Abfragung von einzelnen Werten einer Komponente wird nicht
unterstützt, somit auch nicht die Möglichkeit, einzelne Daten über einen
längerfristigen Verlauf hinweg zu beobachten.
Eine Stärke von NetCentral ist der Aufbau der zentralen Konsole für die
Managementstation. Von ihr aus ist es möglich, alle Komponenten des Netzwerkes
zu überwachen. Durch den Plug-In Mechanismus durch die Device Provider steht
nach der Installation die gesamte Funktionalität der Managementstation zur
Verfügung. Eine Wartung durch eine zusätzliche Arbeitskraft ist nicht notwendig.
Die Forderung nach einer offnen Managementstruktur wird dagegen von
NetCentral nicht erfüllt. Lediglich Komponenten mit vorgefertigten Device
Providern können in das Management integriert werden. Eine Anpassung der
Repräsentation durch diesen Provider ist nicht möglich.
Die Monitoring Funktionalität zählt zu den Stärken der Applikation. Durch die freie
Einteilung der Komponenten in Ordnerverzeichnisse lässt sich eine individuelle
Visualisierung erreichen. Die räumliche Abbildung aller Komponenten sowie deren
Zusammenspiel innerhalb eines Workflows lassen sich durch entsprechende HTML
Dateien darstellen. Durch die Nutzung von HTML Dateien zur grafischen
Darstellung ist es möglich, zusätzliche Programme, weitere HTML Seiten oder
sonstige Verweise einzurichten.
Eine Überwachung von Verbindungen kann ebenfalls realisiert werden. Hierzu
stehen Statusindikatoren für einzelne Untergruppen der MIB Implementierung
bereit, die in die HTML Visualisierung eingebunden werden können ([42], S.137).
Voraussetzung sind eine MIB Untergruppe, welche die jeweiligen Verbindungen
beschreibt, und Traps, die Fehlermeldungen über den Status dieser Verbindungen
signalisieren.
Das Controlling der NetCentral Applikation beschränkt sich auf einige wenige
Parameter, vorgegeben durch den jeweiligen Device Provider. Eine Erweiterung
dieser Controlling Funktionen ist durch die Standardsoftware von NetCentral nicht
gegeben.
85
Anwendung des SNMP
Unter dem Begriff Controlling ist allerdings die Möglichkeit der Einbindung von
VNC oder Web-Interface Diensten zu erwähnen.
NetCentral stellt keine API bereit, um auf individuelle Anforderungen einzelner
Komponenten (Beispiel die Messwertkonvertierung beim DVQ) eingehen zu
können. Für die Lösung solcher Problemstellungen muss die SNMP API des
Windows Betriebssystems genutzt werden. Dies ist mit einem sehr hohen
Programmieraufwand verbunden.
Vorteilhaft ist die Server/Client Architektur der Managementstation. Die
Webinterface Strategie erlaubt einen gleichwertigen Zugriff auf das
Managementsystem von allen Positionen innerhalb des Managementnetzes. Der
Einsatzort der Managementkonsole kann somit flexibel gehandhabt werden.
NetCentral bietet eine schlüsselfertige Managementapplikation für einen Teil der
Broadcastkomponenten. Anpassungen sind möglich, diese orientieren sich
allerdings lediglich an der grafischen Repräsentation der Produktionsumgebung.
Bei einer Beurteilung ergeben sich zwei grundlegende Punkte
Durch die modulare Integration von Komponenten durch Device Provider werden
nur diejenigen Komponenten erfasst, die für den jeweiligen Zweck nötig sind. Dies
fördert die Übersichtlichkeit und Handhabung der Applikation.
Als klarer Nachteil ist die Tatsache zu sehen, dass nur ein Bruchteil der in
Sendeanstalten vorkommenden Technik durch NetCentral Provider ausgerüstet ist.
Ein Generic Device Provider könnte diesen Nachteil allerdings beheben.
Ein umfassendes Management von IT und Broadcaststrukturen ist durch NetCentral
nicht zu gewährleisten. Vielmehr bietet NetCentral eine Applikation zur
maßgeschneiderten Überwachung einzelner Teile eines Broadcastsystems.
Zudem ist es nicht möglich, NetCentral als Proxy-Applikation zu nutzen. Die
Einbindung in ein übergeordnetes Managementsystem wird nicht unterstützt.
86
Anwendung des SNMP
6.3. Die Applikation RollCall und RollMap
Aus dem Hause Snell&Wilcox stammt eine weitere Applikation zur Überwachung
und Kontrolle von Produktionsumgebungen über IT Netzwerkstrukturen. Die
Applikationen RollMap Version 1.7 und RollCall Version 3.4.1 wurden in einem
veränderten Testumfeld nach Abbildung 50 implementiert.
Das Management von RollCall und RollMap beschränkt sich auf die Überwachung
von Komponenten über die RS422 oder GPI Schnittstellen. Im Testaufbau sind
einige Komponenten über diese Schnittstellen an ein Gateway angeschlossen.
Dieses konvertiert die Daten in ein Format zur Übertragung mittels TCP/IP und
dient somit als Übersetzer. Fehlermeldungen und Statusabfragen werden über dieses
Gateway abgewickelt. Kommunikationspartner des Gateways ist dabei die RollCall
Software auf der Managementstation. Diese wertet die gesendeten Informationen
aus und bearbeitet Anfragen an das Gateway. RollMap ist die Monitoring-Einheit
der Managementstation. Sie bietet eine GUI zur Handhabung der
Managementaufgaben.
HS1 HS2 OK1 OK2 PS
1 2 3 4 5 6 7 8 9101112
COLACTSTA-
CONSOLE
Abbildung 50 : Der Testaufbau für die RollCall/RollMap-Managementstation
Diese Softwarestruktur resultiert aus den herkömmlichen Methoden (RS422 oder
GPI) zur Überwachung der Produktionstechnik. Das Management von
Komponenten mittels SNMP soll über einen weiteren Software-Prozess RollSNMP
verwirklicht werden. Dieses Produkt befindet sich derzeit in der Einführungsphase.
In der Testumgebung konnte RollSNMP nicht berücksichtigt werden.
87
Anwendung des SNMP
Allerdings beinhaltet RollCall/RollMap einige Möglichkeiten, die
Berücksichtigung der baldigen Einführung von RollSNMP interessant sind.
unter
6.3.1. Die Monitoring – Möglichkeiten durch RollMap
Die Visualisierung der Komponenten und Integration von Daten in die grafische
Repräsentation von RollMap sind als sehr gut zu bewerten. Eine detaillierte
Nachbildung des gesamten Produktionsnetzes von einer Landkartenansicht bis zur
Visualisierung einzelner Statusabfragen einer Komponente ist äußerst anschaulich
(Abbildung 51). Die Handhabung und Erzeugung der Darstellungen kann leicht
vorgenommen oder modifiziert werden.
Abbildung 51 : Die grafische Einbindung der überwachten Komponenten. Links: reelle
Komponentennachbildung; Rechts: Darstellung des Signalpfades (Screenshot aus der
Testinstallation)
6.3.2. Die RollMap Software als Proxy
Die Monitoring Applikation RollMap enthält eine Anbindung an einen SNMP
Agenten. Diese Anbindung erlaubt die Generierung von Trapnachrichten bei
erkannten Fehlzuständen in der überwachten RS422 und GPI Umgebung.
RollMap fungiert als Proxy Agent. Dabei ist es möglich, RollMap in eine
Managementstation höherer Hierarchie zu integrieren. Im Verlauf der Tests wurde
der Node Manager als Empfänger der RollMap-Traps eingerichtet (siehe Abbildung
50). Alle Fehlzustände der RollCall Komponentenumgebung konnten durch den
Node Manager erfasst werden.
Die RollMap Applikation ist somit ein Beispiel für die Überwachung von Software
durch SNMP.
88
Anwendung des SNMP
6.3.3. Die Schwächen von RollCall/RollMap
RollCall und RollMap bieten im Sinne des SNMP Models keine Funktionalität für
eine Managementstation. Die Überwachung beschränkt sich auf die Schnittstellen
RS422 und GPI und folgt somit einem proprietären Charakter. Die Integration von
SNMP fähigen Komponenten ist ausgeschlossen. RollMap könnte lediglich als
Proxy-System für SNMP dienen.
Die Einführung von RollSNMP könnte diese Schwächen beheben.
Die Aufzeichnung von Managementdaten über einen längeren Zeitraum ist in der
RollMap Software nicht berücksichtigt. Ebenso ist eine Darstellung von
langfristigen Statistiken nicht vorhanden. Auch RollSNMP wird diese Schwächen
wohl nicht beheben.
89
Anwendung des SNMP
7. Zusammenfassung und Ausblick
7.1. Zusammenfassung
Die ausgeführten Arbeiten geben einen Überblick über die Möglichkeiten des
Managements mittels SNMP für die Bereiche der Fernsehproduktion. Aus der
Betrachtung der SNMP Standardisierung ergibt sich die unbedingte Nutzung der
Version 3 für einen möglichen Einsatz.
Es zeigt sich darüber hinaus, dass ein SNMP Dienst für eine Vielzahl von
Komponenten nachrüstbar oder erweiterbar ist. Neben der Überwachung der
Hardware einiger Komponenten ist es durch SNMP möglich, die jeweils integrierte
Software mit einzubinden.
Allerdings fehlen die nötigen MIB Standards für den fernsehtechnischen
Produktionsbereich zur Festlegung der SNMP Funktionalität. Bemühungen auf
diesem Gebiet finden statt, eine umfassende Broadcast MIB wird noch einige Zeit
auf sich warten lassen.
Die tägliche Arbeit mit einem SNMP basierten Managementsystem erfolgt über die
Management-Applikation. Durch eine Vorbetrachtung der Anforderungen dieser
Applikationen lassen sich Kriterien ableiten, die hilfreich bei der Wahl einer
Management-Applikation sind. (siehe Kapitel 4.)
Die Umsetzung des SNMP in den Testkomponenten zeigt sich als äußerst
unterschiedlich. Die MIB2 Gruppe wird teilweise nicht berücksichtigt. Zudem
ergeben sich einige Schwierigkeiten bei verwendeten Datentypen in den SNMP
Implementierungen. Diese treten besonders bei der Nutzung von ManagementApplikationen auf, die solche Daten auswerten.
Messgeräte nehmen im Rahmen des Managements eine besondere Rolle ein. Die
SNMP Implementierungen beinhalten eine Vielzahl von Objekten. Eine umfassende
Kontrolle solcher Messgeräte über eine Managementstation ist nur durch zusätzliche
Software sinnvoll.
Bei der Integration von Komponenten in eine Management-Applikation bedarf es
zuvor einer Analyse der Umsetzung des SNMP jeder einzelnen Komponente. Diese
Arbeit beschreibt anhand von Beispielen, wie solche Analysen durchgeführt werden
können.
Der Vergleich von Managementstationen aus der IT und aus dem Broadcastbereich
zeigt einen eindeutigen Vorsprung der Lösungen aus der IT. Diese entsprechen
einem offenen Managementcharakter, der für eine heterogene Umgebung nötig ist.
Zudem bieten sie eine Vielzahl von Möglichkeiten der zusätzlichen und
nachträglichen Anpassung. Eine Zusammenarbeit mit den entsprechenden IT
Unternehmen zur Umsetzung eines Broadcast-Managementsystems ist allerdings
nötig.
Dem gegenüber stehen Überwachungsapplikationen auf Basis des SNMP einiger
Broadcasthersteller. Diese befinden sich in der Einführungsphase. Die derzeitigen
Applikationen haben Schwächen in den Bereichen Offenheit und Erweiterbarkeit
durch Komponenten von Fremdherstellern.
Die ganzheitliche Überwachung der gesamten vernetzten Produktionsumgebung ist
derzeit weder mit den Produkten der IT noch denen der Boadcasthersteller möglich.
90
Anwendung des SNMP
Die Transportmechanismen der IT können mit SNMP kontrolliert werden.
Schwierigkeiten bei der Überwachung der Produktionsumgebung stellen die
speziellen Übertragungstechniken dar. Für das Management von SDI und SDTI
Strecken wird eine standardisierte MIB Berücksichtigung verlangt.
Durch die Überwachung mittels SNMP können einzelne Komponenten der
Produktionsumgebung überwacht werden. Die Kontrolle und Überwachung der
gesamten Geschäftsprozesse mittels SNMP können derzeit nicht gewährleistet
werden.
In zukünftigen Arbeiten ist dies eine mögliche weitere Aufgabenstellung, und zwar
wäre zu klären. inwiefern SNMP fähig ist, Geschäftsprozesse und Arbeitsabläufe zu
überwachen.
7.2. Ausblick
Die Untersuchungen haben gezeigt, dass SNMP in der Lage ist, Problemstellungen
der Messtechnik in der Fernsehproduktion zu lösen. Bisherige Lösungen
ermöglichen ein Management von einzelnen Komponenten oder von mehreren
Komponenten einzelner Hersteller. Auf dem Weg zu einer generellen ManagementAnwendung für die TV Produktion ist noch einige Standardisierungsarbeit zu
leisten.
Die Bemühungen zu einer Standard Broadcast MIB sollten von den Herstellern
unterstützt werden. Parallel zu diesem Prozess sollten die bestehenden ManagementApplikationen an die neuen Standards angepasst werden.
Empfehlenswert ist die Zusammenarbeit mit den Unternehmen der IT. IBM oder
Hewlett Packard könnten an der Umsetzung der Broadcast MIB in Applikationen
eingebunden werden. Genutzt wird dabei die Grundlage der Node Manager oder
Tivoli Software, die den entsprechenden MIB Voraussetzungen angepasst und
erweitert werden.
Besonders die nötige Anpassung der Pollingverfahren (siehe 6.1.1) und der Controlund Monitoring-Möglichkeiten muss für die Lösungen der IT berücksichtigt werden.
Die Applikationen der Broadcastindustrie stehen in der Entwicklung zum offenen
Management am Anfang. Mittlerweile gibt es erste Ankündigungen für eine
Änderung dieser Lösungen zu einer herstellerunabhängigen Anwendung. Aus
diesem Grund müssen die Lösungen der Broadcasthersteller entsprechend den
Änderungen jeweils neu untersucht werden. Zur Verfügung steht dazu eine von
dieser Arbeit ausgehende Testplattform.
91
Anwendung des SNMP
92
Anwendung des SNMP
ANHANG A-1
Komponenten, die SNMP-fähig zu den jeweiligen Versionen sein wollen, müssen
die folgenden RFC implementieren. Es ist darauf hingewiesen, dass der
Versionsaufbau abwärts kompatibel ist. Version 3 Agenten müssen die Version 2
und Version 1 Standards enthalten.
RFC
1155
1157
1212
1213
1215
Beschreibung
Struktur
und
Identifikation
von
Managementinformationen für TCP/IP
basiertes Internet
Management
Information
Base
Definitionen
Management Information Base 2
Vorschriften zur Trapdefinition für SNMP
Tabelle 6 : RFC Standards der SNMPv1
RFC
1901
2578
2579
2580
3416
3417
3418
3584
Beschreibung
Einführung
zu
community-based
SNMPv2
Structure of Management Information für
SNMPv2 (SMIv2)
Textvereinbarungen für Version 2
Textual Conventions für Version 2
Protokolloperationen für Version 2
Transport Mapping für Version 2
MIB für SNMPv2
Koexistenz zwischen Version 1 und 2 des
SNMP
RFC
3410
3411
3412
3413
3414
3415
3584
Beschreibung
Einführung in das Framework der
Version 3 des SNMP
Beschreibung der Architektur für
SNMPv3
Message Processing und Dispatcher für
das SNMPv3
SNMPv3 Applications
User-based Security Model für Version 3
View-based Access Control Model für
SNMPv3
Koexistenz zwischen den Versionen
1/2/3
A
Anwendung des SNMP
ANHANG A-2
Auszüge aus der AVDC100-MIB (siehe CD Anhang B-2 TestMIBs):
Anhand des Objektes currentMode wird beispielhaft die Struktur des Objekt-Typ
MACROS beschrieben.
DEFINITIONS ::= BEGIN
-- Title : SNMP Support for Avdc100 / Beginn des ASN.1 MIB Moduls für
den AVDC100
IMPORTS -- Übernahmen von Deklarationen aus anderen MIB-Strukturen
MODULE-IDENTITY,
OBJECT-TYPE, IpAddress
FROM SNMPv2-SMI
TRAP-TYPE
FROM RFC-1215
DisplayString
FROM SNMPv2-TC
enterprises
FROM RFC1155-SMI
;
-- Module Identification Definition /
--Beschreibung der Baumstruktur unterhalb des enterprise Zweiges
tekVbuAvdc100ModId MODULE-IDENTITY
LAST-UPDATED "0102220930Z"
ORGANIZATION "Tektronix"
CONTACT-INFO "Tech Support, Tektronix Inc., SW Braun Ave Beavertion"
DESCRIPTION "This is a MIB module for avdc100."
::= { enterprises 1 }
tek
OBJECT IDENTIFIER ::= { enterprises 128 }
tvt
OBJECT IDENTIFIER ::= { tek 5
}
tvtproducts OBJECT IDENTIFIER ::= { tvt 1
}
tvtmibs
OBJECT IDENTIFIER ::= { tvt 2
}
avdc100
OBJECT IDENTIFIER ::= { tvtproducts 6 }
mode
status
config
OBJECT IDENTIFIER ::= { avdc100 1 }
encoder
OBJECT IDENTIFIER ::= { config 1 }
decoder
network
remoteControl OBJECT IDENTIFIER ::= { config 5 }
serialPort OBJECT IDENTIFIER ::= { config 6 }
allSettings OBJECT IDENTIFIER ::= { config 7 }
B
Anwendung des SNMP
-- Operating mode.
currentMode OBJECT-TYPE
--currentMode Objektdefinition durch das Object-Type MACRO
SYNTAX INTEGER
--Angabe des Datentypes des Objektes
{
encoder(1),
decoder(2),
bypass(3)
--Enumerations, geben eine textliche Zuordnung für Integerwerte
}
MAX-ACCESS
read-write
--Zugriffsrecht durch SNMP auf den Wert des Objektes
STATUS
current
--gibt an, ob das Objekt genutzt wird
DESCRIPTION
"Mode of operation of avdc."
--textliche Beschreibung der Objektfunktion
::= { mode 1 }
--Position des Objektes in der Baumstruktur
--(hier Untergruppe mode, Objektposition 1)
… weitere Objekt-Beschreibungen der AVDC 100 MIB …
-- avdc100 traps
-- The oids for traps start from 8. Others
--Beschreibung der durch den AVDC100 möglichen Trapsendungen .
videoStatus
TRAP-TYPE
--Macro Typ
ENTERPRISE avdc100
VARIABLES { sdiDeserializer } --mitgesendete MIBVariablen
DESCRIPTION "Video Status."
::= 8
--TrapOID
… weitere Trap-Beschreibungen der AVDC 100 MIB …
END
C
Anwendung des SNMP
ANHANG B-1
Definierte Trapsendungen der AVDC100 MIB
TRAPSENDUNGEN
TrapTyp
Auslösendes Event
Mitgelieferte Daten
videoStatus
Videosignal liegt an;
Videosignal liegt nicht an
"videosignal liegt (nicht) an"
+ Wert des LTC
LossConfidenceFlag
Verlust oder Widererkennung des
confidence flag
"Verlust/OK des Confidence flag"
+ Wert des LTC
TimeCode
LTC liegt an;
LTC liegt nicht an
"Liegt (nicht) an" + Wert des LTC
SdiDeserializerLocked
Deserialiser gesperrt
"SDI Deserializer locked" + Wert
des LTC
SdiDeserializerNoVideo Kein Video beim SDI deserializer
"no video " + Wert des LTC
SdiDeserializerTrs
TRS liegt (nicht) an
"TRS present at" + Wert des LTC
SdiDerserializerEdh
EDH (nicht) vorhanden
"EDH present at" + Wert des LTC
Wasserzeichen wird aktiv oder
watermarkIsPassive
passiv / im Encoder Modus
Tabelle 9 : Trapsendungen der AVDC100 MIB
"watermark is passive/active" +
Wert des LTC
ANHANG B-2
Die MIB Module der Testkomponenten sind auf der beigelegten CD zu finden. Im
Verzeichnis TestMIBs sind die jeweiligen Module für AVDC100, ProfileXP und
DVQ hinterlegt.
Zusätzlich ist in diesem Verzeichnis eine Software von MGSoft beigefügt. Diese
enthält einen MIB Compiler, der die jeweilige MIB Module darstellt und in einer
Baumdarstellung visualisieren kann.
Zusätzlich bietet diese Software ausreichenden Support zur Generierung von ASN.1
MIB Modulen, sowie einen MIB Browser. Bei der Arbeit mit SNMP ist diese
Software ein wertvolles und anerkanntes Werkzeug.
Die beigefügte Version ist eine eingeschränkte Evaluierungssoftware.
D
Anwendung des SNMP
ANHANG B-3:
Die Variablen der Trapsendungen des DVQ. Zur Beschreibung des Inhalts der
einzelnen Objekte ist auf Anhang B-2 zu verweisen.
srqEvent TRAP-Objekte
identification (OID 1.3.6.1.4.1.2566.3.2.1.1.1)
scpiStatusByte (OID 1.3.6.1.4.1.2566.3.2.1.1.3)
statOperCond (OID 1.3.6.1.4.1.2566.3.2.1.3.2.1)
statQuesCond (OID 1.3.6.1.4.1.2566.3.2.1.3.3.1)
statQuesInputCond (OID 1.3.6.1.4.1.2566.3.2.1.3.4.1)
statQuesRefCond (OID 1.3.6.1.4.1.2566.3.2.1.3.5.1)
tsAlarmTrap TRAP-Objekte
systemDate (OID 1.3.6.1.4.1.2566.3.2.1.2.2)
tsAlarmTrapTime (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.1)
tsAlarmTrapEventType (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.2)
tsAlarmTrapEventValue (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.3)
tsAlarmTrapEventDuration (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.4)
tsAlarmTrapTsId (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.5)
tsAlarmTrapOriginalNetworkId (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.6)
tsAlarmTrapServiceId (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.7)
tsAlarmTrapPacketId (OID 1.3.6.1.4.1.2566.3.2.1.11.100.1.8)
ituAlarmTrap TRAP-Objekte
systemDate (OID 1.3.6.1.4.1.2566.3.2.1.2.2)
ituAlarmTrapTime (OID 1.3.6.1.4.1.2566.3.2.1.11.100.2.1)
ituAlarmTrapEventType (OID 1.3.6.1.4.1.2566.3.2.1.11.100.2.2)
ituAlarmTrapEventValue (OID 1.3.6.1.4.1.2566.3.2.1.11.100.2.3)
ituAlarmTrapEventDuration (OID 1.3.6.1.4.1.2566.3.2.1.11.100.2.4)
Tabelle 10 : Die Variablen der Trapsendungen der DVQ MIB
ANHANG C-1
Eine Darstellung der Netzlast durch die Pollingverfahren des Node Manager. Die
zugrunde liegenden Mitschnitte des Datenverkehrs sind auf der beigefügten CD im
Verzeichnis „NetzlastOpenview“ zu finden. Die verwendete Software Ethereal
0.10.6 ist ebenfalls dort zu finden.
E
10 Kbit/s
1 Stunde
5 Kbit/s
F
Grün: TCP (Configuration Poll)
Rot: SNMP (Configuration, Discovery, Status Poll)
Blau: ICMP (Status Poll)
Netzlast 1-er Segment
(36 Netzkomponenten durch den Node Manager erfasst, davon 8
mit SNMP Agent)
Netzlast 212 - Segment
(16 Komponenten durch den Node Manager erfasst, davon 5 mit
SNMP Agent)
Minimale durchschnittliche
Netzbelastung durch die
Pollingverfahren
! ABER !
Sie steigt mit zunehmender
Netzgrösse!
Die Netzlastanalyse liegt Mitschnitten des Datenverkehrs
der Managementstation zugrunde. Der Mitschnitt wurde
durch die Ethereal Software Version 0.10.6 vorgenommen
Anwendung des SNMP
1 Stunde
Anwendung des SNMP
ANHANG D-1
Die Erzeugung von Objektrepräsentationen auf der Node Manager GUI erfolgt
durch Einträge in den folgenden Textfiles. Alle nötigen Text Dateien für die
AVDC100 und DVQ Objekte sind auf der CD im Verzeichnis „Objektdefinition“
hinterlegt.
Beispieleintrag in der „oid_to_sym“ Datei:
1.3.6.1.4.1.295.3.2:Connector:Ethernet
# Plaintree WaveSwitch 100
1.3.6.1.4.1.1916.2.*:Connector:Bridge
# Extreme Networks Switches
1.3.6.1.4.1.2566.3.2:TVDevice:DVQ
# rohde & schwarz DVQ
TVDevice Typ im „Objektdefinitionen\ symbols_C\TVDevice“ Ordner:
/* Muster Produktions-Symboltyp */
SymbolClass "TVDevice"
{
Scale 3;
Segment (0,3) to (-1,2) to (-2,2) to (-2,1) to (-3,0) to (-2,-1) to (-2,-2) to (-1,-2) to
(0,-3) to (1,-2) to (2,-2) to (2,-1) to (3,0) to (2,1) to (2,2) to (1,2);
DefaultLayout RowColumn;
Filebase "tvtyp";
Capabilities
{
isIP=1;
isNode=1;
isdvq=1;
}
DisplayString "Produktion";
}
Verweis auf tvtyp als Basis für das Bild auf dem Hintergrund.
In Verzeichnis „TVDevice“ finden sich diese Bilder als Pixmapformat. Diese
Dateien sind auf der beigelegten CD im Verzeichnis
„Objektdefinitionen\bitmaps_C\TVDevice“ hinterlegt; 8 Stück , 6 direkte
Pixmapdateien (*.pm) und 2 Konfigurationsdateien.
G
Anwendung des SNMP
ANHANG D-2
Der ARF der DVQ Integration. Alle weiteren Files sind im Verzeichnis
„ARF\registration_C\eigene“ auf der CD zu finden:
Application "Messung_DVQ"
{
Version "SNMP set 1.0";
DisplayString "DVQ_Messung";
Description {
"Einstellungen der Messfunktionen"
}
Copyright {
"Tobias Lausberg",
"all rights reserved"
}
Menubar <100> "DVQ" {
<100> "Messung"
Context(AllContexts)
f.menu messen;
}
Menu messen {
<100> "starten"
f.action mess_start;
<100> "anhalten"
f.action mess_stop;
<100> "weiter"
f.action mess_fortsetzen;
}
Action mess_start {
DisplayString "Mess_Start";
SelectionRule isdvq;
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/mess_start";
}
Action mess_stop {
DisplayString "Mess_Stop";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/mess_stop";
}
Action mess_fortsetzen {
DisplayString "Mess_fortsetzen";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/mess_fortsetzen";
H
Anwendung des SNMP
}
Action messwert {
DisplayString "Messwert_DVQW";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/cygwin/home/administrator/dvq/messbeg";
}
Action messmodus {
DisplayString "Messmodus";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/messung/messmodus";
}
Action messdauer {
DisplayString "Messdauer";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/messung/messdauer";
}
Action messparameter {
DisplayString "messparameter";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/messung/messparameter";
}
Action messdarstellung {
DisplayString "messdarstellung";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/messung/messdarstellung";
}
Action Senderwahl {
DisplayString "Senderwahl";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/DVQ/messung/sendereinstellung";
}
Action tssender {
DisplayString "sender im TS";
MinSelected 1;
MaxSelected 1;
Command "d:/openview_pro/bin/cygwin/home/administrator/dvq/tsprog/geleitet";
}
}
I
Anwendung des SNMP
ANHANG D-3
Die Ablaufpläne der zusätzlichen Programme für tsprog.c und sendereinstellung.c
folgen hier. Im Verzeichnis „zusätzliche Programme NNM“ sind alle Programme zu
finden (zusätzliche Programme NNM\BIN_cygwin_home_administrator), sowie die
Batch-Aufrufe durch die sie vom ARF aus gestartet werden. Auch die
Installationsdatei der cygwin-Umgebung ist in diesem Verzeichnis zu finden.
Das Mail-Tool des Punktes 6.1.6 ist im Verzeichnis „zusätzliche Programme
NNM/BATCH/mailto“ zu finden.
Abbildung 52 : Ablaufplan der Datei sendereinstellung.c (Verzeichnis „zusätzliche Programme
NNM/ BIN_cygwin_home_administrator\DVQ\measurement“)
J
Anwendung des SNMP
Abbildung 53 : Ablaufplan der Datei tsprog.c (Verzeichnis „zusätzliche Programme NNM/
BIN_cygwin_home_administrator\DVQ\TSProg“)
K
Anwendung des SNMP
Literaturverzeichnis:
[1]
J.D Case, M. Fedor, M.L Schoffstall, J. Davin: Simple Network
Management Protocol (SNMP). RFC 1157, May 1990.
[2]
Internet Assigned Numbers Authority:
http://www.iana.org/assignments/port-numbers. erreichbar 9.November
2004.
[3]
M. Hein, D. Griffiths: SNMP Simple Network Management Protocol
Version 2, SNMPv2 in Theorie und Praxis. 1. Auflage International
Thomson Publishing GmbH 1994.
[4]
SimpleWeb: www.simpleweb.org/ietf/rfcs/rfcbytopic.html. erreichbar
9.November 2004.
[5]
J.Flick: Definitions of Managed Objects for the Ethernet-like Interface
Types. RFC 3635, September 2003.
[6]
J.Case, A.Rijsinghani: FDDI Management Information Base. RFC 1512,
September 1993.
[7]
K.Tesink: Definitions of Managed Objects for ATM Management. RFC
2515, February 1999.
[8]
K.Teow: Definitions of Managed Objects fort he Fabric Element in Fibre
Channel Standard. RFC 2837, May 2000.
[9]
M. Hein: Kundenspezifische Schulung SNMP: ComConsult Technologie
Information, März 2004.
[10]
W. Gora, R. Speyerer: ASN.1 Abstract Syntax Notation One. Pulheim:
Datacom-Buchverlag 1987.
[11]
R. Jansen, W. Schott: SNMP Konzepte-Verfahren-Plattformen.
Bergheim: Datacom-Buchverlag 1993.
[12]
R.Presuhn: Version 2 of the Protocol Operation for the Simple Network
Management Protocol (SNMP). RFC 3416, December 2002.
[13]
J.Case, K.McCloghrie, M.Rose, S.Waldbusser: Manager-to-Manager
Information Base. RFC 1451, April 1993.
[14]
D.Harrington, R.Presuhn, B.Wijnen: An Architecture for Describing
Simple Network Management Protocol (SNMP) Management
Frameworks. RFC 3411, December 2002.
[15]
K.McCloghrie, D.Perkins, J.Schoenwaelder: Structure of Management
Information Version 2 (SMIv2). RFC 2578, April 1999.
L
Anwendung des SNMP
[16]
K.McCloghrie, D.Perkins, J.Schoenwaelder: Conformance Statements
for SMIv2. RFC 2580, April 1999.
[17]
K.McCloghrie, M.T.Rose: Management Information Base for Network
Management of TCP/IP-based internets:MIB-II. RFC 1213, March 1991.
[18]
U.Blumenthal, B.Wijnen: User-based Security Model (USM) for version
3 of the Simple Network Management Protocol (SNMPv3). RFC 3414,
December 2002.
[19]
B.Wijnen, R.Presuhn, K.McCloghrie: View-based Access Control Model
(VACM) for the Simple Network Management Protocol (SNMP). RFC
3415, December 2002.
[20]
W.Stallins: Security Comes to SNMP-The New SNMPv3 Proposed
Internet Standards. Internet Protocol Journal December 1998 Volume 1:
Number3, http://www.cisco.com/warp/public/759/ipj_1-3/ipj_13_snmpv3.html, erreichbar 9.November 2004.
[21]
R.Frye, D.Levi, S.Routhier, B.Wijnen: Coexistence between Version 1,
Version 2, and Version 3 of the Internet-standard Network Management
Framework. RFC 3584. August 2003.
[22]
www.internet-und-sicherheit.de, erreichbar 9.November 2004.
[23]
Erik Hia: Secure SNMP-Based Network Management in Low Bandwidth
Networks. Virginia Polytechnic Institute and State University 2001.
[24]
Heise online: Verunsicherung um Sicherheit von Kryptoalgorithmen.
www.heise.de/newsticker/meldung/mail/50148, erreichbar 9.November
2004.
[25]
Shin Tsuda: New Work Style for maintenance of Professional AV/IT
Equipment with the MMStation Application.
http://bssc.sel.sony.com/Professional/service/pdfs/MMStation_White_Pa
per.pdf, eSP Department, BSNC B&P Company, Sony Corporation,
March 6 2003, erreichbar 9.November 2004.
[26]
L. Leidag: Overview of the work and goals of the KPV working group
Public-MIB. Institut für Rundfunktechnik GmbH, Abteilung Broadcast
Networks and Servers, 2004.
[27]
APW Electronics Ltd.: Active Rak Controller, Anwenderhandbuch
Schranküberwachung. APW Electronics Ltd. 1999.
[28]
S.Waldbusser: Application Performance Measurement MIB. RFC 3729,
March 2004.
[29]
C.Kalbfleisch, C.Krupczak, R.Presuhn, J.Saperia: Application
Management MIB. RFC 2564, May 1999.
M
Anwendung des SNMP
[30]
Wikipedia-The free Encyclopedia:
http://de.wikipedia.org/wiki/Management. erreichbar 9.November 2004.
[31]
IBM: http://www-306.ibm.com/software/tivoli/products/enterpriseconsole/. erreichbar 9.November 2004.
[32]
Hewlett-Packard: www.openview.hp.com. erreichbar 9.November 2004.
[33]
Computer Associates International: www.ca.com. erreichbar
9.November 2004.
[34]
Thomson Grass Valley Inc.:
www.thomsongrassvalley.com/products/c2md/netcentral/. erreichbar
9.November 2004.
[35]
Dimetis: www.dimetis.de. erreichbar 9.November 2004.
[36]
Thomson Grass Valley Inc.:
http://www.thomsongrassvalley.com/products/servers/pvs1100/.
erreichbar 9. November 2004.
[37]
Rohde & Schwarz: http://www.rohde-schwarz.com. Digital Video
Quality Analyzer R&S DVQ - Data sheet (english), erreichbar
9.November 2004.
[38]
Hewlett-Packard Company: Managing your Network with HP OpenView
Network Node Manager. May 2002.
[39]
Hewlett-Packard Company: Reporting and Data Analysis with HP
OpenView Network Node Manager. May 2002.
[40]
Hewlett-Packard Company: A Guide to Scalability and Distribution for
HP OpenView Network Node Manager. May 2002.
[41]
Cygwin: www.cygwin.com. erreichbar 9. November 2004.
[42]
Thomson Media and Broadcast Solution: NetCentral TV Facility
Monitoring System User Guide. Software Version 4, June 2004.
[43]
Thomson Media and Broadcast Solution: NetCentral Version 4.0.2
Release Notes. 2004.
[44]
Thomson Grass Valley Inc.: System Guide-Profile XP PVS Series. July
2001.
N

Evaluierung des Systemmanagement in IT basierten TV

Transcrição

Documentos relacionados

Netzwerkadministration

Automatischer Leitungsumschalter

LCS-PS110

Sicherheit in VoIP- und uC-Netzwerken

Ultraschall Durchflussmesser für Kleinstmengen

Windows Netzwerk-Inventarisierung Netzwerk

Kunena - AntonForster.com

Ausschreibung Gilde Cup 2016 - Turnierportal TV Mittelrhein

Action-Figuren - Clicker Spiele

GoToDevice Remote Control mit G/On