VMware ESXi Hypervisor (Labor/Backup Server) - EPYC vs. Xeon

iSource

Lt. Junior Grade
Registriert
Juli 2009
Beiträge
327
Abend zusammen,

der Thread passt sowohl hier als auch in den Bereich "Virtualisierung und Emulation". Habe mich mal für hier entschieden. Sollte es jemand doch eher in dem anderen Bereich verorten, gerne verschieben.

Zum Thema: Für die Laborumgebung und als Backup Hypervisor steht daheim der Kauf eines weiteren Servers an. Dabei bin ich mir derzeit noch unsicher, auf welchen der beiden CPU-Hersteller ich setzen soll - insbesondere deshalb, weil sich beide preislich kaum was nehmen.

Um den Anwendungsfall mal kurz zu umreißen:
  • VMware ESXi / vSphere Hypervisor
  • Hosting von ungefähr 7-10 virtuellen Maschinen
    • der Großteil davon Sekundär- bzw. Backup-Maschinen von Diensten/Systemen, deren "Partner-VMs" auf dem primären VMware ESXi laufen (z.B. zweiter Microsoft Domain Controller, DHCP Failover Server (ISC), DNS Server (Pi-hole), und weitere)
    • allerdings werden zusätzlich auch einzelne, unkritische VMs darauf laufen
Dafür habe ich mir nun je eine Variante mit einem aktuellen AMD EPYC und einem Intel Xeon zusammengestellt:

AMD
Samsung RDIMM 16GB, DDR4-2666, CL19-19-19, reg ECC [2x]​
Intel
Samsung DIMM 16GB, DDR4-2666, CL19-19-19, ECC [2x]​

Probleme habe ich aktuell mit zwei Punkten:
  1. Der Preis ist quasi identisch (~15 EUR Unterschied, konkret sind es 1.330 EUR (Intel) ggü. 1.345 EUR (AMD))
  2. Die Leistung ist offentischtlich ebenfalls nah beieinander.
Bei Punkt 1 betrachte ich das Gesamtsystem. Logischerweise kommen zu den drei Hauptkomponenten oben jeweils noch ein Gehäuse, Netzteil und mehrere SSDs. Bei dem Intel System kommt zusätzlich noch ein Lüfter dazu, der beim AMD System bereits mit der CPU bzw. dem Board kommt.

Bei Punkt 2 beziehe ich mich hauptsächlich auf Reviews auf/von ServeTheHome (z.B. hier oder hier). Der letzte Link behandelt zwar den Vorgänger E-2146G, was der Aussage zur Leistung zum E-2246G jedoch nicht entgegen stehen sollte.

Mehrere VMs heißt häufig: Multithread Performance ist in jedem Fall gut und wichtig. Allerdings scheint der Xeon trotz zweier "fehlender" Kerne (bzw. vier Threads weniger) in dem Bereich nicht ins Hintertreffen zu geraten.

Daneben fällt mir mindestens eine VM ein, die auf dem Server laufen wird, bei der der darin bereitgestellte Dienst nur auf einen Kern zurückgreifen kann - also ist auch Singlethread Performance gefragt. Eben diese ist beim Xeon wohl besser. Leider gibt es allgemein nicht viele Reviews zu den beiden CPUs, um die Tests von den STH Leuten zu verifizieren.

Bei den Stromkosten - und somit im Grunde auch bei der "Leistung pro Watt" - hat der EPYC die Nase vorn.

Was würdet ihr tun? Habe ich evtl. einen Aspekt übersehen/vergessen?

Über das ein oder andere Feedback bzw. etwas Input wäre ich wie immer dankbar.


Cheers,
iSource
 
Tjoa, der Xeon hat deutlich höheren Single-Thread... was auch kein Wunder ist, wenn man eine 80W-CPU gegen eine 55W-CPU vergleicht.

Ansonsten - wofür ist das System? Ist das produktiv?
Falls nicht - brauchst du überhaupt wirklich Server-Komponenten, ECC, etc? Das hat ja auch einen gewissen Aufpreis...

Sind Sicherheits-Aspekte wichtig? Weil bei Intel sind die Haufen an Problemen ja noch nicht in Hardware gefixt, AMD hat da viel weniger Ärger...

Ansonsten würde mich definitiv stören, das der Epyc 3251 Embedded ist, also nicht bei Bedarf später ausgetauscht werden könnte.
 
Rickmer schrieb:
[...] wofür ist das System? Ist das produktiv? [...]
Den Zweck des Systems hatte ich ja oben schon grob umschrieben. Grundsätzlich soll der Server als zweiter Hypervisor dienen, auf dem die Sekundär-/Failover-Instanzen von unterschiedlichen VMs laufen. Will heißen:
  • Eine DHCP Server VM (ISC dhcpd) läuft auf Hypervisor 1.
  • Eine Failover DHCP Server VM (ebenfalls ISC dhcpd) soll auf Hypervisor 2 laufen.
Gleiches gilt dann wie schon oben genannt u.a. für den Domain Controller, DNS Server und so weiter.

Raucht Hypervisor 1 ab, möchte ich fürs Netzwerk essenzielle VMs/Dienste bereits auf Hypervisor 2 laufen haben, die dann kurzfristig übernehmen können.

Neben dem Thema "Failover" sollen auf Hypervisor 2 auch noch ein oder zwei VMs laufen, die auf Hypervisor 1 organisatorisch nichts verloren haben.

Rickmer schrieb:
[...] brauchst du überhaupt wirklich Server-Komponenten, ECC, etc? [...]
ECC ist aus dem Grund wünschenswert, da eine der wichtigen VMs eine Sybase Datenbank bereitstellt. Da das System im Rack im Keller steht, ist BMC/IPMI übers Board erforderlich. Des Weiteren möchte ich den Hypervisor nicht auf einem Desktop-System laufen lassen.

Rickmer schrieb:
[...] Sind Sicherheits-Aspekte wichtig? Weil bei Intel [...] Haufen an Problemen [...] AMD [...] viel weniger Ärger [...]
Ist bekannt, allerdings handelt es sich nicht um eine Shared-User-Umgebung. Die VMs sind in einem weitestgehend geschlossenen Netz. Sollten Meltdown & Co. "geschehen", habe ich schon längst ein anderes Problem.

Rickmer schrieb:
[...] Ansonsten würde mich definitiv stören, das der Epyc 3251 Embedded ist, also nicht bei Bedarf später ausgetauscht werden könnte.
Da ich die Server (abgesehen von RAM oder SSD) nicht aufrüsten oder anderweitig verändern werde, spielt das im konkreten Fall keine große Rolle. Aber dein Punkt ist allgemein natürlich richtig.
 
Zuletzt bearbeitet:
Eigentlich solltest Du darueber nachdenken, eine Cluster zu fahren anstatt eines zweiten Hypervisors.
Alles was Du da oben an Diensten nennst waere damit in einer laufenden VM, egal welches Blech darunter Dir abraucht. Den Aufwand der "Partner-VM's" koenntest Du Dir sparen.

Ist das alles bei Dir zu hause?

Anyway.
Bevor Du Dich fuer irgendeuine HW entscheidest. Schau in die HCL bei VMware.
Ich persoenlich wuerde mehr zu dem XEON neigen. Einfach gefuehlt unkomplizierter.

BFF
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: tony_mont4n4
BFF schrieb:
Eigentlich solltest Du darueber nachdenken, eine Cluster zu fahren [...]
Guter Punkt und grundsätzlich richtig - hatte ich mir auch schon überlegt und durchgerechnet. Zumindest wenn wir vom gleichen Thema sprechen und du mit Cluster eine klassische vSphere HA meinst.

Der Komfortgewinn setzt aber einen zentralen Storage Pool voraus. Selbst wenn ich das ganze bspw. über iSCSI auf einem NAS in der Mittelklasse fahren würde, kommt mich das im Endeffekt teurer als mit einem zweiten, "kleinen" Hypervisor. Abgesehen davon kann der Hypervisor 1 ja einwandfrei laufen, die VM bzw. der entsprechende Dienst darin allerdings im Nirvana sein - wodurch die vSphere HA nicht greifen würde.

Oder sprichst du von einem anderen Konzept?

BFF schrieb:
Ist das alles bei Dir zu hause?
Steht im Keller daheim, ja.
 
Würde auch zu Cluster/HA tendieren, ist aber natürlich abhängig ob es so "redundant" ausgelegt werden soll vor allem wenn man die Kosten gegenüber stellt.
Ggf. wäre dann auch vSphere die Überlegung.

Bzgl. CPU Auswahl, wenn auf dem zweiten HV aber Backup VMs laufen sollen dann sollte die CPU Architektur idealerweise identisch mit der vom ersten HV sein, also Intel oder AMD.
Bin mir da leider nicht sicher wie sich das mit EVC und Single-Hosts beim ESXi verhält.

iSource schrieb:
Abgesehen davon kann der Hypervisor 1 ja einwandfrei laufen, die VM bzw. der entsprechende Dienst darin allerdings im Nirvana sein - wodurch die vSphere HA nicht greifen würde.

Dafür gibts ja Monitoring aber auch hier die Frage wie sich das bei Single-Hosts/ESXi verhält.
 
Du vergleichst hier in meinen Augen völlig unterschiedliche Plattformen. In meinen Augen ist der Epyc und der Xeon Entry die falsche Wahl. Mein Vorschlag wäre folgender:

AM4 Server Board (ggf. Bios Update notwendig): https://www.computerbase.de/preisvergleich/asrock-rack-x470d4u-a2009567.html

AMD Ryzen 7 3700X:
https://www.computerbase.de/preisvergleich/amd-ryzen-7-3700x-100-100000071box-a2064553.html

Passender ECC RAM (Wahlweise 2 oder 4 Riegel):
https://www.computerbase.de/preisvergleich/samsung-dimm-32gb-m391a4g43mb1-ctd-a2057207.html
 
Ich werfe mal einen Threadripper 1920X in die Runde.

Mehr Perfomance wirst Du für weniger als 250 Euro nicht bekommen.

ECC und Quadchannel werden auch unterstützt.
 
Falls es ein Cluster werden soll, brauchst du eine CPU des gleichen Herstellers wie im bereits vorhandenen ESX Host, sonst klappt es nicht mit vMotion.

Stichwort: EVC (wenn ich mich nicht irre)

Und einen gemeinsamen Storagepool brauchst du imho nur wenn du z.B. ein echtes Failover hast und willst das auch Storage vMotion automatisch bei einem Ausfall ausgeführt werden soll.

Wenn der zweite Host nur genutzt werden soll, wenn am ersten z.B. Wartungsarbeiten anstehen kannst du die VMDKs auch selbst davor auf den Storage des zweiten Hosts migrieren.

Bzgl. Leistungsunterschiede bzgl. der Threads kommt es auf deine Services an die du nutzen möchtest, viele Server Anwendungen profitieren aktuell noch eher von viel RAM und viel GHz statt vielen Threads.
 
Danke für die vielen Rückmeldungen! Ich befürchte allerdings, dass wir teilweise ein wenig vom Thema abkommen.

leipziger1979 schrieb:
[...] wenn auf dem zweiten HV aber Backup VMs laufen sollen dann sollte die CPU Architektur idealerweise identisch mit der vom ersten HV sein [...]
tony_mont4n4 schrieb:
Falls es ein Cluster werden soll, brauchst du eine CPU des gleichen Herstellers wie im bereits vorhandenen ESX Host [...]
Wie beschrieben ist mein Ziel keine HA-Umgebung wie von VMware definiert (inkl. vMotion bzw. EVC). Die Hypervisor sollen autark laufen, u.a. auch deshalb, weil hier kein vCenter läuft oder laufen wird.

tony_mont4n4 schrieb:
[...] Storagepool brauchst du imho nur wenn du z.B. ein echtes Failover hast und willst [...]
tony_mont4n4 schrieb:
[...] Wenn der zweite Host nur genutzt werden soll, wenn am ersten z.B. Wartungsarbeiten anstehen [...]
Es soll (wie im Eröffnungspost und #3 formuliert) eine Ausfallsicherheit bzw. Redundanz der Dienste gegeben sein, die in den VMs zur Verfügung gestellt werden, nicht aber für die Hypervisor. Wöllte ich das über ein VMware vSphere HA-Cluster machen, würde das zu höheren Kosten für Lizenzen, einem zentralen Storage Pool und mehr Konfigurationsaufwand führen.

Auch wenn das ohne Einwände eine oder die Lösung für die Ausfallsicherheit der Hypervisor wäre, ist das nicht mein Ziel für die konkrete Umgebung.

Nizakh schrieb:
In meinen Augen ist der Epyc und der Xeon Entry die falsche Wahl. Mein Vorschlag wäre folgender: [...] AMD Ryzen 7 3700X [...]
IBISXI schrieb:
Ich werfe mal einen Threadripper 1920X in die Runde. [...]
Auf Consumer Hardware möchte ich für den Server eigentlich nicht setzen. Zudem ist der 1920X allein schon weger seinen 180 Watt unvernünftig. Trotzdem danke für die Ideen!

BFF schrieb:
Schau in die HCL bei VMware.
Ja, das war auch eine meiner ersten Anlaufstellen bei der Auswahl.

Aktuell werden weder die Xeon E-22xx Serie noch die EPYC 3xxx Serie unterstützt. Da beide allerdings noch relativ frisch erhältlich sind und Xeon E-21xx und EPYC 7xxx in der Liste auftauchen, gehe ich stark davon aus, dass noch im Laufe des Jahres der offizielle Support dafür gegeben sein wird. Zudem ist man mit Supermicro bei VMware häufig auf der sicheren Seite.
 
Zuletzt bearbeitet:
Ich glaube du übertreibst es etwas bei der Hardware^^ Hast du vom bestehenden Host dir mal die Auslastung angesehen? Die meisten Router für zuhause greifen für DHCP auf dnsmasq oder isc-dhcp zurück, PiHole läuft flüssig auf nem Raspi, diese zwei VMs kannst also mit je einem oder zwei Kernen und je nem halben GB Ram. Wenn der Domain Controller nur DC spielt und nicht noch zig andere Aufgaben hat reichen da ebenfalls 1-2 Kerne und 4 GB Ram. Könntest überlegen auf Windows Server Core zu gehen um weitere Ressourcen zu sparen & Administration per RSAT von einem der Clients. Oder bei übertriebenem Basteltrieb: Linux + Samba4 als DC :D

Wenn du keinen Failover vor hast sondern Dienste redundant betreibst dann müssen im Fehlerfall ja auch keine VMs von Hypervisor_1 auf der neuen Kiste laufen und du brauchst nicht dafür Resourcen vorhalten.

Bedenke du kannst bei VMware CPU Kerne problemlos doppelt vergeben nur RAM sollte nicht mehrfach belegt werden.

Aus reiner Neugierde: Darf ich davon ausgehen, dass du den kostenlosen ESXi verwendest und falls ja: Wie hast du das Thema Backup realisiert?

Notiz am Rande: Rein theoretisch könnte man auch mit nur zwei Nodes einen HA Cluster bauen, jedoch nicht mit ESXi. Würde dafür DRBD für den Storage nutzen (quasi ein Raid 1 übers Netzwerk) und dann qemu/kvm oder Proxmox als fertige Lösung. Kann man machen, hat aber ein paar Stolpersteine die man beachten muss beim Setup/Planning.
 
iSource schrieb:
Auf Consumer Hardware möchte ich für den Server eigentlich nicht setzen.
Wo ist denn das ASRock Rack X470D4U Consumer Hardware? Out-of-Band Mgmt, ECC RAM, usw. sprechen eine andere Sprache würde ich meinen...
Nizakh schrieb:
 
snaxilian schrieb:
Ich glaube du übertreibst es etwas bei der Hardware^^ [...]
ISC DHCP, Pi-hole und Microsoft Domain Controller sind wie geschrieben nur Beispiele ;) Da läuft noch ein klein wenig mehr.

snaxilian schrieb:
[...] Wenn du keinen Failover vor hast sondern Dienste redundant betreibst dann müssen im Fehlerfall ja auch keine VMs von Hypervisor_1 auf der neuen Kiste laufen und du brauchst nicht dafür Resourcen vorhalten. [...]
Das wurde hier zwar von den anderen Teilnehmern behandelt und vorgeschlagen, möchte ich aber in der Tat nicht, wie auch schon erläutert.

Somit völlig richtig: Es sollen keine VMs von Hypervisor 1 auf Hypervisor 2 laufen, da auf Hypervisor 2 - auch im Normalbetrieb wenn Hypervisor 1 einwandfrei funktioniert - redundant die entsprechenden VMs/Dienste laufen.

snaxilian schrieb:
Darf ich davon ausgehen, dass du den kostenlosen ESXi verwendest und falls ja: Wie hast du das Thema Backup realisiert?
Ist richtig, es wird die kostenfreie Version verwendet (u.a. deshalb auch kein vCenter).

Die wichtigen VMs werden täglich über Veeam B&R gesichert und auf einem NAS abgelegt.

Ergänzung ()

Nizakh schrieb:
Wo ist denn das ASRock Rack X470D4U Consumer Hardware? [...]
Der Chipsatz sowie die Ryzen 3000 CPUs werden von AMD und auch allgemein in der Fachpresse als "für den Consumer Markt" behandelt.

Außerdem gibt es mit Ryzen 2000 und 3000 CPUs Probleme beim Betrieb von ESXi.
 
Zuletzt bearbeitet:
@iSource Jain, klar wird der Chipsatz so bezeichnet, da dieser ja fast ausschließlich auf Consumer Mainboards zum Einsatz kommt. Wahrscheinlich wäre es schlauer gewesen, man hätte die Ryzen CPUs + Chipsätze auch nochmal umgelabelt, dann wäre das nicht so missverständlich. Defacto sind Intel Xeon Entry CPUs (& Chipsätze) ja ebenfalls identisch zu ihrem "Consumer"-Pendant -> besitzten nur ein anderes Label + ECC Support. Den hast du ja bei jedem Ryzen, zumindest wenn das Mainboard dies unterstützt. Daher würde ich sagen: Bei AMD ist hier die Bezeichnung von Produkten nicht identisch zu Intel, aber es handelt sich nicht automatisch um Consumer Hardware.

In meinen Augen ist das X470D4U daher kein Consumer Produkt. Auch können die Ryzens dank ECC Support auch durchaus als Business Produkt bezeichnet werden. Letztendlich musst du das natürlich für dich selbst entscheiden. Ich finde das X470D4U gerade für solch kleine Server sehr interessant, da es alles mitbringt was dort benötigt wird.
Genauso wie die entsprechenden Ryzen CPUs alle benötigten Features mitbringen.

Bzgl. dem dem Thema ESXi und Ryzen = Das ist nicht mehr aktuell. Im Jahr 2017 gab es da durchaus Probleme, dass sich Ryzen CPUs mit ESXi nicht verstanden haben. Das wurde damals per Bios Update gelöst. Liegt aber weit in der Vergangenheit zurück. Alle anderen Probleme die man so liest hängen mit den Netzwerkadaptern zusammen. Wie du sicher weist unterstützt ESXi seit 6.0 keine Realtek Netzwerkchips mehr für den Hypervisor -> mit solchen Netzwerkadaptern hat man dann natürlich aufgrund fehlender Treiber Probleme. (Außer man passt das ESXi Image an) Viele Consumer Mainboards haben Realtek NICs.

Das X470D4U bietet an dieser Stelle: 2x Intel NICs. (Der Realtek Chip wird nur fürs BMC genutzt und steht im Hypervisor daher nicht zur Verfügung).

Bzgl. dem X470D4U, Ryzen 3000, ECC RAM und ESXi 6.7 U2 gibt es hier noch einen interessanten Erfahrungsbericht (scrollen erforderlich):
https://www.hardwareluxx.de/communi...4u-als-esxi-virtualisierungshost-1241079.html

Selbstverständlich kannst du auch etwas anderes kaufen, nicht falsch verstehen. Ich wollte mit dem Beitrag nur noch mal ein paar Dinge klarstellen. :)
 
Zuletzt bearbeitet:
iSource schrieb:
Ist richtig, es wird die kostenfreie Version verwendet (u.a. deshalb auch kein vCenter).

Die wichtigen VMs werden täglich über Veeam B&R gesichert und auf einem NAS abgelegt.
Hast du dann in jeder VM den Veeam Agent oder wie löst du dies? Denn die kostenlose Variante vom ESXi hat nicht die für Snapshots bzw. Backups notwendige API, die auch Veeam und so ziemlich jedes andere Backupprodukt verwendet.
 
snaxilian schrieb:
[...] Denn die kostenlose Variante vom ESXi hat nicht die für Snapshots bzw. Backups notwendige API [...]
Das wäre ziemlich bescheiden und würde bedeuten, dass ich den Hypervisor 2 auch lizenzieren müsste und nicht mit der freien Version betreiben kann. Von B&R möchte ich nicht weg, auch wenn dort nur die redundanten Systeme laufen.

Vielen Dank für den Hinweis! Ich war davon ausgegangen, dass die VMs auf einem kostenfreien ESXi genauso mit B&R gesichert werden können, wie auf dem lizezierten Hypervisor 1.
 
Nope. Geht schon seit paar Jahren nicht (mehr). Die Arme-Leute-Backup-Lösung die ich diesbezüglich kenne wäre ghettoVCB, kann aber afaik nur Full Backups.

Arme-Leute-Lösung-2: Den ESXi Server alle 60 Tage neu installieren bzw. alle 90 je nachdem wie lange man die Installation für "Testzwecke" nutzen kann. Das meiste ließe sich sogar automatisieren... Kurz vor Ablauf des Zeitraums alle VMs herunter fahren, Configs sichern, den ESXi Server rebooten und per PXE booten lassen und gucken ob/wie man die Installation automatisiert und abschließend Configs wieder einspielen, Datastore durchsuchen, VMs registrieren und starten lassen.

Zu Veeam B&R: Ich nehme an, du verwendest die Community Edition? Dann weißt du, dass du damit auch maximal 10 VMs sichern kannst?
 
Zurück
Oben