Hardware-Monitoring der PING-Server bei Knipp
Um nicht erst von einem sich androhenden Defekt der Server zu erfahren wenn es zu spät ist, werden die PING-Server überwacht und dies Protokolliert. Das einfachste und verständlichste Protokoll findet sich hierbei im Munin. Des Weiteren werden z. B. die Festplatten von smartd aus den Smartmontools überwacht, welches seine Funde in den Syslog-Logfiles und per E-Mail dokumentiert.
Mainboard-Sensoren über IPMI
Die Mainboard-Sensoren können über das Webinterface der IPMI-Karten auch dann eingesehen werden, wenn das Betriebssystem dies gerade nicht kann.
Mainboard-Sensoren über LM-Sensors
Die selben Informationen können allerdings auch über die LM-Sensors (Paket lm-sensors) abgerufen werden. Zwar lassen sich die Sensoren, die am Super-IO-Chip des Mainboards angeschlossen sind, über mehrere Schnittstellen abrufen, allerdings sind diese ggf. nicht vollständig.
Nach einem Test der unterschiedlichen Module hat sich das I²C-Interface des w83793-Sensors (Modul w83793) als zuverlässige Quelle herauskristallisiert. Für den Zugriff auf den Sensor-Chip ist des Weiteren der Intel SMBus Treiber (Modul i2c-i801 notwendig. Sinnvollerweise sollten beide Module automatisch geladen werden, indem sie in die Datei /etc/modules eingetragen werden.
Da nicht alle Eingänge der Sensor-Chips mit Sensoren verbunden sind, ist es notwendig einige Eingänge zu ignorieren. Dies geschieht bei LM-Sensors über die Konfigurationsdatei /etc/sensors3.conf, welche im Bereich w83793-* einige „Ignore“-Zeilen zu ergänzen ist. Folgende Änderungen haben sich dabei als Sinnvoll erwiesen:
--- sensors3.conf.orig 2010-03-11 20:56:00.000000000 +0100 +++ sensors3.conf 2010-03-11 20:56:09.000000000 +0100 @@ -794,6 +794,17 @@ # ignore fan7 # ignore temp3 +ignore fan2 +ignore fan5 +ignore fan6 +ignore fan8 +ignore fan9 +ignore fan10 + +ignore temp2 +ignore temp3 +ignore temp4 + chip "as99127f-*"
Nach dem Anpassen der Konfigurationsdatei kann die neue Konfiguration über das Init-Skript /etc/init.d/lm-sensors mittels reload aktiviert werden.
Festplatten überwachen mit den Smartmonntools
Der 3ware RAID-Controller bzw. das RAID-1-Volume wird im System zwar als SCSI-Device (/dev/sda) dargestellt, allerdings handelt es sich hierbei nicht mehr um individuelle Festplatten, sondern um das fertige RAID-Volume. Sollen nun die Informationen über die verbauten und an den RAID-Controller angeschlossenen Festplatten abgefragt werden, müssen die Smartmontools einen speziellen 3ware-Treiber verwenden.
Da sich die Smartmontools grundsätzlich in zwei unterschiedliche Komponenten teilen, wird der richtige Smartmontools-Treiber unterschiedlich aktiviert. Für direkte Abfrage der Festplatten über das smartctl Kommando ist der Programmparamter -d zu verwenden. Der benötigte Treiber hört auf den Namen 3ware. Eine Ansprechen der Festplatten ist dabei nur individuell möglich, weshalb der 3ware-Treiber einen weiteren Parameter, die Plattennummer, benötigt. Die Plattennummer kann dabei einfach mit einem Komma getrennt an den Treiber angefügt werden. Möchte man also den aktuellen Zustand der ersten Festplatte abfragen, wäre der richtige Aufruf: smartctl -d 3ware,1 -a /dev/twa0 Bei /dev/twa0 handelt es dabei um ein Gerät des Linux 3ware-Treibers (Modul 3w_9xxx), dass nicht automatisch generiert wird. Da dies von den Smartmontools übernommen wird, sollte dies kein Problem darstellen.
Um die Festplatten automatisch zu überwachen, bietet sich das Programm smartd an. Es behält dabei ein Auge auf den Festplatten und schreibt bei Änderungen des Zustands (der SMART-Daten) eine E-Mail und Log-Einträge. Um den smartd zu aktivieren, muss in der Datei /etc/default/smartmontools die Zeile mit dem Eintrag start_smartd=yes aktiviert werden. Danach übernimmt das Init-Skript /etc/init.d/smartmontools das automatische Starten beim booten. Bevor nun aber der smartd-Daemon gestartet werden kann, muss noch seine Konfigurationsdatei (/etc/smartd.conf) angepasst werden. Zumindest die Version der Smartmontools aus Lenny (und auch die Version, die wohl in Squeeze landen wird) kann nicht automatisch erkennen, dass es sich bei /dev/sda um einen 3ware-Controller handelt.
Die mitgelieferte Konfigurationsdatei der Smartmontools erkennt normalerweise Festplatten automatisch. Verantwortlich hierfür ist das Schlüsselwort DEVICESCAN, das dafür Sorge trägt, dass beim starten des smartd-Dämonen vorhandene Gerätedateien in Device-Verzeichnis (/dev) automatisch geprüft werden. Anstelle dieser automatischen Erkennung kann auch ein konkretes Device vorgegeben werden (siehe Beispiele in der Datei). Weitere Optionen, wie z. B. der zu verwendende Treiber und die Treiber-Optionen werden dann hinter dem entsprechenden Device, auf das sie sich beziehen, notiert (in der Sytax, die auch smartctl erwartet). Für unseren 3ware-Controller ist nun die erste DEVICESCAN-Zeile zu ersetzen (da sie ansonsten dafür sorgt, dass keine Geräte erkannt werden) durch zwei konkrete Einträge für die RAID-Platten. Dementsprechend wird aus DEVICESCAN /dev/twa0 -d 3ware,0 respektive /dev/twa0 -d 3ware,1. In Diffform sieht das ganze dann wie folgt aus:
--- smartd.conf.orig 2010-03-11 21:21:20.000000000 +0100 +++ smartd.conf 2010-03-11 23:59:10.000000000 +0100 @@ -19,7 +19,9 @@ # Directives listed below, which will be applied to all devices that # are found. Most users should comment out DEVICESCAN and explicitly # list the devices that they wish to monitor. -DEVICESCAN -m root -M exec /usr/share/smartmontools/smartd-runner +#DEVICESCAN -m root -M exec /usr/share/smartmontools/smartd-runner +/dev/twa0 -d 3ware,0 -m root -M exec /usr/share/smartmontools/smartd-runner +/dev/twa0 -d 3ware,1 -m root -M exec /usr/share/smartmontools/smartd-runner # Alternative setting to ignore temperature and power-on hours reports # in syslog.
Nach dieser Änderung sollte sich der smartd-Daemon über das Init-Skript /etc/init.d/smartmontools starten lassen (siehe /var/log/syslog für entsprechende Meldungen).