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. In diesem Teil werden wir uns mit dem Network Load Balancer beschäftigen und diesen mit der Auto Scaling Group verknüpfen.
Abbildung 1: Drei Arten von Load Balancern
Was geschah in Teil 3? Wir haben die Auto Scaling Group (ASG) aufgesetzt und waren in der Lage unsere Landschaft auf Basis unserer Vorgaben hochzuskalieren. Ein Stresstest mit stress-ng belegte dies. Schauen wir nun, wie wir einen Network Load Balancer mit unserer ASG kombinieren können.
In Teil 3 dieser Blogserie über die ASG habe ich angekündigt, dass wir zum Load Balancer zurückkehren werden. Und los geht's: Unsere Reise beginnt wieder auf der EC2-Konsole. Auf der linken Seite im Navigationsbereich haben wir den Punkt „Load Balancer“ ausgewählt und auf die blaue Schaltfläche in der Mitte „Create Load Balancer“ geklickt. Hier können wir zwischen drei Arten von Load Balancern wählen: Application Load Balancer, Network Load Balancer und Classic Load Balancer. Der Vorteil davon: Der Application Load Balancer ermöglicht die Verteilung von HTTP- (TCP / Port 80) und HTTPS- (TCP / Port 443) Lasten zwischen Instanzen in einer Target Group. Sie erinnern sich vielleicht, dass wir in unserem Szenario über Port 3200 mit dem SAP-Dispatcher kommunizieren. Der Application Load Balancer nutzt andere Ports – also brauchen wir eine andere Lösung. Wir könnten den Classic Load Balancer verwenden, benötigen jedoch eine Anwendung, die im klassischen EC2-Netzwerk ausgeführt wird. AWS empfiehlt, den Classic Load Balancer nicht zu verwenden, da er etwas veraltet ist. Er sollte für HTTPS-, HTTP- und TCP-Datenverkehr früherer Generationen eingesetzt werden. Die beste Lösung für unseren Fall ist der Network Load Balancer. Wie die kurze Einführung in Abbildung 1 zeigt: Er kann Millionen von Anforderungen pro Sekunde sicher verarbeiten bei extrem niedrigen Latenzen. Das brauchen wir.
Abbildung 2: Einstellungen für das Load Balancing in der ASG
Wie Abbildung 2 zeigt, werden wir zunächst die Einstellungen für das load balancing bei der ASG ändern:
Abbildung 3: Basis-Konfiguration
Wir finden zwei Optionen: Load Balancer Target Groups und Classic Load Balancer. Mit unserem Fokus auf den Network Load Balancer, wählen wir den Target-Group-Eintrag. Beim Erstellen des Network Load Balancers erstellen wir auch die Target Group. Im ersten Schritt definieren wir Name und Schema. Der NLB kann sowohl plattform-intern als auch für Internet-Dienste eingesetzt werden. Wir entscheiden uns für intern, da alle unsere Instanzen innerhalb einer VPC ausgeführt werden. Den Listener definieren wir für TCP auf Port 3200. Dies ist der Port für den SAP-Dispatcher, aber wir können weitere Listener (bis zu 50) für einen Load Balancer hinzufügen. Weitere Informationen zur Einschränkung finden Sie in der offiziellen AWS-Dokumentation.
Abbildung 4: Spezifikation der Target Group
Im nächsten Abschnitt werden wir alle Verfügbarkeitszonen aktivieren, weil wir ja am Ende eine redundante und hochverfügbare Lösung haben wollen.
Abbildung 5: Cross-zone Load Balancing
In diesem Abschnitt definieren wir, an welche Ziele in welcher Target Group unser Load Balancer die Anfragen über TCP an Port 3200 weiterleitet. Darüber hinaus haben wir die Möglichkeit, Einstellungen für den Health Check festzulegen. Letztere lassen wir unverändert.
Unser Ziel ist es, die Last zwischen verschiedenen Verfügbarkeitszonen auszugleichen. Daher müssen wir die Einstellung Cross-Zone Load Balancing aktivieren (siehe Abbildung 5).
Abbildung 6: Definition der Target Group für den Load Balancer
Abschließend müssen wir noch die Target Group für unseren Load Balancer setzen. Wir haben sie im vorigen Post unserer Serie erstellt (sap-test-tg). Also werden wir sie nur einfügen, wie in Abbildung 6 zu sehen.
Abbildung 7: Status-Check der beiden Instanzen
Schauen wir zunächst, ob wir die Instanzen innerhalb der ASG erreichen können. Wir ändern die Kapazitäten wieder auf die des vorigen Posts (gewünscht: 2, Minimum: 1, Maximum: 5) um zu prüfen, ob der Load Balancer die Target Group verwendet. Wir müssen die beiden Instanzen für die gewünschte Kapazität finden, d.h. sie müssen als Targets innerhalb der VPC registriert sein.
Abbildung 8: Neuer Eintrag für den Network Load Balancer
Abbildung 7 zeigt uns unsere zwei gewünschten EC2-Instanzen im Status „healthy“. Für den nächsten Schritt brauchen wir das SAP Logon im SAP Frontend. Wir erzeugen einen neuen Eintrag mit dem DNS-Namen des Network Load Balancers. Diesen Namen finden wir in der Load-Balancer-Konsole (unter dem „Description Tab“ (dort: DNS name)).
Abbildung 9: SAP Transaction OS01 im Vergleicht mit der EC2 console
Wenn wir die SAP transaction OS01 prüfen, sehen wir, dass der Network Load Balancer den Verkehr auf TCP/3200 nun auf nlb-test-1 in der Verfügbarkeitszone us-east-1b leitet (Abbildung 9).
Abbildung 10: Der schnellste Weg zum Scale-in
Einmal mehr Glückwünsche! Unser Load Balancer funktioniert einwandfrei in Zusammenarbeit mit der ASG – die Target Group macht es möglich. Jetzt wollen wir wieder herunterskalieren. Den einfachsten Weg dafür kennen wir bereits: Wir ändern unsere Kapazitätseinträge für die ASG auf null (Abbildung 10).
Lassen Sie uns resümieren, was wir erreicht haben. Ich gIaube, das waren interessante Ergebnisse. Wir haben eine Target Group erstellt auf Basis einer Auto Scaling Group und sie mit einem Network Load Balancer verknüpft. Im SAP Logon haben wir den Load Balancer in das System eingetragen. Das hat uns Zugriff auf die SAP Anwendungsserver verschafft.
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 fünften Teil werden wir uns unsere Gesamtlösung nochmal anschauen. Wir werden die Instanzen einem weiteren Stresstest unterziehen, um zu checken, ob der Load Balancer funktioniert. Damit bekommen wir einen Eindruck aus erster Hand, wie das Skalieren abläuft und welche Instanzen „healthy“ bleiben.
