AMD EPYC-Server für Virtualisierung: VMware, Proxmox, Hyper-V und eine VMware-Alternative nach Lizenzwachstum

AMD-EPYC-Server eignen sich gut für die Virtualisierung, wenn viele virtuelle Maschinen auf weniger physischen Knoten betrieben werden sollen, ohne zu früh an die Grenzen von Prozessor, Arbeitsspeicher, Storage oder Netzwerk zu stoßen. Einen solchen Server nur nach der Anzahl der Kerne auszuwählen, reicht jedoch nicht aus: Bei VMware ist die Lizenzberechnung besonders wichtig, bei Proxmox spielen die Storage-Architektur und die Kompetenzen des Teams eine große Rolle, und bei Hyper-V muss die Verbindung zu Windows Server und zur Microsoft-Lizenzierung berücksichtigt werden.

Die beste Lösung ist nicht der leistungsstärkste EPYC „für alle Fälle“, sondern eine ausgewogene Konfiguration, die auf reale virtuelle Maschinen, Ausfallsicherheit, Datensicherung und einen Wachstumsplan für die nächsten Jahre abgestimmt ist.

Ein weiterer wichtiger Punkt ist die Migration. Wenn ein Wechsel von einer Plattform auf eine andere und/oder von Intel-basierten Plattformen geplant ist, reicht das einfache Kopieren der Dateien virtueller Maschinen möglicherweise nicht aus, damit diese starten. Eine Konvertierung oder Neuinstallation kann erforderlich sein. In einigen Fällen kann auch die Softwarelizenzierung innerhalb der virtuellen Maschinen betroffen sein, weshalb Tests in solchen Szenarien unverzichtbar sind.

Servers powered by AMD EPYC processors

Warum AMD EPYC häufig für die Virtualisierung gewählt wird

Virtualisierung profitiert von einer planbaren Ressourcenreserve. Ein physischer Server muss möglicherweise gleichzeitig Dutzende oder Hunderte virtuelle Maschinen bedienen: Einige sind fast im Leerlauf, andere greifen ständig auf den Storage zu, manche benötigen viel Arbeitsspeicher, und wieder andere erzeugen Lastspitzen auf dem Prozessor.

AMD EPYC eignet sich aus mehreren Gründen gut für solche Aufgaben:

• viele physische Kerne in einem einzelnen Prozessor;
• Unterstützung großer Arbeitsspeicherkapazitäten;
• eine hohe Anzahl an PCIe-Lanes für NVMe-Laufwerke, Netzwerkadapter und Controller;
• die Möglichkeit, sowohl Ein-Sockel- als auch Zwei-Sockel-Server zu konfigurieren;
• eine hohe Ressourcendichte pro physischem Knoten.

Moderne AMD-EPYC-9005-Prozessoren sind beispielsweise in Konfigurationen mit bis zu 192 Kernen in einer einzelnen CPU erhältlich. Das zeigt, welche Rechendichte eine einzige Serverplattform bieten kann. Bei der Virtualisierung muss dieser Vorteil jedoch sorgfältig genutzt werden: Verfügt ein Server über sehr viele Kerne, aber zu wenig Arbeitsspeicher oder langsamen Storage, kann er trotzdem keine große Anzahl virtueller Maschinen effizient betreiben. Die technischen Daten der EPYC-9005-Generation finden Sie auf der offiziellen Seite zu AMD EPYC 9005.

Ein AMD-EPYC-Server für die Virtualisierung sollte daher nicht als „Prozessor plus Gehäuse“, sondern als Plattform betrachtet werden. CPU, Arbeitsspeicher, Storage, Netzwerkschnittstellen, Hypervisor, Backup-System und Lizenzen müssen gemeinsam ausgewählt werden.

Was bei der Virtualisierung wichtiger ist als die Anzahl der Kerne

Eine große Zahl von Kernen ist ein klarer Vorteil von EPYC, löst aber nicht jedes Problem von selbst. In realen Infrastrukturen entsteht der Engpass häufig an einer unerwarteten Stelle.

Arbeitsspeicher

CPU-Ressourcen können moderat überbucht werden, weil nicht jede virtuelle Maschine ihre zugewiesenen virtuellen Kerne dauerhaft vollständig auslastet. Arbeitsspeicher lässt sich deutlich schwieriger sicher überbuchen. Wenn virtuelle Maschinen tatsächlich 700–800 GB RAM benötigen, wird ein Server mit 512 GB nur in einer Präsentation gut funktionieren, nicht im Produktivbetrieb.

Für eine dichte Virtualisierung ist es in der Regel sinnvoll, Kapazitätsreserven einzuplanen für:

• das Wachstum der Anzahl virtueller Maschinen;
• temporäre Lastspitzen;
• den Ausfall eines Cluster-Knotens;
• den Ressourcenbedarf des Hypervisors;
• Backup- und Migrationsvorgänge.

Bei AMD EPYC sind Konfigurationen mit 512 GB bis 1–2 TB Arbeitsspeicher pro Knoten häufig sinnvoll. Große Cluster, Datenbanken, Terminalserver und Private Clouds können noch mehr benötigen.

Storage-Subsystem

Virtuelle Maschinen lasten den Prozessor nur selten dauerhaft vollständig aus, greifen aber fast immer auf den Storage zu. Wenn Dutzende Systeme gleichzeitig Protokolle schreiben, Datenbanken aktualisieren, Benutzeranfragen verarbeiten und Backups erstellen, wird das Storage-Subsystem zu einem kritischen Faktor.

Für die Virtualisierung sind nicht nur Terabyte wichtig, sondern auch:

• Ein-/Ausgabeoperationen pro Sekunde;
• Latenz;
• Schreibfestigkeit der SSDs;
• Ausfallsicherheit des Arrays;
• die Möglichkeit, eine virtuelle Maschine schnell wiederherzustellen;
• die Trennung von Produktivdaten und Backups.

NVMe ist besonders nützlich für Datenbanken, Terminalserver, virtuelle Desktop-Infrastrukturen, Analysesysteme und alle Workloads, bei denen die Storage-Latenz direkte Auswirkungen auf die Benutzer hat. Schnelle Laufwerke benötigen jedoch ein passendes Netzwerk und eine gut geplante Storage-Architektur. Andernfalls bleiben die NVMe-Laufwerke unterausgelastet, während die Infrastruktur durch eine Netzwerkverbindung oder einen Controller begrenzt wird.

Netzwerk

Für einen einzelnen Server können 10 GbE manchmal ausreichen. Für einen Cluster mit Live-Migration, gemeinsamem Storage und Backups ist dies möglicherweise zu wenig. In modernen Virtualisierungsumgebungen ist 25 GbE häufig die sinnvollere Basis, während 100 GbE für dichte Cluster, softwaredefinierten Storage und große Migrationen eingesetzt wird.

Es empfiehlt sich, die folgenden Datenströme im Voraus voneinander zu trennen:

• Hypervisor-Management;
• Datenverkehr der virtuellen Maschinen;
• Migrationsverkehr zwischen den Knoten;
• Storage-Zugriff;
• Backup-Verkehr;
• externe Kundennetze.

Je höher die Dichte virtueller Maschinen pro Knoten ist, desto geringer ist die Fehlertoleranz bei der Netzwerkarchitektur.

VMware auf AMD EPYC: eine ausgereifte Plattform mit neuem Kostenmodell

VMware vSphere bleibt eine leistungsfähige Plattform für die Virtualisierung in Unternehmen. Sie wird wegen ihrer ausgereiften Managementwerkzeuge, ihres breiten Ökosystems, hochverfügbarer Cluster, der Live-Migration virtueller Maschinen sowie der Integration mit Backup, Monitoring und Unternehmensprozessen eingesetzt.

Für Unternehmen, die VMware seit vielen Jahren nutzen, ist der Wechsel auf eine andere Plattform nicht immer gerechtfertigt. Ist die Infrastruktur geschäftskritisch, verfügt das Team über umfangreiche vSphere-Erfahrung und bestehen etablierte Betriebs-, Monitoring- und Wiederherstellungsprozesse, kann die Beibehaltung von VMware die sicherste Option sein.

Nach der Übernahme von VMware durch Broadcom mussten jedoch viele Unternehmen ihre Gesamtbetriebskosten neu berechnen. Broadcom kündigte offiziell den Übergang von VMware by Broadcom zu einem Abonnementmodell und das Ende des Verkaufs unbefristeter Lizenzen an. Das bedeutet nicht, dass VMware in jedem Fall sofort ersetzt werden muss. Es bedeutet jedoch, dass frühere Kostenberechnungen nicht automatisch auf einen neuen Beschaffungszeitraum übertragen werden können. Die Änderungen werden in Broadcoms offiziellem Material zur Transformation des VMware-Portfolios beschrieben.

Für AMD EPYC ist dies besonders wichtig. Die Prozessoren bieten eine hohe Kerndichte. Wird die Lizenzierung jedoch nach physischen Kernen berechnet oder an Abonnementpakete gekoppelt, ist der Prozessor mit der höchsten Kernzahl nicht immer die wirtschaftlichste Lösung. In einigen Szenarien reduziert eine hohe Dichte die Anzahl der Server, Racks, Netzwerkports und den Energieverbrauch. In anderen erhöht sie den Lizenzanteil am Budget.

Vor dem Kauf eines EPYC-Servers für VMware sollten Sie berechnen:

• wie viele physische Kerne lizenziert werden müssen;
• welche VMware-Editionen und -Pakete erforderlich sind;
• ob zusätzliche Komponenten für Management, Storage und Monitoring benötigt werden;
• wie viele Knoten der Cluster enthalten wird;
• wie viel Reservekapazität für den Ausfall eines Knotens erforderlich ist;
• welche ESXi-Versionen vom ausgewählten Server unterstützt werden;
• ob Controller, Netzwerkadapter und Laufwerke kompatibel sind.

Bei VMware sollte insbesondere dann, wenn vSAN geplant ist, die Hardwarekompatibilität anhand der aktuellen Broadcom-/VMware-Kompatibilitätslisten überprüft werden. Dies gilt besonders für neue Prozessorgenerationen, Netzwerkadapter, NVMe-Controller und Server, die mehrere Jahre im Einsatz bleiben sollen. Die Broadcom-Dokumentation beschreibt die Lizenzierung von VMware vSphere Foundation über eine Solution License gesondert. Daher sollten während der Planung sowohl die technischen Spezifikationen als auch das aktuelle Bereitstellungsmodell geprüft werden.

In der Praxis verändert dies die Serverauswahl. Für VMware kann ein Prozessor mit weniger Kernen, höherer Taktfrequenz und ausreichender Speicherkapazität manchmal wirtschaftlicher sein als die größte EPYC-Konfiguration, deren Lizenzkosten schneller steigen als der Leistungsgewinn bei realen Workloads.

Proxmox VE auf AMD EPYC: eine beliebte VMware-Alternative

Proxmox VE wird häufig als Alternative zu VMware betrachtet, insbesondere nachdem die Lizenzkosten neu bewertet wurden. Es handelt sich um eine Linux-basierte Plattform, die KVM für virtuelle Maschinen und LXC für Container verwendet, eine Weboberfläche bereitstellt, Cluster, Migration, verschiedene Storage-Typen und die Integration mit Proxmox Backup Server unterstützt. Die offizielle Proxmox-VE-Dokumentation beschreibt die Lösung als Plattform für virtuelle Maschinen und Container auf Basis von Debian GNU/Linux.

Proxmox spielt seine Stärken auf AMD-EPYC-Servern insbesondere in folgenden Szenarien aus:

• kleine und mittlere Unternehmen, für die VMware zu teuer geworden ist;
• Hosting- und Private-Cloud-Umgebungen;
• Test- und Laborumgebungen;
• Infrastrukturen mit einer großen Anzahl von Linux-Servern;
• Cluster mit NVMe-Storage und schnellen Netzwerkschnittstellen;
• Projekte, die Flexibilität und Unabhängigkeit von einer starren Herstellerbindung erfordern.

Zu den Stärken von Proxmox gehören:

• keine klassische Abrechnung „pro physischem Kern“ wie bei einigen kommerziellen Plattformen sowie die Möglichkeit, das Produkt als Open-Source-Software ohne kostenpflichtiges Abonnement zu nutzen;
• eine komfortable Weboberfläche für die grundlegende Administration;
• Cluster-Unterstützung;
• Live-Migration virtueller Maschinen bei korrekt geplanter Storage-Architektur;
• integrierte Unterstützung für ZFS, Ceph, NFS, iSCSI und weitere Storage-Optionen;
• Container-Unterstützung;
• eine separate Backup-Lösung.

Proxmox sollte jedoch nicht als kostenlose VMware-Alternative ohne Nachteile betrachtet werden. Kosten können an anderer Stelle entstehen: bei Implementierung, Mitarbeiterschulung, Storage-Konfiguration, Backups, Monitoring, Migration und Support. Wenn Administratoren zuvor ausschließlich mit VMware gearbeitet haben, benötigen sie Zeit, um Linux-Konzepte, Netzwerk-Bridges, Storage-Verwaltung, Updates und Fehlerdiagnose zu erlernen.

Dies ist bei AMD EPYC besonders relevant: Ein leistungsstarker Server kann viele virtuelle Maschinen betreiben, doch jeder Fehler in der Storage- oder Netzwerkarchitektur skaliert mit dieser Dichte. Je mehr virtuelle Maschinen auf einem Knoten laufen, desto teurer wird ein Ausfall und desto wichtiger ist es, die Ausfallsicherheit im Voraus zu testen.

Eine Migration von VMware zu Proxmox sollte am besten schrittweise erfolgen:

1. Einen Pilot-Cluster bereitstellen.
2. Mehrere unkritische virtuelle Maschinen migrieren.
3. Storage- und Netzwerkleistung einschließlich Lasttests prüfen.
4. Backup und Wiederherstellung konfigurieren.
5. Ausfalltests durchführen und dokumentieren, wie sich der Cluster bei einem vollständigen oder teilweisen Ausfall verhält und welche Besonderheiten bei der Wiederherstellung auftreten.
6. Monitoring und Benachrichtigungen überprüfen.
7. Erst danach Produktivdienste migrieren.

Wenn das Ziel darin besteht, die Abhängigkeit von VMware zu reduzieren und gleichzeitig die Stärken von AMD EPYC zu nutzen, kann Proxmox eine sinnvolle Wahl sein. Es erfordert jedoch bei Architektur und Planung nicht weniger Disziplin als eine kommerzielle Plattform.

Hyper-V auf AMD EPYC: wann es eine rationale Wahl ist

Hyper-V sollte vor allem von Unternehmen in Betracht gezogen werden, die bereits Windows Server, Active Directory, Microsoft SQL Server, Windows Admin Center und andere Microsoft-Produkte einsetzen. In einer solchen Umgebung kann Hyper-V eine logische Erweiterung der vorhandenen Infrastruktur sein und muss kein Kompromiss sein.

Microsoft beschreibt Hyper-V als Virtualisierungstechnologie von Windows Server, mit der Windows- und Linux-VMs in großem Maßstab ausgeführt werden können. Die Dokumentation behandelt außerdem Failover-Cluster, Cluster Shared Volumes und Live-Migration.

Hyper-V kann besonders geeignet sein, wenn:

• die meisten virtuellen Maschinen unter Windows Server laufen;
• Windows-Server-Datacenter-Lizenzen bereits gekauft wurden oder geplant sind;
• das Team über umfangreiche Erfahrung mit Microsoft-Infrastrukturen verfügt;
• Active Directory eingesetzt wird;
• die Verwaltung über Windows Admin Center oder System Center sinnvoll ist;
• eine Integration in bestehende Sicherheits- und Administrationsrichtlinien erforderlich ist.

Hyper-V sollte nicht als „kostenloses VMware“ betrachtet werden. Eine eingeschränkte kostenlose Edition existiert, die ausgereiftere Lösung ist jedoch kostenpflichtig, auch wenn ihr Betrieb in der Regel günstiger ist als bei VMware. Die Wirtschaftlichkeit hängt von der Windows-Server-Lizenzierung, der Anzahl physischer Kerne, der Edition Standard oder Datacenter und der Anzahl der Windows-VMs ab. Für einige Unternehmen ist dies kosteneffizient, für andere nicht.

Hyper-V kann auf AMD EPYC effizient betrieben werden, allerdings gelten dieselben Planungsanforderungen wie bei anderen Hypervisoren:

• ausreichend Arbeitsspeicher;
• schneller Storage;
• Netzwerkschnittstellen für Migrations- und Storage-Verkehr;
• Treiberkompatibilität;
• ein korrekt geplanter Cluster;
• Backups, die getrennt von den Produktivdaten gespeichert werden.

Hyper-V ist besonders stark, wenn die Virtualisierung Teil einer Microsoft-Umgebung und keine separate unabhängige Plattform ist. Ist die Infrastruktur gemischt, enthält viele Linux-Systeme, nutzt nicht standardisierte Netzwerke und setzt stark auf offene Werkzeuge, kann Proxmox komfortabler sein. Wenn ein ausgereiftes Unternehmensökosystem entscheidend ist und bereits umfassende VMware-Kompetenz vorhanden ist, kann vSphere weiterhin die bevorzugte Wahl bleiben.

VMware, Proxmox und Hyper-V auf AMD EPYC

Die Wahl des Hypervisors sollte nicht mit der Frage „Welche Option ist günstiger?“ beginnen. Zunächst muss festgelegt werden, welche virtuellen Maschinen betrieben werden müssen, welche Ausfallzeit akzeptabel ist, wer die Plattform administriert und wie schnell das Unternehmen sich nach einem Vorfall erholen muss. Erst danach sollten Lizenz- und Supportkosten verglichen werden.

AMD EPYC Servers

So wählen Sie einen AMD-EPYC-Server für die Virtualisierung aus

Beginnen Sie nicht mit dem Prozessormodell, sondern mit einer Bestandsaufnahme der virtuellen Maschinen. Ein Server wird für eine konkrete Last gekauft, nicht wegen seiner Kernzahl.

Vor der Auswahl einer Konfiguration sollten Sie bestimmen:

• wie viele virtuelle Maschinen derzeit laufen;
• wie viele in zwei bis drei Jahren benötigt werden;
• welche Systeme geschäftskritisch sind;
• welche Maschinen dauerhaft stark ausgelastet sind;
• welche Workloads viel Arbeitsspeicher verbrauchen;
• welche Workloads viele Schreibzugriffe auf den Storage erzeugen;
• welche Systeme schnell wiederhergestellt werden müssen;
• welche Systeme bei einem Vorfall vorübergehend gestoppt werden dürfen;
• welche Systeme niemals gestoppt werden dürfen.

Erst danach sollte die Hardware ausgewählt werden.

Prozessor

Für übliche Office-Dienste, kleine Websysteme, Domänencontroller und Hilfs-VMs ist eine moderate CPU-Überbuchung akzeptabel. Nicht jede virtuelle Maschine nutzt alle ihr zugewiesenen virtuellen Kerne gleichzeitig.

Stark ausgelastete Systeme benötigen eine deutlich größere Reserve. Dazu gehören:

• Datenbanken;
• Terminalserver;
• 1C und andere Buchhaltungssysteme;
• virtuelle Desktop-Infrastrukturen;
• Analysedienste;
• Videoüberwachungssysteme;
• Mailserver;
• Webanwendungen mit hoher Last.

Es reicht nicht aus, alle virtuellen Kerne zu addieren und dieselbe Anzahl physischer Kerne zu kaufen. Tatsächliche Auslastung, Lastspitzen, Workload-Profil und Anforderungen an die Ausfallsicherheit müssen berücksichtigt werden. Wenn der Cluster den Ausfall eines Knotens überstehen muss, müssen die verbleibenden Server dessen virtuelle Maschinen ohne kritischen Leistungsverlust übernehmen können.

Arbeitsspeicher

Bei der Virtualisierung ist der Arbeitsspeicher häufig wichtiger als der Prozessor. Ein Server mit 96 Kernen und 256 GB RAM kann unausgewogen sein: Die CPU verfügt noch über Reserven, aber für zusätzliche virtuelle Maschinen ist kein Arbeitsspeicher mehr vorhanden.

Für Produktivinfrastrukturen ist in der Regel eine Reserve von mindestens 20–30 % sinnvoll. In einem Cluster wird diese Kapazität nicht nur für Wachstum, sondern auch für die Notfallverlagerung virtueller Maschinen benötigt. Wenn jeder Knoten nahezu vollständig ausgelastet ist, besteht die Ausfallsicherheit nur auf dem Architekturdiagramm.

AMD-EPYC-Server werden üblicherweise mit großzügigen Arbeitsspeicherreserven konfiguriert: 512 GB, 1 TB, 2 TB oder mehr. Dies ist besonders wichtig für Virtualisierungsplattformen, Datenbanken, Terminalserver und Private Clouds.

Storage

Bei der Auswahl der Laufwerke sollten drei unterschiedliche Aufgaben voneinander getrennt werden:

1. Speicherung virtueller Maschinen.
2. Speicherung von Backups.
3. Betriebsaufgaben wie Protokolle, Migrationen, temporäre Daten und Replikation.

SSDs mit SAS- oder SATA-Schnittstelle können für moderate Workloads ausreichen. Für dichte Virtualisierung, Datenbanken, Terminalserver und aktive Benutzerumgebungen ist NVMe vorzuziehen. Ist der Server Teil eines Clusters, sollte im Voraus entschieden werden, ob der Storage lokal, gemeinsam genutzt oder softwaredefiniert sein soll.

Wichtig: Backups können nicht als zuverlässig gelten, wenn sie ausschließlich auf demselben Array wie die virtuellen Maschinen gespeichert werden. Ein Array-Ausfall, ein Administratorfehler, ein Angriff oder eine Datenbeschädigung kann gleichzeitig sowohl die Produktivumgebung als auch ihre Backups zerstören.

Netzwerk

Für einen wenig ausgelasteten einzelnen Knoten können 10 GbE noch ausreichen. Für einen Cluster ist es besser, von Anfang an 25 GbE in Betracht zu ziehen, insbesondere wenn Folgendes geplant ist:

• Live-Migration virtueller Maschinen;
• zentraler Storage;
• Ceph, vSAN, Storage Spaces Direct oder ähnliche Architekturen;
• Backups während der Geschäftszeiten;
• eine große Anzahl virtueller Maschinen pro Knoten.

100 GbE ist für dichte Cluster, Provider-Plattformen, NVMe-Storage und Szenarien sinnvoll, in denen das Netzwerk Teil des Storage-Subsystems wird.

Für moderne Serverlandschaften können auch Dell PowerEdge 16G und Dell PowerEdge 17G als Orientierung für Plattformgeneration, Speicherdichte, Unterstützung schneller Schnittstellen und Erweiterungsmöglichkeiten dienen. Die endgültige Auswahl sollte dennoch auf dem Workload-Profil und nicht auf dem Namen der Produktlinie basieren.

Beispielkonfigurationen mit AMD EPYC für verschiedene Szenarien

Diese Konfigurationen sind keine universellen Standards. Zehn Datenbank-VMs können einen Server stärker belasten als hundert wenig genutzte Hilfs-VMs. Vor dem Kauf sollten daher nicht nur die Anzahl der virtuellen Maschinen, sondern auch ihr Verhalten analysiert werden: Arbeitsspeichernutzung, Storage-Aktivität, Netzwerkverkehr, Lastspitzen und Wiederherstellungsanforderungen.

Die Lizenzierung kann die gesamte Berechnung verändern

AMD EPYC trägt häufig dazu bei, die Anzahl physischer Server zu reduzieren. Ein leistungsstarker Knoten kann mehrere ältere Systeme ersetzen, das Rack vereinfachen, die Anzahl der Netzwerkports reduzieren und den Energieverbrauch senken. Eine Lizenzierung nach physischen Kernen oder Abonnementpaketen macht die Berechnung jedoch komplizierter.

In einer VMware-Umgebung muss ein Prozessor mit hoher Kernzahl besonders sorgfältig bewertet werden. Wird der größte verfügbare EPYC nur deshalb gewählt, weil er verfügbar ist, zahlt das Unternehmen möglicherweise für überschüssige Kerne, während die realen virtuellen Maschinen durch Arbeitsspeicher oder Storage begrenzt werden.

Hyper-V folgt einem anderen wirtschaftlichen Modell. Windows-Server-Lizenzen, die Edition Standard oder Datacenter und die Rechte zum Betrieb virtueller Instanzen müssen bewertet werden. Datacenter kann wirtschaftlich sinnvoll sein, wenn die meisten Systeme unter Windows Server laufen. In einer gemischten Umgebung kann die endgültige Berechnung weniger eindeutig sein.

Proxmox verwendet nicht dasselbe Abrechnungsmodell pro physischem Kern, doch dadurch wird das Projekt nicht kostenlos. Folgende Kosten müssen berücksichtigt werden:

• Implementierung;
• Schulung des Teams;
• Support;
• Monitoring;
• Backup-Konfiguration;
• Migration;
• Tests der Ausfallsicherheit;
• Dokumentation und laufender Betrieb.

Manchmal ist eine teurere Lizenz günstiger als ein Migrationsfehler. In anderen Fällen führt der Wechsel von der bisherigen Plattform über mehrere Jahre zu erheblichen Einsparungen. Daher sollte der Endbetrag als Gesamtbetriebskosten und nicht isoliert als Preis des Servers oder des Abonnements berechnet werden.

Ausfallsicherheit, Backup und Migration

Virtualisierung bietet Flexibilität, ersetzt jedoch keine solide Architektur. Wenn ein leistungsstarker Server alle virtuellen Maschinen eines Unternehmens betreibt, wird er zu einem Single Point of Failure. AMD EPYC kann eine große Last auf einem Knoten konsolidieren, doch das ist für die Zuverlässigkeit nicht immer von Vorteil.

Cluster

Produktivinfrastrukturen benötigen in der Regel einen Cluster. Zwei Knoten können ein Ausgangspunkt sein, drei sind jedoch häufig besser für eine robustere Architektur. Ein dritter Knoten oder ein separater Witness hilft dem Cluster, bei Kommunikationsfehlern und Ausfällen korrekte Entscheidungen zu treffen.

Bei der Planung eines Clusters gilt:

• keinen Knoten bis an seine Grenze auslasten;
• Kapazität für den Ausfall eines Servers reservieren;
• Prozessoren aus ähnlichen Generationen verwenden;
• gemeinsamen oder verteilten Storage sorgfältig planen;
• Management-, Storage- und Migrationsnetzwerke voneinander trennen;
• die Migration virtueller Maschinen vor einem Vorfall testen, nicht erst danach.

Besteht ein Cluster aus zwei leistungsstarken EPYC-Servern, muss jeder davon vorübergehend die kritischen virtuellen Maschinen des anderen Knotens aufnehmen können. Andernfalls besteht die angegebene Ausfallsicherheit nur auf dem Papier.

Backup

Ein Snapshot ist kein Backup. Ein Snapshot ermöglicht zwar ein schnelles Rollback vor einem Update oder einer Konfigurationsänderung, schützt jedoch nicht vor dem Verlust des gesamten Storage-Systems, vor Administratorfehlern, Ransomware-Verschlüsselung oder Beschädigung des Arrays.

Virtualisierung erfordert separate Backups:

• auf einem anderen Storage-System;
• mit überprüfter erfolgreicher Wiederherstellung;
• mit einer klar definierten Aufbewahrungsdauer;
• mit Schutz vor Löschung oder Verschlüsselung;
• mit regelmäßigen Wiederherstellungstests zumindest für einen Teil der virtuellen Maschinen.

VMware-Umgebungen verwenden häufig Veeam und andere kommerzielle Lösungen. Für Proxmox kann Proxmox Backup Server in Betracht gezogen werden. Hyper-V kann Microsoft-Werkzeuge und Backup-Systeme von Drittanbietern nutzen. Der Produktname ist weniger wichtig als die nachgewiesene Fähigkeit, den Dienst innerhalb der erforderlichen Zeit wiederherzustellen.

Migration von VMware

Bei einer Migration von VMware zu Proxmox oder Hyper-V geht es nicht nur um die Konvertierung virtueller Festplattendateien. Treiber, Netzwerkeinstellungen, Typen von Storage-Controllern, Bootloader, Gast-Agenten, Backups, Monitoring und die Startreihenfolge der Dienste müssen berücksichtigt werden.

Ein sicherer Prozess sieht in der Regel wie folgt aus:

1. Zuerst unkritische virtuelle Maschinen migrieren.
2. Startvorgang, Netzwerkverbindung, Leistung und Backups überprüfen.
3. Monitoring konfigurieren.
4. Rollback-Prozess dokumentieren.
5. Erst danach die Migration der Produktivsysteme planen.
6. Die alte Plattform verfügbar halten, bis das Pilotprojekt abgeschlossen ist.

Wenn ein Unternehmen gleichzeitig Server, Hypervisor und Storage-Architektur ändert, wird das Projekt komplexer. In diesem Fall sollten die Änderungen in Phasen aufgeteilt werden: zuerst die neue Serverplattform bereitstellen, dann den Test-Hypervisor und schließlich einen Teil der Last migrieren.

Wann es sinnvoll ist, bei VMware zu bleiben

VMware beizubehalten ist sinnvoll, wenn die Plattform bereits stabil läuft und die Abonnementkosten im Verhältnis zu den Migrationsrisiken akzeptabel sind. Dies gilt insbesondere, wenn die Virtualisierung kritische Systeme wie ERP, Datenbanken, Abrechnung, Produktionsdienste, Terminalserver-Farmen, medizinische Anwendungen oder Finanzanwendungen unterstützt.

VMware kann vorzuziehen sein, wenn:

• das Team über umfassende vSphere-Kompetenz verfügt;
• Backup und Monitoring bereits eingerichtet sind;
• komplexe Netzwerkarchitekturen eingesetzt werden;
• SAN, vSAN oder ausgereifte Storage-Prozesse vorhanden sind;
• ein möglichst geringes Änderungsrisiko erforderlich ist;
• Ausfallzeiten teurer sind als die möglichen Einsparungen;
• Anforderungen an Unternehmenssupport und Zertifizierungen erfüllt werden müssen.

In diesem Szenario kann AMD EPYC weiterhin eine ausgezeichnete Serverplattform sein. Der Prozessor muss lediglich unter Berücksichtigung der Lizenzierung ausgewählt werden. Weniger physische Kerne, mehr Arbeitsspeicher und schneller NVMe-Storage können einer maximalen Kerndichte vorzuziehen sein, die den virtuellen Maschinen nur geringen praktischen Nutzen bietet.

Wann VMware-Alternativen in Betracht gezogen werden sollten

Alternativen sollten geprüft werden, wenn die VMware-Kosten im Verhältnis zur Größe der Infrastruktur unverhältnismäßig geworden sind oder das Wachstum einschränken. Dies ist besonders für kleine und mittlere Unternehmen, Hosting-Anbieter, Laborumgebungen und Unternehmen relevant, die nicht stark von spezialisierten VMware-Funktionen abhängig sind.

Proxmox kann eine gute Option sein, wenn:

• das Team bereit ist, mit Linux-Infrastrukturen zu arbeiten;
• Flexibilität beim Storage erforderlich ist;
• Einsparungen bei den Lizenzkosten wichtig sind;
• Zeit für ein Pilotprojekt vorhanden ist;
• die Infrastruktur nicht von seltenen VMware-spezifischen Funktionen abhängt;
• eine Private Cloud oder Hosting-Plattform aufgebaut werden soll.

Hyper-V kann logischer sein, wenn:

• die meisten Dienste unter Windows laufen;
• das Unternehmen bereits Windows Server Datacenter beschafft;
• die Administration auf Microsoft-Technologien ausgerichtet ist;
• das Team Erfahrung mit Windows Failover Clustering hat;
• die Integration mit Active Directory und Windows Admin Center wichtig ist.

Der Wechsel von VMware sollte keine emotionale Entscheidung sein. Einsparungen bei den Lizenzen können zu höheren Gesamtkosten führen, wenn dadurch Verwaltbarkeit, zuverlässige Backups oder eine planbare Wiederherstellung verloren gehen.

AMD EPYC Servers

Ein-Sockel- oder Zwei-Sockel-Server mit AMD EPYC

Dell PowerEdge R7625, 2U-Rack-Server.

Bildquelle: dell.com

Eine weniger offensichtliche Frage ist, ob ein Server mit zwei Prozessoren erforderlich ist. Früher wurden für große Virtualisierungsumgebungen häufig standardmäßig Zwei-Sockel-Systeme ausgewählt. Mit AMD EPYC ist dies nicht immer notwendig.

Ein Ein-Sockel-EPYC-Server kann vorteilhaft sein, wenn:

• ein Prozessor genügend Kerne bereitstellt;
• ausreichend Speichersteckplätze vorhanden sind;
• ausreichend PCIe-Lanes vorhanden sind;
• eine einfachere Architektur bevorzugt wird;
• Energieverbrauch und Wärmeentwicklung wichtig sind;
• Komplexität und mögliche Lizenzkosten reduziert werden sollen.

Ein Zwei-Sockel-Server ist erforderlich, wenn:

• die maximal mögliche Arbeitsspeicherkapazität benötigt wird;
• viele NVMe-Laufwerke und Erweiterungskarten erforderlich sind;
• eine maximale Dichte virtueller Maschinen wichtig ist;
• der Server Teil eines großen Clusters sein wird;
• der Workload effizient über zwei Prozessoren skaliert.

Bei einer Zwei-Sockel-Konfiguration muss NUMA berücksichtigt werden. Vereinfacht gesagt befinden sich Arbeitsspeicher und Kerne innerhalb eines Servers nicht immer in gleicher Nähe zueinander. Große virtuelle Maschinen können schlechter arbeiten, wenn ihre Ressourcen unkoordiniert auf Prozessordomänen verteilt werden. Für große Datenbanken, Terminalserver und anspruchsvolle Anwendungen müssen die Größen der virtuellen Maschinen daher korrekt konfiguriert und die Empfehlungen des Hypervisors beachtet werden.

Wie ein ausgewogener AMD-EPYC-Server aussehen sollte

Eine gute Virtualisierungskonfiguration besteht nicht aus dem größten Prozessor in der kleinstmöglichen Ausstattung. Sie ist ein ausgewogenes System ohne offensichtlichen Schwachpunkt.

Für einen kleinen Knoten kann dies Folgendes umfassen:

• einen AMD-EPYC-Prozessor mit 32–48 Kernen;
• 512 GB RAM;
• ein NVMe- oder SSD-Array;
• 10/25-GbE-Netzwerk;
• ein separates Backup-System.

Für einen mittelgroßen Cluster:

• 2–3 AMD-EPYC-Knoten;
• 48–64 Kerne pro Knoten;
• 512 GB–1 TB RAM pro Knoten;
• NVMe-Storage für virtuelle Maschinen;
• 25 GbE für Migrations- und Storage-Verkehr;
• ein separates Backup-System.

Für dichte Virtualisierung:

• EPYC mit 64–96 Kernen oder mehr;
• 1–2 TB RAM pro Knoten;
• NVMe oder externer/verteilter Storage;
• 25/100-GbE-Netzwerk;
• sorgfältige Lizenzberechnungen;
• für Ausfälle reservierte Kapazität;
• Monitoring und regelmäßige Wiederherstellungstests.

Beim Kauf generalüberholter oder gebrauchter Hardware ist es besonders wichtig, die Kompatibilität zwischen dem konkreten Servermodell, den Prozessoren, dem Arbeitsspeicher, den Laufwerken, den Netzwerkadaptern und dem Hypervisor zu prüfen. Virtualisierungsplattformen haben lange Lebenszyklen: Ein Server kann drei bis fünf Jahre oder länger im Einsatz bleiben. Eine geringe Einsparung bei einem Controller oder Netzwerkadapter kann daher bei späteren Hypervisor-Upgrades zu Einschränkungen führen.

Welche Lösung für die Virtualisierung auf AMD EPYC geeignet ist

Für ein Unternehmen, das eine neue Infrastruktur aufbaut und eine hohe Dichte virtueller Maschinen anstrebt, ist AMD EPYC eine leistungsfähige Plattform. Sie eignet sich besonders für Umgebungen, die viele Kerne, große Arbeitsspeicherkapazitäten, schnellen NVMe-Storage und leistungsfähige Netzwerke benötigen. Der Server sollte jedoch zusammen mit dem Hypervisor und nicht unabhängig davon ausgewählt werden.

VMware bleibt eine rationale Wahl für kritische Unternehmensumgebungen, wenn die Abonnementkosten durch Stabilität, ein ausgereiftes Ökosystem und ein geringeres Migrationsrisiko gerechtfertigt sind. Proxmox eignet sich für Unternehmen, die mehr Flexibilität wünschen und bereit sind, in Architektur, Linux-Kompetenz und eine Pilotmigration zu investieren. Hyper-V ist für Unternehmen mit einer starken Microsoft-Umgebung sinnvoll, in der Windows-Server-Lizenzen effizient genutzt werden können.

Die zuverlässigste Strategie besteht nicht darin zu berechnen, „wie viele Kerne gekauft werden können“, sondern wie viel belastbare Virtualisierung aufgebaut werden kann. Die Berechnung sollte Prozessor, Arbeitsspeicher, Storage, Netzwerk, Lizenzen, Backups, Ausfallsicherheit und die Kosten von Ausfallzeiten umfassen. Erst dann bietet ein AMD-EPYC-Server einen echten Vorteil, statt lediglich leistungsstarke, aber unausgewogene Hardware zu sein.