Die DB Systel betreibt als IT Dienstleister der Deutschen Bahn unter anderem eine größere Anzahl an Linuxsystemen. Für das Plattformmonitoring kommt eine verteilte Nagiosumgebung zum Einsatz. Derzeit werden rund 40000 Host- und Servicechecks durchgeführt, Tendenz steigend.
Im Vortrag werde ich den Prozess und die verwendeten Techniken schildern mit denen sowohl alle Nagiosserver als auch die zu überwachenden Systeme kontinuierlich, mehrmals täglich, mit den für die Überwachung notwendigen Konfigurationen versorgt werden. Die Daten dazu stammen aus einer externen CMDB und einer Meta-Konfigurationsbeschreibung für die Definition von Services sowie die Zuordnung von Services zu Hosts und Hostgruppen anhand verschiedener Kriterien.
4. 4DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Der Vortragende
Über mich:
Ralf Döring
Mitarbeiter DB Systel „Plattform Unix/Linux“
Plattform Unix betreut Solaris und Linux Server vom Standort
Erfurt aus
Meine Aufgabengebiete im Bereich der „Systemtechnik Unix“
– Linux
– Monitoring
– Virtualisierung
5. 5DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Wir sind:
3.000 Mitarbeiter an den drei Standorten Frankfurt/Main, Berlin und Erfurt
Wir betreiben:
2 Rechenzentren mit über 3.200 Servern
Datennetz mit rund 330.000 IP-Anschlüssen von DSL bis Breitband-Glasfaser
Rund 500 produktive IT-Verfahren
1,5 Petabyte Plattenspeicher / 4,5 Petabyte Backup-Kapazität
bundesweit das digitale Funknetz der Bahn (GSM-R)
Wir betreuen bei der Bahn:
43.000 GSM-R Teilnehmeranschlüsse
80.000 Nutzer des Bürokommunikationssystems der Bahn
92.000 VoIP-Anschlüsse
(Stand: Juni 2012)
DB Systel – Das Unternehmen
Der Auftrag
Daten & Fakten
5
Foto: DB Systel
5
6. 6DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Personenverkehr
2,7 Milliarden Reisende mit Bahn und Bus pro Jahr
26.000 Personenzüge pro Tag
1mal um die Welt fährt jeder ICE in Deutschland umgerechnet pro Monat
Netze
5.700 Bahnhöfe
33.600 km Streckennetz – 3 mal so lang wie die deutschen Autobahnen
72.000 Weichen/Kreuzungen
5. größter Stromversorger in Deutschland
Transport & Logistik
412 Millionen Tonnen beförderte Güter auf der Schiene pro Jahr
1,2 Million Tonnen Luftfrachtvolumen pro Jahr
1,6 Millionen TEU1) Seefrachtvolumen pro Jahr
96 Millionen Sendungen im europäischen Landverkehr pro Jahr
Über 5 Millionen Quadratmeter Lagerfläche weltweit
Die Deutsche Bahn AG – Daten und Fakten
Geschäftsfelder in Zahlen
6
Foto: Roland Horn
1) Twenty-foot Equivalent Unit = Containereinheit
8. 8DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Nagios bei der Plattform UNIX/Linux
Vereinfachtes Architekturmodell der Plattform
RZ Netz
Hardware
Betriebssystem
Anwendungen („Verfahren“)
Storage
9. 9DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Nagios bei der Plattform UNIX/Linux
Fokus des Plattformmonitorings UNIX/Linux
RZ Netz
Hardware
Betriebssystem Storage
Anwendungen („Verfahren“)
Fokus des
Plattformmonitorings
10. 10DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Nagios bei der Plattform UNIX/Linux
Aufgaben
Plattformmonitoring
Überwachung der Parameter, die der Plattform Unix die Erbringung der Leistungen laut vereinbartem SLA ermöglichen
Ausgefallene Hardware
Netzwerkerreichbarkeit des Servers
Betriebssystemspezifische Filesysteme
Essentielle Systemprozesse
Anbindung Storage (Multipathing)
Was ist Plattformmonitoring nicht?
Überwachung der Funktion von auf der Plattform aufbauenden Anwendungen („Wir wissen aufgrund unseres
Monitorings nicht, ob bahn.de derzeit Fahrkarten verkaufen kann oder nicht…“)
Schnittmenge mit Anwendungen
Mit dem Vorgängerprodukt wurden den Verfahren einige Monitoringparameter angeboten:
Anwenderfilesysteme
Vorhandensein von Systemprozessen
Logfilemonitoring
Mit der Ablösung durch Nagios werden diese Dienste weiter angeboten, aber im Rahmen des Plattformmonitorings nicht
ausgebaut.
13. 13DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Herausforderungen (organisatorisch)
Umfangreiche Serverlandschaft und bestehende Toollandschaft
Mehr als 3200 Serversysteme (virtuelle und physische Systeme)
Nagios produktiv für Plattformmonitoring Linux, Solaris derzeit in
einem Migrationsprojekt
Eigenheiten und Unterschiede zwischen SLES und RHEL sollen
im Monitoring berücksichtigt werden
Monitoring für physische und virtuelle Systeme erfordert
unterschiedliche Services
Einbinden in bestehende Toolandschaft
Anbindung an bestehende CMDB der Plattform Unix
Anbindung an bestehende Network Management Infrastruktur
Explizite Freigabe für Monitoring erst nach erfolgter
Qualitätssicherung
14. 14DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Herausforderungen (technisch)
Kein Single-Point-Of-Failure
Ausfall eines Nagios-Servers soll nicht zu einer Vielzahl falscher
Alarme führen
Abdeckung des höchsten Servicelevels für Kunden auch durch die
Nagios-Umgebung: 7x24
Zukunftssicherheit durch einfache Erweiterbarkeit um weitere
Instanzen
Deployment
Keine manuellen Eingriffe in Nagios Konfiguration!
Anbindung an CMDB und QS Prozess
Automatisiertes Enrollment der Nagios Konfiguration für verteilte
Nagios Umgebung
Automatisiertes Deployment klientenseitiger
Konfigurationsbestandteile (z.B. NRPE Konfiguration, spezielle
Plugin Konfigurationen, etc.)
15. 15DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Technische Architektur Nagios - Fakten
Kenndaten
Derzeit ca. 2000 Server mit Nagios überwacht
Die Nagios-Umgebung führt ca. 40000 Servicechecks aus, den
Großteil davon in einem 10 Minuten Intervall
Redundanter Aufbau
Zwei „Master“, die passive Checks entgegennehmen, verteilt
auf zwei Standorte
Pro Standort 4 Nagiosinstanzen, die jeweils ca. ¼ der Hosts
monitoren
Aktualisierung der Serverkonfiguration mit den Daten aus der
CMDB alle zwei Stunden
Aktualisierung der Nagios Konfiguration auf allen überwachten
Hosts ebenfalls alle zwei Stunden
17. 17DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Schritte zur Integration in das Monitoring
Aufbau des
Systems
QS
Freigabe für
Monitoring
Einbindung
in Nagios
18. 18DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Aufbau des Servers und QS
24. 24DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Automatisierte Konfigurationserstellung Nagiosserver
Ziel
Automatische Erstellung einer Nagios-Konfiguration für eine
verteilte Nagiosumgebung
Randbedingungen
Auszug von Stammdaten aus interner CMDB ist vorhanden
Vordefiniertes Set von Services, aber nicht jeder Host soll oder
kann jeden Service erhalten.
Services sollen anhand von Eigenschaften aus den Stammdaten
für jeweils Gruppen von Hosts erzeugt werden
Ausnahmen, sowohl positiv als auch negativ, sollen auf Basis von
Hosts, Gruppen, Services und Serviceparametern eingebracht
werden können
Erweiterbarkeit der Kernfunktionalität ohne Änderung am Kern soll
möglich sein
25. 25DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Automatisierte Konfigurationserstellung Nagiosserver
Umsetzung - Kern
Perl-Skript, welches Datenquellen entsprechend
Vorgaben/Randbedingungen auswertet.
Internes Tool, im Kern ca. 2500 Zeilen Code
Plugin-Architektur, weitere Funktionalitäten können über eine
simple Plugin-Schnittstelle realisiert werden (derzeit weitere ~2000
Zeilen Code in Plugins vorhanden)
Umsetzung – Pflegeprozess Datenquellen
Freischaltung eines Hosts fürs Monitoring durch Eintrag in der
CMDB, dadurch wird er Bestandteil des Exports
Zusätzliche Datenquellen werden im Zuge des Changeprozesses
aktualisiert.
Dadurch werden zusätzliche Services aus einem Set von
Standardservices einem Host zugeordnet
26. 26DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Kerngedanken Konfigurationsfrontend
Funktionalität
Es steht nur ein festes Set von Services zur Verfügung
Zuordnung von Services zu Gruppen von Hosts ist die Regel
Zuordnung von Services zu einzelnen Hosts ist eine Ausnahme
Ein Service, der einer Gruppe zugeordnet ist, wird für alle Hosts
gleich parametrisiert
Ein Service, der für einen Host einer bestehenden Gruppe anders
parametrisiert werden soll ist eine Ausnahme
Soll ein Host, der Bestandteil einer Gruppe ist, einen Service nicht
ausführen, so ist dies eine Ausnahme
Flexibilität
Kein Service ist fest kodiert, die zur Verfügung stehenden Services
sind selbst eine Datenquelle
Einfachheit
Der „Standardadmin“ braucht kein Wissen über Interna der Nagios
Konfigurationsobjekte/Dateien
Er muss nur in der Lage sein, Datenquellen zu pflegen
28. 28DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Stammdaten services.cfg (Ausschnitt)
Stammdaten
Service Mapping
(Gruppe: Dienst)
Gruppe1: Host,..
Gruppe2: Host,..
GruppeX: Host,..
Interne services.cfg
Ausnahmen
Explizite Gruppen
Templates
für services
Parameter
für services
Filter Anzahl
Scanhost
MASTER
Services.cfg
Scanhost_1
Services.cfg
Scanhost_n
Services.cfg
Service
Mapper
Splitter
Gruppierung
Plugin
Eingriffsmöglichkeit
für Plugins
29. 29DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Automatisierte Konfigurationserstellung Nagiosserver
Umsetzung - Kern
Perl-Skript, welches Datenquellen entsprechend
Vorgaben/Randbedingungen auswertet.
Internes Tool, im Kern ca. 2500 Zeilen Code
Plugin-Architektur, weitere Funktionalitäten können über eine
simple Plugin-Schnittstelle realisiert werden (derzeit weitere ~2000
Zeilen Code in Plugins vorhanden)
Umsetzung - Infrastruktur
In kontinuierlichen Intervallen (derzeit tagsüber alle 2 Stunden)
werden Stammdaten und Datenquellen aktualisiert
Es werden neue Konfigurationen für Nagios-Master und Scanhosts
erzeugt
Ausrollen und Prüfung auf syntaktische Korrektheit, im Fehlerfall
wird die vorherige Konfiguration wieder hergestellt.
31. 31DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Aufgaben des automatisierten Deployments
Serverseitig
Erstellung einer Konfiguration für eine verteilte Nagiosumgebung
Differenzierung zwischen „Master“ und Scanhost
Master
– haben eine komplette Sicht auf alle Services/Hosts
– führen keine aktiven Checks durch
– Schicken Notifications an das Cockpit
Scanhosts
– Jede Nagiosinstanz kennt jeweils nur den Teil der Hosts und
Services, für die sie zuständig sind
– Führen aktive Checks durch
– Melden Ergebnisse an einen „Master“
Herausforderung
Kontinuierliche Erstellung der Konfiguration
Ausrollen auf alle Komponenten (2 Master, 2 Scanhosts mit
insgesamt 8 Instanzen)
Test und ggfs. Zurückrollen auf allen Komponenten
32. 32DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Aufgaben des automatisierten Deployments
Clientseitig
Erstellung versionierter RPM Pakete für
– NRPE und NRPE Konfiguration
– Nagios Standard Plugins
– Eigene Nagios Plugins
– Checklogfiles Plugin und Konfiguration
Pflege zweier unterschiedlicher Repositories
– Abnahme
– Produktion
– Systeme haben genau eines dieser Repositories konfiguriert
Aktualisierung der Pakete ausserhalb des kontinuierlichen
Patchprozesses
Jedes System aktualisiert alle 2 Stunden die in diesen
Repositories vorhandenen Pakete (soweit Aktualisierungen
vorhanden)
Änderungen werden erst im Abnahmerepo getestet, bevor sie in
die Produktion wandern.
34. 34DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Zusammenfassung
Plattformmonitoring
Enger Fokus auf die „Plattform“
Konfigurationsfrontend
Metakonfiguration
Zuweisung aus einem Set vordefinierter Services
Identisches Gruppenverhalten, Abweichungen sind Ausnahmen
Nagios
Verteilte, redundante Umgebung im produktiven Betrieb
„Nur“ Einsatz der Scan- und Notification-Funktionen
Verarbeitung der Events in externem Tool
35. 35DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Vielen Dank für Ihre Aufmerksamkeit