System- und Ressourcenüberwachung eines komplexen Unternehmensnetzwerks mit Hilfe einer Monitoringsoftware in einer virtuellen Systemumgebung

Thema: System- und Ressourcenüberwachung eines komplexen Unternehmensnetzwerks mit Hilfe einer Monitoringsoftware in einer virtuellen Systemumgebung Cacti

Inhaltsverzeichnis: 1. Projektbeschreibung 1.1. Titel des Projektes 1.2. Wesentliche Zielsetzung des Projektes 1.3. Beschreibung der Ausgangslage des Projektes 1.4. Beschreibung des Projektumfelds 1.5. Beschreibung der resultierenden Aufgabenstellung aus persönlicher Sicht 1.6. Beschreibung relevanter Prozessschnittstellen aus persönlicher Sicht 1.7. Auflistung der Teilprozesse des Referenzprojektes aus persönlicher Sicht 2. Prozesskompass 2.1. Change Management 2.1.1. Analysieren der Anforderung 2.1.2. Erstellen der Prozessdokumentation 2.1.3. Informieren der Betroffenen Personen/Stellen 2.1.4. Ausarbeiten eines Angebotes 2.1.5. Planen der Abwicklung 2.1.6. Beschaffen der erforderlichen Komponenten 2.1.7. Installieren der Komponenten 2.1.8. Konfigurieren nach Anforderung 2.1.9. Überprüfung der durchgeführten Arbeiten 2.1.10 Durchführen der Übergabe 2.2. Fault Management 2.2.1. Durchführen der initialen Bereitstellung 2.2.2. Durchführen kontinuierlicher Überwachung 2.2.3 Wahrnehmen der Störung 2.2.4 Erstellen der Prozessdokumentation 2.2.5 Informieren der betroffenen Stellen 2.2.6 Lokalisieren der Störung 2.2.7 Eingrenzen der Fehlerart 2.2.8 Planen der Abwicklung 2.2.9 Ausführen der Arbeiten nach Plan 2.2.10 Durchführen von Tests (im Fehlerumfeld) 2.3 Performance Management 2.3.1 Durchführen der initialen Bereitstellung 2.3.2 Durchführen von kontinuierlichen Messungen 2.3.3 Erstellen einer Prozessdokumentation 2.3.4 Informieren betroffener Personen/Stellen 2.3.5 Analysieren der Schwellwertüberschreitungen 2.3.6 Lokalisieren des Engpasses 2.3.7 Erstellen von Handlungsalternativen 2.3.8 Ausführen Changemanagement - 2 -

2.4 Security Management 2.4.1 Umsetzen der Richtlinien auf Netzwerkebene 2.4.2 Durchführen kontinuierlicher Kontrollen 2.4.3 Umfassendes Informieren 2.4.4 Analysieren der Anforderung 2.4.5 Erstellen der Prozessdokumentation 2.4.6 Informieren betroffener Stellen 2.4.7 Untersuchen der Auswirkungen 2.4.8 Aktives Entwickeln von Umsetzungsmöglichkeiten 2.4.9 Reaktives Entwickeln von Umsetzungsmöglichkeiten 2.4.10 Ausführen Change Management 2.4.11 Ausführen Sicherheitscheck 2.5 Organisation und Beratung 2.5.1 Erstellen eines Vorschlages für Servicestrukturen 2.5.2 Durchführen von Service 2.5.3 Beraten von nicht-fachlichen Projektleitern 2.5.4 Bereitstellen von Netzwerkressourcen 3. Schlüsselsituationen 3.1. Meilenstein 1 3.1.1 Problemstellung 3.1.2 Ergebnis der Lösung 3.1.3 Lernertrag 3.2 Meilenstein 2 3.2.1 Problemstellung 3.2.2 Ergebnis der Lösung 3.2.3 Lernertrag 3.3 Meilenstein 3 3.3.1 Problemstellung 3.3.2 Ergebnis der Lösung 3.3.3 Lernertrag 3.4 Meilenstein 4 3.4.1 Problemstellung 3.4.2 Ergebnis der Lösung 3.4.3 Lernertrag 3.5 Meilenstein 5 3.5.1 Problemstellung 3.5.2 Ergebnis der Lösung 3.5.3 Lernertrag 3.6 Meilenstein 6 3.6.1 Problemstellung 3.6.2 Ergebnis der Lösung 3.6.3 Lernertrag - 3 -

1 Projektbeschreibung 1.1 Titel des Projektes System- und Ressourcenüberwachung eines komplexen Unternehmensnetzwerks mit Hilfe einer Monitoringsoftware in einer virtuellen Systemumgebung. 1.2 Wesentliche Zielsetzung des Projektes aus Gesamtprojektsicht Bedingt durch immer komplexere Systemlandschaften und immer knapper werdende personelle Ressourcen galt es eine Lösung zu finden, mit der die Performance des Netzwerkes der Firma???? optimiert wird und die Fehlersuche im Fehlerfall besser eingegrenzt werden kann. Letztlich sollen mit der projektierten Lösung auch die Ausfallzeiten des Netzwerks auf ein Minimum begrenzt werden. 1.3 Beschreibung der Ausgangslage aus Gesamtprojektsicht Durch die immer größeren und komplexeren Systemumgebungen ist eine Überwachung an allen Stellen gleichzeitig nicht mehr möglich. Im Zeitalter von heterogenen Netzwerken ist die Lokalisierung von Fehlern darüber hinaus meist sehr zeitintensiv. In vielen Fällen muss heute ein Teilbereich nach dem anderen überprüft werden und oftmals muss bei dem jeweils für einen Netzabschnitt zust. Spezialisten nachgefragt werden, ob Teile des Netzwerkes noch (oder wieder) ordnungsgemäß funktionieren. Damit verbundene längere Entstörzeiten sind einerseits sehr zeit- und kostenintensiv und andererseits nicht mehr zumutbar. Ziel des Projektes ist es deshalb, eine zentrale Überwachungsfunktionalität zu schaffen, die gut skalierbar ist und so mit dem Ausbau des Netzwerks und der stetig zunehmenden Komplexität des Netzwerkes mitwachsen kann. 1.4 Beschreibung des Projektumfeldes aus Gesamtprojektsicht. Das gesamte Projekt wurde innerhalb der EDV Abteilung der Fa???? durchgeführt, lediglich eine Zuliefererfirma wurde beauftragt. Eine der Problemstellungen dabei war, eine kostengünstige Lösung und schon vorhandene Ressourcen zu nutzen, ohne weitere Kosten zu verursachen oder Insellösungen zu produzieren. Alle Beteiligten waren unmittelbar mit der Problematik befasst. Es musste keine Übergabe oder Abnahme durch innerbetriebliche Stellen durchgeführt werden. - 4 -

1.5 Beschreibung der resultierenden Aufgabenstellung aus persönlicher Sicht. Erforderliche Software und die Art der Software musste von mir ausgewählt werden. Dabei stellte ich mir zunächst die Frage, ob es nicht die Möglichkeit gab, eine Software aus dem Open-Source Bereich zu wählen und diese in bestehende IT-Landschaften zu integrieren. Dabei war insbesondere zu klären, wie eine reine Windows Umgebung in einen Linux Server integriert werden kann. Es sollten hierbei jedoch keine weiteren Gelder in die Anschaffung neuer Server investiert werden. Der wesentliche Geschäftsablauf sollte zudem nicht unterbrochen werden. Die lange Erfahrung im Windows Server Betrieb zahlte sich hierbei selbstverständlich aus und ein ausgeprägtes Grundlagenverständnis sollte sich auch bezahlt machen. Ich musste mir erst einmal einen Überblick verschaffen, wie eine System- und Ressourcenüberwachung insgesamt aussehen soll. Was wird benötigt und vor allem wie gelange ich an die notwendigen Informationen? Grundsätzlich galt es, sich auf die Suche nach bereits vorhandenen Lösungswegen zu machen, denn solch ein Problem ist ja nichts Neues. Ich ging davon aus, dass andere Unternehmen sich sicherlich auch mit solchen Problemstellungen befassen müssen oder bereits befasst haben. 1.6 Beschreibung relevanter Prozessschnittstellen aus persönlicher Sicht Um mir erst einmal einen Marktüberblick zu verschaffen, recherchierte ich im Internet nach einer Monitoringsoftware und schaute mir die verschiedenen Herstellerseiten an, die kommerzielle Softwarelösungen anbieten. Hierbei fiel mir sofort die Software von Hewlett Packard (HP) auf. Diese, so schien es, ist eine der besten kommerziellen Softwarelösungen auf dem IT Markt und in dieser Softwaresparte. Ein Zulieferer für die virtuelle Umgebung ist auch die Fa. VMWare. Deren Softwarelösung ist zwar nicht kostenlos (wie z.b. Microsofts Virtuell Server), jedoch nutzt VMWare die Spezifikationen bzw. Netzwerktreiber von AMD, welche auch unter Linux vollständig kompatibel sind. Für die Auswahl der richtigen VM war nicht zuletzt mein Kollege verantwortlich, der selbst schon seit 2 Jahren in virtuellen Umgebungen Programme testete. In der ersten Phase musste ein passender Server ausgewählt werden, auf dem nicht zu kritische Geschäftsabläufe abgearbeitet werden. Zudem sollte dieser auch von der Arbeitsspeicher Ausstattung her genügend Hardware-Ressourcen aufweisen und größtmöglich dimensioniert sein. Es wurde entschieden, dass ein nicht mehr genutzter Server, der lediglich eine Datenbank des Intranets hostet, für diese Aufgabe bestens geeignet ist. Dieser ist für die Aufgabe des Hostings völlig überdimensioniert und bietet für die Aufgabe des Hostsystems der VMware genügend Ressourcen. Als Lösung wurde eine nicht mehr benötigte Lizenz einer VM Workstation freigestellt, sodass ich die virtuelle Umgebung schon auf dem Server installieren konnte. Um das Netzwerk nicht zu stören wurde jedoch die VM erst einmal komplett in ein Testnetzwerk integriert um evtl. Störungen zu vermeiden. - 5 -

Zeitgleich eignete ich mir in Sachen Linux Installation schon ein paar Grundlagen an und las mir hierzu diverse How-To s durch. Dabei stellte ich schon früh fest, dass es bei einem modernen Betriebsystem wie OpenSuse 10.2 mehrere Möglichkeiten gibt eine Linux Systemumgebung zu installieren. In der Open Source Community ist es üblich, in kurzen Intervallen Updates der Produkte auf den Markt zu bringen. Um nicht alte Pakete installieren zu müssen, entschloss ich mich eine Internetinstallation der OpenSuse Software durchzuführen. Hierbei benötigt man nur ein ca. 40 MB großes ISO Image statt des üblichen DVD Images. Eine Erleichterung des Installationsprozesses ergibt sich automatisch durch die Option, eine ISO Image an das virtuelle DVD-Laufwerk der VM einzubinden. Durch den Einsatz der Internetinstallation wurde auch gleichzeitig sichergestellt, dass alle Pakete auf dem neusten Stand sind und mit dem anschließenden Sicherheitsupdate auch alle kritischen Sicherheitslücken der diversen Pakete gestopft sind. Nach erfolgreicher Installation der Linux Systemumgebung musste noch sichergestellt werden, dass alles ordnungsgemäß funktioniert. Hierbei unterstützte mich ein Kollege aus der Entwicklungsabteilung, dessen Know-How für solch einen Test hervorragend war. Parallel wurden die Anforderungen an die Software von mir dokumentiert. Hierbei fielen direkt folgende must have - Features ins Gewicht: Erweiterbarkeit Plattformunabhängiges Checking Rescue managemant Low Cost Software Fall-Back/ Clustering Langzeit Reporting Notification managemant Support Nach dem Festlegen der key features wurde eine weitere Auswertung über den Einsatz einer Open Source Software angefertigt. Die nachfolgenden Punkte waren die wesentlichen Aussagen zu diesem Thema: Vorteile Individuelle Anforderungen Schnelle Updates Lücken werden schnell bekannt und geschlossen Keine Kosten Nachteile Kein fester Support Lange Projektlaufzeit Hohes Projektrisiko Keiner haftet durch Schäden an der Software Nach Klärung der must have -Kriterien wurden 2 Software Produkte ausgewählt, das System Monitoring Tool Nagios und das reporting und live data collecting Tool Cacti. - 6 -

Nach viel Überlegen wie man jetzt an die Sache am Besten rangeht, las ich erst mal die notwendigen how-to s und analysierte in diversen Internetforen die Angaben der Community. Dabei stellten sich schon die ersten Probleme ein. Ein Rezept für die Integration bzw. Installation gibt es an sich gar nicht. Jedes Netzwerk ist anders und es liegen andere Schwerpunkte bzw. Problematiken vor. Sollte das System warnen, wenn ein Fehler vorliegt, und vor allem wie soll es warnen? Die Frage, welches System verwendet werden sollte, war somit schnell geklärt. Die Wahl fiel auf Nagios, nicht zuletzt durch das hervorragende Framework und die darauf aufsetzenden Schnittstellen. Diese möchte ich nun einmal kurz vorstellen. Als Framework bezeichne ich zunächst einmal die Applikation Nagios, die an sich erst mal keine eigenen Checks durchführt und mit sich bringt. Zu diesem Zweck gibt es 3 verschiedene Arten. Nagios unterstützt das SNMP Protokoll, welches in fast allen netzwerkfähigen Geräten integriert ist. Hierbei unterscheidet man 3 Versionen, wobei SNMPv3 die aktuellste Version ist und schon mit Benutzername und Passwort fungiert. Zum Auslesen der einzelnen Statuswerte benötigt man einen SNMP Client, welcher im Wesentlichen das Interpretieren von Statusmeldungen umsetzt. Welche Statusmeldungen ein Gerät hat, steht in so genannten managed objects. Statusmeldungen werden in einer Datenbank gespeichert, der sog. MIB (management infomation base). Die MIB s sind in einer Baumstruktur organisiert. Die Baumstruktur ist nach RFC 1157 und Version 3 nach RFC 3410 genau festgelegt. In Bezug auf Nagios gibt es ein Plugin, welches in der Lage ist, diese MIB mit Hilfe des SNMP Paketes von Linux abzufragen. Hierbei muss jedoch die Antwort des Gerätes, welches in der Regel als String antwortet, noch interpretiert werden. Dies heißt genauer gesagt, man muss Nagios programmieren, wie systemseitig mit der Zeichenkette umgegangen werden soll. Hierbei kann dann konfiguriert werden, mit welchem Wert es warnen soll und bei welchem Wert es sofort eine Critical Meldung ausgeben soll. Zusätzlich kann die Meldung des Web-Frontend angepasst werden, um die Zeichenkette einem Objekt zuzuordnen und diese dann anwenderfreundlich abzubilden. Als weitere Schnittstelle ist der NRPE ( Nagios remote plugin executer) an das Framework angeschlossen. Diese ermöglicht es, Plugins auf einem entfernten Rechner auszuführen. Hierzu sendet es einen String an den entfernten Rechner, der wiederum prüft, ob sich ein solches String auch in seiner Konfiguration findet. Ist dies positiv, führt es einen Test aus und schickt das Ergebnis an den Nagios Server zurück. Zur Integration auf einem Linux Server muss der NRPE lokal auf der Maschine als Daemon mit dem Port 5666 laufen. Unter Windows gibt es hierzu einen zu installierenden Dienst Namens NSClient++. Dieser wird als Dienst auf der Windows Plattform installiert und lauscht auch wiederum - 7 -

auf Port 5666, jedoch kann zur Sicherheit noch zusätzlich konfiguriert werden, von welcher IP die Anfragen angenommen werden. Die letzte Schnittstelle und auch zugleich eine der am aufwendigsten zu konfigurierenden Programmteile des Nagios stellt die des NSCA (Nagios service check acceptor) dar. Ein Vorteil dieser Schnittstelle ist es, eine Statusmeldung zu empfangen, ohne dass die Schnittstelle selbst einen Check dabei ausführen muss. Dies bedeutet, dass kein aktiver Host- oder Servicecheck die Last des Systems oder der Netzwerkkarte nach oben treibt. Hierbei sendet ein anderer Nagios Server oder ein z.b. Windows Client einen bestimmt formatierten String an den NSCA Dienst des Nagios Servers. Dieser wiederum speichert diese Meldung in der Command Datei des Nagios Servers ab. Ein lokaler Plugin prüft innerhalb einer festgelegten Zeitspanne diese Datei und wertet den Inhalt aus. Dies nennt man bei Nagios einen passive Check. Um das Kriterium des Langzeit-Reportings abzudecken, kam das Tool Cacti in Frage. Dieses ist durchgängig in der Programmiersprache PHP geschrieben und plattformunabhängig. Hierbei muss auf dem Server zusätzlich noch das Paket net-snmp installiert werden. Dieses ermöglicht es der PHP Engine selbst SNMP Abfragen durchzuführen. Ergebnisse der Abfragen werden hierbei samt in einer MySQL Datenbank gespeichert und durch das Tool RDD von Tobi Ötiker graphisch dargestellt. Hierbei kann die Zeitspanne beliebig gewählt werden. So lässt sich zum Beispiel die CPU Auslastung des Webservers in einem Chart über einen Jahreszeitraum darstellen und analysieren. Eine Auswertung der downtimes der Server oder die Anzahl der angemeldeten Benutzer auf dem Terminalserver werden hierbei genau abgebildet und lassen sich hervorragend auswerten. Voraussetzung hierfür ist jedoch auch ein ausgeprägtes Verständnis und sehr gute Informationen über das SNMP Protokoll. Die Informationen der einzelnen Geräte ließ ich mir so weit es ging von den einzelnen Herstellern von Druckern oder Kopierern schicken. Hierbei erwies sich die Fa. Astaro als sehr hilfsbereit. Sie stellte mir eine genaue Tabelle der abrufbaren Informationen über ihr Produkt der Firewall zusammen. Ganz im Gegenteil zur Fa. Microsoft, welche Informationen über die Bedeutung der einzelnen Object Identifier (OI) nicht gerade anwenderfreundlich aufbereitet. Dies liegt meiner Meinung nicht zuletzt in der Produktpalette des Microsoft Operation Manager, welcher speziell für das Monitoring entwickelt wurde. Gleichzeitig bietet Microsoft auch keinen Schutz vor Zugriffen mittels Benutzer Authentifizierung, wie es im SNMP Version 3 der Fall ist. Unter Linux lässt sich dies schon einsetzen. Im Zuge des Sicherheitskonzeptes von Nagios war es erforderlich, den Zugriff auf Bereiche zu sperren. - 8 -

Dies machte sich schon in den ersten Schritten des Web-Frontends bemerkbar. Seltsamerweise waren einige CGI nicht aufrufbar. Durch das Hinzuziehen unseres Webdevelopers aus der Nachbarabteilung stellte sich ziemlich schnell heraus, dass es am Apache Webserver liegen musste, dessen CGI Einstellungen nicht korrekt waren. Zu diesem Zweck suchte ich in einem Forum nach der Lösung und fand schnell heraus, dass dies ein provozierter Fehler des Nagios ist mit dem Zweck, dass kein anonymer Zugriff auf die CGI stattfinden kann. Um diesen Schutz abzustellen musste ich in der globalen Konfigurationsdatei die CGI Sicherheitseinstellungen anpassen. Daraus resultierte eine Änderung der globalen httpd.conf Datei des Apache Webservers. Dieser muss mit einer einfachen Benutzer-Authentifizierung ausgestattet werden. Weiter ist es unabdingbar Aliase der Weboberfläche zu erstellen um die CGI und html Dateien korrekt zu laden und die Ausführbarkeit der CGI zu aktivieren. Über den Bereich der Benutzer Anmeldung wird auch die Rechtevergabe des Nagios gelöst. Hierbei fragt das Framework ab, welcher Benutzername erfolgreich angemeldet ist und gewährt für die in der nagios.conf konfigurierten Benutzer verschiedene Benutzerrechte. Als zusätzliche Sicherheit wurde der Zugriff auf den Webserver nur für das Administratoren Netz freigegeben, sodass sichergestellt wird, dass zum einen keine unberechtigte Anmeldung am System erfolgen kann und zum anderen alle Anmeldungen, ob access oder deny Anmeldungen, protokolliert werden. Das Sicherheitskonzept des Cacti gestaltete sich hierbei etwas unkomplizierter, da Cacti von Haus aus seine eigene Benutzerverwaltung anbietet. Benutzer werden in der normalen Konfigurations- Weboberfläche angelegt und deren Passwörter mittels MD5 Verschlüsselung innerhalb der MySQL Datenbank verschlüsselt abgelegt. Eine genaue Rechteverwaltung ist innerhalb des Cacti somit auch möglich. Um jedoch dem Sicherheitsaspekt noch etwas mehr Aufmerksamkeit zu widmen, wurde auch hier eine Benutzer Authentifizierung mittels.htaccess Datei mit in der Webserver Konfiguration eingestellt. Diese lässt selbstverständlich auch nur Anmeldungen aus dem Admin Netzwerk zu. Andere Verbindungen werden dabei abgewiesen. 1.7 Auflistung der Teilprozesse des Referenzprojektes aus persönlicher Sicht Name des Teilprozesses Im Betrieb absolviert Nicht im Betrieb absolviert 1. Change Management X - 2. Fault Management X - 3. Performance X - Management 4. Organisation und Beratung X - - 9 -

2. Der Prozesskompass 2.1 Teilprozesse des Referenzprozesses 1: Changemanagement 2.1.1 Analysieren der Anforderung Zeitraum für die Bearbeitung vom: 04.07.2007 bis: 05.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 2 Die genauen Anforderungen an ein Monitoring System wurden zunächst von mir analysiert und festgelegt. Dabei stellte sich heraus, dass durch die immer knapper werdenden personellen Ressourcen und die immer komplexeren heterogenen Systemumgebungen immer häufiger Fehler auftreten. Die Kosten durch Ausfälle der IT Infrastruktur betrugen bei deutschen Unternehmen laut Umfrage 1,6 Mrd. in 2006. Ein dreitägiger Ausfall gilt für 25% aller Unternehmen als existenzbedrohend. Aus diesem Anlass wurde auch in unserem Unternehmen über die Vermeidung und frühzeitige Erkennung eines Ausfalls nachgedacht. Die Struktur des Netzwerkes bestand bisher aus 7 Servern wobei 2 Server eine Sicherstellung des Betriebes und eine max. Verfügbarkeit von 99% aufweisen müssen. Diese sind der Webserver und der Exchangeserver als Mailgateway. Was die Art der Monitoring Software betraf, so entschloss ich mich für eine komplette Open Source Umgebung. Nicht nur zuletzt durch die Kosten der Anschaffung durch Lizenzen sammelten Nagios und das Langzeit Reporting Tool Cacti Pluspunkte. Die Erweiterbarkeit des Nagios ist optimal abgedeckt. Zum einen bringt die Software eine Vielzahl von Plugins schon von Haus aus über das zusätzliche Softwarepaket mit und zum anderen besteht die Möglichkeit über die Community an weitere Checks zu gelangen. Im unwahrscheinlichen Fall, dass es mal keinen Service Check zu einem System geben sollte, besteht die Chance zur eigenen Erstellung und Programmierung solcher Programme. Durch die ständige Expansion der IT Landschaft kann ein zusätzlicher Nagios Server aufgesetzt werden und beide zu einem Cluster zusammengeführt werden. Aus Kostengründen wurde beschlossen, eine nicht mehr benötigte VMWare Lizenz zu nutzen und die Linux Umgebung in einer virtuelle Umgebung zu integrieren. - 10 -

2.1.2 Erstellen einer Prozessdokumentation Zeitraum für die Bearbeitung vom: 06.07.2007 bis: 06.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 1 Die von mir erstellte Anforderungsanalyse des Monitoringsystems wurde im Qualitätsmangement Handbuch (QM) abgelegt und ist damit jederzeit für jeden Mitarbeiter öffentlich zugänglich. In einem Projekttagebuch wurden alle projektrelevanten Arbeiten dokumentiert und festgehalten. Weiter wurden alle kritischen Arbeitsschritte gesondert ausgeführt. Eine Installationsanleitung des Nagios und des Cacti wurde beigelegt. Alle Konfigurationsdateien oder SNMP Abfragen wurden mitunter in das Projekttagebuch integriert und auszugsweise abgeheftet. Sollten externe Firmen oder neue Mitarbeiter sich einmal in das Projekt einarbeiten müssen, so ist jederzeit gewährleistet, dass sie sich einen umfassenden Überblick über das Projekt verschaffen können. Durch den Einsatz einer VMWare wäre auch die Weitergabe an Kollegen oder andere Firmen zum Testen kein Problem. Einzig die Neukonfiguration der IP- Adresse des Netzwerkadapters der Linux Distribution müsste einmal neu eingestellt werden, weil sich in jeder VMWare die statische MAC-Adresse neu einstellt, durch den Wechsel des Mastersystems der Virtuell Maschine. Die komplette IP-Adress Konfiguration wird aus diesem Grund auch dokumentiert. - 11 -

2.1.3 Informieren betroffene Stellen Zeitraum für die Bearbeitung vom: 09.07.2007 bis: 09.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 0,5 Da das Projekt nicht einer zeitlichen Terminierung unterlag, war es unerheblich einen genauen Zeitplan mittels Gantt- Diagramm aufzustellen und gewisse Pufferzeiten einzuplanen. Dennoch wurde der Projektumfang min. über 2 Wochen angesetzt. Da sich schnell große Fortschritte einstellten, wurde die Projektdauer nicht in Frage gestellt. Wöchentlich wurde die IT-Leitung über den Verlauf des Projektes informiert. Zudem konnte sich jeder Projektmitarbeiter jederzeit durch das Projekttagebuch über den Verlauf und den aktuellen Stand des Projektes informieren. Bei einigen kritischen Abschnitten wurden zusätzlich die Vorgesetzten per E- Mail über den aktuellen Status informiert. - 12 -

2.1.4 Ausarbeiten des Angebotes Zeitraum für die Bearbeitung vom: 09.07.2007 bis: 09.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 0,1 Da das Projekt ein internes Projekt der Firma???? ist, wurde kein Angebot erstellt. Lediglich der Aufwand an Software und Kosten der Mitarbeiter wurden auf Kostenstellen innerhalb des Unternehmens gebucht. Dies erledigte die Buchhaltung bzw. das Controlling. - 13 -

2.1.5 Planen der Abwicklung Zeitraum für die Bearbeitung vom: 09.07.2007 bis: 11.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 2 Trotz der nicht terminierten Dauer des Projektes wurden verschiedene Phasen des Projektes in einer groben Zeitachse abgebildet. Hierbei wurden jedoch nur die wesentlichen Phasen berücksichtigt. Übersicht TAG 1 6: Installation VMWare Installation Linux Installation Nagios TAG 7 12: Konfiguration Nagios Installation Cacti Konfiguration Cacti TAG 13 15: Diverse Tests der Konfiguration Nach der groben Planung des Projektes wurde nun auch die gesamte Dauer des Projektes ersichtlich. Hierzu fehlte lediglich noch der Zeitpunkt der Einführung, der jedoch noch nicht terminlich festgesetzt werden konnte. Dieser wird voraussichtlich nach den Tests der Konfigurationen angesetzt. Zur fertigen Planung besorgte ich mir nun noch aus dem Qualitätsmanagement- Handbuch eine vollständige Liste des gesamten IT Equipments der Firma. Diese wird regelmäßig im Abstand von 14 Tagen mit Hilfe eines Inventarisierungstools erstellt. Daraus ergab sich auch eine genaue Liste der IP- Adressen zu den einzelnen Maschinen. Ergänzt wurde dies noch durch einen Auszug der vergebenen IP s des DHCP Servers. - 14 -

2.1.6 Beschaffung der erforderlichen Komponenten Zeitraum für die Bearbeitung vom: 12.07.2007 bis: 12.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 0,5 Da fast alle Komponenten unter die GPL (General Public License) fallen, ist lediglich ein Download aus dem Internet fällig. Selbst die Linux Distribution ist frei im Internet erhältlich. Durch die Installationsart der Internetinstallation musste nur das passende Image aus dem Internet heruntergeladen werden. Die Lizenz der VMWare war bereits schon im Besitz der Firma und konnte ohne weiteres dafür genutzt werden. Lediglich ein Vermerk im Lizenzhandbuch ist dafür nötig und wurde von mir abgezeichnet. Darin ist festgehalten, welche Lizenz in welchem Projekt verwendet ist oder ob diese noch frei ist. Der Server musste auch nicht beschafft werden, weil dieses Gerät schon im aktiven Einsatz war und nur noch die virtuelle Maschine von mir darauf installiert werden musste. - 15 -

2.1.7 Installieren der Komponenten Zeitraum für die Bearbeitung vom: 13.07.2007 bis: 18.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 4 Die Installation der VMWare-Umgebung erfolgte direkt im Wirkbetrieb des Servers. Das Einstellen der virtuellen Maschine erfolgte nach dem Installationsassistenten. Es musste nur darauf geachtet werden, dass der VM genügend Arbeitsspeicher zur Verfügung steht. Durch meinen Entschluss der Internetinstallation der Linux Distribution konnte das Installationsimage an das virtuelle CD-Rom Laufwerk gekoppelt werden. Nach dem Booten des Images konnte ich mit Hilfe einer Anleitung und dem Eintrag verschiedener Parameter der Netzwerkeinstellung den FTP Server erreichen. Dort lud sich automatisiert ein YAST Setup Tool in den RAM. Nach der Auswahl der Partitionierung der virtuellen Festplatte begann ich sorgfältig mit der Auswahl der Programme für das Grundsystem. Dort begrenzte ich mich nur auf die wesentlichen Dinge wie der Webserver, und auf die verschiedenen Hilfsprogramme wie Net-SNMP. Durch das Fertigstellen der Installation waren einige Prüfungen nötig, wie z.b. das Überprüfen der Firewall und das Einstellen versch. Daemons. Dazu zählte auch das Verändern der einzelnen Runlevels. Damit sollte gewährleistet werden, dass nur die nötigsten Programme beim Systemstart gestartet werden, um unnötige Last auf der Maschine zu reduzieren. Unmittelbar danach machte ich mich an die Installation des Nagios. Dies wurde zunehmend komplizierter. Mit Hilfe einiger Foren und einer guten Installationsanleitung des Heise Zeitschriftenverlages konnte ich mich mühselig durch die Installation hangeln. Das Problem verschiedener Anleitungen ist oftmals durch die Versionsunterschiede der einzelnen Distributionen begründet. Nachdem der Abschluss der Grundinstallation abgeschlossen war, waren noch einige Schritte nötig, um die Sicherheitseinstellungen der CGI Dateien einzustellen. Hierzu befragte ich unseren Webdeveloper, der mir Informationen über CGI Dateien gab. Darüber hinaus wurde ich in einem Internet-Forum fündig. Hier wurde genau erläutert, welche Sicherheitseinstellungen getroffen werden mussten, um die Ausführbarkeit der CGI einzustellen. Bis hierhin stand das Grundsystem nun erstmal. Jetzt musste noch die Plugins kompiliert werden mit, denen das Nagios Framework die Hosts testet. - 16 -

Die Installation der Windows Services wurde mit Hilfe der automatisierten Installation der Active Directory von mir durchgeführt. Damit wurde sichergestellt, dass alle Clients beim nächsten Anmelden an der Domäne den Service NsClient++ installiert werden und im Netzwerk nur auf Anfragen des Nagios Frameworks antworten. Die Installation des Cacti Programms verlief ohne weitere Zwischenfälle. Hierzu musste lediglich ein Datenbankbenutzer und eine dazugehörige Datenbank angelegt werden. In einer Config. Datei mussten jetzt die Parameter eingetragen werden, um den Installationsvorgang zu beenden. - 17 -

2.1.8 Konfiguration nach Anforderung Zeitraum für die Bearbeitung vom: 19.07.2007 bis: 23.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 3 Der erste Schritt bestand darin, alle Hosts in der globalen hosts.cfg einzurichten. Hierzu nahm ich die Inventarisierungsliste zur Hand, welche mir die IP-Adressen der einzelnen Computer verriet. Innerhalb dieser Datei wurden dann die nach einer bestimmten Syntax einzugebenden Hosts angelegt. Gleichzeitig habe ich die Informationserweiterungsdatei der Hosts mit ausgefüllt, welche zusätzliche Informationen zu den einzelnen Hosts führt und wichtige Infos über OS Stand und ein Bild der Maschine im Nagios- Monitor anzeigt. Der Abschluss der Hostkonfiguration wurde ergänzt durch die Typierung der einzelnen Hosts in sog. Hostgruppen. Dies hat den Vorteil, sich im Rahmen des Fault Managements schnell Übersicht über Server, Workstations oder Drucker verschaffen zu können. Bezüglich des Securitymanagements wurde noch die Rechteverwaltung der Benutzer in der zentralen Nagios Hauptkonfigurationsdatei erweitert und verschiedene Benutzer eingesetzt, um Support Mitarbeitern z.b. das Neustarten des Nagios Prozesses zu verbieten. Zusätzlich wurde das Verzeichnis mit Hilfe einer.htaccess Datei gesichert, um nicht jedem User den aktuellen Gesundheitszustand direkt zu verraten, und um die Benutzer des Nagios anzulegen. Darüber hinaus wurden noch die Servicechecks der einzelnen Hosts angelegt. Diese Konfigurationsdatei musste auch nach bestimmter Syntax angelegt werden, welche ich mir auszugsweise aus einem Forum besorgte. Diese Servicechecks definieren im Rahmen des Faultmanagements auch die Schwellwerte wann Warnungen und kritische Systemzustände eintreten. Besonderes Interesse widmete ich dem Plugin check_nt. Dieser musste für die einzelnen Windows Checks konfiguriert werden, welche mit Hilfe des Windows Services NsClient++ aktuelle Systemzustände aus der Leistungsanzeige von Windows ausliest und auf Anfrage des Nagios bereitstellt. Weiter wurden noch verschiedene Zeitperioden definiert, wann z.b. bei Fehlern benachrichtigt wird. Die Abfrage der Drucker und deren Systemstatus erfolgt über bestimmte OID s des SNMP. Diese testete ich erstmalig an den verschiedenen Druckern und definierte die Systemzustände aufgrund bestimmter Rückgabewerte. - 18 -

Zur Langzeitüberwachung wurden die einzelnen Devices nach der Inventarisierungsliste vom mir angelegt und die bereits Standard im Auslieferungszustand befindlichen Graphen verwendet. Diese zeigen z.b. die Auslastung der Netzwerkkarte oder die der CPU. - 19 -

2.1.9 Überprüfen der durchgeführten Arbeiten Zeitraum für die Bearbeitung vom: 24.07.2007 bis: 24.07.2007 Eigener tatsächlicher Zeitbedarf (in Arbeitstagen): 1 Zur korrekten Überprüfung der Syntax überprüfte ich die Nagios Konfiguration mit dem Befehl: /srv/www/htdocs/nagios/bin/nagios v /srv/www/htdocs/nagios/etc/nagios.cfg Erst als dieser Check ohne Fehlermeldung abgeschlossen war konnte ich das Nagios Programm starten. Die Sicherheitseinstellungen des Webservers wurden anhand von falschen Anmeldeversuchen überprüft. Zur Sicherheit habe ich danach noch die Log Datei des Webservers geprüft, um das Aufzeichnen der fehlerhaften Anmeldungen zu prüfen. Die Funktionsweise des Nagios stellte ich anhand der Weboberfläche fest. Diese zeigte mir die Ergebnisse der einzelnen Checks an. Um sicher zu gehen, dass auch alles funktioniert, erzeugte ich einen ausgewählten Fehler an einem Rechner. Die korrekte Funktion des Cacti erfolgte auch über die Weboberfläche. Die Anzeige der Graphen über die gesammelten Daten der Devices stellte die reibungslose Funktionsfähigkeit in keiner Weise in Frage. Der Versand der Warnungs E-Mails wurde am zentralen Mail-Gateway getestet. Dort schaute ich in den log Dateien nach, ob die E-Mails an die zuständigen Administratoren das Gateway passieren. - 20 -