Artikel mit ‘netzwerk’ getagged

iowait – Ein Lehrstück

Sonntag, 16. Januar 2011

Wir betreiben seit längerer Zeit einen Storagecluster, auf dessen Basis wir sowohl dedizierte als auch virtuelle Server laufen lassen. Technisch läuft das so, dass die betreffenden Server ohne lokale Festplatten über PXE booten, mit Hilfe von gPXE (früher etherboot) dann per iSCSI ihre Root-Partition vom Storagecluster beziehen und das betreffende System booten. Das läuft 1a und sorgt für eine deutlich bessere Ressourcenausnutzung verglichen mit Failover-Clustern, bei denen pro produktivem Server ein Gerät als Spare daneben steht: Nur der Storagecluster muss redundant sein – die eigentliche Serverhardware nicht, beziehungsweise: Es reicht, für eine ganze Gruppe von Servern nur wenige Ersatzgeräte bereitzuhalten, denn wenn eine Hardware physisch ausfällt, kann man das zentral auf dem Storage liegende System problemlos auf beliebiger neuer Hardware booten lassen.

Allerdings kann einem das auch ziemlich auf den Fuß fallen, und zwar, weil sich „Performance“ in Sachen Datenübertragung primär in zwei Faktoren ausdrückt: Dem Durchsatz einerseits; der Latenz andererseits. In der Theorie war uns das allen bekannt, aber das plastischste Beispiel dafür haben wir erst im Zusammenhang mit dem Storagecluster gefunden – leider erst im produktiven Betrieb, wie es nun so ist. Insofern ist es auch ein Beispiel dafür, dass auch wir im Laufe unserer Arbeit noch so einiges dazulernen, und manches davon durchaus nicht im stillen Kämmerlein, sondern weil’s gerade brennt.

Um einen kurzen Exkurs für diejenigen zu machen, die mit Latenz und Durchsatz nicht viel anfangen können:

Man stelle sich eine vierspurige Autobahn vor. Es gibt keine Geschwindigkeitsbegrenzung. Die Autobahn kann also im Prinzip auch von Raketenautos befahren werden, und da sie vier Spuren hat, können sogar vier Raketenautos gleichzeitig darauf fahren. Oder auch ein paar mehr. Nur dann, wenn’s richtig viele werden – dann gibt es Stau. Die Latenz ist gering (man kann rasen), aber die Bandbreite begrenzt (nur vier Spuren).

Umgekehrt: Eine kilometerbreite Schotterstrecke. Selbst Raketenautos können hier nur 50 km/h fahren. Aber dafür können hier hunderte Autos in diesem Tempo nebeneinanderfahren – ohne dass es Stau gibt. Es gibt hohe Latenzen (die Straße ist schlecht), aber viel Durchsatz (sehr breite Straße).

Hat man nun mit einem übers Netzwerk erreichbaren Storage zu tun, so spielen hier zwei Komponenten eine Rolle: Einerseits die Netzwerkkarte; andererseits das Plattensystem, also die Kombination aus RAID-Controller und physischen Festplatten. Dass auf der Netzwerkebene manchmal nicht nur nur die Bandbreite („Ich hab DSL Soundsovieltausend!“), sondern auch die Latenz eine Rolle spielen kann, weiß jeder, der viel online zockt und hier gerne besonders schnelle Ping-Zeiten hätte – und dann für eine FastPath-Option von seinem DSL-Provider oft mit einem kleinen Aufpreis zur Kasse gebeten wird. Ganz klar: Will ich schnell vorankommen, spielt – bei leerer Straße – keine Rolle, ob mir zwei oder hundert Spuren zur Verfügung stehen, sondern die Straße muss eben gut ausgebaut und nicht nur geschottert sein.

Netzwerkkarten sind Paradebeispiele für Geräte, die äußerst niedrige Latenzen aufweisen (die Latenzen, die man sich mit FastPath beim DSL wegkaufen muss, entstehen erst an anderer Stelle). Die Bandbreite steht auf der Packung: 100 MBit/s (Fast Ethernet) oder 1000 MBit/s (Gigabit Ethernet) sind hier gängige Größen. Gigabit Ethernet heißt: Es können 1000 MBit pro Sekunde übertragen werden, also etwa 128 MB. Eine konventionelle Serial-ATA-Festplatte überträgt demgegenüber 300 MB pro Sekunde – also mehr als doppelt soviel. Aber dafür ist eine Festplatte ein Gerät, wo sich erstmal physisch irgendwelche Teile drehen, ein Schreib-/Lesekopf sich bewegen muss … und das heißt: Es gibt Latenzen. Die Zugriffsgeschwindigkeit „normaler“ Festplatten liegt heute so um die 10ms – was zwar schnell klingt, aber bei einer Netzwerkverbindung liegt die Latenz bei weit unter 1ms, ist also um eine satte Größenordnung kleiner.

Beim Einsatz von netzwerkbasiertem Storage könnte man also zunächst meinen, dass dann hier die schlechte Zugriffsgeschwindigkeit von Festplatten die geringe Latenz der Netzwerkkarte schnell vergessen lässt, und dass die ach so schicke Bandbreite einer Festplatte keine Chance hat, weil die Daten ja zuvor erst noch durch eine Netzwerkkarte gequetscht werden müssen, die deutlich weniger Bandbreite hat. Von beidem also das Schlechteste? Nein, nicht ganz. Denn zum einen verteilt der RAID-Controller im Storage die Zugriffe auf viele Festplatten, was deren hohe Latenz entschärft. Zum zweiten muss darauf sowieso nicht gewartet werden, denn der RAID-Controller besitzt einen eingebauten batteriegepufferten Cache, und es reicht, wenn sich zu schreibende Daten dort befinden. Physisch auf Festplatten schreiben kann der RAID-Controller die Daten auch später.

Insofern: Latenzprobleme gibt’s bei diesem Aufbau eher weniger. Aber eben schmalere Bandbreite. Würde man das Setup auf lokale Festplatten umstellen, hätte man bessere – aber dann auch mehr Latenz. Gute Voraussetzungen also für ein Vom-Regen-in-die-Traufe-Problem. Und so sieht es aus:

iowait-Last-Beispiel

Der erste große Bereich bis zur senkrechten Linie 1 zeigt den Betrieb eines Servers im Storage-Cluster, also via iSCSI; die rote Kurve zeigt dabei vereinfacht gesagt, wieviel Prozent seiner Zeit der Server darauf gewartet hat, mit dem Plattensystem interagieren zu können. Hier ist deutlich erkennbar, dass diese Kurve zwar im Allgemeinen relativ niedrig ist, aber immer wieder hässliche Peaks hat – Peaks, in denen man ls -l eingibt und sich fragt: Was zur Hölle dauert hier so lange? Ein klares Zeichen für einen Engpass.

Die Linie 1 markiert nun den Moment, an dem wir den Server aus dem Storagecluster und auf ein baugleiches System mit lokalen Platten umgebaut haben. Kurz vorher zeigen zwei Peaks der roten Linie die zwei vorab durchgeführten Datensynchronisationen an; eine grobe am Abend und dann noch eine für die letzten Änderungen mitten in der Nacht.

Der Abschnitt zwischen 1 und 2 zeigt nun deutlich: Das war nicht nur vom Regen in die Traufe; das war vom Regen sogar bis in den Brunnen, ganz tief unten. Soll heißen: Obwohl die lokalen Festplatten eine wesentlich höhere Bandbreite haben, zieht ihre schlechtere Latenz das System noch viel massiver in den Keller. Auf der Haben-Seite steht, dass es im Grunde keine schlimmen Peaks mehr gibt. Umgekehrt muss zähneknirschend festgestellt werden, dass die Festplattenlast nun eigentlich einen einzigen durchgehenden Peak darstellt.

Wir haben während dieser Zeit bereits einen Replikationspartner aufgesetzt, der via DRBD den gesamten Datenbestand auf ein baugleiches System übertragen und aktuell gehalten hat – diesmal aber nicht auf ein RAID1, sondern auf ein RAID0. (Wem das nichts sagt: Beim RAID1 werden die Daten einer Festplatte 1:1 auf eine zweite gespielt. Beim RAID0 hingegen werden Schreibzugriffe auf beide Festplatten verteilt – finden also grob gesagt doppelt so schnell statt.)

Die Linie 2 zeigt nun den Zeitpunkt, an dem wir auf das andere Gerät – das mit dem RAID0 – umgeschaltet haben. Unmittelbar danach haben wir auf dem vorherigen Gerät das RAID1 ebenfalls durch ein RAID0 ersetzt und die Daten zurücksynchronisiert, was der Grund dafür ist, wieso die rote Kurve hier erstmal nicht signifikant runtergeht.

Aber dann: 6 Uhr morgens; Linie 3. Die Rück-Synchronisation ist abgeschlossen – und das System atmet förmlich auf. Es ist gut erkennbar, wie sämtliche Kurven den gesamten Freitag über keinerlei Peaks zeigen. Vor allem, wenn man das mit Montag, Dienstag und Mittwoch – also ebenfalls Werktagen – vergleicht, ist das ein massiver Fortschritt. Die Maschine ist nun effektiv rund um die Uhr zu 90% untätig, so wie es sein soll, um für plötzliche Lastspitzen, wenn mal wieder ein Kunde Fernsehwerbung schaltet, anständig gerüstet zu sein.

Gut erkennbar ist nebenbei der Peak, der mit 4 eingekringelt ist. Der lässt sich nicht vermeiden: So sieht das aus, wenn die tägliche Datensicherung einmal alle Daten auf dem Festplattensystem anschauen muss, um festzustellen, ob sie in die inkrementelle Sicherung neu übertragen werden müssen. Aber selbst dieser Peak ist, verglichen mit den Peaks an anderen Tagen zur gleichen Uhrzeit, fast schon zu vernachlässigen.

Wenn Switche zu smart sind

Donnerstag, 23. Dezember 2010

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.

Einfach mal umgebaut

Montag, 07. September 2009

Es ist sicherlich nicht die feine Art, über Mitbewerber zu lästern, und es soll auch eine Ausnahme bleiben. Aber was einem unserer Kunden vor wenigen Tagen bei einem anderen Hoster – nennen wir ihn „N“ – passiert ist, ließ mir wirklich die Kinnlade herunterfallen.

Wir haben kein Problem damit, wenn Kunden von uns Server bei anderen Anbietern betreiben und dann nur den Support von uns beziehen. Sicherlich ist das nicht optimal, wenn wir bei echten Problemen keine Möglichkeit haben, z.B. Hardware zu reparieren und auch sonst auf die Debugging-Möglichkeiten des anderen Anbieters angewiesen sind, wenn der Kunde Hilfe braucht, aber wir kommunzieren im Vorhinein klar, was geht und was nicht, so dass es hier eigentlich nie zu Irritationen kommt.

Der Server, den unser Kunde neben einigen anderen bei N hat, machte Probleme. Die genaue Vorgeschichte kennen wir nicht; aus telefonischen Schilderungen konnten wir Unspezifisches entnehmen wie „das Gerät reagiert nur langsam“ (obwohl der Load bei 0 liegt), „Pings gehen mal durch und mal nicht“ … kurz, Symptome, die vieles bedeuten können.

Den Logfiles konnten wir entnehmen, dass der fragliche Server in den letzten Tagen etwa 40 Mal rebootet worden ist – au weia. Wenn ein Reboot ein Problem nicht löst, tut’s ein zweiter in der Regel auch nicht. Aber sei’s drum.

Wir wurden zu Hilfe gerufen, als die Situation die war, dass N dem Kunden mitteilte, den Server rebootet zu haben, der Kunde den Server aber dennoch nicht erreichen konnte. N hat für diese Fälle ein einfaches Schema: Der Server wird in den Rescue-Modus versetzt und dem Kunden das Rescue-Passwort mitgeteilt, damit er sich die Sache selber ansehen kann.

Ich will anmerken, dass ich diese Vorgehensweise – gelinde gesagt – bereits eine Unverschämtheit finde. Der Server ist nämlich ein Mietgerät, das mit von N vorinstallierter Software ausgeliefert wird und ein Webinterface mit sich bringt. Der Kunde hat zu keinem Zeitpunkt am Kernel, an den Netzwerkeinstellungen oder an sonst irgendetwas herumgebastelt, sondern einfach nur Websites über das bereitgestellte Webinterface eingerichtet. Wenn so grundlegende Funktionalität wie die schlichte Erreichbarkeit übers Netzwerk fehlt, ist das aus meiner Sicht daher immer Sache des Anbieters, dies vertragsgemäß bereitzustellen. (Anders sieht der Fall natürlich aus, wenn der Kunde selber ein Betriebssystem installiert oder am bereitgestellten System herumbastelt, zum Beispiel einen anderen Kernel installiert, der nicht funktioniert. Anbieter, die eine solche Freiheit ermöglichen, bieten dann aber typischerweise dafür auch eine Rescue-Konsole. Bei N heißt „Rescue-Modus“, dass man anrufen muss und ein Techniker eine CD einlegt. Von daher muss man auch nochmal anrufen, wenn die CD wieder entfernt werden muss, damit das Gerät normal booten kann. An Rescue außerhalb der Geschäftszeiten ist von daher nicht zu denken.)

Wir hatten nun also Zugang zum Rescue-System des Servers, der nicht mehr per Netzwerk erreichbar war. Die letzte Auskunft des Supports von N lautete: Wir hatten Tastatur und Monitor angeschlossen und konnten verifizieren, dass der Server hochgefahren ist und nun am Login-Prompt steht. Als der Kunde daraufhin anmerkte, dass der Server aber nicht mal per Ping erreichbar wäre, folgte kurzerhand der Rescue-Modus, „damit Sie das wieder in Ordnung bringen können“.

Mein Kollege Matthias brachte mich auf den entscheidenden Punkt: Ich solle mir doch mal die Ausgabe von lspci anschauen; da würde was von einer Intel-Netzwerkkarte stehen. Er meine, sich erinnern zu können, dass da eine RealTek-Karte drin gewesen sei.

Einige Checks in den dmesg-Logfiles später war klar:

Erstens, N hat die Netzwerkkarte ausgetauscht.

Zweitens, N hat dem Kunden aber nicht gesagt, dass sie die Netzwerkkarte ausgetauscht haben.

Drittens, in dem – von N! – installierten Kernel ist überhaupt kein Treiber für die neue Netzwerkkarte vorhanden. Das Gerät kann also überhaupt nicht übers Netzwerk erreichbar sein.

N hat folglich überhaupt nicht geprüft, ob die neue Netzwerkkarte funktioniert. Sie haben es nicht mal geprüft als der Kunde sich explizit darüber beschwerte, dass der Server nicht per Netzwerk erreichbar ist. Stattdessen hat man einfach den Rescue-Modus aktiviert und dem Kunden die Fehlersuche überlassen – wie gesagt, ohne ihm mitzuteilen, dass da jetzt eine ganz andere Netzwerkkarte drinsteckt.

Letztlich konnten wir an dem Problem nicht viel machen, denn der installierte Kernel ist, vorsichtig gesagt, antik. Kurz, für aktuelle Intel-Netzwerkkarten ist da mit einem Treiber nicht viel zu wollen. Unser Support für den Kunden beschränkte sich also eher darauf, ihn darin zu unterstützen, dass N das Problem korrekt löst – und sich vielleicht dann doch auch bitte mal zum Thema „stillschweigend getauschte Netzwerkkarte“ äußern möge.

Das hat N dann schließlich auch getan: Die einzige Möglichkeit sei, einen neuen Kernel zu kompilieren oder die Daten zu sichern und den Server neu aufzusetzen. Offensichtlich war es N aber zu mühselig, einen neuen Kernel zu kompilieren, denn die finale Aufforderung lautete schließlich:

Daher bitten wir Sie, die wichtigen Daten zu sichern, sodass wir den Server neu aufsetzen können. Dies können Sie im Rescuemodus mit dem Programm „WinSCP“ machen, welches so ähnlich funktioniert wie ein ftp-Programm.

Verständlicherweise ist dem Kunden da dann ziemlich der Kragen geplatzt. Immerhin ist bei einem Mietserver die korrekte Funktion der Hardware strikt die Sache des Anbieters, und genauso auch das korrekte Zusammenspiel mit dem ausgelieferten System – sprich, wird die Hardware durch den Anbieter (zumal ohne Rücksprache) verändert, sehe ich es auch als Sache des Anbieters, das installierte Betriebssystem entsprechend anzupassen.

Unnötig zu sagen, dass „die wichtigsten Daten sichern“ nicht einfach ein scp-Befehl gewesen wäre. Immerhin geht es um unterschiedliche Systemuser, deren Daten, Konfigurationsdateien, und schließlich auch noch die Daten der Konfiguration der Web-Administration, von der niemand genau weiß, wo sie liegen und wie man sie so sichern kann, dass man sie woanders wieder einspielen kann. Aber offensichtlich meint N, das manuelle Anlegen von, sagen wir mal, 100 Websites und 1000 E-Mail-Adressen und anschließendes Wiedereinspielen von Backups sei keine Arbeit, das kannman ja mal in der Kaffeepause erledigen.

Nachdem wir den Kunden mit entsprechender Argumentation ausgestattet hatten, war es eine Sache von einer Stunde, bis der Anbieter eine Netzwerkkarte eingebaut hatte, die vom bestehenden Kernel unterstützt wird. Das Gerät läuft seitdem wieder ohne Schwierigkeiten.


Impressum