Überwachung eines LSI SAS2 Controllers (SAS2008) mit Nagios

Der LSI SAS Controller wird durch das Kernel-Modul mpt2sas betrieben. Für das anzeigen des Status wird ein CLI Tool mit dem Namen sas2ircu benötigt. Aktuelle Debian bzw. Ubuntu Pakete sind auf der Webseite http://hwraid.le-vert.net/wiki/DebianPackages#no1 zu finden.

Damit man die Ausgabe dieses CLI Tools mit Nagios überwachen kann, benötigt man das Nagios-Plugin check_sas2ircu.

Damit das Nagios-Plugin funktionierte, muss es natürlich mit sudo gestartet werden. Damit dies funktioniert, muss man in die Datei /etc/sudoers noch die folgende Zeile eintragen:

nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/check_sas2ircu

Überwachung des 3ware Controllers SAS9750-8i mit Nagios

Um den Status eines RAID bei einem 3ware Controller abzufragen, gibt es ein CLI Tool mit dem Namen tw_cli. Jonas Genannt war so nett und hat dazu ein paar Debian-Pakete gebaut, die auch unter Ubuntu laufen. Diese findet man auf der Webseite http://jonas.genannt.name/.

Die Ausgabe dieses CLI Tools kann man dann wiederum mit Nagios überwachen. Dadurch bekommt man sofort mit, wenn eine Festplatte ausfällt. Ich habe dazu das Nagios-Plugin check_3ware_raid_1_1 verwendet. Es gibt aber auch noch diverse andere.

Damit das Nagios-Plugin funktionierte, musste ich allerdings einen Softlink für das tw_cli im Verzeichnis der Nagios-Plugins anlegen und das Nagios Plugin mit sudo starten. Damit dies funktioniert, muss man in die Datei /etc/sudoers natürlich noch die folgende Zeile eintragen:

nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/check_3ware_raid_1_1

Linux: Austausch einer defekten Festplatte im Software-RAID

Der Status des Software RAID (Redundant Array of Independent Disks) wird bei Linux in der Datei /proc/mdstat festgehalten. Man kann sich den Status eines RAID also mit folgenden Befehl anzeigen lassen:

cat /proc/mdstat

Wenn z.B. die Festplatte /dev/sdb defekt ist, könnte die Ausgabe von wie folgt aussehen:

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear] [multipath]
md2 : active raid1 sdb3[2](F) sda3[0]
730202368 blocks [2/1] [U_]
 
md1 : active raid1 sda2[0] sdb2[2](F)
264960 blocks [2/1] [U_]
 
md0 : active raid1 sdb1[1](F) sda1[0]
2102464 blocks [2/2] [U_]

Details über die einzelnen RAID Devices kann man sich mit dem Befehl mdadm anzeigen lassen. Wenn man die Details von md1 sehen möchte gibt man also den folgenden Befehl ein:

mdadm --detail /dev/md0

Bevor eine neue Festplatte verbaut wird, sollte jetzt zunächst die defekte Festplatte aus dem RAID entfernt werden.

mdadm /dev/md0 -r /dev/sdb1
mdadm /dev/md1 -r /dev/sdb2
mdadm /dev/md2 -r /dev/sdb3

Unter Umständen kann es sein, dass eine verwendete Festplatte teilweise defekt ist und sich nicht alle Devices im Status [U_] befinden, sondern einige Devices im Status [UU] sind. In diesem Fall schlägt der Befehl fehl, da das device in Ordnung ist. In diesem Fall müssen vorher die intakten Devices mit dem Befehl mdadm als defekt markiert werden. Wenn in unserem Beispiel das Device md1 noch intakt wäre, könnte man dies mit dem folgenden Befehl erreichen:

mdadm --manage /dev/md1 --fail /dev/sdb2

Danach kann die neue Festplatte verbaut werden. Wenn dies geschehen ist können Partitionierung und Bootsektor von der intakten Festplatte mit dem Befehl dd kopiert werden. Das kopieren der Partitionstabelle mit dd funktioniert nicht für extended-Partitionen, diese müssen von Hand angelegt werden. Da in unserem Beispiel keine extended-Partitionen vorkommen, könnte man mit dem folgenden Befehl Partitionierung und Bootsektor auf die neue Festplatte kopieren:

dd if=/dev/sda of=/dev/sdb count=1 bs=512

Die Partitionstabelle muss nun vom Kernel neu eingelesen werden.

sfdisk -R /dev/sdb

Zum Schluss müssen die Partitionen der neuen Festplatte noch in das RAID eingebunden werden:

mdadm /dev/md0 -a /dev/sdb1
mdadm /dev/md1 -a /dev/sdb2
mdadm /dev/md2 -a /dev/sdb3

Die neuen Partitionen sind somit Teil des Arrays und werden nun synchronisiert. Dieser Vorgang kann je nach Größe eine ganze Weile dauern. Mittels cat /proc/mdstat kann der Status der Synchronisation aufgerufen werden.

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear] [multipath] 
md2 : active raid1 sdb3[2] sda3[0]
      730202368 blocks [2/1] [U_]
      [==>..................]  recovery = 11.7% (85713024/730202368) finish=143.8min speed=74694K/sec
 
md0 : active raid1 sdb1[2] sda1[0]
      2102464 blocks [2/1] [U_]
        resync=DELAYED
 
md1 : active raid1 sdb2[1] sda2[0]
      264960 blocks [2/2] [UU]
 
unused devices: <none>

OMSA unter Ubuntu für den Dell PERC H700 einrichten

In den Dell PowerEdge Servern wird aktuell häufig der PERC H700 RAID-Controler verbaut. Als ich Heute bei einem solchen Server – der mit der aktuellen „Long Term Support“ Ubuntu-Version „10.04 LTS“ läuft – den OMSA (OpenManage Server Administrator) installierte, überraschte mich dieser gleich mit der Warnung: Controller 0 [PERC H700 Integrated]: Driver '00.00.04.01' is out of date.

Nach ein wenig Recherche im Internet zeigte sich, dass der Treiber 00.00.04.01 eigentlich o.k. ist. Da bei RedHat und SuSe aber inzwischen neuere Treiber verwendet werden, verlangt der OMSA hier den neuen.

Da mich die Warnung in der Überwachung stört, habe ich diese einfach abgeschaltet. Dazu ändert man einfach die Datei lsiver.cfg entsprechend ab. Wenn man das OMSA 6.4 Paket von Dell installiert hat (dieses finde man unter der URL: http://linux.dell.com/repo/community/deb/), liegt diese Datei in dem Verzeichnis /opt/dell/srvadmin/etc/srvadmin-storage/.

In der Datei lsiver.cfg gibt es einen Abschnitt der wie folgt beginnt:

ID=0x1F17
VENDORID=4
NAME=PERC H700 Integrated

In diesem Abschnitt steht etwas weiter unten die Zeile:

DEF-LX26-64=00.00.04.27

Wenn man hier die 27 in 01 ändert und alle OMSA Services (am besten den ganzen Server) neu startet ist der Alarm weg.