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 Auto Scaling 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. Heute schauen wir uns die Auto Scaling Group (ASG) genauer an.
Abbildung 1: Erzeugung des Launch Templates
Was geschah in Teil 2? Mithilfe eines benutzerdefinierten Shell-Skripts konnten wir die richtige private IP-Adresse für unsere Hostnamen definieren. Dieses Skript führen wir (automatisch) bei jedem Start aus. Danach haben wir ein sogenanntes „goldenes“ AMI (Amazon Machine Image) als Basis für unser Launch Template erstellt.
Launch Templates erlauben das Speichern von Startparametern, sodass wir diese nicht jedes Mal manuell angeben müssen, wenn wir eine Instanz starten. Diese Funktion benötigen wir, wenn wir den Skalierungsprozess automatisieren möchten. Weitere Informationen zu Launch Templates finden Sie in der offiziellen AWS-Dokumentation. Beginnen wir mit unserer eigenen benutzerdefinierten Startvorlage. In der EC2-Konsole auf der linken Seite im Navigationsbereich finden Sie die Funktion zum Erstellen eines Launch Templates (der dritte Menüpunkt unter „Instances“).
Abbildung 2: Auswahl des AMI
Im ersten Schritt definieren wir den Namen und eine Beschreibung des Templates. Darüber hinaus haben wir die Möglichkeit, Tags hinzuzufügen und auszuwählen, ob wir das Template aus einer bereits vorhandenen Vorlage („Quellvorlage“) erstellen möchten. Diese Funktionen blenden wir in diesem Post aus – wir erstellen unser eigenes Template. Wie Abbildung 2 zeigt, wählen wir im nächsten Schritt unser goldenes AMI aus, das wir in Teil 2 erstellt haben. Wir finden es unter „my AMIs“ oder wir tragen die AMI-ID direkt ein. Sie beginnt treffenderweise mit „ami-“.
Abbildung 3: Instanztyp
Im nächsten Schritt wählen wir einen Instanztyp aus. Wir greifen wieder auf eine r4.8xlarge zurück, die wir bereits beim Aufsetzen der SAP-Landschaft genutzt hatten:
Abbildung 4: Security Group
Natürlich brauchen wir auch hier wieder unser Schlüsselpaar (Abb. 2 unten). Das gibt uns die (sehr nützliche) Möglichkeit, uns bei den erstellten EC2-Instanzen später anzumelden. Wir können dasselbe Schlüsselpaar wie für die SAP-CAL-Instanzen verwenden oder ein neues erstellen – Letzteres verursacht ein wenig zusätzlichen Aufwand, erhöht aber das Sicherheitsniveau erheblich.
Im nächsten Abschnitt definieren wir die Security Group. Da SAP CAL bereits die richtigen Regeln für eingehende und ausgehende Nachrichten erstellt hat, werden wir diese für das SAP-Backend erstellte Sicherheitsgruppe wiederverwenden. Gleichzeitig können wir überprüfen, ob der Name der zugewiesenen Sicherheitsgruppe in der EC2-Konsole korrekt ist. Er beginnt mit „sg-“.
Abbildung 5: User data
Die Einträge für Speicher (Volumes), Ressource Tags und Netzwerkschnittstellen bleiben unverändert. Im Abschnitt „Advanced Details” finden wir unten ein Textfeld, in dem wir unser magisches Skript als „user data“ festlegen können (siehe Abbildung 5).
Abbildung 6: Launch Template mit Details
Das war’s. Nach Klicken auf Create launch template können wir mit dem Aufbau unserer Auto Scaling Group beginnen.
Mithilfe des Amazon EC2 Auto-Scaling-Dienstes können wir sicherstellen, dass immer die richtige Anzahl von EC2-Instanzen verfügbar ist, um die Arbeitslast unserer SAP-Anwendung zu bewältigen. Weitere Informationen zum Service finden Sie in der offiziellen AWS-Dokumentation. Werfen wir einen Blick auf das Setup.
Zuerst müssen wir den Namen unserer ASG und das Launch Template definieren, das wir im vorherigen Abschnitt erstellt haben. Wir erhalten erneut eine Übersicht über die ausgewählte Version (falls Sie sie ändern, wird eine neue Version erstellt), die AMI-ID, den Instanztyp, den Schlüsselpaarnamen und die Sicherheitsgruppen-ID – mit anderen Worten: eine Übersicht über alles, was wir zuvor definiert haben (Abbildung 6). Ein guter Zeitpunkt, um zu überprüfen, ob alles passt.
Abbildung 7: Auto scaling – ASG-Größe
Im folgenden Fenster belassen wir die Kaufoptionen und den Instanztyp wie im Standard vorgegeben als „Adhere to launch template“. Wir konzentrieren uns nun auf das Netzwerk-Setup. Da wir eine Multi-AZ-Lösung erstellen wollen, wählen wir zunächst die richtige VPC (am besten diejenige, die SAP CAL bereits für uns erstellt hat). Wir brauchen auch alle verfügbaren Subnetze, in unserem Fall fünf in der Region us-east-1. Der folgende Bildschirm bietet uns drei Optionen für das Load Balancing. Diesen Teil werden wir im Moment überspringen – der nächste Blogpost wird sich ausschließlich damit beschäftigen. Health Check und Additional Settings bleiben unverändert. Zurück zu unserem eigentlichen Thema: Im nächsten Schritt legen wir die Größe der ASG fest, indem wir einen Wert für die gewünschte, die Minimal- und die Maximalgröße eintragen. Abbildung 7 zeigt ein Beispiel zum besseren Verständnis.
Abbildung 8: Größe der Auto Scaling Group
In diesem Beispiel haben wir die Mindestgröße auf eine Instanz festgelegt. Damit stellen wir sicher, dass das SAP-Backend immer verfügbar ist. Da wir ein redundantes Setup für mehrere Verfügbarkeitszonen definiert haben, wird in unserem Maximalszenario jede Instanz in einer anderen Verfügbarkeitszone (in fünf verschiedenen Subnetzen) gestartet. Wenn beispielsweise der Health Check Probleme mit der ursprünglichen Instanz in us-east-1a findet, haben wir immer noch Instanzen in anderen Verfügbarkeitszonen, sodass das SAP-Backend-System erreichbar bleibt. Die gewünschte Kapazität definiert die Anzahl der EC2-Instanzen, die wir im „Normalfall“ haben möchten. Da wir ein Load-Balancing-Setup definieren möchten, haben wir als gewünschte Kapazität zwei Instanzen definiert. Die maximale Größe definiert – wie der Name unschwer verständlich andeutet – die maximale Anzahl von EC2-Instanzen, die unsere ASG starten darf. Wie bereits erwähnt, ist dies nur ein Beispiel. Bitte denken Sie daran, eine höhere, aber nicht zu hohe Anzahl einzurichten. Die Architektur muss immer dem geplanten Zweck dienen. Ich werde mit dem in Abbildung 8 gezeigten Setup fortfahren.
Abbildung 9: Target Tracking Policy
In unserem Proof of Concept werden wir eine Target Tracking Scaling Policy mit den Werten aus Abbildung 9 einrichten. Die Werte dienen nur zu Testzwecken. Unser Plan ist es, das SAP-Backend zu belasten und eine hohe CPU-Auslastung zu erzielen, damit wir testen können, ob unsere SAP-Landschaft wirklich skaliert, wie von uns gewünscht. Wir haben relativ kleine Werte als Target Value festgelegt, damit wir die Reaktion der AWS-Services früher sehen und nicht zu lange warten müssen. Bitte besprechen Sie solche Werte immer mit Ihrem Architekten.
Ein näherer Blick auf die Einstellungen zeigt: Unsere Skalierungsrichtlinie überprüft die durchschnittliche CPU-Auslastung der Instanzen. Eine Skalierung soll ausgelöst werden, wenn eine durchschnittliche CPU-Auslastung von 10 Prozent erreicht wird. Der Warm-up-Wert wird in Sekunden angegeben und bedeutet in unserem Fall, dass das Vorbereiten einer neuen Instanz 60 Sekunden dauert. Solange die Instanzen nur für das Scale-out (Hochskalieren) vorbereitet werden (Warm up) sind sie für AWS noch kein Bestandteil der ASG. Dadurch wird sichergestellt, dass wir nur zusätzliche Instanzen erhalten, die wir wirklich benötigen. Im Falle eines Scale-in (Herunterskalieren) werden Instanzen beendet. Sie zählen zur aktuellen Kapazität. Es ist wichtig zu erwähnen, dass eine Scale-in-Aktivität nicht gestartet werden kann, während eine Scale-Out-Aktivität ausgeführt wird.
Abbildung 10: Gewünschtes Setup mit zwei EC2-Instanzen
Das Thema Instance Scale-In Protection werden wir hier nicht näher besprechen und wir belassen diesen Punkt unverändert. Im nächsten Fenster könnten wir uns über einen Simple Notification Service informieren lassen, falls bestimmte Ereignisse eintreten sollten, auch das werden wir vorerst überspringen. Der nächste Schritt wäre das Setzen von Tags, aber da wir nur eine Testumgebung haben, ignorieren wir dies ebenfalls. Wir erreichen eine weitere Überprüfungsseite mit unseren Einstellungen. Nachdem wir überprüft haben, ob wir die richtigen Werte eingestellt haben, stehen wir kurz vor dem Ziel: Mit Create an Auto Scaling Group hauchen wir unserer ASG Leben ein.
Wie Abbildung 10 zeigt, haben wir zwei Instanzen in verschiedenen Verfügbarkeitszonen (us-east-1a und us-east-1f), basierend auf unserem Launch Template:
Abbildung 11: 32 vCPU bei nahezu 100 % Auslastung
Für den Stresstest nutzen wir stress-ng. Dieses aktuelle Stress-Tool wird den Server hinsichtlich folgender Parameter belasten:
Stress-ng enthält über 60 verschiedene Stresstests, 50 davon sind CPU-spezifisch. Mit dem Tool werden wir hohe Last auf den Instanzen simulieren – ganz wie auf einer echten SAP-Landschaft. Das Tool lässt sich ganz einfach unter SUSE Linux installieren:
SUSEConnect ist ein Command Line Tool, um ein Client-System an das SUSE Customer Center anzubinden. Nachdem SAP CAL den SUSE Linux Enterprise Server 12 SP 3 verwendet, verbinden wir unsere Instanz mit dem PackageHUB 12.3 für x86_64-Architekturen. Zypper install stress-ng-0.10.14-2.1 installiert das Software-Paket.
In diesem Abschnitt werden wir unsere Instanzen auf Herz und Nieren prüfen. Wie wir wissen, haben wir eine r4.8xlarge-Instanz. Die hat immerhin 32 vCPU unter der Haube. Wir nutzen die volle Kapazität aller vCPUs mit:
stress-ng --cpu 32 --io 2 --vm 1 --vm-bytes 1G - timeout 300s
Der Befehl wird 300 Sekunden lang unter Verwendung von 32 CPU-Stressoren, zwei I/O-Stressoren und einem VM-Stressor mit 1 GB virtuellem Speicher ausgeführt.
Jetzt sind wir gespannt auf die CPU-Auslastung. Denn die Target Tracking Policy beobachtet die durchschnittliche CPU-Auslastung. Wir erwarten sehr hohe Werte. Sehen wir uns das mit dem Befehl mpstat -P ALL 1 an, um Echtzeitwerte zu erhalten.
Abbildung 12: Instanz-Übersicht
Sieht gut aus. Werfen wir einen Blick darauf, wie unsere ASG reagiert:
Abbildung 13: Fünf EC2-Instanzen in fünf AZ
Wie erwartet, versucht die ASG, die CPU-Auslastung auszubalancieren und startet die maximale Anzahl von EC2-Instanzen. In unserem Fall sind das die fünf des Maximalszenarios in den fünf Verfügbarkeitszonen der Region Nord-Virginia (siehe Abbildung 12). Damit hat unsere Infrastruktur das Limit erreicht. Wir können nicht weiter skalieren. Abbildung 13 zeigt die aktiven Instanzen in der EC2-Konsole.
Abbildung 14: SAP Logon – neuer Eintrag
Lassen Sie uns nun mit unserer SAP-Frontend-Instanz testen, ob wir über die SAP-GUI auf den SAP-Anwendungsserver zugreifen können. Wir erstellen einen neuen Eintrag mit der zufällig gewählten asg-3 als Test. Wir können jede beliebige der fünf Instanzen wählen. Bei der SAP-Anmeldung erstellen wir einen neuen Systemeintrag, in dem wir auf die private IP-Adresse des SAP-Backends verweisen. Das SAP-Frontend und das SAP-Backend befinden sich in derselben VPC. Zudem erlaubt die Sicherheitsgruppe es dem SAP-Frontend, mit dem SAP-Backend über Port 3200 zu kommunizieren. Damit können wir die neu erstellte EC2-Instanz auf Basis unseres Launch Templates und unseres benutzerdefinierten Skripts als „User Data“ erreichen. Wir werden, wie zuvor, die Instanznummer 00 und die System-ID A4H verwenden (siehe Abbildung 14).
Abbildung 15: SAP Transaktion OS01 als Beleg
Überprüfen wir nun die IP-Adresse des Anwendungsservers in der SAP-Transaktion OS01 (siehe Abbildung 15). In der Tat ist es so, als ob wir mit asg-3 verbunden wären, einer EC2-Instanz, die durch die ASG auf Basis unserer Startvorlage erstellt wurde. Sie erscheint wie A4H. Aber vielleicht erinnern Sie sich: Der ursprüngliche SAP-Anwendungsserver hatte die IP-Adresse 10.0.2.87 (siehe Teil 2).
Abbildung 16: Scale-in auf dem schnellsten Weg
Wir waren erfolgreich! Aber lassen Sie uns jetzt schnell wieder herunterskalieren. Wir haben ja in Wirklichkeit keine so hohe Last, wir spielen nur rum. Und wir wollen unser Budget nicht komplett aufzehren. Die einfachste Möglichkeit herunterzuskalieren, ist es, die gewünschte, minimale und maximale Kapazität auf 0 zu ändern (siehe Abbildung 16).
Abbildung 17: Beendete Instanzen
Was wir davon erwarten? Abbildung 17 beantwortet das: Alle Instanzen wurden sofort beendet.
Mal sehen, wie weit wir in diesem Teil gekommen sind. Ich denke, dieser Post war das Herzstück unserer Serie. Wir haben eine Startvorlage erstellt und eine Auto Scaling Group (ASG) mit Vorgaben für die Skalierung. Diese kümmert sich um die dynamische Skalierung basierend auf der durchschnittlichen CPU-Auslastung. Im nächsten Schritt haben wir unsere Instanzen gestresst, indem wir nahezu 100 Prozent aller 32 vCPUs ausgelastet haben. Diese extreme Arbeitslast ließ die ASG „anspringen“: Sie startete die maximale Anzahl von Instanzen, um die Arbeitslast auf mehrere Schultern zu verteilen. Als die Auslastung wieder normal war, skalierte die automatische Skalierungsgruppe herunter und beendete drei der maximal fünf Instanzen, um die voreingestellte gewünschte Kapazität von zwei Instanzen zu erreichen. Am Ende der Demonstration haben wir alle Einstellungen der ASG für die Instanzen auf null gesetzt. Dies ist eine Art „Suspend“. Aber wir haben die Gruppe nicht gelöscht, da wir sie in Teil 4 für das Load Balancing noch benötigen.
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.
„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 vierten Teil werden wir uns das Load Balancing näher anschauen. Momentan haben wir fünf Instanzen, aber wir werden sehen, dass wir dafür keine fünf Einträge in das SAP Logon brauchen. Stattdessen geben wir dort nur den Namen der Fully Qualified Domain (FQDN) an – und das funktioniert ganz prima.
