Ausfallsicherheit Server nachträglich optimieren

neueinsteiger84 · 30. November 2023

Hallo zusammen,

habe das Thema nochmal hervorgekramt. Geht hier weiter, falls ihr keine Lust habt, alles zu lesen: https://www.computerbase.de/forum/t...achtraeglich-optimieren.2172493/post-29240414

----

Hallo zusammen,

aktuell treibt mich ein bisschen das Thema Ausfallsicherheit meines kleinen Servers um. Ich betreibe jetzt keine kritischen Anwendungen. Nur mache ich mir Gedanken, was passiert, wenn der Server ausfällt.

Also wie viel Aufwand das für mich verursacht, insbesondere, da ich mich damit bisher (zum Glück) nicht beschäftigen musste.
Und auf meinem Server laufen ein paar VMs + Docker. In Summe nutze ich die Funktionalität des Servers schon täglich (Alleine wegen meiner Hausautomatisierung, dem integrierten NAS usw.)

Setup:

Der Server ist ein Lenovo Think Center Tiny mit einem i5-6500T und zwei SSDs als JBOD (500 GB und 2 TB --> also bisher auch keine großen Datenmengen).
Auf dem Server läuft unter anderem auch ein Proxmox Backup Server.
Backup ist ein zweiter, alter Xeon Server mit 2 4TB HDDs, welche in Raid 1 konfiguriert sind. Der Server läuft aber nur, wenn ich mal ein Backup erstelle, da er ein Idle Verbrauch von 40W hat.

Meine Sorge ist nun, dass eine der beiden SSDs ausfällt. Dann wäre ggf. mein NAS, meine Nextcloud, Home Assistant etc. würden nicht mehr funktionieren.

Und was dann? Zuerst mal eine neue SSD auftreiben (Dauer: 1 Tag+), dann - sofern es den Proxmox Backupserver nicht zerschossen hat - das letzte Backup "aktivieren".
Hat es sogar den Backupserver erwischt, müsste ich den erst mal neu aufsetzen. Das schaffe ich aber zeitlich möglicherweise erst an einem Wochenende --> mein Server ist dann schnell mal eine Woche down.
Und wenn ich Pech habe, ist das Backup alt und alle neuen Daten wären verloren.

Was sind meine bisherigen Gedanken:

1. Ich baue ein separates NAS mit Raid1 auf. Das binde ich dann per NFS in Proxmox ein. Und dann übertrage ich alle VMs in Proxmox auf den NFS Storage. Vorteil: Ich kann das NAS in Ruhe aufsetzen. Außerdem lässt mir das NAS einfach die Möglichkeit zu Speicherweiterung (falls ich mal ein Medienserver aufbauen will). Nachteil: ein weiteres System, entsprechende Anschaffungskosten. Das NAS kann ebenfalls ausfallen und verbraucht natürlich zusätzlich Strom

2. Ich baue einen weiteren Server auf mit ZFS Storage in Raid1 und betreibe dann diesen mit meinem bestehenden Server in einem Cluster. Erhöht nicht nur die Ausfallsicherheit, wenn mir eine SSD abraucht. Nach meinem Verständnis könnte dann sogar ein Server komplett ausfallen und der andere würde alles übernehmen können. Nachteil: identisch zu Punkt 1 oder?
--> ohne echte Begründung (da mir bisher noch das Know How fehlt), klingt diese Lösung besser als Variante 1

3. Sobald ich mal etwas Zeit habe, mache ich den Server platt (vorher Backup auf den Backupserver) und tausche die bestehende 500 GB SSD mit einer 2 TB SSD aus. Dann baue ich den Server erneut auf und beide SSDs als ZFS Raid 1.
Und dann nutze ich das aktuelle Backup aus dem Server.
Vorteil: die preiswerteste Lösung, kein weiteres System, kein zusätzlicher Stromverbrauch.
Nachteil: anstelle von 2.5 TB habe ich dann nur noch 2 TB. Das reicht mir aktuell aus.
Außerdem das gefühlte Risiko / Unwohlsein, dass irgendwas bei Erstellung des Backups falsch lief und ich den Server nicht mehr (vollständig) herstellen kann.
Daneben schützt diese Variante nur vor dem Ausfall der SSD, aber nicht vor dem Ausfall des kompletten Servers. D

Ich hoffe, ihr könnt meine Gedanken und Sorgen nachvollziehen und mir weiterhelfen, eine gute Lösung zu finden.

Danke schon mal im voraus.

Blackeye33 · 30. November 2023

Hört sich alles ganz schön kompliziert an für 2TB Daten und "nicht-kritische" Services.

Ich hab (fast) alles in Docker laufen (ebenfalls nicht kritische Services). Falls mein NAS ausfallen sollte, kann ich das Wichtigste als Übergang auf meinem gelagerten Raspi 4 laufen lassen, bis ein NAS wieder im Angebot ist. Backups habe ich verschlüsselt in der Cloud und einfach manuell auf Platte (Bilder nochmal zusätzlich auf den Clients).

An deiner Stelle würde ich es bei Version 3 belassen. Und ggf. noch ein 2. Backup machen, falls der Backupserver tatsächlich abrauchen sollte. Dann hat man zumindest noch Daten, wenn auch nicht ganz aktuell.

TriceO · 30. November 2023

Wie wär's denn, wenn du vor allem schon mal damit anfängst, deine Backup-Strategie etwas anzupassen.
Zum Beispiel, indem du den Server täglich auf eine externe 2TB-Platte sichern lässt (mit deiner Option 3-Strategie - sonst halt 3TB-Platte).

Das hilft zwar nicht gegen Diebstahl oder Blitzschlag oder Ransomware, ist aber immerhin schon besser, als die sporadischen Backups auf den alten Backup-Server. RAID 1 ist witzig, um den Server im Betrieb zu halten, schützt aber nicht vor Fehlern.

Und dann wäre vielleicht auch ganz gut, wenn du dir einen Backupplan überlegst, bei dem deine Backups nicht allesamt im Haus/Wohnung existieren, sondern du wichtige Daten auch außerhalb des Hauses lagerst (sei es per HDD oder per Cloudspeicher).

Und theoretisch könntest du dir natürlich auch schon eine SSD als Spare besorgen, die du im Fehlerfall sofort tauschen könntest, ohne sie erst bestellen/liefern lassen zu müssen.

Zudem vielleicht den alten Xeon gegen einen kleinen Pi oÄ tauschen, damit die Stromkosten-Hürde wegfällt.

nutrix · 30. November 2023

Wenn etwas wirklich wichtig ist und unbedingt ausfallsicher sein soll, macht man einen Cluster mit einem Loadbalancer davor. Oder man hält sich mindestens ein ebenbürtiges Standby-System vor, auf dem täglich die Dockercontainer oder anderes gesichert oder gespiegelt wird. Alles andere ist Kololores.

neueinsteiger84 · 30. November 2023

Danke für eure Antworten.

Noch etwas zum Hintergrund: Das ganze Setup ist historisch entstanden. Ich hatte irgendwann mal Lust, mich etwas mit dem Thema auseinander zu setzen und hatte dann günstig einen alten Server gekauft.
Da wollte ich dann unbedingt ZFS mit Raid 1 ausprobieren, nur musste ich dann schnell feststellen, dass der Server zu viel Strom braucht und dass er insgesamt etwas Overkill war/ist.
Hätte mich vorher wohl besser informieren oder beraten lassen sollen....
Aber deswegen habe ich ihn jetzt und nutze ihn zumindest noch als Archiv (Archiv trifft es wohl besser als der Begriff Backup).

Und an sich sind es keine kritischen Services oder wirklich richtige Daten (beispielsweise lösche ich Fotos von meinen SDs der Kamera erst dann, wenn ich diese vom Server auch aufs Archiv kopiert habe. Also ich habe immer mindestens eine Kopie aller Daten).
Mir geht es eher um die Einfachheit / Bequemlichkeit, falls etwas mal schiefgeht. Also dass ich so schnell wie möglich den Server im Fall eines Ausfalls wieder zum Laufen bekomme.

@Blackeye33 ok, einen RPI 3B habe ich hier auch noch herumfliegen. Wenn der Server ausfällt, dann müsste ich irgendwie Proxmox auf dem RPI zum Laufen bekommen und dann aus dem Backup-Server die letzte Version wieder herstellen.

@TriceO und das passt dann wohl auch zu deinem Vorschlag. Einfach eine externe Platte anhängen, die als regelmäßiges Backup dient. Genial wäre es, wenn die irgendwie automatisiert hoch und herunterfährt, sodass sie nicht durchgehend aktiv am Server angeschlossen ist.
Aktuell habe ich bereits eine externe Festplatte, mit der ich extrem sporadisch (ca 2 mal im Jahr) ein Backup des Archivs mache.
Also aktuell ist es: ca einmal im Monat ein Backup vom Server zum Archiv und alle 6 Monate ein Backup des Archivs auf eine externe Festplatte.
Die externe Festplatte lagert aber bei mir im Keller, also nicht außer Haus.
Könnte natürlich diese oder eine weitere externe Festplatte auch nutzen, um dann eine Kopie bei meinem Vater unterzubringen.

@nutrix wahrscheinlich die professionellste Lösung, aber wohl in der Anschaffung und im Betrieb die teuerste Lösung.

nutrix · 30. November 2023

Wie gesagt, kauf Dir ein günstiges Standby-System wie einen Mini-PC für 200-300 €, und spiegle dort Deine Dockersachen rein. Das ist leistungsfähiger als ein Rasberry und auch nicht so teuer.

redjack1000 · 30. November 2023

neueinsteiger84 schrieb:
Meine Sorge ist nun, dass eine der beiden SSDs ausfällt. Dann wäre ggf. mein NAS, meine Nextcloud, Home Assistant etc. würden nicht mehr funktionieren.

Wieso Sorge? Wenn das richtig geplant und getestet ist.....

Geh zum dem Rechner ziehe eine SSD ab und schau was passiert!

Im besten Fall läuft das System weiter, im schlimmsten Fall stellst du das Backup wieder her.

CU
redjack

neueinsteiger84 · 1. Dezember 2023

@redjack1000
Ich meine damit, was ist, wenn ein Defekt vorliegt. Dann fallen definitiv Teile des oder gar mein gesamter Server aus.
Und dann müsste ich erst mal ein Ersatzteil besorgen (das könnte ich natürlich bereits bevorraten), aber insbesondere den Server wieder zum Laufen bekommen.
Und da ich das noch nie gemacht habe, kann es ungewollt viel Zeit für mich in Anspruch nehmen. Und während dieser gesamten Zeit sind dann alle oder einige Services down.

@nutrix
Klingt für mich wirklich nach einer sehr vernünftigen Lösung. Ein identischer Lenovo ThinkCenter Tiny kostet mich ca 100€ + Ram ca 50€+ 4TB HDD (2.5 Zoll)+100€
--> 250€ für einen Fallback-Server

Weißt du oder jemand anders, ob ich dann diesen Server automatisch hoch (WOL?) und runter fahren kann?
Dann könnte ich mir folgendes Setup vorstellen:

Server A läuft 24/7.
Fallback-Server wird regelmäßig (einmal die Woche) von Server A aufgeweckt, beispielsweise per WOL
Dann wäre es genial, wenn automatisch von Server A auf den Fallback-Server alle VMs repliziert werden (so wie ich das verstehe macht replicate genau das, was ich möchte, wenn beide Server in einem Cluster zusammengefasst sind).
Danach wird der Fallback-Server wieder heruntergefahren.

--> Ich hätte in dem Fall immer einen wochenaktuellen geklonten Fallback-Server. Fällt also mein Server A aus, müsste ich nur den Fallback-Server anschalten, ggf. die letzten Änderungen nachziehen und fertig.

Unabhängig davon würde ich weiterhin ein monatliches Backup von Server A auf mein Archiv durchführen (das muss ich noch automatisieren....). Dann hätte ich Rollback Möglichkeit auf Monatsbasis.

Und der letzte Schritt wäre dann noch, von Server A halbjährlich/jährlich ein externes Backup zu machen, welches ich bei meinem Vater lagern kann.

h00bi · 1. Dezember 2023

neueinsteiger84 schrieb:
ok, einen RPI 3B habe ich hier auch noch herumfliegen. Wenn der Server ausfällt, dann müsste ich irgendwie Proxmox auf dem RPI zum Laufen bekommen

Das wird nix.
Du brauchst x86 Hardware als Unterbau.
Selbst die Docker Container kannst du nicht auf eine andere Architektur migrieren.

neueinsteiger84 schrieb:
Auf dem Server läuft unter anderem auch ein Proxmox Backup Server.

Ich gehe jetzt einfach mal davon aus dass auf dem Server auch Proxmox läuft, wenn ein PBS im Einsatz ist.

Der große Vorteil von Proxmox ist, dass es auf jedem alten Office Rechner läuft, solange der genug RAM für die notwendigen VMs und Container hat.

Zum PBS: Dein PBS ist virtualisiert auf dem Thinkcenter-Server? Das is Kacke wenn der Host ausfällt. Mein PBS ist ebenfalls virtualisiert, aber auf einem zweiten Host im 2er Cluster. Ich kann die PBS Backups also sogar auf dem zweiten Host recovern und die VMs dort starten.
Nachteil: Ein Cluster ist dann doch etwas pflegeintensiver. Natürlich auch zusätzlicher Stromverbrauch, aber den kann man erstens massiv drücken (hier) und ansonsten auch nur dann automatisiert hochfahren lassen wenn er was zu tun hat (wake up time im UEFI), danach wieder shutdown per script.

Dein "alter Server" bietet sich hier eigentlich wunderbar an. Ich würde hier Proxmox installieren und den PBS virtualisieren.

neueinsteiger84 schrieb:
Meine Sorge ist nun, dass eine der beiden SSDs ausfällt. Dann wäre ggf. mein NAS, meine Nextcloud, Home Assistant etc. würden nicht mehr funktionieren.

Und was dann? Zuerst mal eine neue SSD auftreiben (Dauer: 1 Tag+), dann - sofern es den Proxmox Backupserver nicht zerschossen hat - das letzte Backup "aktivieren".

Das ist schon mal der richtige Ansatz. Du musst für jede Art eines Ausfalls ein Szenario durchdenken.
Also sowohl SSD/HDD im Host als auch Ausfälle anderer Komponenten. Gerade bei deinem Thinkcenter sind viele Komponenten proprietär und nicht gegen was schnell ausgeliehenes tauschbar.

Diese Gedanken sind nur gegen Ausfall!
Dann müsstest du dir noch Gedanken machen, wie du die Daten gegen Löschen, überschreiben oder Verschlüsselungstrojaner schützen willst und wie lange du zurück springen willst.
Da sind deine Gedanken aus Posting #8 sicher nicht falsch.

Blackeye33 · 1. Dezember 2023

h00bi schrieb:
Selbst die Docker Container kannst du nicht auf eine andere Architektur migrieren.

Also ich hab problemlos alle meine Docker Container von nem Raspi 4 auf ein x86 QNAP migriert. Kommt halt auf die Container an. Oder liegt das auch an Proxmox?

h00bi · 1. Dezember 2023

Nein, es liegt an der Containerimage-Architektur.
Das du hast dann jeweils das x86 oder AMD64 Containerimage verwendet.
Das arm64 oder armv7 Containerimage hättest du nicht weiter verwenden können.

Das ist aber besonders dann problematisch wenn es vom Maintainer kein x86/AMD64 Containerimages gibt oder es durch Updates deutlich abweicht.
Bekanntes Beispiel ist der https://github.com/NginxProxyManager/nginx-proxy-manager der sich trotz mehr oder weniger regelmäßiger releases in relevanten teilen deutlich unterscheidet (bzw. unterschieden hat, ich hab den armv7 container nicht mehr im Einsatz, genau deswegen).

Blackeye33 · 1. Dezember 2023

Ok, das meinte ich mit kommt auf die Container an. Hätte ich präzisieren müssen. Auf dem Pi hatte ich natürlich keine x86 Images. Migration bedeutet ja oft nicht einfach nur copy-paste.

Dass die unterschiedlichen Versionen auch noch Inhaltlich unterscheiden können war mir neu - hätte ich nicht erwartet.

nutrix · 1. Dezember 2023

neueinsteiger84 schrieb:
Weißt du oder jemand anders, ob ich dann diesen Server automatisch hoch (WOL?) und runter fahren kann?

Das mußt Du mit der Hardware testen, das kann man so pauschal nicht sagen.

neueinsteiger84 schrieb:
Dann könnte ich mir folgendes Setup vorstellen:

Server A läuft 24/7.
Fallback-Server wird regelmäßig (einmal die Woche) von Server A aufgeweckt, beispielsweise per WOL
Dann wäre es genial, wenn automatisch von Server A auf den Fallback-Server alle VMs repliziert werden (so wie ich das verstehe macht replicate genau das, was ich möchte, wenn beide Server in einem Cluster zusammengefasst sind).
Danach wird der Fallback-Server wieder heruntergefahren.

--> Ich hätte in dem Fall immer einen wochenaktuellen geklonten Fallback-Server. Fällt also mein Server A aus, müsste ich nur den Fallback-Server anschalten, ggf. die letzten Änderungen nachziehen und fertig.

Das macht man in der Praxis anders. Separater Speicher (NAS, usw.), auf mit allen VMs, wo jeder Knoten (Rechner) per SMB, NFS usw. gemeinsam auf den gleichen Speicher zugreifen. Aber hier ist die Schwierigkeit, bei Ausfall des einen Knotens die VMs trotzdem in einen konsistenten Zustand zu halten. Ab hier wird es etwas komplizierter...

neueinsteiger84 · 1. Dezember 2023

@h00bi
Richtig auf dem Thinkcenter läuft der PBS. Wie es halt so ist, habe ich mich da an Youtube-Videos gehalten, da ich von der Materie keine Ahnung hatte.
Aber das von dir genannte Problem ist mir mittlerweile auch aufgefallen. Was mache ich, wenn mein Thinkcenter ausfällt?
Immerhin werden per PBS die Backups auf meinem Archiv-Server gespeichert.

Und hier habe ich dann schon mal etwas Glück. Ursprünglich wollte ich den Archiv-Server nur als NAS nutzen, dachte aber dann bereits "wenn ich mehr Flexibilität will, könnte ich doch Proxmox nutzen und per VM ein NAS aufsetzen".
Genau das habe ich damals dann getan, wobei da bisher nur die eine VM drauf ist.

Aber jetzt könnte ich auf dem Archiv Server ja relativ einfach PBS aufsetzen. Dann ist das schon mal unabhängig beim Ausfall meines Thinkcenters.

Aktuell finde ich dann den Ansatz mit einem Cluster mit zwei Nodes eigentlich gar nicht dumm. Der Fallback-Server wird dann nur einmal die Woche (automatisiert) hochgefahren und per Replicate ein aktueller Snapshot aller Container und VMs auf den Fallback-Server gezogen.
Danach müsste der Fallback-Server wieder automatisch heruntergefahren werden.

Fällt dann mein Thincenter aus, müsste ich beim Fallback Server eigentlich nur die Snapshots einbinden und alle VMs und Container stehen im Fallback-Server zur Verfügung.
Also so wie hier im Video simuliert:

Und falls aus irgendeinem Grund das Thincenter und der Fallback Server die Fliege machen, hätte ich ja noch die Backups auf meinem Archiv-Server.

Danke auf jedenfall für das viele Feedback und den Input.

h00bi · 1. Dezember 2023

neueinsteiger84 schrieb:
nur die Snapshots einbinden

vermutlich meinst du das richtige, aber eigentlich wirst du das Backup vom PBS recovern.
Ansonst passt das so.

neueinsteiger84 · 2. Dezember 2023

@h00bi
das Backup vom PBS würde ich nur im Extremfall nutzen wollen, also wenn sowohl Server A als auch der Fallback-Server nicht mehr funktionieren.

Stelle mir das zukünftige Setup wie folgt vor (alles was rot ist, steht noch nicht):

Server B wäre ebenfalls ein ThinkCenter tiny. Sollte dann Server A ausfallen, müsste ich doch einfach nur die conf Dateien der VMs und Docker in Server B in den richtigen Ordner verschieben (wie in dem von mir verlinkten Video ab Min 11 gezeigt).

Für mich ist aktuell noch unklar ob / wie:

Proxmox damit umgeht, dass vom Cluster Node 2 eigentlich (fast) immer offline ist
wie ich es am einfachsten hinbekomme, dass Server B einmal die Woche automatisch hochgefahren ist und nach der Replikation von Server A auf Server B dann automatisch wieder heruntergefahren wird

Abgesehen davon müsste ich noch auf Server C PBS installieren & konfigurieren.

neueinsteiger84 · 4. Dezember 2023

Nachtrag:
Ich muss über obigen Ansatz nochmal in Ruhe nachdenken, denn habe jetzt gelesen, dass Two Node Cluster nicht empfohlen werden.
Denn wenn der Fallback Server eigentlich immer down ist, kann ich im regulären Server wohl keine VMs & Container mehr gestartet oder beendet werden (fehlendes Quorum)
Entweder müsste ich dann meine RPi als QDevice einbinden oder die Anzahl der nötigen Stimmen im Cluster auf 1 heruntersetzen (pvecm expected 1).
Beides erhöht die Komplexität nochmals, man, man, man

Alternative könnte aber auch ein PCE zsync sein. Das muss ich mir mal anschauen.

h00bi · 4. Dezember 2023

Naja, bei dieser Aussage geht es afaik um Hochverfügbarkeit. Also wenn deine User/Kunden auf dem System arbeiten und ein Node wegbricht.
Und bei sowas würde ich dann auch 3 nodes mit ceph storage nutzen.

Üblicherweise stellt man sich keinen Cluster hin für Dienste, die auch mal 24h ausfallen dürfen. Dir geht's ja hauptsächlich um die unproblematische Recovery in einer überschaubaren Zeitspanne.

Du kannst in einem 2er Cluster problemlos VMs starten, anhalten und neustarten, wenn der zweite Node down ist.
Wichtig ist aber, dass du die storage lösungen in den Hosts nicht verlinkst. Also kein live migrate Cluster.
Wenn du sowas wollen würdest, müsste zu den beiden Nodes noch ein separates storage.

Theoretisch brauchst du die beiden Server nichtmal in einen Cluster packen, Hauptsache wenn der Haupt-Proxmox Host nicht mehr geht kannst du die VM Backups auf dem Proxmox des Backup Servers Recovern.

neueinsteiger84 · 4. Dezember 2023

Mir ist bewusst, dass ich den großen Vorteil eines Clusters - die Verfügbarkeit - nicht nutzen würde.

An sich könnte ich auch mit PBS arbeiten, nur aktuell läuft der Archiv-Server nur ca. einmal im Monat. Und da führe ich das Backup dann manuell / bewusst durch, immer wenn sich aus meiner Sicht vieles geändert hat (größere Anpassungen in Home Assistant, neue Fotos auf mein NAS gespielt oder in die Nextcloud).

Daher dachte ich eher an die Replikation von zwei Nodes in einem Cluster.

Und ich denke, für mein Problem (fehlendes Quorum), gibt es in diesem Video eine, für mich geeignete Lösung:

Hier erklärt er, dass Server 1 24/7 läuft und Server 2 nur, wenn er die zusätzliche Leistung braucht. Damit aber Server 1 weiterhin einwandfrei funktioniert, wenn Server 2 heruntergefahren ist, erhält dieser eine zusätzliche Stimme. Dann reicht das für das Quorum.
Er erklärt im Video auch, dass er die Proxmox Funktionen des Clusters verwenden möchte, aber keine Hochverfügbarkeit braucht.

Genau so könnte ich es auch konfigurieren. Im Normalbetrieb (Server 1 ist online, Fallback ist offline) und auch während der Replikation (beide sind online) ist das Quorum gegeben.
Wenn dann Server 1 komplett ausfällt, müsste ich natürlich dem Fallback Server mehr Stimmrecht geben - also die Situation umdrehen.

Insgesamt sollte es dann wenig (zeit)Aufwand sein, alle Dienste wieder online zu bekommen. Und ich könnte das Ganze auch ohne Risiko mal simulieren, indem ich Server 1 einfach bewusst herunterfahre.
Also Trockenübungen, damit es im Ernstfall gut funktioniert.

neueinsteiger84 · 19. März 2024

Hallo zusammen,

es ist zwar etwas Zeit vergangen, leider bin ich bei dem Thema noch nicht ganz durch.

Aktuell verfolge ich weiterhin das Ziel, ein Proxmox Cluster mit zwei Nodes anzulegen. Bevor jetzt der Aufschrei kommt "niemals ein Cluster mit zwei Nodes" folgendes Setup, welches ich andenke - und noch wichtiger, was ich nicht brauche:

Angedachtes Setup

24/7 Server (Node 1) auf dem alle Container & VMs laufen
Fallback Server (Node 2) zu dem regelmäßig (täglich/wöchentlich) eine Replication der ganzen Container & VMs durchgeführt wird. Dieser Server soll meistens ausgeschaltet sein (Stromsparen). Problem mit Split Brain & Quorum und angedachte Lösung erwähne ich weiter unten
nur lokaler ZFS Speicher auf beiden Servern

NICHT relevant

ich benötige keinen shared Storage zwischen den Nodes / im Cluster
ich brauche keine High Availability, da ich im Fall eines Ausfalls eines Nodes mit einer (kurzen) Ausfallzeit leben kann. Also auch keine automatische Recovery, die möchte ich händisch anstoßen können

Ziel & Lösung zu Quorum & Split Brain

im Fall von Node 1 möchte ich möglichst sicher, einfach und schnell alle VMs & Container auf Node 2 zum Laufen zu bringen
jetzt weiß ich, dass im Standard bei einem zwei Node Cluster kein Quorum vorliegt. Optionen die es hierfür gibt
- drei Node Cluster, aber das macht bei mir wenig Sinn. Zusätzliche Anschaffungskosten und es müssen zwei der drei Nodes immer aktiv sein. Das würde den Strombedarf steigern.
- zwei Node Cluster mit Quorum Device (RPi zum Beispiel, habe ich sogar herumliegen). Steigert die Komplexität und fällt das RPi aus, besteht kein Quorum mehr, wenn der Fallbackserver ebenfalls ausgeschaltet ist (was meistens der Fall sein wird). Steigert auch etwas den Strombedarf
- Node 1 erhält zwei Votes und kann dadurch alleine ein Quorum erzeugen.Fällt dann Node 1 aus, weiß ich gar nicht ob Node 2 (dem Fallback Server) in der Situation zwei Votes bekommen kann, wenn er selber zu dem Zeitpunkt des Ausfalls von Node 1 kein Quroum vorliegt. Daher für mich eher uninterssante Lösung
- Angedachte Lösung: Herabsetzen der nötigen Votes in einem Quorum auf 1 (pvecm expected 1). In einem "normalen" Cluster Setup würde man das nie machen, weil man dadurch ein hohes Risiko von Split Brain hat. Aber ist das bei meinem Setup auch der Fall? Denn auf dem Fallback Server (Node 2) ist im Normalbetrieb kein Container und keine VM aktiv. Fällt der 24/7 Server (Node 1) beispielsweise wegen eines Hardwaredefekts aus, würde ich nach Prüfung die Netzwerkverbindung dieses Servers trennen. Dadurch kann Node 1 nicht eigenständig/unkontrolliert online kommen. Dann würde ich bei Node 2 alle Container & VMs aktivieren (Video, wie ich die Container & VMs aktivieren will hier
  
  YouTube
  
  An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
  YouTube-Embeds laden
  
  Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personenbezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.
  
  YouTube-Embeds laden
  Datenschutzerklärung
  
  )

Habe ich etwas übersehen? Wird das so funktionieren?

Ich weiß, dass man auch mit einem Backup-Server arbeiten könnte (habe ich ja sogar als "Archiv-Server", alte Hardware sehr stromhungrig, daher nur in wenigen Fällen angeschaltet). Da bräuchte ich wohl drei Server, einmal den 24/7 Server, einen Fallback-Server der bei mir dann im Schrank liegt um jederzeit angeschaltet werden kann und den Backup-Server. Entsprechend nach meinem Verständnis hohe Anschaffungskosten und dreifacher Speicherbedarf. Daher habe ich diese Option ausgeschlossen.

Ausfallsicherheit Server nachträglich optimieren

Lieutenant

Lt. Junior Grade

Captain

Lt. Commander

Lieutenant

Lt. Commander

Fleet Admiral

Lieutenant

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Lt. Commander

Lieutenant

Fleet Admiral

Lieutenant

Anhänge

Lieutenant

Fleet Admiral

Lieutenant

Lieutenant

Ähnliche Themen