OSMC 2012 | Monitoring bei der DB Systel by Ralf Döring

Nürnberg, 18.10.2012
DB Systel
Ralf Döring
ralf.doering@deutschebahn.com
Plattformmonitoring mit Nagios bei der DB Systel

2DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
1.
2.
3.
4.
5.
6.
Vorstellung
Nagios bei der Plattform UNIX/Linux
Technische Architektur Plattformmonitoring
Automatisierte Konfigurationserstellung
Automatisiertes Deployment
Zusammenfassung/Fragen
Inhalt

1.
2.
3.
4.
5.
6.
Vorstellung
Inhalt

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

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

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

1.
2.
3.
4.
5.
6.
Vorstellung
Inhalt

Vereinfachtes Architekturmodell der Plattform
RZ Netz
Hardware
Betriebssystem
Anwendungen („Verfahren“)
Storage

Fokus des Plattformmonitorings UNIX/Linux
RZ Netz
Hardware
Betriebssystem Storage
Anwendungen („Verfahren“)
Fokus des
Plattformmonitorings

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.

Integration in bestehende Monitoringprozesse
Cockpit
(First Level)
Netz
Unix
Windows
Notifications
Rückfragen
(2nd Level)
Wartungs-
Partner3rd Level

1.
2.
3.
4.
5.
6.
Vorstellung
Inhalt

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

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.)

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

Standort FFM
Master 2
Scanhost 2Scanhost 2
Master 2
Scanhost 2
Master 2
Scanhost 2
Standort Berlin
Technische Architektur Nagios – Schematischer Aufbau
Master 1
„Cockpit“
Netcool
Notificiations
Acks Acks
Überwachtes System
Scanhost 1

Schritte zur Integration in das Monitoring
Aufbau des
Systems
QS
Freigabe für
Monitoring
Einbindung
in Nagios

Aufbau des Servers und QS

Freigabe für Monitoring

Verarbeitung der Nagios Events

1.
2.
3.
4.
5.
6.
Vorstellung
Inhalt

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

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

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

Basis: Auszug aus Stammdaten
SYSTEM_NAME FULL_NAME IP ARCHITEKTUR RAUM OS STANDORT SL PL PROD
erfsbdzsl03 erfsbdzsl03.unix.db.de 172.a.b.c ProLiantBL460cG1 2014 sles11 Erfurt SL1 PL4 Produktion
tstsrdzsl09 tstsrdzsl09.unix.db.de 172.a.b.d ProliantDL360G4p 2014 sles9 Erfurt SL3 PL4 Produktion
#tstsrdzsl32 tstsrdzsl32.unix.db.de 172.a.b.c ProliantDL360G5 2014 sles11 Erfurt SL3 PL4
tstsrdzsl25 tstsrdzsl25.unix.db.de 172.a.b.d ProliantDL380G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
tstsrdzsl28 tstsrdzsl28.unix.db.de 172.a.b.c ProliantDL585G7 2014 rhel5 Erfurt SL3 PL4 Abnahme
tstsbdsbn30 tstsrdzsl30.unix.db.de 172.a.b.d ProLiantBL460cG1 2014 rhel6 Erfurt SL3 PL4 Abnahme
bt-sbl-200v bt-sbl-200v.unix.db.de 172.a.b.c ESX 2014 sles11 Erfurt SL3 PL4 Abnahme
bt-sbl-201v bt-sbl-201v.unix.db.de 172.a.b.d ESX 2014 sles11 Erfurt SL3 PL4 Abnahme
kaufbeuren kaufbeuren.unix.db.de 172.a.b.c ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kreuztal kreuztal.unix.db.de 172.a.b.d ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kupferberg kupferberg.unix.db.de 172.a.b.c ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kappeln kappeln.unix.db.de 172.a.b.d ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kodiak kodiak.unix.db.de 172.a.b.c ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kastellaun kastellaun.unix.db.de 172.a.b.d ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
koethen koethen.unix.db.de 172.a.b.c ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
koennern koennern.unix.db.de 172.a.b.d ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
knoxville knoxville.unix.db.de 172.a.b.c ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kaysville kaysville.unix.db.de 172.a.b.d ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kaufungen kaufungen.unix.db.de 172.a.b.c ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme
kentville kentville.unix.db.de 172.a.b.d ProliantDL360G5 2014 rhel6 Erfurt SL3 PL4 Abnahme

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

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.

1.
2.
3.
4.
5.
6.
Vorstellung
Inhalt

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

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.

1.
2.
3.
4.
5.
6.
Vorstellung
Inhalt

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

Vielen Dank für Ihre Aufmerksamkeit

OSMC 2012 | Monitoring bei der DB Systel by Ralf Döring

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2012 | Monitoring bei der DB Systel by Ralf Döring (20)

OSMC 2012 | Monitoring bei der DB Systel by Ralf Döring