Diese Blogpost-Serie basiert auf einem Proof of Concept – und zwar wollen wir Ihnen zeigen, wie einfach es ist, SAP Application Server mit einem Network Load Balancer zu verbinden. Damit Sie das Beste aus Ihrer Cloud-Flexibilität herausholen können, wird der Network Load Balancer mit der AWS Auto Scaling Group verbunden. Es ist genau diese Architektur, die es uns möglich macht, über mehrere Verfügbarkeitszonen (AZ) hinweg nach oben und nach unten zu skalieren. In diesem Teil richten wir das SAP Backend ein und optimieren es mit einem maßgeschneiderten Skript.
Abbildung 1: Verbinden mit dem SAP Frontend
Was haben wir in Teil 1 gemacht? Mit Hilfe der SAP Cloud Appliance Library haben wir die Basis für unseren Proof of Concept bereitgestellt – in Gestalt zweier EC2-Instanzen. Eine für das SAP Frontend mit vorinstalliertem SAP Logon auf einem Microsoft Windows R2 2012 Server und, das Herzstück dieses Projekts, das SAP Backend mit SAP Application Server und SAP HANA In-Memory-Datenbank.
Bevor wir etwas am ursprünglichen Setup verändern, wollen wir uns erstmal ansehen, was wir in unserem AWS-Konto haben. Wie schon erwähnt, befinden sich hier zwei Instanzen mit vorkonfigurierten Security Groups, die uns eine Verbindung mit dem Windowsrechner über das Remote Desktop Protocol auf Port 3389 und mit SSH zum SAP Backend auf dem Standardport 22 ermöglichen. Starten wir nun den SAP Frontend-Teil. In der AWS EC2 Management Console genügt es hierzu, die Instanz zu markieren und auf den „Connect”-Button zu klicken (siehe Abbildung 1).
Abbildung 2: SAP Logon
Öffnen wir das Dokument und geben für Zugriff das Passwort für den Benutzer „Administrator” ein, das wir in der SAP CAL festgelegt haben. Wir starten eine neue Sitzung und öffnen das SAP Logon (siehe Abbildung 2). A4H ist die System-ID (SID) unserer SAP NetWeaver-Installation. Mit einem Doppelklick auf den Eintrag sehen wir den Anmeldebildschirm für A4H. Dort geben wir DEVELOPER als Benutzer an, und verwenden dasselbe Passwort wie für die Windows-Instanz (das ursprünglich aus der SAP CAL-Konsole stammt). Voilà! Willkommen in unserer SAP-Welt.
Abbildung 3: SAP Transaktion OS01
In der SAP-Transaktion OS01 (siehe Abbildung 3) können wir noch einmal überprüfen, ob auch alles beim Alten ist. Das SAP-Backend-System besteht aus Applikationsserver und Datenbankserver. Später nutzen wir diese Transaktion, um zu prüfen, an welcher virtuellen Maschine wir angemeldet sind. So können wir sicherstellen, ob die Skalierungslösung und das Load Balancing auch funktionieren und welche SAP-Backend-Instanz wir tatsächlich verwenden.
Abbildung 4: Herunterladen des Schlüssels in SAP CAL
Bis jetzt läuft unsere SAP-Landschaft wie am Schnürchen. Was können wir noch tun, um sie optimieren?
Wie wir sehen, funktioniert das SAP Backend tadellos, jedoch war es bis hierhin eine „black box”. Schauen wir sie einmal näher an. Dazu nutzen wir SSH. Es gibt viele Möglichkeiten, sich in ein Linux-System einzuloggen, der einfachste Weg für Windows-10-Benutzer wie mich ist die Verwendung des OpenSSH SSH Client via Command Prompt (CMD). Hierfür benötigen wir den Schlüssel (.pem). Falls wir ihn noch nicht heruntergeladen haben, müssen wir das nun tun. Abbildung 4 zeigt, wie das in der SAP CAL Konsole geht:
Abbildung 5: SSH-Zugriff auf das SAP Backend
Sobald Sie ihn haben, öffnen Sie Command Prompt (CMD) und geben den SSH-Befehl emtsprechend Abbildung 5 ein. Weitere Einzelheiten dazu, wie Sie sich auf alternative Weise mit einer Linux-Instanz verbinden können, finden Sie entweder in den AWS-Unterlagen oder in SAP CAL's Getting Started, Kapitel 2.5.
Abbildung 6: /etc/hosts file
Wie Abbildung 6 zeigt, befinden sich in /etc/hosts, wo die Hostname-to-Adress-Mappings für die TCP/IP-Subsysteme enthalten sind, zwei Einträge für unsere SAP-Landschaft. Der gelb markierte Eintrag ist der problematische, weil er u.a. den Hostnamen für die Datenbank und die Zentralinstanz festlegt. Aber wenn wir skalieren wollen, können wir dieselbe private IP-Adresse nicht für verschiedene Instanzen verwenden. Was sollen wir also tun?
Abbildung 7: Das Zauberskript
Keine Sorge, es ist ein Leichtes, diesen Eintrag beim Hochfahren so zu verändern, dass dem Hostnamen die richtige private IP-Adresse zugewiesen wird. Aber wie? Abbildung 7 zeigt uns die Lösung; im Folgenden schauen wir uns die Befehle im Detail an.
Abbildung 8: Image erzeugen
In Zeile 11 erhalten wir die private IP, die der virtuellen Netzwerkschnittstelle eth0 zugewiesen wird. In Zeile 15 werden wir den sed (Stream-Editor zum Filtern und Transformieren von Texten) verwenden. Die Option -i legt fest, dass die Datei /etc/hosts an Ort und Stelle bearbeitet wird. Das „d" hier steht für delete und löscht alle Zeilen, die „vhcalhdbdb“ enthalten, also den Hostnamen. Danach wird durch einen einfachen echo-Befehl die private IP mit den Hostnamen an /etc/hosts angehängt mit dem Kommentar, dass sie von sap-up.sh hinzugefügt wurde.
Da wir eine große Änderung vorgenommen haben und auch die SAP-Komponenten darüber „informiert" werden müssen, werden wir zunächst die SAP-HANA-Datenbank mithilfe des Befehls sapcontrol stoppen, der sich im Ordner /usr/sap/hostctrl/exe befindet. Nach Angabe der Instanznummer (in unserem Fall 00) und deren Ausführung mit der Option -function Stop (Zeile 23) wird die SAP HANA-Datenbank gestoppt. Da sie eine wichtige Komponente des SAP-NetWeaver-Stacks ist, wird sie auf dieselbe Weise gestartet, wie sie gestoppt wurde, nämlich mit der Option -function Start (Zeile 27). Es bleibt nur noch eines übrig: den SAP NetWeaver-Stack zu stoppen/zu starten. Dies geschieht als Benutzer a4hadm und mit der Option -c „stopsap r3" (Zeile 31) sowie mit der Option -c „startsap r3" (Zeile 35). Um dieses Skript beim Booten auszuführen, könnten wir auch einen crontab-Eintrag verwenden, jedoch möchten wir uns auf native Cloud-Lösungen konzentrieren. AWS bietet uns die Möglichkeit, Skripte beim Booten als „Use Data" auszuführen. In Teil 3 werden wir eine Startvorlage erstellen und dieses Skript darin einbinden.
Mit unseren erwähnten Schritten steht unserem „goldenen” AMI nun nichts mehr im Wege, welches wir als Grundlage unseres Launch Templates für die Auto Scaling Group verwenden.
AMI steht für Amazon Machine Image. Dies kann verschiedene Typen haben: öffentlich, privat und owned by me. Wenn wir unser eigenes Image erstellen, wird es uns unter „owned by me" gezeigt. Zunächst müssen wir die SAP-Backend-Instanz anhalten. Wie Abbildung 8 zeigt, können wir unter Action/Image/Create Image ein AMI erstellen.
Abbildung 9: Name und Image-Beschreibung
Im folgenden Fenster sollen wir einen Namen für das Amazon Machine Image sowie eine Beschreibung festlegen (Abbildung 9).
Nach ein paar Minuten erhält das AMI den Status available und ist startbereit.
Mit der Vorbereitung des SAP-Backend auf Basis von AWS-Plattformdiensten und etwas Cloud-Magie beenden wir diesen zweiten Teil. Ich hoffe, es hat Ihnen gefallen und Sie bleiben weiter neugierig auf unser finales Setup mit der funktionierenden Lösung.
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.
„Sehen Sie nächste Woche..." – genau wie in den Fernsehserien soll dieser abschließende Abschnitt eine kurze Einführung darüber geben, was in Teil 3 geschehen wird. In unserem dritten Teil werden wir uns auf die Auto Scaling Group und die Skalierungsrichtlinien konzentrieren. Wir werden ein Launch Template auf Grundlage der goldenen Amazon Machine Images erstellen, das wir hier in Teil 2 erstellt haben.
