Proaktive auf Basis von Open Source Technologien innerhalb ... · r R e p l i k a t i o n s - p e i...

HP IT-Symposium 2006

www.decus.de 1

Seite 1

ATIX GmbHATIX GmbH

Referent: Dipl.Referent: Dipl.--Ing. Thomas MerzIng. Thomas Merz

EE--Mail: [email protected]: [email protected]

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

Seite 2

InhaltIT Infrastrukturen und die „five 9s“Architektur einer ÜberwachungsplattformKomponenten dieser ÜberwachungsplattformProaktive und reaktive ÜberwachungMonitoring-Konsolidierung oder „Single Point of Monitoring“Über ATIX


www.decus.de 2

Seite 3

Die „five nines“ - 99,999%

keine spezielle Verfügbarkeit

99,999%99,9%

Core

Infra

struk

turRe

plika

tions

-Spe

icher

Kriti

sche

Ap

plik

atio

nen

SAP,

...

Appl

ikat

ione

nEm

ail,

...Clients

Seite 4

Die „five nines“ - 99,999%Triebfeder sind die Kosten die eine Auszeit verursacht

daraus ergibt sich eine Verfügbarkeitsanforderung99,999% entspricht ca. 5 min/JahrHäufig werden diese Anforderungen in so genannten Service Level Agreements - SLAs - festgelegt

Vereinbarung zwischen Service Nutzer und Service Providertypische Parameter

VerfügbarkeitServicequalität - QoS


www.decus.de 3

Seite 5

Die „five nines“ - 99,999%Mean-Time

Between Failure

Mean-TimeTo Repair

Mean-Time

To Detect

Availability Class (# of 9s)90.% more than a month 199.% just under 4 days 2

99.9% just under 9 hours 399.99% about an hour 4

99.999% a little over 5 minutes 599.9999% about half a minute 6

99.99999% about 3 seconds

Total Accumulated Outages per Year

Verfügbarkeit = ___ MTBF_______

MTBF+MTTD+MTTR

Verfügbarkeit = ___ MTBF ___

MTBF+MTTR

Seite 6

Die „five nines“ - 99,999%Faktoren zum Erreichen der „five nines“

1. Maximale MTBF - Kein Fehler passiertHot-Failover Redundanzen Hot-Failover Clustering (stretched Cluster)AusweichrechenzentrenDatenreplikation (synchron)

2. Minimale MTTR - Fehler reparierenCommodity HardwareAustauschlagerService-Verträge mit Herstellern


www.decus.de 4

Seite 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ügbarkeitJedoch die Verfügbarkeit wird durch die Ausfallkosten definiert...aber mit den Faktoren erreicht

Seite 8

InhaltIT Infrastrukturen und die „five 9s“Architektur einer ÜberwachungsplattformKomponenten einer ÜberwachungsplattformProaktive und reaktive ÜberwachungMonitoring-Konsolidierung oder „Single Point of Monitoring“Über ATIX


www.decus.de 5

Seite 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 thereal-time, operational performance, and quality of service requirements at areasonable Availabilitycost.T. Saydam, T. Magedanz. From Networks and Network Management into Service and Service Management. Journal of Networks and System Management, Vol. 4, S.345-348, December 1996

A really good Network Management is more important than science.

Seite 10



www.decus.de 6

Seite 11


Managed Devices

Managed ObjectsManaging Entity

Network Management

ProtocolGet/Set

Push

Seite 12


Managed Devices

SNMP AgentsManagement Appliance

SNMP: Simple NetworkMangement Protocol

Trap

Get/Set

SNMP


www.decus.de 7

Seite 13

InhaltIT Infrastrukturen und die „five 9s“Architektur einer ÜberwachungsplattformKomponenten dieser ÜberwachungsplattformProaktive und reaktive ÜberwachungÜberwachungssensorenMonitoring-Konsolidierung oder „Single Point of Monitoring“Über ATIX

Seite 14

Die Management AgentsMöglichst wenig Network Management Protokolle (Kis -Keep it simple)Am weitesten verbreitet ist SNMPJe nach Managed Object werden Traps und/oder Get/Set Operationen unterstütztReferenziert werden die MO-Eigenschaften über OIDsUm OIDs in lesbare Form zu übersetzen, werden zusätzlich MIBs - so genannte Management Information Bases - benötigt


www.decus.de 8

Seite 15

Die Management AgentsNet-SNMP ist „Standard“ für die Open-Source Welt

www.net-snmp.orgAls Agent werden SNMP-Gets/Sets und Traps unterstütztVia SNMP Multiplexing (SMUX) und dem AgentX Protokoll können dynamisch Agenten mit eigenen MIBs eingebunden werdenStandardmässig werden die RMON-MIB sowie einige net-snmp/Unix eigene Eigenschaften überwacht

z.B. Load, Disk-Auslastung, Prozesse, eingeloggte User usw.

Ist Teil jeder Enterprise Linux Distribution

Seite 16

Die Management AgentsNet-SNMP ist „Standard“ für die Open-Source Welt

Unterstützt auch von den meisten Hardware-Herstellern mit eigenen AgentenVerfügbar auch für die meisten UNIX-DerivateSelbst eigene, nicht unterstützte Skripte lassen sich einfach integrierenFolge: Optimal geeignet um Linux/UNIX Server via SNMP zu überwachen


www.decus.de 9

Seite 17

SNMP AllgemeinDie meisten modernen Betriebssysteme bieten zusätzlich eigene SNMP-Schnittstellen anWindows benötigt nur die Installation/Freischaltung des mitgelieferten AgentenFrage ist meist welche Standard-MIBs werden unterstützt

Meist RMONDas gleiche gilt für MOs, die als Appliance gesehen werden

Dort unterscheidet sich die Unterstützung sehr häufigTraps vs. Get/SetNoMIB vs. MIB

Seite 18

Die Management Appliance

Betriebssystem

SNMP Trap DienstSNMP Dienst

Datensammel-Dienst

Basis:Zeitpunkt

Basis:Zeitraum

Datenbank

User Interface

HTML Mail

ICQSMS

SNMP Proxy SNMP Traps

Get

Push

Managed Devices

SNMP Agents

GetPush


www.decus.de 10

Seite 19


Linux/UNIX

SNMPTrapd (net-snmp)SNMPd (net-snmp)

Datensammel-Dienst

nagios cacti

MySQL/Postgres/RRD/Text

User Interface

Apache Postfix

nagios PluginMail2SMS

SNMP Proxy SNMPTrapd

Get

Push

Managed Devices

SNMP Agents

GetPush

Seite 20

Die Management ApplianceNet-SNMP ist „Standard“ für die Open-Source Welt

Umfangreiche Tools für alle Aktionen im Bezug auf SNMPEmpfang von Traps: snmptrapd (ab Version 5.11)

Zusatz: Übersetzung von Trap-OID zu FehlermeldungUnd Auslösen weiterer Aktionen:

Integration von Traps in z.B. nagiosAbfrage aller SNMP-Werte (snmpget, snmpgetnext, snmpwalk, snmptable)Integration externer MIBs


www.decus.de 11

Seite 21

Die Management ApplianceNagios als Datensammeldienst mit umfangreichen User Interface Funktionen

www.nagios.org Version 1.2 bzw. 2.0Sensoren sind entweder „Hosts“ oder „Services“Jeder Sensor kann verschiedene Stati haben:

Host: Up, Down, UnreachableService: OK, Warning, Critical

Bei Statusänderung können unterschiedlichste Reaktionen definiert werden

Seite 22


Reaktionen auch abhängig vom Zeitpunktz.B. bestimmte Reaktionen sollen zu Arbeitszeiten anders aussehen als Nachts um 1:00UhrJedem Sensor können unterschiedliche Reaktionen und Kontaktgruppen zugeordnet werdenEs lassen sich Abhängigkeiten zwischen Host/Service bzw. Host/Host und Service/Service definieren

Dadurch werden nur relevante Meldungen weitergeleitet


www.decus.de 12

Seite 23


Die Abfrage der Sensoren erfolgt über SkripteUmfangreiche einfach anpassbare Skripte verfügbarMuss nicht über SNMP erfolgen

Sensoren können passiv/aktiv abgefragt werdenSeit Version 2.0b1 passive Checks für HostsBei Aktiv-Checks initiiert Nagios die Abfrage des SensorsBei Passiv-Checks initiiert der Sensor die Meldung an Nagios (SNMP-Traps)

Seite 24


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 E-Mail-Weiterleitungen definiert werdenKontakte bzw. Gruppen von Kontakten werden dabei angesprochen


www.decus.de 13

Seite 25


Seite 26



www.decus.de 14

Seite 27


Seite 28

Die Management ApplianceCacti als Datensammeldienst für Trendanalyse

www.cacti.netHost und Sensor wird unterschiedenJeder Host kann beliebig viele Sensoren aufnehmenDie Werte werden in eine Round Robin Database gespeichert (konstantes Datenaufkommen)

RRDTool von Tobi OetikerViel flexiblere Weiterentwicklung von MRTG

Konfiguration wird in einer Datenbank gespeichertMySQL, Postgres


www.decus.de 15

Seite 29


Über die Definition von Graphen werden die RRDs graphisch über die Zeit dargestellt

Auch diese Funktionalität stellen die RRD-Tools bereitGraphen können benutzerdefiniert erstellt werdenGraphen und RRDs verbinden „Data Sources“Sowohl für „Data Sources“ als auch für Graphen existieren umfangreiche Vorlagen

Seite 30


Zusätzlich können unterschiedliche Benutzer definiert werden

Berechtigungen für bestimmte Aktionen und ZugriffeDie Graphen werden dann in benutzerdefinierte Bäume oder Suchlisten organisiertEin Graph ist dann über unterschiedlichste Zeiträume darstellbar

Definiert im RRD


www.decus.de 16

Seite 31


Seite 32



www.decus.de 17

Seite 33


Seite 34



www.decus.de 18

Seite 35

Proaktive und reaktive Überwachung

Am besten Fehler erkennen bevor er passiert!!!!Man spricht hierbei von proaktiver ÜberwachungSonst reaktive ÜberwachungWichtig: Überlegung, wo ist das möglich und wo nichtHierbei sind sowohl Trendanalyse als auch kurzfristige Sensorabfrage von Wichtigkeit

Rückblick: Ziel Maximales MTBF und minimales MTTR

Seite 36


Beispiel für einen proaktiven SensorAuslastung des DateisystemsWenn das Dateisystem voll ist (z.B. das „/“ Dateisystem)

Kann der ganze Server abstürzenAnsatz: kurzfristige Analyse

Hierbei kann nur reagiert werden wenn die Auslastung des Dateisystems einen gewissen Level übersteigtDas Monitoring-System löst dann eine entsprechende Mitteilung aus und der Administrator muss entsprechende Reparaturaktionen vornehmen


www.decus.de 19

Seite 37


Beispiel für einen proaktiven SensorAnsatz: Trendanalyse

Hier ist die Entwicklung der Auslastung von BedeutungWenn z.B. die Steigung der Auslastung größer als 0 ist, wird mein Dateisystem irgendwann voll seinIst die Steigung sehr viel größer als 0 passiert das wohl sehr schnellKonsequenz: Ich habe einen Dienst, der mein Dateisystem „zumüllt“Für das Dateisystem unter „/“ sollte dies nicht passieren

Seite 38


Beispiel für einen proaktiven SensorAnsatz: Trendanalyse

Existiert eine Trendanalyse auf dem „/“-Dateisystem können derartige Verhalten frühzeitig erkannt werdenDer nächste jedoch viel schwierigere Schritt ist das Auffinden des ÜbeltätersDiese 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


www.decus.de 20

Seite 39


KonstanteAuslastung

Auslastungsteigt=> Reaktion

Seite 40


Anmerkungen:Genaue Definition der SensorenSensoren OverkillWas soll denn überhaupt überwacht werden?Skalierbarkeit der ÜberwachungMöglichst ein dedizierter ServerTiefes Verständnis der unterliegenden TechnologienNiemals auch die Dokumentation und Prozesse vergessen


www.decus.de 21

Seite 41


Seite 42

Monitoring-Konsolidierung oder „Single Point of Monitoring“

Möglichst ein User-Interface für alle „wichtigen“ AktionenVerschiedene Benutzer mit verschiedenen RechtenSowohl Trendanalyse als auch kurzfristige Sensoren in einer OberflächeMöglichst auch inkl. DokumentationMöglichst auch mit offiziellem MaintenanceOutsourcing?


www.decus.de 22

Seite 43


Seite 44

Die ATIX Philosophie

ATIXadvanced technology for individual success

„Wir helfen Ihnen, Ihre Daten sicher und effizient zu speichern“


www.decus.de 23

Seite 45

ATIX GeschäftsfelderBeratung

Linux im Rechenzentrum (Cluster-Lösungen, HA)SpeichernetzwerkeVerfügbarkeitsanalyse / Katastrophenvorsorge

ServicesCC - Proof of ConceptProjektbegleitung / IntegrationWorkshops / Schulungen

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

Der com.oonics GrayHeadDer com.ooncis GrayHead ist ein Service um Ihre Applikationen in Ihrem Rechenzentrum rund um die Uhr zu überwachenAls reine Blackbox zu erwerbenAls Service Leasing zu erwerbenÜberwacht alle Komponenten in Ihrem RechenzentrumIst an ein ATIX Helpdesk System angebundenJe nach Wunsch mit 24x7 oder 7x5 Überwachung verbunden

Ziel: Maximales MTBF und minimales MTTR


www.decus.de 24

Seite 47

Vielen Dank für Ihre Aufmerksamkeit!

Noch Fragen?

ATIX GmbHEinsteinstr. 1085716 Unterschleiß[email protected]

Proaktive auf Basis von Open Source Technologien innerhalb ... · r R e p l i k a t i o n s - p e i...

Documents

Transcript of Proaktive auf Basis von Open Source Technologien innerhalb ... · r R e p l i k a t i o n s - p e i...