Ist Proxmox eine Lösung für uns?

[Hannes.Hutmacher]

Hallo,

aktuell haben wir 8 alte Server, die wir virtualisieren wollen. Die Idee ist, dass wir zwei Knoten haben. Auf dem einen laufen alle VMs und auf dem anderen werden die VMs repliziert. Im Falle eines Ausfalls soll die zweite Maschine die VMs starten. Hyper-V fällt für uns weg. Der Grund liegt hier vor allem in der Lizensierung. Das ist aber ein anderes Thema und möchte ich hier auch nicht diskutieren.

Ein Aufsetzen von zwei Wirten mit KVM, DRBD, Pacemaker/Corosync, usw. ist nicht die erste Wahl, weil ich der Einzige bin, der sich damit auskennt.

Darum denken wir an Proxmox. Nun haben wir erfahren, dass dafür mindestens drei Knoten notwendig sind. Blöderweise haben wir aber nur zwei Brandabschnitte. Den Dritten gibt es erst in gut zwei Jahren. Nun fragen wir uns, ob der Betrieb von drei Knoten in zwei Brandabschnitten wirklich sinnvoll ist. "Fackelt" der falsche Brandabschnitt ab, so haben wir nichts vom Failover.

Wie könnte man das am besten lösen? Ist Proxmox für uns überhaupt eine brauchbare Lösung und eher ungeeignet?

Gruß und Dank im Voraus

 

[t.lamprecht]

Hi!

naja, für automatischen failover (HA) werden schon drei knoten (oder zwei + ein qdevice) benötigt, man will ja nicht dass wenn ein switch drauf geht beide knoten munter im split-brain weiter machen.
Natürlich ist dass im Brandfall mit zwei abschnitten nicht ganz ideal, in dem Fall ist ein manuelles eingreifen möglich. Vielleicht haben sie ja auch eine Schnittstelle zur Brandmeldeanlage und können damit was machen, wie viel man da reinsteckt kommt nur darauf an wie wichtig die Dienste sind und wie hoch man die Wahrscheinlichkeit fürs abfackeln eines Abschnitts annimmt.

Wenn sie generell nichts gegen etwas manuelles eingreifen haben kann auch mit zwei Knoten durchaus was angefangen werden..

Wie ist den dass mit dem Datenaustausch geplant? Ab drei könnte man über Ceph reden, hochverfügbar, skalierbar und sehr gut im Proxmox VE integriert.
Ansonsten wäre auch ZFS + replizierung eine Möglichkeit, hier ist man halt beim Replika immer etwas hinterher.
Ansonsten gibt's schon DRBD oder GlusterFS auch, da ist man halt wieder weniger in Proxmox VE integriert, und man muss sich etwas mehr damit befassen.

 

[Hannes.Hutmacher]

Hallo,

danke für deine ausführliche Antwort. Hatte nun Zeit ein bisschen über die Sache nachzudenken. Aber zuerst zu deiner Frage wie der Datenaustausch geplant ist. Wenn wir Proxmox einsetzen, so wären für uns drei Knoten selbstverständlich. Daraus ergibt sich die Entscheidung für Ceph automatisch, weil darüber alle VMs auf allen Knoten verteilt werden können und HA verfügbar ist.

Am Freitag hatten wir ein Telefonat mit einem Mitarbeiter eines Serveranbieters, der sich laut eigener Aussage mit Proxmox auskennt. Er meinte, dass er keine drei Knoten auf zwei Räume aufteilen würde, weil dann zwei zusammen in einem Brandabschnitt stehen. Würden beide Knoten ausfallen, so würde das Cluster wegen Ceph (3/2) zum Stillstand kommen. Im ersten Moment habe ich mich damit geschlagen gegeben, aber ein Weilchen später kam ich, wie du vorgeschlagen hast, auch auf den Gedanken, dass man die VMs doch manuell auf dem einen übrig gebliebenen Knoten starten können müsste. Hier wäre es schön, wenn du mich jetzt ausbremst, falls ich falsch liege.

Ich muss sagen, dass ich nach wie vor keinen Grund mehr sehe Proxmox mit drei Knoten in zwei Brandabschnitten nicht einzusetzen. Die Verbindung von Brandabschnitt 1 zu 2 ist redundantes LWL (vorraussichtlich 50 Gbit, der Kosten wegen). Ein Defekt eines Switches wird nicht das Problem werden, da wir die Anbindung direkt Server zu Server machen möchten. Oder spricht da etwas gegen? Der dritte Brandabschnitt wird in zwei Jahren (ein drittes Gebäude auf dem Gelände mit Technikraum) hinzukommen. Wären also zwei Jahre zu überbrücken. Machen oder besser lassen?

Über ein bisschen Starthilfe, um möglichst alles bedacht zu haben, wären wir sehr dankbar. Je länger wir uns mit dem Thema Virtualisierung (mit HA) beschäftigen, desto mehr Für und Wider erhalten wir von verschiedenen Leuten. Selbstverständlich kommen widersprüchliche Aussagen zusätzlich oben drauf, was uns die Entscheidung nicht leichter macht.

Für ein paar erleuchtende Worte wäre ich sehr dankbar, denn ich glaube, dass Proxmox das ist was wir einsetzen sollten. Zumal KVM bei uns an anderer Stelle schon eingesetzt wird somit nichts Unbekanntes für uns ist.

Gruß und Dank aus Köln

 

[sb-jw]

aber ein Weilchen später kam ich, wie du vorgeschlagen hast, auch auf den Gedanken, dass man die VMs doch manuell auf dem einen übrig gebliebenen Knoten starten können müsste. Hier wäre es schön, wenn du mich jetzt ausbremst, falls ich falsch liege.

Wenn die Min Size vom CEPH Pool nicht mehr erfüllt wird, wird der CEPH, sofern es noch läuft wegen der nicht mehr verfügbaren Mons, nur noch im Read Only arbeiten. Hier solltest du dich mit CEPH und dessen Konzept vertraut machen, denn auch hier brauchst du ein Quorum, damit es läuft und CEPH funktioniert nicht mehr ohne, da gibt es kein "Force Online". CEPH wurde für höchste Verfügbarkeit und Datensicherheit ausgelegt.

Ein Defekt eines Switches wird nicht das Problem werden, da wir die Anbindung direkt Server zu Server machen möchten. Oder spricht da etwas gegen?

Ja, mehr als genug. Wie willst du denn erweitern? Wie willst du hier 3 Mons ins Netz hängen? Uswt... Bitte einfach zwei Switche pro Brandabschnitt im VC (Juniper) oder besser mit MLAG (Arista) verwenden.

Je länger wir uns mit dem Thema Virtualisierung (mit HA) beschäftigen, desto mehr Für und Wider erhalten wir von verschiedenen Leuten. Selbstverständlich kommen widersprüchliche Aussagen zusätzlich oben drauf, was uns die Entscheidung nicht leichter macht

Dann Dreh den Spieß doch mal um, welche Vorteile siehst du von Baremetal? Ich gar keine mehr. Du hast keine Redundanz, geht das Mainboard kaputt oder das Netzteil ist der Server aus. Geht der RAID Controller kaputt könnten alle Daten vollständig zerstört sein, geht eine Festplatte im RAID 1 kaputt sind deine Daten auch stark gefährdet. Du kannst nicht einfach erweitern, du kannst nicht einfach die Hardware ohne Ausfall durch neue ersetzen. Du kannst etliche Services und Server auf einem Server betreiben, was die Laufkosten reduziert, deine Datensicherung kannst du Zentrale ansteuern und durchführen usw. Usw.

 

[Hannes.Hutmacher]

Wenn die Min Size vom CEPH Pool nicht mehr erfüllt wird, wird der CEPH, sofern es noch läuft wegen der nicht mehr verfügbaren Mons, nur noch im Read Only arbeiten. Hier solltest du dich mit CEPH und dessen Konzept vertraut machen, denn auch hier brauchst du ein Quorum, damit es läuft und CEPH funktioniert nicht mehr ohne, da gibt es kein "Force Online". CEPH wurde für höchste Verfügbarkeit und Datensicherheit ausgelegt.

Danke für die Info. Das mit dem Quorum hatte ich schon aus dem Post von t.lamprecht verstanden. Das " in dem Fall ist ein manuelles eingreifen möglich" bestätigte für einen Moment lang meine Hoffnung, dass wir die VMs auch so starten könnten.

Bitte einfach zwei Switche pro Brandabschnitt im VC (Juniper) oder besser mit MLAG (Arista) verwenden.

Danke für den Hinweis.

Dann Dreh den Spieß doch mal um, welche Vorteile siehst du von Baremetal? Ich gar keine mehr. Du hast keine Redundanz, geht das Mainboard kaputt oder das Netzteil ist der Server aus. Geht der RAID Controller kaputt könnten alle Daten vollständig zerstört sein, geht eine Festplatte im RAID 1 kaputt sind deine Daten auch stark gefährdet. Du kannst nicht einfach erweitern, du kannst nicht einfach die Hardware ohne Ausfall durch neue ersetzen. Du kannst etliche Services und Server auf einem Server betreiben, was die Laufkosten reduziert, deine Datensicherung kannst du Zentrale ansteuern und durchführen usw. Usw.

Danke für deine ausführliche Antwort. Ich habe mich nicht verständlich genug ausgedrückt. Die Frage war nicht, ob Virtualisierung Sinn macht, sondern welcher Hypervisor eingesetzt werden soll. Der eine sagt "3 Server in 2 Brandabschnitten macht keinen Sinn", der nächste sagt "doch, kannst du so machen". Nur als Beispiel. Doch was ist "best practice" in diesem Fall?

Wenn ich eine Quorumdisk hinzufüge, dann habe ich wieder eine gerade Zahl. Die Verteilung könnte also 4/2 sein. Müsste es nicht ungerade sein oder kann man auf die Art die zwei Jahr gut überbrücken?

 

[HBO]

Ich habe das folgendermaßen gelöst (mir reicht es aber, dass ich 1x Nachts ein ZFS Sync mache):
2 Nodes ohne Cluster, beide mit ZFS. Primäre und aktive Node synct das ZFS System auf Node 2 in der Nacht. Fällt Node 1 aus starte ich auf Node 2 die VMs und gut ist. Geht halt in meinem Fall (mit Pech) 1 Tag Arbeit verloren.
Mit ZFS Sync habe ich mich aber noch nicht soweit beschäftigt ob man dies regelmäßig und während des Betriebes durchführen kann, die VMs fahren für den ZFS Sync in der Nacht runter und starten danach wieder.

 

[Hannes.Hutmacher]

Danke für deine Antwort. Ist eine Lösung, die ich mit in die Besprechung heute Nachmittag nehmen könnte. Live-Sync wäre mir zwar lieber, aber man kann nicht alles haben.

 

[wolfgang]

Ob man sync oder async braucht, muss jeder selber entscheiden.
Meiner Meinung nach ist sync über mehrere DC/Brandabschnitte nicht möglich.

Selbst DRBD unterscheidet in 3 Protokolle[1].

Und die wenigsten verwenden Protokoll C was das einzige wirkliche sync ist.
Protokoll C ist langsam weil die Daten auch auf der remote Seite geschrieben werden müssen.
Wenn Protokoll A oder B verwendet wird, sind wir schon im asynchronen Bereich angelangt.
Da nur lokal wirklich geschrieben ist.
Protokoll B sagt nur das die Daten am Remote Host angekommen sind, also wie ein Raid ohne BBU.
Und Protokol A ist aysncron.

Ceph ist immer synchron, das geht aber auf Kosten der benötigten Hardware minimal Anforderungen.
Oder es wird sehr langsam, wie alle 100% synchronen Technologien.

ZFS mit Replika kann alle 1 Minute gesynct werden und es wird nur das komprimierte delta gesendet.
Die einzelne syncs sind immer konsistent und damit immer lauffähig.

Das ist bei semi-sync Technologien nicht gewährleistend.

GlusterFS ist eigenlich asyncron.

1.) https://docs.linbit.com/docs/users-guide-9.0/#s-replication-protocols

 

[Hannes.Hutmacher]

Danke für die Antwort.

ZFS mit Replika kann alle 1 Minute gesynct werden und es wird nur das komprimierte delta gesendet.
Die einzelne syncs sind immer konsistent und damit immer lauffähig.

Bin bei Recherche über OpenE gestolpert und hatte ein nettes Gespräch mit einem CTO. Dachte, dass vielleicht ein Storage (wie OpenE) hilfreich sein könnte. Dabei erklärte der nette Herr mit polnischem Akzent, dass ZFS eine Synchronisierung bietet. Wird wohl Mirror genannt. Nun sehe ich, dass Proxmox diese Möglichkeit nicht nutzt (oder irre ich mich?) und frage mich wieso. Wenn ich das richtig sehe, dann wird nur eine snapshotbasierte Lösung verwendet. Gibt es einen Nachteil bei ZFS, der Proxmox davon abgehalten hat?

Danke für eure Mühe und Geduld.

 

[HBO]

ZFS mit Replika kann alle 1 Minute gesynct werden und es wird nur das komprimierte delta gesendet.
Die einzelne syncs sind immer konsistent und damit immer lauffähig.

Damit hätte man doch eigentlich eine recht gute Ausfallsicherheit da die Syncs konsistent sind. Also könntest du in diesem Fall meinen Aufbau nehmen mit minütlichem Sync. Ist kein HA ansich mit automatischen Start auf anderer Node, aber man erhällt konsistente Daten.

https://pve.proxmox.com/wiki/PVE-zsync

 

[wolfgang]

Da OpenE kein OpenSource ist kann ich nur spekulieren was sie genau machen.
Was ich aber 100% hat ZFS keine netzwerk mirror funktion hat.

Ich glaube sie machen einen mirror wobei eine disk per iscsi in den anderen Node bereit gestellt wird.
Oder sie machen es gleich wie wir mit sehr kleien delta und sagen es ist syncron.