kann die Diplomarbeit heruntergeladen werden. - bei BS-NetSolutions

- 34 -
4.1.3 Gegenüberstellung IBM/Tivoli und Nagios
Weder IBM/Tivoli noch Nagios halten sich strikt an einen der beiden Ansätze. Vielmehr
versuchen sie die grundlegenden Techniken mit gezielten Veränderungen sowie
Erweiterungen zu vermischen. Die folgende Tabelle stellt die wesentlichen,
architekturbedingten Vor- bzw. Nachteile der beiden Tools im Bezug auf Incident-
Management dar.
Nagios
Tivoli
+
Konfigurationsänderungen lassen sich Konfigurationsänderungen können über das
+
größtenteils zentral durchführen
Framework zentral durchgeführt werden
+
zentrales, „intelligentes“ Scheduling
minimiert die Last auf den Remote-Hosts
- nur lokales Scheduling möglich
+
Aktualität der Zustände abhängig von der
direkte Statusabfrage sämtlicher Systeme
- Zuverlässigkeit der Monitore und des
von zentraler Instanz möglich
Heartbeats
+
Heartbeat-Funktionalität architekturbedingt zusätzliche Heartbeat-Implementierung
-
implementiert
notwendig
+ geringerer Wartungsaufwand -
erhöhter Wartungsaufwand durch verteilte
Komplexität
+ simple Agenten sind robust - komplexe Agenten sind fehleranfällig
-
Änderungen an der Konfiguration benötigt Die meisten Änderungen können on-thy-fly
+
einen Neustart des Prozesses
ohne Neustart durchgeführt werden
- erhöhte Last auf dem Netzwerk +
Entlastung des Netzwerkes durch autarke
Agenten
-
Zugriff auf lokale Ressourcen und lokale
Automation nur mit zusätzlichem Agent
+ Lokale Automation über Agenten möglich
- Hohe Last auf dem Server - Erhöhte Last auf den Remote-Hosts