Die letzte Zeit war es etwas ruhiger hier, aber anderswo hat es gewaltig geknallt.
Gegeben seien 2 Systeme, die gemeinsam auf ein Dateisystem lesend wie schreibend zugreifen müssen. NFS kommt aus diversen Gründen nicht in Frage. Dann bleibt im IBM-Umfeld GPFS übrig, das man dann auf SAN-Storage ablegt. Da man das Clusterfilesystem auch hochverfügbar haben will, wird das Filesystem auch gleich doppelt abgelegt auf zwei verschiedenen Storage-Systemen (quasi ein RAID 1 auf Schrank-Ebene).
Beide Systeme sind entsprechend grossem Blech virtualisiert (LPARs) und greifen mittels VIO auf das Storage zu. Jedes VIO hat daher Verbindungen zu beiden Storage-Systemen.
Dann ... fällt ein Storagesystem komplett aus. Zumindest derart, daß die Daten nicht mehr auf die Disks kommen. Und daß die Verbindungen zu diesem Storagesystem ausfallen. Tada, die Stunde der Hochverfügbarkeit hat geschlagen. Jetzt kann sich zeigen, ob das teure System sein Geld wirklich wert ist.
Was machen allerdings die VIO Systeme auf beiden Blechen? Sie fahren alle Verbindungen zu sämtlichen Storage-Systemen herunter. Auf beiden LPARs blockieren sämtliche I/O Aufrufe, während das Clusterfilesystem noch gemountet ist.
Diese Blockade der VIO Systeme lässt sich nur durch einen Reboot aufheben (nachdem das kaputte Storage auch richtig vom Rest der Umgebung abgetrennt wurde). Und weil die LPARs auch hängen, braucht man auch dort einen Reboot. Richtiges unmounten des Clusterfilesystems? Leider nicht möglich. Datenverlust bzw ein inkonsistentes Dateisystem ist zu erwarten.
Nach diesen Reboots und bangen Stunden, wie denn das Filesystem aussieht, die erlösende Nachricht: Hat wohl keine bleibenden Schäden erlebt. Nach dem Reboot konnten die Applikationen wieder hochgefahren und in Betrieb genommen werden. Was gut ist, denn ein Restore aus dem Backup hätte noch Tage gedauert, da ja nicht nur dieses System betroffen war; das Restore der weniger wichtigen betroffenen Systeme war dann 5 Tage später dran.
Jetzt hat es sich herausgestellt, daß die VIO da einen Bug gehabt hat; eigentlich hätten ja nur die Verbindungen zum defekten SAN-System gekappt werden dürfen. Das Testing des gefixten Treibers läuft...
