iSCSI-Root booten – manchmal ein Problem – hier eine Lösung

Da hatte ich doch letztens ein Problem der besonderen Art bei einem Kunden.

Es war gefordert dass das Root-FS vom iSCSI (über eine superschnelle SAN) zur Verfügung gestellt wird. An sich kein Problem – oft gemacht – klappt an sich….

In dieser Maschinenkonstelation hat sich jedoch ein Problemchen eingetreten dass so auch nocht nicht da war. Und zwar hat (!!) die Maschine lokale Platten, diese sollen allerdings nicht zum Zwecke des Bootens verwendet werden, sondern dienen ausschliesslich als „flüchtiger Ablageplatz“ der auch gerne mal vernichtet werden darf und kann….

So – jetzt stellt sich das Problem das der iSCSI-Boot zwar schön den Kernel und die initrd vom iSCSI holt, aber dann einfach stecken bleibt. So als würde er sein Root-FS nicht finden.

 

In der Config ein bisschen herumgesucht – wenn man den RAID-Controller im BIOS abschaltet, klappt alles hervorragend. Wenn man von einem anderem Netzwerkadapter ins iSCSI bootet (in dem Fall 1GB Intel) klappt auch alles hervorragend. Nur eben nicht wenn man vom 10GB-Intel-Adapter ins iSCSI booten will.

Verschiedene Ansätze das Problem zu umgehen (initrd neu bauen) haben leider nicht gefruchtet – bis ich plötzlich eine seltsame Idee hatte : Warum nicht das gesamte Storage beim initialisieren des initrd ausklammern – man kann doch so viel beim booten ausschalten, warum also nicht das Storage.

Und siehe da – es gibt einen (sehr sehr selten verwendwten) Parameter nostorage, welcher tatsächlicher jegliches lokale (!!) Storage beim initialisieren ausnimmt. Genau das was ich brauche – dachte ich…..

Es bedarf nähmlich noch eines Parameters der verhindert dass die vom BIOS erkannten Laufwerke für den Bootvorgang herangezogen werden. Der eher bekanntere edd = off.

Mit edd=off nostorage bootet der Server bei eingeschaltenem RAID-Kontroller (sonst kann ihn das OS beim laden der Module nicht identifizieren) wunderschön in das Root-FS und bindet die lokalen Platten ins Filesystem ein – wie es sein soll…..

Das ganze noch (bei CentOS) Updateresistend im Grub /boot/grub/grub.cfg) eingetragen und es kann eigentlich nichts mehr passieren.

Umgebung :

• 5 ganz dicke Server mit SIX-Core und 96GB RAM
• SAN mit ganz viel Platten drinnen – angebunden über einen 10GB-Switch
• CentOS 5.5 als Betriebssystem