Route ins Nichts – ein Microsoft-iSCSI Märchen

Eigentlich hat sich meine Einstellung zu Microsoft und deren Produkten in den letzten Jahren stark gewandelt. Anstatt solchem Müll wie Windows 95 machen sie seit Vista wirklich brauchbare Betriebssysteme und auch der Rest ist nicht schlecht. Den MSSQL ziehe ich Oracle oder vor allem DB2 (ich hasse DB2!) vor und Exchange ist auch ein richtig feines Stück Software. Lync ist auch… ich schweife ab!

Bei ihrem iSCSI Initiator haben sie aber an einer Stelle richtig ins Klo gegriffen – und mich fast einen kompletten Arbeitstag gekostet. Zu allem Überfluss wird das aber noch mit der alten „it’s a feature“-Masche verkauft. Wie in den alten Zeiten, als MS dafür bekannt war, mit unglaublicher Arroganz nur Müll zu verschleudern…

Ich bastle derzeit an ein paar richtig beschissenen Gurken, für die jemand sehr viel Geld bezahlt hat, weil sie schick aussehen und einen Touchscreen haben, den nur die Geschäftsführung toll findet, aber keiner benutzt. Nein, keine Apple Rechner. Die haben keine mit Heißkleber montierten Bleche und USB-Soundkarten im Inneren ­­- und keine Touchscreens. Wie sich herausstellte, können die Krücken kein Wake on LAN – und dem Hersteller ist das auch egal. Das war selbst im Jahr 2000 schon nicht mehr zeitgemäß. Jedenfalls kann ich sie genau deshalb nicht auf normalen Wege mit Images versorgen und dafür einmal zwischen vier und fünf morgens per Netzwerk wecken. Als Lösung sollen sie, da fest verkabelt an guten Ciscos, via iSCSI booten. Dann kann ich nachts auf dem Server die Images plattmachen.

Windows 7 und iSCSI-Boot sind, soweit mir bekannt, von Microsoft als Kombination nicht offiziell unterstützt. Bei 2008 R2 sind sie es aber. Im Kern sind beide Betriebssysteme ziemlich gleich, weshalb es in der Praxis mit Win7 auch sehr gut geht. Nur das Installieren ist manchmal ein wenig fummelig, weil eine ganze Menge Dinge richtig zusammen spielen müssen. Manchmal muss man bspw. den Modus das SATA Controllers ändern, damit das Setup die iSCSI-Platte akzeptiert, oder eine bestimmte Version des Netzwerktreibers macht Probleme.

Schnitt, einige Stunden später.

Mittlerweile habe ich mir einen Windows PE USB Stick mit (sogar dem grafischen) MS iSCSI-Client und einem halben Dutzend verschiedenen Versionen des Realtek Treibers gebastelt, verschiedene Versionen von gPXE/iPXE im PXE Bootmenü, iPXE in verschiedenen Versionen kompiliert und getestet und auch die Windows 7 SP1 CD via iSCSI CDROM bereitgestellt. Dank des saudummen BIOS, dass nach dem Verlassen von gPXE nur auf CDROM oder Platte zurückfallen kann, nicht aber auf USB, habe ich sogar einige Boot-CDs. Aber egal was ich versuche, Windows 7 weigert sich, eine Installation auf die iSCSI-Platte durchzuführen.

Vom Windows PE Stick booten klappt 1a, Initiator startet, ich kann Targets einbinden und darauf lesen und schreiben. Im Windowssetup hilft das aber nicht, iSCSI Bereitstellung nicht verfügbar… bla, iBFT… kann keinem NT-sichtbaren Gerät zugeordnet werden. Meine, durchaus richtige, Vermutung war, dass das Einbinden des Targets zwingend durch gPXE oder iPXE erfolgen muss, und der Initiatorservice unter WinPE nicht reicht.

Es ist sogar richtig tückisch. Der Initiatorservice unter Windows PE funktioniert nämlich hervorragend. Keinerlei Probleme, hervorragende Schreib-/Leseraten, auch iSCSI-CDROMs funktionieren. Ich konnte sogar testweise vom PE Stick booten, dann das iSCSI-CDROM einbinden und von dem die Installation auf die lokale Platte starten. Mit dem Bootinitiator, der die Probleme verursachte, hat das Ding aber sehr wenig zu tun.

Ob es überhaupt möglich ist, Windows PE zu booten, dort erst die iSCSI Verbindung herzustellen und dann direkt auf ein iSCSI-Target zu installieren, weiß ich nicht und bezweifle es fast. Der Initiator dort scheint nämlich tatsächlich keinerlei iBFT Einträge zu erstellen, auf die das Windows Setup aber beharrt. Bisher war ich nie so verzweifelt diesen Weg zu probieren. HBAs und BIOS gingen immer direkt, wenn die nicht vorhanden waren, oder kein iSCSI konnten, gab es auch nie Probleme mit gPXE. Da war aber wohl viel Zufall dabei, wie ich jetzt weiß.

Nachdem ich also sicher war, dass ich mit gPXE soweit kommen muss, dass die Festplatte unter Windows PE, ohne den angepfropften iSCSI Dienst, sichtbar ist, war die Frage, warum das nicht klappt. Nach einigen Versuchen mit den verschiedensten Varianten und Versionen war mir klar, es gibt ein grundsätzlicheres Problem als Treiber und gPXE. Aber welches? Sind die Kisten so verbockt, dass es wirklich nicht geht? Falls ja wollte ich wenigstens genau wissen, woran es denn läge.

Was macht man, wenn man Probleme mit Netzwerkzeug hat, und nicht genau weiß, was schief geht? Richtig, Wireshark – oder eingedeutscht Kabelhai. Weil es so herum bequemer war, natürlich zuerst auf dem Server. Das Ergebnis war interessant, aber wenig erhellend. gPXE baute eine Verbindung auf, aber mit dem Laden von Windows PE oder dem Windows Setup kam nichts mehr, auch kein Abbau. Als ob plötzlich die Verbindung tot wäre. Der Versuch, das Target von der PE Kommandozeile zu pingen schlug fehl. Das Standardgateway antwortete mir mit „Zielnetz nicht erreichbar“. Moment, warum das? Das Target ist doch im selben Netzwerksegment! Was zum…? Den iSCSI Dienst gestartet, mich zum Target verbunden, alles geht. Warum geht das, aber kein Ping?!?

Also einmal laut gestöhnt und unter leisem Fluchen alles bereit gemacht, um auf Clientseite zu lauschen. Und da ging mir ganz schnell ein Licht auf! Mit dem Start von Windows gab es tatsächlich Versuche, das Target zu erreichen. Aber die gingen an eine komplett falsche Adresse, nämlich das Standardgateway. Das ergibt aber keinen Sinn, da sich das Target im selben Netzwerksegment befindet, man also kein Gateway braucht. Das Gateway hat dann, als vielleicht einzig richtig konfiguriertes Gerät in dem ganzen Netzwerk, das nicht von mir stammt, vollkommen richtig gehandelt. Pakete als Gateway dorthin zu routen, wo sie herkommen, ist nämlich schlechter Stil und sollte mit einer entsprechenden ICMP Nachricht quittiert werden. Tatsächlich konnte man unter PE via route print sehen, dass es eine Hostroute für das Target gab, die über das Standardgateway führte. Aber wo kommt die bitte her? Und warum ignoriert der manuell gestartete Initiatordienst die?

Google wusste eine Antwort auf die erste Frage und da ist mir die Kinnlade heruntergeklappt. Der Bootinitiator (nicht dem normalen Initiator zu verwechseln) fügt einfach blind eine Route über das Gateway hinzu – immer. Man lese sich mal das hier durch. http://support.microsoft.com/kb/960104

Unter „Cause“ steht minimal paraphrasiert exakt das, was als Symptom beschrieben wird, aber keinerlei Erklärung, warum das Sinn machen soll oder was schief ginge. Unter „Resolution“ steht eine halbgare Predigt über iSCSI und getrennte NICs. In einem Nebensatz wird dann erwähnt, dass man halt in dem Netz, in dem sich der iSCSI Boot-NIC befindet, keine Gateways verteilen soll, wenn man die Probleme nicht haben will.

Bei so einer Scheiße klappt mir das Messer in der Tasche auf! Aber richtig!

Dass ich bisher nie auf dieses Problem gestoßen bin liegt nur daran, dass ich bisher immer entweder isolierte iSCSI Netze hatte oder das Target gleichzeitig auch Gateway war. Aber dieser Schwachsinn kann richtig gefährlich werden. Man stelle sich vor, dass das Gateway nicht meckert und den Traffic weiterleitet. Wenn das Target mit einem 10GBit Link am Switch hängt und das Gateway nur mit einem Gbit, wird das Ding unter Umständen totgeflutet und man wundert sich erst einmal, warum iSCSI so langsam ist – oder das Gateway. Oder das Gateway fällt aus und iSCSI merkwürdigerweise gleich mit. Und natürlich kommt auf dem Weg auch sinnlos Latenz hinzu, was ein sehr kritischer bei Faktor iSCSI ist.

Nun könnte man dieses merkwürdige Verhalten akzeptieren, wenn es einen guten Grund dafür gäbe. Den sehe ich aber nicht! Ganz im Gegenteil.

Wie trickst man den saudummen Bootinitiator aber nun aus? In meinem Fall ist ein zusätzlicher NIC keine Option und an DHCP und Gateway kann ich nicht ran. Also werde ich wohl nächste Woche gPXE mit einem kleinen Skript kompilieren, dass nach dem DHCP Request das Standardgateway auf 0.0.0.0 setzt. Sobald Windows bootet holt sich der eigentliche TCP/IP Stack eh nochmal die Daten vom DHCP.

Was lernen wir also daraus? Auch heute noch baut Microsoft manchmal richtige Scheiße. Richtige, dumme Scheiße.

Und wenn wir am Meckern sind: iPXE zu kompilieren war auch eine ganz tolle Erfahrung. Ein einfaches „make bin/kpxe“ schlägt nämlich fehl, irgendein buildscript überschreitet irgendwelche Arraygrenzen. Ich hatte Glück und konnte auf Google zurückgreifen, anstatt mich selbst durch den Code zu kämpfen. Mit „make bin/kpxe NO_WERROR=1″ funktionierte es dann. Das ist die Schattenseite von Open Source: So etwas muss man selbst herausfinden oder Mailinglisten durchsuchen. Einfach in eine Anleitung schreibt es keiner, weil es keine Kunden gibt, die einen Hotfix verlangen könnten, und die man zufriedenstellen müsste.

Comments are closed.