GlusterFS: Hat damit jemand Erfahrung?

[Localhorst]

Hallo Leute,

man merkt erst beim GAU, was man alles so beachten muss Ich hatte bereits in einem anderem Thread geschrieben, dass ich auf Hetzner einen Root laufen lasse mit ESXi, dort wird in jeder VM einzeln verschiedene Dienste bereitgestellt (HTTP, E-Mail etc.) Jetzt ist gestern Abend eine HDD des Servers verreckt, die Platte wo die E-Mail VM draufliegt. Demzufolge habe ich seit über 12 Stunden keinen E-Mail Server und verpass so einige Mails Backup ist da und wird auch bald eingespielt, sodass ich wieder E-Mail technisch erreichbar bin. Doch dann fiel mir erst auf, ich hätte einen zweiten E-Mail Server einrichten sollen um eine Fallback zu haben. Wie gesagt, an sowas denkt man erst wenn es passiert.

Der E-Mail Server wurde ganz einfach mit iRedAdmin und der MySQL Datenbank realisiert. Wenn ich jetzt einfach bei einem anderen Anbieter nen vServer miete, dort iRedAdmin genauso einrichte und einen zweiten DNS Eintrag mache habe ich zwar nen zweiten Server, aber ihm fehlen ja die Daten des ersten (sozusagen den Master) Im Laufe meiner Recherche bin ich auf GlusterFS gestoßen. Die Theorie ist ja denklich einfach: Ich erstelle ein Volume, dass auf beiden Servern gespiegelt wird, und wenn der eine Ausfällt greift ja der andere Server auf die Maildaten zu.

Deshalb meine Frage: Habt ihr schonmal soetwas gemacht? Wenn ihr eure eigenen Mails hostet, setzt ihr da auch auf zwei Server oder passt euch dann eine Downtime zu haben?

Besten Dank schonmal!

MfG

Localhorst

 

[Metal_Warrior]

@Localhorst:
Mal ne Gegenfrage: Wieso bist du überhaupt bei einem Hardwareausfall betroffen? Warum ist die Hardware nicht redundant ausgelegt? Am falschen Ende gespart?

 

[Localhorst]

@Metal_Warrior: Ich weis es selber nicht wieso jetzt der ESXi solche zicken macht. Ich kann probieren was ich will, der vSphere Client stürzt immer wieder ab. Ich hatte gestern Abend eine Fehlermeldung im ESXi, der sagte das die Verbindung zu sda verloren ging. Und seit diesem Reboot will halt gar nichts mehr ...

 

[Metal_Warrior]

@Localhorst:
Du missverstehst mich an der Stelle: Ein Ausfall von /dev/sdX sollte bei einem vernünftig aufgesetzten Serversystem keinerlei Probleme machen. Mail an $SYSADMIN und mehr nicht. Man sollte Speicher bei Hochverfügbarkeitssystemen immer redundant betreiben, oder so redundant wie möglich (zwei HDDs an zwei Controllern, beide über RAID1 gespiegelt etc.). Wenn bei mir ne HDD ausfällt, ist das Schlimmste, was passieren kann, dass /boot neu geschrieben werden muss (weil ich keine Möglichkeit kenne, das in einem RAID unterzubringen - Henne-Ei-Problem). Vielleicht solltest du dir erstmal überlegen, wie du mdadm richtig einrichtest, bevor du mehrere virtuelle Maschinen wild verknüpfst, die am Ende stehen und Fallen mit dem Single Point of Failure namens Speicherhardware.

Mein Vorschlag: RAID5+1 unterm Grundsystem, /boot jeweils auf die 3 anderen aktiven Platten kopiert (per Cronjob zum Beispiel). Dann macht dir der Ausfall einer Platte gar nix, selbst wenn zwei Tage später die zweite den Geist aufgibt und zwischendurch die Hardware nicht getauscht werden konnte. Dann kannst du dir nämlich auch dein Zauberkunststück mit der zweiten VM sparen.

 

[Localhorst]

@Metal_Warrior: Die Variable $SYSADMIN kenne ich ja: Mich! Oder meinste nun Hetzner?

Spaß beiseite, ja Metal ich kann mir den Schuh anziehen da nicht wirklich mitgedacht zu haben. Mein Root Server ist da ein EX40 @32 GB RAM und 2 HDD mit jeweils 3 TB. RAID wurde da nicht angeboten. Als OS habe ich da VMWare ESXi 5.1 drauf. Ich hätte die zwei Platten als Software-RAID 1 einrichten können. Aber da habe ich (jetzt zurecht gesagt) am falschen Ende gespart und wollte da keine Redundanz haben. Jetzt habe ich ja den Salat: Die HDD auf der der ESXi installiert ist spackt nun herum. Was dazu führt, dass einzelne VM einfach nicht mehr starten, u. a. der Mail Server. Da ich nur 2 Platten habe, kann ich das RAID 5+1 Konstrukt vergessen.

Meine Idee ging eher dahin auf, bei einem anderen Anbieter einen kleinen vServer zu mieten, der als Fallbacklösung für den E-Mail Server dient. Da muss ich aber auch die E-Mails synchronisieren und das wollte ich mit GlusterFS realisieren. Ich weis ja, dass ich Admin technisch einfach Mist gebaut habe, jedoch benutze ich das glücklicherweise nur zum privatgebrauch und schädige damit niemanden, außer mir selbst Ich muss jetzt nur aus dem Ausfall lernen und mir was neues überlegen.

 

[Metal_Warrior]

@Localhorst:
Wie gesagt, in meinen Augen ist das Rumgefrickel, in etwa so als würde man eine Brücke planen, während der Simulation feststellen, dass Autos runterfallen können, wenn unten jemand gegen den Pfeiler fährt und statt einfach ein paar Pfeiler mehr zu bauen, eine zusätzliche Hängekonstruktion plant, welche die Fahrbahn stützt, wenn ein Pfeiler nachgibt, und das zudem noch von einer neuen Brücke direkt darüber. Völliger Unsinn.

Rede doch mal mit Hetzner, lass dich beraten. Vielleicht hast du an dieser Stelle einfach das falsche System und Setup gewählt. Lass dir nen Debian drauf installieren, gib fünf Euro für ne zusätzliche Festplatte aus, bau ein RAID5 - auf Deutsch: Stell dein Grundsystem auf solide Füße. Füße, die dir erst wegbrechen, wenn die APU, das Mainboard oder der RAM abkackt, aber deine Daten sicher verwahren. Ich denke, das kommt dir billiger. Bei den Servern, die ich hier so verwalte (sind nur 5 Stück, aber immerhin), hab ich das exakt so gemacht. Ausfälle bislang nur, wenn der Strom ausfällt (und selbst da hab ich bei einem ne USV für den ganzen Schrank nachgerüstet) oder wenn die Basishardware abraucht. Ausfallende Festplatten sind bei mir nur Grund für ne Mail, dann wird ne neue gekauft, alte raus, neue rein, zwei Kommandos über SSH und der Rebuild beginnt. Die "Kunden" merken davon gar nichts. Und genau das möchtest du ja: Ein solide funktionierendes System, das Ausfälle hinsichtlich Hardware weitestgehend problemfrei wegstecken kann. Virtualisieren kannst du hinterher immer noch.

 

[drfuture]

in dem Preissegment wird immer mit einem SoftwareRaid "gerechnet" ... im Grundsystem war vermutlich auch eins Installiert *g*
Es sind ja extra 2x 3TB eingebaut - genau die sollten per Raid1 gespiegelt werden - was nur vermutlich nicht im ESXi geht ....
Einen Hardware-Controller bietet Hetzner für 15€ im Monat an https://www.hetzner.de/de/hosting/produkte_rootserver/flexipack was ich aber recht teuer finde....

 

[Metal_Warrior]

@drfuture:
Ein Hardware-RAID ist in meinen Augen auch nicht nötig und schadet im Privatbereich eher als dass es nützt. mdadm braucht nur Bruchteile eines Prozents der derzeitigen Prozessoren für ein Software-RAID, das hinterher zudem jederzeit mit wenigen Schritten ohne Downtimes bearbeitet (shrink, grow, zusätzliche Festplatten etc.) werden kann und letztlich sogar von der Funktionsfähigkeit der Controller-Hardware unabhängig agiert. D. h. raucht dir der Controller ab, kannst du jederzeit einen x-beliebigen anderen/neueren Controller verwenden und bist nicht darauf angewiesen, dass der Controller die Initialisierung des Vorgängers erkennen und weiter verwenden kann. Diese Flexibilität möchte ich ehrlich gesagt unter keinen Umständen missen.

 

[drfuture]

@Metal_Warrior: Grundsätzlich hast du da schon recht - aber der ESXi ist ja ein eigenes mini-OS das als Hypervisor funktioniert... und ich *glaube* dort kann man kein Softwareraid erstellen / betreiben...
Wenn das anders ist dann würde ich auch klar sagen SoftwareRAID

 

[Polii]

... gib fünf Euro für ne zusätzliche Festplatte aus, bau ein RAID5

Oder einfach die Platten behalten und ein RAID1 machen.

 

[Metal_Warrior]

aber der ESXi ist ja ein eigenes mini-OS das als Hypervisor funktioniert...

Was mich immer wundert an dieser Stelle ist die falsche Herangehensweise an Probleme. Es macht überhaupt keinen Sinn, jeden Furzkack zu virtualisieren. Natürlich ist es super, wenn man ein "Spielsystem" braucht, oder eins für bestimmte Programme, aber mir geht nicht in den Schädel rein, wie man eine vertrauenswürdige Serverstruktur aufbauen will, indem man alles virtualisiert (Clustersysteme und Rechenzentren mal ausgenommen, da geht's ja um Scaling). Der vorliegende Fall zeigt doch ganz deutlich, dass die VMs so toll sein können, wie sie mögen, wenn der Hypervisor oder die zugrundelegende Hardware einfach den Geist aufgeben. Es ist doch nichts vertrauenswürdiges an einem Setup, in dem ich einen künstlichen weiteren Single Point of Failure einbaue:

SPoF vorher: Prozesshardware (also APU, RAM, Mainboard, Controller), Speicherhardware (HDDs, SSDs, Sticks und Memory Cards), Betriebssystem
SPoF nachher: alles obere plus ein Hypervisor.

Das ist doch Unsinn, so klar und deutlich, dass ihn ein Kleinkind erkennen könnte. Vor Allem wenn der Hypervisor nicht richtig mit der Hardware umgehen kann.

@Polii
RAID1 verliert halt 50% des Speicherplatzes. Beim RAID5 sinds nur noch 33%, das läppert sich schon, außerdem ist es flexibler/erweiterbar.

 

[Polii]

Naja ESXi ist jetzt in diesem Fall nicht mal das grosse Problem, denn der grössrre SPOF ist nunmal die Harddisk. Wenn der Hyprvisor ausfällt und nicht grad ein DB Server drauf läuft, hast du ja die Daten noch. Nach der Reparatur des Hypervisor funktionierts ja dann wieder oder du installierst gleich ESXi neu.

Bevor man ein RAID5 in Betracht zieht sollte man aber schon noch wissen ob da SAS oder SATA Platten drin sind.

 

[Metal_Warrior]

@Polii:
Daher ja RAID, was das Betriebssystem vor den Problemen eines HDD-Ausfalls bewahrt. Wenn der Hypervisor das nicht selbst implementieren kann, ist er nicht nur selbst ein SPoF, sondern ermöglicht zudem erst den SPoF "Harddisk". Verstehst du jetzt, worauf ich hinaus will? Jeder neue Layer bringt das Problem mit sich, dass er einen SPoF darstellt, ob wahrscheinlich oder unwahrscheinlich ist völlig egal. Erst wenn der neue Layer in der Lage ist, ein SPoF-Problem eines notwenigen vorhergehenden Layers zu lösen, stellt sich die Frage nach der Wahrscheinlichkeit: Tritt der neu eingebrachte SPoF wahrscheinlicher auf als der gelöste, oder nicht? Wenn ja, ist der Layer schlecht und sollte nicht eingebunden werden. Wenn nein, hat er einen Zweck und sollte eingebunden werden. Im vorliegenden Fall (Hypervisor kann kein RAID) müssten sogar die Ausfallwahrscheinlichkeiten addiert werden, weil nur ein zusätzlicher SPoF eingebracht wird.

SAS ist eine SATA-Erweiterung; ich sehe keinen Grund, warum das Einschränkungen bezüglich eines SoftRAID5 bieten sollte.

 

[Polii]

Verstehe schon vorauf du hinauswillst. Ich wollte sagen, dass der SPOF beim ESXi weniger starke auswirkungen hat als der bei einer HDD.

Unt bei den SAS Platte gehts nicht ums Interface sondern um die bessere URE, sprich wann ein Read Error auftritt, bei S-ATA bei meist 10^14 Bit bei SAS 10^16. Was 12TB bzw. 1.25 Petabyte entspricht. Deshalb ist es idiotisch mit 3TB Platten ein RAID5 zu erstellen. Gibt aber auch S-ATA Platten die 10^15 oder 10^16 haben zb. die SE und RE von Western Digital, wobei es dort weniger als 10 Fehler sind statt weniger als einer. Wäre also durch aus wichtig zu wissen was da verbaut wird.

 

[Metal_Warrior]

@Polii:
Die Read Error Rate wird zumindest beim Software-RAID mit genug Spielraum eingeplant, um Standard-SATAs problemlos im RAID laufen lassen zu können. Ich hab 5 WD20EARS seit über 4 Jahren im RAID5-Verbund mit mdadm und dmcrypt laufen - ein einziger Ausfall (drop aus dem RAID aufgrund der Lesefehlerrate auf ein paar Sektoren, kein Vollversagen). Ja, die SAS sind in mehrerlei Hinsicht besser, aber einen signifikanten Unterschied zur Laufzeit macht das nach meiner Erfahrung in diesem Punkt nicht.

 

[Polii]

Das Problem tritt erst beim Rebuild auf, während dem Betrieb läuft das schon wie es soll. Wenn nähmlich die Parity der einen Disk nicht gelesen werden kann, kannst du deinen Daten auf wiedersehen sagen.
Es ist heutzutage mit 3TB Platte einfach schwachsinnig ein RAID5 zu erstellen. Die grossen Hersteller von Profesionellen Speicherarrays haben den RAID5 Support auch schon gestrichen. RAID5 ist tot.

 

[Metal_Warrior]

@Polii:
Kann ich so nicht unterschreiben, und ich hab damit auch schon Rebuilds und Grow hinter mir. Man muss sich auch mal vor Augen halten, was 10^-14 bzw. 10^-16 bedeutet - der Unterschied ist 'nur' Faktor 100. Das Problem ist ja nicht aus der Welt, also muss damit so oder so gerechnet werden und es müssen daher Routinen für genau diesen Fall existieren. Ob die nun öfter oder weniger oft anschlagen, ist ziemlich egal, jedenfalls ist der Linux-Kernel sowieso recht allergisch auf Lesefehler in RAIDs - der droppt auch gerne, wenn die Fehler nur hin und wieder auftreten, und wartet definitiv nicht auf irgendwelche SMART-Werte. Ich glaub dir gern, dass RAID5 nicht mehr in großen Umgebungen verwendet wird (da ist der Speicherplatz sowieso das Billigste am System), aber für Privatleute sehe ich keine größeren Nachteile. 1x Parity ist immer noch wesentlich besser als 0x Parity.

 

[Polii]

Naja wir haben im Geschäft auch schon im NAS mit 30TB ein Grow sowie ein Rebuild gemacht, hat auch ohne Probleme funktioniert und wir werden dort den Raid Typ auch nicht ändern, aber wenn man schon etwas neu macht, sollte es auch gleich richtig erstellt werden. Und gerade als Privat Person ist Parity eigentlich noch weniger intressant, da eignet isch ein RAID1 eigentlich immer noch am besten. Aber ich denke wir haben hier zwei verschiedene Meinungen und die Disskusion geht glaube ich auch leicht an der eingetlichen Frage des TS vorbei.

 

[Metal_Warrior]

@Polii:
Eigentlich sind wir sogar einer Meinung: RAID1 hab ich nämlich nur nicht vorgeschlagen, da ich annahm, der TS brauchte die 6 TB voll und ne 4. Festplatte würde die Kalkulation sprengen (wobei dann logischerweise RAID10 nötig wird). Keine Frage, RAID1 ist (mit dem Auge auf Ausfallsicherheit) sinnvoller - 200% Lesegeschwindigkeit, etwa 90% Schreibgeschwindigkeit, hohe Ausfallsicherheit, sichere Identifikation der ausfallenden Platte, Rebuild ohne Berechnung (allerdings mit 100% Belastung der Schwesterplatte).