Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät für Informatik, Mathematik und Naturwissenschaften. Projektarbeit

Transkript

1 Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät für Informatik, Mathematik und Naturwissenschaften Projektarbeit ZENOSS ALS TOOL ZUR NETZWERKÜBERWACHUNG COMMERCIAL OPEN SOURCE APPLICATION FOR SYSTEM UND NETWORK MONITORING verfasst und vorgelegt von B.Sc. Michael Schmidt Mat.Nr B.Sc. Matthias Rick Mat.Nr Leipzig, den 22. April 2010

2 Inhaltsverzeichnis Einleitung 1 1 Theoretische Grundlagen allgemeine Grundlagen Das OSI -Referenzmodell IP-Adressklassen (IPv4) Netzwerkmanagement RRDTool Simple Network Management Protokoll Management Information Base Netzwerkmanagement Systeme Cacti Nagios Netzwerkmanagement mit Zenoss Was ist Zenoss Architektur User Layer Data Layer Collection Layer Installation und Konfiguration Installation Konfiguration der Server SNMP Installation und Konfiguration unter Linux WMI Installation und Konfiguration unter Windows XP Management Überwachung von Servern Serverüberwachung mit SNMP Serverüberwachung mit WMI Das Userinterface Main Views I

3 Inhaltsverzeichnis Inhaltsverzeichnis 5.2 Event Classes Monitoring CPU Auslastung Festplattenüberwachung Speicherüberwachung Management 39 8 Schlusswort Zusammenfassung Fazit Abbildungsverzeichnis Tabellenverzeichnis Glossar Abkürzungsverzeichnis Literaturverzeichnis III IV V VIII X II

4 Einleitung Motivation Netzwerk-Management bekam mit der steigenden Komplexität von Netzwerken immer mehr Bedeutung. Um diese Netzwerk-Systeme zu pflegen und die Administratoren bei deren Arbeit zu unterstützen ist es für viele Firmen und Institute unerlässlich, Pakete für das System- und Netzwerkmanagement einzusetzen. Diese sind in der Lage Administratoren bei Problemen mit Rechnern, Diensten und Ressourcen umgehend zu benachrichtigen und bei der Fehlersuche zu assistieren. Informationen können dabei häufig verdichtet werden, bei Bedarf aber auch umfassend informieren. Kommerzielle Lösungen stellen beispielsweise Tivoli (IBM), Openview (HP), Unicenter (Computer Associates) und Patrol (BMC) dar, die in der Lage sind, tausende von Servern zu verwalten und zu überwachen. Der Anschaffungspreis, den ein Unternehmen für solch ein umfassendes Schwergewicht zahlen muss, ist jedoch meist nicht rentabel. Deswegen ist es vor allem für kleinere Firmen sinnvoll nach Alternativen im Open-Source-Sektor zu suchen. Dabei gibt es neben Werkzeugen wie Nagios, Cacti, Big Sister und Ganglia auch das Netzwerk-Management-System Zenoss, welches durch eine Vielzahl an Funktionen und nahezu beliebige Erweiterbarkeit durch Plugins besticht. Inhalte dieser Arbeit Diese Arbeit betrachtet das System- und Netzwerk-Management-Werkzeug Zenoss. Grundlegend werden zwei Versionen von Zenoss entwickelt, eine kostenpflichtige Enterprise Version und eine Open Source Version, welche unter der General Public License (GPL)v2 zum freien Download zur Verfügung steht. In der vorliegenden Projektarbeit wird lediglich die Open Source Version betrachtet. Trotzdem kann dabei nicht die gesamte Palette an Funktionen und Einsatzmöglichkeiten beleuchtet werden, wodurch nur Grundkonzepte und spezielle Teilaspekte des Systems zur Sprache kommen werden. Die Arbeit lässt sich in zwei Teile untergliedern. Der erste Teil beschäftigt sich zunächst mit den theoretischen Grundlagen der Netzwerktechnik und gibt allgemeine Informationen über die Grundkonzepte von Zenoss. Anschließend folgen dann im Kapitel 3 die Installation und Konfiguration von Zenoss. Dabei stellt sich heraus, dass diese Schritte aufgrund ihrer 1

5 Einleitung Komplexität Einsteiger ohne Fachkenntnisse überfordern, sie erlauben aber auch eine hohe Flexibilität und Anpassung an eine Vielzahl von Problemen. Weiterhin wird besonders die Funktionalität der Weboberfläche beschrieben, welche es dem Administrator ermöglicht, genau die Informationen angezeigt zu bekommen, die für ihn wichtig sind. Der zweite Teil, der mit Kapitel 4 beginnt, gibt dann einen umfangreichen Überblick über verschiedene Möglichkeiten der Überwachung von Servern mithilfe von Zenoss. Diese Überwachung wird hauptsächlich durch Grafiken realisiert. Dabei wird in der vorliegeneden Arbeit zum Beispiel im Abschnitt 6.3 geschildert, wie man anhand dieser Grafiken mögliche Engpässe der zur Verfügung stehenden Hardware erkennen kann. Auch ist eine Optimieriung hinsichtlich des Zeitmanagements durch geeignetes Rechtemanagement im Kapitel 7 geschildert. Als Abschluss dieser Arbeit erfolgt dann eine Bewertung sowie ein Vergleich mit anderen Systemen. Allgemein gültige Empfehlungen für eine Lösung lassen sich dabei nicht treffen. Als Kernaussage gilt, dass die Wahl eines Paketes von der jeweiligen Rechnerumgebung und dem Einsatzzweck abhängt und individuell erfolgen muss. Die angegebene Übersicht der Lösungen und die Bewertung geben eine Orientierung und sind bei der Wahl eines Systems behilflich. 2

6 Kapitel 1 Theoretische Grundlagen Dieses Kapitel befasst sich mit den Grundlagen aller Themengebiete, welche direkt zur Funktion eines Netzwerk Überwachungs Servers gehören und zu dessen Betrieb nötig sind. Es stellt die Grundlagen für die nachfolgenden, praktisch bezogenen Kapitel dar. Dabei werden in Abschnitt 1.1 zuerst allgemeine Grundlagen von Netzwerken gegeben. In Abschnitt 1.2 werden anschließend zwei weitere Netzwerk-Management-Tools vorgestellt. 1.1 allgemeine Grundlagen Das OSI -Referenzmodell Das Open System Interconnection (OSI) -Modell ist ein Referenzmodell, welches als Designgrundlage von Kommunikationsprotokollen entwickelt wurde. Dieses Referenzmodell trägt auch die Bezeichnung 7-Schichten-Modell, da es in sieben verschiedene Schichten unterteilt ist. Die Schichten werden auch als Ebenen oder Layer bezeichnet. Jeder Schicht ist eine klar umrissene Aufgabe zur Durchführung der Kommunikation zugewiesen. Hierdurch wird das komplexe Problem der Datenkommunikation innerhalb eines Kommunikationssystems in kleinere Teilprobleme zerlegt. Die Schichten eins bis vier werden auch als transportorientierte Schichten und die Schichten fünf bis sieben auch als anwendungsorientierte Schichten bezeichnet. Da die Schichten bildhaft als übereinander gestapelt erscheinen, wird ihre Gesamtheit auch häufig als Protokoll-Stapel oder Protokoll-Stack bezeichnet (siehe Tabelle 1.1) [Odo05]. Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen Transmission Control Protocol (TCP) und Internet Protokol (IP) der Netzarchitektur beruht auf den Vorschlägen, die bei der Fortentwicklung des Advance Research Projects Agency Networks (ARPANET) gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI-Standardisierung eingeflossen. Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus nur vier Schichten: Application Layer, Transport Layer, Internet Layer und Network Layer. Der 3

7 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen OSI Application Presentation Session Transport Network Data Link Physical TCP/IP Application Transport Internet Network Tabelle 1.1: Vergleich zwischen OSI und TCP/IP Application Layer des TCP/IP-Modells kann mit den drei Anwendungsschichten des OSI- Referenzmodells verglichen werden. Der Transport Layer ist bei beiden Modellen gleich definiert, und der Internet Layer des TCP/IP-Modells entspricht dem Network Layer des OSI- Modells. Die Schichten eins und zwei des OSI-Referenzmodells werden beim TCP/IP-Modell zum Network Layer zusammengefasst IP-Adressklassen (IPv4) Jede IP-Adresse besteht aus einer Netzwerkkennung und einer Hostkennung. Die Netzwerkkennung (auch Netzwerkadresse genannt) identifiziert die Systeme, die sich im selben Netzwerk befinden. Alle Computer eines logischen Segmentes (Layer 3) müssen über dieselbe Netzwerkkennung verfügen, wobei diese innerhalb eines Verbundnetzes eindeutig sein muss. Die Hostkennung (auch Hostadresse genannt) identifiziert die einzelnen TCP/IP-Hosts innerhalb eines Netzwerks [Odo05]. IP-Adressen sind logische 32-Bit-Zahlenwerte, die in vier 8-Bit-Felder unterteilt werden, die sogenannten Oktette. Nach Request for Comments (RFC) 3330 wurden folgende IP Adress Klassen festgelegt, welche mit den Buchstaben A, B, C, D und E bezeichnet werden. Die Adressklassen definieren, welche Bits für die Hostkennung verwendet werden [win02]. Die drei Klassen A, B und C werden auch als Hauptklassen bezeichnet. Bei Adressen der Klasse D handelt es sich um Multicast-Adressen. Die Adressen der Klasse E sind spezielle, reservierte Adressen. Anhand der ersten vier Bits wird jeweils die Einordnung in die Adressklassen vorgenommen. In Tabelle 1.2 wird ein Überblick über die Adressklassen A, B und C gegeben. Die Tabelle 1.3 zeigt die maximal möglichen Anzahlen von Netzen, IP-Adressen sowie die Adressbereiche der Netze A, B und C Die schnelle Verknappung der Adressen (vor allem der Klasse B) hat deutlich gemacht, dass drei primäre Adressklassen nicht genug sind. Die Klasse A war viel zu groß und die Klasse C viel 4

8 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen Class Bit A Bit-Netz 24-Bit-Host B Bit-Netz 16-Bit-Host C Bit-Netz 8-Bit-Host Klasse Tabelle 1.2: Adressklassen Anzahl Netze Adressen Netze A /8 bis B /16 bis C /24 bis Tabelle 1.3: Adressbereiche der Klassen A, B und C zu klein. Um eine Lösung für die daraus resultierende Klasse-B-Adresskrise zu finden, musste das Modell etwas flexibler gestaltet werden. Da die IP-Adresse aus 32 aufeinanderfolgenden Bits besteht, wurde dies durch eine Bitmaske zur flexibleren Interpretation des Netzwerk- und Hostteils erreicht. Die Verwendung einer Maske anstelle von Adressklassen zur Bestimmung des Zielnetzwerkes nennt man Classless Inter-Domain Routing (CIDR)[FL06]. Der Vorteil dabei ist, dass mehrere (Sub-)Netze zusammengefasst werden können, um somit weniger verschiedene Routen auf den Routern zu haben. Dies spart Last und bringt somit eine bessere Performance der Netzkoppelgeräte mit sich. Die Verwendung von Bitmasken zur Generierung von Netzwerken, deren Größe die Standardmaske überschreitet, bezeichnet man als Supernetting [Hun98]. Das Internet Protokoll Version 6 (IPv6) ist der Nachfolger des gegenwärtig im Internet noch überwiegend verwendeten Internet Protokolls der Version 4. IPv4 bietet einen Adressraum von etwas über vier Milliarden IP-Adressen. In den Anfangstagen des Internet, als es nur wenige Rechner gab, die eine IP-Adresse brauchten, galt dies als weit mehr als ausreichend. Aufgrund des unvorhergesehenen Wachstums des Internet herrscht seit Ende der des 20. Jahrhunderts Adressknappheit. Die historische Entwicklung des Internet wirft weitere Probleme auf: Durch die mit der Zeit mehrmals geänderte Vergabepraxis der IP-Adressen des IPv4-Adressraums ist dieser inzwischen auch stark fragmentiert, das heißt häufig gehören mehrere nicht zusammenhängende Adressbereiche zur gleichen organisatorischen Instanz. Dies führt in Verbindung mit der heutigen Routingstrategie (CIDR) zu langen Routingtabellen. Zudem erfordert IPv4 von Routern, Kopfdaten jedes weitergeleiteten Pakets umzuschreiben und entsprechend Prüfsummen neu zu berechnen, was eine weitere Prozessorlast darstellt. Um diese Probleme zu beheben begann die Internet Engeneering Task Force (IETF) 1995 die Arbeiten an IPv6. Im Dezember 1998 wurde IPv6 mit der Publikation von RFC 2460 offiziell zum Nachfolger von IPv4 gekürt. Eine Schätzung, welche die American Registry for 5

9 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen Internet Numbers (ARIN) zur Bewertung ihrer Vergabepolitik heranzieht, geht davon aus, das die Internet Assigned Numbers Authority (IANA) im Januar 2011 die letzte IPv4-Netze an die Regional Internet Registries vergeben wird Netzwerkmanagement Unter Netzwerkmanagement versteht man die Verwaltung, Betriebstechnik und Überwachung von IT-Netzwerken und Telekommunikationsnetzen. Der englische Fachbegriff für diese Tätigkeiten lautet Operation, Administration and Maintenance (OAM). Die International Organisation of Standardization (ISO) hat das Fault, Configuration, Accounting, Performance, Security Management (FCAPS) Modell entwickelt welches die funktionalen Aufgaben von Netzwerkmanagement beschreibt. Die Tabelle 1.4 gibt einen Überblick über die fünf Schichten des FCAPS Modells. Definition Übersetzung Beschreibung Fault Management Fehlermanagement Erkennen, protokollieren, melden und beheben von auftretenden Fehlerzuständen Configuration Management Konfigurationsmanagement Erfassung aller Komponenten (Configuration Items), die überwacht werden müssen Accounting Management Abrechnungsmanagement Erfassen der Benutzung des Netzes, so dass Rechnungen gestellt werden können Performance Management Leistungsmanagement Verkehrswerte/Leistungsdaten sammeln und Statistiken führen, Grenzwerte festlegen Security Management Sicherheitsmanagement Authentifizierung von Benutzern, Autorisierung von Zugriff und Nutzung Tabelle 1.4: Überblick über die Schichten des FCAPS Ein großer Teil dieser Aufgaben wird von rechnerbasierten Netzmanagementsystemen unterstützt. Reale Netzmanagementsysteme unterstützen in der Regel jedoch nur einen Teil dieser Aufgaben. IP-Netze werden häufig mittels Simple Netzwork Management Protocol (SNMP) und/oder Windows Management Instrumentations (WMI) verwaltet und überwacht. In größeren Netzen werden auch andere Protokolle wie z. B. SAA oder Netflow verwendet. In den nationalen und internationalen Telekommunikationsnetzen werden proprietäre Protokolle mit höherer Leistungsfähigkeit verwendet, in Deutschland z. B. QD2, in den USA TL1. Wegen der im Vergleich mit privaten Heimnetzen wesentlich höheren Anzahl von Netzelementen können 6

10 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen keine Protokolle verwendet werden, die wie SNMP auf Polling basieren. In Europa werden auch OSI-Protokolle verwendet. Unter Netzwerk-Monitoring versteht man die Überwachung und regelmäßige Kontrolle von Netzwerken, deren Hardware (z. B. Server, Router, Switches) und Diensten (z. B. Webserver, DNS-Dienste, -Dienste). Man unterscheidet hierbei zwischen externem und internem Monitoring. Beim externen Monitoring wird ein zusätzliches Monitoring-Gerät an das Netz angeschlossen, beim internen Monitoring nicht. Eine weitere Charakterisierung wird mit den Begriffen aktiv und passiv getroffen. Beim aktiven Monitoring werden zusätzliche Pakete in das Netz gesendet, beim passiven wird lediglich mitgehört RRDTool RRDtool ist ein open source Programm, mit dem zeitbezogene Messdaten gespeichert, zusammengefasst und visualisiert werden können. Dieses Programm ist unter der GNU lizensiert. Die Abkürzung Round-Robin-Database (RRD) bezieht sich auf die Art und Weise, in der Daten von RRDtool gespeichert werden. Beim Anlegen einer Datenbank, einer so genannten RRD-Datei, wird ein Speicherbereich mit einer festen Größe reserviert. Die Größe des Speicherbereichs wird dabei so gewählt, dass die in der fest definierten Zeitspanne anfallenden Daten in dieser Datei gespeichert werden können. Nach dieser Zeitspanne ist der reservierte Speicherbereich aufgebraucht, jedoch wird die Datenbank nicht erweitert (die Datei wird nicht vergrößert), sondern die ältesten Daten werden überschrieben. Dieses Reihum-Verfahren wird in der Informatik häufig mit Round-Robin bezeichnet. Die Benutzer-Schnittstelle von RRDtool besteht aus Kommandozeilen-Programmen. Damit RRDtool von anderen Programmen zum Speichern von Daten und Erstellen von Graphen verwendet werden kann, stehen Programmierschnittstellen (APIs) für mehrere Programmiersprachen bereit, unter anderem C und Perl. Üblicherweise wird RRDtool nicht direkt über die Kommandozeile verwendet, sondern dient anderen Programmen als Datenspeicher bzw. -quelle. Beispiele von Free Open Source Software (FOSS)-Programmen, die RRDtool verwenden, sind Cacti und Multi Router Traffic Grapher (MRTG)[cac09] Simple Network Management Protokoll Das SNMP ist ein Netzwerkprotokoll, das von der IETF definiert wurde. Es wurde entwickelt, um Netzwerkelemente 1 von einer zentralen Managementstation aus überwachen und steuern zu können. Dabei wird die Kommunikation zwischen den überwachten Geräten und der Überwachungsstation geregelt. SNMP beschreibt hierbei den Aufbau der Datenpakete, die zwischen 1 zum Beispiel Router, Server, Switches, Drucker, Computer 7

11 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen den überwachten Stationen und der Managementkonsole übertragen werden und den Kommunikationsablauf. Durch seine Einfachheit hat sich SNMP zum Standard entwickelt, der von den meisten Managementtools unterstützt wird. Zu den Aufgaben des Netzwerkmanagements, die mit SNMP möglich sind, zählen: Überwachen von Netzwerkkomponenten Fernsteuerung und Fernkonfiguration von Netzwerkkomponenten Fehlererkennung und Fehlerbenachrichtigung Funktion Auf den überwachten Netzwerkelementen muss ein so genannter Agent laufen. Dabei handelt es sich um ein Programm, das die jeweilige Station überwacht und dessen Eigenschaften im Netz verfügbar macht. Managerprogramme können über diese Agenten auf die Stationen zugreifen um Daten abzufragen, Einstellungen vorzunehmen und Aktionen auszulösen. Für die Kommunikation zwischen den Agenten und den Managern gibt es sechs verschiedene SNMP-Pakete. Diese sechs Pakete sowie die Funktion der einzelnen Pakete wird in Tabelle 1.5 aufgezeigt. Name GET GETNEXT GETBULK SET RESPONSE TRAP Aufgabe zum Anfordern eines Management Datensatzes um den nachfolgenden Datensatz abzurufen (um Tabellen zu durchlaufen) um mehrere Datensätze auf einmal abzurufen, wie zum Beispiel mehrere Reihen einer Tabelle (verfügbar ab SNMPv2) um einen Datensatz eines Netzelementes zu verändern Antwort auf eines der vorherigen Pakete unaufgeforderte Nachricht von einem Agenten an den Manager, dass ein Ereignis eingetreten ist Tabelle 1.5: SNMP-Pakate und deren Aufgaben Abbildung 1.1 gibt einen Überblick über die Kommunikation zwischen einem SNMP-Manager und einem Agent. Bei dem Agent kann es sich sowohl um einen einzelnen Agent handeln, als auch um einen Masteragent. Ein Masteragent fungiert als Schnittstelle zwischen mehreren Agents und einem SNMP-Manager. Der Manager sendet an die einzelnen Agents GET - oder SET - Requests um Datensätze anzufordern oder zu verändern. Daraufhin sendet der Agent RESPONSE - Pakete als Antwort auf einen solchen Request. Beim Eintreten eines Ereignisses wird von dem jeweiligen Agent ein TRAP - Paket an den Manager gesandt. Damit dieses Paket Empfangen und Ausgewertet werden kann, beinhaltet der SNMP-Manager einen sogenannten Trap-Empfänger. 8

12 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen Abbildung 1.1: Simple Network Management Protokoll Die drei Get-Pakete (Get, GetNext, GetBulk) können vom Manager zu einem Agenten gesendet werden um Daten über die jeweilige Station anzufordern. Dieser antwortet mit einem Response-Paket, das entweder die angeforderten Daten enthält oder eine Fehlermeldung. Mit dem Set-Paket kann ein Manager Werte beim Agenten verändern. Damit ist es möglich Einstellungen vorzunehmen oder Aktionen auszulösen. Der Agent bestätigt die Übernahme der Werte ebenfalls mit einem Response-Paket. Wenn der Agent bei der Überwachung des Systems einen Fehler erkennt, kann er diesen mit Hilfe eines Trap-Paketes unaufgefordert an die Management-Station melden. Diese Pakete werden nicht vom Manager bestätigt. Der Agent kann damit nicht feststellen, ob der Trap beim Manager angekommen ist. Damit die Netzwerkbelastung gering bleibt wird zum Versenden der Nachrichten das verbindungslose User Datagramm Protocol (UDP)-Protokoll verwendet. Der Agent empfängt dabei die Requests auf dem Port 161, während für den Manager der Port 162 zum Empfangen der Trap-Meldungen vorgeschrieben ist[cfsd90] Management Information Base Welche Informationen ein Agent sammeln und ein Verwaltungssystem von einem Agenten anfordern kann, ist in der Management Information Base (MIB) festgelegt. Eine MIB ist ein Satz verwaltbarer Objekte, die verschiedene Arten von Informationen über ein Netzwerkgerät darstellen können (zum Beispiel die Anzahl der aktiven Sitzungen oder die Version der Netzwerkbetriebssystem-Software, die auf dem Host ausgeführt wird). SNMP-Verwaltungssysteme und SNMP-Agenten interpretieren MIB-Objekte gleich. Informationen über die Objekte einer bestimmten MIB werden vom Agent gespeichert, und das Verwaltungssystem ruft die Informationen aus der MIB über den Agenten ab. Die Informationen der MIB sind in einer Art Baumstruktur organisiert, deren einzelne Zweige 9

13 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen entweder durch Nummern oder alternativ durch alphanumerische Bezeichnungen dargestellt werden können. Die MIB-2 ist zum Beispiel unter iso.org.dod.internet.mgmt.mib-2 zu finden, das ebenso durch die Zahlenreihe eindeutig bestimmt ist (1 steht für iso, 3 für org ). Diese aus Punkten und Zahlen bestehende Zeichenkette nennt man Object Identifier (OID). In den MIBs wird dann weiter verzweigt bis zu den einzelnen Daten, die jeweils auch eine eigene OID besitzen und somit eindeutig identifiziert werden können. Neben den in den RFCs definierten MIBs kann jeder Hersteller von Soft- oder Hardware eigene MIBs, so genannte private MIBs, definieren, die die speziellen Eigenschaften seines Produktes wiedergeben. Unter der OID iso(1).org(3).dod(6).internet(1).private(4).enterprises(1) werden diese bei der IANA registriert. Mittlerweile sind unter dieser OID mehrere tausend Firmen registriert. Ist einer OID einmal ein Objekt zugeordnet, so darf sich die Bedeutung dieser OID - sofern vom Gerät (dem SNMP-Agenten) unterstützt - nicht wieder ändern. Es darf auch keine Überschneidungen geben. Mit Hilfe der MIB-Dateien sind die Managementprogramme in der Lage den hierarchischen Aufbau der Daten beim Agenten darzustellen und sie abzufragen, ohne dass der Benutzer die OID selber kennen muss. SNMP Paketaufbau Die meisten SNMP-Pakete sind identisch aufgebaut. Lediglich bei Trap-Meldungen werden im Protocol Data Unit (PDU)-Header teilweise andere Informationen versendet. SNMP-Paket Header Im Header wird die Angabe über die Gesamtgröße des Pakets, die Versionsnummer (SNMPv1, SNMPv2 oder SNMPv3) und der Community Name übermittelt. Durch Zuweisen von Communities sollten Zugriffsrechte vergeben werden. In den meisten Fällen wurde aber als Community Name public gewählt für Lesezugriff und private für Lese und Schreibzugriff. Sicherheit kann aber auch durch andere Namen nicht erreicht werden, da der Community Name im Klartext übertragen wird und von jedem im Netz mitgehört werden kann. PDU-Header (Nicht-Trap-Pakete) Der erste Teil des PDU-Headers beinhaltet die Angabe über die Art des SNMP-Paketes und die Angabe über die Größe der PDU. Der Aufbau des zweiten Teils hängt von der Art des SNMP-Paketes ab. Damit Antwortpakete den vorherigen Anfragen zugeordnet werden können, gibt es die Request ID. Diese Request 10

14 Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen ID ist im Anfrage- und Antwortpaket identisch. Damit ist es möglich mehrere Anfragen zu verschicken und die Antworten wieder richtig zu sortieren. Der Fehlerstatus und - index wird dazu verwendet, um in den Antwortpaketen mitzuteilen, warum eine Anfrage nicht bearbeitet werden konnte. Solange kein Fehler auftritt, sind die beiden Felder mit dem Wert Null belegt. Im Fehlerfall gibt der Fehlerindex an, beim wievielten Datensatz der Fehler auftrat. Mit dem Fehlerstatus wird der Grund des Fehlers angegeben. Der Fehlerstatus kann bei SNMPv1 einen von 6 möglichen Werten haben: Kein Fehler Paket ist zu groß um versendet zu werden Die OID wird nicht unterstützt Falscher Datentyp oder Werte Nur Lesezugriff Unbekannter Generierungsfehler PDU-Header (Trap-Pakete) Die ersten beiden Felder des PDU-Header sind bei Traps identisch zu anderen SNMP-Paketen. Das Feld Pakettyp gibt an, dass es sich um einen Trap handelt. Ebenfalls wird hier die Größe der PDU angegeben. Im zweiten Teil werden andere Werte übertragen, die nur bei Traps benötigt werden. Zum Erkennen von wem die Nachricht kommt wird eine OID des Gerätes mitgeschickt, dass den Trap generiert hat und die IP-Adresse des Absenders. Die OID gibt an um was für ein Gerät es sich handelt. Das ist wichtig zu wissen, wenn es sich um einen firmenspezifischen Trap handelt, die nur für diesen Gerätetyp gilt. Danach folgt die allgemeine TrapID. Es gibt sieben mögliche allgemeine TrapIDs: Kaltstart Warmstart Link Down Link Up Authentifizierungsfehler EGP-Nachbar verloren Firmenspezifisch 11

15 Kapitel 1 Theoretische Grundlagen 1.2 Netzwerkmanagement Systeme Wird in diesem Feld angegeben, dass es sich um einen firmenspezifischen Trap handelt, wird dessen ID im nachfolgenden Feld übertragen. Da es möglich ist, dass Trap-Pakete nicht in der Reihenfolge eintreffen wie sie versendet wurden, gibt es zusätzlich noch eine Zeitangabe, die auf hundertstel Sekunden genau angibt, wie lang der SNMP-Agent gelaufen ist, bis das Trap-Ereignis auftrat. Dadurch ist es möglich, die Trap-Ereignisse in die zeitlich richtige Reihenfolge zu bringen. PDU-Body Im PDU-Body werden die eigentlichen Werte übertragen. Jeder Wert wird in einer Variable binding übertragen: Zu einer Variable binding gehören deren OID, der Datentyp und der Wert an sich. Es gibt keine Vorgabe wie viele Variablen binding im PDU-Body mitgeschickt werden dürfen. Es ist also möglich mehrere Werte mit einem Get-Befehl abzufragen. Wenn aber das Antwortpaket dabei zu groß wird, kann es passieren, dass die entsprechende Fehlermeldung im Antwortpaket zurückgeschickt wird. Bei Traps ist es auch möglich, dass keine Variablen binding mitgeschickt werden. In dem Fall wird die TrapID als ausreichende Information angesehen. Im SNMP-Paket ist keine Angabe vorgesehen, welche die Anzahl an mitgeschickten Variablen binding angibt. Das lässt sich nur über die Größenangabe des PDU-Bodys und der Größenangabe der einzelnen Variablen binding heraus finden. 1.2 Netzwerkmanagement Systeme Cacti Cacti ist eine Open Source Software, mit welcher sich Messwerte periodisch sammeln und grafisch darstellen lassen. Diese Daten können via SNMP oder über eigene Skripte von Cacti ausgelesen werden. Die Daten werden in einer RRD gespeichert. Dadurch ist Cacti in der Lage, praktisch alle maschinenlesbaren Datenquellen zu lesen. Es kann zur Überwachung aktiver Netzwerkkomponenten oder anderer IT-Systeme innerhalb eines autonomes System benutzt werden. Es kann unter anderem für die Beaufsichtigung der Auslastung verschiedener Komponenten genutzt werden. Zudem ist eine Darstellung von Umweltbedingungen, wie zum Beispiel Temperatur, Luftfeuchtigkeit und vielen anderen, möglich. Für die Installation von Cacti wird folgende Software benötigt: PHP Webserver MySQL 12

16 Kapitel 1 Theoretische Grundlagen 1.2 Netzwerkmanagement Systeme RRDTool SNMP Nagios Auch Nagios (dieses Wort setzt sich zusammen aus Network und Hagios ) dient zur Überwachung von komplexen IT-Infrastrukturen. Nagios bietet dazu eine Sammlung von Modulen zur Überwachung von Netzwerken, Hosts und speziell Diensten sowie einer Web- Schnittstelle zum Abfragen der gesammelten Daten. Es steht unter der GPL, ist also auch eine Freie Software, und läuft unter zahlreichen Unix-ähnlichen Betriebssystemen. Am 9. November 2007 wurde die Nagios Enterprises LLC von Ethan Galstad gegründet, welche Consulting und technische Unterstützung rund um das Thema Nagios als kommerzielle Dienstleistung anbietet. Die Software selber bleibt aber weiterhin unter einer freien Lizenz. 13

17 Kapitel 2 Netzwerkmanagement mit Zenoss Ungeachtet der Größe eines Unternehmens spielt die IT im 20.Jahrhundert eine große und weiter anwachsende Rolle des täglichen Geschäftes. Nicht nur aus diesem Grunde ist es immer wichtiger die verschiedenen Server, Klienten und Netzwerkkoppelgeräte zu verwalten. Zenoss ist eines von vielen Netzwerk- und System-Managementtools, welche derzeit auf dem Markt vertreten sind. Nagios oder auch Cacti sind 2 weitere Open Source Lösungen, welche zum Zwecke der Netzwerküberwachung entwickelt wurden. Die Abschnitte 2.1 bis geben einen Überblick über die Strunktur und die Funktionalität von Zenoss. 2.1 Was ist Zenoss Zenoss ist ein Enterprise open source Netzwerk Management System (NMS), welches in Python/Z Object Publishing Environment (ZOPE) entwickelt wurde. Zenoss stellt ein ganzheitliches Produkt zur Überwachung von Verfügbarkeit, Performance, Events und Konfigurationen quer durch das Netzwerk bereit. Zudem bietet es eine auf Asynchronous JavaScript and XML (AJAX)-basierende Weboberfläche, welche es dem Administrator ermöglicht die Überwachung der Geräte zu überprüfen und zu konfigurieren. Egal ob fünf oder 5000 Geräte überwacht werden, Zenoss bietet eine Skalierbare Lösung zum jeweiligen Zweck. 2.2 Architektur Zenoss hat alles, was benötigt wird, um eine IT-Infrastruktur auf Fehler zu untersuchen, zu warten oder um Konfigurationen vorzunehmen. Zu diesem Zweck kann Zenoss in drei Schichten unterteilt werden: User Data 14

18 Kapitel 2 Netzwerkmanagement mit Zenoss 2.2 Architektur Collection In Abbildung 2.1 wird ein Überblick über die Architektur von Zenoss gegeben. Diese Abbildung zeigt, dass der User Layer auf den Data und Collection Layer zugreift. Der Data Layer interagiert mit dem Collection Layer und dieser ist der einzige welcher auf das Netzwerk zugreift. Collection Layer User Layer Netzwerk Data Layer Abbildung 2.1: Überblick über die Systemarchitektur von Zenoss Die Anwenderschicht (auch User-Layer genannt) erlaubt es von einem Webbrowser aus auf den Zenoss-Server zuzugreifen und mit diesem zu arbeiten. Offiziell wird hierbei nur die aktuelle Version von Mozilla Firefox 1 oder des Microsoft Internet Explorers unterstützt. Die Anwenderschicht erlaubt es, die angeschlossenen Ressourcen des Zenoss-Servers zu konfigurieren oder die aufgezeichneten Daten abzurufen. Die Schnittstelle stellt dabei das Webinterface des Servers dar. Zenoss arbeitet auf der Basis von verschiedenen Open Source Werkzeugen. Die wichtigsten davon sind ZOPE, Python, MySQL und RRDTool. In den Abschnitten 2.2.1, und werden die einzelnen Schichten genauer erläutert User Layer Zenoss ist flexibel genug, um komplett über die Kommandozeile bedient zu werden. Allerdings kann ein Großteil der Arbeit auch über das auf AJAX basierende Webinterface erledigt werden. Aus diesem Grund wurde die Arbeit auf der Kommandozeile in diesem Projekt lediglich auf die Fehlersuche und Installation begrenzt. Mit Hilfe des Webinterfaces können sowohl der Data Layer als auch der Collection Layer bedient werden. Folgende Aufgabenbereiche werden dabei abgedeckt: 1 Bei der Erstellung dieser Ausarbeitung wurde die Version verwendet 15

19 Kapitel 2 Netzwerkmanagement mit Zenoss 2.2 Architektur Navigation und Organisation Devicemanagement Verfügbarkeits- und Performanceüberwachung Systemberichte Eventmanagement Einstellungen und Administration Data Layer Das Herzstück des Data Layers sind Datenbanken. Der Data Layer von Zenoss besteht grundsätzlich aus drei verschiedenen Datenbanken, in welche die Daten gespeichert werden. Im Collection Layer (siehe Abschnitt 2.2.3) werden die Daten selektiert und anschließend durch den ZenHub in der entsprechenden Datenbank abgespeichert (vergleiche Abbildung 2.2). Configuration CMDB Performance ZenRRD Collection ZenHub Events ZenEvents Abbildung 2.2: Überblick über den Data Layer von Zenoss Ereignisse werden in einer MySQL-Datenbank abgespeichert.es wird immer dann vom Zenoss- Daemon ein Ereignis generiert, wenn ein bestimmter Grenzwert über- oder unterschritten wird. Beispiele für solche Grenzwerte sind unter anderem eine hohe Hauptspeicherauslastung eines Servers oder Stromausfall eines Servers. Solche Ereignisse können eine Aktion wie zum Beispiel das Senden einer oder einer SMS an den Administrator erzwingen. Zeitbezogene Messreihen oder Logfiles werden in einer RRD gespeichert. Der Vorteil einer solchen Datenbank besteht darin, dass die Speichergröße dieser Datenbank nur bis zu einem 16

20 Kapitel 2 Netzwerkmanagement mit Zenoss 2.2 Architektur festgelegten Wert ansteigt. Falls dieser Wert erreicht wird, werden die ältesten Daten überschrieben. In Zenoss gibt es zudem die Möglichkeit solche Daten graphisch darzustellen, beispielsweise in einem Diagramm. Die dritte Datenbank von Zenoss ist eine Configuration Management Database (CMDB). CMDB ist ein Information Technology Infrastructure Library (ITIL) Standard zum verwalten von Konfigurationen, Abhängigkeiten und zur Speicherung von Änderungender überwachten Netzwerkgeräte. Anhand dieser Daten kann mittels Zenoss ein detailliertes Modell des Netzwerkes erstellt werden. Die CMDB ist unter Zenoss in einer ZOPE eingebettet Collection Layer Der Collection Layer besteht aus mehreren Daemons, die Informationen über Geräte, Verfügbarkeiten, Dienste und Ereignisse (siehe Abbildung 2.3) sammeln und speichern. Diese Informationen werden an ZenHub geschickt und mit Hilfe dieses Dienstes in der entsprechenden Datenbank gespeichert. Geräte Management Verfügbarkeit und Funktion Collection ZenHub Ereignisse Abbildung 2.3: Überblick über den Collection Layer Über die Weboberfläche kann eine Auswahl getroffen werden, welche Daemons mitgespeichert werden sollen. Alle Daemons, welche standardmäßig von Zenoss bereitgestellt werden, beginnen mit dem Präfix zen. Der Status gibt an, ob ein bestimmter Daemon aktiv (grün) oder inaktiv (rot) ist. Anhand von view config oder edit config kann die jeweilige Konfiguration des Dienstes angezeigt oder verändert werden. Zudem kann über die Weboberfläche ein Dienst angehalten oder (neu) gestartet werden. In den Logfiles werden jeweils die Meldungen mit Verweisen auf die Ereignisse der einzelnen Dienste gespeichert. 17

21 Kapitel 2 Netzwerkmanagement mit Zenoss 2.2 Architektur Abbildung 2.4 zeigt die Ansicht einer Übersicht mit den standardmäßig installierten Daemons von Zenoss. In der ersten Spalte steht Name des Daemons. Die zweite Spalte beinhaltet die Angabe über die Prozess ID (PID) des jeweiligen Daemons. In der dritten und vierten Spalte steht eine Verlinkung zu den Logfiles und den Konfigurationsdateien der Daemons. Diese Dateien können dabei betrachtet und die Konfigurationsdatei zusätzlich bearbeitet werden. In der fünften Spalte wird der aktuelle Status dargestellt. Die sechste Spalte bietet die Möglichkeit die einzelnen Daemons über einen Button neuzustarten beziehungsweise zu stoppen. Abbildung 2.4: Standardmäßig installierte Daemons von Zenoss 18

22 Kapitel 3 Installation und Konfiguration In diesem Kapitel wird die Installation und Konfiguration eines Zenoss-Servers beschrieben. Die folgenden Rechner dienten bei der Erstellung dieser Arbeit als Hosts. Der Zenoss-Server wurde auf einem handelsüblichen Notebook installiert. Mit diesem wurden anschließend die anderen Hosts überwacht. Auf den zu überwachenden Hosts wurden verschiedene Softwarepakete und Programme installiert, welche für die fehlerfreie Funktion von SNMP benötigt werden. Zenoss Server Host 1 Host 2 Hardware IBM Think Pad T41 Think Pad X60s Bluechip S14Y CPU Intel Centrino Intel Core Duo Intel Centrino 1,7 1,6 GHz RAM 1GB 2GB 2GB BS Ubuntu 9.10 Server Ubuntu 9.10 Windows XP SP3 Software Zenoss Core SNMP WMI Tabelle 3.1: Verwendete Hosts Die Tabelle 3.1 gibt einen Überblick über die Hardwarezusammenstellung der verwendeten Geräte. Bei allen drei Geräten handelt es sich um handelsübliche Notebooks, welche nicht ausschließlich für dieses Projekt genutzt wurden, sondern täglich zusätzlich für verschiedene Aufgaben genutzt wurden. Aus diesem Grund war auf beiden Host-Notebooks zusätzliche Software installiert, welche allerdings keinen Einfluss auf die Durchführung dieses Projektes hat. 3.1 Installation Wie in Tabelle 3.1 aufgezeigt, diente ein handelsübliches Notebook als Hardwaregrundlage für den Zenoss-Server. Als Betriebssystem dient in diesem Projekt Ubuntu 9.10 Server. Bei der Installation wurde der Linux, Apache, MySQL and PHP (LAMP) Server mit ausgewählt. Da 19

23 Kapitel 3 Installation und Konfiguration 3.1 Installation auf die Installation des X-Servers verzichtet wurde, wurde auf dem Zenoss-Server zusätzlich der Secure Shell (SSH)-Daemon installiert. In Tabelle 3.2 wird ein Überblick über die Softwarepakete (Programme oder Bibliotheken) gegeben, welche für die fehlerfreie Installation von Zenoss zusätzlich benötigt werden. Zudem wird zu jedem Paket eine Beschreibung gegeben, für was die Pakete benötigt werden. Paketname build-essential libmysqlclient15-dev python-dev Beschreibung Paket zum Erzeugen von Debian-Paketen Entwicklungsbibliotheken und Header Files für MySQL Header-Dateien, statische Bibliotheken und eine Entwicklungsumgebung für Python Tabelle 3.2: Zusätzlich benötigte Pakete Diese Softwarepakete wurden mit Hilfe des Paketmanagers apt-get auf dem Server installiert. Das build-essential Paket wird zum erzeugen von Debian-Paketen benötigt. Das Paket libmysqlclient15-dev stellt Entwicklungsbibliotheken und Headerfiles für MySQL zur Verfügung. Im Paket python-dev werden zusätzliche Headerfiles, statische Bibliotheken und eine Entwicklungsumgebung für Python bereitgestellt. Für die Installation von Zenoss stehen drei Varianten zur Verfügung. Die erste ist eine Installation als virtuelle Applikation. Da in diesem Projekt ein dedizierter Server für Zenoss zur Verfügung steht, wurde diese Methode nicht ausgewählt. Bei den anderen beiden Methoden handelt es sich um die Installation der aus den Binaries oder von den Sources. Auf der Homepage von Zenoss 1 steht bereits ein Debian-Paket (*.deb) zur Installation auf einem Ubuntu Server zur Verfügung. Des weiteren kann Zenoss unter Ubuntu bereits über die Repositories installiert werden. Der Vorteil hierbei ist, dass apt 2 alle Abhängigkeiten automatisch erkennt und alle benötigten Pakete automatisch nachinstalliert. Aus diesem Grund wurde die Installation aus den Repositories gewählt. Zudem kann diese Installation komplett ohne graphische Oberfläche ausgeführt werden. Dies ist nötig, da auf dem Server kein X Window System installiert wurde. Um Zenoss aus den Repositories installieren zu können, muss zunächst die Liste der Quelldateien angepasst werden. Dabei muss lediglich die Homepage von Zenoss bekannt gemacht werden. Dies wird durch folgenden Eintrag in die /etc/apt/sources.list realisiert: 1 # Zenoss repository 2 deb main stable Anschließend müssen die Quellen aktualisiert werden. Die Aktualisierung der Quellen wird mit folgendem Befehl ausgeführt: Das Advanced Packaging Tool (APT) ist ein Paketverwaltungssystem, das im Bereich des Betriebssystems Debian GNU/Linux entstanden ist. 20

24 Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server 1 apt-get update Durch diesen Befehl wird zunächst die Datei /etc/apt/sources.list eingelesen und danach werden die Informationen über alle verfügbaren Softwarepakete und Aktualisierungen geladen und gespeichert.nachdem die Quellen aktualisiert wurden, kann mit folgendem geprüft werden, ob das Zenoss-Paket verfügbar ist: 1 apt-cache search zenoss-stack Die Rückgabe der folgenden Meldung besagt dabei, dass das gesuchte Paket zenoss-stack mit allen Abhängigkeiten in den aktuell verfügbaren Quellen vorhanden ist und installiert werden kann. 1 zenoss-stack - Zenoss Stack with all requirements. Da das gewünschte Paket in den Quellen verfügbar ist, kann dieses mit dem folgenden Befehl über apt installiert werden. 1 sudo apt-get install zenoss-stack Nach erfolgreicher Installation kann Zenoss mit dem Befehl 1 /etc/init.d/zenoss-stack start gestartet werden. Der entsprechende Eintrag in der /etc/init.d, damit der Server bei jedem Neustart automatisch startet, ist bereits während der Installation aus den Repositories gesetzt wurden. 3.2 Konfiguration der Server In diesem Abschnitt wird beschrieben, wie zu überwachende Server konfiguriert werden können. Zenoss bietet eine Vielzahl von Möglichkeiten, um verschiedene Server mit unterschiedlichen Betriebssystemen zu überwachen. All diese Möglichkeiten zu betrachten sprengt den Rahmen dieses Projektes. Aus diesem Grund wird hier lediglich auf die Grundkonfiguration eingegangen. Als Protokoll für die Überwachung wurde hierbei SNMP und WMI gewählt. Die Betriebssysteme der zu überwachenden Server sind Ubuntu 9.10 und Windows XP SP3 (siehe Tabelle 3.1 ). Beide Hosts werden dabei mit SNMP überwacht. Zusätzlich wird der Windows-Host mit WMI überwacht. 21

25 Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server SNMP Installation und Konfiguration unter Linux Um ein Linux-System mit SNMP überwachen zu können, muss der SNMP-Daemon snmpd installiert werden. Dieser Daemon liegt bei den meisten Distributionen bereits in den Repositories, sodass er bequem installiert werden kann. Auch die Installation unter Ubuntu kann aus den Repositories erfolgen. Dieser Weg ist auch zu empfehlen, da auf diesem Weg alle Abhängigkeiten geprüft werden und eventuell benötigte Softwarepakete automatisch nachinstalliert werden. Mit dem Befehl 1 apt-get install snmpd wird dieser Daemon unter Debian/Ubuntu mit Hilfe des Paketmanagers apt-get installiert. Die Konfiguration dieses Daemons findet im Anschluss an die Installation durch bearbeiten der Konfigurationsdatei /etc/snmp/snmpd.conf statt. Im Zuge dieses Projektes wurde unter Ubuntu 9.10 die Version des snmpd gewählt. Zuerst muss die Konfigurationsdatei /etc/snmp/snmpd.conf angepasst werden. In der vorliegenden Projektarbeit wird lediglich die Grundkonfiguration von SNMP erläutert. Anhand dieser Grundkonfiguration ist es möglich, vom Zenoss-Server auf den zu überwachenden Ubuntu-Host mit SNMP-V1 zugreifen zu können und verschiedene Werte abzufragen. Das Listing 3.1 zeigt eine minimale /etc/snmp/snmpd.conf um dieses Ziel verfolgen zu können. 1 com2sec readonly mycomm 2 #com2sec readwrite mycomm 3 4 group MyROGroup v1 readonly 5 #group MyRWGroup v1 readwrite 6 7 view all included #view system included.iso.org.dod.internet.mgmt.mib-2.system 9 10 # context sec.model sec.level match read write notif 11 access MyROGroup "" any noauth exact all none none 12 #access MyRWGroup "" any noauth exact all all none syslocation worldwide 15 syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf) Listing 3.1: "Minimalkonfiguration der snmpd.conf Datei" In der ersten Zeile wird dabei festgelegt, dass vom der IP und der Community mycomm lediglich gelesen werden kann. Um Schreibzugriff zu bekommen, muss der Wert readonly in readwrite geändert werden(siehe Zeile 2). Die vierte Zeile legt fest, zu welcher Gruppe readonly gehört. In dieser Gruppe werden dann die Lese- und Schreibberechtigungen festgelegt (siehe Zeile 10). Eine Beispielkonfiguration der Gruppe mit Schreibberechtigungen wird in Zeile 11 aufgezeigt. In den Zeilen 14 und 15 werden variablen gesetzt, welche 22

26 Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server Über SNMP abgefragt werden können. Diese beiden Zeilen sind für eine Grundkonfiguration jedoch nicht notwendig. Im nächsten Schritt müssen die Startparameter für SNMP gesetzt werden. Hierfür wird die Datei /etc/default/snmpd, wie in Listing 3.2 aufgezeigt, bearbeitet. 1 # This file controls the activity of snmpd and snmptrapd 2 3 # MIB directories. /usr/share/snmp/mibs is the default, but 4 # including it here avoids some strange problems. 5 export MIBDIRS=/usr/share/snmp/mibs 6 7 # snmpd control (yes means start daemon). 8 SNMPDRUN=yes 9 10 # snmpd options (use syslog, close stdin/out/err). 11 #SNMPDOPTS= -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid SNMPDOPTS= -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 13 -c /etc/snmp/snmpd.conf # snmptrapd control (yes means start daemon). As of net-snmp version 17 # 5.0, master agentx support must be enabled in snmpd before snmptrapd 18 # can be run. See snmpd.conf(5) for how to do this. 19 TRAPDRUN=no # snmptrapd options (use syslog). 22 TRAPDOPTS= -Lsd -p /var/run/snmptrapd.pid # create symlink on Debian legacy location to official RFC path 25 SNMPDCOMPAT=yes Listing 3.2: "Minimalkonfiguration der snmpd Datei" Zeile 12 des Listings 3.2 zeigt die standardmäßige Konfiguration. Bei dieser wird lediglich auf dem Loop-Interface eine SNMP-Abfrage beantwortet. Damit auch von anderen Interfaces SNMP-Anfragen beantwortet werden können, wird aus dieser Zeile die Loop-Adresse entfernt und dafür die entsprechende Konfigurationsdatei /etc/snmp/snmpd.conf mit dem Schalter -c aufgerufen. Nachdem diese Änderungen vorgenommen wurden, muss der SNMP Daemon (neu-) gestartet werden. Ein Neustart wird mit dem Befehl 1 /etc/init.d/snmpd restart ausgeführt. Für den Fall, dass der Daemon noch nicht läuft, muss er mit dem Befehl 1 /etc/init.d/snmpd start 23

27 Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server gestartet werden WMI Installation und Konfiguration unter Windows XP Unter Windows gibt es ein weiteres Protokoll, um Hosts überwachen zu können. Das WMI ist bei den meisten Windows Versionen bereits in den Komponenten vorhanden. Lediglich die Auswahl des Protokolls sowie die anschließende Installation und Konfiguration muss durchgeführt werden. Um WMI unter Windows XP zu installieren, muss in der Systemsteuerung der Menüpunkt Software ausgewählt werden. Dabei öffnet sich ein Fenster (siehe Abbildung 3.1), in welchem alle zusätzlich installierten Programme angezeigt werden. Abbildung 3.1: Systemsteuerung: Software In der Menüleiste auf der Linken Seite des Fensters steht der Punkt Windows-Komponenten hinzufügen/entfernen. nachdem dieser ausgewählt wurde, öffnet sich ein weiteres Fenster. In diesem Fenster ( Assistent für Windows-Komponenten, siehe Abbildung 3.2) muss der Punkt Verwaltungs- und Überwachungsprogramme markiert werden. 24

28 Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server Abbildung 3.2: Assistent für Windowskomponenten Anschließend wird der Button Details ausgewählt. Dabei öffnet sich ein weiteres Fenster mit dem Namen Verwaltungs- und Überwachungsprogramme (siehe Abbildung 3.3). 25

29 Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server Abbildung 3.3: Detailansicht der Verwaltungs- und Überwachungsprogramme In diesem können die Protokolle SNMP beziehungsweise WMI ausgewählt werden. Im Zuge dieses Projektes wurden beide Pakete ausgewählt, auch wenn explizit nur auf die Konfiguration von WMI eingegangen wird. 26

30 Kapitel 4 Management In diesem Kapitel wird ein Überblick darüber gegeben, wie verschiedene Server mittels Zenoss überwacht werden können. Da es den Rahmen des Projektes sprengt, wenn alle Funktionen beschrieben würden, liegt das Hauptaugenmerk hierbei auf einer Default-Konfiguration. Wie bereits in Kapitel 3 erwähnt, wird ein Ubuntu- und ein Windows-Server überwacht. 4.1 Überwachung von Servern Nach erfolgreicher Installation von Zenoss kann das Webfrontend über einen Browser aufgerufen werden. Wie bereits in Kapitel 2.2 beschrieben, werden offiziell von Zenoss nicht alle Browser unterstützt. Eine vollständige Liste der unterstützten Browser ist auf der Homepage von Zenoss einzusehen. Um das Webfrontend aufzurufen muss die IP-Adresse beziehungsweise der DNS-Name des Zenoss-Servers in die Adressleiste des Browsers eingefügt werden. Standardmäßig lauscht der Zenoss-Server auf Port Da der Standard HTTP-Port auf Port 80 liegt, muss dieser mit übergeben werden. Bei der Erstanmeldung wird der Benutzer aufgefordert ein Konto anzulegen. Die Konfigurationsroutine dabei ist sehr einfach und nüchtern gehalten. Nachdem diese zwei Schritte durchgeführt wurden, können vom Benutzer die verschiedenen Server hinzugefügt werden. Im Zuge dieses Projektes wurden diese Schritte jedoch übersprungen. Wie die verschiedenen Server später hinzugefügt werden können ist in den Abschnitten (Serverüberwachung mit SNMP) und (Serverüberwachung mit WMI) beschrieben. 27

31 Kapitel 4 Management 4.1 Überwachung von Servern Serverüberwachung mit SNMP Um einen neuen Server in Zenoss hinzuzufügen, muss im Zenoss-Webinterface in der Menüleiste der Punkt Add Device ausgewählt werden (diese Menüleiste ist nicht in Abbildung 4.1 abgebildet). Danach öffnet sich eine Seite, auf der Eigenschaften des zu überwachenden Servers, sowie Abhängigkeiten und Attribute eingegeben werden können. Abbildung 4.1: Hinzufügen von Servern In Abbildung 4.1 ist diese Seite dargestellt. Im Feld Device Name wird die IP-Adresse oder der DNS-Name des zu überwachenden Servers eingegeben. Im Feld Device Class Path kann die Klasse des Gerätes 1 eingetragen werden. Das Feld Collector definiert die Netzwerkkarte, über welche der Server erreichbar ist. Unter dem Punkt Attributes können verschiedene SNMP-Einstellungen vorgenommen werden. Falls die Geräte nicht auf den Default-SNMP-Port 161 eingestellt sind, kann auch dies hier geändert werden. Unter dem Punkt Production State kann eingestellt werden, in welchem Status sich der Server befindet. Dies ist insbesondere dann sinnvoll, wenn neue Server, welche noch nicht im Produktivbetrieb sind, hinzugefügt werden. Diese können auf den Status Test gesetzt werden. Im Abschnitt Relations können Hardware-Eigenschaften der Geräte beziehungsweise Betriebssystem-Eigenschaften hinzugefügt werden. Nachdem alle Einstellungen vorgenommen wurden, wird mit Betätigung des Add Device -Buttons das neue Gerät hinzugefügt. Zudem öffnet sich die Statusseite, auf welcher der Status des neuen Gerätes angezeigt wird. 1 Im vorliegenden Szenario handelt es sich jeweils um Server, alternativ können auch andere Geräte wie Router, unterbrechungsfreie Stromversorgung (USV)s oder Switches mit Zenoss überwacht werden. 28

32 Kapitel 4 Management 4.1 Überwachung von Servern Serverüberwachung mit WMI Die Konfiguration und Installation von WMI wurde bereits in Abschnitt beschrieben. In diesem Abschnitt wird die Konfiguration der zproperties des Zenoss-Servers aufgezeigt, welche nötig ist, um einen Windowsserver via WMI überwachen zu können. Zuerst muss ein neuer Host (Device) hinzugefügt werden. Dieser Schritt ist bei allen Geräten gleich, egal ob das Gerät mit SNMP oder mit WMI überwacht wird. Wie bereits in Abschnitt beschrieben, muss dafür im Frontend des Zenoss-Servers auf der linken Seite der Punkt Add Device ausgewählt werden. Daraufhin öffnet sich ein Eingabefenster, in diesem müssen mindestens der Device Name 2, und die SNMP-Community eingegeben werden. Die Bestätigung und Speicherung des neuen Gerätes erfolgt durch die Betätigung des Add Device - Buttons. Nachdem Das Gerät vom Server gefunden wurde, erfolgt die WMI-Konfiguration. Dazu wird das Gerät markiert und im Menü unter more der Punkt zproperties ausgewählt. Am Ende der Seite (siehe Abbildung 4.2) müssen folgende Angaben vorgenommen werden: zwineventlog auf true setzen Das Windows-Benutzerpasswort in das Feld zwinpassword eintragen Benutzername (Dieser benötigt Administrative Rechte auf dem Windowsserver) in das Feld zwinuser eintragen.\user bei lokalen Useraccounts DOMAIN\user für Domain Useraccounts zwmimonitorignore auf false setzen Abbildung 4.2: Konfiguration von WMI Nachdem alle Änderungen vorgenommen wurden, müssen diese bestätigt und gespeichert werden. Um diese wirksam zu machen, muss die Konfigurationsdatei vom Zenoss-Server neu eingelesen werden. Dafür wird unter dem Menüpunkt Manage der Punkt Model Device ausgewählt. 2 Als Device Name kann entweder der DNS-Name oder die IP-Adresse des zu überwachenden Servers eingegeben werden. 29

33 Kapitel 5 Das Userinterface Dieser Abschnitt gibt einen Überblick über ein paar ausgewählte Funktionen, welche mit Zenoss ausgeführt werden können. Bei diesen Funktionen handelt es sich um Standardtools, welche von Zenoss mitgeliefert werden. Diese Auswahl dient dabei nur als Überblick. Jede einzelne dieser ausgewählten Funktion genau zu erläutern sprengt den Rahmen dieses Projektes. Als Gliederung dieses Kapitels wurde zur besseren Übersicht teilweise die Gliederung des Menüs von Zenoss gewählt. 5.1 Main Views Unter dem Abschnitt Main Views im Webfrontend von Zenoss gibt es die folgenden vier Einträge: Dashboard Event Console Device List Network Map Das Dashboard ist dabei standardmäßig der Startbildschirm von Zenoss. Auf diesen kann eine Karte (ein Google Maps Plugin) eingerichtet werden, worauf der Standort der zu überwachenden Geräte eingetragen werden kann. Dies ist vor allem bei Dienstleistern sinnvoll, die ein Gebiet betreuen, welches sich beispielsweise über einen Stadtteil oder eine ganze Stadt streckt. Falls ein Gerät oder Dienst ausfällt oder nicht mehr verfügbar ist wird von Zenoss ein Ereignis (Event) generiert. Diese Events können auch für die Über oder Unterschreitung definierter Grenzwerte generiert werden. Ein Weg, ein solches Ereignis anzuzeigen ist die Darstellung in der Event Console. Abbildung 5.1 zeigt einen Ausschnitt, in dem vier Meldungen über aufgetretene Ereignisse aufgezeigt werden. Da die Skripte zum Abfragen der Stati der Geräte in einem bestimmten Zeitintervall ausgeführt werden, wird diese Tabelle in unangemessen kurzer 30

34 Kapitel 5 Das Userinterface 5.1 Main Views Abbildung 5.1: Event Konsole Zeit voll werden, falls beispielsweise ein Gerät komplett ausfällt. Aus diesem Grund gibt es für jedes Ereignis nur einen Eintrag. In der achten Spalte wird die Anzahl der Vorfälle dieses Ereignisses angezeigt. Die siebente Spalte zeigt die Zeit, in welcher das Ereignis als letztes aufgetreten ist. Zudem ist es möglich, das Zenoss benutzerdefinierte Befehle oder Skripte ausführt. Die Benachrichtigung über ein Ereignis kann auch via Mail, über einen Pager oder über SMS geschehen. Abbildung 5.2 zeigt eine Ausgabe unter dem Abschnitt Device List. In dieser Ausgabe werden alle zu überwachenden Geräte, sowie ein paar grundlegende Daten zu diesen, wie zum Beispiel die IP-Adresse und die Geräteklasse zu der das jeweilige Gerät hinzugefügt wurde, angezeigt. In dieser Ansicht können einzelne Geräte oder mehrere Geräte gleichzeitig ausgewählt werden, um bestimmte Aktionen durchzuführen. In der letzten Spalte dieser Tabelle wird eine Zusammenfassung über die Ereignismeldungen aufgezeigt. Diese Zusammenfassung erinnert stark an das Ampelprinzip von Nagios, ist aber bei genauer Betrachtung bedeutend umfangreicher. In dieser Zusammenfassung wird farblich und durch Ziffern darauf aufmerksam gemacht, ob es Fehlermeldungen am System gibt oder nicht. Abbildung 5.2: Device List Den letzten Punkt unter der Main View stellt die Network Map dar. In dieser Ansicht können einzelne Netze grafisch dargestellt werden. Abbildung 5.3 zeigt diese grafische Darstellung für das Subnetz dieses Projektes. In dieser Ausgabe kann zusätzlich zum Subnetz ein Filter für bestimmte Geräte gesetzt werden. Diese Ansicht ist besonders hilfreich, um zum Beispiel zu sehen welche Server von einem Ausfall eines Netzkoppelelements betroffen sind. 31

35 Kapitel 5 Das Userinterface 5.2 Event Classes Abbildung 5.3: Netzwerkkarte 5.2 Event Classes In Zenoss werden Events in Klassen (sogenannte Event Classes) unterteilt. Beim Eintreten eines Ereignisses wird der sogenannte event class key abgefragt. Anhand von diesem Schlüssel wird die Einteilung des Ereignisses in die verschiedenen Klassen vorgenommen. Event Classes können durch den Administrator angelegt oder gelöscht werden. Zudem können die verschiedenen event class keys durch den Administrator verändert werden. Dadurch ist es möglich, dass bei einem Ereignis mehrere Events gesetzt ausgelöst werden. Die Struktur dieser Klassen ist hierarchisch aufgebaut. Abbildung 5.4: Die Event Klassen In Abbildung 5.4 ist ein Beispiel für diese Klassen aufgezeigt. In der ersten Spalte steht jeweils der Name der Klasse und die Spalte SubClasses zeigt auf, wie viele Klassen sich unter der Klasse befinden. In der letzten Spalte steht die Anzahl der Ereignisse der jeweiligen Klasse inklusive all ihrer Unterklassen. 32