[SOLVED] Frage zu den Snapshots und dem Backup-Server

[Renegade33]

Moin miteinander,

also bin ja noch ein Neuling, was Linux und Proxmox usw. angeht. Arbeite mich gerade fleißig rein. Jetzt bin ich beim Thema snapshots angekommen. Ist ja per se ein super System. Wurde endlich auch mal Zeit, dass da mal was neues kommt. Volles Backup vom Band ist echt eine Geduldssache usw.^^

Also mein Hauptsystem ist ein pve mit 2 NVMe im Mirror auf denen eine Partition zfs läuft und ein RAID1 mit LVM-Thin. Etwas Platz lasse ich für ein eventuelles Swap frei.

Dann habe ich noch einen kleinen mini ITX mit einer NVMe und 16 GB Ram.

Wo sollte jetzt der Backup-Server aufgesetzt werden, um das Hauptsystem zu sichern? Als VM auf diesem oder auf dem mini-ITX?

Wie ist das jetzt genau mit der Sache snapshots und local-zfs? Habe gelesen, dass hier nur lineare snapshots möglich sind, also nur der letzte snapshot wiederhergestellt werden kann. Allerdings habe ich Videos gesehen, bei denen ältere snapshots wiederhergestellt wurden. Ich glaube zfs.rocks war das.
Mir wäre schon wichtig sagen zu können OK ich springe jetzt 45 min zurück und nicht 15 min oder 1h, weil da der nächste aktuelle snapshot liegt.

Sollte ich zumindest die VMs und lxc-Container auf das lvm-thin packen, um hier dem Problem aus dem Weg zu gehen?

Schönen Samstag Morgen und ein Danke im voraus
Rene

 

[UdoB]

Wurde endlich auch mal Zeit, dass da mal was neues kommt. Volles Backup vom Band ist echt eine Geduldssache

Snapshots ersetzen kein Backup. Kein einziges der 3-2-1 Strategie.

Wo sollte jetzt der Backup-Server aufgesetzt werden, um das Hauptsystem zu sichern? Als VM auf diesem oder auf dem mini-ITX?

Also ich will ein Backup zurückspielen können, wenn etwas kaputt geht. Wenn der PBS als VM auf dem gerade verstorbenen Server läuft, geht das aus offensichtlichen Gründen nicht mehr. Daher ist natürlich die Empfehlung: der Backup-Server muss eine separate Hardware sein.

Am Ende läuft es meist auf Kompromisse hinaus, insbesondere im Homelab - sowohl wegen der Verfügbarkeit passender Hardware als auch hinsichtlich der Stromkosten für einen weiteren Server, "der nichts tut".

Im Homelab habe ich beides: ein kontinuierlich laufender PBS als VM auf einem nur wenig genutzten Cluster-Member und mehrere weitere Server, die eigentlich ausgemustert sind, aber als Backup-Storage wirklich sehr gute Dienste leisten. Die schalte ich nur sporadisch ein: einen davon automatisch wöchentlich für ein paar Stunden und zwei weitere manuell monatlich...

YMMV

Wie ist das jetzt genau mit der Sache snapshots und local-zfs? Habe gelesen, dass hier nur lineare snapshots möglich sind, also nur der letzte snapshot wiederhergestellt werden kann.

Hier musst du unterscheiden zwischen den Fähigkeiten, die ZFS mitbringt und den Mechanismen, die Proxmox offiziell implementiert und die auf KVM/QEMU aufsetzen. Das ist nicht deckungsgleich.

Obwohl ich Christian Zengel/zfs.rocks/sysops.tv ebenfalls gerne verfolge, beschränke ich mich lieber auf die offiziell unterstützen Funktionen. Alles andere driftet sonst sehr schnell in "nicht supported"-Szenarien ab.

Der offizielle Snapshot-Mechanismus hat tatsächlich die Einschränkung, dass man erst neuere Snapshots löschen muss, wenn man einen älteren wiederherstellen will.

Glücklicherweise bin ich sehr, sehr selten an dieser Stelle. Ich behelfe mich dann mit parallel erstellten Backups. Oder ich akzeptiere eben den Verlust der neueren Snapshots. Das kommt wirklich sehr auf die Situation an.

Viele Grüße

 

[Renegade33]

Snapshots ersetzen kein Backup. Kein einziges der 3-2-1 Strategie.

Mahlzeit @UdoB. Ich dachte,RAID1 +Snapshot auf 2.Gerät + Fallback Sicherung auf Bandlaufwerk im anderen Gebäude kommt doch schon sehr Nahe an 3-2-1 ran. 3Speicherorte, 2 unterschiedliche Medien und eines außer Haus(anderer Brandabschnitt). Bisher lief es auch so, nur dass anstelle snapshots halt veeam fungierte mit inkrementellem Backup.

Am Ende läuft es meist auf Kompromisse hinaus, insbesondere im Homelab - sowohl wegen der Verfügbarkeit passender Hardware als auch hinsichtlich der Stromkosten für einen weiteren Server, "der nichts tut".

Das ist mir auch klar, dass ich nur schwer ein vollwertiges 3-2-1 erreichen kann, da ich allein schon keine Lust habe jede Woche das Band zu wechseln, um offline zu erreichen. Offside muss von daher für Privat reichen. Aber immerhin galvanisch getrennt über LWL und komplett andere Stromversorgung + Blitzschutz.
Für mich ist das soweit ein guter Kompromiss. Ist ja auch immer noch alles Privat bzw. Kleinstgewerbe.

Im Homelab habe ich beides: ein kontinuierlich laufender PBS als VM auf einem nur wenig genutzten Cluster-Member und mehrere weitere Server, die eigentlich ausgemustert sind, aber als Backup-Storage wirklich sehr gute Dienste leisten. Die schalte ich nur sporadisch ein: einen davon automatisch wöchentlich für ein paar Stunden und zwei weitere manuell monatlich...

Ich hätte eben noch meinen Mini-ITX, den ich in den Cluster einbinden wollen würde. Dieser würde aber nur alle 1-2 Tage starten und die snapshots machen. 1-2x wöchentlich würde der PC in der Werkstatt angehen und sich die snapshots holen und aufs Band packen.
Also so mein Plan.

Hier musst du unterscheiden zwischen den Fähigkeiten, die ZFS mitbringt und den Mechanismen, die Proxmox offiziell implementiert und die auf KVM/QEMU aufsetzen. Das ist nicht deckungsgleich.

Obwohl ich Christian Zengel/zfs.rocks/sysops.tv ebenfalls gerne verfolge, beschränke ich mich lieber auf die offiziell unterstützen Funktionen. Alles andere driftet sonst sehr schnell in "nicht supported"-Szenarien ab.

Der offizielle Snapshot-Mechanismus hat tatsächlich die Einschränkung, dass man erst neuere Snapshots löschen muss, wenn man einen älteren wiederherstellen will.

Also Christian Zengel macht das ja mit Cockpit und da hat es super geklappt. Allerdings ist mir auch vollkommen klar, das er in einer anderen Liga spielt. Mir geht es um Stabilität und unkomplizierte Administrierbarkeit in meinem Home-System. Will und kann mir nicht erlauben da Stunden um Stunden reinzustecken, nur damit das System läuft.
Support hab ich ja ohne Kaufversion(Lizenz) sowieso nur von den ganzen freundlichen und geduldigen Menschen hier im Forum, die meine Fragen aushalten und beantworten. Darum sollte es eben auch schlussendlich ein stabiles System sein, mit dem ich ohne ständige Hilfe klar komme.

Von daher eben meine ganzen Fragen lieber jetzt und richtig Planen, als dann überfordert zu sein und ständig um Hilfe betteln müssen.

 

[Dunuin]

Mahlzeit @UdoB. Ich dachte,RAID1 +Snapshot auf 2.Gerät + Fallback Sicherung auf Bandlaufwerk im anderen Gebäude kommt doch schon sehr Nahe an 3-2-1 ran. 3Speicherorte, 2 unterschiedliche Medien und eines außer Haus(anderer Brandabschnitt). Bisher lief es auch so, nur dass anstelle snapshots halt veeam fungierte mit inkrementellem Backup.

Snapshots sind aber Teil vom ZFS Pool und daher auch auf den selben Platten wie deine Daten. Wenn du die Snapshots extern haben willst, dann müsstest du schon einen zweiten Pool irgendwo haben und die dann dahin replizieren. Dann sind die Snapshots ja aber nur ein Baustein um deine Zvols/Datasets zu syncen. Aber ja, der andere Pool wäre dann schon eine vollwertige zweite Kopie.

 

[UdoB]

Das ist mir auch klar, dass ich nur schwer ein vollwertiges 3-2-1 erreichen kann

Naja, wichtig ist aus meiner Sicht, dass man sich die Optionen, die Empfehlungen, die für einen selbst machbaren Varianten und die jeweils zu erwartenden Konsequenzen im Problemfall zumindest mal ansieht und gedanklich durchspielt. Danach kann man ja eine beliebige Entscheidung treffen.

Ich hätte eben noch meinen Mini-ITX, den ich in den Cluster einbinden wollen würde. Dieser würde aber nur alle 1-2 Tage starten

Wie gesagt, das mache ich auch so. (Wöchentlich, monatlich.) Bei einer geringen Anzahl Cluster-Member kommt das Problem der Mindestanzahl Nodes hinzu: man braucht mindestens drei Stück, auch wenn es "Tricks" wie ein zusätzliches "Quorum-Device" gibt.

Wenn du nur einen einzigen PVE-Server kontinuierlich betreiben willst, lass ihn am besten Standalone - baue keinen Cluster. Einen PBS kann man exakt genau so gut an einen einzelnen PVE (oder mit passendem Aufwand auch an zwei/mehrere unabhängige PVE) wie an an einen Cluster anbinden. Ich habe gerade diese Woche (beruflich) wieder gelernt, dass KISS (Keep it simple, stupid!) eine gute Idee ist. Komplexität ist der Feind jeder Stabilität und Zuverlässigkeit.

Der Zweit-Mini-ITX "kennt" dann allerdings den Haupt-PVE nicht direkt. Einen VM von A nach B zu verschieben klappt dann am einfachsten über den PBS. (Oder per Kommandozeilen-Befehl, aber nicht per Gui.)

Andererseits: wenn man einmal mit einem Cluster experimentiert hat, will man so etwas haben. Ich kann bei Kernel-Updates oder Hardwareproblemen einfach die laufenden VMs auf einen anderen Node verschieben - und die laufenden Programme/Serverdienste merken das nicht einmal. Wenn irgend ein Node stirbt werden dank HA (HIgh Availability) die nun verschwundenen VMs automatisch auf einem anderen Node neu gestartet. Solange nur ein Medienserver für das Wohnzimmer als VM läuft, ist das natürlich alles egal. Sobald Home-Automatisierung oder "richtige" Serverdienste hinzukommen, kann das aber sehr nützlich sein.

und die snapshots machen.

ZFS-Snapshots entstehen und existieren (zunächst) immer innerhalb eines ZFS-Pools. Man kann sie von einem Pool zu einem anderen Pool (auch auf einem anderen Server) senden. Im PVE wird dieser Mechanismus genutzt, wenn man (ZFS-) "Replikation" verwendet. Das funktioniert für mich sehr gut, ich nutze das intensiv. Dieses Konzept nennt man nicht Backup.

Mir geht es um Stabilität und unkomplizierte Administrierbarkeit in meinem Home-System.

Dann nutzt man am besten ausschließlich die Funktionen, die offiziell unterstützt bzw. mitgeliefert werden. Plus monitoring.

Viel Erfolg!

 

[Renegade33]

Naja, wichtig ist aus meiner Sicht, dass man sich die Optionen, die Empfehlungen, die für einen selbst machbaren Varianten und die jeweils zu erwartenden Konsequenzen im Problemfall zumindest mal ansieht und gedanklich durchspielt. Danach kann man ja eine beliebige Entscheidung treffen.

Genau so sehe ich das auch. Optionen und Risiken abwägen. Da bei mir die größten Risiken Stromausfall und Bitrod sind. Die meisten Daten liegen wirklich da nur rum. Erschlage ich ja Bitrod schon mit zfs und der Stromausfall wird durch USV gepuffert. Somit ist das nächste Problem defekte Hardware und Anwenderfehler.

Wie gesagt, das mache ich auch so. (Wöchentlich, monatlich.) Bei einer geringen Anzahl Cluster-Member kommt das Problem der Mindestanzahl Nodes hinzu: man braucht mindestens drei Stück, auch wenn es "Tricks" wie ein zusätzliches "Quorum-Device" gibt.

Ja das läuft zu testzwecken gerade auf meinem Raspi fürs smarthome. Das Problem bei 3 ist, wenn einer immer aus ist, sind es doch wieder nur 2.

Andererseits: wenn man einmal mit einem Cluster experimentiert hat, will man so etwas haben. Ich kann bei Kernel-Updates oder Hardwareproblemen einfach die laufenden VMs auf einen anderen Node verschieben - und die laufenden Programme/Serverdienste merken das nicht einmal. Wenn irgend ein Node stirbt werden dank HA (HIgh Availability) die nun verschwundenen VMs automatisch auf einem anderen Node neu gestartet. Solange nur ein Medienserver für das Wohnzimmer als VM läuft, ist das natürlich alles egal. Sobald Home-Automatisierung oder "richtige" Serverdienste hinzukommen, kann das aber sehr nützlich sein.

Ja hat schon was. gerade für die Domain oder meine Datenbanken für Informationshaltung. Einfach scvhnell rüber und nur das Datengrab ist halt dann mal schlafen, aber OK, man kann arbeiten.

ZFS-Snapshots entstehen und existieren (zunächst) immer innerhalb eines ZFS-Pools. Man kann sie von einem Pool zu einem anderen Pool (auch auf einem anderen Server) senden. Im PVE wird dieser Mechanismus genutzt, wenn man (ZFS-) "Replikation" verwendet. Das funktioniert für mich sehr gut, ich nutze das intensiv. Dieses Konzept nennt man nicht Backup.

Ich dachte, wenn man den PBS nutzt, werden sie automatisch dort abgelegt? OK, aber ob Fisch oder Fleisch, nenn es, wie du willst. Beides macht satt Und darum geht es mir.

Dann nutzt man am besten ausschließlich die Funktionen, die offiziell unterstützt bzw. mitgeliefert werden. Plus monitoring.

Ist auch meine Idee. Halt die wichtigsten Tools drauf(ethtools, zfs auto snapshot,...) und dann laufen lassen.

Jetzt ist allerdings immer noch meine Frage, OS, VM, LXC lieber auf LVM-Thin im RAID1 oder auf zfs Mirror?

 

[UdoB]

Jetzt ist allerdings immer noch meine Frage, OS, VM, LXC lieber auf LVM-Thin im RAID1 oder auf zfs Mirror?

Alles auf ZFS Mirror, sofern möglich.

Für mich überwiegen die Vorteile von ZFS massiv.

Viel Erfolg!

 

[Dunuin]

Ich dachte, wenn man den PBS nutzt, werden sie automatisch dort abgelegt? OK, aber ob Fisch oder Fleisch, nenn es, wie du willst. Beides macht satt Und darum geht es mir.

Nein PBS nutzt keine ZFS Replikation und die Backups enthalten auch nicht deine ZFS Snapshots.

 

[Renegade33]

Nein PBS nutzt keine ZFS Replikation und die Backups enthalten auch nicht deine ZFS Snapshots.

Was macht der dann genau?

Alles auf ZFS Mirror, sofern möglich.

OK. Werde mir aber mal ein wenig über lassen für eine LVM-Thin und evtl eine Swap. DEnke 500-600 GB sollten reichen für den pve, ucs, LXC-toolbox und noch eine kleine VM für Datenbanken.

Was sind denn vernünftige(und günstige) SSD für ein special device? Und wie groß sollten die SSDs sein?

 

[Dunuin]

Was macht der dann genau?

Ganz normal Blockdevices auf Blockebene und Ordner auf Dateiebene einlesen, dann verarbeiten und sichern. Unabhängig davon was die PVE oder PBS Hosts als Storage nutzen. Würde man mit ZFS Replikation arbeiten wären ja nur Backups von ZFS nach ZFS möglich.

Was sind denn vernünftige(und günstige) SSD für ein special device?

Das gleiche wie generell bei ZFS. X-beliebige Enterprise SSD die für deine Workloads ausreicht (Performance und Haltbarkeit) mit Power-loss Protection.

Und wie groß sollten die SSDs sein?

Siehe hier: https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954

 

[Renegade33]

Für mich überwiegen die Vorteile von ZFS massiv.

Was siehst du persönlich als Vorteile?


Wie würdest du denn das Datengrab aufteilen? Bei 6 Platten 2 vdev mit je 3 Platten Raidz1 in den Pool oder eines mit allen 6 Platten und Raidz2?
Habe gehört bei 2 cDevs ist lese/schreib Geschwindigkeit besser?

Ganz normal Blockdevices auf Blockebene und Ordner auf Dateiebene einlesen, dann verarbeiten und sichern. Unabhängig davon was die PVE oder PBS Hosts als Storage nutzen. Würde man mit ZFS Replikation arbeiten wären ja nur Backups von ZFS nach ZFS möglich.

Aber er macht das doch über snapshots oder?

Das gleiche wie generell bei ZFS. X-beliebige Enterprise SSD die für deine Workloads ausreicht (Performance und Haltbarkeit) mit Power-loss Protection.

Ein paar Modelle wären hier für mich von Vorteil. Was haltet ihr von einer 960GB Samsung Enterprise PM893MZ?

 

[Falk R.]

Die PM893 sind OK.

Der PBS regelt das über eine Technik im qemu, daher ist das unabhängig vom Storage und ob das Storage Snapshots kann. Ja man kann somit auch inkremetelle Backups im Snapshot Mode machen von Shared LVM Disks, die sonst nicht Snapshotfähig sind.

 

[Renegade33]

Die PM893 sind OK.

Würde 2 gebrauchte bekommen für je 50,- Ein Jahr gelaufen im 24/7. Denke, das ist OK.

Der PBS regelt das über eine Technik im qemu, daher ist das unabhängig vom Storage und ob das Storage Snapshots kann. Ja man kann somit auch inkremetelle Backups im Snapshot Mode machen von Shared LVM Disks, die sonst nicht Snapshotfähig sind.

Also gleicht er quasi das Problem der linearen snapshots auch aus oder?

 

[Falk R.]

Also gleicht er quasi das Problem der linearen snapshots auch aus oder?

Welches Problem meinst du?
Die Technik bringt ein eigenes Problem mit, wenn der Backupserver zu langsam angebunden ist, oder die Disks zu langsam, dann werden deine VMs sehr langsam, solange das Backup läuft.

 

[sb-jw]

Würde 2 gebrauchte bekommen für je 50,- Ein Jahr gelaufen im 24/7. Denke, das ist OK.

Wenn du die Möglichkeit hast, lass dir die SMART Werte geben, insbesondere Wearout / TBW ist ein relevanter Faktor.

 

[Renegade33]

Welches Problem meinst du?
Die Technik bringt ein eigenes Problem mit, wenn der Backupserver zu langsam angebunden ist, oder die Disks zu langsam, dann werden deine VMs sehr langsam, solange das Backup läuft.

Die linearen snapshots. WEnn die VMs im zfs liegen kann man ja nur den letzten snapshot rebuilden und keinen vorhergehenden direkt.
Das Backup wäre bei mir nachts, wo eh kein Nutzen ist. Der Backup Server läuft über NVMe SSD bzw. SATA SSD und eine 2,5Gbit Verbindung an den Server.

Wenn du die Möglichkeit hast, lass dir die SMART Werte geben, insbesondere Wearout / TBW ist ein relevanter Faktor.

Leider nein, der Verkäufer hat nix dergleichen. Meint bei SSD braucht es das nicht, nur bei HDD. Mit solchen Leuten diskutier ich ned. Evtl. geht er auf die Bedingung ein, dass ich sie prüfe und wenn sie unter 10% TBW sind, ist es für mich OK.
Anderenfalls wären neue

Intel SSD DC S3610 400GB, 2.5", SATA (SSDSC2BX400G401)

Samsung OEM Datacenter SSD PM883 480GB, SATA (MZ7LH480HAHQ-00005)

oder eben die selben mit 480GB noch in der Auswahl.

 

[UdoB]

Was siehst du persönlich als Vorteile?

Das Übliche:

• Datenintegrität = ZFS liefert niemals falsche Daten
• wirksamen Schut gegen Bitrot inklusive "self-healing" - sofern man hinreichend Redundanz vorsieht
• transparente Komprimierung - bringt bei mir etwa 10 bis 40 Prozent
• "billige" Snapshots
• Replikation zwischen meinen Nodes = "Shared Storage für Arme" = funktioniert für mich sehr gut

Wie würdest du denn das Datengrab aufteilen?

Ich verwende fast überall Mirrors, insbesondere für die Storages der VMs innerhalb PVE.

Ausnahme: sowohl meine "echten" Daten als auch mehrere sekundäre(!) Backups liegen jeweils auf RaidZ2 (mit und ohne Special-Device, je nach Möglichkeiten der Hardware), dort können dann zwei beliebige Devices gleichzeitig ausfallen, ohne dass Datenverlust auftritt. Aber das ist echt langsam! Man sollte sich dies gut überlegen - wenn ich diese Systeme neu bauen würde, wären wohl auch dies (multiple) Mirrors.

Viele Grüße

 

[Falk R.]

Die linearen snapshots. WEnn die VMs im zfs liegen kann man ja nur den letzten snapshot rebuilden und keinen vorhergehenden direkt.
Das Backup wäre bei mir nachts, wo eh kein Nutzen ist. Der Backup Server läuft über NVMe SSD bzw. SATA SSD und eine 2,5Gbit Verbindung an den Server.
.

deshalb mache ich lieber mehr Backups. Wenn der PBS schnell ist, stören die 5 Sekunden nicht und du kannst jeden Restorepunkt frei nutzen.
Für viele ist Snapshot das Allheilmittel, ich sehe das etwas anders. Nett wenn es da ist, aber kein Must Have für mich.

 

[Renegade33]

Das Übliche:

• Datenintegrität = ZFS liefert niemals falsche Daten
• wirksamen Schut gegen Bitrot inklusive "self-healing" - sofern man hinreichend Redundanz vorsieht
• transparente Komprimierung - bringt bei mir etwa 10 bis 40 Prozent
• "billige" Snapshots
• Replikation zwischen meinen Nodes = "Shared Storage für Arme" = funktioniert für mich sehr gut

Punkt 1+2 sind mir klar, aber was meinst du mit transparente Komprimierung, "billige" snapshots und REplikationen ist mir klar, aber warum machst du nicht einfach ein shared storage über LXC Toolbox oder so?

Ich verwende fast überall Mirrors, insbesondere für die Storages der VMs innerhalb PVE.

Ausnahme: sowohl meine "echten" Daten als auch mehrere sekundäre(!) Backups liegen jeweils auf RaidZ2 (mit und ohne Special-Device, je nach Möglichkeiten der Hardware), dort können dann zwei beliebige Devices gleichzeitig ausfallen, ohne dass Datenverlust auftritt. Aber das ist echt langsam! Man sollte sich dies gut überlegen - wenn ich diese Systeme neu bauen würde, wären wohl auch dies (multiple) Mirrors.

Ja VMs und OS sitzen sowieso auf meinem NVMe Mirror. Es geht rein ums "Datengrab". Also wo all die Fotos, Dokumente,... rumfliegen. Dafür sind ja bei mir 6HDD und 2SSD als special device vorgesehen. Die SSD sind im Mirror, aber die HDD bin ich mir noch nicht sicher, wie ich sie anlegen soll. Will halt nicht nur 50% effektive Kapazität. Sollten schon 65-80% sein. Einfache REdundanz reicht, da sowieso extra Backups gehalten werden.

deshalb mache ich lieber mehr Backups. Wenn der PBS schnell ist, stören die 5 Sekunden nicht und du kannst jeden Restorepunkt frei nutzen.
Für viele ist Snapshot das Allheilmittel, ich sehe das etwas anders. Nett wenn es da ist, aber kein Must Have für mich.

Ja bei mir soll alles quasi alle 1-2 Tage gesichert werden und dann nochmal 1x Woche. Zwischendrin hätte ich mir überlegt alle 30 min eines als "temporärer" zu fahren, falls mal beim Arbeiten an den Daten was schief geht.

 

[UdoB]

Punkt 1+2 sind mir klar, aber was meinst du mit transparente Komprimierung,

Wenn man die Komprimierung einschaltet, was per Default der Fall ist, dann werden abgespeicherte Dateien (und auch virtuelle Festplatten per ZVOL) automatisch komprimiert. Das geschieht komplett transparent, also unsichtbar für den Nutzer. Der Erfolg hängt natürlich drastisch von den Daten ab: reiner Text lässt sich auf ~50% zusammenquetschen, übliche Mediendateien gar nicht.

aber warum machst du nicht einfach ein shared storage über LXC Toolbox oder so?

"Unterhalb" von dem LXC muss ja trotzdem echter, zuverlässiger Speicher liegen.

Ach so..., einen Storage und den dann sharen. Ja, kann man machen. Aber dieser Storage darf dann eigentlich nicht von einem Cluster-Member kommen. Sonst fällt ja der ganze Cluster aus, wenn dieser eine Node ein Problem hat --> Single Point of Failure.

Ausfallsicherer externer Speicher mit Storage- und Netzwerk-Redundanz ist ein wirklich großes Thema für sich und sprengt hinsichtlich Komplexität meinen Toleranzbereich um mehrere Größenordnungen.

Dann lieber hyperconverged mit Ceph! Aber damit ich mich damit wohlfühlen könnte, bräuchte ich fünf Nodes mit jeweils mindestens vier OSDs und natürlich mehr als ein Gigabit-Netzwerk. Das sprengt @home schlicht mein Budget, insbesondere auch hinsichtlich des Stromverbrauchs. (Das theoretische Minimum sind drei Nodes und ein einziges OSD.)


Choose your poison... and have fun ;-)