Seit ein paar Tagen wurde das Jahr 2009 erfolgreich eingeläutet und der Server lief bisher (seit dem letzten Absturz) ohne Absturz. WIndows Server 2008 x64 ist bereits erfolgreich auf dem drbd Device unter XEN installiert, ja selbst der Exchange 2007 darauf läuft. Nun trug es sich zu, das die Maschine bei einigen kleinen Konfigurationsarbeiten in der VM (nichts Weltbewegendes) einmal wieder dicke Backen machte. Das erste Fass war ja schon lange übergelaufen, damit war es nun das Zweite das es dem Ersten gleich tat.
Schneller und ein im Nachhinein nicht übereilter Schluss: Maschine aus dem RZ holen und vor Ort noch einmal durchchecken bzw. durchchecken lassen. Dank DRBD war die Arbeit nicht verloren und so wurde sofort die VM auf der Ersatzmaschine gestartet die auch erfolgreich Ihren Dienst tat. Die komplette Maschine (incl. der VMs die darauf laufen sollen, ist ein Kundenprojekt). In solch einem Fall lassen wir unsere Kunden niemals im Regen stehen (vorher stell ich meine eigene WS als Server ins RZ) und haben schnell die für die weiteren VMs benötigten Ressourcen auf verschiedenen unserer Server reserviert, der Kunde kann erst einmal arbeiten und wir können uns im Ruhe dieser Schrottkiste annehmen. Allerings, gerade weil wir momentan noch einige andere Dinge auf VMs ausgelagert hatten (ein paar größere Kundenprojekte, deren eigene Maschinen am Ende der Leistungsgrenze waren, und aufgrund spezieller “Sonnenverhältnisse” ging so ein Upgrade nicht von heute auf Morgen. Denn wir haben nicht endlos unbenutzte neue Hardware rumliegen, allerdings immer genug VM Ressourcen frei um innerhalb weniger Minuten/Stunden etwas auf die Beine stellen zu können). Jedenfalls aus diesen Gründen waren damit unsere freien Ressourcen auch so gut wie am Ende (zwischendurch wurde schon RAM aus unwichtigen eigenen Test VMs assimiliert).
Wir fühlen uns ja alle so wohl in Hannover, also wieder hin und die Maschine aus dem Rack gezogen. Im Büro angekommen ließ sich das Problem ganz schnell und einfach nachbauen, wieder einmal hat sich der SCSI Bus aufgehangen. Und wieder einmal folgte ein Telefonat mit IBM. Das erste was der IBM Techniker konnte, war sich darüber zu beschweren das er noch keinen DSA Report bekommen hatte und das es zu 100% daran liegt das wir kein Supportetes Betriebssystem einsetzen. Daraufhin habe ich ihm prohezeit, das wir das mit dem Supporteten Betriebssystem gerne einmal ausprobieren können, sollte aber dann der gleiche Fehler auftreten, ich persönlich in Stuttgart erscheinen würde und ihm die Maschine so lang im die Ohren hauen würde, bis eines von beiden zuerst nachgibt.
Dem Techniker also einen Haufen DSA Reports zugesandt (für jede Treiberversion einen . . das wurde während der Treiber Tests schon vorbereitet). Dem Techniker also am 5.1.2009 um 12:10 die Mail zugesandt, die Antwort erfolgte in absoluter Bestzeit am 6.1.2009 um 14:25 (da weiß man wieso man ein teures CarePack hat). Der Techniker könne nichts erkenne, meine aber das in einigen DSAs die falsche Treiber Version wäre, aber auch einige mit den richtigen Versionen. Unter anderem ist in den DSAs der Inhalt der Logs enthalten, der Techniker meinte nun das er in den Logs nichts erkennen könne und das es von daher keine Probleme gibt.
Mittlerweile ist das dritte Fass im gleichen Status wie die beiden zuvor. Jedes Kind (naja, jeder Admin Azubi) weiß, das wenn einem der SCSI Bus und damit sämtliche Block devices die der Server hat um die Ohren fliegen, man dann auch nichts mehr loggen kann. Diese einfache Logik ist IBM wohl nicht klar. Im Anhang der Mail befand sich ein Script, welches den ServRaid Controller auswerten soll. Die angehangene aacconf Binary war natürlich im Eimer, aber soetwas hat man ja selbstverständlich auf Lager. Also dem Herrn eine Antwort um 6.1.09 um 16:02 zukommen lassen.
Eine Antwort von IBM erfolgte um 17:21 Uhr desselben Tages, das ist nun wirklich Bestzeit, ich kann es noch garnicht glauben. Sicherheitshalber prüfe ich meinen Schlafzustand infolgedessen Wunschträume möglich wären. Techniker ist immer noch der Meinung das es am Betriebssystem liegt, ich solle es doch bitte einmal mit RHEL5 testen, würde dann der gleiche Fehler auftauchen, würde man das Systemboard und den RAID Controller tauschen. In weiser Vorraussicht habe ich bereits eine RHEL5 Testlizenz organisiert (wir selbst haben bis auf ganz ganz ganz ganz wenige Ausnahmen kein RHEL5). Die Installation begann.
IBM xSeries returns in: IBM xSeries AKT VII – Oder: Rote Hüte und IBM