Handbuch

Eine VM für eine produktive SAP HANA-Datenbank auswählen.

→Verwenden Sie VMs der Mv2- oder M-Serie für große Datenbanken (>4TB). Verwenden Sie SAP-zertifizierte VMs der Edsv5-Serie für kleinere produktive HANA-Datenbanken (<4TB).

Warum: VMs der M-/Mv2-Serie sind SAP-zertifiziert für Workloads mit großem Speicherbedarf. Die Edsv5-Serie bietet eine kostengünstige, zertifizierte Option für kleinere HANA-Instanzen. Andere Serien (D, F, L) sind nicht für produktive HANA-Datenbanken zertifiziert.

Referenz↗

Eine VM für einen SAP NetWeaver-Anwendungsserver auswählen.

→Verwenden Sie VMs der Edsv5- oder Ddsv5-Serie. Die Dimensionierung basiert auf den SAPS-Anforderungen aus SAP EarlyWatch Alert-Berichten oder SAP Quick Sizer.

Warum: VMs der E- und D-Serie bieten ein ausgewogenes CPU-zu-Speicher-Verhältnis, das für SAP-Anwendungsserver-Workloads geeignet und SAP-zertifiziert für NetWeaver ist.

Minimale Netzwerklatenz zwischen SAP-Anwendungsservern und dem Datenbankserver sicherstellen.

→Alle zugehörigen VMs (App-Server, ASCS/ERS, Datenbank) innerhalb einer einzigen Proximity Placement Group (PPG) bereitstellen.

Warum: PPGs platzieren VMs physisch im selben Rechenzentrum und minimieren die Netzwerk-Roundtrip-Zeit, um die SAP-Anforderung an die Latenz im Sub-Millisekundenbereich zwischen Anwendungs- und Datenbankschichten zu erfüllen.

Ein freigegebenes Dateisystem für das /hana/shared-Volume in einer SAP HANA Scale-Out-Bereitstellung bereitstellen.

→Verwenden Sie Azure NetApp Files (ANF) mit dem NFS-Protokoll.

Warum: ANF ist die SAP-zertifizierte, hochleistungsfähige, freigegebene NFS-Speicherlösung, die für HANA Scale-Out-Konfigurationen erforderlich ist. Block Storage wie Managed Disks kann dafür nicht verwendet werden.

Ein hochverfügbares, freigegebenes Dateisystem für /sapmnt und das globale Transportverzeichnis (/usr/sap/trans) bereitstellen.

→Verwenden Sie Azure NetApp Files (NFS) oder Azure Files Premium (NFS). Für Windows verwenden Sie Azure Files Premium (SMB) oder einen SOFS-Cluster.

Warum: Diese Dienste bieten verwaltete, hochverfügbare Dateifreigaben mit der erforderlichen Leistung und Protokollunterstützung (NFS für Linux, SMB für Windows), wodurch die Notwendigkeit entfällt, einen separaten Dateiserver-Cluster zu erstellen und zu verwalten.

Speicher für produktive SAP HANA /hana/data- und /hana/log-Volumes entwerfen, die hohe IOPS und Latenz im Sub-Millisekundenbereich erfordern.

→Verwenden Sie verwaltete Azure Ultra Disk oder Premium SSD v2-Datenträger. Für /hana/log auf VMs der M-Serie ist Premium SSD mit Write Accelerator ebenfalls eine gültige Option.

Warum: Ultra Disk und Premium SSD v2 erfüllen die strengen IOPS-, Durchsatz- und Sub-Millisekunden-Latenz-KPIs, die von SAP für produktive HANA-Workloads definiert wurden. Standard-Speicher-Tiers werden nicht unterstützt.

Eine sichere Netzwerkarchitektur für SAP-Workloads entwerfen, die Produktion von Nicht-Produktionsumgebungen isoliert.

→Verwenden Sie eine Hub-Spoke-Topologie. Stellen Sie SAP-Systeme in dedizierten Spoke-VNets für jede Umgebung (Produktion, QA, Entwicklung) bereit. Verwenden Sie Netzwerksicherheitsgruppen (NSGs), um strenge Verkehrsregeln zwischen Subnetzen durchzusetzen.

Warum: Dies bietet eine starke Netzwerkisolation auf VNet-Ebene und eine feingranulare Verkehrskontrolle mit NSGs, gemäß den bewährten Sicherheitspraktiken und dem Azure Landing Zone-Konzept.

SAP-Landschaften in Azure mit einem Infrastructure as Code (IaC)-Ansatz für Konsistenz und Automatisierung bereitstellen.

→Verwenden Sie das offizielle SAP on Azure Deployment Automation Framework, das Terraform und Ansible nutzt. Alternativ können Sie benutzerdefinierte Bicep- oder Terraform-Module erstellen.

Warum: Das Framework bietet vorgefertigte, SAP-validierte Vorlagen für die Bereitstellung der gesamten Landschaft (Control Plane, Workload Zones, SAP-Systeme), reduziert den manuellen Aufwand und gewährleistet die Einhaltung bewährter Praktiken.

SAP Fiori oder andere webbasierte SAP-Anwendungen sicher über das Internet für externe Benutzer veröffentlichen.

→Verwenden Sie Azure Application Gateway mit aktivierter Web Application Firewall (WAF).

Warum: App Gateway bietet Layer-7-Lastverteilung, SSL-Terminierung und WAF-Schutz gegen gängige Web-Schwachstellen, was es zum idealen und sicheren Einstiegspunkt für webbasierte SAP-Anwendungen macht.

Eine extrem große SAP HANA-Datenbank (>12 TB Speicher) bereitstellen, die die Azure VM-Kapazität überschreitet.

→Verwenden Sie SAP HANA on Azure Large Instances (HLI). Die Konnektivität erfordert eine ExpressRoute-Leitung, die den HLI-Stempel über ein ExpressRoute-Gateway mit einem Azure VNet verbindet.

Warum: HLI sind speziell entwickelte Bare-Metal-Server, die den massiven Speicher und die Leistung bereitstellen, die für die größten HANA-Workloads erforderlich sind und über die Skalierung der aktuellen virtualisierten Infrastruktur hinausgehen.

Ein SAP-System über Verfügbarkeitszonen hinweg bereitstellen und gleichzeitig die Latenz innerhalb jeder Zone minimieren.

→Eine separate Proximity Placement Group (PPG) für die Ressourcen in jeder Verfügbarkeitszone erstellen. Jede PPG an ihre jeweilige Zone "pinnen".

Warum: Eine einzelne PPG kann Zonen nicht überspannen. Dieser Ansatz gewährleistet eine latenzarme Co-Lokalisierung von Ressourcen *innerhalb* einer Zone, während gleichzeitig eine hohe Verfügbarkeit *über* Zonen hinweg erreicht wird.

Standardisierte, gepatchte und vorkonfigurierte VM-Images für SAP-Bereitstellungen über mehrere Regionen hinweg erstellen und verteilen.

→Verwenden Sie Azure Image Builder, um einen wiederholbaren Image-Erstellungsprozess zu definieren. Speichern und replizieren Sie die resultierenden verwalteten Images mithilfe von Azure Compute Gallery.

Warum: Dies bietet eine versionskontrollierte, automatisierte "Golden Image"-Fabrik, die Konsistenz gewährleistet und die Bereitstellungszeit im Vergleich zur manuellen Konfiguration jeder neuen VM reduziert.

Sicheren RDP-/SSH-Administrationszugriff auf SAP-VMs bereitstellen, ohne diese dem öffentlichen Internet auszusetzen.

→Azure Bastion (Standard SKU) in einem dedizierten Subnetz innerhalb des virtuellen SAP-Netzwerks bereitstellen. Bastion verwenden, um über das Azure-Portal oder native Clients eine Verbindung zu VMs herzustellen.

Warum: Bastion fungiert als sichere, verwaltete Jump Box, wodurch die Notwendigkeit öffentlicher IP-Adressen auf SAP-VMs oder komplexer VPN-Einrichtungen für den Administrationszugriff entfällt und somit die Angriffsfläche reduziert wird.

SAP-Datenvolumes mit kundenverwalteten Verschlüsselungsschlüsseln verschlüsseln.

→Azure Disk Encryption mit einem vom Kunden verwalteten Schlüssel (CMK) verwenden, der in Azure Key Vault gespeichert ist. Dies kann mit der nativen SAP HANA-Verschlüsselung für Defense-in-Depth kombiniert werden.

Warum: Diese Konfiguration gibt dem Kunden die volle Kontrolle über die Datenverschlüsselungsschlüssel und erfüllt strenge Compliance- und Sicherheitsanforderungen für die Schlüssel-Lebenszyklusverwaltung.

Ein lokales SAP-System mit einer Nicht-HANA-Datenbank (z. B. Oracle, Db2) zu SAP HANA in Azure migrieren.

→Verwenden Sie den SAP Software Update Manager (SUM) mit der Database Migration Option (DMO). Für minimale Ausfallzeiten verwenden Sie die Optionen "DMO with System Move" oder Near-Zero Downtime (nZDT).

Warum: DMO kombiniert Datenbankkonvertierung, System-Upgrade und Datenmigration in einem einzigen, optimierten Prozess. Es ist das Standard-SAP-Tool für diese Aufgabe und minimiert Ausfallzeiten im Vergleich zum klassischen Export/Import.

Ein lokales SAP HANA-System mit der geringstmöglichen Ausfallzeit zu Azure migrieren.

→Verwenden Sie die SAP HANA System Replication (HSR), um Daten kontinuierlich auf die Ziel-Azure-VM zu replizieren. Führen Sie einen letzten, kurzen Cutover (Übernahme) während des Wartungsfensters durch.

Warum: HSR minimiert das Ausfallzeitfenster auf Minuten, da nur die finale Synchronisation und Übernahme erforderlich sind. Backup/Restore- oder Export/Import-Methoden führen bei großen Datenbanken zu stundenlangen Ausfallzeiten.

Ein großes Volumen an SAP-Daten (>10 TB) vom lokalen Rechenzentrum zu Azure für die anfängliche Migrationslast übertragen, wenn die Netzwerkbandbreite unzureichend ist.

→Verwenden Sie Azure Data Box für die anfängliche Massendatenübertragung. Verwenden Sie ExpressRoute oder VPN für die nachfolgende Delta-Synchronisation.

Warum: Data Box bietet eine schnellere Offline-Übertragungsmethode als netzwerkbasierte Übertragungen über begrenzte Bandbreite und reduziert die anfängliche Ladezeit erheblich.

SAP S/4HANA-Systeme in Azure mithilfe einer vereinfachten, geführten Erfahrung bereitstellen und verwalten.

→Verwenden Sie Azure Center for SAP solutions (ACSS). Zu den Voraussetzungen gehören die Registrierung des `Microsoft.Workloads`-Anbieters und die Erstellung einer benutzerseitig zugewiesenen verwalteten Identität mit den erforderlichen Berechtigungen.

Warum: ACSS optimiert die Bereitstellung durch Bündelung bewährter Praktiken und bietet einen zentralen Überblick im Azure-Portal für grundlegende Verwaltung (Start/Stopp, Monitoring) und Qualitätsprüfungen.

Die richtigen Azure VM-Größen für ein neues oder migriertes SAP-System bestimmen.

→Verwenden Sie das SAP Quick Sizer-Tool für neue Implementierungen. Für Migrationen analysieren Sie SAP EarlyWatch Alert-Berichte des bestehenden Systems, um die aktuellen SAPS- und Speichernutzung zu ermitteln. Ordnen Sie diese SAP-zertifizierten Azure-VMs zu.

Warum: Diese SAP-nativen Tools bieten die genaueste Workload-Charakterisierung (SAPS, Speicher, I/O), die für die korrekte Auswahl von Azure-Ressourcen und die Gewährleistung von Leistung und Unterstützbarkeit unerlässlich ist.

Eine kundenverwaltete Azure-Umgebung mit einem über RISE with SAP bereitgestellten SAP S/4HANA-System integrieren.

→SAP verwaltet die zugrunde liegende Azure-Infrastruktur in einem separaten Abonnement. Stellen Sie die Konnektivität von Ihrem Azure VNet zum von SAP verwalteten VNet mittels VNet Peering her.

Warum: RISE ist ein Managed Service-Angebot von SAP. VNet Peering bietet den standardmäßigen, sicheren und privaten Netzwerk-Integrationspfad zwischen der RISE-Umgebung und anderen Kunden-Workloads in Azure.

Unternehmensstandards und bewährte Sicherheitspraktiken über alle SAP-Bereitstellungen in Azure hinweg durchsetzen.

→Verwenden Sie Azure Policy, um Regeln durchzusetzen, z. B. die Anforderung spezifischer VM SKUs, verwaltete Datenträgerverschlüsselung, NSG-Zuweisung oder obligatorische Kennzeichnung. Verwenden Sie den Effekt `DeployIfNotExists`, um die VM-Erweiterung für SAP automatisch zu installieren.

Warum: Azure Policy bietet automatisierte, groß angelegte Governance, die sicherstellt, dass alle Bereitstellungen konform sind, ohne auf manuelle Überprüfungen oder individuelle Vorlagenkonfigurationen angewiesen zu sein.

Validieren, dass die bereitgestellte Azure-Infrastruktur korrekt konfiguriert ist und die SAP-Supportanforderungen vor dem Go-Live erfüllt.

→Die Azure VM Extension for SAP (Enhanced Monitoring) installieren und aktivieren. Das SAP on Azure Quality Check Tool von GitHub ausführen.

Warum: Die VM-Erweiterung ist für den SAP-Support zwingend erforderlich. Das Quality Check Tool validiert proaktiv Konfigurationen (Speicher, Netzwerk, OS-Einstellungen) anhand einer Liste bekannter Best Practices und Anforderungen.

Eine anwendungskonsistente, automatisierte Backup-Lösung für SAP HANA-Datenbanken auf Azure-VMs implementieren.

→Verwenden Sie Azure Backup für SAP HANA, das über die SAP-zertifizierte Backint-Schnittstelle integriert ist. Konfigurieren Sie eine Richtlinie mit vollständigen/differenziellen und häufigen Log-Backups für die Point-in-Time-Wiederherstellung.

Warum: Azure Backup bietet eine native, integrierte und zertifizierte Lösung, die die Backup-Planung, -Aufbewahrung und -Verwaltung automatisiert, ohne dass benutzerdefinierte Skripte oder eine separate Backup-Infrastruktur erforderlich sind.

Umfassendes, zentralisiertes Monitoring für eine SAP-Landschaft in Azure implementieren.

→Azure Monitor for SAP Solutions bereitstellen. Anbieter für SAP HANA, NetWeaver, OS (Linux) und Hochverfügbarkeitscluster-Telemetrie konfigurieren.

Warum: Dies ist ein nativer Azure-Dienst, der für SAP entwickelt wurde. Er bietet umfangreiche, SAP-sensible Telemetrie und Visualisierungen, die das Monitoring des gesamten SAP-Stacks von der Infrastruktur bis zur Anwendung zentralisieren.

Betriebssystem- oder SAP-Kernel-Patches auf einen hochverfügbaren SAP-Cluster mit minimaler Ausfallzeit anwenden.

→Einen Rolling Update-Ansatz verwenden. Den sekundären Knoten in den Wartungsmodus versetzen, patchen und neu starten. Ein kontrolliertes Cluster-Failover durchführen, um den gepatchten Knoten zum primären Knoten zu machen. Schließlich den ehemaligen primären Knoten patchen.

Warum: Dieser rollierende Ansatz stellt sicher, dass der SAP-Dienst auf einem Knoten während des gesamten Wartungsprozesses verfügbar bleibt, wodurch die Geschäftsunterbrechung minimiert wird.

Den Prozess des Erstellens von Kopien oder des Aktualisierens von SAP-Systemen automatisieren (z. B. ein QAS-System von PRD aktualisieren).

→Verwenden Sie SAP Landscape Management (LaMa) mit dem Azure Connector.

Warum: LaMa orchestriert den End-to-End-Prozess, einschließlich Azure-Infrastrukturaufgaben (VM-Stopp/-Start, Datenträger-Snapshots) und SAP-spezifischer Post-Copy-Automatisierung (BDLS), wodurch der manuelle Aufwand erheblich reduziert wird.

Den SAP-Notfallwiederherstellungsplan validieren, ohne die Produktionsumgebung zu beeinträchtigen.

→Verwenden Sie die "Test Failover"-Funktion von Azure Site Recovery, die replizierte VMs in einem isolierten VNet hochfährt. Für HSR verwenden Sie Snapshot-basierte Wiederherstellungen auf ein isoliertes System oder ein dediziertes tertiäres Replikationsziel.

Warum: Das Testen in einem isolierten Netzwerk verhindert IP-Konflikte und jegliche Störungen von Produktionssystemen oder laufender Replikation, was eine sichere und gründliche Validierung des DR-Runbooks ermöglicht.

Zukünftige Ressourcenanforderungen (CPU, Speicher, Storage) für ein wachsendes SAP-System in Azure planen.

→Azure Monitor-Metriken und Log Analytics verwenden, um historische Nutzungstrends zu analysieren. Diese Daten für die Prognose nutzen. Für den Speicher die Möglichkeit nutzen, Azure Managed Disks online dynamisch zu vergrößern.

Warum: Proaktives Kapazitätsmanagement auf Basis historischer Daten verhindert Leistungsverschlechterungen und ermöglicht eine Just-in-Time-Bereitstellung, wodurch Kosten im Vergleich zu einer erheblichen Vorab-Überprovisionierung optimiert werden.

Azure-Kosten für den Betrieb einer vollständigen SAP-Landschaft minimieren.

→Für Produktions-Workloads verwenden Sie 1- oder 3-Jahres Azure Reserved Instances. Für Nicht-Produktionssysteme implementieren Sie automatisierte Start-/Stopp-Zeitpläne über Azure Automation. Nutzen Sie Azure Hybrid Benefit für berechtigte Lizenzen.

Warum: Reserved Instances bieten hohe Rabatte für vorhersehbare, 24/7-Workloads. Die automatische Abschaltung eliminiert Rechenkosten in Leerlaufzeiten für Nicht-Produktionssysteme. Diese Kombination adressiert beide Hauptkostentreiber.

Azure-Kosten für SAP-Workloads bestimmten Geschäftsbereichen, Projekten oder SAP-Systemen (SIDs) zuordnen und verfolgen.

→Eine obligatorische Tagging-Strategie für alle Azure-Ressourcen implementieren. Tags wie `CostCenter`, `Environment`, `SAP-SID` und `BusinessOwner` verwenden. Kosten mit Azure Cost Management analysieren.

Warum: Tagging ist der native Azure-Mechanismus zur Kategorisierung von Ressourcen. Konsistentes Tagging ermöglicht eine detaillierte Kostenanalyse und -verrechnung und bietet wesentliche finanzielle Transparenz.

Intermittierende Netzwerkverbindungs- oder Latenzprobleme zwischen SAP-VMs in Azure diagnostizieren.

→Azure Network Watcher-Tools verwenden, insbesondere Connection Monitor zum Testen von Pfaden und Latenz, und NSG Flow Logs zum Analysieren und Identifizieren von blockiertem Datenverkehr.

Warum: Network Watcher bietet proaktive und reaktive Tools, um Netzwerkprobleme auf Azure-Plattformebene zu lokalisieren, was oft schwierig ist, allein aus dem Gast-OS heraus zu diagnostizieren.

Betriebssystem-Patching für SAP-VMs automatisieren und gleichzeitig sicherstellen, dass Anwendungen ordnungsgemäß heruntergefahren werden.

→Azure Update Manager mit Pre-/Post-Skripten verwenden. Das Pre-Skript stoppt die SAP-Anwendung und -Datenbank, und das Post-Skript startet sie nach Abschluss des Patchings neu.

Warum: Dies kombiniert die Automatisierung des Azure Patch Managements mit der für SAP erforderlichen Anwendungsintelligenz und verhindert Dateninkonsistenzen, die beim Patchen eines laufenden Systems auftreten könnten.

Hochverfügbarkeit für SAP Central Services (ASCS/ERS) oder SAP HANA auf SUSE/RHEL Linux-VMs implementieren.

→Einen Pacemaker-Cluster konfigurieren. Verwenden Sie den `fence_azure_arm`-Agent für STONITH (Fencing), um Split-Brain-Szenarien zu verhindern, authentifiziert über eine verwaltete Identität.

Warum: Pacemaker ist die von SAP unterstützte Clustering-Lösung unter Linux. `fence_azure_arm` ist der Azure-native Mechanismus zur zuverlässigen Isolierung eines ausgefallenen Knotens über Azure APIs, was für einen stabilen Cluster zwingend erforderlich ist.

Hochverfügbarkeit für SAP Central Services (ASCS/ERS) auf Windows Server-VMs implementieren.

→Einen Windows Server Failover Cluster (WSFC) konfigurieren. Für den gemeinsam genutzten Clusterspeicher verwenden Sie entweder Azure Shared Disks oder eine Replikationslösung eines Drittanbieters wie SIOS DataKeeper.

Warum: WSFC ist der Standard für Windows-Clustering. Azure Shared Disks bieten nativen gemeinsamen Blockspeicher, während SIOS einen "Shared-Nothing"-Cluster erstellt; beide ersetzen die Notwendigkeit traditioneller SANs in der Cloud.

Eine Hochverfügbarkeits- (HA) und Notfallwiederherstellungs- (DR) Strategie für SAP HANA entwerfen.

→Für HA (innerhalb der Region) stellen Sie VMs über Verfügbarkeitszonen hinweg bereit und verwenden synchrone (SYNC) SAP HANA System Replication (HSR). Für DR (regionsübergreifend) verwenden Sie asynchrone (ASYNC) HSR.

Warum: Synchrone Replikation bietet ein Zero RPO, erfordert aber eine geringe Latenz (<2ms), was sie ideal für HA über Zonen hinweg macht. Asynchrone Replikation toleriert höhere regionsübergreifende Latenz und ist daher die Wahl für DR.

Einen Azure Load Balancer konfigurieren, um die virtuelle IP-Adresse für einen SAP HA-Cluster (ASCS/ERS oder HANA) zu verwalten.

→Verwenden Sie einen Azure Standard Load Balancer. Aktivieren Sie Floating IP (Direct Server Return) bei der Lastverteilungsregel. Konfigurieren Sie einen Health Probe auf dem spezifischen Port, der vom Cluster überwacht wird (z. B. 620xx für ASCS).

Warum: Die Standard SKU ist für Zonenredundanz erforderlich. Floating IP ist notwendig, damit die virtuelle IP des Clusters korrekt funktioniert. Der spezifische Health Probe stellt sicher, dass der Datenverkehr nur an den aktiven Knoten gesendet wird.

Den Zweck des Enqueue Replication Servers (ERS) in einem SAP ASCS Hochverfügbarkeitscluster verstehen.

→Die ERS-Instanz verwaltet eine Replik der SAP-Sperrtabelle der aktiven ASCS-Instanz.

Warum: Wenn die ASCS-Instanz ein Failover durchführt, ruft die neu gestartete ASCS-Instanz die replizierte Sperrtabelle vom ERS ab. Dies bewahrt Transaktionssperren und ermöglicht es Benutzern, ohne Unterbrechung weiterzuarbeiten.

Eine vollständige Disaster Recovery-Lösung für eine mehrstufige SAP-Landschaft entwerfen.

→Native Datenbankreplikation für die Datenbankschicht verwenden (z. B. asynchrone HSR für HANA). Azure Site Recovery (ASR) für die Anwendungsschicht (ASCS/ERS und Anwendungsserver) verwenden.

Warum: Dieser "Best-of-Breed"-Ansatz gewährleistet die Anwendungskonsistenz für die Datenbank über deren native Replikation, während ASR eine kostengünstige und automatisierte Möglichkeit bietet, die VM des Anwendungsservers zu replizieren und ein Failover durchzuführen.

Hochverfügbarkeit für eine SAP-Datenbank implementieren, die auf Microsoft SQL Server in Azure-VMs ausgeführt wird.

→Verwenden Sie SQL Server Always On Availability Groups, typischerweise mit synchronem Commit-Modus für HA innerhalb einer Region, kombiniert mit einem WSFC.

Warum: Always On AG ist die empfohlene und vollständig unterstützte HA/DR-Lösung für SQL Server, die Datenbank-Level-Replikation und automatische Failover-Funktionen bietet.

SBD (STONITH Block Device) als Quorum-Mechanismus für einen Zwei-Knoten-Pacemaker-Cluster implementieren.

→Eine kleine Azure Shared Disk konfigurieren und an beide Clusterknoten anhängen. Alternativ einen dedizierten iSCSI-Zielserver auf einer dritten VM einrichten.

Warum: Während `fence_azure_arm` der primäre Fencing-Agent ist, bietet SBD einen zusätzlichen Witness-/Quorum-Mechanismus, um Split-Brain zu verhindern, insbesondere in Clustern ohne einen dritten abstimmenden Knoten.