T-Systems-Claim-Logo
Suchen
IM-Hero

Flexibilisieren Sie Ihre SAP Workloads wie nie zuvor

Eine Serie von fünf Blogposts, in der wir zeigen, wie man SAP-Systeme für Enterprise-Anforderungen auf AWS einrichtet. Lesen Sie hier Teil 1 der Serie.

21. September 2020Norbert Putz

Aufsetzen von SAP-Systemen in Amazon Web Services

Diese Blogpost-Serie basiert auf einem Proof of Concept, in dem wir demonstrieren, wie einfach es ist, SAP Application Server mit einem Network Load Balancer zu verbinden. Der Letztere wird zudem verknüpft mit einer AWS AutoScaling Group, mit der wir die Flexibilität der Cloud voll ausschöpfen können. Die Architektur, die wir in den fünf Beiträgen beschreiben, erlaubt die Skalierung nach oben und unten über mehrere Verfügbarkeitszonen (AZ) hinweg. Die Basis dafür sind passende Skalierungsrichtlinien. In diesem Teil richten wir zunächst die SAP-Landschaft in AWS ein. 

Die SAP Cloud Appliance Library

SAP Cloud Appliance Library

Abbildung 1: Architekturdesign im Überblick

Für diesen Proof of Concept nutzen wir zwei Provider: SAP und AWS. Die Unternehmen arbeiten bereits seit über 12 Jahren zusammen und haben mehr als 5.000 Kunden weltweit, die SAP-Workloads in der Cloud betreiben (Quelle: https://aws.amazon.com/sap/). Lassen Sie also auch uns das Beste beider Welten kombinieren: SAP als ERP-Lösung und die Cloud-Infrastrukturen von AWS. 

Wir benötigen nur ein einziges Tool, um die SAP-Landschaft einzurichten: die SAP Cloud Appliance Library (CAL). Mit ihr ordnen wir den Applikationsservern die erforderlichen AWS-Infrastrukturkapazitäten zu. Sie haben noch nie von SAP CAL gehört? Probieren Sie es aus, denn das Tool ist kostenlos (Sie zahlen nur für die genutzten AWS-Ressourcen). Mit SAP CAL haben wir nun die Möglichkeit, SAP-Landschaften in einer Art Testmodus für alle Phasen von SAP-Projekten bereitzustellen: Validierung, Test, Demo, Entwicklung, Proof of Concept, Schulung und Evaluation sowie Produktion. Weitere Informationen dazu finden Sie im allgemeinen FAQ-Bereich von CAL. SAP CAL unterstützt alle drei großen Cloud-Anbieter. In diesem Beitrag werden wir uns jedoch auf Amazon Web Services konzentrieren. 

Setup der Landschaft

Unser Ziel in diesem ersten Teil der Blogpost-Serie ist es, unsere SAP-Landschaft mit Hilfe der SAP Cloud Appliance Library einzurichten. Die folgende Architektur zeigt, wie das Setup am Ende des ersten Teils aussehen wird. 

Overview SAP Cloud Appliance Library

Abbildung 2:  Hinzufügen eines AWS-Kontos zur SAP Cloud Appliance Library

Nach der Registrierung müssen wir SAP CAL „sagen”, mit welchem AWS-Konto wir arbeiten wollen. Dabei verlangt CAL einige Details. Zu diesen gehören u.a. der Zugriffsschlüssel und der geheime Zugriffsschlüssel der IAM-Benutzer. Weitere Informationen zum Erstellen der erforderlichen Schlüssel für einen IAM-Benutzer finden Sie in der offiziellen AWS-Dokumentation. Wichtig: Wir müssen die folgenden IAM-Richtlinien mit dem IAM-Benutzer verknüpfen: 

  • AmazonEC2FullAccess 
  • AmazonVPCFullAccess 
  • ReadOnlyAccess 
  • AWSAccountUsageReportAccess 

Falls diese Richtlinien fehlen, wird ein Deployment unmöglich. Zusätzliche Details hierzu bietet das offizielle FAQ-Dokument bei SAP. 

Accounts via Amazon Web Services

Abbildung 3: AWS-Account ist aktiv

Wenn alles gut gegangen ist, sollten wir den folgenden Eintrag unter Accounts finden:

figure4

Abbildung 4: SAP NetWeaver AS ABAP 7.51 SP02 auf HANA

Als nächsten Schritt wählen wir die SAP-Lösung; in unserem Fall SAP NetWeaver AS ABAP 7.51 SP02 on HANA: 

Cost Calculator via Amazon Web Services

Abbildung 5: Kostenrechner

Bereits hier bekommen wir durch Klicken auf Calculate Costs einen Eindruck über die Kosten, die unsere SAP-Landschaft erzeugen wird. Unsere Demo enthält die folgenden Posten: 

Instances via Amazon Web Services

Abbildung 6: Aktive SAP-Lösung

Für die SAP-CAL-Bereitstellung ist Nord Virginia als Standardregion voreingestellt (USA-East-1). Unsere Lösung enthält zwei EC2-Instanzen: eine für das SAP-Frontend mit der vorinstallierten und vorkonfigurierten SAP-GUI („SAP Frontend”) und eine deutlich leistungsfähigere r4-Instanz für das SAP-Backend, den SAP Application Server in der SAP-HANA-Datenbank („Linux”, s. Abbildung 5). 

Die folgenden Komponenten werden auf den virtuellen Maschinen installiert: 

  • SAP Kernel 7.49 Linux auf x86_64 64bit 
  • SAP HANA Platf. Ed. 1.0 (SAP HANA DB 1.00.122.07) 
  • NetWeaver AS ABAP 7.51-Innovationspaket SP02 

Weitere Details finden Sie im offiziellen Dokument Erste Schritte

Erstellen Sie Ihre SAP-Landschaft mit einem Klick 

Entspricht diese SAP-Lösung unseren Anforderungen? Wir sind zufrieden und starten die Bereitstellung, indem wir auf die Schaltfläche Create Instance in der rechten oberen Ecke klicken. Bevor es losgeht, müssen wir aber – wie üblich – die Allgemeinen Geschäftsbedingungen über „I accept” annehmen. Dann müssen wir noch das zugehörige AWS-Konto festlegen, entweder ein bereits existierendes oder ein neues, das wir dann noch erstellen müssen. Zudem fragt SAP CAL uns nach dem Namen des Stacks und der Region (wie oben bereits geschrieben ist für die Region nur US-East-1 für das Backend möglich) sowie nach einem Passwort. Letzteres wird mehrfach verwendet, nämlich für: 

  • den Master User des Datenbankservers (user: system) 
  • den HANA-Administrator (user: hdbadm) 
  • den ABAP-Administrator (user: a4hadm) 
  • den SAP-Systemadministrator (user: sapadm) 
  • und als Initialkennwort für den Administrator des SAP Frontend  

Nach dem Klicken auf Create wird der SAP-Stack mit einer Windows 2012 R2-Serverinstanz und einer SUSE Linux Enterprise Server 12 SP 3-Instanz erstellt. Im Basismodus ist das schon alles. Dies kann bis zu 30 Minuten dauern. 

Natürlich ist es möglich, den Stack im Advanced Mode zu optimieren, z. B. mit einer Bereitstellung in einer vorhandenen Virtual Private Cloud (VPC) und einem Subnetz in AWS. Hier können wir auch verschiedene EC2-Instanztypen auswählen und die Speichergrößen der EBS-Volumes ändern. Zusätzlich bietet SAP hier die Möglichkeit, die Regeln der von den Instanzen verwendeten Sicherheitsgruppen zu ändern.  

Herzlichen Glückwunsch – die SAP-Landschaft ist betriebsbereit 

Nun ändert sich der Status der Instanzen in „aktiv”. Unsere SAP-Landschaft ist einsatzbereit. 

Analytics via Amazon Web Services

Abbildung 7: AWS EC2 console

Das können wir mit einem Blick auf unsere Management-Konsole bei AWS kontrollieren. Das EC2-Dashboard muss zwei neue virtuelle Maschinen anzeigen. Et voilà: 

Kostenoptimierung – Best Practices

Wenn Sie unseren Proof of Concept „live“ ausprobieren, ist es wichtig, dass Sie auf die Kosten achten. Mit der SAP Cloud Appliance Library (CAL) können wir die SAP-Landschaft jederzeit anhalten, wenn wir sie nicht mehr benötigen. Dazu wählen wir in der SAP-CAL-Konsole Suspend. Das stoppt beide Instanzen (sie werden aber nicht endgültig abgeschaltet!). Auf diese Weise sparen wir Geld, wenn wir unser Test-Setup nicht verwenden. Die Kosten gehen aber nicht auf Null. Das obige Kostenbeispiel zeigt: Auch angehaltene Instanzen erzeugen Kosten. Wenn wir die Landschaft mehrere Tage nicht nutzen wollen, lohnt es sich, sie zu beenden. Damit sparen wir auch die Kosten des Suspended-Status ein. Die SAP-Lösung kann jederzeit wieder bereitgestellt werden. 

Das Appetithäppchen für Teil 2 

„Und nächste Woche sehen Sie ...” – wie in TV-Serien erfolgreich erprobt, wollen wir Ihnen hier noch einen kurzen Ausblick auf den nächsten Teil unserer Blogserie geben. Im zweiten Teil werden wir unsere SAP-Landschaft besser auf Unternehmensbedürfnisse anpassen, indem wir sie für den Einsatz einer Autoscaling-Gruppe vorbereiten. Wir erstellen dazu ein benutzerdefiniertes Shell Script.
t’s a kind of magic.

Bleiben Sie dran – Teil 2 kommt demnächst! Viel Spaß beim Ausprobieren. 

Zur Person
Norbert Putz, Cloud Architect

Norbert Putz

Cloud Architect, T-Systems International GmbH

Profil und alle Artikel ansehen
Besuchen Sie t-systems.com außerhalb von Germany? Besuchen Sie die lokale Website für weiterführende Informationen und Angebote für Ihr Land.