Diese Blogpost-Serie basiert auf einem Proof of Concept, in dem wir demonstrieren, wie einfach es ist, SAP Application Server schnell mit einem Network Load Balancer zu verbinden. Der Letztere wird zudem verknüpft mit einer AWS Auto Scaling Group. Der Vorteil: Damit können wir die Flexibilität der Cloud voll ausschöpfen. 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 werden werden wir uns die Gesamtlösung anschauen.
Abbildung 1: Liste der EC2-Instanzen
Was ist in Teil 4 passiert? Wir haben den Network Load Balancer eingerichtet und eine Target Group entworfen, indem wir den Load Balancer mit einer Auto Scaling Group verbunden haben. Wir haben geprüft, ob wir via DNS-Name des Load Balancers auf unseren SAP-Anwendungsserver zugreifen können. Und es hat gut funktioniert.
Wie in Teil 3 und 4 gezeigt, haben wir unsere automatische Skalierungslösung gestartet, indem wir den gewünschten Wert auf 2, den Minimalwert auf 1 und den Maximalwert auf 5 hoch gesetzt haben. Wir haben zunächst zwei Instanzen gestresst. Wir werden dieses Vorgehen wieder benutzen, es hat beim letzten Mal recht gut funktioniert:
stress-ng --cpu 32 --io 2 --vm 1 --vm-bytes 1G - timeout 300s
Die automatische Skalierungsgruppe reagierte schnell und startete die maximale Anzahl von EC2-Instanzen:
Abbildung 2: Management der Instanzen der Auto Scaling Groups
In der Konsole für die Auto Scaling Groups sieht es ebenfalls gut aus (Abbildung 2).
Abbildung 3: Registrierte Targets
Auch die Situation bei den Target Groups ist ok (Abbildung 3).
Abbildung 4: SAP Transaktion OS01
Nach dem Start von stress-ng auf allen fünf Instanzen leitet der Load Balancer den Datenverkehr zu der ersten „gesunden” virtuellen Instanz, nämlich final-test-1 (Abbildung 4).
Abbildung 5: Final-test-1 Instanz befindet sich im „unhealthy”-Status
Jetzt simulieren wir einen Ausfall der laufenden Instanz. Dazu stoppen wir den SAP NetWeaver Stack auf der entsprechenden Instanz (final-test-1). Kein Wunder, dass sich eine leistungsfähige „gesunde” Instanz innerhalb von Sekunden aufs Krankenlager zurückzieht (Status „unhealthy“, Abbildung 5).
Abbildung 6: Umleitung des Traffic auf eine gesunde Instanz
Der Network Load Balancer zieht die Konsequenzen: Er entscheidet, den Datenverkehr auf eine gesunde Instanz zu verteilen; in unserem Fall final-test-4 in us-east-1e (Abbildung 6) mit einer anderen IP-Adresse.
Abbildung 7: Finale Architektur
Wir können uns zum Abschluss auf die Schulter klopfen: Unsere Lösung läuft! Schauen wir ein letztes Mal darauf zurück, was wir aufgebaut haben.
Abbildung 8: Der schnellste Weg zum Scale-in
Unser Test war erfolgreich. Jetzt skalieren wir ein letztes Mal herunter. Wie auch zuvor, setzen wir die Kapazitäten auf null wie in Abbildung 8 gezeigt.
Wir sind am Ende unserer Blog-Reihe angekommen. Vergessen Sie nicht, die Instanzen in der SAP Cloud Appliance Library (CAL) durch Klicken auf Terminate zu beenden. Beide Instanzen werden dadurch endgültig gelöscht.
Löschen Sie zudem in der AWS-Konsole Folgendes:
Vielen Dank, dass Sie uns auf unserer „SAP on AWS Load Balancing“-Reise begleitet haben. Ich hoffe, unser technischer Trip hat Ihnen gefallen.
