SlideShare ist ein Scribd-Unternehmen logo
1 von 35
Downloaden Sie, um offline zu lesen
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
3DB 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
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
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
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
7DB 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
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
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
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.
11DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Integration in bestehende Monitoringprozesse
Cockpit
(First Level)
Netz
Unix
Windows
Notifications
Rückfragen
(2nd Level)
Wartungs-
Partner3rd Level
12DB 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
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
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.)
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
16DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
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
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
18DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Aufbau des Servers und QS
19DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Freigabe für Monitoring
20DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Freigabe für Monitoring
21DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Verarbeitung der Nagios Events
22DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Verarbeitung der Nagios Events
23DB 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
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
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
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
27DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
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
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
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.
30DB 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
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
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.
33DB 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
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
35DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012
Vielen Dank für Ihre Aufmerksamkeit

Weitere ähnliche Inhalte

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

Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...Splunk EMEA
 
20181210_ITTage2018_OracleNoSQLDB_KPatenge
20181210_ITTage2018_OracleNoSQLDB_KPatenge20181210_ITTage2018_OracleNoSQLDB_KPatenge
20181210_ITTage2018_OracleNoSQLDB_KPatengeKarin Patenge
 
OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...
OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...
OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...NETWAYS
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice ArchitekturenLeo Lindhorst
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsmatfsw
 
Zurück in die Zukunft - DNUG 2014 - Track 5.2
Zurück in die Zukunft - DNUG 2014 - Track 5.2Zurück in die Zukunft - DNUG 2014 - Track 5.2
Zurück in die Zukunft - DNUG 2014 - Track 5.2panagenda
 
OSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd Erk
OSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd ErkOSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd Erk
OSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd ErkNETWAYS
 
Anwender-Case Karl Storz GmbH & Co. KG auf OpenText Basis
Anwender-Case Karl Storz GmbH & Co. KG auf OpenText BasisAnwender-Case Karl Storz GmbH & Co. KG auf OpenText Basis
Anwender-Case Karl Storz GmbH & Co. KG auf OpenText Basisnetmedianer GmbH
 
Enterprise Cloud Native ist das neue Schwarz
Enterprise Cloud Native ist das neue SchwarzEnterprise Cloud Native ist das neue Schwarz
Enterprise Cloud Native ist das neue SchwarzQAware GmbH
 
.NET Core Architecture (UI)
.NET Core Architecture (UI).NET Core Architecture (UI)
.NET Core Architecture (UI)Robin Sedlaczek
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...QAware GmbH
 
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-StrategieCitrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-StrategieDigicomp Academy AG
 
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-UmfeldInfrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-UmfeldDaniel Steiger
 
Ivory Soa Suite
Ivory Soa SuiteIvory Soa Suite
Ivory Soa SuitePredrag61
 
Citrix Day 2014: Panalpina - global und doch nah
Citrix Day 2014: Panalpina - global und doch nahCitrix Day 2014: Panalpina - global und doch nah
Citrix Day 2014: Panalpina - global und doch nahDigicomp Academy AG
 
DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...
DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...
DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...JRibbeck
 
Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...
Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...
Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...comspace GmbH & Co. KG
 
Serverless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisServerless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisBATbern
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalQAware GmbH
 
IPv6 Integration im Datacenter - wie komplex ist es wirklich?
IPv6 Integration im Datacenter - wie komplex ist es wirklich?IPv6 Integration im Datacenter - wie komplex ist es wirklich?
IPv6 Integration im Datacenter - wie komplex ist es wirklich?Swiss IPv6 Council
 

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

Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
Splunk für alle: Optimierte Prozesse für eine zuverlässige und störungsfreie ...
 
20181210_ITTage2018_OracleNoSQLDB_KPatenge
20181210_ITTage2018_OracleNoSQLDB_KPatenge20181210_ITTage2018_OracleNoSQLDB_KPatenge
20181210_ITTage2018_OracleNoSQLDB_KPatenge
 
OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...
OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...
OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by...
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice Architekturen
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
 
Zurück in die Zukunft - DNUG 2014 - Track 5.2
Zurück in die Zukunft - DNUG 2014 - Track 5.2Zurück in die Zukunft - DNUG 2014 - Track 5.2
Zurück in die Zukunft - DNUG 2014 - Track 5.2
 
OSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd Erk
OSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd ErkOSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd Erk
OSMC 2008 | Aufbau eines Nagios Reporting Frameworks by Bernd Erk
 
Anwender-Case Karl Storz GmbH & Co. KG auf OpenText Basis
Anwender-Case Karl Storz GmbH & Co. KG auf OpenText BasisAnwender-Case Karl Storz GmbH & Co. KG auf OpenText Basis
Anwender-Case Karl Storz GmbH & Co. KG auf OpenText Basis
 
Enterprise Cloud Native ist das neue Schwarz
Enterprise Cloud Native ist das neue SchwarzEnterprise Cloud Native ist das neue Schwarz
Enterprise Cloud Native ist das neue Schwarz
 
.NET Core Architecture (UI)
.NET Core Architecture (UI).NET Core Architecture (UI)
.NET Core Architecture (UI)
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
 
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-StrategieCitrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
 
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-UmfeldInfrastruktur agil bauen - der DBA im SAFe-Umfeld
Infrastruktur agil bauen - der DBA im SAFe-Umfeld
 
Ivory Soa Suite
Ivory Soa SuiteIvory Soa Suite
Ivory Soa Suite
 
Citrix Day 2014: Panalpina - global und doch nah
Citrix Day 2014: Panalpina - global und doch nahCitrix Day 2014: Panalpina - global und doch nah
Citrix Day 2014: Panalpina - global und doch nah
 
DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...
DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...
DNUG 2014 Herbstkonferenz: Moderne Architektur - Hochskalierbare Anwendungsar...
 
Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...
Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...
Umzug in die Cloud - flexible, dynamische Websites und Digital Marketing am B...
 
Serverless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisServerless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der Praxis
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
 
IPv6 Integration im Datacenter - wie komplex ist es wirklich?
IPv6 Integration im Datacenter - wie komplex ist es wirklich?IPv6 Integration im Datacenter - wie komplex ist es wirklich?
IPv6 Integration im Datacenter - wie komplex ist es wirklich?
 

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

  • 1. Nürnberg, 18.10.2012 DB Systel Ralf Döring ralf.doering@deutschebahn.com Plattformmonitoring mit Nagios bei der DB Systel
  • 2. 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
  • 3. 3DB 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
  • 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
  • 7. 7DB 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
  • 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.
  • 11. 11DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 Integration in bestehende Monitoringprozesse Cockpit (First Level) Netz Unix Windows Notifications Rückfragen (2nd Level) Wartungs- Partner3rd Level
  • 12. 12DB 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
  • 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
  • 16. 16DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 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
  • 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
  • 19. 19DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 Freigabe für Monitoring
  • 20. 20DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 Freigabe für Monitoring
  • 21. 21DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 Verarbeitung der Nagios Events
  • 22. 22DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 Verarbeitung der Nagios Events
  • 23. 23DB 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
  • 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
  • 27. 27DB Systel | Ralf Döring | ralf.doering@deutschebahn.com | 18.10.2012 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
  • 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.
  • 30. 30DB 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
  • 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.
  • 33. 33DB 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
  • 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