SAP auf Azure: Was du vor der Migration planen musst

Die Grundlage liefert das System selbst. Der EarlyWatch-Alert-Bericht enthält Auslastung, Antwortzeiten und Datenbankwachstum über Monate, die Transaktion ST03N zeigt die Verteilung der Dialogschritte und ST06 die Betriebssystemwerte. Daraus ergeben sich drei Zahlen, die du für die Auslegung brauchst: der benötigte SAPS-Wert für Anwendungs- und Datenbankschicht, der Arbeitsspeicherbedarf der Datenbank und das erwartete Wachstum über die geplante Laufzeit. Für neue Systeme oder größere Umbauten tritt an diese Stelle der SAP Quick Sizer.

# Zustand aller Prozesse einer Instanz
sapcontrol -nr 00 -function GetProcessList
sapcontrol -nr 00 -function GetSystemInstanceList

# HANA: Speicherbelegung und Größe der größten Tabellen
hdbsql -i 00 -u SYSTEM -p '<kennwort>' \
  "SELECT HOST, ROUND(USED_PHYSICAL_MEMORY/1024/1024/1024) AS GB_GENUTZT, \
          ROUND(ALLOCATION_LIMIT/1024/1024/1024) AS GB_LIMIT \
   FROM M_HOST_RESOURCE_UTILIZATION"

# Belegung der Dateisysteme, getrennt nach Daten, Protokoll und Sicherung
df -h /hana/data /hana/log /hana/shared /usr/sap

Der Arbeitsspeicherbedarf der Datenbank bestimmt die Maschinengröße stärker als die Prozessorlast, denn HANA hält die Daten im Speicher. Rechne das erwartete Wachstum von zwei bis drei Jahren auf, sonst steht kurz nach der Migration der nächste Größenwechsel an.

# Welche Größen der M-Serie gibt es in der Region, und in welchen Zonen?
az vm list-skus --location germanywestcentral \
  --resource-type virtualMachines \
  --query "[?starts_with(name,'Standard_M')].{name:name,zonen:locationInfo[0].zones}" \
  -o table

# Näherungsgruppe für kurze Wege zwischen Anwendung und Datenbank
az ppg create --name ppg-sap-prod \
  --resource-group rg-sap-prod --location germanywestcentral

# Datenträger mit eigens gesetzten Leistungswerten
az disk create --resource-group rg-sap-prod --name hana-data-01 \
  --size-gb 512 --sku PremiumV2_LRS \
  --disk-iops-read-write 8000 --disk-mbps-read-write 400 \
  --zone 1

Premium SSD v2 erlaubt es, IOPS und Durchsatz unabhängig von der Größe zu setzen, was die klassische Praxis überflüssig macht, Datenträger nur wegen der Leistungsstufe zu groß zu wählen. Prüfe die geforderten Werte je Dateisystem in den Speicherleitfäden von Microsoft, sie unterscheiden sich für Daten, Protokoll und gemeinsam genutzte Bereiche.

# Speiche für SAP mit getrennten Teilnetzen je Schicht
az network vnet create --resource-group rg-sap-prod \
  --name vnet-sap-prod --address-prefixes 10.42.0.0/16 \
  --location germanywestcentral

az network vnet subnet create --resource-group rg-sap-prod \
  --vnet-name vnet-sap-prod --name snet-sap-db --address-prefixes 10.42.1.0/24
az network vnet subnet create --resource-group rg-sap-prod \
  --vnet-name vnet-sap-prod --name snet-sap-app --address-prefixes 10.42.2.0/24

# Kopplung an den Hub mit der ExpressRoute-Verbindung
az network vnet peering create --resource-group rg-sap-prod \
  --name sap-zu-hub --vnet-name vnet-sap-prod \
  --remote-vnet /subscriptions/$ABO/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworks/vnet-hub \
  --allow-vnet-access --allow-forwarded-traffic --use-remote-gateways

Die Option --use-remote-gateways ist der Punkt, an dem SAP-Speichen häufig scheitern: Ohne sie nutzt das Netz das ExpressRoute-Gateway im Hub nicht, und die Anbindung ans eigene Rechenzentrum bleibt aus. Wie dieser Hub grundsätzlich aufgebaut wird, beschreibt die Anbindung des eigenen Rechenzentrums.

# Auf dem Datenbankserver: niping als Server starten
niping -s -I 0

# Auf dem Anwendungsserver: 100 Durchläufe mit 1000 Byte Nutzlast
niping -c -H db-prod-01 -B 1000 -L 100

# Gegenprobe auf Paketebene
ping -c 100 db-prod-01 | tail -2

Für die Umlaufzeit zwischen Anwendungs- und Datenbankschicht nennt Microsoft in den Leitfäden zu Näherungsgruppen eine Größenordnung unterhalb von etwa 0,7 Millisekunden. Miss diesen Wert vor dem Rollout und schreibe ihn in die Projektakte, damit spätere Leistungsdiskussionen einen Bezugspunkt haben.

# Pacemaker-Cluster für ASCS und ERS, hier auf SLES
sudo crm status
sudo crm configure show | grep -A5 stonith

# Auf RHEL heißt das Werkzeug anders
# sudo pcs status

# HANA-Systemreplikation: Zustand aus Sicht der primären Instanz
sudo -u hdbadm hdbnsutil -sr_state
sudo -u hdbadm /usr/sap/HDB/HDB00/HDBSettings.sh systemReplicationStatus.py

Der Rückgabewert von systemReplicationStatus.py ist entscheidend: 15 bedeutet aktiv und im Gleichlauf, alles andere ist ein Befund. Diese Prüfung gehört in die Überwachung, nicht in eine wöchentliche Sichtkontrolle, denn eine unterbrochene Replikation fällt sonst erst im Notfall auf.

Für die Ebene der zentralen Dienste ist die Fencing-Konfiguration der kritische Punkt. Der Cluster braucht ein zuverlässiges Verfahren, um einen hängenden Knoten abzuschalten, in Azure entweder über den Fence-Agenten, der die Maschine per Verwaltungsschnittstelle stoppt, oder über ein SBD-Gerät. Ohne funktionierendes Fencing entsteht im Fehlerfall genau die Situation, die ein Cluster verhindern soll, nämlich zwei Knoten, die gleichzeitig dieselben Ressourcen beanspruchen. Für die Notfallwiederherstellung in eine zweite Region ist bei HANA die asynchrone Systemreplikation der übliche Weg, nicht eine allgemeine Maschinenreplikation. Lege dabei Wiederherstellungszeit und zulässigen Datenverlust vorher schriftlich fest, denn diese beiden Zahlen bestimmen, wie viel die zweite Region kostet.

# Azure Backup für HANA: gesicherte Elemente auflisten
az backup item list --resource-group rg-sap-prod \
  --vault-name rsv-sap-prod --output table

# Wiederherstellungspunkte eines Elements ansehen
az backup recoverypoint list --resource-group rg-sap-prod \
  --vault-name rsv-sap-prod --container-name <container> \
  --item-name <element> --output table

# Bei Azure NetApp Files: anwendungskonsistente Momentaufnahmen
azacsnap -c backup --volume data --prefix taeglich --retention 30

Für HANA zählt nur eine über die Backint-Schnittstelle zertifizierte Sicherung als unterstützt. Eine Momentaufnahme des Datenträgers ohne Abstimmung mit der Datenbank ist im besten Fall unbrauchbar und im schlechtesten trügerisch, weil sie sich anstandslos anlegen lässt.

Nach dem Cutover beginnt der Teil, der über die Gesamtkosten entscheidet. Maschinen der M-Serie zum vollen Preis rund um die Uhr sind der größte Posten einer SAP-Landschaft in Azure, deshalb gehören Reservierungen für die produktive Grundlast und Abschaltzeitpläne für Entwicklungs- und Qualitätssicherungssysteme früh eingerichtet. Wie du die Rechnung danach systematisch auseinandernimmst, steht in Cloud-Rechnung zu hoch. Und wenn neben SAP weitere Systeme umziehen sollen, lohnt sich der allgemeine Ablauf aus Cloud-Migration planen, weil SAP darin ein Sonderfall mit eigenen Regeln bleibt.