OSMC 2012 | Environmental Monitoring in der Praxis by Carsten John

© 2012 Carsten John, Max-Planck-Institut für marine Mikrobiologie Seite 1/28
Environmental Monitoring
in der Praxis

● whoami
– Carsten John
– Ursprünglich Studium der Elektrotechnik
– Danach im Bereich Netzwerke, *nixserver etc.
projektbezogen unterwegs
– Seit 2004 am Max-Planck-Institut für marine
Mikrobiologie in Bremen
– Schwerpunkte: Infrastruktur, *nix-Server,
Netzwerk, Sicherheit

● Agenda
– Warum dieser Vortrag
– Fallbeispiele aus der Praxis
– Konsequenzen für die Sensorik
– Lösung für das kontrollierte Herunterfahren der
Systeme
– Diskussion

● Warum dieser Vortrag
– Versorgung der IT-Infrastruktur nimmt eine
Schlüsselposition ein:
● Gibt es Probleme in der Versorgungstechnik
(insbesondere Kühlung) nutzen die tollsten Server
nichts. Es kommt zu Ausfällen und meist auch zu
Hardwareschäden
● Alle denkbaren Ausfälle ereignen sich irgendwann
● ich habe einige Vorfälle dieser Art live erlebt (in großen
wie in kleinen Umgebungen)
● “If you can't monitor it, you can't manage it”

Fallbeispiele aus der Praxis

● Fall A (kleine Umgebung, Arztpraxis), der
Klassiker
– Die Klimaanlage (Splitgerät), in dem als
“Serverraum” genutzen Lagerraum, fällt am
Wochenende aus. Am Montag ist dann alles “gar”.
– In der Folge sterben in schneller Folge der DLT
Streamer, ein Servermainboard sowie ein
redundant ausgelegtes Netzteil.

● Fall B
– System mit gekühlten Schränken (Rittal LCP), Kühlung erfolgt
über Luft/Wasser Wärmetauscher mit zentraler
Kühlwasserversorgung
– Bei Wartungsarbeiten an der elektrischen Anlage fällt die
Steuerung der Kühlwasserpumpen aus. Dies bleibt zunächst
unbemerkt, da das System der Gebäudeleittechnik nur die Vor-
und Rücklauftemperaturen sowie den (quasi statischen)
Wasserdruck, nicht aber den Durchfluss überwacht.
– Als die Temperaturüberwachung der Schränke anspricht ist
kaum noch Zeit zu reagieren
– Nach kurzer Zeit erreichen einzelne Schränke 90°C
– Die Hardwareschäden sind erheblich (insbes. Festplatten)

Pumpe Pumpe
Wärmetauscher
Regelventil
Rittal LCP
°C Pa

● Fall C
– Die Stellgröße (Steuerspannung) für ein
Regelventil der primären Külwasserversorgung
fällt aufgrund eines technischen Defektes aus.
– Das Ventil fährt daraufhin in Stellung “ZU”
– In der Folge kommt es zum Ausfall der gesamten
Kühlung
– Die (paranoid eingestellte) Überwachung der
Vorlauftemperatur der IT-Systeme schlägt
rechtzeitig Alarm.

● In den Fällen A und B wäre durch eine
geeignete Überwachung der Schaden deutlich
geringer ausgefallen.
● Versorgungssysteme können in der Praxis
systematische Fehler haben. Ein
Kühlwasserventil wie im Fall C sollte bei
Verlust der Stellgröße in Stellung “AUF”
fahren.
● Die Überwachung muss unabhängig vom
Regelkreis des Systems sein!

● Unabhängigkeit der Überwachung von den
Regelkreisen der überwachten Systemen
– Sensoren, die Bestandteil der Regelung sind,
sollten nicht zur Überwachung/Alarmierung
genutzt werden!
● Ein defekter Sensor, der zu fehlerhaftem Verhalten der
Regelung führt bleibt sonst unentdeckt.
– Auch bei den Sensoren ist Redundanz notwendig

Pumpe Pumpe
Wärmetauscher
Regelventil
Rittal LCP
°C Pa
All die schönen Sensoren sind für die Überwachung
nur eingeschränkt zu gebrauchen, da sie integraler
Bestandteil der Regelung sind!
Diese Sensoren liefern wert-
volle Informationen.

● Auswertung der Informationen aus den LCPs
– Per SNMP lassen sich alle Messwerte der Rittal
LCPs auslesen
– Interessant sind hier die Vorlauftemperaturen, die
Stellung des Regelventiles sowie der
Kühlmittelfluss
● Wenn die Vorlauftemperatur mehr als 2°C vom Sollwert
abweicht → Alarm
● Wenn das Ventil offen ist, aber kein Durchfluss → Alarm
● Wenn das Ventil geschlossenn ist, aber trotzdem
Durchfluss → Alarm

● Die zahlreichen vorhandenen Plugins für Rittal
LCPs boten nicht die gewünschte Funktion
● die beiden “quick and dirty” Plugins stehen
zum Download zur Verfügung:
http://magnum.mpibremen.de/~cjohn/OSMC_2012/check_rittal_inlet_temp.sh
http://magnum.mpibremen.de/~cjohn/OSMC_2012/check_rittal_waterflow.sh

● Zusätzliche netzwerkfähige Sensorunits sind
von unterschiedlichen Herstellern verfügbar.
● Nagios Plugins sind i.d.R. vorhanden (oder
einfach SNMP basiert zu implementieren)

● Bei direkt gekühlten Schränken (z.B. Rittal LCP,
Knürr o.ä.) muss jeder Schrank mit einem eigenen
Sensor ausgestattet werden.
● Bei Raumkühlung reicht oft ein Sensor pro Raum
● Die Sensorunits ermöglichen oft den Anschluss
mehrerer Sensoren, häufig auch für weitere phys.
Größen (Luftfeuchtigkeit, Leckage etc.)
● Eine gute Zusammenarbeit mit den Kollegen von der
Gebäudebetriebstechnik ist extrem vorteilhaft.

● Kontrolliertes Herunterfahren der Systeme bei
kritischen Umgebungsbedingungen
– Die bestehenden Lösungen (SNMP Traps,
herstellerspezifische Lösungen) waren uns zu
unflexiblel
– Lösung: der NetworkWeatherReport
(M.Döhle, MPI Bremen)

● NetworkWeatherReport
– An verschiedenen Orten werden “Wetterdaten”
gesammelt (Temperatur, Luftfeuchtigkeit, USV
Status usw.)
– Das Ergebnis wird als “Wetterbericht” per
Multicast gesendet
– Alle Maschinen empfangen den “Wetterbericht”
– Werden individuelle Grenzwerte überschritten,
fahren die betroffenen Maschinen herunter (oder
führen einen beliebigen Befehl aus)

Server (nwrd)
Standort A Standort B
Environment Unit Environment Unit
SNM
P-GET
Multicast
Client (nwr) Client (nwr)

● Auf einem Server läuft die Serverkomponente
(nwrd) und sammelt die Umgebungsdaten von
den Standorten ein.
● Die Information wird als Multicast gesendet.
● Auf den Hosts läuft jeweils die Clientkomponente
(nwr).
– nwr ermittelt zunächst per SNMP den eigenen
Standort (SysLocation, 1.3.6.2.1.6, localhost). Wenn
ein empfangener Messwert zum eigenen Standort
ausserhalb des Grenzwertes liegt, wird ein Shell-
Kommando ausgeführt.

/etc/nwrd.conf (Serverkomponente)
port = 54321
group = 224.0.0.42
interfaces = eth0 eth1 eth2 eth3 eth5 eth6
secret = geheim
community = public
interval = 20
MPI|R107|rack1.temp: 1.3.6.1.4.1.318.1.1.10.4.2.3.1.5.0.1@envmonitorr1071
MPI|R107.remaining: 1.3.6.1.4.1.318.1.1.1.2.2.3.0@usvr107
MPI|R107.usvTemp: 1.3.6.1.4.1.318.1.1.1.2.2.2.0@usvr107
MPI|R1134.remaining: 1.3.6.1.4.1.318.1.1.1.2.2.3.0@usvr1134
MPI|R1134.usvTemp: 1.3.6.1.4.1.318.1.1.1.2.2.2.0@usvr1134

nwr (Clientkomponente)
port = 54321
group = 224.0.0.42
secret = geheim
timeout = 60
retimeout = 3600
# Mindestanzahl der Überschreitungen
threshold = 5
.temp > 28 : init 0
.temp > 26 : # gridengine foo
.remaining < 10 : init 0
timeout : cat /etc/nwr.msg | mail s 'no more Weather reports' it@mpibremen.de

● Über unterschiedliche Grenzwerte lässt sich
ggf. eine zeitliche Staffelung beim
Herunterfahren erreichen:
– z.B. Clusterknoten bei 26°C, NFS Server bei 28°C
– Abhängigkeiten zwischen Servern können ein
Problem darstellen!

● Die Clientkomponente ist auch für Windows
verfügbar
● Die Quellen (GPL) und die Dokumentation des
NetWeatherReports stehen unter
http://magnum.mpibremen.de/~cjohn/OSMC_2012/nwr.tar.gz
zur Verfügung.

Danke für die Aufmerksamkeit
mailto:cjohn@mpibremen.de

OSMC 2012 | Environmental Monitoring in der Praxis by Carsten John

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Empfohlen

Empfohlen (20)

OSMC 2012 | Environmental Monitoring in der Praxis by Carsten John