iowait – Ein Lehrstück

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:

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.