Kommentare zu: Lob des Backups

Von: Axel Eble

Axel Eble — Fri, 28 Sep 2012 10:13:39 +0000

Ja, uns beißen Ausfälle auch immer da, wo wir nichts dran drehen können. Mal fallen zwei von drei Phasen Strom aus, mal bleibt irgendetwas halb am Leben anstatt komplett auszufallen – 100% Absicherung ist halt nie. Schade nur, dass die ganzen Verrenkungen mit Redundanz die eigentlichen Probleme nicht abfangen :)

Von: Jonas Pasche

Jonas Pasche — Sun, 26 Feb 2012 14:46:31 +0000

Im Grunde meine ich mit Umbau/Zurückbau die gleiche Sache: „Zurückbauen“ in dem Sinne, dass wir versuchen, die Instanzen, die nach wie vor auf dem Storagecluster laufen, Stück für Stück ebenfalls in Standalone-Cluster zu migrieren – mit dem Ziel, den Storagecluster irgendwann in nicht allzu ferner Zukunft ausstellen zu können. Das sind halt hardwaretechnisch „Monster“, viele Platten, laut (okay, das ist im Rechenzentrum relativ egal), tonnenschwer und auch von der Leistungsaufnahme her nicht ganz ohne. Soll heißen, das ist eigentlich nur dann interessant, wenn man sie wirklich als Ersatz vieler Standalone-Plattensysteme verwenden kann, was im Prinzip auch viel effizienter wäre. Nur haben sich eben unsere Erwartungen an die Performance des Storageclusters in der Realität nicht in dem Maße erfüllt, wie wir uns das gedacht hatten, auch nach Aufrüstung um mehrere NICs nicht. Insofern befindet sich der Cluster derzeit in einem Zustand, wo schon Einiges weggezogen ist und dadurch die verbliebenen Hosts wieder angenehm flott darauf laufen – aber die opulente Storage-Hardware damit in keinster Weise so ausgelastet ist, dass der Betrieb irgendwie „wirtschaftlich“ wäre. Nun ja, auch wir lernen dazu.

Von: Tim

Tim — Sun, 26 Feb 2012 14:21:04 +0000

Hallo Jonas,
danke für die flotte, ausführliche und sogar mir verständliche Antwort! :)

Mir ist jetzt allerdings nicht klar geworden, was ihr nun mit dem Storage Cluster machen wollt – du sprichst einmal von „zurückbauen“ (= die Maschinen Stück für Stück mit eigenen Festplattensystemen ausstatten) und einmal von „umbauen“ (= ?).

Ich halte das Prinzip ebenfalls für eine „ziemlich coole Sache“, das Blog hier ist übrigens auch super. Habe jeden Artikel gelesen.

Grüße

Von: Jonas Pasche

Jonas Pasche — Sun, 26 Feb 2012 12:24:00 +0000

In diesem konkreten Fall werden wir dem Kunden vorschlagen, statt Nutzung unseres Storageclusters stattdessen auf eingebaute Festplatten in den beiden Knoten zu wechseln – natürlich auch jeweils mittels RAID gespiegelt, und hier dann mit einem lokalen DRBD drüber. Die Kosten für den entsprechenden Umbau und die Nachrüstung lokaler Festplatten übernähmen dabei natürlich wir.

Es ist ansonsten halt schwierig, wirkliche „Lehren“ aus dem Vorfall ziehen zu können, denn auch nach intensivem Austausch und noch einiger Überprüfungen konnte die Ursache von uns nicht ermittelt werden. Einerseits ist es zwar kein Anlass zu hektischem Aktionismus, wenn auf einem Storage-Cluster, der seit mehreren Jahren ausfallfrei läuft und einige Dutzend Volumes via iSCSI exportiert, mal ein Problem auftritt, auf der anderen Seite senkt es natürlich das „Grundvertrauen“ in eine bestimmte Technologie, die wir bisher für uns in allen Tests und dann auch in produktivem Betrieb eigentlich als „rock-solid“ erlebt hatten. Da wir aber auch aus anderen Gründen dabei sind, den betreffenden Storage-Cluster „zurückzubauen“ (nicht aufgrund von strukturellen Problemen, sondern weil die anfänglich sehr gute Performance beim verstärkten Einsatz ziemlich verschlechtert hat, obwohl wir mehrere mehrere dedizierte NICs verbaut haben, um den IO-Traffic zu separieren), ist dieser Vorfall für uns eher noch ein weiteres Argument, diesen Umbau voranzutreiben – auch wenn wir das zugrundeliegende Setup mit plattenlosen Hosts, die via gPXE vom Cluster booten und dabei auch ihr Root-Device via iSCSI erhalten, nach wie vor für eine ziemliche coole Sache halten.

Von: Tim

Tim — Sat, 25 Feb 2012 23:59:15 +0000

„Die Lehren, die ggf. aus diesem Vorfall zu ziehen sind, werden wir dann am Montag im Teammeeting besprechen.“
Na dann schieß mal los. :D Würde mich echt sehr interessieren. :)

Von: Sebs

Sebs — Sun, 12 Feb 2012 19:36:41 +0000

Genau mit solchen Posts erschleichst du dir die „credibility“ die wohl einige meiner Freunde zu euch treibt und auch meine nächste Empfehlung uberspace lauten lassen wird. Mal nicht zu wissen was passiert ist gehört auch dazu.

Von: Jonas Pasche

Jonas Pasche — Sat, 11 Feb 2012 13:16:26 +0000

Das ist leider nicht so ohne weiteres möglich, da wir DRBD hier ganz konventionell in einer Active-/Passive-Konstellation einsetzen und wir hier leider nur zwei große DRBD-Devices haben, die dann jeweils mittels LVM eine Volume Group und darauf dann entsprechend viele Volumes für die einzelnen Xen-Instanzen haben. Insofern ist das DRBD-Device auf dem anderen Host – da Secondary – nicht ansprechbar, und ein Failover nur dieses einen Volumes nicht machbar. Es bliebe von daher aus meiner Sicht maximal, direkt auf das zugrundeliegende Blockdevice auf dem Secondary (lesend) zuzugreifen, sozusagen unter DRBD durch. Das ist mir allerdings im Moment ehrlich gesagt etwas arg viel manueller Aufwand – zumal ich daraus dann auch keinen Erkenntnisgewinn ableiten könnte, woran genau es denn nun lag, dass auf einer Seite der Replikation plötzlich „alles weg“ war. DRBD ist an sich loggingmäßig ja – erfreulich – geschwätzig, hat hier auf den konkreten Systemen aber keine Silbe im Log hinterlassen.

Von: Daniel

Daniel — Sat, 11 Feb 2012 13:06:39 +0000

Interessanter, gut geschriebener Artikel.
Hattest Du auf dem DRBD-Slave auch mal auf die Platten geschaut? Da nur genau ein LVM Volume betroffen war, müsste der Fehler wohl auch oberhalb dieser Schicht passiert sein und dementsprechend auch repliziert worden sein, aber nachgucken würd ich ja trotzdem mal.