Proaktive Infrastrukturüberwachung auf Basis von Open Source Technologien innerhalb von Appliances. Inhalt

Transkript

1 Proaktive Infrastrukturüberwachung auf Basis von Open Source Technologien innerhalb von Appliances ATIX GmbH Referent: Dipl.-Ing. Thomas Merz Seite 1 Inhalt IT Infrastrukturen und die five 9s Architektur einer Überwachungsplattform Komponenten dieser Überwachungsplattform Proaktive und reaktive Überwachung Monitoring-Konsolidierung oder Single Point of Monitoring Über ATIX Seite 2 ww.decus.de 1

2 Die five nines - 99,999% Clients keine spezielle Verfügbarkeit Applikationen ,... 99,9% Core Infrastruktur Replikations-Speicher 99,999% Kritische Applikationen SAP,... Seite 3 Die five nines - 99,999% Triebfeder sind die Kosten die eine Auszeit verursacht daraus ergibt sich eine Verfügbarkeitsanforderung 99,999% entspricht ca. 5 min/jahr Häufig werden diese Anforderungen in so genannten Service Level Agreements - SLAs - festgelegt Vereinbarung zwischen Service Nutzer und Service Provider typische Parameter Verfügbarkeit Servicequalität - QoS Seite 4 ww.decus.de 2

3 Die five nines - 99,999% Verfügbarkeit = MTBF+MTTR Verfügbarkeit = MTBF+MTTD+MTTR Mean-Time To Detect MTBF MTBF Mean-Time Between Failure Mean-Time To Repair Availability Total Accumulated Outages per Year Class (# of 9s) 90.% more than a month 1 99.% just under 4 days % just under 9 hours % about an hour % a little over 5 minutes % about half a minute % about 3 seconds Seite 5 Die five nines - 99,999% Faktoren zum Erreichen der five nines 1. Maximale MTBF - Kein Fehler passiert Hot-Failover Redundanzen Hot-Failover Clustering (stretched Cluster) Ausweichrechenzentren Datenreplikation (synchron) 2. Minimale MTTR - Fehler reparieren Commodity Hardware Austauschlager Service-Verträge mit Herstellern Seite 6 ww.decus.de 3

4 Die five nines - 99,999% Faktoren zum Erreichen der five nines 3. Minimal MTTD (Mean-Time to detect) - erkennen Überwachung (proaktiv und reaktiv) Definition und Dokumentation von Prozessen und SOPs (Standard Operation Procedures) Folge: Maximale Verfügbarkeit Jedoch die Verfügbarkeit wird durch die Ausfallkosten definiert... aber mit den Faktoren erreicht Seite 7 Inhalt IT Infrastrukturen und die five 9s Architektur einer Überwachungsplattform Komponenten einer Überwachungsplattform Proaktive und reaktive Überwachung Monitoring-Konsolidierung oder Single Point of Monitoring Über ATIX Seite 8 ww.decus.de 4

5 Architektur einer Überwachungsplattform Network Management includes the the deployment, integration and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate, and control the network and element resources to meet the real-time, operational performance, and quality of service requirements at a reasonable Availabilitycost. T. Saydam, T. Magedanz. From Networks and Network Management into Service and Service Management. Journal of Networks and System Management, Vol. 4, S , December 1996 A really good Network Management is more important than science. Seite 9 Architektur einer Überwachungsplattform Seite 10 ww.decus.de 5

6 Architektur einer Überwachungsplattform Push Get/Set Network Management Protocol Managing Entity Managed Objects Managed Devices Seite 11 Architektur einer Überwachungsplattform Trap SNMP Get/Set Management Appliance SNMP Agents Managed Devices SNMP: Simple Network Mangement Protocol Seite 12 ww.decus.de 6

7 Inhalt IT Infrastrukturen und die five 9s Architektur einer Überwachungsplattform Komponenten dieser Überwachungsplattform Proaktive und reaktive Überwachung Überwachungssensoren Monitoring-Konsolidierung oder Single Point of Monitoring Über ATIX Seite 13 Die Management Agents Möglichst wenig Network Management Protokolle (Kis - Keep it simple) Am weitesten verbreitet ist SNMP Je nach Managed Object werden Traps und/oder Get/Set Operationen unterstützt Referenziert werden die MO-Eigenschaften über OIDs Um OIDs in lesbare Form zu übersetzen, werden zusätzlich MIBs - so genannte Management Information Bases - benötigt Seite 14 ww.decus.de 7

8 Die Management Agents Net-SNMP ist Standard für die Open-Source Welt Als Agent werden SNMP-Gets/Sets und Traps unterstützt Via SNMP Multiplexing (SMUX) und dem AgentX Protokoll können dynamisch Agenten mit eigenen MIBs eingebunden werden Standardmässig werden die RMON-MIB sowie einige netsnmp/unix eigene Eigenschaften überwacht z.b. Load, Disk-Auslastung, Prozesse, eingeloggte User usw. Ist Teil jeder Enterprise Linux Distribution Seite 15 Die Management Agents Net-SNMP ist Standard für die Open-Source Welt Unterstützt auch von den meisten Hardware-Herstellern mit eigenen Agenten Verfügbar auch für die meisten UNIX-Derivate Selbst eigene, nicht unterstützte Skripte lassen sich einfach integrieren Folge: Optimal geeignet um Linux/UNIX Server via SNMP zu überwachen Seite 16 ww.decus.de 8

9 SNMP Allgemein Die meisten modernen Betriebssysteme bieten zusätzlich eigene SNMP-Schnittstellen an Windows benötigt nur die Installation/Freischaltung des mitgelieferten Agenten Frage ist meist welche Standard-MIBs werden unterstützt Meist RMON Das gleiche gilt für MOs, die als Appliance gesehen werden Dort unterscheidet sich die Unterstützung sehr häufig Traps vs. Get/Set NoMIB vs. MIB Seite 17 SNMP Agents User Interface SNMP Proxy SNMP Traps Managed Devices HTML Mail Get SMS ICQ Datensammel-Dienst Push Basis: Zeitpunkt Basis: Zeitraum Get Datenbank SNMP Dienst Push SNMP Trap Dienst Betriebssystem Seite 18 ww.decus.de 9

10 SNMP Agents SNMP Proxy User Interface SNMPTrapd Managed Devices Apache Postfix Get Mail2SMS nagios Plugin Datensammel-Dienst Push nagios cacti Get MySQL/Postgres/RRD/Text SNMPd (net-snmp) Push SNMPTrapd (net-snmp) Linux/UNIX Seite 19 Net-SNMP ist Standard für die Open-Source Welt Umfangreiche Tools für alle Aktionen im Bezug auf SNMP Empfang von Traps: snmptrapd (ab Version 5.11) Zusatz: Übersetzung von Trap-OID zu Fehlermeldung Und Auslösen weiterer Aktionen: Integration von Traps in z.b. nagios Abfrage aller SNMP-Werte (snmpget, snmpgetnext, snmpwalk, snmptable) Integration externer MIBs Seite 20 ww.decus.de 10

11 Nagios als Datensammeldienst mit umfangreichen User Interface Funktionen Version 1.2 bzw. 2.0 Sensoren sind entweder Hosts oder Services Jeder Sensor kann verschiedene Stati haben: Host: Up, Down, Unreachable Service: OK, Warning, Critical Bei Statusänderung können unterschiedlichste Reaktionen definiert werden Seite 21 Nagios als Datensammeldienst mit umfangreichen User Interface Funktionen Reaktionen auch abhängig vom Zeitpunkt z.b. bestimmte Reaktionen sollen zu Arbeitszeiten anders aussehen als Nachts um 1:00Uhr Jedem Sensor können unterschiedliche Reaktionen und Kontaktgruppen zugeordnet werden Es lassen sich Abhängigkeiten zwischen Host/Service bzw. Host/Host und Service/Service definieren Dadurch werden nur relevante Meldungen weitergeleitet Seite 22 ww.decus.de 11

12 Nagios als Datensammeldienst mit umfangreichen User Interface Funktionen Die Abfrage der Sensoren erfolgt über Skripte Umfangreiche einfach anpassbare Skripte verfügbar Muss nicht über SNMP erfolgen Sensoren können passiv/aktiv abgefragt werden Seit Version 2.0b1 passive Checks für Hosts Bei Aktiv-Checks initiiert Nagios die Abfrage des Sensors Bei Passiv-Checks initiiert der Sensor die Meldung an Nagios (SNMP-Traps) Seite 23 Nagios als Datensammeldienst mit umfangreichen User Interface Funktionen Haupt-User-Interface ist über Web-Browser und damit in Web-Server integrierbar (Apache und Perl) Es können eine ganze Menge verschiedener Ansichten auf die Sensoren dargestellt werden (siehe folgende Folien) Es können Pager und -Weiterleitungen definiert werden Kontakte bzw. Gruppen von Kontakten werden dabei angesprochen Seite 24 ww.decus.de 12

13 Seite 25 Seite 26 ww.decus.de 13

14 Seite 27 Cacti als Datensammeldienst für Trendanalyse Host und Sensor wird unterschieden Jeder Host kann beliebig viele Sensoren aufnehmen Die Werte werden in eine Round Robin Database gespeichert (konstantes Datenaufkommen) RRDTool von Tobi Oetiker Viel flexiblere Weiterentwicklung von MRTG Konfiguration wird in einer Datenbank gespeichert MySQL, Postgres Seite 28 ww.decus.de 14

15 Cacti als Datensammeldienst für Trendanalyse Über die Definition von Graphen werden die RRDs graphisch über die Zeit dargestellt Auch diese Funktionalität stellen die RRD-Tools bereit Graphen können benutzerdefiniert erstellt werden Graphen und RRDs verbinden Data Sources Sowohl für Data Sources als auch für Graphen existieren umfangreiche Vorlagen Seite 29 Cacti als Datensammeldienst für Trendanalyse Zusätzlich können unterschiedliche Benutzer definiert werden Berechtigungen für bestimmte Aktionen und Zugriffe Die Graphen werden dann in benutzerdefinierte Bäume oder Suchlisten organisiert Ein Graph ist dann über unterschiedlichste Zeiträume darstellbar Definiert im RRD Seite 30 ww.decus.de 15

16 Seite 31 Seite 32 ww.decus.de 16

17 Seite 33 Inhalt IT Infrastrukturen und die five 9s Architektur einer Überwachungsplattform Komponenten dieser Überwachungsplattform Proaktive und reaktive Überwachung Monitoring-Konsolidierung oder Single Point of Monitoring Über ATIX Seite 34 ww.decus.de 17

18 Proaktive und reaktive Überwachung Rückblick: Ziel Maximales MTBF und minimales MTTR Am besten Fehler erkennen bevor er passiert!!!! Man spricht hierbei von proaktiver Überwachung Sonst reaktive Überwachung Wichtig: Überlegung, wo ist das möglich und wo nicht Hierbei sind sowohl Trendanalyse als auch kurzfristige Sensorabfrage von Wichtigkeit Seite 35 Proaktive und reaktive Überwachung Beispiel für einen proaktiven Sensor Auslastung des Dateisystems Wenn das Dateisystem voll ist (z.b. das / Dateisystem) Kann der ganze Server abstürzen Ansatz: kurzfristige Analyse Hierbei kann nur reagiert werden wenn die Auslastung des Dateisystems einen gewissen Level übersteigt Das Monitoring-System löst dann eine entsprechende Mitteilung aus und der Administrator muss entsprechende Reparaturaktionen vornehmen Seite 36 ww.decus.de 18

19 Proaktive und reaktive Überwachung Beispiel für einen proaktiven Sensor Ansatz: Trendanalyse Hier ist die Entwicklung der Auslastung von Bedeutung Wenn z.b. die Steigung der Auslastung größer als 0 ist, wird mein Dateisystem irgendwann voll sein Ist die Steigung sehr viel größer als 0 passiert das wohl sehr schnell Konsequenz: Ich habe einen Dienst, der mein Dateisystem zumüllt Für das Dateisystem unter / sollte dies nicht passieren Seite 37 Proaktive und reaktive Überwachung Beispiel für einen proaktiven Sensor Ansatz: Trendanalyse Existiert eine Trendanalyse auf dem / -Dateisystem können derartige Verhalten frühzeitig erkannt werden Der nächste jedoch viel schwierigere Schritt ist das Auffinden des Übeltäters Diese Probleme kann eine Trendanalyse nicht so einfach leisten, da es unter Linux/Unix keine praktikable Möglichkeit gibt, herauszufinden welcher Dienst wohin wieviel geschrieben hat. D.h. Tools wie Top, vmstat, iostat etc. können hierbei helfen Seite 38 ww.decus.de 19

20 Proaktive und reaktive Überwachung Konstante Auslastung Auslastung steigt => Reaktion Seite 39 Anmerkungen: Proaktive und reaktive Überwachung Genaue Definition der Sensoren Sensoren Overkill Was soll denn überhaupt überwacht werden? Skalierbarkeit der Überwachung Möglichst ein dedizierter Server Tiefes Verständnis der unterliegenden Technologien Niemals auch die Dokumentation und Prozesse vergessen Seite 40 ww.decus.de 20

21 Inhalt IT Infrastrukturen und die five 9s Architektur einer Überwachungsplattform Komponenten dieser Überwachungsplattform Proaktive und reaktive Überwachung Monitoring-Konsolidierung oder Single Point of Monitoring Über ATIX Seite 41 Monitoring-Konsolidierung oder Single Point of Monitoring Möglichst ein User-Interface für alle wichtigen Aktionen Verschiedene Benutzer mit verschiedenen Rechten Sowohl Trendanalyse als auch kurzfristige Sensoren in einer Oberfläche Möglichst auch inkl. Dokumentation Möglichst auch mit offiziellem Maintenance Outsourcing? Seite 42 ww.decus.de 21

22 Inhalt IT Infrastrukturen und die five 9s Architektur einer Überwachungsplattform Komponenten dieser Überwachungsplattform Proaktive und reaktive Überwachung Monitoring-Konsolidierung oder Single Point of Monitoring Über ATIX Seite 43 Die ATIX Philosophie ATIX advanced technology for individual success Wir helfen Ihnen, Ihre Daten sicher und effizient zu speichern Seite 44 ww.decus.de 22

23 ATIX Geschäftsfelder Beratung Linux im Rechenzentrum (Cluster-Lösungen, HA) Speichernetzwerke Verfügbarkeitsanalyse / Katastrophenvorsorge Services CC - Proof of Concept Projektbegleitung / Integration Workshops / Schulungen Produkte com.oonics Enterprise IT-Plattform com.oonics NAS-Serie (NASBox, NASHead, NASCluster, GrayHead) com.oonics Infra-Serie (InfraBox, InfraHead, InfraCluster, GrayHead) com.oonics Cluster-Suite (Multi-Node Active/Active) Seite 45 Der com.oonics GrayHead Der com.ooncis GrayHead ist ein Service um Ihre Applikationen in Ihrem Rechenzentrum rund um die Uhr zu überwachen Als reine Blackbox zu erwerben Als Service Leasing zu erwerben Überwacht alle Komponenten in Ihrem Rechenzentrum Ist an ein ATIX Helpdesk System angebunden Je nach Wunsch mit 24x7 oder 7x5 Überwachung verbunden Ziel: Maximales MTBF und minimales MTTR Seite 46 ww.decus.de 23

24 Noch Fragen? Vielen Dank für Ihre Aufmerksamkeit! ATIX GmbH Einsteinstr Unterschleißheim Seite 47 ww.decus.de 24