SAP HANA auf VMware vSphere und VCF 9: Supportstatus, VM-Sizing und Wahl der Hosts

Unterstützung von SAP HANA auf VMware vSphere und VCF 9

SAP unterstützt SAP HANA 2.0 in virtuellen Maschinen auf VMware vSphere 8 sowie auf vSphere in VMware Cloud Foundation (VCF) 9 und vSphere Foundation (VVF) 9, jeweils unter einer eigenen SAP Note je Plattformversion und auf den dafür validierten CPU-Generationen. Broadcoms VCF-Blog hat die SAP-Unterstützung für VCF 9 am 19. Januar 2026 angekündigt und verweist für die Details auf SAP Note 3663150. SAP HANA auf vSAN folgt einer eigenen Note und braucht ein System, das sowohl für SAP HANA als auch für vSAN zertifiziert ist.

SAP Notes lassen sich nur mit einem SAP-Konto lesen. Die folgenden Supportaussagen sind deshalb die, die Broadcom in seinem VCF-Blog und in seinem Best-Practices-Leitfaden für SAP HANA veröffentlicht, die die Notes mit ihrer Nummer zitieren. Lesen Sie vor einer Entscheidung für die Produktion die aktuelle Fassung jeder Note im SAP-Supportportal.

SAP-HANA-Supportstatus je vSphere-Version

Broadcoms VCF-Blogbeiträge mit den genannten Daten und sein Leitfaden SAP HANA on VMware vSphere Best Practices (Titelblatt mit Datum Dezember 2024). Note-Nummern so, wie Broadcom sie zitiert; die Texte der SAP Notes erfordern eine SAP-Anmeldung.

Broadcoms Beitrag vom 1. August 2025 richtete sich an SAP-Kunden, die noch mit vSphere 7 arbeiten. Er hält fest, dass vSphere 7 SAP HANA auf Haswell-, Broadwell- und Skylake-CPUs unterstützte, dass „diese älteren Prozessoren auf vSphere 8 wegen der Einstufung der CPUs als veraltet und/oder eingestellt nicht unterstützt werden“ und dass vSphere 8 „für SAP HANA auf Cascade Lake und neueren Intel-CPUs vollständig unterstützt“ ist. SAP-HANA-Systeme auf den älteren CPUs wechseln deshalb auf neue Hosts statt über ein In-place-Upgrade. Der Beitrag empfiehlt „vSphere 8 für eine unkomplizierte Anhebung oder VCF 9 für eine vollständige Private-Cloud-Grundlage und Support bis 2031“. Derselbe Beitrag sagt, dass vSphere 8 „bis Oktober 2027 unterstützt wird“, mit einem optionalen, kostenpflichtigen Extended Support über zwei Jahre; unser Leitfaden zum Ende des allgemeinen Supports für vSphere 8 behandelt die Termine.

Der Beitrag vom Januar 2026 führt für SAP HANA auf VCF 9 die Intel-Xeon-Plattformen von der 2. Generation (Cascade Lake und Cooper Lake) bis Xeon 6 mit P-Kernen (Granite Rapids). Cascade Lake steht auf dieser Liste, doch Broadcoms KB 318697 stuft es in VCF 9.x als veraltet ein, weiterhin unterstützt und mit CPU_SUPPORT_WARNING installiert; die Hardware-Anforderungen für ESX 9 führen die CPUs und Geräte auf, die Sie prüfen sollten, bevor Sie diese Hosts für VCF 9 behalten. Die Unterstützung für Xeon 6 auf vSphere 8 „wurde Ende September 2025 veröffentlicht“, sodass neue Xeon-6-Hosts zuerst einem vSphere-8-Cluster beitreten und später auf VCF 9 wechseln können.

Broadcoms Beitrag vom 12. Mai 2026 sagt: „VCF 9.1 ermöglicht jetzt das Deployment von Systemen mit 2-Sockel-Intel-Xeon-6-CPUs mit P-Kernen (Granite Rapids-SP) auf VMware vSAN“. Unter VCF 9.0 liefen diese Hosts mit Fibre-Channel- oder NFS-Storage. Zu den Plänen gehören 4-Sockel-Hosts mit Xeon 6 und mehr als 2 TB Arbeitsspeicher je CPU-Sockel, sobald die DIMMs verfügbar sind.

SAP-HANA-VM-Sizing auf vSphere: Maximalwerte je Sockel und Host

SAP-HANA-VMs auf vSphere werden in ganzen oder halben CPU-Sockeln dimensioniert. Broadcoms Leitfaden nennt „VMs mit einer Breite von 0,5, 1 und 2 Sockeln auf 2-Sockel-Hosts“ und dieselben Stufen bis zu 8 Sockeln auf 8-Sockel-Hosts. Er zählt jeden Hyperthread als vCPU, zum Beispiel „56 vCPUs (28 Kerne plus Hyperthreading)“ auf einem Sockel mit 28 Kernen, und empfiehlt, Hyperthreading eingeschaltet zu lassen, was die Standardeinstellung von ESXi ist.

Broadcom-VCF-Blog: 19. Januar 2026 (Zeilen zu Xeon 6, VCF 9.0), 14. April 2025 (16 TB auf vSphere 8.0 U3, Scale-out auf Anfrage) und 12. Mai 2026 (Scale-out bis 48 TB auf VCF 9 und neuer, Details in SAP Note 3663150).

Der Beitrag vom Januar 2026 bezeichnet „bis zu 2 TiB Arbeitsspeicher und bis zu 172 vCPUs je CPU-Sockel“ als aktuelles Maximum für Standardkonfigurationen und führt 2 TiB je Sockel für Xeon 6 als validiert, mit „bis zu 4 TiB, jedoch nicht validiert“. Er ergänzt, dass für 4 TiB je Sockel typischerweise eine CPU mit 86 Kernen nötig ist und dass eine geringere Kernzahl genügen kann, wenn ein workload-basiertes Sizing nach SAP Note 2779240 das bestätigt. Für Hosts mit Xeon der 4. Generation nennt der Beitrag 16 TiB als größte VM auf VCF 9.

Der Arbeitsspeicher eines Hosts steht SAP HANA nicht vollständig zur Verfügung. Broadcoms Leitfaden zieht den Speicherbedarf von ESXi vom Arbeitsspeicher des Hosts ab, bevor er VMs platziert, mit Standardwerten von 128 GB auf 2-Sockel-, 256 GB auf 4-Sockel- und 512 GB auf 8-Sockel-Hosts. Mit dem Standardwert hat ein 2-Sockel-Host mit 2 TiB je Sockel 128 GB weniger als seine 4 TiB für SAP-HANA-VMs.

NUMA-Ausrichtung, Arbeitsspeicherreservierungen und Latenz

SAP HANA ist NUMA-fähig, und die Regeln des Leitfadens richten jede VM an den physischen Sockeln aus. VMs mit halbem Sockel auf Xeon 6 erfordern Sub-NUMA Clustering (SNC-2). Der Leitfaden, geschrieben für Sapphire-Rapids-Hosts, bevor Xeon 6 validiert war, verlangt auf jeder VM mit SNC-2 den VMX-Parameter sched.nodeX.affinity, um ungewollte Migrationen zwischen NUMA-Knoten zu verhindern, sowie einen eigenen Cluster aus SNC-2-Hosts für die Migration dieser VMs. Jede SAP-HANA-VM erhält numa.vcpu.preferHT=TRUE, was ihre vCPU-Threads auf dem NUMA-Knoten hält.

Produktive SAP-HANA-VMs teilen sich keine Hosts mit anderen Workloads. Laut Leitfaden „dürfen produktive Workloads nicht auf den Hosts laufen, auf denen die Managementkomponenten oder Nicht-SAP-HANA-VMs laufen“, und eine SAP-HANA-VM sollte sich keinen NUMA-Knoten mit einer Nicht-SAP-HANA-VM teilen. Auf den gemeinsam genutzten Clustern, die den Rest der Umgebung tragen, zeigt CPU Ready je vCPU, ob das Verhältnis der vCPUs noch zur Last passt.

Arbeitsspeicher wird mit Reservierungen dimensioniert. Laut Leitfaden ist die Speichernutzung des Hosts erst bekannt, wenn alle VMs mit Arbeitsspeicherreservierungen konfiguriert und gestartet sind, und die zuletzt gestartete VM läuft möglicherweise nicht an, wenn die Reservierung falsch gewählt wurde. Für Workloads mit sehr niedrigen Latenzanforderungen macht der Leitfaden eine Ausnahme von seiner Empfehlung zu Hyperthreading und hat einen eigenen Abschnitt zur Performance-Optimierung von SAP-HANA-VMs mit niedriger Latenz.

Storage für SAP-HANA-VMs und SAP HANA auf vSAN

Der Leitfaden verlangt getrennte Datastores für Betriebssystem, SAP-HANA-Binärdateien, gemeinsame Ordner, Daten und Logs. Auf modernen Systemen empfiehlt er NVMe-Controller statt PVSCSI. Das Datenvolume ist mindestens so groß wie der RAM, per Thick Provisioning angelegt. Das Log-Volume umfasst auf Systemen bis 512 GB mindestens die Hälfte des RAM und auf größeren mindestens 512 GB, per Thick Provisioning angelegt. Produktiver Storage muss die Leistungskennzahlen (KPIs) von SAP erfüllen, die mit dem Hardware and Cloud Measurement Tool (HCMT) gemessen werden. vSphere HA und DRS für SAP-HANA-VMs funktionieren auf Datastores mit Fibre Channel, NFS und vSAN, nicht auf lokalem Speicher.

Zu vSAN hält der Beitrag vom März 2025 über vSAN 8 ESA fest: „Für SAP-HANA-Deployments dürfen nur SAP HANA HCI-zertifizierte Systeme verwendet werden“. Für VCF 9.1 verlangt der Beitrag vom Mai 2026 nach dem Deployment herstellerdefinierte vSAN-Richtlinien, das SAP-HANA-HCI-Erkennungsskript für vSAN auf den Hosts und neue Hosts, die „die Hardwarespezifikationen der vorhandenen Systeme erfüllen oder übertreffen müssen“. SAP-NetWeaver-Systeme mit anderen Datenbanken brauchen auf vSAN-Ready-Systemen von Herstellern, die beides unterstützen, „keine zusätzliche Validierung“. Unser Vergleich von vSAN ESA und OSA behandelt die beiden Architekturen und ihre Anforderungen.

Appliance, TDI oder HCI: die Wahl der Hosts

Von SAP definierte Appliance-Konfigurationen legen das Verhältnis von CPU zu Arbeitsspeicher fest. Laut Leitfaden müssen Hosts für SAP HANA Systeme sein, die für SAP HANA TDI unterstützt sind, und seit TDI Phase 5 hebt ein workload-basiertes Sizing nach SAP Note 2779240 die Abhängigkeit von „Appliance-Konfigurationen mit festen Verhältnissen von CPU zu Arbeitsspeicher“ auf. HCI-Lösungen auf vSAN sind herstellerspezifisch und SAP-ICC-zertifiziert, und für die zertifizierten VCF-basierten Systeme verweist Broadcom auf das Certified and Supported SAP HANA Hardware Directory von SAP.

In einer VMware-Umgebung mit 10 bis 60 Hosts führen diese Regeln zu einem eigenen Cluster oder einer eigenen VCF-Workload-Domäne für SAP HANA, mit Hosts gleicher Spezifikation. Die Unterstützung von HA und vMotion im Leitfaden setzt gemeinsam genutzten Storage voraus, und vMotion einer großen VM dauert länger: „Die Migration einer SAP-HANA-VM mit 2 TB oder einer SAP-HANA-VM mit 12 TB per vMotion dauert deutlich länger“. Große Hosts haben viele Kerne, und wie VVF und VCF sie zählen, erklärt unser Leitfaden zur VMware-Lizenzierung nach Broadcom.

Rechenbeispiel: SAP-HANA-Systeme in einer Umgebung mit 40 Hosts

Nehmen wir ein Unternehmen mit 40 vSphere-8-Hosts und diesen SAP-HANA-Systemen: S/4HANA-Produktion mit 1,5 TB, Qualitätssicherung mit 1,5 TB, Entwicklung mit 512 GB, eine Sandbox mit 512 GB und ein BW-System mit 3 TB. Auf neuen 2-Sockel-Hosts mit Xeon 6 und 2 TiB je Sockel verteilen die Layouts, die Broadcom für VCF 9 veröffentlicht hat (Sizing-Tabelle oben), sie wie folgt; für vSphere 8 prüfen Sie zuerst die Maximalwerte in SAP Note 3372365. Das BW-System belegt einen Host als VM über zwei Sockel mit bis zu 344 vCPUs. S/4HANA-Produktion und Qualitätssicherung teilen sich einen zweiten Host, mit je einem Sockel. Entwicklung und Sandbox belegen je einen Sockel auf einem dritten Host. Ein vierter Host gleicher Spezifikation gibt vSphere HA Platz, die größte VM nach einem Hostausfall neu zu starten.

Die vier Hosts bilden einen eigenen Cluster mit gemeinsam genutztem Fibre-Channel- oder NFS-Storage, der die HCMT-KPIs erfüllt, oder eine zertifizierte HCI-Lösung auf vSAN in VCF 9.1. Die Regel des Leitfadens schließt Managementkomponenten und Nicht-SAP-HANA-VMs von produktiven Hosts aus; zur Qualitätssicherung neben der Produktion sagt er nichts. Prüfen Sie deshalb SAP Note 3372365 und 3663150, bevor Sie beide auf einem Host zusammenlegen. Wächst die Entwicklung um weitere VMs mit halbem Sockel, kommen diese auf SNC-2-Hosts in einem eigenen Cluster.

Unsere VMware-Optimierung auditiert Versionen, Abonnements und tatsächliche Ressourcennutzung der Umgebung, und unser Engineering-Partner Vixen.UNO modernisiert vSphere und vSAN in vereinbarten Wartungsfenstern. Nennen Sie uns Ihre SAP-HANA-Systeme mit ihren Arbeitsspeichergrößen und Host-CPUs über das Formular auf dieser Seite.

Migration von SAP-HANA-VMs auf Xeon-6-Hosts und VCF 9

Broadcoms Beitrag vom Januar 2026 nennt diese Schritte für die Migration von älterer Hardware:

1. Prüfen Sie das Sizing der SAP-HANA-VM und wählen Sie eine Xeon-6-Konfiguration, die eine Überdimensionierung vermeidet, mit einer Turbofrequenz, die mit der bisherigen CPU vergleichbar ist.
2. Fügen Sie den neuen Host einem bestehenden vSphere-Cluster hinzu oder legen Sie einen neuen an.
3. Fahren Sie die VM herunter und migrieren Sie sie offline auf den neuen Host.
4. Heben Sie die Hardwareversion der VM auf mindestens 21 (vSphere 8) oder 22 (vSphere 9) an.
5. Passen Sie Kerne je Sockel und die Speicherausrichtung an die NUMA-Topologie des neuen Hosts an.
6. Starten Sie die VM und validieren Sie Leistung und Stabilität.

Schritt 3 ist eine Offline-Migration; planen Sie die Ausfallzeit jedes SAP-Systems deshalb mit dem SAP-Basis-Team. Da Xeon 6 auf vSphere 8 unterstützt wird, können der Hardwarewechsel und das Plattform-Upgrade auf VCF 9 in zwei getrennten Wartungsfenstern stattfinden.

Unser Engineering-Partner Vixen.UNO führt clusterübergreifende Migrationen in vereinbarten Wartungsfenstern durch, mit einem Rollback-Plan für jede Etappe. Beschreiben Sie Ihre aktuellen Hosts und die Zielversion im Formular unten.

Was wir tun

Unsere Leistung VMware-Optimierung auditiert die Umgebung und ihre Lizenzen, passt die Broadcom-Editionen an die Workloads an und modernisiert vSphere, vSAN und VCF; das Engineering übernimmt unser Partner Vixen.UNO. In einer Umgebung mit SAP HANA umfasst das Audit Versionen, Abonnements und Ressourcennutzung, und der Maßnahmenplan setzt Termine vor Renewal und End of Support. Änderungen laufen in vereinbarten Wartungsfenstern mit einem Rollback-Plan, und nach dem Projekt leisten wir Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ