Die letzten zwei Tage waren schlimm. Der eigentliche Plan war, den beiden Knoten unseres größten Storage-Clusters (2 x 16 Festplatten im DRBD-Verbund) angesichts gestiegenen Datendurchsatzes zwei zusätzliche GBit-Netzwerkschnittstellen zu verpassen, um die Bandbreite für iSCSI zu erhöhen.
Der Einbau der zusätzlichen Netzwerkkarten verlief auch prima und von Kunden unbemerkt – da bei einem manuellen Failover des aktiven Knotens im Storagecluster die angeschlossenen Systeme maximal 5-10 Sekunden kurz bei Plattenzugriffen hängen, fällt nicht mal mitten am Tag ein solcher Failover auf.
Bei der Konfiguration der zusätzlichen Netzwerkschnittstellen hörte der Spaß dann leider auf. Das eingeplante Bonding ließ sich um’s Verplatzen nicht im laufenden Betrieb aktivieren; ein Netzwerk-Restart tat sowohl DRBD als auch Heartbeat alles anderes als gut; noch ein menschlicher Fauxpas dazu … und schon hatten wir alle Hände voll zu tun damit, um den gesamten Cluster wieder zu stabilisieren. Doch darum soll es hier nicht gehen. Im Lauf des heutigen Vormittags haben wir im Team unsere Pläne und unsere Erfahrungen vom Vortag durchgesprochen und uns schließlich dazu entschieden, anstelle von Bonding die zusätzliche Ports über einen zusätzlichen Switch laufen zu lassen und einige der besonders iSCSI-intensiven Knoten dann dorthin zu verlagern. Und damit fingen die Unwägbarkeiten dann erstmal so richtig an.
Alle angeschlossenen Hosts haben keine lokalen Festplatten. Sie booten via PXE direkt aus dem Cluster und bekommen via iSCSI ihre Root-Partition. Der PXE-Server befindet sich dabei mit je einer Schnittstelle an jedem Switch, kann also beide Netzbereiche bedienen.
Wir haben nicht schlecht gestaunt, als der PXE-Bootvorgang – der immer mit einem DHCP-Request beginnt – am einen Switch so problemlos läuft wie immer; versuchten wir es jedoch am anderen Switch, so dauerte es eine halbe Minute, bis per DHCP eine IP bezogen wurde. Über PXE wird dann gPXE (früher Etherboot) geladen, was dann auch iSCSI-fähig ist und das eigentliche System einbindet. Dafür macht es selbst auch noch einmal einen DHCP-Request – und der schlug (dank eines kürzeren Timeouts) schließlich ganz fehl. Der Server bootet nicht.
Nun hatten wir bereits via tcpdump herausgefunden: Die DHCPDISCOVER-Pakete kommen gar nicht erst am DHCP-Server an – erst nach besagter halber Minute. Ein Serverproblem ist von daher auszuschließen. Der DHCP-Request wird hier direkt von der Netzwerkkarte gestellt – ist also auch nichts, wo man einfach mal eben --verbose oder --debug angeben könnte. Sollte etwa … der Switch?
Problematisch ist immer, wenn man es nicht mit einem konkreten Programm oder einer konkreten Fehlermeldung zu tun hat. Wonach sollte man googlen? Switch? DHCP? Timeout? Alles Begriffe, die viel zu generisch sind, um (auch in Kombination) vernünftige Treffer zu liefern. Aber nach längerem Stöbern fanden sich in der Tat Beschreibungen wie
A little further analysis with other devices has determined that the SFE2000 simply is not passing every DHCP Discover request. It seems to work every 4th or 5th request, the others being dropped
Hat zwar nichts mit unserem Switch-Modell zu tun, aber ein Anhaltspunkt, dass ein Problem jener Art existiert. Jemand anders meldet:
dhcpcd not sending DHCPDISCOVER/-REQUEST at boot, timing out
in dessen Diskussionsverlauf schließlich ein vages
On a switched network I would be suspect of the switch just in case it is being clever somehow
zutage tritt. Und schließlich:
Checking with the comms gurus they said to check for a switch feature called „portfast“. Google finds quite a bit on it if you are not familiar with it already.
Klare Sache, „checking with the comms gurus“ werde ich ab sofort in meinen Sprachgebrauch mit aufnehmen, und „portfast“ hat sich als genau das richtige Stichwort herausgestellt – obwohl alle Beteiligten angaben, das würde nur Cisco- und HP-Switche betreffen, während wir einen 3com haben.
Fürs Protokoll: Es ist die Kommunikation aus eingeschalteten Spanning Tree Protocol und ausgeschaltetem Portfast. Nicht, dass wir das Spanning Tree Protocol benutzen würden oder wollten – es war einfach standardmäßig eingeschaltet. Und es sorgt dafür, dass beim Aktivieren des betreffenden Switchports zunächst eine Art „Lernphase“ einsetzt, bevor dann – etwa 30 Sekunden später – die ersten Pakete tatsächlich über den Port laufen können.
Aus genau diesem Grund kommen die DHCPDISCOVER-Requests auch erst so spät durch – und für gPXE sogar zu spät. Kaum dass wir Spanning Tree deaktiviert hatten, lief alles genauso fix wie am anderen Port. Durchatmen, weitermachen.