Evaluierung des Systemmanagement in IT basierten TV. Produktionsumgebungen unter Anwendung des Simple. Network Management Protocol

Transkript

1 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

2 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

3 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

4 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

5 Inhaltsverzeichnis: Kurzfassung...i Abbildungsverzeichnis...v Tabellenverzeichnis...vii Akronyme...vii 1. Einleitung und Aufgabenstellung Grundlagen des SNMP Management Das Managementkonzept mittels SNMP Unterlagerte Dienste Der Transport von SNMP Die Management Information Base-MIB Der Aufbau der Managementinformationen Die standardisierten Versionen des SNMP Die SNMP Version Die SNMP Version Die SNMP Version 3, Die Datensicherheit des SNMP Voraussetzungen für eine Integration von SNMP in die TV Produktion Anforderungen an einzelne Komponenten durch SNMP Der Standardisierungsprozess von broadcastspezifischen MIB Modulen Die aktuelle Situation der MIB Implementierung Möglichkeiten der Einbindung von Geräten ohne SNMP Unterstützung Die Nachrüstung des SNMP Dienstes durch zusätzliche Software Die Überwachung von Software mittels SNMP Aufgaben des Managements in der TV Produktion Kriterien des Systemmanagement Aufgaben des Agenten der Einzelkomponenten in der Produktion Aufgaben des Managers der Managementstation in der Produktion Aufgaben der Systemmanagement Applikation: Bestehende Systemmanagementlösungen Eine Auswahl von Systemmanagement-Applikationen Die Testbedingungen für Management-Applikationen Die Testumgebung für das Systemmanagement Die Geräte der Testumgebung und ihre Möglichkeiten Der Audio and Video Delay Corrector 100 (AVDC) Der Profile XP Media Platform PVS Der Digital Video Quality Analyser (DVQ)...49 iii

6 6. Die Inbetriebnahme von ausgewählten Managementapplikationen Die Installierung des Network Node Manager von HP-Openview Die Erkennung und Darstellung des Netzwerkes Zuverlässigkeit der Netzerkennung Das Grundlayout Die Anpassung der Darstellung an das Broadcastumfeld Standard-Tools zur Analyse von Managementdaten Das Error-Mapping des Node Managers Die Einbindung von Broadcastkomponenten Die vereinfachte Softwarestruktur des Node Managers Die Nutzung der offenen Softwarestruktur Das Controlling und Monitoring der Testkomponenten Beurteilung des Node Managers zum Einsatz in der TV-Produktion Die Management-Applikation NetCentral von Grass Valley Die Installation der Managementstation Die Erkennung der Netzkomponenten Die Funktionalität der NetCentral Managementstation Das Monitoring der Komponenten Das Error Handling von NetCentral Weitere Funktionalitäten Beurteilung der NetCentral Managementstation Die Applikation RollCall und RollMap Die Monitoring Möglichkeiten durch RollMap Die RollMap Software als Proxy Die Schwächen von RollCall/RollMap Zusammenfassung und Ausblick Zusammenfassung Ausblick...91 ANHANG...A Literaturverzeichnis... L iv

7 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 Play- Out [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

8 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 NetCentral- Applikation (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

9 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 7 : RFC Standards der SNMPv2...A Tabelle 8 : RFC Standards der SNMPv3...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

10 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

11 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

12 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

13 2. Grundlagen des SNMP Management Erste Überlegungen hin zu einem Netzwerkmanagement entstanden in der IT Industrie 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 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 Manager und Agent folgt einfachen Kommunikationsszenarien. Der Manager (Client) kann Werte der Agentenkomponente abfragen. Dazu stehen durch SNMP mehrere Kommandos bereit 3

14 (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) Internet(1) directory(1) Mgmt(2) Experimental(3) Private(4) directory(1) Mgmt(2) Experimental(3) Private(4) mib2(1) enterprises(1) mib2(1) enterprises(1) system(1) Interfaces(2)... IRT(19831) system(1) sysdescr(1) sysobjectid(2) sysuptime(3) syscontact(4) sysname(5) syslocation(6) sysservice(7) Interfaces(2)... IRT(19831) Hersteller 1 Hersteller 1 Ifnumber(1) iftable(2) ifentry(1) ifindex(1) ifdescr(2) sysdescr(1) sysobjectid(2) sysuptime(3) syscontact(4) sysname(5) syslocation(6) sysservice(7) Ifnumber(1) iftable(2) ifentry(1) 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

15 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

16 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 IT- Netzwerktechnologie 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

17 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) = (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

18 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 Trap- Sendungen 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 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 ). 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 ) 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 Das Institut für Rundfunktechnik hat die Nummer zugeteilt bekommen. Unterhalb der OID 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

19 ATM MIB [7], FibreChannel MIB [8] Diese können ein Management der entsprechenden Netzwerktechnologien gewährleisten 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 OBJECT-TYPE Definition des Inhalt einer Objektbeschreibung NOTIFICATION-TYPE Beschreibung der möglichen Trapsendungen einer Komponente 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

20 SNMP Typ Beschreibung Integer Octet String ipaddress Counter Gauge Timeticks Unsigned Table Tabelle 2 : Datentypen innerhalb des SNMP Modells [15] 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 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 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 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

21 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 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-zu- Manager 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) 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

22 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

23 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 set- Abfragen 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

24 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

25 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 im Anhang auf CD zu finden 15

26 ********************************************************************************* Simple Network Management Protocol Version: 2C (1) Community: PUBLIC PDU type: RESPONSE (2) Request Id: 0x Error Status: NO ERROR (0) Error Index: 0 Object identifier 1: (iso ) Value: Timeticks: ( ) 2 days, 3:36:58.21 Object identifier 2: (iso ) Value: STRING: "72,72" Object identifier 3: (iso ) Value: INTEGER: Object identifier 4: (iso ) Value: INTEGER: Object identifier 5: (iso ) Value: INTEGER: Object identifier 6: (iso ) Value: INTEGER: ********************************************************************************* Diese Daten beruhen auf dem folgenden Klartext. Der Community String PUBLIC ist eindeutig zu erkennen. ******************************************************************************* * b3 98 b6 df b E be e9 b bd c0 a8 02 b6 c0 a8...@ b7 00 a1 0d aa f X c a PUBLIC...f b b 89 3d d 2b...C....= c d 2b , c d 2b 06...D ea e a d 2b b d 2b c ea e ********************************************************************************* 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

27 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

28 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

29 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 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

30 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 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

31 ******************************************************************* irt OBJECT IDENTIFIER ::= { enterprises 19831} broadcast OBJECT IDENTIFIER ::= { irt 1} transmitter OBJECT IDENTIFIER ::= { broadcast 1} operational OBJECT IDENTIFIER ::= { transmitter 1} maintenance OBJECT IDENTIFIER ::= { transmitter 2} baseband OBJECT IDENTIFIER ::= { broadcast 2} multiplexer OBJECT IDENTIFIER ::= { baseband 1} production OBJECT IDENTIFIER ::= { irt 2} server OBJECT IDENTIFIER ::= { production 1} camera OBJECT IDENTIFIER ::= { production 2} mixer OBJECT IDENTIFIER ::= { production 3} storage OBJECT IDENTIFIER ::= { production 4} measurement OBJECT IDENTIFIER ::= { irt 3} networking OBJECT IDENTIFIER ::= { irt 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 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

32 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 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 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

33 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

34 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 Agent 2 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ß 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 Trap- 2 Teile der Abbildung 12 basieren auf [27] 24

35 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) 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

36 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

37 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, 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

38 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

39 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

40 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 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: - WinSNMP 3 ist die SNMP API der Windows Betriebssysteme - SNMP Research International Inc. 4 ist eine Plattform unabhängige SNMP API - Net-snmp 5 ist eine Softwareumgebung zur Erzeugung von eigenständigen SNMP Lösungen

41 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

42 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 Managementapplikation 6 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 32

43 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äte- Hierarchieebene (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

44 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 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

45 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 Eine Auswahl von Systemmanagement-Applikationen Zunächst wird ein Blick auf Systemmanagement-Applikationen der IT geworfen. Unter ist ein kleiner aber durchaus repräsentativer Überblick der Management Applikationen der IT zu finden. Bei der Suche nach SNMP- Applikationen 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

46 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 ( 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

47 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 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 SAN- Komponenten. 37

48 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 * 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 * eingebunden. Den Aufbau dieses Testnetzes beschreibt Abbildung

49 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

50 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 * installiert. Das DVQ ist in eine Empfangskette von digitalen Fernsehtransportströmen integriert. Er gehört dem Netzsegment * 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 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 Systemmanagement- Applikationen 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 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

51 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 A- 2) im SNMP Dienst abgebildet. Weitere MIB-Module, beispielsweise die MIB2 Gruppe, sind nicht implementiert. Der Objektidentifikator des AVDC Moduls lautet *. 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

52 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 Monitoring- Möglichkeiten der Applikation die folgenden MIB Objekte darstellbar sein. In der Status-Gruppe werden Statusinformationen über SDI, AES, Timcode- Receiver sowie den SDI Deserializer angezeigt. Das mesasuredaudiodelay Objekt (OID ) gibt den Messwert des A/V Delays an, welcher aktuell im Decoder Modus gemessen wird. Das currentaudiodelay-objekt (OID ) 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

53 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 Controlling- Mö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 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

54 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 XP 7 Den ersten Block bildet das Echtzeitsystem. Es kontrolliert alle Ein- und Ausgänge des Profile und regelt die Signalverarbeitung der Video-, Audio- und Timecode- Daten. 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

55 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

56 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 *). 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 *) 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 *) 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: ) zählt beispielsweise alle ausgehenden Frames des Interfaces. 46

57 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 pvsaudio- Gruppe. 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: ) 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 pvspowersupply- Gruppe 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 GPI 8 (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 ). 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

58 Systemreboot kann nicht durch SNMP ausgelöst werden. Die Nutzung von anderen Diensten zur Gewährleistung des Controllings ist notwendig. Problemspezifische Anforderungen: 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 Überwachung nach dem Blockschaltbild (Abbildung 23 ) pvsmodechange Betriebsart des Applikationssystems pvsboardstatuschange Alle Komponenten am PCI Bus (in Abb. 23 weis hinterlegt) pvstempstatuschange Bereiche sonstiger Überwachung Temperaturüberwachung als Schutz vor Überhitzung des Profile XP pvsfanstatuschange Sicherstellung der Lüfterfunktionalität pvspowersupplystatuschange Sicherstellung der Stromversorgung pvsdrivemodulestatuschange Überwachung des pvsraidchassisstatuschange Speichers mit pvsraidcontrollerstatuschange sämtlichen RAID pvsstoragecapacitystatuschange Parametern pvssystemdrivefailure Überwachung der Systemdisk des Applikationssystems Tabelle 3 : Überwachungsbereiche der definierten Traps des Profile XP 48

59 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 RS- 232 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 Ethernet- Schnittstelle 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 ) und snmp (OID ) werden unterstützt. Die Funktionalität des DVQ wird im Modul DVQ-MIB abgebildet. Unterhalb der OID gliedern sich 11 Untergruppen (siehe Abbildung 26). 49

60 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 ) 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 Systemmanagement- Applikation 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 Management- Applikation 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

61 Relevant für die Analyse des TS ist es zu wissen, welche Programme im Strom enthalten sind. Das Objekt readarrayprog (OID ) beschreibt einen String, der die Kennnummern aller enthaltenen Programme des TS liefert. Diese Nummern können über die Untergruppe readarrprog (OID ) 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: *) 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: ) 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: ) 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 *) 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" mögliche Werte cont oder once 10 Einstellungen von 5 Sekunden bis 5 Stunden 51

62 confmeasdetpar (OID *.4.7) confmeasdetdisp (OID *.4.8) 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 confmeascont (OID *.4.15.*) 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 *) Bedeutung readmeasdetailsbitrate (OID *.5.6) readtsbitrate (OID *.5.18) readvideobitrate (OID *.5.19) readaudiobitrate (OID *.5.20) readmeasdetailsdvql (OID *.5.4) Tabelle 5 : Messwerte des DVQ Datenrate des ausgewählten Programms innerhalb des Transportstroms Datenrate des gesamten Transportstroms Datenrate der Videoinformation innerhalb des ausgewählten Programms Datenrate der Audioinformation innerhalb des ausgewählten Programms Messwert der Qualitätsanalyse Problemspezifische Anforderungen: 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 beschrieben. Neben diesen frei wählbaren Schwellwertgrenzen zur Erzeugung von Traps sind auch einige nicht konfigurierbare Auslöseereignisse vorgesehen. Das Objekt tsalarmtrapeventtype (OID ) bzw. itualarmtrapeventtype (OID * ) beschreibt alle möglichen Fehlerursachen. 52

63 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

64 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 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

65 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 : Netzwerkdarstellung der Openview-Applikation (Screenshots aus der Testinstallation) Ein Klasse C Netzwerk der Adressierung 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 IPX 9. 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 *), einige Objekte des iftable der interfaces- Untergruppe (OID *), sowie einige Objekte aus der ip-untergruppe (OID *). 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

66 Besondere Bedeutung hat dabei die system-untergruppe. Das Objekt sysobjectid (OID ) 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 eindeutig beschreiben. Diese Kennung ist im sysobjectid hinterlegt. Erhält der Pollingprozess diesen Wert als Antwort auf die sysobjectid- Anfrage, 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), (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 *) der ip- Untergruppe. 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

67 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

68 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" ~ *) &&!("IP Address" ~ ) &&!("IP Address" ~ )) (isnetwork issegment)} Informationen über mögliche Filter und deren Konfiguration gibt das Openview Manual Scalability and Distribution in Kapitel 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 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

69 erfolgt die Darstellung der Symbole nach den Informationen aus den SNMP Polling- Abfragen. 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 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

70 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 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 Monitoring- Fähigkeiten der Applikation dar. Der Zugriff auf diese erfolgt über die Systemleiste der GUI oder über executable Objects innerhalb einer Darstellungsebene. 60

71 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 ). 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

72 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 sysuptime- Objektes (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

73 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 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

74 Report Presenter: Eine weitere wichtige Funktionalität der Openview Managementstation ist die Generierung von Reporten. Dabei sammelt die Applikationssoftware SNMP Daten, um diese per 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

75 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

76 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 der Sendekomponente und mit $1-3 die übermittelten Objektwerte des Traps in den String eingebunden werden. Es stehen einige solcher Parametervorgaben zur Verfügung ([38], S. 411). Der erzeugte String wird im Alarmbrowser als Beschreibung des Fehlers dargestellt. 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 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 Sendung bei Eingang eines Traps soll die Einrichtung der Automatic Action verdeutlichen. Der Inhalt der DVQ- Trapsendung liegt diesem Konfigurationsbeispiel zu Grunde. Als 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 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

77 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, Messung in Programm 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 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 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 Polling- Verfahren. Der Eintrag :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

78 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 Monitoring- Szenarien unter Punkt 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

79 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, 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 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

80 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 Die Nutzung der offenen Softwarestruktur Zur Realisierung der problemspezifischen Programme wurde eine Cygwin Umgebung 10 [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

81 Abbildung 41 : Ablaufplan der DVQ Messwertkonvertierung durch messung.exe (Anhang D-3) Eine ähnliche Vorgehensweise wurde bei den Problemstellungen der TS- Programmauswertung 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

82 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 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

83 Der DVQ Analyser ist ein Beispiel für Komponenten, die nachträglich mit SNMP ausgerüstet wurden. Der SNMP Dienst bedient sich hierbei der SCPI- Befehlssprache. 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 Analyse- Programm 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 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

84 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 AVDC- MIB 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 Controlling- Funktionalitä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

85 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 Beurteilung des Node Managers zum Einsatz in der TV- Produktion 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

86 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

87 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

88 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 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

89 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 URL 11 - Versendung einer ; entwender direkt oder nach Zeitplan - Abspielen eines Audiofiles - Ausführung eines seperaten Programms; mit Übergabe der Trapparameter - LED 12 Anzeige - Generierung eines Peep-Tons - Triggerung eines GPI 13 -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 Die Installation der Managementstation NetCentral nutzt die Betriebssysteme Windows XP und 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 MSDE 14 Datenbank mit. Diese muss zusätzlich installiert werden. 11 Uniform Ressource Locator; Adresskonvention von www Seiten 12 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 79

90 Die Client/Server Struktur von NetCentral basiert auf.net 15 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 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 ). 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 [ 80

91 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 Pipe 16. 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 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

92 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 VNC- Verbindungen 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

93 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 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

94 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 Tray 17 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 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 ftp 18 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 Signalisierung von laufenden Programmen in der Windows Symbolleiste 18 File Transfer Protocol; IP Dienst zum Datentransfer 84

95 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

96 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

97 HS1 HS2 OK1 OK2 PS COL- ACT- STA- CONSOLE Tobias Lausberg: Evaluierung des Systemmanagement in IT basierten TV Produktionsumgebungen unter 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 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. 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