Artikel mit ‘raid’ 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.

RAID1 mit neuen Platten vergrößern

Donnerstag, 24. Juni 2010

In einem Kundenserver, der schon ein paar Jahre auf dem Buckel hat, sollte der Speicherplatz erweitert werden – eingebaut waren zwei Festplatten mit je 160 GB; für heutige Verhältnisse in der Tat nicht mehr zeitgemäß. Möglichkeiten gibt es viele: Zusätzliche Platten einbauen (dann verbraucht die Kiste aber mehr Strom und wird lauter); eine externe Festplatte anschließen (die ist dann aber nicht redundant); die Festplatten austauschen und das System umkopieren (das dauert dann aber ewig). Schließlich haben wir uns für die schickste Möglichkeit mit minimaler Downtime entschieden: Die Festplatten nacheinander im RAID auswechseln. Downtime: Etwa zweimal fünf Minuten jeweils für den Austausch einer Platte. Plus ein bisschen Arbeitsaufwand, der aber im laufenden Betrieb erledigt werden kann.

Zum Nachmachen hier nun das Protokoll. Die Festplatten sind Platten nach S-ATA-Standard; stehen im System also als /dev/sda und /dev/sdb bereit. Sie haben jeweils drei Partionen, die per Software-RAID zusammengefasst sind:

# cat /proc/mdstat 
Personalities : [raid1] 
md1 : active raid1 sda1[0] sdb1[1]
      200704 blocks [2/2] [UU]
      
md2 : active raid1 sda3[0] sdb3[1]
      974550976 blocks [2/2] [UU]
      
md0 : active raid1 sda2[0] sdb2[1]
      2008000 blocks [2/2] [UU]
      
unused devices: 

Dabei fungiert /dev/md0 als Swap-Partition; /dev/md1 als /boot und /dev/md2 als Root-Partition. So, und jetzt geht’s los.

Erstmal wird kurz und schmerzlos eine der beiden Platten ausgebaut – in unserem Fall /dev/sdb, aber welche zuerst kommt, spielt keine Rolle. An ihrer Stelle wurde eine unpartitionierte Platte eingebaut. Der Server wurde wieder hochgefahren; alles kein Problem – dafür ist ein RAID1 ja da. Anschließend galt es, die neue Festplatte zu partitionieren. Das haben wir hier ganz traditionell mit fdisk gemacht und dabei für die ersten beiden kleinen Partitionen (Swap und /boot) die gleiche Zylinderzahl verwendet; die dritte Partition wurde dann entsprechend ausgeweitet. So sieht’s nun aus:

# fdisk -l /dev/sdb

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          25      200781   fd  Linux raid autodetect
/dev/sdb2              26         275     2008125   fd  Linux raid autodetect
/dev/sdb3             276      121601   974551095   fd  Linux raid autodetect

Wichtig ist, hier den korrekten Partitionstyp zu vergeben (in diesem Fall fd für Linux raid autodetect) sowie die erste Partition bootfähig zu machen.

Nun fehlt den drei /dev/md*-Devices ja die Redundanz; die stellen wir also erstmal wieder her, in dem wir mittels mdadm die frisch angelegten Partitionen hinzufügen:

mdadm /dev/md1 -a /dev/sdb1
mdadm /dev/md0 -a /dev/sdb2
mdadm /dev/md2 -a /dev/sdb3

Die ersten beiden synchronisieren in unter einer Minute; für /dev/md2 wurde gut eine halbe Stunde fällig. Mittels

watch cat /proc/mdstat

lässt sich die Synchronisation gut beobachten. Dieser Vorgang muss vollständig und fehlerfrei abgeschlossen sein, denn wir haben ja vor, gleich die Platte, von der synchronisiert wird, ebenfalls zu wechseln, und dafür muss die neu eingebaute natürlich komplett auf dem neuesten Stand sein!

Nun möchte man meinen, das wär’s, aber eine ganz wichtige Sache fehlt noch: Auch wenn die Daten jetzt wieder synchron sind, so fehlt noch der Bootloader – sprich, wenn jetzt die verbliebene Platte ausgewechselt würde, könnte das System nicht mehr booten. Es gilt also, GRUB auf /dev/sdb zu installieren, und das ist nicht ganz so einfach, wie es auf den ersten Blick scheint. Die RAID1-Redundanz liegt ja auf Partitionsebene – betrifft also nicht den Bootsektor selbst.

Der Haken an der Sache ist: GRUB führt eine device.map, in der die physischen Festplatten auf die GRUB-internen Bezeichnungen hd0 und hd1 gemappt werden. Kein Problem, solange es die zweite Festplatte ist, die ausfällt – fällt allerdings die erste aus, wird /dev/sdb als einzige verbleibende Platte plötzlich hd0 statt hd1 – und das schmeckt GRUB nun überhaupt nicht. Man kann nun in der device.map zwar beide Platten von Hand als hd0 definieren; das mag jedoch grub-install nicht und quittiert mit:

The drive (hd0) is defined multiple times in the device map /boot/grub/device.map

Es bleibt also letztlich nur, das Spiel von Hand zu spielen, und zwar so:

grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Mit anderen Worten: Man verkauft GRUB die zweite Platte als hd0, also als erste, denn wenn die echte erste Platte einmal ausfällt – dann ist die zweite Platte ja auch faktisch die erste. Das klappt prima, und das System ist bereit zum Austausch der verbliebenen kleinen Platte gegen das größere Modell. Hat man alles richtig gemacht, sollte der Server problemlos mit der einen neuen großen Platte booten (die nun ihrerseits auch nur eine Hälfte des RAID1 darstellt).

Nun sind die obigen Schritte für die verbliebene Platte, in unserem Fall /dev/sda, zu wiederholen: Partitionieren; mittels mdadm zum RAID1 hinzufügen; GRUB von Hand in den Bootsektor packen.

Nun haben wir einen Server mit neuen Festplatten, bei denen die Root-Partition deutlich größer ist, aber bisher haben wir davon noch nichts – es fehlen noch zwei entscheidende Schritte. Zunächst muss die Partition /dev/md2, die jetzt nur noch einen Bruchteil des physisch vorhandenen Speicherplatzes nutzt, auf die neue Größe ausgedehnt werden. Das erledigen wir mit:

mdadm --grow -z max /dev/md2

Hiermit wird für den zusätzlichen Speicherplatz ein Resync angestoßen – sprich, dieser Vorgang zieht sich eine ganze Weile, zumal wir ja hier auf Terabyte-Platten aufgerüstet haben. Im konkreten Fall mussten wir rund zwei Stunden dafür einkalkulieren.

Nun sind wir aber immer noch nicht fertig. Zwar ist das Device jetzt endlich so groß, wie wir es haben wollen, aber das Dateisystem weiß davon noch nichts – und das muss schließlich die neu hinzugekommenen Blöcke auch ansprechen können.

Erfreulicherweise gibt es seit einigen Jahren die Möglichkeit, ein ext2-/ext3-Dateisystem im laufenden Betrieb, sprich: im gemounteten Zustand zu vergrößern. Bei CentOS 4, das auf diesem Server noch läuft (kein Problem, wird ja noch bis Anfang 2012 supportet), übernimmt diesen Job noch ext2online; bei neueren Distributionen ist der Live-Resizing-Code in resize2fs aufgegangen, das bis dahin nur eine Größenanpassung von nicht aktiv verwendeten Devices realisierte. Auf geht’s:

ext2online -v /dev/md2

Der Vorgang zieht sich ein bisschen, aber man kann sehr schön beobachten, wie sich die Größe im laufenden Betrieb ändert – und sich der prozentuale Füllstand der Root-Partition entsprechend nach und nach verringert:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              178G  123G   46G  73% /
/dev/md1              190M   15M  166M   8% /boot
none                  505M     0  505M   0% /dev/shm

… warten …

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              203G  123G   69G  65% /
/dev/md1              190M   15M  166M   8% /boot
none                  505M     0  505M   0% /dev/shm

… warten …

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              213G  123G   79G  62% /
/dev/md1              190M   15M  166M   8% /boot
none                  505M     0  505M   0% /dev/shm

Wenn dieser Vorgang abschlossen ist – war’s das. Viel Spaß mit dem neu hinzugewonnenen Speicherplatz!

Bevor man das RAID anfaßt

Freitag, 26. März 2010

Nur eine Anmerkung zu dem Bericht meines Kollegen Jonas über die Rettung eines RAID 5:

Ich war mal mit einem RAID 10 in einer ganz ähnlichen Situation, ich hatte kein aktuelles Backup der Daten auf dem RAID und ich konnte leider auch keine Images der Platten im RAID mehr ziehen, um bei einem gescheiterten Reparaturversuch nötigenfalls den Versuch rückgäng zu machen. Es ging auch nicht nur um ein paar Photos, sondern leider um ziemlich wichtige Daten. Ich war also sehr auf Vorsicht bedacht.

Wie schon gesagt war die Situation ganz ähnlich. Ich war mir sehr sicher, daß die Daten auf den Platten noch konsistent waren, aber die Superblöcke wollten partout nicht zusammengehen. Auch ich bin damals auf den Hinweis gestoßen, daß man das RAID auch quasi neu anlegen kann und so wieder zu intakten Superblöcken kommen kann. Aber da ich mir Fehler nicht leisten konnte, zögerte ich etwas mit der Umsetzung.

Und dann hatte ich eine Idee, die letztlich auch funktioniert hat: Man kann sich auf einem anderen Rechner mit Linux auf dem man LVM eingerichtet hat (in diesem Fall war das eine gerade nicht gebrauchte Workstation, auf der im LVM noch viel Platz war) einfach ein paar Logical Volumes einrichten und damit einen RAID einrichten. Natürlich ist ein RAID über Logical Volumes auf derselben Festplatte vollkommen sinnfrei und absolut inperformant, aber es eignet sich hervorragend um das Verhalten von mdadm zu testen. Ich hab mir also vier LVs angelegt, darüber einen RAID 10 erzeugt, darin ein Dateisystem angelegt und einfach ein paar Nutzdaten reinkopiert: eine größere Logdatei, eine MP3, einen Film. Dann habe ich das Dateisystem wieder ausgehängt und den RAID bewußt beschädigt — und zwar so daß derselbe Fehlerzustand hergestellt wurde wie auf dem “echten” RAID 10. Ich konnte dann die Reparatur in aller Ruhe testen, man könnte sogar sagen üben, und nach erfolgreicher Reparatur des Test-RAIDs wunderbar verifizieren, ob die Daten in dem Dateisystem noch stimmten.

Das beste daran war, daß mdadm eben wirklich nicht auf das neu angelegte RAID schreibt, solange man es in degradiertem Zustand anlegt. D.h. ich konnte mir sogar mehrere Fehlversuche leisten. (Bei einem RAID 10 nicht unwahrscheinlich, man muß ja die korrekte Anordnung der Festplatten finden.) Ob das RAID korrekt zusammengefügt war hab ich jeweils damit getestet, ob ich das Dateisytem darin im Read Only Modus mounten konnte oder nicht.

Ein weiterer Vorteil dieser LVM Testumgebung: Man kann sich mit LVM wunderbar Snapshots der LVs anlegen. Wenn man dann bei den Reparaturversuchen tatsächlich etwas beschädigen sollte (kam mir damals nicht vor, aber es hätte ja), dann kann man seine Testumgebung schnell wieder in den Ausgangszustand zurückversetzen und muß sie nicht komplett neu anlegen.

Wenn sonst nichts mehr beim kaputten RAID5 hilft

Donnerstag, 25. März 2010

Ein Kundeskunde ist stolzer Besitzer einer Synology CubeStation. Das sind kleine NAS-Server für daheim, auf Linux-Basis mit einem proprietären Webinterface, aber immer noch mit einer Shell. Je nach Modell sind unterschiedlich viele Platten verbaut; hier konkret vier. Jede Platte hat drei Partitionen, wobei die ersten beiden kleineren jeweils ein kleines RAID1 für die Root- bzw. Swap-Partition darstellen (und hier ergo dreifache Redundanz haben); die jeweils dritten – großen – Partitionen sind zu einem RAID5 ohne Spare zusammengefasst, das als /volume1 gemountet wird, was bei den Synology-Boxen offensichtlich für die eigentliche Ablage von Daten benutzt wird.

Eine der Platten ging kaputt. Kein Problem, dafür hat man ja das RAID. Beim Ausbau der defekten Platte wurde allerdings offensichtlich das Stromkabel einer der weiteren Platten gelockert. Wir wissen nicht genau, was passiert ist, aber der Zustand war der, dass die ersten beiden RAIDs problemlos zusammengesetzt werden konnten; das dritte aber nicht. /dev/sda3 und /dev/sdc3 waren da, /dev/sdb3 fehlte (weil ausgebaut), und /dev/sdd3 – die Platte mit dem Wackelkontakt am Strom – hatte zwar einen md-superblock, der aber nicht mit den anderen harmonierte. Zwar stimmte die UUID; allerdings war der Update-Timestamp nicht ganz synchron. Ein

mdadm --assemble /dev/md2 /dev/sd[acd]3

schlug von daher fehl. Nun ist das an sich kein großes Problem: Man kann mdadm einfach zwingen und die md-superblocks dann wieder neu schreiben. Also:

mdadm --assemble --force /dev/md2 /dev/sd[acd]3

Denkste. Zwar bereitet sich mdadm schon korrekt vor und informiert darüber, dass es den abweichenden update count der dritten Partition anzupassen gedenkt. Dann jedoch stirbt es mit einem Segmentation Fault.

Offensichtlich ein bekanntes Problem. Und zwar nicht spezifisch für die Syno-Box; auch der Ubuntu-Bugtracker findet:
mdadm seg faults when forced to assemble array. Das Problem scheint also spezifisch für mdadm 2.6.7 zu sein – schon bei der 2.6.7.1 soll es angeblich wieder gehen.

Nun ist auf der Syno-Box aber eben die 2.6.7 – und ein Update ist nicht in Sicht. Was also tun? Mein erster Gedanke dazu (und ich bleibe dabei, so schlecht war er nicht): IPKG installieren, und darüber dann eine hoffentlich wahlweise ältere oder neuere Version von mdadm installieren, die diesen Bug nicht hat. Und wenn’s keine gibt, bliebe immer noch die Möglichkeit, über IPKG einen Compiler zu installieren und mdadm 2.6.7.1 aus den Sourcen zu kompilieren.

Es gibt ein mdadm in IPKG. Ein 2.6 – also älter. Nur behauptet /opt/sbin/mdadm --examine (also das via IPKG installierte, im Gegensatz zum vorinstallierten /sbin/mdadm) bei allen Partitionen, dort keinen md-superblock vorzufinden. Hm, vielleicht zu alt? Also doch die Variante mit dem Compiler, und dann ein mdadm aus den Sourcen kompiliert. Noch eine neuere Version genommen. Und dann noch eine. Und noch eine ältere. Aber es half nichts: Alle Versionen fanden keinen md-superblock. Nicht mal eine aus den Sourcen kompilierte 2.6.7, obwohl das doch nun die identische Version zur offiziell installierten ist.

(Gängige Reparaturanleitungen empfehlen, die Platten aus der Syno in einen normalen PC zu bauen – wofür man erstmal entsprechend viele freie SATA-Ports bräuchte – und dann dort den Superblock von der little-endian-Byteorder der ARM-CPU der Syno auf big endian einer Intel-CPU zu ändern, damit das RAID auf einem Intel-PC wieder zusammengesetzt werden kann. Mein Bauchgefühl sagt mir, dass das Problem mit den überhaupt nicht mehr erkannten md-superblocks etwas damit zu tun haben könnte. Allerdings habe ich das mdadm ja auf der Syno kompiliert, also auch mit deren Headerfiles. Insofern müsste die Byteorder eigentlich stimmen. Hm.)

Lange Rede, kurzer Sinn: Nichts half. Bis auf das RAID-Wiki bei kernel.org, das den entscheidenden Tipp gab:

When an array is created, the data areas are not written to, *provided* the array is created in degraded mode; that is with a ‘missing’ device.

Ich denke, man kann sich das in etwa so vorstellen wie eine defekte Partitionstabelle auf einer Festplatte: Es scheint alles weg; keine Partition ist mehr lesbar. Dabei ist klar, dass die Daten an sich alle noch auf der Platte vorhanden sind – man kommt nur ohne Partitionstabelle nicht mehr dran. Man muss es also “nur” schaffen, die paar Bytes Partitionstabelle wiederherzustellen, und das Problem ist gelöst.

So auch hier: Wird bei einem mdadm --create ein Device als “missing” angegeben, wird der Datenbereich der Platten in Ruhe gelassen und nur der Superblock neu geschrieben. Das ist natürlich nur was für echte Männer. Naja, oder für Männer wie mich, die sich vorher versichert haben, dass der Kunde Images der Platten gesichert hat, falls bei den Arbeiten am RAID irgendetwas schief geht. Auf jeden Fall muss man für so ein “Reparatur-create” allerdings wissen, wie dieser Superblock auszusehen hat: Welcher RAID-Level? Wieviele Platten? Welche Platte in welchem RAID-Slot? Welche Chunk-Size? Welche Symmetrie? Das war in diesem Fall einfach: Alle drei Partitionen haben ja schließlich noch einen md-superblock, der all diese Parameter verrät. Letztlich war es also nur das hier:

mdadm --create /dev/md2 --chunks=64 --level=5 --raid-devices=4 \
  /dev/sda3 missing /dev/sdc3 /dev/sdd3

mdadm bemerkte korrekt, dass auf den Partitionen bereits etwas drauf sei, was nach einem RAID riechen würde. Okay, wissen wir ja. Nach einer entsprechenden Bestätigung wurden die Superblocks neu geschrieben. Keine Fehlermeldung. Ein

mount /dev/md2 /volume1

funktionierte anstandslos. Alle Daten vorhanden; auch nach einem Reboot erkennt die Syno-Box das RAID5 jetzt wieder von selbst und bindet es ein. Nach einer jetzt natürlich umgehend anstehenden Datensicherung wäre es von daher im Bereich des Möglichen, nun wieder die vierte, noch fehlende Platte einzubauen und einen Resync zu wagen.

Mein Kunde berichtet vom Kundeskunden, dieser sei “grad total hingerissen davon (echt jetzt)”. Schöne Sache, wobei es hier weniger um ein geschäftliches Desaster gegangen wäre, sondern “nur” etliche Gigabyte an Fotos über den Jordan hätten gehen können. Aber die sind manchmal ja noch viel wertvoller. Ich gehe davon aus, ab heute macht der Kundeskunde Backups.

Angeschossen? Abgeknallt!

Samstag, 14. November 2009

Für einen Kunden adminstrieren wir einen Server, den er sich selbst bei Anbieter S gemietet hat. S ist einer der Großen der Branche; einer von denen, die in die c’t immer bunte Prospekte einlegen lassen, also nicht gerade ein Wald-und-Wiesen-Provider.

Da der fragliche Server mit einem Software-RAID1 bereitgestellt wird, fragen wir per Nagios regelmäßig den mdadm-Status ab, um rechtzeitig bei Plattenproblemen informiert zu werden. Vor wenigen Tagen war es dann leider auch tatsächlich soweit: Das RAID1 ist degraded, eine Platte fehlt. Da wir auf die Hardware keinen Zugriff haben, vereinbarten wir mit dem Kunden, dass wir uns direkt mit S in Verbindung setzen, um die defekte Festplatte auswechseln zu lassen – im Rahmen unserer Wartungsverträge mit Kunden, die bei externen Providern hosten, ist das für uns selbstverständlich.

Der Anruf bei der Hotline von S verlief jedoch gänzlich anders als erwartet. Ich versuche es mal aus dem Gedächtnis wiederzugeben und bitte für leichte Anpassung in der Dramaturgie um Verständnis – inhaltlich hat das Telefonat wirklich so stattgefunden.

Hotline: “Anbieter S, Kundenservice, guten Tag!”

Ich so: “Guten Tag! Bei einem Server, den wir für einen Ihrer Kunden warten, ist eine Festplatte ausgefallen. Das Gerät läuft aber noch, da es ein RAID1 hat. Wie schnell können Sie denn da die Festplatte tauschen? Geht das per Hot-Swap im laufenden Betrieb, oder muss da eine kurze Downtime erfolgen?”

Er so: “Nein, die Festplatte wechseln wir nicht aus. Wir stellen Ihnen einen neuen Server bereit.”

Ich so: “Ääääh … aber es ist doch nur eine der beiden Festplatten kaputt. Der Server an sich läuft ja noch …”

Er so: “Das ist egal. Wenn es Hardwareprobleme gibt, bekommen Sie einen neuen Server.”

Ich so: “Wieso tauschen Sie denn nicht einfach die defekte Platte aus und dann ist alles wieder gut?”

Er so: “Nein, sowas machen wir grundsätzlich nicht. Sowas macht überhaupt kein Internetprovider. Höchstens ein kleines Systemhaus.”

Ich so: “Entschuldigung, aber da muss ich Ihnen widersprechen. Wir betreuen im Kundenauftrag auch noch Server bei H1, H2 und bei P, und bei allen gab es im Lauf der Jahre auch schon mal Festplattenschäden. Ich kann Ihnen versichern: Jeder dieser Anbieter [nebenbei allesamt in der Liga von S] hat anstandslos die defekte Festplatte ausgetauscht, und dann lief das RAID1 wieder.”

Er so: “Das kann ich mir nicht vorstellen. Vielleicht früher mal. Versuchen Sie das heute mal. Das wird Ihnen keiner machen.”

Ich so: “Selbst wenn Sie Recht hätten: Ist denn der Umstand, dass andere Anbieter schlechten Service bieten, für Sie Entschuldigung genug, um auch selbst schlechten Service zu bieten?”

Er so: “Ich verstehe Sie nicht. Sie bekommen doch einen ganz neuen Server. Das ist doch gut für Sie!”

Ich so: “Nehmen wir das mal so hin. Wie wäre denn dann der Ablauf; wie gehen wir strategisch am Besten vor?”

Er so: “Sie versetzen Ihren bisherigen Server in den Neuinstallationsmodus und geben uns dann Bescheid. Wir stellen Ihnen dann den neuen Server bereit.”

Ich so: “Und was ist mit den Daten des Servers?”

Er so: “Ich verstehe die Frage nicht.” [Kein Scherz! Das hat er wirklich gesagt!]

Ich so: “Naja, wenn Sie einen neuen Server bereitstellen, dann ist der ja erstmal nur mit dem nackten Betriebssystem installiert. Wie kommen denn die Daten von dem alten Server auf den neuen? Oder kopieren Sie die gleich mit rüber?”

Er so: “Welche Daten? Wenn Sie den alten Server in den Neuinstallationsmodus versetzen, dann werden alle Daten von der Festeplatte gelöscht. Insofern sind da ja keine Daten mehr zum Übertragen auf den neuen Server.”

Ich so: “Ach so, dann stellen Sie uns den neuen Server doch einfach vorab bereit, wir kopieren die Daten rüber, und wenn alles drüben ist, können Sie den alten Server abschalten.”

Er so: “Nein, das geht nicht.”

Ich so: “Bitte? Wieso das denn nicht?”

Er so: “Der neue Server bekommt ja die gleiche IP-Adresse. Wissen Sie, es kann grundsätzlich nicht zwei Server mit der gleichen IP-Adresse geben, das geht einfach technisch nicht.”

Ich so: “Stellen Sie sich vor: Das weiß ich. Aber Sie können ihm ja einfach vorübergehend eine andere, temporäre IP geben, damit wir die Daten übertragen können, und danach wird jene IP wieder freigegeben.”

Er so: “Nein, das können wir nicht machen.”

Ich so: “Dann verraten Sie mir doch bitte mal, wie ich die Daten vom alten auf den neuen Server bekommen soll, wenn der neue Server noch nicht da ist, während der alte noch läuft, und wenn der alte dann weg ist, sobald der neue Server läuft!”

Er so: “Sie können ja den bereitgestellten Backup-Speicherplatz benutzen, der bleibt ja bestehen.”

Ich so: “Ich muss also ein paar Dutzend Gigabyte per FTP auf einen anderen Server kopieren, was Stunden dauern wird, dann muss ich Ihnen Bescheid geben, dass Sie einen neuen Server bereitstellen, was Stunden dauern wird, dann darf ich das Betriebssystem von Hand wieder zurechtfrickeln, was Stunden dauern wird, weil das System, das damals installiert wurde, heute gar nicht mehr zur Installation angeboten wird, und dann darf ich die gleichen paar Dutzend Gigabyte wiederum per FTP zurückkopieren, was nochmals Stunden dauern wird?”

Er so: “Ja, das ist das normale Vorgehen in diesem Fall. Dieses Vorgehen ist das Ergebnis unserer internen Prozessoptimierung und Qualitätssicherung.” [sic!]

Ich so (erregt): “Haben Sie eine Vorstellung davon, wieviele Stunden an Downtime das bedeuten wird, um ein Problem zu beheben, das jeder Ihrer Konkurrenten innerhalb einer Downtime von höchstens zehn Minuten lösen könnte? Wie kann das denn bitte ein Ergebnis von Prozessoptimierung sein?”

Er so: “Beim Austausch von einzelnen defekten Festplatten gibt es einfach zuviele Probleme.”

Ich so: “Im Moment machen eher Sie mir Probleme und nicht die defekte Festplatte. Können Sie mir denn dann bitte sagen, wofür Sie überhaupt ein RAID1 in diesen Server bauen, wenn Sie dann bei dem Problem, für das ein RAID1 einen Workaround bietet, nämlich den Ausfall einer Festplatte zu kompensieren, dann gleich dem ganzen Gerät den Gnadenschuss verpassen? Dann hätten wir uns das RAID1 ja auch gleich sparen können.”

Er so: “Nein, denn dann wäre der Server sofort ausgefallen und Sie hätten unter sofortigem Handlungsdruck gestanden. So können Sie sich den Zeitpunkt frei aussuchen, wann Sie die Neueinrichtung machen wollen, also eben dann, wenn es Ihnen gelegen kommt.”

Ich so: “Das RAID1 ist nur dazu da, dass ich mir den Zeitpunkt der stundenlangen Downtime selbst aussuchen kann, wann immer es mir, ich zitiere: “gelegen” kommt? Ist das ihr Ernst?”

Er so: “Ja, genau.”

Ich so: “Ihnen ist aber doch klar, dass das Internet 24 Stunden täglich geöffnet hat und eine mehrstündige Downtime immer ungelegen kommt? Auf dem Server läuft ein Onlinespiel, das rund um die Uhr aktiv genutzt wird!”

Er so: “Also, die meisten unserer Kunden finden es gut, einen ganz neuen Server zu bekommen.”

Ich so: “Ja und? Offensichtlich haben die meisten Kunden keine wirklich wichtigen Sachen auf den Servern bei Ihnen. Dass ein einzelner Server keine hochverfügbare Lösung ist, ist natürlich klar, aber wir haben uns absichtlich einen Server mit RAID1 ausgesucht, um der wahrscheinlichsten Ausfallursache eines Servers, nämlich einer defekten Festplatte, entgegentreten zu können. Und nun machen Sie dies völlig zunichte, in dem Sie ohne Not eine stundenlange Downtime provozieren, die für uns mit jeder Menge Arbeit verbunden ist, nicht zuletzt für den darauf folgenden zu erwartenden Support. Gibt es da wirklich keine andere Möglichkeit?”

Er so: “Nein, die gibt es nicht.”

Es hat unsererseits gar keiner Empfehlung für diesen Schritt bedurft – unser Kunde kündigt den bei S betriebenen Server  von sich aus. Und für uns bleibt es unterm Strich ein lehrreiches Beispiel dafür, wie wir uns von Providern abgrenzen, für die “Prozessoptimierung” wichtiger ist, als die für den Kunden optimale Lösung zu finden – und dafür dann eben auch mal einen Finger mehr krummzumachen. In diesem Sinne sind wir stolz darauf, in den Augen von S “höchstens ein kleines Systemhaus” zu sein.


Impressum