[SOLVED] Gemischter Cluster AMD/Intel - wie aufteilen, welcher CPU Typ?

[Firebat]

Hallo in die Runde,
wir sind aktuell dabei unsere VMware-Umgebung durch Proxmox zu ersetzen. So zumindest die grobe Idee. Bevor ich das aber "scharf schalte", habe ich noch zwei oder drei kleinere Fragen, die mir die Doku auch nicht abschließend beantwortet.

Zum einen die Frage, wie man die Hardware in sinnvolle "Unterkategorien" einteilt. Aus dem vCenter bin ich es bisher gewohnt, dass ich die Cluster (u.a.) nach verbauter CPU sortiere, so wie hier:


Lässt sich diese Darstellung oder Einteilung in Proxmox auch abbilden? Oder ist es sinnvoller, alle PVE-Hosts einem Cluster zuzuordnen und die logische Einteilung dann anders vorzunehmen? Wenn ich die Doku richtig deute, dann heißt es sinngemäß "ja, mehrere Cluster kann man machen, sollte man aber nicht". Auch wenn es so explizit da nicht steht... Ich habe es bisher auch noch nicht selbst getestet, aber stellt das Webinterface eines PVE-Hosts dann auch mehere Knoten dar, die verwaltet werden können, wenn sie einem Cluster zugeordnet sind?

Meine andere Frage zielt auf den CPU-Typ ab, mit dem man die Maschinen in einer gemischten Umgebung am besten betreibt. Im Prinzip würde es mir reichen, wenn ich die Maschinen, die bisher auf AMD Hardware liefen (alles EPYC 7001 und 7002) weiterhin nur auf AMD Hardware betreibe. Und die Intel-VMs dann eben nur auf Intel-Hardware (alles älteres Zeug, die neuste CPU müsste ein Xeon 2640 v3 sein). Grundsätzlich scheint es ja aber auch möglich, Live-Migration auch zwischen Intel und AMD machen zu können, sofern die CPU Flags passen. Das wäre natürlich eine echte Verbesserung zum jetzigen Zustand. Wenn ich meine virtuellen Maschinen aber migriere, will ich sie am besten nur einmal anfassen, alles richtig einstellen und dann in Frieden lassen.

Es handelt sich dabei um Linux- und Windows-Maschinen. Bei Linux mache ich mir keinen Kopf, aber den Windows-Kisten möchte ich nicht (im schlimmsten Fall) x-verschiedene CPUs zumuten. Oder ist die Verwendung vom CPU-Typ "Host" auch kein Problem mehr? Es sei gesagt, da ist noch ein bisschen legacy stuff (Server 2008 R2 als ältestes Beispiel) dabei...

Danke vorab für eure Unterstützung

 

[Kiotsoukis]

Praxisantwort: mach einen Cluster mit Ceph-Unterbau und teile die Nodes nach HA-Gruppen auf.

Gerade bei Windows VMs hast Du ja das Problem, dass sie nur auf den lizensierten Nodes laufen dürfen, da bietet sich eine geschlossene HA-Gruppe an.

Welcher Prozessor de facto auf dem Node werkelt dürfte keinen Unterschied machen.

 

[gmed]

Nun, das mit der CPU macht schon nen Unterschied.
Wenn in der VM CPU-Type Host ist und die migrierst von Intel nach AMD, dann denke ich schon , dass sich das bemerkbar macht.
Anderst sieht es aus, wenn der CPU-Type kvm64 usw. ist. Das sollte auf allen Nodes funktionieren.

 

[Firebat]

Praxisantwort: mach einen Cluster mit Ceph-Unterbau und teile die Nodes nach HA-Gruppen auf.

Gerade bei Windows VMs hast Du ja das Problem, dass sie nur auf den lizensierten Nodes laufen dürfen, da bietet sich eine geschlossene HA-Gruppe an.

Welcher Prozessor de facto auf dem Node werkelt dürfte keinen Unterschied machen.

Storage brauche ich nicht, also zumindest nicht als HCI. ;-) Lizenzierung ist auch kein Problem, die sind ja jetzt schon für alle Hosts entsprechend lizenziert. Ist also auch kein Hinderungsgrund. HA und Lizenzmobilität werden entsprechend berücksichtigt. Mir geht es eher darum, wie ich die Aufteilung mache. Ob einen großen Cluster oder mehrere, aufgeteilt nach CPU-Hersteller.

Zum Migrieren hätte ich gerne einfach ein paar Praxisbeispiele gehört, wie andere das machen. Danke euch aber auf jeden Fall schon für den Input.

 

[Kiotsoukis]

Die Migration zwischen Clustern ist etwas umständlich und geht eigentlich nur über ein Backup.

 

[Falk R.]

HI,
eine Aufteilung wie im vCenter ist leider nicht möglich. Eine GUI stellt auch immer nur einen Cluster dar.
Die Aufteilung nach HA Gruppen ist eine gute Möglichkeit.
Live Migration zwischen Inten und AMD empfehle ich gar nicht. Erstens hast du die CPU Kompatibilität auf einen so kleinen Nenner geschrumpft, dass due zu viele CPU Features verschenkst und die Windows Kisten werden das trotzdem nicht mögen.
Die werden dich dann nur mit mega schlechter Performance bestrafen, aber das muss nicht sein.
Meine Empfehlung, übernehme deine EVC Cluster Einstellungen nur mit etwas Umdenken. Die AMD Kisten in eine HA Gruppe und die VMs auf die Epyc 7001 Features begrenzen. Genauso für die Intel Kisten eine HA Gruppe, wo du die CPU features auf die älteste Intel CPU einstellst. Genauso wie die EVC Level in den Clustern, im vCenter.

Meine Frage an dich,
Wie möchtest du das Thema Storage realisieren. Hier gibt es erhebliche Unterschiede beim Handling zu VMFS unter vSphere.

 

[Firebat]

Das ergibt Sinn, denke ich. Danke.

Zum Thema Storage: aktuell haben wir einen Mix aus iSCSI mit VMFS und NFSv3. Ich würde zukünftig, um das Handling zu vereinfachen, nur auf NFS setzen. Habe also ein/mehrere dedizierte(s) Storage(s), die per NFSv3 verfügbar gemacht werden. Außer jemand sagt mir, mit Begründung, dass das die dümmste aller Ideen wäre.

Ceph würde ich mir gerne ansehen, aber ich ziehe nicht los und setze auf eine Technologie die ich noch nicht aus der Praxis kenne. Hyper Converged Infrastructure ist aktuell kein Thema, das hatte ich oben ja schon kurz angeschnitten. Wir setzen also ganz klassisch auf Maschinen für Virtualisierung und auf andere Maschinen nur für Storage. Die Storages existieren (teilweise) schon und bei einer Neuanschaffung bin ich flexibel, NFSv3 kann ja eigentlich jeder...

Bei der Migration würde ich zusehen, dass ich alle Maschinen auf qcow2 Festplatten umstelle, um Live-Snapshots etc. zur Verfügung zu haben. Musst du noch konkretere Dinge wissen oder reicht das als grober Umriss?

 

[Kiotsoukis]

Zum Thema Storage: aktuell haben wir einen Mix aus iSCSI mit VMFS und NFSv3. Ich würde zukünftig, um das Handling zu vereinfachen, nur auf NFS setzen. Habe also ein/mehrere dedizierte(s) Storage(s), die per NFSv3 verfügbar gemacht werden. Außer jemand sagt mir, mit Begründung, dass das die dümmste aller Ideen wäre.

Ceph würde ich mir gerne ansehen, aber ich ziehe nicht los und setze auf eine Technologie die ich noch nicht aus der Praxis kenne.

Ceph und die gute Integration in Proxmox war für uns einer der Hauptgründe umzusteigen. CephFS statt NFS bringt auch ein paar Vorteile, wir nutzen es allerding nur unter Linux, https://docs.ceph.com/en/latest/cephfs/ceph-dokan/ habe ich noch nicht getestet. Zusätzlich kannst Du noch das Rados Gateway als S3 Speicher nutzen, s3cmd werkelt ohne zu meckern.

 

[Falk R.]

Wie ich auch, bist du von VMFS und dem NFS Handling des ESXi verwöhnt. Mit NFS wird das vermutlich auch gut laufen, aber iSCSI und FC fällt in der Regel aus, da kein Clusterfähiges Filesystem wie VMFS da ist. Du hast dann Einschränkungen bezüglich Snapshots und Backup.
Ich hatte vor Proxmox meinen Cluster schon auf HyperV mit S2D (Storagevirtualisierung) umgestellt. Daher habe ich unter Proxmox direkt auf Ceph gewechselt. HCI macht das Leben deutlich einfacher und günstiger.
Beim nächsten Hardwarekauf würde ich auf jeden Fall HCI ins Auge fassen.

 

[Firebat]

Das letzte Storage, welches per FC angebunden ist, geht mit dem Wechsel von VMware auf Proxmox in den Ruhestand. Da mache ich mir keine Sorgen. Zumindest im Storage-Bereich nicht. ;-)

HCI ist ja ein bisschen eine Philosophiefrage. Ich finde die Idee grundsätzlich nicht verkehrt, kann unsere Infrastruktur aber nicht auf einen Schlag umstellen. Das hält mich bisher davon ab. Aber Ceph habe ich schon lange auf dem Radar.

Meine Ausgangsfragen sind im Prinzip aber alle beantwortet. Danke für die Unterstützung.