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

Transkript

1 Proaktive Infrastrukturüberwachung auf Basis von Open Source Technologien innerhalb von Appliances ATIX GmbH Referent: Marc Grimme 01/09/2005 Seite 1

2 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

3 In fra str uk tu r 99,9% Re pli ka tio ns -S pe ich er Co re App lika Em tione ail, n... 99,999% Kriti sche App SAP likatio nen,... Die five nines - 99,999% Clients keine spezielle Verfügbarkeit Seite 3

4 Die five nines - 99,999% Triebfeder sind die Kosten die eine Auszeit verursacht daraus ergibt sich eine Verfügbarkeitsanforderung 99,999% entspricht ca. 5min/Jahr Häufig werden diese Anforderungen in sogenannten Service Level Agreements - SLAs - festgelegt Vereinbarung zwischen Service Nutzer und Service Provider typische Parameter Verfügbarkeit Servicequalität - QoS Seite 4

5 Die five nines - 99,999% Mean-Time ur e il a F n e e MTBF w t Be Verfügbarkeit= Mean-Time MTBF MTTR To Repair Verfügbarkeit = MTBF MTBF MTTD MTTR ime T n a Me ect t e D To Availability 90.% 99.% 99.9% 99.99% % % % Total Accumulated Outages per Year more than a month just under 4 days just under 9 hours about an hour a little over 5 minutes about half a minute about 3 seconds Class (# of 9s) Seite 5

6 Die five nines - 99,999% Faktoren zum Erreichen der five nines 1. Maximale MTBF - Kein Fehler passiert Hot-Failover Redundanzen Hot-Failover Clustering (streched Cluster) Ausweichrechenzentren Datenreplikation (synchron) 2. Minimale MTTR - Fehler reparieren Commodity Hardware Austausch Lager Service Verträge mit Herstellern Seite 6

7 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

8 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

9 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

10 Architektur einer Überwachungsplattform Überwachungsinfrastruktur Anforderungen (minimales MTTD) Betriebssystemübergreifend Leistungsfähig Skalierbar Modular Zentral Konsolidiert Seite 10

11 Architektur einer Überwachungsplattform Push Network Management Protocol Get/Set Managing Entity Managed Objects Managed Devices Seite 11

12 Architektur einer Überwachungsplattform Trap SNMP Get/Set Management Appliance SNMP Agents Managed Devices SNMP: Simple Network Mangement Protocol Seite 12

13 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

14 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 übersetzten werden zusätzlich MIBs - so genannte Management Information Bases - benötigt Seite 14

15 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, Diskauslastung, Prozesse, eingeloggte User usw. Ist Teil jeder Enterprise Linux Distribution Seite 15

16 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

17 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

18 Die Management Appliance User Interface SNMP Proxy SNMP Traps SNMP Agents Managed Devices t Ge HTML Mail SMS ICQ Basis: Zeitpunkt Ge t sh Pu Datensammel-Dienst SNMP Dienst Push Basis: Zeitraum Datenbank SNMP Trap Dienst Betriebssystem Seite 18

19 Die Management Appliance User Interface SNMP Proxy SNMPTrapd SNMP Agents Managed Devices t Ge Ge t sh Pu SNMPd (net-snmp) Push Apache Postfix Mail2SMS nagios Plugin Datensammel-Dienst nagios cacti MySQL/Postgres/RRD/Text SNMPTrapd (net-snmp) Linux/UNIX Seite 19

20 Die Management Appliance 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

21 Die Management Appliance Nagios als Datensammeldienst mit umfangreichen User Interface Funktionen Version 1.2 bzw. 2.0b2 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

22 Die Management Appliance 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 Kontakt-Gruppen 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

23 Die Management Appliance 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

24 Die Management Appliance Nagios als Datensammeldienst mit umfangreichen User Interface Funktionen Haupt-Userinterface ist über Webbrowser und damit in Webserver 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

25 Die Management Appliance Seite 25

26 Die Management Appliance Seite 26

27 Die Management Appliance Seite 27

28 Die Management Appliance Cacti als Datensammeldienst für Trendanalyse Version 0.8.6f 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 wir in einer Datenbank gespeichert MySQL, Postgres Seite 28

29 Die Management Appliance 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 RRDTools bereit Graphen können entweder benutzerdefiniert erstellt werden Graphen und RRDs verbinden Data Sources Sowohl für Data Sources als auch für Graphen existieren umfangreiche Vorlagen Seite 29

30 Die Management Appliance 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 einfach Suchlisten organisiert Ein Graph ist dann über unterschiedlichste Zeiträume darstellbar Definiert im RRD Seite 30

31 Die Management Appliance Seite 31

32 Die Management Appliance Seite 32

33 Die Management Appliance Seite 33

34 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

35 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

36 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 Monitoringsystem löst dann eine entsprechende Mitteilung aus und der Administrator muss entsprechende Reperaturaktionen vornehmen Seite 36

37 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

38 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

39 Proaktive und reaktive Überwachung Konstante Auslastung Auslastung steigt => Reaktion Seite 39

40 Proaktive und reaktive Überwachung Anmerkungen: 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

41 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

42 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

43 Die com.oonics GrayHead Appliance Seite 43

44 Die com.oonics GrayHead Appliance Seite 44

45 Die com.oonics GrayHead Appliance Seite 45

46 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 46

47 Die ATIX Philosophie ATIX advanced technology for individual success Wir helfen Ihnen, Ihre Daten sicher und effizient zu speichern Seite 47

48 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 NAS-Serie (NASBox, NASHead, NASCluster, GrayHead) com.oonics Cluster-Suite (Multi-Node Active/Active) com.oonics Parallel Enterprise Plattform Seite 48

49 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 49

50 Noch Fragen? Vielen Dank für Ihre Aufmerksamkeit! Atix GmbH Einsteinstr Unterschleißheim Seite 50