Bibliographische Beschreibung:

Stippl, Ernst:

Fernwartung von heterogenen IT-Infrastrukturen Konzept und Implementierung eines Prototyps, Wien, Hochschule Mittweida (FH), Fachbereich Technische Informatik, Diplomarbeit, 2005

Referat:

Diese Diplomarbeit hat das Ziel, ein Konzept zur Fernwartung von heterogenen IT-Infrastrukturen zu erarbeiten und eine darauf basierende Implementierung zu beschreiben, welche von Systemintegratoren und Servicepartnern betrieben werden kann.. Dabei sollen Geräte unterschiedlicher Herstellerfirmen, Type und Bauart unterstützt werden. Eingangs werden der technische und wirtschaftliche Hintergrund beschrieben. Weiters erfolgt die Spezifikation der Anforderungen und deren Konzeptierung und Realisierung, sowie eine Darstellung der Hardware- und Softwarekomponenten.

Inhaltsverzeichnis

Inhaltsverzeichnis   

INHALTSVERZEICHNIS.................................................................................................   I

ABK  ÜRZUNGSVERZEICHNIS.  IV

ABBILDUNGSVERZEICHNIS   VII

TABELLENVERZEICHNIS   IX

KAPITEL  ÜBERSICHT  X

VORWORT...................................................................................................................   XII

1  EINLEITUNG.  1

2  STAND DER TECHNIK.  3

2.1  Entwicklung der Ferndiagnose und Fernwartung.  3

2.2  Remote-Service Angebot von Sun Microsystems  8

2.3  Remote-Service der StorageTek Corporation  14

3  PRÄZISIERUNG DER AUFGABENSTELLUNG  17

3.1  Funktionelle Anforderungen  17

3.2  Wirtschaftliche Anforderungen.  19

3.3  Weitere Anforderungen.  21

4  SYSTEMKONZEPT.  22

4.1  Betrachtung möglicher Hardware Konzepte  23

4.2  Gegenüberstellung von Embedded Lösungen.  24

4.2.1  TINI Tiny Network Interface.  25

4.2.2  RCM 2000 / RCM 3000  29

4.2.3  Auswahl der Hardware  31

4.3  Betrachtung möglicher Software Konzepte.  32

4.4  Konzeptentscheidung  33

4.5  Funktion der Fernwartungseinheit  33

4.6  Der Aufbau der Fernwartungseinheit  34

5  DIE ETHERNUT HARDWARE UND SOFTWARE  35

5.1  Das System-Board.  35

5.1.1  Der ATmega128 Microcontroller.  36

5.1.2  Der LAN91C111 LAN Controller  36

5.1.3  SRAM und Flash Speicher  37

5.1.4  Der CPLD Adress-Decoder  38

5.2  Das Betriebssystem Nut/OS  38

5.2.1  Threads.  39

5.2.2  Events.  39

5.2.3  Speicherverwaltung  40

I

Inhaltsverzeichnis

5.2.4  Ein/Ausgabe  41

5.2.5  Device Driver  42

5.3  Der Netzwerk-Stack Nut/Net  43

5.3.1  Data Link Layer  44

5.3.2  Network Layer.  45

5.3.3  Transport Layer  45

5.3.4  Applikations-Layer  45

6  DIE ERWEITERUNGSPLATINE FÜR SERIELLE ANSCHLÜSSE  46

6.1  Die Hardware der Erweiterungsplatine  46

6.1.1  Design und Bauteilauswahl  47

6.1.2  Funktion und Aufbau  49

6.1.3  Der MAX3110E Serial Interface Bauteil  52

6.1.4  Bauteilliste der Erweiterungsplatine  53

6.2  Die Software für die Erweiterungsplatine  53

6.2.1  Ein-/Ausgabe über das Serial Peripheral Interface  53

6.2.2  Interrupt-Behandlung.  55

6.2.3  Der Device-Driver  56

7  DIE APPLIKATIONSSOFTWARE DER FERNWARTUNGSEINHEIT.  57

7.1  Das Konfigurationsprogramm.  60

7.1.1  Globale Einstellungen.  60

7.1.2  Gerätespezifische Einstellungen  62

7.1.3  Speicherung und Konvertierung der Einstellungen.  65

7.1.4  Konfigurationsdaten in der Fernwartungseinheit.  66

7.2  Das zentrale Steuerprogramm  69

7.3  Die aktiven Überwachungsprogramme.  70

7.3.1  Der ICMP Echo Sender  71

7.3.2  Der Request/Response Sender  72

7.3.3  Der SNMP Request Sender  73

7.4  Die reaktiven Überwachungsprogramme  75

7.4.1  Der E-Mail Empfänger  76

7.4.2  Der SNMP-Trap Empfänger  78

7.5  Die Nachrichten-Sender.  79

7.5.1  Der SMS-Sender  80

7.5.2  Der E-Mail-Sender.  82

7.6  Die Benutzerschnittstelle.  84

7.7  Der TFTP Server  91

8  SYSTEMINTEGRATION  93

9  TEST UND INBETRIEBNAHME  97

10  ZUSAMMENFASSUNG  102

10.1  Einschätzung der Ergebnisse  102

10.2  Mögliche Weiterentwicklungen an der Hardware  103

10.2.1  HW-Interrupt-Register auf der Erweiterungsplatine  103

10.2.2  Real Time Clock  104

II

Inhaltsverzeichnis

10.3  Mögliche Weiterentwicklungen an der Software.  104

10.3.1  Dynamische Konfigurationsänderungen  104

10.3.2  HTTP Server statt Telnet-Benutzerschnittstelle.  105

10.3.3  Remote Software Update für die Fernwartungseinheit.  105

10.3.4  Anschluss von speziellen Einzelgeräten.  106

ANHANG. 108   

LITERATURVERZEICHNIS.   112

III

Abkürzungsverzeichnis

ACK ... Acknowledge (positiv) ALOM .. .. Advanced Lights Out Management API .. .. . Application Programming Interface ARP .. .. ... Address Resolution Protocol BOOTP . Boot Protocol CISC .. .. ..... Complex Instruction Set Computer CAN .. .... Controller Area Network CHAP .. .. Challenge Handshake Authentication Protocol CPLD . Complex Programmable Logic Device CPU .. .. .. Central Processing Unit DCE .. . Data Communications Equipment DHCP .. .... . Dynamic Host Configuration Protocol DIMM . ....... Dual Inline Memory Module DNS ... ....... Domain Name System DTE .. . Data Terminal Equipment DTR .. .. ...... Data Terminal Ready EEPROM . ........ Electrically Erasable Programmable Read Only Memory ESCON ..... Enterprise Systems Connection FICON .. . Fiber Connectivity FSC .. ........ Fault Symptom Code FTP . ...... File Transfer Protocol HTML ... . Hypertext Markup Language HTTP . ..... .. Hypertext Transfer Protocol HW .. . . Hardware I/O .. Input/Output I ² C Bus .. .. . Inter-Integrated Circuit Bus IC . . .... Integrated Circuit ICE . In-Circuit Emulation ICMP . . Internet Control Message Protocol

IEEE IIC IP .. . Internet Protocol

IV

IPCP .... .. Internet Protocol Control Protocol ISP .. . .. Internet Service Provider ISP .. ... In-System Programming IT .. .. Informationstechnologie JDK .. ..... JAVA Development Kit JTAG ........ Joint Test Action Group JVM .. . .. .. JAVA Virtual Machine LAN . . . Local Area Network LCP ....... Link Control Protocol LED .. ......... Light Emitting Diode LMU .... .. Library Management Unit LQFP .. . .. Low Profile Quad Flat Pack LSB . .. .... Least Significant Bit LTO . .. .. .. Linear Tape Open MHz . .. .... Megahertz MIB Management Information Base MIPS . .. .. Million Instructions Per Second MSB .... .. Most Significant Bit NACK .... Negative Acknowledge NAS .. . Network Attached Storage NMS .... .. Network Management Station Nut/OS .... .. Nut / Operating System Nut/Net .. Nut / Network Stack OEM ............. Original Equipment Manufacturer OID .... Object Identifier PC . .... Personal Computer PCI ........ Peripheral Component Interconnect PCM . .... . Plug Compatible Machine PDU .... .. Protocol Data Unit PPP .. .... . Point to Point Protocol PQFP . Plastic Quad Flat Pack RAM .... .. Random Access Memory RISC ... .. Reduced Instruction Set Computer ROM ... ... Read Only Memory RSC .. . Remote Systems Control RTS .... ... Request To Send

V

SAN .. .. .. Storage Area Network SCSI .. Small Computer System Interface SDLT .. .. . Super Digital Linear Tape SLA .................. Service Level Agreement SMS .... .. Short Message Service SMSC ... . Short Message Service Center SMTP .. . . Simple Mail Transfer Protocol SNMP .. .. Simple Network Management Protocol SPI .. ... Serial Peripheral Interface SRAM .. .. Static Random Access Memory SW .. .. . Software TCP/IP .. Transmission Control Protocol / Internet Protocol TFTP .. ... Trivial File Transfer Protocol TTL . .... .. Transistor Transistor Logik UART .. .. Universal Asynchronous Receiver Transmitter UDP ... User Datagram Protocol URL . ............ Uniform Resource Locator

VI

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  1 Remote Support Arbeitsplatz, ca. 1983.  

Abbildung  2 Heterogene RZ-Infrastruktur  

Abbildung  3 Fernwartung bei heterogener IT-Infrastruktur  

Abbildung  4 Architektur von Sun Net Connect  

Abbildung  5 SMC Gliederung.  

Abbildung  6 V20z System Board mit System Controller  

Abbildung  7 StorageTek L-Series Diagnosekommandos.  

Abbildung  8 StorageTek L-Series Library Fault Symptom Code Listing  

Abbildung  9 Fernwartung durch Service-Partner bei heterogener IT-Infrastruktur.  

Abbildung  10 Heterogene RZ-Infrastruktur mit Fernwartungseinheit  

Abbildung  11 Microcontroller Hersteller und Produkte  

Abbildung  12 TINI Board (beidseitig)  

Abbildung  13 TINI Prototyp Board.  

Abbildung  14 TINI Run-Time Softwareumgebung.  

Abbildung  15 RCM3200 Core Modul.  

Abbildung  16 RCM3200 Prototyp Board  

Abbildung  17 Ethernut System Board Blockschaltbild  

Abbildung  18 Ethernut System Board  

Abbildung  19 Blockschaltbild LAN91C111  

Abbildung  20 Hierarchischer Aufbau der Ausgabefunktionen.  

Abbildung  21 Hierarchischer Aufbau der Eingabefunktionen.  

Abbildung  22 Nut/Net Software Schichten  

Abbildung  23 Blockschaltbild Erweiterungsplatine  

Abbildung  24 Blockschaltbild MAX3110E  

Abbildung  25 MAX3110E Beschaltung  

Abbildung  26 Adressdecodierung und MISO Buffer.  

Abbildung  27 Prototyp der seriellen Erweiterungsplatine.  

Abbildung  28 SPI Datenübertragung.  

Abbildung  29 HW/SW-Struktur Fernwartungseinheit  

Abbildung  30 Programm- und Datenfluss  

Abbildung  31 Nut/OS Message Queue Funktionen  

Abbildung  32 Globale Einstellungen  

Abbildung  33 Übersicht Geräteeinstellungen  

VII

Abbildungsverzeichnis   

Abbildung  34 Detailinformation Geräteeinstellungen  

Abbildung  35 Zugriff auf den Konfigurationsfile.  

Abbildung  36 Übertragung der Konfiguration  

Abbildung  37 EEPROM Speicherzuordnung.  

Abbildung  38 Pseudocode zentrales Steuerprogramm  

Abbildung  39 Pseudocode ICMP Echo Sender.  

Abbildung  40 Nut/Net ICMP API  

Abbildung  41 Pseudocode Request/Response Sender  

Abbildung  42 Pseudocode SNMP Request Sender  

Abbildung  43 Kommunikation zw. NMS und Agent  

Abbildung  44 Pseudocode E-Mail Empfänger.  

Abbildung  45 Empfangen einer E-Mail.  

Abbildung  46 Pseudocode SNMP Trap Empfänger  

Abbildung  47 SNMP Trap Paket  

Abbildung  48 Pseudocode SMS Sender  

Abbildung  49 F-BUS Protokoll.  

Abbildung  50 F-BUS Nachrichtenaufbau  

Abbildung  51 Pseudocode E-Mail Sender.  

Abbildung  52 Nachrichtenfluss beim Senden einer E-Mail  

Abbildung  53 Pseudocode Benutzerschnittstelle  

Abbildung  54 Telnet Session zur Benutzerschnittstelle  

Abbildung  55 Threadinformationen  

Abbildung  56 Anzeige des device Kommandos.  

Abbildung  57 Anzeige des PHONE und STATUS Kommandos.  

Abbildung  58 Pseudocode TFTP Server  

Abbildung  59 TFTP Übertragung  

Abbildung  60 Geräteanordnung  

Abbildung  61 E-Mail-Nachrichtenübersicht  

Abbildung  62 SMS-Nachrichteneingang  

Abbildung  63 Prototyp der Fernwartungseinheit  

Abbildung  64 Layer 1 der Erweiterungsplatine.  

Abbildung  65 Layer 2 der Erweiterungsplatine.  

Abbildung  66 Bauteilanordnung der Erweiterungsplatine  

Abbildung  67 Schaltplan der Erweiterungsplatine.  

VIII

Tabellenverzeichnis   

Tabellenverzeichnis   

Tabelle 2-1  Verfügbarkeit und Down-Time.  7

Tabelle 3-1  Überwachungsmethoden  18

Tabelle 3-2  Anforderungen an die Fernwartungseinheit  19

Tabelle 3-3  Kommunikationsmethoden.  19

Tabelle 3-4  Servicevertragstypen.  20

Tabelle 4-1  DS80C390 Eigenschaften  26

Tabelle 4-2  TINI Board Komponenten.  26

Tabelle 4-3  R2000 / R3000 Gegenüberstellung.  29

Tabelle 4-4  HW und SW Auswahlkriterien  31

Tabelle 4-5  Software-Konzepte.  32

Tabelle 4-6  Komponenten der Fernwartungseinheit  34

Tabelle 5-1  Ethernut System Board Eigenschaften  35

Tabelle 5-2  Nut/OS Funktionen.  38

Tabelle 5-3  Device-Driver Funktionen.  43

Tabelle 5-4  Nut/Net Funktionen  44

Tabelle 6-1  Adressdecodierung der Erweiterungsplatine.  50

Tabelle 6-2  MAX3110E Register.  52

Tabelle 6-3  Bauteilliste Erweiterungsplatine  53

Tabelle 6-4  Signalrichtungen am SPI.  54

Tabelle 7-1  Globale Einstellung  60

Tabelle 7-2  Gerätespezifische Einstellungen  62

Tabelle 7-3  Anschlusstyp vs. Kommunikation.  63

Tabelle 7-4  Konfigurationsdatei.  65

Tabelle 7-5  Konfigurationsdaten - Zugriffsfunktionen.  68

Tabelle 7-6  Implementierte SMTP Kommandos  76

Tabelle 9-1  Komponenten der Fernwartungseinheit  100

IX

Kapitelübersicht

Kapitel 1 Einleitung

Die Einleitung beleuchtet in kurzer Form den Hintergrund des Themas und den Konnex zu meinem Arbeitgeber Bacher Systems.

Kapitel 2 Stand der Technik

Hier wird ein Abriss über die technologische Entwicklung der Fernwartung gegeben. Weiters wird gezeigt, welche Produkte und Dienstleistungen namhafte IT-Hersteller heute vermarkten.

Kapitel 3 Präzisierung der Aufgabenstellung

Dieses Kapitel beschreibt die Anforderungen an eine Fernwartungseinheit, sowohl technisch-funktionell, als auch wirtschaftlich.

Kapitel 4 Systemkonzept

In diesem Kapitel wird dargestellt, welche Konzepte zur Implementierung der Fernwartungseinheit umgesetzt werden können. Es werden verschiedene Konzepte und Gerätevarianten beschrieben.

Kapitel 5 Die Ethernut Hardware und Software Es werden die drei Komponenten gezeigt, welche die Basis für die Fernwartungseinheit bilden: Das System-Board, das Betriebssystem Nut/OS und der TCP/IP Stack Nut/Net.

Kapitel 6 Die Erweiterungsplatine für serielle Anschlüsse Diese Hardware und die dazu notwendige Software wurden für die Fernwartungseinheit entwickelt. Hier werden das Design und die Funktion beschrieben und die Einbettung der Software in Nut/OS erklärt.

Kapitel 7 Die Applikationssoftware der Fernwartungseinheit Aufsetzend auf die in den Kapiteln 5 und 6 beschriebene Hardware und Software wird die Implementierung der Funktionen der Fernwartungseinheit dargestellt. Dies umfasst auch das für PCs entwickelte Konfigurationsprogramm.

X

Kapitel 8 Systemintegration

Hier wird zusammengefasst, in welche Phasen sich die Entwicklungsarbeit der Fernwartungseinheit aufteilte. Ferner wird die Vorgangsweise während des Integrationstests beschrieben.

Kapitel 9 Test / Inbetriebnahme

Die Tests der Hardware und Software sowie der verwendeten Hilfsprogramme werden hier erläutert.

Kapitel 10 Einschätzung der Ergebnisse / Ausblick

Es werden die ersten Testergebnisse dargelegt und Überlegungen zu möglichen Weiterentwicklungen der Hardware und Software der Fernwartungseinheit aufgezeigt. Die Software bietet eine Menge an Möglichkeiten, Funktionalität und Handhabung der Fernwartungseinheit zu erweitern.

XI

Vorwort

Die hier vorliegende Diplomarbeit wurde in der Zeit von September 2004 bis Mai 2005 angefertigt.

Schon im Jahr 2002 fiel mir als Mitarbeiter von StorageTek Österreich die Diskrepanz zwischen dem technisch Möglichen und den vorhanden Funktionen von IT-Produkten bezüglich ihrer Ferndiagnose und Fernwartbarkeit auf. Dies wurde durch die Erfahrungen mit einer breiteren Produktpalette bei Bacher Systems noch untermauert: Möglichkeiten, Informationen über ihren Betriebszustand an die Außenwelt zu kommunizieren haben fast alle Server, Disk-Subsysteme, Bandroboter, Firewalls und andere Geräte, welche in einem modernen Rechenzentrum zu finden sind. In solchen heterogenen IT-Umgebungen muss aber oft auf große, komplexe, und mit beträchtlichen Investitionen verbundene Softwarelösungen zurückgegriffen werden, um alle diese Geräte, oder zumindest die meisten davon, zu überwachen.

Ein Konzept aufzuzeigen, wie diese Überwachung und die damit einhergehenden Kommunikationsnotwendigkeiten mit wenig Aufwand auf Basis von Embedded Systems implementiert werden können, wird mit dieser Arbeit dokumentiert. Ich möchte mich an dieser Stelle bei all jenen bedanken, die diese Arbeit möglich gemacht und sie unterstützt haben. Allen voran meine Gattin Christine, die durch ihr Verständnis mein Studium und diese Arbeit ermöglichte. Weiters meine Kollegen bei Bacher Systems, die mit ihrer praktischen technischen Erfahrung wertvolle Impulse lieferten und insbesondere bei Herrn Prof. Dr.-Ing. Olaf Hagenbruch und Hrn. Dipl. Ing. Martin Schneider für die Durchsicht des Manuskripts und die wertvollen Anregungen während dieser Arbeit.

XII

1 Einleitung

Die stetig anwachsende Abhängigkeit geschäftskritischer Prozesse von der Informationstechnologie bringt immer höher werdende Anforderungen an die Verfügbarkeit der Rechner, Applikationen und Netze mit sich. Diese Verfügbarkeit wird einerseits durch stabilere Hardware, andererseits durch den Einsatz von redundanten Komponenten wie Server-Cluster für hochkritische Anwendungen, erreicht. Somit kommt dem raschen Erkennen, Melden und Behandeln von Fehlersituation eine große Bedeutung zu, um Ausfallzeiten zu minimieren.

Viele Geräte, die in einem modernen Rechenzentrum betrieben werden, verfügen über Diagnosemöglichkeiten. Diese reichen von der Möglichkeit, einen Laptop direkt mit einem speziell dazu vorgesehenen Anschluss des Gerätes zu verbinden bis hin zur automatischen Übertragung von Fehlerinformationen an den Gerätehersteller über das Internet.

Diese Vielzahl birgt natürlich auch Unausgewogenheiten mit sich: Einerseits gibt es Geräte, die Fehlerinformationen intern aufzeichnen und auf Abfrage bereitstellen. In dieser Variante hängt es von den Kommunikationsfähigkeiten des Gerätes ab, ob diese Abfragen lokal oder remote durchgeführt werden können. Andere Geräte melden Betriebszustandsänderungen und Statusinformationen an Überwachungs-Zentren und erleichtern somit auch vorbeugende Servicemaßnahmen.

Bacher Systems EDV GmbH ist seit 1992 als System-Integrator am österreichischen Markt tätig und vertreibt, installiert, integriert und serviciert IT-Infrastrukturlösungen sowie eine breite Palette von Produkten und Dienstleistungen im Bereich der IT-Sicherheit. Die effiziente Erbringung von Serviceleistungen ist dabei ein wesentlicher wirtschaftlicher Faktor, welcher in seiner Kostenstruktur immer weiter zu optimieren ist.

Hier soll untersucht werden, wie eine Integration unterschiedlicher Fernwartungs- und Ferndiagnoselösungen verschiedener Hersteller vorgenommen werden kann, um dem steigenden Anspruch der Kunden nach wenigen, im Optimalfall einen, Servicepartner gerecht zu werden.

1

Gleichzeitig gilt es, die Arbeit der Servicetechniker zu unterstützen, indem Fehlersituationen einer umgehenden Bearbeitung zugeführt werden. Ja rascher ein eingetretener Fehler gemeldet wird, desto schneller kann mit der Behebung begonnen werden!

Und letztlich soll dem steigenden Kostendruck durch einen noch effizienteren Einsatz der Ressource Servicetechniker Rechnung getragen werden.

2

2 Stand der Technik

In diesem Kapitel wird ein kurzer Einblick in die Entwicklung der Ferndiagnose und Fernwartung und deren Verknüpfungen mit den technologischen Verbesserungen der letzten drei Jahrzehnte gegeben. Anhand zweier Beispiele, der Firma Sun Microsystems und der Firma StorageTek Corporation, werden die unterschiedlichen Ausprägungen der heutigen Implementierungen gezeigt

2.1 Entwicklung der Ferndiagnose und Fernwartung

Betrachtet man die Computersysteme der letzten 30 Jahre so wie die wesentlichen Veränderungen und Weiterentwicklungen der zugrunde liegenden Technologien, so kann folgendes leicht ersehen werden:

Starker Verfall der Hardwarepreise durch Massenfertigung Explosion der Komplexität der Hardware und Software Immer weitere Vergrößerung von IC - Packungsdichten Trend von der zentralen EDV zu vernetzten dezentralen Einheiten

Viele weitere Veränderungen sind damit verknüpft oder basieren auf diesen Entwicklungen.

Der Verfall der Hardwarepreise brachte mit sich, dass die grundlegende Preisstrategie der 60er Jahre überdacht werden musste. Hatte zuerst die Hardware einen Preis, der Software sowie notwendige Dienstleistungen inkludierte, so wurde in einem ersten Schritt die Software extra bepreist; natürlich auch um die Hardware billiger wirken zu lassen. Trotzdem war in den 70er Jahren des 20. Jahrhunderts nach wie vor die Hardware das Teuerste am gesamten Computersystem. Dementsprechend war auch die Hardwarewartung auf eine optimale Wiederverwendbarkeit von Austausch-Baugruppen ausgerichtet, deren Reparatur und Funktionstests in den Zentralen der Service-Organisationen von Computerherstellern stattfanden. Dabei war natürlich sicherzustellen, dass die richtige, also defekte, Baugruppe ausgetauscht wurde. Die Hardware-Techniker rückten Problemen mit Oszilloskop und Logikplänen zu Leibe, was einerseits einen oft nicht unbeträchtlichen Zeitaufwand bei der Fehlersuche zur

3

Folge hatte und andererseits natürlich nur am Aufstellungsort des Computers, also beim Kunden durchgeführt werden konnte.

Mit zunehmender Komplexität der Geräte erreichte diese Form der Fehlerdiagnose ihr Limit, und Oszilloskop/Logikdiagramm wurde durch Diagnosesoftware ergänzt, und später vollkommen ersetzt. Die Diagnosesoftware war zuerst eine für sich allein stehende Sammlung von Programmen, die einzelne Systemkomponenten (CPU, Memory, I/O Kanal, etc.) testete, ohne dabei unter der Steuerung eines Betriebssystems zu stehen. Daher wurden diese Tests auch standalone oder offline genannt, da der Systembetrieb gänzlich unterbrochen war.

Die 80er Jahre brachten eine Ausweitung der Datenkommunikation über Telefonleitungen durch Konstruktion und Vermarktung der ersten erschwinglichen 300/1200 bit/s Modems und Akustikkoppler.

Die Übertragungsgeschwindigkeit stieg dann unter Zuhilfenahme von Datenkompression und neuen Modulationstechniken rasant an und erreichte innerhalb kurzer Zeit 2400/9600/19200 und später 38400 und 56000 bit/s. Diesen Trend machten sich die Designer der Diagnosesoftware zu Nutze und ermöglichten den Technikern, diese Testprogramme über Modem-Telefonleitungen anzuwenden. Um nicht mehr das gesamte Computersystem dabei außer Betrieb nehmen zu müssen, wurden die Diagnoseprogramme so angepasst, dass sie zumindest teilweise während des

4

normalen, wenn auch etwas eingeschränkten Systembetriebs ablaufen konnten. Die Fernwartung war geboren.

Fernwartung

remote support maintenance

Technische Lösung, um die Wartung eines Computers aus räumlicher Entfernung (typischerweise für Kundendienst) durchzuführen. Die Verbindung erfolgt durch Datenübertragung, die unter besonderer Berücksichtigung des Datenschutzes vom Anwender vorübergehend für bestimmte Wartungsebenen (Hardware, Software, Datenbestände) freigegeben wird. Moderne Computer haben die Möglichkeit, auftretende Störungen intern aufzuzeichnen und bei Fernwartung einem zentral verfügbaren Diagnoseprogramm mitzuteilen und die Störungen analysieren zu lassen. (vgl. [23])

Aus dem vorstehenden Zitat lässt sich eine wesentliche Randbedingung dieser Entwicklung erkennen: Die Fehlerdiagnose und die sich daraus ergebende weitere Vorgangsweise war auf die Produkte des jeweiligen Hardwareherstellers bezogen. Die einzigen Ausnahmen davon waren die so genannten PCMs ( Plug-Compatible Machines ), also ganze Systeme oder Teile wie Disksubsysteme, die jedoch funktionell bis hin zum Anschlussstecker identisch zu ihrem Original waren.

Die späten 80er und beginnenden 90er Jahre brachten mit dem Schlagwort open einen zusätzlichen Trend. Die kommerzielle Ausbreitung des Betriebssystems UNIX, die Entkopplung der Hardware und Betriebssystem-Software, die früher immer vom gleichen Hersteller geliefert wurde, und die intensiver werdende Implementierung und Verwendung von standardisierten Schnittstellen wie SCSI, X.25, etc. ermöglichte das Zusammenwirken von Hardware unterschiedlicher Hersteller. Weiters hatten sich durch die hohen Stückzahlen der hergestellten Hardware die Kostenfaktoren gänzlich verschoben: Hardware war für den Kunden billig geworden, Software teuer und die Mitarbeiterkosten stiegen bei den IT-Lieferanten extrem an. Das Hardwareservice war zu einem signifikanten Kostenfaktor geworden: sowohl kunden- als auch herstellerseitig galt es, Kosten einzusparen.

Einer dieser Wege ist seither, auf Basis offener Standards Systeme oder Systemkomponenten verschiedener Hersteller zum Einsatz zu bringen. Offene Standards wie TCP/IP LANs, Fibre Channel SANs oder SCSI Schnittstellen erlauben

5

es, Server, Disk-Subsysteme oder Bandroboter von denjenigen Lieferanten zu beziehen, welche eine Markt führende Position in technischer Funktionalität oder Preis bieten. Voraussetzung dafür ist jedoch, dass alle Geräte diese Standards umfassend und genau implementieren, sodass die Heterogenität in der Systemlandschaft keine funktionellen Nachteile mit sich bringt.

Parallel dazu setzte die kommerzielle Nutzung des Internets ein und brachte eine Explosion an komplexen Applikationen mit sich, die das neue Medium nutzten. Die durch das Internet ermöglichte Globalisierung einer IT-basierenden Geschäftsidee (Software-Download, Bücherverkauf, etc.) brachte steigende Anforderungen an die Verfügbarkeit der IT-Infrastruktur mit sich.

6

Folgende Stillstandszeiten ergeben sich jährlich bei einem 24 Stunden / 7 Tage pro Woche Betrieb in Abhängigkeit von gewünschten Verfügbarkeitswerten:

Es lässt sich leicht erkennen, dass Verfügbarkeitswerte kleiner als 99,9% für ein global über das Internet zur Verfügung gestelltes Geschäftsmodell nicht akzeptierbar sind. Allerdings muss hier noch angemerkt werden, dass neben der Verfügbarkeit der IT-Infrastruktur auch die Verfügbarkeit der Applikationsprogramme, Datenbanken, etc. betrachtet werden muss. Regelmäßig durchgeführte Studien erheben die Umsatzeinbußen durch Down-Time , welche je nach Geschäftszweig in den USA

zwischen Tausenden und Hunderttausenden Dollar liegen (vgl. [17] und [21]).

Für das Service von IT-Infrastrukturen bedeutet dies, dass Fehler, Defekte oder sonstige Problemsituationen möglichst schnell ihrer weiteren Behandlung zugeführt werden müssen. In heute üblichen heterogenen IT-Infrastrukturen, in denen Geräte unterschiedlicher Hersteller zusammenwirken, müssen die Störungsinformationen derjenigen Firma oder Organisation zur Verfügung gestellt werden, die das Service für das jeweilige Gerät erbringt.

Damit wird sichtbar, dass in diesem Fall nur der Kunde als einziger über die Gesamtinformation aller Gerätezustände verfügt. Es obliegt somit auch ihm, die Auswirkungen eines Fehlers auf den Gesamtbetrieb richtig zu analysieren und daraus die notwendigen Maßnahmen abzuleiten.

Im Folgenden werden stellvertretend die Service-Angebote von zwei wesentlichen IT-Lieferanten betrachtet: Sun Microsystems als Beispiel eines Systemlieferanten und StorageTek Corporation als Beispiel eines spezialisierten Speicherlieferanten (vgl. [4], Seite 5ff.).

2.2 Remote-Service Angebot von Sun Microsystems

In den mehr als 20 Jahren seit der Gründung ¹ hat sich Sun Microsystems vom Nischenanbieter einfach vernetzbarer UNIX Workstations zu einem umfassenden Systemlieferanten entwickelt.

Fast alle Produkte bieten dabei eine Möglichkeit der Fehlerdiagnose und unterstützen Ferndiagnose und Fernwartung. Die selbst produzierten Serverprodukte unterscheiden sich hier jedoch von den zugekauften Platten- und Bandspeicher-Subsystemen.

Als Lieferant einer so breiten Palette von Hardware, Software und Dienstleistungen bietet Sun eine Vielzahl von Fehlerdiagnose- und Service-unterstützenden Produkten. Da als zentrale Komponente einer Sun-basierenden IT-Infrastruktur immer einer oder mehrere Server gesehen werden, zentrieren sich Fernwartungssoftware und Monitoring-Hilfsmittel um diese Serverprodukte. Das Betriebssystem Solaris hat mit seinen Administrations-Tools auch die Aufgabe, den Status der Peripheriegeräte zu überwachen und gegebenenfalls Fehlerinformationen auf der Systemkonsole anzuzeigen oder über geeignete APIs den System-Management Applikationen von Drittanbietern (CA-Unicenter, HP Openview, Tivoli, BMC Patrol u.s.w.) zur Verfügung zu stellen. In dem breiten Spektrum von externen Plattenspeichern, Bandstationen und unterschiedlichen Netzwerkkomponenten werden von Sun selbst produzierte Produkte und solche, welche von OEMs (Original Equipment Manufacturer = Originalhersteller) für Sun produziert werden, angeboten. Aber auch der Anschluss von Fremdgeräten

¹ Sun steht für Stanford University Network und benennt das Projekt, welches die Firmengründer Andreas v. Bechtolsheim, Bill Joy, Vinod Koshla und Scott McNealy gemeinsam bearbeiteten.

8

anderer Lieferanten ist üblich. All dies bringt Unterschiede in der Art und Tiefe der Integration der Geräte in die Überwachungsfunktionen des Betriebssystems mit sich.

Die beiden wesentlichen Softwareprodukte, welche heute im Einsatz stehen, sind Sun Net Connect (vgl. [26 a]) und Sun Management Center (vgl. [26 b]). Während Sun

Net Connect mit jeder Kopie des Betriebssystems Solaris kostenfrei ausgeliefert wird

und eine Basisfunktionalität zur Steuerung und Überwachung des Betriebs enthält, ist Sun Management Center ein weit umfassenderes Produkt, welches jedoch seine

vollen Fähigkeiten erst bei der Kombination mit kostenpflichtigen Zusatzmodulen entfaltet. Doch nicht nur Funktionsumfang und Preisgestaltung unterscheiden diese beiden Produkte.

Sun Net Connect Services ermöglichen die Kommunikation von Kundenservern mit einem Sun Service Center. Dabei werden Informationen über unterschiedlichste Ereignisse und Zustände der Systeme erfasst, ausgewertet, weitergeleitet und angezeigt.

Voraussetzung dafür ist die Verbindung der überwachten Systeme mit dem Internet, über welches die gesammelten Informationen zum Sun Support Center übertragen werden. Daraufhin stehen die ausgewerteten Informationen über ein Internet-Portal abrufbar bereit. Hier zeigt sich auch eine wesentliche Stärke von Sun Net Connect : Durch die Zuordnung von Rollen und Zugriffsberechtigungen zu den Benutzer-Identifikationen werden Views (Ansichten) erzeugt, die es erlauben, verschiedenen

Personenkreisen Zugriff zu diesen Daten zu geben. Hervorzuheben ist dabei, dass zusätzlich zu den Views des Sun Support Center und des Endkunden es auch

möglich ist, Dritte wie z.B. einen Servicepartner teilweise in dieses Konzept mit einzubeziehen.

Sun Net Connect bietet folgende Funktionen:

Systemüberwachung Resourcenauslastung: Nachverfolgung von Betriebssystem-Ereignissen durch ein Set von Performancemessgrößen. Auslösen von Alarmen bei Überschreitung von Systemparametern oder Schwellenwerte.

Ferndiagnose Mitarbeiter des Support Centers können Diagnoseprogramme in den Servern via Internet ablaufen lassen und die Ergebnisse auswerten.

Benachrichtigung bei Hardwarefehlern Mittels der System Controller (siehe Abbildung 6) werden wichtige Hardwarekomponenten der Server überwacht. Informationen über Anzeichen eines drohenden Defektes.

Trendberichte Treten gleiche oder ähnliche Situationen wie z.B. Lastspitzen gehäuft auf, so wird dies in Trendberichten dargestellt und damit vor Überlastungen gewarnt, bzw. Hinweise auf sinnvolle Systemerweiterungen gegeben.

Verfügbarkeitsberichte Es werden die Zeiten, in denen das Betriebssystem läuft, und solche, in denen ein Server gestoppt ist, in Relation gesetzt und daraus Verfügbarkeitsdaten errechnet.

Konfigurations- und Patch-Berichte Es wird die Systemkonfiguration mit den Auslastungsdaten verglichen um Veränderungen im Auslastungsprofil mit der aktuellen Betriebssystemkonfiguration zu vergleichen. Außerdem werden die am System installierten Softwareversionen auf Aktualität analysiert.

Während Sun Net Connect Systeme überwacht, indem in regelmäßigen Intervallen Informationen an ein Sun Remote Support Center gesendet und dort aufbereitet bzw.

10

von dort über das Internet abgerufen werden können, geht das Produkt Sun Management Center einen anderen Weg. Hier werden die Informationen auf dem

System selbst, oder bei einem Netzwerk auf einem Management Server gesammelt,

konsolidiert und ausgewertet.

Die Sun Management Center Software vereint viele verschiedene Komponenten,

welche einerseits Informationen über den Zustand ganzer Netzwerke von Sun-Servern charakterisieren, und andererseits diese Informationen auswerten bzw. über APIs anderen Softwareprodukten zur Verfügung stellen. Damit ist die Einbettung solcher Netzwerke in rechnerübergreifende Management-Systeme möglich.

Sun Management Center bietet folgende Funktionen:

Service Availability Manager steigert die Verfügbarkeit der Dienste (FTP, Webserver, Mail, etc.) auf den Systemen durch Konfigurationsvorschläge und Überprüfungen.

11

System Reliability Manager hilft, die Zuverlässigkeit des Systems weiter zu steigern, indem z.B. Crash-Dump Analysen nach einem Betriebsystemfehler durchgeführt werden.

Performance Reporting Manager analysiert Informationen über die Auslastung von Systemkomponenten und Peripheriegeräten und erstellt Diagramme, die potentielle Engpässe und Trends zeigen.

Change Manager unterstützt System-Administratoren beim Aktivieren neuer Versionen von Softwarekomponenten durch Analyse von Abhängigkeiten.

Advanced System Monitoring überwacht die Hardware des Gesamtsystems und das Verhalten des Betriebssystems Solaris und unterstützt Diagnoseprogramme beim Auffinden von möglichen Defekten.

Container Manager ermöglicht es dem Systemverwalter, Solaris Container ² einfach zu erstellen und zu verwalten.

Um die weiter oben beschriebenen Softwaretools mit möglichst detaillierten Informationen über den Betriebszustand von Hardwarekomponenten versorgen zu können, entwickelte Sun schon vor einigen Jahren Sun Remote System Control (RSC), eine Erweiterungskarte für die Sun Fire Produktlinie der Mittelklasse-Server. Sie besitzt einen seriellen RS232 und einen RJ45-LAN Anschluss sowie ein on-Board Modem und ist in der Lage, Temperatur und Einzelkomponentenfunktionen des Servers zu messen und zu reporten. Weiters können die Funktionen der Systemkonsole und des Open Boot PROM mit seinen verschiedenen

Diagnosemöglichkeiten via RSC über Modemleitungen oder LANs zum Einsatz kommen.

² Ein Solaris Container ist eine gekapselte Instanz des Betriebssystems Solaris, wovon tausende auf einem Server gleichzeitig aktiv sein können.

12