
Ich bin mit meinen Kunden schon lange auf AWS, aber ich muss jetzt Kosten senken, um meine Dienste weiterhin anbieten zu können. Auf AWS verwende ich RSync, um einige Ordner synchron zu halten, und DRDB, um hohe Verfügbarkeit mit transparentem Failover zu gewährleisten, sodass für jeden Client-Rechner immer ein funktionsfähiger und einsatzbereiter Spiegel vorhanden ist.
Jetzt kann ich DRBD nicht mehr weiter verwenden, da die viel günstigere Cloud-Lösung, auf die ich migriere, für jede Maschine nur ein Ubuntu 14.04 LTS mit nur einer Partition und ohne LVM bereitstellt. Diese Cloud-Plattform ist auch für einige meiner Kunden zu einer Anforderung geworden.
Die Lösung, die mir in den Sinn kommt, ist, Shell-Skripte für den täglichen BKP auf der einen Seite einzuplanen, diese per SSH auf die andere Seite zu übertragen und den BKP wiederherzustellen. Das wird komplex, fehleranfällig und erfordert einen hohen Entwicklungs- und Verwaltungsaufwand.
Viele meiner Kunden nutzen nur Wordpress+Mysql und akzeptieren einen Tag Verzögerung. Ich bin auf der Suche nach Alternativen, um „hohe Verfügbarkeit“ zu gewährleisten, auch wenn dies mit einem Tag Verzögerung einhergeht, und die mich nicht dazu zwingen, für jeden Fall Skripte mit dem eingeschränkten Kontext zu entwickeln und zu verwalten.
Antwort1
Wenn Sie wirklich kein Blockgerät verwenden können (DRBD wäre hier wahrscheinlich besser und Sie haben bereits Erfahrung damit), kann GlusterFS Ihnen die Replikationsfunktionen bieten, die Sie auf Dateiebene suchen.
Gluster-„Bausteine“ sind zwar im Idealfall ein einzelnes Speichergerät mit einem eigenen dünnen LVM-Stapel, der auf XFS endet, können aber eigentlich jedes POSIX-kompatible Dateisystem (oder sogar nur ein Verzeichnis statt eines dedizierten FS) auf einem Knoten sein.
Diese Bausteine werden zu einem einheitlichen „Volume“ mit einer „Replikat“-Richtlinie zusammengefasst, die definiert, wie viele Bausteine mit einer bestimmten Datei geschrieben werden – in diesem Fall wahrscheinlich Replikat 2 oder 3. Diese Replikate werden nach Möglichkeit auf unterschiedlichen Knoten platziert.
Die Fehlersemantik bei Gluster ist noch nicht so kohärent wie bei DRBD. Split-Brain-Zustände sind einfacher zu erreichen, da die Datenreplikation in der Verantwortung des verbindenden Clients liegt (er sendet N Kopien aller Schreibvorgänge an jeden Gluster-Knoten, anstatt an einen Master zu schreiben, der dann die Daten repliziert). Allerdings kann es potenziell einfacher sein, Split-Brain-Zustände mit divergierenden Daten aufzulösen, da bei Verwendung der Replikation jeder Baustein ein intaktes Dateisystem mit vollständig lesbaren Daten ist.
Es wird nicht so schnell sein wie DRBD, aber vielleicht ist das auch gar nicht nötig?