149680
06.12.2023, aktualisiert um 15:08:00 Uhr
6073
22
0
Realisiserung Cluster Proxmox
Hallo Community,
ich überlege gerade mein Homelab auf grundlage eines Proxmox Clusters aufzubauen. Dazu habe ich ein, zwei Fragen.
Aktuell habe ich im Kopf, zwei identische Server (MiniPc) zu nutzen die als Node1 und Node2 fungieren sollen. Als Quorum soll ein Rasberry Pi dienen. Was ich nicht ganz verstehe: Was passiert wenn der Pi ausfällt? Läuft alles weiter oder droht "Chaos" like Split-brain?
Wie verhält es sich wenn ich ein "komplettes" Proxmox Cluster aus drei vollwertigen Nodes aufbaue? Fällt einer weg, sollte doch eigentlich alles normal weiterlaufen oder droht dann auch "Chaos"? Falls ja bräuchte man für einen absolut stabilen Clusterbetrieb nicht immer 4 Nodes?
Dazu noch eine weitere Idee um Kabel und Geräte zu sparen (Homelab eben):
Auf Node3 könnte ich doch theoretisch den Proxmox Backup Server als VM laufen lassen, der eine Replizierung auf Node1 und Node2 ausführt. Die Nodes1 und Node2 hingegen sollen nicht auf Node3 replizieren. Damit hätte ich aus meiner Sicht den Vorteil, dass bei Ausfall von Node3 der PBS auf Node1 oder Node2 "wandern" würde und damit funktionsfähig bleibt. Nachteil wäre in meiner Umgebung, dass ich den den Backup Storage dann als USB Device anbinden muss, sollte dann der der Node tatsächlich ausfallen folgt eben ein umhängen. Ist sicherlich nicht die "beste und optimalste" Lösung aber möglich und für Homelab vertretbar?
Danke für euer Feedback.
ich überlege gerade mein Homelab auf grundlage eines Proxmox Clusters aufzubauen. Dazu habe ich ein, zwei Fragen.
Aktuell habe ich im Kopf, zwei identische Server (MiniPc) zu nutzen die als Node1 und Node2 fungieren sollen. Als Quorum soll ein Rasberry Pi dienen. Was ich nicht ganz verstehe: Was passiert wenn der Pi ausfällt? Läuft alles weiter oder droht "Chaos" like Split-brain?
Wie verhält es sich wenn ich ein "komplettes" Proxmox Cluster aus drei vollwertigen Nodes aufbaue? Fällt einer weg, sollte doch eigentlich alles normal weiterlaufen oder droht dann auch "Chaos"? Falls ja bräuchte man für einen absolut stabilen Clusterbetrieb nicht immer 4 Nodes?
Dazu noch eine weitere Idee um Kabel und Geräte zu sparen (Homelab eben):
Auf Node3 könnte ich doch theoretisch den Proxmox Backup Server als VM laufen lassen, der eine Replizierung auf Node1 und Node2 ausführt. Die Nodes1 und Node2 hingegen sollen nicht auf Node3 replizieren. Damit hätte ich aus meiner Sicht den Vorteil, dass bei Ausfall von Node3 der PBS auf Node1 oder Node2 "wandern" würde und damit funktionsfähig bleibt. Nachteil wäre in meiner Umgebung, dass ich den den Backup Storage dann als USB Device anbinden muss, sollte dann der der Node tatsächlich ausfallen folgt eben ein umhängen. Ist sicherlich nicht die "beste und optimalste" Lösung aber möglich und für Homelab vertretbar?
Danke für euer Feedback.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 74044883448
Url: https://administrator.de/forum/realisiserung-cluster-proxmox-74044883448.html
Ausgedruckt am: 22.12.2024 um 19:12 Uhr
22 Kommentare
Neuester Kommentar
Moin,
was hat denn der PI damit zu tun? Der läuft ja auf ARM.
Ansonsten ist das halt alles ne Konfig Frage.
Active active kann Proxmox nicht, soweit ich weiß.
Gruß
Spirit
was hat denn der PI damit zu tun? Der läuft ja auf ARM.
Ansonsten ist das halt alles ne Konfig Frage.
Active active kann Proxmox nicht, soweit ich weiß.
Gruß
Spirit
Naja auf den Pi würde ich einfach ein Debian oder so installieren kein ProxMox. Dass würde dann auf einem anderen MiniPc laufen
Woher sollen wir wissen was in deinem Homelab vertretbar ist? "Mein Homelab"ist ein PC der da meist offen rum steht. Wenn irgendwas nicht geht wird es halt gefixt, was nicht passt, wird passend gemacht. Ich wüsste nicht, was ich mit einem Cluster tun sollte. Wenn du statt mehreren MiniPCs z.B. einen soliden Mini Server kaufst ist deine Umgebnung bestimmt stabiler aufgestellt als mit einem Cluster auf Consumer Hardware.
Ich kann noch nicht wirklich erkennen, was das Ziel sein soll.
Wenn du das zum lernen aufbaust, okay. Ansonsten bringt das alles nicht viel.
Wenn du das zum lernen aufbaust, okay. Ansonsten bringt das alles nicht viel.
Ich denke "haben will" ist hier Grund genug
@149680
ich kenne das Teil noch nicht wirklich - ist aber schneller ausprobiert als so eine Diskussion in einem Forum
@149680
ich kenne das Teil noch nicht wirklich - ist aber schneller ausprobiert als so eine Diskussion in einem Forum
Wenn der PI ausfällt, ist das Quorum ja immer noch erfüllt. Des weiteren kommt es drauf an was du für ein Storage verwenden willst.
Proxmox Cluster ist nämlich die eine Sache, Cluster Storage eine andere.
Das Proxmox Cluster basiert auf Corrosync und stellt in einem Heatbeat fest ob alle Cluster-Member noch da sind. Mehr macht er erstmal nicht. Dann kann man das kombinieren, mit HCI (z.B. mit Ceph) oder als ZFS. Auch Shared Storage per NFS oder iSCSI ist möglich. Je nachdem für was für ein Storage man sich entscheidet, verhält sich auch das Cluster.
Ein Proxmox-Cluster mit ZFS geht zum Beispiel nur über Storage Replication. Heißt: Fällt ein Node aus, dann müssen die Daten auf dem anderen schon vorhanden sein. Danach wird per Live Migration bei einer VM der Arbeitsspeicher transferiert.
Bei Ceph ist das wieder völlig anders. Da sich dort die Object Storages ständig abgleichen und mehrere Kopien pro Node abgelegt sein können, ist dort immer Zugriff auf die möglichst neuste Änderung möglich. Solange natürlich das Ceph funktioniert.
Ich an deiner Stelle würde erstmal anfangen mit einem 2-Node-Cluster, Storage mit ZFS und Storage Replication. Belese dich zum Thema Corrosync. Wenn du das mal durchgespielt hast, dann kannst du dein 3-node aufbauen. Du hast eben grundlegende Sachen bei Proxmox, so scheint es mir, noch nicht verstanden.
Proxmox Cluster ist nämlich die eine Sache, Cluster Storage eine andere.
Das Proxmox Cluster basiert auf Corrosync und stellt in einem Heatbeat fest ob alle Cluster-Member noch da sind. Mehr macht er erstmal nicht. Dann kann man das kombinieren, mit HCI (z.B. mit Ceph) oder als ZFS. Auch Shared Storage per NFS oder iSCSI ist möglich. Je nachdem für was für ein Storage man sich entscheidet, verhält sich auch das Cluster.
Ein Proxmox-Cluster mit ZFS geht zum Beispiel nur über Storage Replication. Heißt: Fällt ein Node aus, dann müssen die Daten auf dem anderen schon vorhanden sein. Danach wird per Live Migration bei einer VM der Arbeitsspeicher transferiert.
Bei Ceph ist das wieder völlig anders. Da sich dort die Object Storages ständig abgleichen und mehrere Kopien pro Node abgelegt sein können, ist dort immer Zugriff auf die möglichst neuste Änderung möglich. Solange natürlich das Ceph funktioniert.
Ich an deiner Stelle würde erstmal anfangen mit einem 2-Node-Cluster, Storage mit ZFS und Storage Replication. Belese dich zum Thema Corrosync. Wenn du das mal durchgespielt hast, dann kannst du dein 3-node aufbauen. Du hast eben grundlegende Sachen bei Proxmox, so scheint es mir, noch nicht verstanden.
Bedenke das für ein Cluster SHARED STORAGE notwendig ist.
Ohne Shared Storage ist es lediglich Replication zwischen HV 1 und HV 2.
Ach ja und der Platz auf der Platte verringert sich ebenfalls um die Hälfte weil die Replica
ja auch Platz braucht
Ohne Shared Storage ist es lediglich Replication zwischen HV 1 und HV 2.
Ach ja und der Platz auf der Platte verringert sich ebenfalls um die Hälfte weil die Replica
ja auch Platz braucht
Zitat von @149680:
Naja auf den Pi würde ich einfach ein Debian oder so installieren kein ProxMox. Dass würde dann auf einem anderen MiniPc laufen
Naja auf den Pi würde ich einfach ein Debian oder so installieren kein ProxMox. Dass würde dann auf einem anderen MiniPc laufen
Du kannst auf dem Pi auch "Pimox" installieren. Ist ein Pi Projekt für Proxmox und funktioniert für Cluster genauso und hat somit auch einen "Vote". Gibts ein Github dazu - google findets gleich!
LG
1
Hi. Schau mal auf Youtube nach dem Kanal "raspberry pi cloud" der hat vor 2-3jahren genau so etwas mit proxmox erstellt . Dort heißt es "high availabe" HA Cluster. Dort werden fast alle deine Fragen direkt beantwortet. Link:
https://youtu.be/PtwOihR2QLY?si=8JFuDytG1ImRJKrp
Wie viele nodes brauche ich, was passiert wenn einer ausfällt usw.
Was nicht gehen wird ist, so denke ich zumindest, das die nodes parallel laufen und nur bei Ausfall übernehmen. Ich denke die vm disk wird zentral liegen müssen.
Aber berichte gern wenn du das getestet hast, lerne gern dazu
VG
https://youtu.be/PtwOihR2QLY?si=8JFuDytG1ImRJKrp
Wie viele nodes brauche ich, was passiert wenn einer ausfällt usw.
Was nicht gehen wird ist, so denke ich zumindest, das die nodes parallel laufen und nur bei Ausfall übernehmen. Ich denke die vm disk wird zentral liegen müssen.
Aber berichte gern wenn du das getestet hast, lerne gern dazu
VG
Danke für euer Feedback. Video und Hinweise schaue ich mir mal an.
Zu dem Feedback:
Warum das Ganze: Lernen, haben wollen
, kaputt spielen und sich über Backups freuen :D (überspitzt)
Was ich gedacht hatte, da bisher bekannt: die Variante mit 2 Node, mittels ZFS and Replikation, hatte ich eingangs ja erwähnt. Ceph könnte aber auch eine Option sein. Ich habe bisher gedacht und bin mir aktuell auch unsicher, daher mal konkret die Frage. Wenn ich 2 Nodes habe, die ich in einem Cluster zusammenschließe und eine "ZFS" Replikation einrichte (entsprechend getacktet), kann ich dann bei Ausfall von 1 alle VMs die repliziert sind auf 2 hochfahren mit dem Unterschied, dass es eben nicht mit "HA" automatisiert geht oder wie ist das?
Und was ich nicht verstehe. Wenn ich 2 Proxmox Nodes und 1 Pi als Quorum habe, wenn der Pi ausfällt wieso ist das Quorum noch gegeben? Eine Mehrheit kann doch dann faktisch nicht mehr gebildet werden und es folgt ein readonly mode der Nodes1 und 2 oder nicht?
Zu dem Feedback:
Warum das Ganze: Lernen, haben wollen
, kaputt spielen und sich über Backups freuen :D (überspitzt)Was ich gedacht hatte, da bisher bekannt: die Variante mit 2 Node, mittels ZFS and Replikation, hatte ich eingangs ja erwähnt. Ceph könnte aber auch eine Option sein. Ich habe bisher gedacht und bin mir aktuell auch unsicher, daher mal konkret die Frage. Wenn ich 2 Nodes habe, die ich in einem Cluster zusammenschließe und eine "ZFS" Replikation einrichte (entsprechend getacktet), kann ich dann bei Ausfall von 1 alle VMs die repliziert sind auf 2 hochfahren mit dem Unterschied, dass es eben nicht mit "HA" automatisiert geht oder wie ist das?
Und was ich nicht verstehe. Wenn ich 2 Proxmox Nodes und 1 Pi als Quorum habe, wenn der Pi ausfällt wieso ist das Quorum noch gegeben? Eine Mehrheit kann doch dann faktisch nicht mehr gebildet werden und es folgt ein readonly mode der Nodes1 und 2 oder nicht?
Warum glaubst du das nicht.
Ein Cluster Quorum ist Ok wenn über 50% der stimmen erreicht wird. Wenn von 3 Nodes einer fehlt sind noch über 50% im Cluster.
Ein Cluster Quorum ist Ok wenn über 50% der stimmen erreicht wird. Wenn von 3 Nodes einer fehlt sind noch über 50% im Cluster.
Ja das mit der zfs replikation funtktioniert wie du denkst. Aber vorsicht mit einstellungen wie "run vm at boot". Wenn du den ausgefallenen Node wieder online bringst das nicht irgend welche VM's doppelt laufen.
Auch wichtig ist ein monitoring des ganzen. Wenn dir der raspi stirbt bekommst du das für gewöhnlich nicht mit. Wenn dann noch ein VmHost stirbt kannst dü mit dem übrig gebliebenen auch nichts mehr machen ohne grob ein zu greifen.
Auch wichtig ist ein monitoring des ganzen. Wenn dir der raspi stirbt bekommst du das für gewöhnlich nicht mit. Wenn dann noch ein VmHost stirbt kannst dü mit dem übrig gebliebenen auch nichts mehr machen ohne grob ein zu greifen.
danke für euer Feedback. MIr ist nun eingies klarer.
Finde eine Lösung mit drei Node inkl. Proxmox und Ceph schon ganz cool, glaube ich werde das in den kommenden Wochen mal aufbauen. Hardware habe ich noch liegen, also warum nicht.
Eine Ergänzung (passt nicht ganz aber wird schon gehen). Der PBS auf den dann drei Nodes müsste doch theoretisch super klappen da er dann auch redundant ist. Den backup storage für die drei Notes würde ich am einfachsten mit einem NAS zur Verfügung stellen.
Was ich mich noch Frage. Ich möchte mich gegen Diebstahl meiner Hardware schützen, heißt jemand klaut einen oder mehrere Nodes vielleicht sogar alles inkl. Router und Firewall. In diesem Case könnte er oder sie zu haus theoretisch alles aufbauen und müsste dann eben root Kennwörter etc. knacken und hätte zugriff auf alles.
Würde er oder sie eine Platte (boot und data) aus einem Node ausbauen könnte er mit der Boot Platte alles machen da (aktuell nicht) encrypted. Was ich verstanden habe ist, dass der encryption key für Ceph auf der root Partition liegt, ist diese nicht encrpted kommt also jeder mit physikalischen access auf die Platte ran, könnte den key dann nutzen um auch den Ceph pool zu entschlüsseln.
Bedeutet doch, dass ich meine boot Partition auf der Proxmox und damit auch Ceph läuft encrypten muss. Dies würde dazu führen, dass auch bei Ausbau keiner Zugriff auf die Daten auf der boot Disk hätte und baut jemand die data disk aus kann er mit den daten darauf auch nichts anfangen, da diese per ceph encrypted sind.
Sind diese Gedankengänge richtig? Wie geht ihr mit dem Thema encryption um?
Aktuell habe ich meine boot Partition nicht encrypted, dafür aber die data Partition auf der mein ZFS Pool liegt. Der Key ist auf einem USB Device welches beim boot gemountet wird, per Scipt wird dann der ZFS Pool decryted und eingebunden. Funktioniert soweit gut. USK stick wird natürlich nach einem boot abgezogen und verstaut.
Finde eine Lösung mit drei Node inkl. Proxmox und Ceph schon ganz cool
, glaube ich werde das in den kommenden Wochen mal aufbauen. Hardware habe ich noch liegen, also warum nicht.Eine Ergänzung (passt nicht ganz aber wird schon gehen). Der PBS auf den dann drei Nodes müsste doch theoretisch super klappen da er dann auch redundant ist. Den backup storage für die drei Notes würde ich am einfachsten mit einem NAS zur Verfügung stellen.
Was ich mich noch Frage. Ich möchte mich gegen Diebstahl meiner Hardware schützen, heißt jemand klaut einen oder mehrere Nodes vielleicht sogar alles inkl. Router und Firewall. In diesem Case könnte er oder sie zu haus theoretisch alles aufbauen und müsste dann eben root Kennwörter etc. knacken und hätte zugriff auf alles.
Würde er oder sie eine Platte (boot und data) aus einem Node ausbauen könnte er mit der Boot Platte alles machen da (aktuell nicht) encrypted. Was ich verstanden habe ist, dass der encryption key für Ceph auf der root Partition liegt, ist diese nicht encrpted kommt also jeder mit physikalischen access auf die Platte ran, könnte den key dann nutzen um auch den Ceph pool zu entschlüsseln.
Bedeutet doch, dass ich meine boot Partition auf der Proxmox und damit auch Ceph läuft encrypten muss. Dies würde dazu führen, dass auch bei Ausbau keiner Zugriff auf die Daten auf der boot Disk hätte und baut jemand die data disk aus kann er mit den daten darauf auch nichts anfangen, da diese per ceph encrypted sind.
Sind diese Gedankengänge richtig? Wie geht ihr mit dem Thema encryption um?
Aktuell habe ich meine boot Partition nicht encrypted, dafür aber die data Partition auf der mein ZFS Pool liegt. Der Key ist auf einem USB Device welches beim boot gemountet wird, per Scipt wird dann der ZFS Pool decryted und eingebunden. Funktioniert soweit gut. USK stick wird natürlich nach einem boot abgezogen und verstaut.
Moin,
für ein PVE Cluster benötigst du immer eine ungerade Anzahl an Nodes (min. 3) für das Quorum.
Solle dann ein Node ausfallen, läuft, evtl. mit kurzen unterbrechungen einzelner VMs, alles im Readonly-Betrieb normal weiter, vorrausgesetzt du hast die Nodes so dimensioniert das alle VM rechnerrisch auf 2 Nodes laufen könnten.
Best
Jürgen
für ein PVE Cluster benötigst du immer eine ungerade Anzahl an Nodes (min. 3) für das Quorum.
Solle dann ein Node ausfallen, läuft, evtl. mit kurzen unterbrechungen einzelner VMs, alles im Readonly-Betrieb normal weiter, vorrausgesetzt du hast die Nodes so dimensioniert das alle VM rechnerrisch auf 2 Nodes laufen könnten.
Best
Jürgen
Okay, spannend das ist jetzt ja wieder ne andere Aussage.
ich habe verstanden in einem drei Node Cluster, habe ich auch bei Ausfall von einem Node immer eine Mehrheit, weil quasi jeder Node 33 % oder eben eine Stimme jat.
Also habe ich auch mit zwei Nodes die Mehrheit. Warum sollte das System bei einem Ausfall eines Nodes dann in den Read Only Modus gehen? Dann hätte ich ja mit einem drei Node Cluster nichts gewonnen, da ich produktiv nicht weiter arbeiten kann.
ich habe verstanden in einem drei Node Cluster, habe ich auch bei Ausfall von einem Node immer eine Mehrheit, weil quasi jeder Node 33 % oder eben eine Stimme jat.
Also habe ich auch mit zwei Nodes die Mehrheit. Warum sollte das System bei einem Ausfall eines Nodes dann in den Read Only Modus gehen? Dann hätte ich ja mit einem drei Node Cluster nichts gewonnen, da ich produktiv nicht weiter arbeiten kann.
Muss mich etwas entschuldigen, mein erster Satz war nicht ganz richtig.
Damit der Cluster vernünftig funktioniert benötigt er ein Quorum, dieses muss nach ausfall eines Nodes immer noch >50% sein (größer und nicht gleich), sprich wie du bei der Fragestellung schon festgestellt hast benötigt das Cluster mind. 3 Nodes (hier war auch mein Fehler in der vorantwort).
Sollte das Quorum <= 50% sein gehts aus eigenschutz in den Readonly Modus.
In deinem Beispiel hättest du ja bei wegfall eines Nodes immer noch 66..%
Dennoch solltest du deine Konfiguration so dimensionieren das alle VMs auf einem MiniPC laufen würden falls der 2. Wegfällt.
Greets
Damit der Cluster vernünftig funktioniert benötigt er ein Quorum, dieses muss nach ausfall eines Nodes immer noch >50% sein (größer und nicht gleich), sprich wie du bei der Fragestellung schon festgestellt hast benötigt das Cluster mind. 3 Nodes (hier war auch mein Fehler in der vorantwort).
Sollte das Quorum <= 50% sein gehts aus eigenschutz in den Readonly Modus.
In deinem Beispiel hättest du ja bei wegfall eines Nodes immer noch 66..%
Dennoch solltest du deine Konfiguration so dimensionieren das alle VMs auf einem MiniPC laufen würden falls der 2. Wegfällt.
Greets
Kein Problem 😉 so macht alles wieder Sinn 😉.
Ja, die Nodes werden identisch sein, je:
Für mich ein schön kompaktes Steomsparendes Cluster. Denke dass deckt meine Ansprüche auch was Langlebigkeit angeht ganz gut.
Ja, die Nodes werden identisch sein, je:
- Ryzen 5 5600U 6Core/12 Threads
- 64GB Corsair und 1x Kingston DDR4 3200 RAM
- Kingston DC600M 960GB als ProxMox boot drive
- Kingston KC300 2TB für VM, Container und Nutzdaten
- Cluster bekommt ein eigenes VLAN, leider aktuell nur mit 1000Mbit. Sollte für meine Zwecke reichen
- Machinenen kommen dann in ein eigenes VLAN
Für mich ein schön kompaktes Steomsparendes Cluster. Denke dass deckt meine Ansprüche auch was Langlebigkeit angeht ganz gut.
Wenn du die kommunikation des clusters und der VM's über die selbe NIC laufen lässt musst du aber das QOS der vlans richtig konfigurieren da du sonst ziemlich schnell in probleme rennst weii die NIC ausgelastet ist.
Ich lasse die Cluster kommunikation immer über eigene NIC's laufen.
Solltest du auch noch mit CEPH spielen wollen musst du zusätzlich mindesten 10Gbit NIC's haben da das ganze sonst ziemlich lahm wird.
Ach ja und CEPH schaltet immer den cache von SSD's aus. Also benötigst du SSD's mit Plp die sich den cache nicht deaktivieren lassen. Sonst sind diese auch lahm und ziemlich schnell kaputt.
Ich lasse die Cluster kommunikation immer über eigene NIC's laufen.
Solltest du auch noch mit CEPH spielen wollen musst du zusätzlich mindesten 10Gbit NIC's haben da das ganze sonst ziemlich lahm wird.
Ach ja und CEPH schaltet immer den cache von SSD's aus. Also benötigst du SSD's mit Plp die sich den cache nicht deaktivieren lassen. Sonst sind diese auch lahm und ziemlich schnell kaputt.
Hmm...mir scheint es fast so nach Meinung / Erfahrung hier und in vielen Bereichten als sollte ich lieber Abstand von der Ceph Idee nehmen und lieber bei ZFS Replikation bleiben. Ich denk 15Min als kürzeste Spanne sollte bei mir Dicke ausreichen.
Ceph ist schon super wenn man es richtig macht. Aber ist sicher nichts wenn man kein geld ausgeben möchte. Ich betreibe einige Cluster mit 50+ SSD's und das ist schon eine feine Sache.
Ok, also von Ceph habe ich nun abgesehen, obwohl es mich schon mal interessiert hätte, aber was nicht ist kann ja noch kommen.
Nun stehe ich allerdings vor dem nächsten PRoblem. Wie gelernt habe kann Proxmox von Haus keine Replikation mit nativer ZFS Verschlüsselung - sehr ärgerlich!!
Nun bin ich am Überlegen wie ich weiter machen sollte. Aktuell sehe ich zwei Optionen:
Einfacher wäre aus meiner Sicht die Variante 2 SED. Wenn ich dies einrichte und der ZFS Pool schon besteht sind doch bestimmt aller bisherigen Daten nicht verschlüsselt sondern nur neue? Kann ich sowas wie dropbear auch für SED Kenntworteingabe nutzen?
Bei LUKS kann ich zwar die Disk verschlüssel (data), dann kann ich meines Wissens anch aber kein ZFS pool mehr initieren.
Wie geht ihr vor?
Nun stehe ich allerdings vor dem nächsten PRoblem. Wie gelernt habe kann Proxmox von Haus keine Replikation mit nativer ZFS Verschlüsselung - sehr ärgerlich!!
Nun bin ich am Überlegen wie ich weiter machen sollte. Aktuell sehe ich zwei Optionen:
- Encryption der data disk mit LUKS
- Meine SSD und NVME von Kingston bieten SED, "Server" unterstützen dies auch
Einfacher wäre aus meiner Sicht die Variante 2 SED. Wenn ich dies einrichte und der ZFS Pool schon besteht sind doch bestimmt aller bisherigen Daten nicht verschlüsselt sondern nur neue? Kann ich sowas wie dropbear auch für SED Kenntworteingabe nutzen?
Bei LUKS kann ich zwar die Disk verschlüssel (data), dann kann ich meines Wissens anch aber kein ZFS pool mehr initieren.
Wie geht ihr vor?
ok, gelöst. Replication läuft nun mit ZFS auf Basis von LUKs.
