SAP on AWS: Enterprise-Architektur, zertifizierte Instanzen und der Weg in die Public Cloud

Willkommen im Maschinenraum der modernen Enterprise-IT! Wer im Jahr 2019 in großen Konzernen große Cloud-Migrationen plant, kommt an einem Thema nicht vorbei: Die Verlagerung monolithischer SAP-Landschaften in die Public Cloud. Amazon Web Services (AWS) hat sich hier als absoluter Vorreiter etabliert. Das alte Dogma, dass eine SAP HANA zwingend auf zentnerschwerem "Big Iron" im eigenen Rechenzentrum laufen muss, ist endgültig gefallen.

Als Senior SAP Technology Consultant werfe ich heute einen detaillierten Blick auf die architektonischen Fundamente von SAP on AWS. Wir klären die Mythen rund um zertifizierte Instanzen, sezieren das Netzwerk-Design und zeigen, wie High Availability (HA) in der Cloud wirklich funktioniert.

Das Herzstück: AWS EC2 Instanzen für SAP HANA

Nicht jede virtuelle Maschine darf eine SAP-Datenbank hosten. SAP verfolgt hier das strenge TDI-Konzept (Tailored Datacenter Integration), das auch für Cloud-Provider gilt. AWS lässt seine EC2-Instanzfamilien aufwendig von SAP zertifizieren, um die geforderten KPI-Werte (CPU-Throughput, Memory-Latenz) zu garantieren.

Architekten müssen bei der Skalierung im Jahr 2019 grundlegend zwischen zwei Datenbank-Typen unterscheiden:

1. Scale-Up (OLTP - S/4HANA & Business Suite): Das Wachstum findet innerhalb einer einzigen, massiven Instanz statt.

2. R4/R5-Instanzen: Perfekt für kleinere Workloads und Test-Systeme (Memory-to-vCPU Ratio von 8:1, bis zu 768 GB RAM).

3. X1 und X1e-Instanzen: Das absolute Arbeitstier für große S/4HANA-Systeme. Die x1e.32xlarge liefert unglaubliche 4 TB RAM (ausgestattet mit vier Intel Xeon E7 8880 v3 Prozessoren).

4. High Memory Instances (Bare Metal): Für die absoluten Giganten. Seit Ende 2018 bietet AWS dedizierte Hosts mit 6 TB, 9 TB und 12 TB RAM an, die nahtlos in die Virtual Private Cloud (VPC) integriert sind.

5. Scale-Out (OLAP - SAP BW/4HANA): Hier werden mehrere EC2-Instanzen zu einem Cluster zusammengeschaltet. AWS unterstützt Scale-Out-Architekturen mit bis zu 50 Terabyte Gesamtspeicher (z.B. durch das Bündeln von mehreren 2-TB- oder 4-TB-Instanzen).

Storage-Architektur: IOPS sind das neue Gold

Eine HANA-Datenbank im RAM ist schnell, aber ohne performanten persistierenden Speicher für das Transaction Log (/hana/log) droht Datenverlust oder ein massiver Performance-Knick beim asynchronen Schreiben (Savepoints).

In AWS nutzen wir dafür Amazon EBS (Elastic Block Store). Das klassische Architektur-Design 2019 sieht so aus:

• OS und SAP-Binaries (/usr/sap): Hier reichen kosteneffiziente SSD-Volumes vom Typ gp2 (General Purpose SSD).

• HANA Data (/hana/data): Häufig ebenfalls gp2, da Leseoperationen primär im RAM stattfinden.

• HANA Log (/hana/log): Hier sind sub-millisekunden Latenzen Pflicht! Architekten setzen hier zwingend auf io1-Volumes (Provisioned IOPS), bei denen die I/O-Operationen pro Sekunde (IOPS) hart garantiert und unabhängig von der Speicherkapazität allokiert werden können.

Netzwerk und High Availability (HA) jenseits des Rechenzentrums

Im klassischen Rechenzentrum wird High Availability oft über Layer-2-Netzwerke und Floating IPs via Gratuitous ARP gelöst. In der AWS Virtual Private Cloud (VPC) funktioniert das Broadcast-Routing auf Layer-2 so nicht. Wie bauen wir also einen Pacemaker-Cluster über zwei Rechenzentren?

AWS bietet das Konzept der Availability Zones (AZs) – physisch getrennte, aber über hochperformante Glasfaser verbundene Rechenzentren innerhalb einer Region (z.B. eu-central-1 in Frankfurt).

Das Overlay-IP Konzept: Wir platzieren die primäre HANA-Instanz in AZ-A und die sekundäre Instanz in AZ-B (HANA System Replication im Modus SYNC). Der SUSE Linux Enterprise Server (SLES) Pacemaker-Cluster überwacht die Knoten. Fällt Node A aus, übernimmt Node B. Da Node B in einem anderen IP-Subnetz liegt, nutzt der Cluster-Ressource-Agent das AWS API. Er schreibt die Routing-Tabelle der VPC dynamisch um, sodass Traffic, der an die virtuelle "Overlay-IP" der Datenbank gerichtet ist, ab sofort auf die EC2-Instanz in AZ-B geroutet wird. Der SAP-Applikationsserver (ASCS / DIA) merkt von diesem Failover auf Netzwerkebene im Idealfall fast nichts.

🚀 SAP & AWS News-Ticker (Stand: Mai 2019)

Um bei der rasanten Evolution der Cloud-Technologien den Überblick zu behalten, fasse ich ab sofort die wichtigsten architektonischen News für euch zusammen:

• Neue Bare-Metal Giganten: AWS hat im April 2019 die Verfügbarkeit von neuen Amazon EC2 High Memory-Instanzen mit 18 TB und 24 TB RAM angekündigt. Ein massiver Meilenstein für die Migration von extrem großen, monolithischen ERP-Systemen, die bisher On-Premise gefangen waren.

• SAP Cloud Platform (Neo vs. Cloud Foundry): SAP treibt die Öffnung voran. Immer mehr Services der SAP Cloud Platform (heute BTP) sind nun direkt in AWS-Rechenzentren verfügbar, was die Latenz zwischen S/4HANA (gehostet auf EC2) und den SAP SaaS-Diensten drastisch minimiert.

• AWS Transit Gateway: Dieses Ende 2018 eingeführte Feature wird 2019 zum De-facto-Standard für komplexe SAP-Landschaften. Es ersetzt das chaotische VPC-Peering durch eine zentrale Hub-and-Spoke-Architektur, was das Routing zwischen SAP-Dev-, QA- und Prod-VPCs massiv vereinfacht.

Fazit

Die Migration von SAP auf AWS ist nicht das bloße Verschieben virtueller Maschinen. Es erfordert ein tiefgreifendes Umdenken der Architektur-Prinzipien. Wer die Spezifikationen der X1e-Instanzen kennt, den Unterschied zwischen io1 und gp2 Storage beherrscht und weiß, wie man Pacemaker-Cluster via Overlay-IPs über AWS Availability Zones spannt, hält den Schlüssel zur IT der Zukunft in den Händen. Die Cloud ist 2019 endgültig Enterprise-ready.