[TUTORIAL] Kleiner Gamechanger bei der Windows Migration zu Proxmox

Da ich nun zum leidtragenden geworden bin, mitten in der Umstellung und im Unternehmen sehr stark auf KI zur Wissensfindung gesetzt wird, teilweise vermehrt ohne kritische Hinterfragung (mit teils möglichen katastrophalen Auswirkungen) und ich mich hierdurch durch unzählige Beiträge wühlen musste, ist es mittlerweile soweit das ich mein Wochenende nutze.
Da läuft dann aber etwas verkehrt!

Letztlich kann ich zwar darauf hinweisen aber als jemand der noch in der Probezeit ist, ist es natürlich schwierig offen zu sagen, das Teile der Planung auf ChatGPT-Halluzinationen basieren (z.B. Proxmox 9.1.2= Bullseye Paketquellen hinzufügen) und so nicht umsetzbar sind.
Wann willst Du es denn dann sagen?
Das was faktisch nicht korrekt ist und mit Argumenten und Quellen belegt werden kann, muss ungeschönt auf den Tisch! Da spielt Probezeit erst Recht keine Rolle! Wer sagt Dir denn, das das kein Test ist? Bring das richtig rüber und du wirst sehen ob dein neues Unternehmen und deine Kollegen wirklich die richtig Stelle/Firma sind. Das "rauszögern" kann dir später auch mal auf die Füße fallen oder man Dank dir für dein Engagement während der Umstellung, aber leider.....
My2Cent
 
Last edited:
  • Like
Reactions: Johannes S
Tatsächlich ist auch das mit heißer Nadel und ohne viel Erfahrung (mittels ChatGPT) in die Wege geleitet worden, d.h. es gibt aktuell 1x richtigen Proxmox Host (Node1) mit echter Serverhardware und zusätzlich eine Workstation (Node3/Witness) mit durchgereichter GPU für On-Prem KI-Modelle, die ebenfalls Proxmox nutzt und im späteren Setup einerseits als dritte Node3&Witness genutzt werden soll.

Im Moment müssen hierzu erstmal die VMs vom aktuellen HyperV HV migriert werden, damit dieser dann hierauf als zweiter Proxmox Node in Betrieb genommen werden kann, das gesetzte Ziel ist es zusammen mit Ceph zu nutzen, wobei hierzu meine praktische Erfahrung aus meinen Homelab nicht reicht (nur zwei Nodes + RPI als QDevice) um zu bewerten ob in so einer Konstellation Proxmox Ceph überhaupt realisierbar und sinnvoll ist, da sich zumindest die Workstation massgeblich von den anderen beiden Server unterscheidet und mein bisheriger Wissenstand hierzu,der war, dass Proxmox mit Ceph es voraussetzen würde.

Meiner Recherche nach wären das bestenfalls drei völlig identische Knoten (Serverhardware), möglichst (all-)Flashspeicher und min. 10GE-Netzwerk mit getrennten Schnittstellen für Ceph-Kommunikation und Management, wobei das für die stellvertretend genutzte Workstation nicht der Fall ist und Ceph mit zwei Knoten + Witness, wenn ich das noch richtig in Erinnerung habe, nicht möglich oder nicht zielführend ist.

Leider ist das Projekt nicht aus meiner Feder und wie viele andere ITler kennen, mit möglichst minimalem Budget ausgestattet, weswegen auch sowas wie ein kleiner 10GE Switch für die Kommunikation untereinander noch diskutiert werden muss.

Letztlich kann ich zwar darauf hinweisen aber als jemand der noch in der Probezeit ist, ist es natürlich schwierig offen zu sagen, das Teile der Planung auf ChatGPT-Halluzinationen basieren (z.B. Proxmox 9.1.2= Bullseye Paketquellen hinzufügen) und so nicht umsetzbar sind.

Ich schätze dann das folgende Aussage hier aus dem Forum zutreffend ist und sich ein zwei Knoten Ceph-Cluster mit Witness im Zweifelsfall sehr unvorteilhaft für die Datenintegrität und Uptime auswirken kann? ^^




Vielen Dank für deine Rückmeldung, das hilft mir sehr
:)

#wissenschwamm
Bei 2 Nodes kein Ceph nutzen, außer in einer Spielumgebung zum testen.
ZFS Replikation wäre da das Feature der Wahl für dich.
Wenn du frisch im Job bis und einen guten Start hinlegen willst, könnte ich dir anbieten wir sprechen mal 1-2 Stunden per Discord oder so.
Dann erkläre ich dir gern das Standardvorgehen und die üblichen Stolperfallen.
HyperV kenne ich erst seit 2013, aber auch da weiß ich was du beachten musst.
 
Ich schätze dann das folgende Aussage hier aus dem Forum zutreffend ist und sich ein zwei Knoten Ceph-Cluster mit Witness im Zweifelsfall sehr unvorteilhaft für die Datenintegrität und Uptime auswirken kann? ^^
Das ist noch sehr vorsichtig formuliert. Ohne schnelles Netzwerkverbindungen ( 10 Gbit/s ist das absolute Minimum, außerdem sollten Corosync, Ceph und der eigentliche VM-Traffic strikt getrennt werden!) mindestens drei Knoten und Enterprise-SSDs mit power-loss-protection ( pro Knoten vier Stück ) wird das ein Setup mit bescheidener Performance und "build to break". Ich hoffe deine KI-Fans glauben wenigstens der Hersteller-Doku statt der KI:
https://pve.proxmox.com/wiki/Deploy...r#_recommendations_for_a_healthy_ceph_cluster


Ebenfalls lesenswert @UdoB writeup zu kleinen Clustern:

Er unterstellt allerdings, dass man gerne auch Cephs Selbstheilung nutzen bzw. den Ausfall von zwei Knoten abfangen will, daher seine Empfehlung für mindestens vier Knoten.
Wenn das Hauptszenario eine Hochverfügbarkeit während geplanter Wartungen ( wo immer nur ein Host down ist) oder Ausfall eines Knotens ist, tun es auch drei Server.

Solltet ihr aber kein Budget für die passende Hardware haben, würde ich an eurer Stelle eher auf Storage-Replication mit zfs setzen: https://pve.proxmox.com/wiki/Storage_Replication

Damit werden die vms und container regelmäßig auf den oder die Zielknoten repliziert ( default alle 15 Minuten, kann auf eine Minute reduziert werden), bei aktivierten HA wird die VM/der Container dann auf den anderen Knoten gestartet ( mit minimalen Datenverlust, also 1/15/whatever Minuten ). Wenn ein solcher Datenverlust tragbar ist, kann das eine kostensparende Alternative zu ceph sein.

Das geht selbst in einen zwei-Knoten-Cluster, der aber trotzdem noch einen dritten Knoten fürs quroum braucht. Der Clou: Das kann auch ein sogenanntes qdevice sein, ein Debian-Linux, wo ein kleiner schlanker Dienst fürs Quorum sorgt. Selbst ein Raspberry kann das ;)

Im Proxmox-Unfeld wird stattdessen gerne ein dritter Server ( gerne mit geringeren Ressourcen als die Virtualisierungshost) genommen, der dann auch als ProxmoxBackupServer fungiert.
Standardmäßig kommt dann aber jeder mit Konsolenzugang auf die Virtualisierungsknoten auch per ssh auf dem Backupserver, das lässt sich aber durch ein Setup wie es Proxmox Entwickler Aaron beschreibt lösen:

Im Grunde wird auch auf den dritten Server ProxmoxVE installiert, aber NICHT in den Cluster aufgenommen. Stattdessen fungiert ein Container oder eine kleine VM als qdevice. Außerdem wird der ProxmoxBackupServer parallel zum PVE installiert, so hat man dann qdevice ubd Backups auf dem gleichen Knoten und doch sauber getrennt.
Wenn ihr also noch kein Backupkonzept für eure VMs habt ( Veeams Proxmoxsupport kann meines Erachtens nach derzeit bestenfalls als public beta bezeichnet werden) und die Ressourcen des dritten Knotens nicht besucht, wäre das in meinen Augen die budgetfreundlichste Variante.

Davon abgesehen würde ich dir empfehlen die Probezeit ( gilt für beide Seiten ) zu nutzen, um weitere Bewerbungen zu schreiben, auf Dauer gegen bullshit-as-a-service-ki-Dienste zu argumentieren würde ich mir nicht dauerhaft geben wollen ;)
 
Last edited:
  • Like
Reactions: ThoSo