Seitdem wir^[TM] auf HP-Server der DL-Serie setzen, bin ich recht überzeugt von dieser Wahl. Die Maschinchen powern was das Zeug hält und lassen sich für einfach alles einsetzen: Datenbankserver, Webserver, Java-Applicationserver. Alles mit einer Hardware mit leicht modifizierten Setups. Hier^[TM] kommen DL-360G5 mit 2-6 15k-SAS-Platten, oft mit 512MB-BWBC-Raid-Controller und 12-32GB (eher letzteres) RAM zum Einsatz.

Nun gibt es da noch ein Problem. So ein Serverchen muss gemonitort werden, da man sonst nichts annähernd zeitnah mitbekommt. Als bekennender Nagios-Freund (only NSA monitors more) gibt es da auch schon etwas: den check_ilo2_health. Dieser geht auf die Remote-Konsole und holt sich Informationen über die Verfügbarkeit und Temperaturen von CPU, Board und Netzteilen. Fein, Maschine lebt, aber….
Da gibt es ja noch Festplatten, und sogar recht intensiv genutzte im System, und auch bei einem Raid 1+0 darf nunmal im worst-case nur eine einzigste ausfallen, die sollte dann ASAP ersetzt werden (spare-Platten sind zu teuer, dafür sind die System aber nochmal redundant ;)).

Da ich kein Freund von „zu-Tode-Monitoren“ bin, kann ich also auch nicht ressourcenintensive Monitor-clients auf den Servern leiden. Auch ist das recht unangenehm, mit den Tools zu arbeiten, die HP bereitstellt, wenn man nun nicht gerade ein Redhat4 oder was auch immer vorgeschrieben wird, nutzen möchte. Unsere^[TM] Strategie tendiert derzeit in Richtung Debian-basierter Systeme. Da Lenny noch nicht frozen war/ist, Etch doch auch schon wieder etwas alt, ist es ein Ubuntu Hardy geworden, das mit dem LTS (long time support) auch etwas Zukunftssicherheit für security-patches gibt oder geben sollte ;).
HP ist da leider noch nicht soweit und „unterstüzt“ Debian Etch – aber auch nur rudimentär – der Link ist auf der HP-site kaum zu finden.

Die HPacuCLI laufen recht gut, das ist ein auf Kommandozeile basiertes Tool — eben CLI, mit dem ich im laufenden Betrieb schnell mal das Raid umkonfigurieren kann. Reboot war gestern. Festplatten rein, Raid build, mkfs, mountpoint gesetzt, fertig.
Dieses Tool nutzt mein folgendes kleines Plugin, um den Health-Status der disks und der Raids zu prüfen. Damit ist es „etwas“ günstiger als HP OpenView und für das kleine ein-mal-eins — wie geht es meinen Serverchen so rein hardwaremäßig, abseits dessen was das OS von sich aus darüber erzählen kann (iostat, memory-usage) — reichts.
Wer mag und ein Raid6 betreibt, kann da Erweiterungen vornehmen und z.B. bei Ausfall einer Platte erst und ein WARN-Status gehen. Oder er sagt, dass, wenn der Controller im ReBuild-Prozess ist, das bereits Warning sei (in der Zeit darf aber auch keine andere Platte ausfallen ;)), oder, oder, oder …

Die Installation:
* wir benötigen ein altes libstdc++2.10-glibc2.2, dass es in Debian-Etch noch gab. Zu beziehen bei Debian.org oder bei Ubuntu-Gutsy — Installation etc. natürlich mit Super-user Privilegien
** http://packages.ubuntu.com/gutsy/i386/libstdc++2.10-glibc2.2/download
* weiterhin natürlich die HPacuCLI, die es bei HP für umme gibt, wer mit neueren Paketen (8.10 läuft auch recht fehlerfrei) herumexperimentieren will, nimmt alien zu Hilfe, um aus den RPMs ein DEB zu machen
** http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T8569AAE
* Auf 64-Bit Systemen ist die 32-Bit Architektur dieser Pakete zu ignorieren:

dpkg -i –force-architecture hpacucli-7.80-3.linux.deb
dpkg -i –force-architecture libstdc++2.10-glibc2.2_2.95.4-24_i386.deb

* Nicht hinterlegte Abhängigkeiten für hpacucli ist libc6-dev

apt-get install libc6-dev-i386 libc6-dev

Der Test:
mit /usr/sbin/hpacucli ctrl all show status können wir nun das erste Erfolgserlebnis verzeichnen, mit /usr/sbin/hpacucli ctrl all show config detail sehen wir so richtig viel.

Die NRPE-Implementation:
Herr nagios (oder der user, in dessen Kontext nrpe läuft) muss super-user Rechte auf dieses Tool bekommen, aber bitte nur auf show ;) — eine /bin/false in der passwd für Herrn nagios sichert das ganze nochmal etwas ab:
*visudo

nagios ALL = NOPASSWD: /usr/sbin/hpacucli ctrl all show config

Wir müssen unser Plugin dem NRPE bekanntmachen, unter dem Pfad sollte sich natürlich auch das kleine bash-Plugin check_hpacucli finden lassen
* /etc/nagios/nrpe_local.cfg (oder was auch immer)

command[check_hpacucli]=/usr/lib64/nagios/plugins/check_hpacucli

Nach dem Restart des nrpe ist damit auf dem zu messenden System schon alles getan.

Die Nagios-Implementation:
Auf dem Nagios-Server sind es zwei Konfigurationen:
* die Definition des Kommandos in checkcommands.cfg

define command{
command_name    check_nrpe_hpacucli
command_line    $USER1$/check_nrpe -u -H $HOSTADDRESS$ -c check_hpacucli
}

* die Definition des Services, Wir prüfen hier stündlich, im Fehlerfall 15 Minuten später und senden bei Bestätigung des CRIT einen Alarm – und wiederholen diesen alle 6 Stunden, wenn sich wieder mal kein Schwein drum kümmert.

define service{
use    generic-GROUP-service
hostgroup_name    GROUP
service_description    disk_health
flap_detection_enabled    1
contact_groups    admin,alert,icke
notification_options    c
normal_check_interval    60
retry_check_interval    15
max_check_attempts    2
notification_interval    360
check_command    check_nrpe_hpacucli
}

Dieser Text wurde am 17.10.2008 um 07:03 in der Kategorie Allgemein hinterlegt. Kommentare können mit dem RSS 2.0 Feed verfolgt werden. You can skip to the end and leave a response. Pinging is currently not allowed.