Konzeption, Einführung und Integration eines Monitoringsystems in bestehende Netzwerkdienste in einer Krankenhausumgebung

Transkript

1 Aus dem Institut für Medizininformatik, Biometrie und Epidemiologie Lehrstuhl für Medizinische Informatik der Friedrich-Alexander-Universität Erlangen-Nürnberg Direktor: Prof. Dr. H.-U. Prokosch Konzeption, Einführung und Integration eines Monitoringsystems in bestehende Netzwerkdienste in einer Krankenhausumgebung Inaugural-Dissertation zur Erlangung des akademischen Grades Doctor rerum biologicarum humanarum (Dr. rer. biol. hum.) der Medizinischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg vorgelegt von Dipl.-Inf. (Univ.) Serkan Beyaz geb. am in Salzgitter Erlangen, den

2 Gedruckt mit Erlaubnis der Medizinischen Fakultät der Friedrich-Alexander-Universität Erlangen-Nürnberg Dekan: Prof. Dr. Jürgen Schüttler Referent: Prof. Dr. Hans-Ulrich Prokosch Korreferent: Prof. em. Dr. Fridolin Hofmann Tag der mündlichen Prüfung:

3 Inhaltsverzeichnis 1 Zusammenfassung Einleitung Motivation Problemstellung Zielsetzung Fragestellung Grundlagen Verfügbarkeit Netzwerkmanagement Netzwerkmonitoring Dynamic Host Configuration Protocol Domain Name System Monitoringsystem Nagios Grundlagen Prüfmechanismen Eskalation im Fehlerfall Webinterface IT Struktur des Universitätsklinikums Erlangen Netzwerkstruktur EDV Systeme Methodik Wahl der Überwachungssoftware Ermittlung der Überwachungskriterien Redundante Überwachung Autokorrektur von Fehlern Systemdokumentation Integration DHCP, DNS und Nagios Verbesserung der Administrationstätigkeit Messen der Nutzung des Gesamtsystems Ergebnisse Einführung des Monitoringsystems Nagios Technischer Aufbau Grundkonfiguration Analyse der Prozesse... 33

4 5.2.1 DHCP Konfigurationsprozess DNS Konfigurationsprozess Nagios Konfigurationsprozess Managementsystem HANAS Konzept und technischer Aufbau Verwaltete Datenfelder Rollenbasiertes Rechtekonzept Implementierte Funktionen Veränderung der Arbeitsabläufe Überwachung von Soarian Integrated Care Ermitteln der Server Ermitteln der Dienste, die für den Betrieb der Applikation notwendig sind Ermitteln weiterer notwendiger Kriterien für die Funktion des Systems Herausarbeiten automatisierbarer Instandsetzungmaßnahmen Abonnieren der Fehlermeldungen Auswertung der HANAS Logdateien DHCP Nutzung DNS Nutzung Nagios Nutzung Management Nutzung Auswertung der Nagios Logdateien Messung der Verfügbarkeit Diskussion Einführung von Nagios Entwicklung von HANAS Analyse der Nutzung Abbildungsverzeichnis Literaturverzeichnis Abkürzungsverzeichnis Danksagung Tabellarischer Lebenslauf...69

5 5 1 Zusammenfassung Durch die Einführung und den stetigen Ausbau von EDV Anlagen im medizinischen Umfeld wird es immer wichtiger, die fehlerfreie Funktion dieser Anlagen ununterbrochen zu gewährleisten. Hierfür muss die vorhandene Verfügbarkeit ermittelt und mit technischen Mitteln verbessert werden. Ziel dieser Arbeit ist es, am Universitätsklinikum Erlangen technische Vorrausetzungen zu schaffen, um die Ausfallzeiten zu minimieren und die Verfügbarkeit zu erhöhen. Dieses Ziel soll erreicht werden durch die Konzeption und die Einführung eines Monitoringsystems und durch die Entwicklung eines Managementsystems, welches das Monitoringsystem, sowie die Dienste DHCP und DNS integriert und dadurch den Administratoren am Universitätsklinikum Erlangen eine einfache Möglichkeit bietet, Prüfmechanismen für EDV Systeme einzurichten und sich im Fehlerfall automatisiert benachrichtigen zu lassen. Im Ergebnisteil dieser Arbeit wird gezeigt, wie das Monitoringsystem Nagios eingeführt und parametriert wurde, um den Anforderungen des Universitätsklinikums zu genügen. Es werden bestehende Prozesse bei der Konfiguration der Netzwerkdienste DHCP und DNS analysiert. Es wird beschrieben wie das Managementsystem HANAS entwickelt wurde, um die Dienste Nagios, DHCP und DNS zu integrieren und die Prozesse zur Konfiguration der Dienste zu optimieren. Anhand eines Beispiels wird der systematische Aufbau einer Applikationsüberwachung dargestellt. Es wird geprüft ob die eingeführten Systeme von den Administratoren am Universitätsklinikum Erlangen gut akzeptiert und genutzt werden. Zu diesem Zweck werden Logdateien ausgewertet, die eine Nutzung belegen. Abschließend wird ermittelt, inwieweit die Einführung eines Monitoringsystem die Verfügbarkeit der EDV steigern konnte. In der Diskussion wird festgestellt dass die Einführung des Monitoringsystem Nagios erfolgreich war. Das System konnte gut mit den bestehenden Netzwerkdiensten DHCP und DNS durch das Managementsystem HANAS integriert werden. Die Nutzung durch die Administratoren am Universitätsklinikum Erlangen konnte belegt werden. Die Verbesserung der Verfügbarkeit konnte systembezogen gezeigt werden, jedoch kann dies nicht zweifelsfrei auf die Einführung des Monitoringsystem Nagios zurückgeführt werden. Der Vergleich der Verfügbarkeit mit dem Zeitraum vor Einführung von Nagios war nicht möglich, da vorher keine Erfassung von Ausfällen in der EDV stattfand.

6 6 Abstract Due to the introduction and the continuous further development of computer systems in the medical field the proper and uninterrupted functionality of these systems is becoming increasingly important. For this purpose it is necessary to capture the availability's current state and improve it by technical means. This work aims at establishing the technical prerequisites at the University Hospital Erlangen in order to minimize down times and increase the system's availability. This will be achieved by implementing a monitoring system and by developing a management system which integrates the monitoring system with the services DHCP and DNS. This solution offers the administrators at the University Hospital Erlangen a simple way for establishing verification mechanisms that can notify them in case of any errors. In the result section of this work, the installation process of the monitoring system Nagios will be described in detail. It will also be discussed how a suitable set of parameters has been chosen to meet the requirements by the University Hospital. Furthermore, existing processes for configuring the network services DHCP and DNS will be analyzed. Based on that analysis, the development of the management system HANAS will be displayed. Forming an integration of the services Nagios, DHCP and DNS, this system allows an optimized configuration process. The methodic setup of an application monitoring system will be displayed based on a practical example. It will also be examined how the administrators of the University Hospital Erlangen respond to the newly implemented system and integrate it into their daily work routine. This analysis bases on the evaluation of log files that clearly demonstrate the system's usage. Finally, it will be determined to what extent the roll out of a monitoring system can help to increase the computer systems' availability. The discussion section will show that the introduction of the monitoring system Nagios has been a success. The management system HANAS allowed a smooth integration of the system with the existing network services DHCP and DNS. It has furthermore been proved that the administrators at the University Hospital Erlangen actually use the system as a part of their routine. Although the increased availability of a sample system could be clearly demonstrated, it was not possible to attribute this in a scientific way to the introduction of the monitoring system Nagios as no failure records have ever been kept before its introduction.

7 7 2 Einleitung Das Gesundheitswesen in Deutschland befindet sich wie viele andere Branchen im Umbruch. Gesetzliche Neuerungen wie Fallpauschalen, Einführung der elektronischen Gesundheitskarte, neue Telematikstrukturen sowie der stetig steigende Kostendruck zwingen Institutionen zum Einsatz von immer größeren EDV Anlagen. Dabei steigt nicht nur die Anzahl der eingesetzten Systeme, sondern auch deren Komplexität. Wann immer ein System in Betrieb genommen wird, beeinflusst es die Arbeitsweise in seinem medizinischen Umfeld. Bestehende Prozesse werden mit Hilfe der EDV verändert, im besten Falle optimiert. Das hat zur Folge, dass die klinische Versorgung nach und nach durch die Computerisierung bestimmt wird, wodurch ein Abhängigkeitsverhältnis gegenüber der EDV entsteht und eine hohe Verfügbarkeit immer wichtiger wird. Die Verfügbarkeit von EDV Systemen hängt von drei Faktoren ab. Erstens von der Zeit, in der ein System fehlerfrei und ohne Unterbrechung in Betrieb ist, zweitens von der Reaktionszeit bis ein Fehler festgestellt wurde, und drittens von der Instandsetzungszeit, die nötig ist, um den Fehler zu lokalisieren und zu beheben. Die Zeit, in der ein System fehlerfrei arbeitet, ist gebunden an die eingesetzte Hard- und Software. Sie kann vom Betreiber der EDV Systeme optimiert werden, indem er möglichst ideale Umgebungsverhältnisse bereitstellt. Weiterhin kann die Laufzeit durch Fehlermaskierung mit redundanter Hardware oder durch Clusterlösungen verbessert werden. Diese Lösungen sind jedoch mit hohen Kosten verbunden, erweitern das Gesamtsystem durch zusätzliche Komponenten, die ausfallen können, und haben letztendlich keinen Einfluss auf die Ausfalldauer. Da ein Ausfall von EDV Systemen nicht zu 100 Prozent vermieden werden kann, spielt die Reaktions- und Instandsetzungszeit eine wichtige Rolle. Ein System, das mehrmals im Jahr ausfällt aber sofort wieder instand gesetzt werden kann, ist verfügbarer als ein System das einmal ausfällt und tagelang nicht reparabel ist. 2.1 Motivation Zu Beginn dieser Arbeit existiert am Universitätsklinikum Erlangen weder die Möglichkeit, die Verfügbarkeit der EDV Systeme zu messen, noch sie zu verbessern. Darüber hinaus fehlt eine zentrale Übersicht, in der die eingesetzten Netzwerke und Server dokumentiert werden, sodass es sehr schwer ist, eine konsistente und möglichst

8 8 umfassende Überwachung aufzubauen, mit der die Verfügbarkeit gemessen werden kann. Diese gravierenden Mängel sollen beseitigt werden, um am Klinikum mittelfristig Service Level Agreements (SLA) einführen zu können. SLAs sind Dienstgütevereinbarungen, die zwischen einem Dienstanbieter und seinen Kunden abgeschlossen werden. Sie beinhalten unter anderem Leistungsumfang, Verfügbarkeiten, Reaktionszeiten, Eskalationsmechanismen und Preise für die zu erbringenden Dienste (vgl. [33][45]). 2.2 Problemstellung Die Reaktionszeit wird im Betrieb von EDV Anlagen oft vernachlässigt. Ausfälle werden erst durch die Anwender entdeckt und mündlich an den Betreiber mitgeteilt. Zum einen geht dies auf Kosten der Kundenzufriedenheit, zum anderen wird kostbare Zeit vergeudet, da der Anwender bei nicht regelmäßiger Nutzung des Systems den Fehler erst sehr spät bemerkt. Es entsteht eine unnötige Verzögerung in der Fehlerbehandlung. Folglich sollten EDV Systeme ununterbrochen überwacht werden, um einen Ausfall vor dem Kunden registrieren zu können. Eine Verkürzung der Instandsetzungszeit ist für die Verbesserung der Verfügbarkeit ebenso wichtig. Zu diesem Zweck ist eine eindeutige Fehlerdiagnose entscheidend. Die Ursache des Fehlers muss dabei durch die Kombination aussagekräftiger Tests ermittelt werden. Unabhängig davon, ob die Tests manuell oder durch ein Monitoringsystem automatisiert durchgeführt werden, spielt dabei die Art und Weise der Überwachung eine große Rolle. Die meisten Tests die verwendet werden sind semientscheidbar, d.h. es werden Kriterien geprüft, die für die Funktion eines Systems notwendig aber nicht hinreichend sind. Das bekannteste Beispiel hierfür ist ein Pingtest. Mit einem Pintest wird überprüft, ob ein bestimmter Rechner im Netzwerk erreichbar ist [26]. Reagiert ein Rechner nicht mehr auf diesen Test, kann in der Regel davon ausgegangen werden, dass der Rechner und die darauf laufenden Dienste nicht mehr verfügbar sind. Ist die Antwort jedoch positiv, liefert das Ergebnis keine hinreichende Bestätigung dafür, dass das System korrekt arbeitet. In großen Netzwerken wie beispielsweise am Universitätsklinikum Erlangen werden manchmal Netzwerkadressen von Servern in Folge von Migrationen und Updates umkonfiguriert. Dabei kann es passieren, dass die Überwachung aufgrund veralteter Informationen auf einer nicht mehr existierenden Netzwerkadresse erfolgt, und die

9 9 Tests somit einen Fehler liefern. Es kommt zu einem Fehlalarm. Ein sinnvolles Monitoring ist daher nur möglich, wenn die Daten für die Überwachung aktuell sind, da sonst anhand der Prüfergebnisse keine zuverlässige Aussage getroffen werden kann. Um ein Monitoringsystem aktuell zu halten, gibt es zwei Möglichkeiten. Entweder werden alle Adressänderungen der überwachten Systeme dem Monitoringsystem manuell mitgeteilt, was jedoch einen sehr hohen Grad an Disziplin erfordert, oder das Monitoringsystem wird per Automatismus an ein System angebunden, in dem Adressänderungen bereits gepflegt werden. In beiden Fällen bedarf es einer Kooperation der Administratoren, die für die beteiligten EDV Systeme verantwortlich sind. Da eine Verbesserung der Verfügbarkeit ohne die Zusammenarbeit der Systembetreuer nicht realisiert werden kann, ist es erforderlich, diese Personengruppen vom Nutzen einer Überwachung zu überzeugen, indem zum einen der Aufwand gering gehalten wird, und zum anderen ein gewisser Mehrwert in der Administrationstätigkeit entsteht. Zusammenfassend lassen sich folgende Problempunkte erkennen: P1. Ausfälle werden erst durch die Anwender erkannt, was zu Kundenunzufriedenheit und Imageverlust führt. Fehler werden verzögert bemerkt, so dass Reaktionszeiten unnötig verlängert werden. P2. Bei einer Überwachung können aufgrund veralteter Information Fehlalarme ausgelöst werden. P3. Eine fehlende Kooperation der Systembetreuer in der Datenpflege sowie eine Nichtnutzung des Monitoringsystems macht die Einführung des Systems obsolet. 2.3 Zielsetzung Um eine Verbesserung der Verfügbarkeit von EDV Systemen zu erreichen, muss neben dem Einsatz hochwertiger Hard- und Software vor allem die Reaktions- und Instandsetzungszeit optimiert werden. Hierfür ist ein Monitoringsystem einzuführen, das durch kontinuierliche Prüfung von Diensten Fehler erkennt, und per oder SMS eine Mitteilung an die jeweiligen Administratoren verschickt. Dabei ist es erstrebenswert, nicht nur fehlerhaft arbeitende, sondern auch fehlerfreie Komponenten zu erfassen, um sie bei der Fehlersuche als Ursache ausschließen zu können. Durch

10 10 diese Vorgehensweise können die Administratoren bei der Fehlerdiagnose unterstützt und die Instandsetzungszeit verkürzt werden. Im Idealfall sind die Prüfmechanismen so aufzubauen, dass Fehler eindeutig lokalisiert werden können. Dafür sind Tests notwendig, die hinreichende Aussagen liefern. Als hinreichend können alle Tests bezeichnet werden, welche die Nutzung des Systems durch einen menschlichen Benutzer nachbilden. Beispielsweise kann bei der Prüfung eines Webservers eine Seite aufgerufen und ausgewertet werden, um die Funktionsfähigkeit des Webservers zu verifizieren. Ist ein Fehler eindeutig ermittelbar, und die Art und Weise der Instandsetzung jedes Mal identisch, kann sie unter Umständen automatisiert werden. Das bedeutet, das Monitoringsystem würde einen Ausfall bemerken, die Administratoren benachrichtigen und eigenständig die Fehlerbehebung einleiten, z.b. durch den Neustart einer Applikation. Ein weiteres Ziel ist der Betrieb eines Monitoringsystems mit möglichst geringem Arbeitsaufwand. Dabei darf die Aktualität der Überwachungsdaten nicht vernachlässigt werden, da es sonst zu Fehlalarmen kommen kann. Um den Aufwand in Grenzen zu halten, ist die Verbindung zu Systemen mit ähnlichen Datenbeständen unumgänglich. Da jedoch Dienste wie beispielsweise der Domain Name Service (DNS) [29][30] nur sehr wenige Informationen bereitstellen und daraus nicht alle Parameter der Überwachung generiert werden können, ist es notwendig, die Integration der Netzwerkdienste durch ein Managementsystem zu realisieren, welches die Informationen rollenbasiert in einer Graphical User Interface (GUI) zur Verfügung stellt. Bevor ein Monitoringsystem betrieben werden kann, ist daher eine rudimentäre Dokumentation über die zu überwachenden Systeme aufzubauen, in der zentral durch alle beteiligten Administratorengruppen Änderungen eingepflegt werden. Diese Dokumentation dient als Informationsquelle für einen automatisierten Betrieb des Monitoringsystems. Dabei werden die Anwender durch Softwareagenten unterstützt, die den Datenbestand auf seine Aktualität und Konsistenz prüfen, und die Daten gegebenenfalls berichtigen.

11 11 Die Ziele dieser Arbeit sind wie folgt zu formulieren: Z1. Konzeption und Einführung eines Monitoringsystems, welches Ausfälle vor dem Anwender eigenständig erkennen kann. Z2. Entwicklung und Aufbau eines Managementsystems mit dem Ziel, das Monitoringsystem und die Dienste DHCP und DNS zu integrieren, sowie eine Systemdokumentation aufzubauen. Z3. Überprüfen der Akzeptanz beider Systeme. 2.4 Fragestellung Im Rahmen der Zielsetzung ergeben sich folgende Fragen, die zu beantworten sind: Frage 1: Frage 2: Frage 3: Können durch die Einführung eines Monitoringsystems Ausfälle zeitnah und eigenständig erkannt werden? Lässt sich durch die Entwicklung eines Managementsystems zur Integration des Monitoringsystems mit DHCP und DNS ein automatisierter Betrieb des Monitoringsystems erreichen? Werden die eingeführten Systeme von den Systembetreuern angenommen?

12 12 3 Grundlagen Im folgenden Kapitel werden technische Grundlagen erklärt, die für das Verständnis eines Monitoringsystems und dessen Integration in die bestehende Netzwerkumgebung entscheidend sind. Zunächst wird der Begriff der Verfügbarkeit definiert. Anschließend wird ein Überblick darüber gegeben, in welchem Bereich des Netzwerkmanagements sich das Monitoring befindet. Danach werden die Dienste DHCP, DNS und Nagios beschrieben, es wird auf die Netzwerkstruktur des Universitätsklinikums Erlangen eingegangen und das Telemedizinportal Soarian Integrated Care (SIC) vorgestellt, für das in dieser Arbeit beispielhaft eine Überwachung aufgebaut wird. 3.1 Verfügbarkeit Die Verfügbarkeit wird im Allgemeinen definiert durch den Quotienten aus der Differenz der Gesamtzeit und der Ausfallzeit dividiert durch die Gesamtzeit. Sie spiegelt die Zeit wider, in der ein System innerhalb definierter Parameter gemäß seiner Spezifikation korrekt arbeitet. Abgeleitet nach Information Technology Infrastructure Library (ITIL) wird definiert: Gesamtzeit Ausfallzeit Verfügbarkeit = Gesamtzeit Die Formel verdeutlicht, dass in der Praxis nur durch Minimierung der Ausfallzeit ein höherer Verfügbarkeitsquotient erreicht werden kann. Die Ausfallzeit wiederum setzt sich zusammen aus der Summe der Reaktionszeit und der Instandsetzungszeit. Ausfallzei t = Reaktionszeit + Instandsetzungszeit Substituiert ergibt sich somit: Gesamtzeit (Reaktionszeit + Instandsetzungszeit) Verfügbarkeit = Gesamtzeit

13 13 Die Verfügbarkeit wurde von der Harvard Research Group (HRG) durch die Availability Environment Classification (AEC) in sechs Klassen unterteilt [18]. Klasse Bezeichnung Bedeutung Verfügbarkeit in % 0 Conventional Funktion kann unterbrochen werden, Datenintegrität ist nicht essenziell 1 High Reliable Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein 2 High Availability Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit minimal unterbrochen werden 3 Fault Resilient Funktion muss innerhalb festgelegter Zeiten oder während der Hauptbetriebszeit ununterbrochen aufrechterhalten werden 4 Fault Tolerant Funktion muss ununterbrochen aufrechterhalten werden, 24x7-Betrieb (24 Stunden, 7 Tage die Woche) muss gewährleistet sein 99 99,9 99,99 99,999 99, Disaster Tolerant Funktion muss unter allen Umständen verfügbar sein 99,99999 Abb. 1: AEC Klassen nach der HRG Werden die Verfügbarkeitsquotienten angewendet auf eine Gesamtzeit von einem Jahr, wird deutlich wie lange die Ausfallzeiten sein können, insbesondere wenn diese bei einem einzigen Ausfall zustande kommen. Verfügbarkeit in % Ausfallzeit pro Jahr 99 3 d 15 h 36 m 99,9 8 h 45 m 36 s 99,99 52 m 34 s 99,999 5 m 15 s 99, s 99, s Abb. 2: Ausfallzeiten nach AEC Klassen Ausfälle die mehrere Tage dauern können sind in einer Krankenhausumgebung nicht akzeptabel, daher muss die Ausfallzeit verkürzt werden, indem die Reaktions- und Instandsetzungszeit verkürzt wird. Da die Instandsetzungszeit aber stark abhängig ist

14 14 von den ausgefallenen Hard- und Softwarekomponenten, ist sie in ihrer Dauer sehr variabel. Sie kann von der Zeit für den Neustart eines Systems bis hin zur Wiederbeschaffung der Hardware beim Lieferanten reichen. Die Reaktionszeit hingegen ist komponentenunabhängig und mit sehr viel geringerem Aufwand optimierbar. Hierfür müssen die Dienste kontinuierlich auf ihre Funktionsfähigkeit von einer zentralen Instanz, einem Monitoringsystem, geprüft werden. 3.2 Netzwerkmanagement Bevor über Monitoring gesprochen werden kann, muss verstanden werden in welchem Bereich des Netzwerkmanagements die Überwachung angesiedelt ist. Die International Standard Organisation (ISO) und die International Telecommunication Union (ITU) bietet dafür in ihren Standards ISO [20] bzw. ITU-T X.700 [21] ein Modell namens FCAPS, welche den Initialbuchstaben der folgenden Punkte abgeleitet ist: 1. Fault Management: beschreibt das Erkennen und Beheben von Fehlern 2. Configuration Management: beschreibt das Sammeln und Speichern von Netzwerkinformationen sowie die Pflege dieses Datenbestandes 3. Accounting Management: beschreibt das Abrechnen der Nutzung von Netzwerkkomponenten 4. Performance Management: beschreibt die Erfassung von Leistungsdaten und die sich daraus ergebende Skalierbarkeit von Systemressourcen 5. Security Management: beschreibt den Umgang mit Schwachstellen von Systemen sowie Mechanismen zur Authentifizierung und Autorisierung Die Überwachung befindet sich demnach im Fault Management und beschreibt das Erkennen von Fehlern. Das IP Managementsystem hingegen, welches die Datenbasis des Monitoring darstellt, ist im Punkt Configuration Management anzusiedeln. Das Accounting-, Performance- und Security-Management werden in dieser Arbeit nicht weiter ausgeführt. Das Fault Management verfügt über Kennzahlen, die verschiedene

15 15 Aspekte im Lebens- bzw. Ausfallzyklus der Systeme wiedergeben. Die für diese Arbeit wichtigsten Kennzahlen werden kurz vorgestellt. 1. MTFD Mean Time between Failure and Disclosure beschreibt die mittlere Dauer zwischen dem Auftreten des Fehlers und dessen Entdeckung 2. MTTR Mean Time To Repair beschreibt die mittlere Dauer zwischen der Entdeckung des Fehlers und dessen Behebung 3. MTFR Mean Time between Failure and Repair beschreibt die mittlere Dauer zwischen dem Auftreten des Fehlers und dessen Behebung MTFR stellt die Summe von MTFD und MTTR dar und kann als mittlere Dauer der Ausfallzeit angesehen werden. Während MTFD die mittlere Dauer der Reaktionszeit widerspiegelt und MTTR die mittlere Dauer der Instandsetzungszeit beschreibt. 3.3 Netzwerkmonitoring Um ein Monitoringsystem in Betrieb nehmen zu können, muss definiert werden was zu überwachen ist, und vor allem wie zu überwachen ist. Bei EDV Systemen die in einem Computernetzwerk miteinander interoperieren ist es angemessen, die bestehende Netzwerkinfrastruktur für die Überwachung zu nutzen, anstatt neue physikalische Strukturen aufzubauen. Dadurch unterliegt das Monitoringsystem den gleichen Vorund Nachteilen wie andere Netzwerkapplikationen. Um die gegenseitige Abhängigkeit einzelner Prüfmechanismen in einem Computernetzwerk zu verstehen, sollte das ISO/OSI 7 Schichtenmodell näher betrachtet werden, welches 1984 von der International Standardization Organization als Open System Interconnection Standard veröffentlicht wurde. Ziel der Standardisierung war es, Normen zu entwickeln, welche die Kommunikation in unterschiedlichen Sprachebenen abbilden. Dabei ergänzt jede Ebene die Nachrichten der darunterliegenden Ebene um weitere spezifische Informationen. Dieser Aufbau wird bei der Überwachung in einem IP basierten Netzwerk genutzt. Nachdem die korrekte Funktion der Schicht n ein notwendiges Kriterium für die Funktion der Schicht n+1 ist, impliziert ein Fehler der Ebene n einen Fehler der Ebenen n+m mit m>0. Umgekehrt kann davon ausgegangen werden, dass einer funktionierenden Schicht n eine intakte Schicht n-m mit m>0 vorangehen muss.

16 16 7. Anwendungsschicht 6. Darstellungsschicht 5. Sitzungsschicht 4. Transportschicht 3. Netzwerkschicht 2. Verbindungsschicht 1. Bitübertragungsschicht HTML HTTP Port 80 Transmission Control Protocol Internet Protocol Ethernet CAT 5 Verkabelung Abb. 3: Zuordnung Webserveraufbau zum ISO / OSI 7 Schichtenmodell Das obige Beispiel verdeutlicht die Abhängigkeit der Schichten in einem TCP/IP Netzwerk beim Betrieb eines Webservers. Wird bereits in der Netzwerkschicht (Ebene 3) ein Fehler festgestellt, ist ein Test zur Überprüfung der korrekten Funktion der Webserverapplikation (Ebene 7) unnötig, da der Server ohnehin nicht erreicht werden kann. Ein korrekter Aufruf der Webseiten hingegen impliziert die fehlerfreie Funktion des darunterliegenden Netzwerks. Zusammenfassend können folgende zwei Punkte festgehalten werden: 1. Funktion der Schicht n ist notwendiges Kriterium für die Funktion der Schicht n+1 2. Funktion der Schicht n ist hinreichendes Kriterium für die Funktion der Schichten n-m mit m>0 Dadurch ergeben sich bei der Überwachung eines Systems zwei unterschiedliche Herangehensweisen, die aus Sicht eines Anwenders und die aus Sicht eines Administrators. Aus Anwendersicht ist es interessant, ob eine Applikation korrekt arbeitet. Die Checks um dies zu validieren sind in Schicht 7 anzusiedeln. Damit könnte sehr schnell eine Aussage darüber getroffen werden, ob eine Fehlerbehebung eingeleitet werden muss oder nicht. Aus Administrationssicht ist der Nachweis der korrekten Funktion der einzelnen Ebenen von unten nach oben ebenso wichtig. Mit diesem Ausschlussverfahren können

17 17 funktionierende Schichten aus der Fehlersuche ausgegrenzt werden bis die Fehlerquelle lokalisiert wurde. In der Praxis ist es nicht immer möglich direkt an der untersten Schicht, der Bitübertragungsschicht, zu messen, daher wird häufig mit der Verbindungsschicht (Ebene 2) oder der Netzwerkschicht (Ebene 3) begonnen. 3.4 Dynamic Host Configuration Protocol In den Requests for Comments (RFC) 2131 [16] wird das Dynamic Host Configuration Protocol (DHCP) wie folgt definiert: The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. Damit ein Rechner in einem TCP/IP Netzwerk kommunizieren kann, müssen einige Parameter gesetzt werden. Die wichtigsten sind: 1. IP-Adresse: eine 32-stellige Binärzahl, die innerhalb eines Netzwerks eindeutig ist. Sie besteht aus einem Netzwerkteil und einem Geräteteil. 2. Netzmaske: eine 32-stellige Binärzahl, die angibt, wie viele Bits am Anfang einer IP-Adresse zum Netzwerkanteil gehören. Die übrigen Bits gehören zum Geräteteil. Die Netzmaske definiert somit die Größe des Netzwerks. 3. Standardgateway: in der Regel die IP-Adresse eines Routers. Sie ist notwendig, um mit Rechnern zu kommunizieren, die außerhalb des eigenen Netzwerks liegen. Die Einstellungen können entweder manuell am jeweiligen Rechner erfolgen oder aber automatisch von außen zugewiesen werden. Für die automatische Zuweisung wird das Dynamic Host Configuration Protocol (DHCP) verwendet. Der Hauptvorteil dieses Verfahrens besteht darin, dass die Einstellungen des Netzwerks zentral an einer Stelle modifiziert werden können, anstatt umständlich jeden Rechner einzeln konfigurieren zu müssen. Dabei wird unterschieden zwischen dem dynamischen und dem statischen DHCP. Ersteres wird besonders dann benötigt, wenn die Anzahl von IP-Adressen stark limitiert ist und sich viele Rechner einen kleinen Pool von IP-Adressen teilen müssen. Dabei wird die IP-Adresse nicht exklusiv und dauerhaft für einen Rechner reserviert, sondern nach Ablauf der Nutzung wieder freigegeben. Da das Universitätsklinikum

18 18 Erlangen über eine ausreichende Anzahl von IP-Adressen verfügt, wird das statische DHCP verwendet. Es bietet den Vorteil, dass durch die dauerhafte Zuordnung der IP- Adressen zu einem Rechner besser nachvollziehbar ist, welcher Rechner zu einem bestimmten Zeitpunkt Daten im Netzwerk kommuniziert hat. Hierfür wird die Media Access Control (MAC), die für jede Netzwerkkarte eindeutig ist, mit der zugeordneten IP-Adresse in den DHCP Dienst eingetragen [1][2]. 3.5 Domain Name System Der Domain Name System (DNS) wird wie folgt beschrieben [14]: DNS handles mapping between host names, which we humans find convenient, and between internet addresses, which computers deal with. Der Einführung eines Domain Name Systems liegt zugrunde, dass die Rechner in einem TCP/IP Netzwerk mit IP-Adressen kommunizieren, welche aus 32-stelligen Binärzahlen bestehen. Für den Menschen sind diese Adressen schwierig zu handhaben. Zwar werden die IP-Adressen in der Darstellung in Hexadezimalwerte umgewandelt, dennoch ist es kaum möglich, sich bei der Vielzahl von Servern in einem Netzwerk mehr als ein paar Serveradressen zu merken. Aus diesem Grund erhalten Rechner zusätzlich einen Hostund Domainnamen. Das Domain Name System gewährleistet dann die Zuordnung zwischen den Hostnamen und den IP-Adressen, analog zu einem Telefonbuch, das Namen Telefonnummern zuordnet. 3.6 Monitoringsystem Nagios Die Software Nagios wurde 1999 von Ethan Galstad entwickelt und dient der Überwachung von Rechnern und Diensten in einem Computernetzwerk. Dabei bietet das System sowohl eine Weboberfläche auf der Ergebnisse veröffentlicht werden, als auch eine Komponente zur proaktiven Benachrichtigung im Fehlerfall per oder SMS. Zum Zeitpunkt der Erstellung dieser Arbeit befindet sich Nagios in der Version 2.7 und steht unter der General Public Licence (GPL). Somit handelt es sich um eine freie Software, die auch für kommerzielle Nutzung kostenlos verfügbar ist.

19 Grundlagen irgendwo in Deutschland läuft in einem Krankenhaus die Festplatte voll, auf der die zentrale Oracle-Datenbank ihre Logfiles ablegt. Zwar gehen im OP deswegen nicht die Lichter aus, da aber die Datenbank ihre Arbeit verweigert, kommt es zu erheblichen Störungen im Betriebsablauf: Patienten können nicht aufgenommen werden, Untersuchungsergebnisse lassen sich nicht abspeichern und Befunde nicht dokumentieren solange bis das Problem behoben ist. [4] Bereits in der Einleitung zum Buch Nagios beschreibt Wolfgang Barth welche Bedeutung die Verfügbarkeit im Betrieb von EDV Anwendungen einnimmt und wie die Ausfallzeit mit dem Überwachungssystem Nagios minimiert werden kann. Dabei orientiert sich das Monitoringsystem an einer Ampel mit drei Zuständen, grün wenn das geprüfte Kriterium korrekt arbeitet, gelb wenn eine Warnung vorliegt und rot wenn etwas fehlerhaft bzw. kritisch ist. Die jeweiligen Zustände können unabhängig vom vorhergehenden Zustand erreicht werden. ok warning critical Abb. 4: Graph eines Automaten zur Anzeige von Prüfergebnissen im Nagios Umgesetzt wird dieses Konzept mit einem sehr modularen System, in dessen Kern ein Scheduler sitzt. Dieser führt in vordefinierten Zeitintervallen Prüfkommandos aus, welche als Plugins bezeichnet werden, und wartet anschließend auf einen Rückgabewert. Es können folgende Werte zurückgegeben werden. 0: OK 1: WARNING 2: CRITICAL

20 20 Abhängig vom Rückgabewert leitet Nagios ein weiteres Kommando ein. Das kann sowohl die Benachrichtigung eines Administrators sein, als auch ein Automatismus der versucht den Fehler zu beheben Prüfmechanismen Nagios verfügt über unterschiedliche Mechanismen um Tests durchzuführen. Zum einen können Abfragen des überwachten Servers vom Monitoringsystem direkt ausgehen, zum anderen ist es möglich über Zusatzapplikationen indirekt zu prüfen. Die drei wichtigsten Typen von Prüfmechanismen sind Netzwerktests, SNMP-Abfragen und Tests, die über einen Client erfolgen, der auf dem überwachten Server installiert wird Netzwerktest Eine einfache Art und Weise um Server und Dienste auf Ihre Verfügbarkeit zu prüfen, ist anhand von Netzwerktests möglich, welche die Funktionalität eines TCP/IP Ports verifizieren und darüber kommunizierte Daten auswerten. Hierfür ist es ausreichend, die Prüfmechanismen auf dem Nagios Server zu implementieren. Eine Modifikation des überwachten Servers ist nicht nötig. Nagios Server Server Nagios Daemon 0, 1, 2 Check Plugin Webserver Port Abb. 5: Funktionaler Aufbau eines Netzwerktests mit Nagios Netzwerktests sind im ISO/OSI 7 Schichtenmodell auf Ebene drei bzw. vier anzusiedeln und dienen meist dazu, eine Basisüberwachung der Server zu gewährleisten.