[SOLVED] Mixed CPU Cluster, mit Custom CPU Models möglich?

[InZaneDanii]

Hallo,

Wir haben derzeit 3x PVE Server mit dual Socket Intel(R) Xeon(R) Gold 6442Y.
Wir überlegen derzeit, ob wir unseren PVE Cluster mit mehreren Hosts weitern sollen. (Uns gehen langsam die Ressourcen für HA aus).
Da die Hardware Preise ziemlich teuer sind, überlegen wir einen Host, mit einer AMD CPU.

Mir ist bekannt, das Mixed CPU Cluster nicht empfohlen werden kann, vor allem mit den Komplikationen die dadurch entstehen könnten, jedoch haben wir uns gefragt, ob es nicht möglich ist, Mixed Cluster halbwegs Zuverlässig zu betreiben (mit HA-Live Migration Möglichkeit) wenn ein Custom CPU Model erstellt wird, welches nur die Features aktiviert, welche beide CPU Hersteller enthalten.

Habt ihr damit schon Erfahrungen? Gibts argumente dies nicht zu tun, oder sogar eventuelle Vorteile?

 

[Bu66as]

Custom CPU Models gehen in PVE grundsätzlich (/etc/pve/virtual-guest/cpu-models.conf), das ist aber gar nicht der Knackpunkt. Live-Migration Intel <-> AMD funktioniert auch mit gemeinsamen Mindest-Features nicht zuverlässig, weil sich unter dem laufenden Gast u.a. Vendor-ID und verschiedene CPUID-Leaves ändern. Windows quittiert das gern direkt mit BSOD, Linux macht teils erst Stunden später komische Sachen. QEMU/KVM supportet das schlicht nicht, egal wie sauber du das Modell schneidest.

Was dagegen sauber läuft: HA-Failover, der Gast startet dabei ja neu. Mit x86-64-v2-AES oder einem eigenen Modell startet die VM auf beiden Seiten problemlos. Heißt für dich: Wartungsfenster auf dem AMD-Host = VMs runterfahren statt evakuieren. Wenn du das nicht willst, würd ich mit Node-Affinity-Rules arbeiten, sodass die migrationskritischen VMs im Intel-Pool bleiben und auf dem AMD-Host nur Zeug läuft, das einen Reboot verträgt.

Was mir bei dem Ausbau noch auffällt: mit 4 Nodes bleibt das Quorum bei 3, du verträgst also weiterhin nur einen Ausfall. Der vierte Host bringt dir RAM/CPU-Reserve, aber keine zusätzliche Fehlertoleranz. Was hängt denn als Storage drunter, Ceph oder ZFS-Replikation? Bei Ceph wär ein einzelner andersartiger Node nochmal ein eigenes Thema.

 

[InZaneDanii]

Custom CPU Models gehen in PVE grundsätzlich (/etc/pve/virtual-guest/cpu-models.conf), das ist aber gar nicht der Knackpunkt. Live-Migration Intel <-> AMD funktioniert auch mit gemeinsamen Mindest-Features nicht zuverlässig, weil sich unter dem laufenden Gast u.a. Vendor-ID und verschiedene CPUID-Leaves ändern. Windows quittiert das gern direkt mit BSOD, Linux macht teils erst Stunden später komische Sachen. QEMU/KVM supportet das schlicht nicht, egal wie sauber du das Modell schneidest.

Was dagegen sauber läuft: HA-Failover, der Gast startet dabei ja neu. Mit x86-64-v2-AES oder einem eigenen Modell startet die VM auf beiden Seiten problemlos. Heißt für dich: Wartungsfenster auf dem AMD-Host = VMs runterfahren statt evakuieren. Wenn du das nicht willst, würd ich mit Node-Affinity-Rules arbeiten, sodass die migrationskritischen VMs im Intel-Pool bleiben und auf dem AMD-Host nur Zeug läuft, das einen Reboot verträgt.

Was mir bei dem Ausbau noch auffällt: mit 4 Nodes bleibt das Quorum bei 3, du verträgst also weiterhin nur einen Ausfall. Der vierte Host bringt dir RAM/CPU-Reserve, aber keine zusätzliche Fehlertoleranz. Was hängt denn als Storage drunter, Ceph oder ZFS-Replikation? Bei Ceph wär ein einzelner andersartiger Node nochmal ein eigenes Thema.

Danke für deine Antwort!

Darunter hängt eine shared Storage mit NFS.
Dass wir mit 4 Nodes dennoch nur einen Ausfall ertragen können, ist uns bewusst. Sooo wichtig sind uns die meisten VMs dann auch wieder nicht

Aber ich denke, mit deiner tollen Antwort werde ich hier den Thread zu machen, leider hatte ich die Hoffnung, dass es besser / ohne gröbere Schmerzen möglich sein müsste. Dann back to Intel.