Ich höre dich.
Und willkommen zurück.
Im heutigen Video geht es um die klebrigen Sitzungen.
Bevor wir uns nun mit diesem Thema befassen, wollen wir uns eine typische Herausforderung ansehen.
In der Regel wird in einem Load Balancer-basierten Setup der Datenverkehr von den Benutzern auf mehrere Backend-Server
verteilt.
Nehmen wir zum Beispiel an, dass die erste Anfrage eines Benutzers an den ersten Server geht.
Die zweite Anfrage, die er stellt, könnte an den zweiten Server gehen und so weiter.
Der Verkehr wird also verteilt.
Das Gleiche gilt auch für den Benutzer.
Das Gleiche gilt für den Benutzer.
Drittens.
Wenn nun eine nachfolgende Anfrage an einen anderen Server weitergeleitet wird, geht auch die Sitzungsinformation
verloren.
Nehmen wir zum Beispiel an, Sie gehen zu einer Bank.
Sie haben einige Probleme.
Sie sind zur Bank gegangen und haben das ganze Problem einer Person erklärt, einer Person von heute.
A hat Sie gebeten, morgen zu kommen, damit eine geeignete Lösung angewendet werden kann.
Nun, Sie sind morgen hingegangen und die Person war nicht da.
Was ist also passiert?
Sie sind jetzt zu einer Person gegangen.
B, jetzt weiß Person B nicht wirklich über Ihr Problem Bescheid.
Auch hier müssen Sie also Person B das gesamte Problem erklären. Genau das passiert also auch in der Load
Balancer-basierten Einrichtung.
Bei statischen Websites stellt dies im Allgemeinen kein großes Problem dar, da eine Website statisch ist.
Beide Server haben den gleichen Satz von Seiten für die dynamischen Websites.
Das wird wirklich ein Problem.
Eine Möglichkeit, dieses Problem zu lösen, ist die Sticky Session.
Sticky Session bezieht sich also auf eine Funktion vieler Load Balancer, die die Anfrage für eine bestimmte Sitzung an denselben physischen
Rechner weiterleitet, der die erste Anfrage dieser Sitzung bedient hat.
Die erste Anfrage eines Benutzers ging also an den Server.
Nun folgen Antrag auf Antrag drei Anträge für alle Anträge, die er stellen wird.
Alle diese Anfragen werden an den Server selbst weitergeleitet.
Nehmen wir noch einmal das Beispiel einer Bank: Sie sind am ersten Tag hingegangen, haben sich am zweiten Tag mit Person A
getroffen, am dritten Tag wieder mit Person A. Sie treffen also dieselbe Person in der Bank, und sie weiß über alle Ihre
aktuellen Probleme und auch über alle Ihre früheren Probleme Bescheid.
So kann er Ihnen viel effizienter helfen.
An dieser Stelle kommt also auch die klebrige Sitzung ins Spiel.
Sticky Sessions werden nun auch auf der Seite des Lastausgleichs unterstützt.
Lassen Sie uns also zunächst über den Application Load Balancer sprechen.
Standardmäßig gleicht die Anwendung also jede Anfrage unabhängig an ein registriertes Ziel auf der Grundlage eines
gewählten Lastausgleichsalgorithmus aus.
Ähnlich wie auf der ersten Folie, wo die Anfrage zuerst an Server eins, dann
an Server zwei und so weiter geht.
Bei Bedarf können Sie jedoch auch eine Sticky-Session-Funktion nutzen, die es dem Load Balancer ermöglicht,
die Sitzung eines Benutzers an ein bestimmtes Ziel zu binden.
Wenn Sie nun sehen, dass Sie einen Webbrowser haben, einen Webbrowser, zwei Webbrowser, einer stellt eine Anfrage, einer oder
zwei sind drei an den Load Balancer, der Load Balancer wird sie weiterleiten.
Alle Anträge sind ein oder zwei sind drei an dieselbe EC-2-Instanz.
Diese Einstellung gilt nun, nachdem die Sticky Session aktiviert wurde.
Andernfalls könnte der Load Balancer die Anfrage r eins nach e leiten.
c2122e.
c2232, e, c23 und so weiter.
Lassen Sie uns also eine Sache tun.
Gehen wir der Sache auf den Grund.
Für das heutige Setup habe ich zwei Load Balancer zur Verfügung.
Der eine ist der Application Load Balancer und der zweite ist der klassische Load Balancer, und wir werden uns ansehen,
wie wir hier Sticky Sessions aktivieren können.
Lassen Sie uns zunächst den Application Load Balancer untersuchen.
Zu diesem Zeitpunkt haben Sie noch nicht wirklich eine klebrige Sitzung aktiviert.
Machen wir weiter und kopieren dies nach oben.
Bevor wir uns damit befassen, möchte ich Ihnen auch die Instanzen zeigen.
Es gibt also zwei EC, zwei Instanzen, auf denen Engine X und der Load Balancer laufen, sowohl die klassische als
auch die Anwendung sind mit diesen beiden C-Instanzen verbunden.
Lassen Sie mich also fortfahren und die URL des Application Load Balancer einfügen.
Zuerst ging es zur EC zwei Instanz, Nummer zwei, die eine Seite Klasse Website zu hat.
Wenn ich die Seite aktualisiere, wird die Website angezeigt, die leicht zu finden ist.
Lassen Sie uns eine Pause einlegen.
Jetzt ging es zur Website zwei.
Es handelt sich also um einen klassischen Zustand des Lastausgleichs, bei dem mehrere Anfragen an verschiedene Server weitergeleitet werden.
Nehmen wir nun an, dass wir das nicht wirklich wollen.
Was wir also tun können, ist die Aktivierung von sticky sessions.
Bevor wir jedoch Sticky Sessions aktivieren.
Ich möchte Ihnen die genauen Antwort-Header von HTTP zeigen.
Dies sind also alle Antwort-Header.
Jetzt notieren wir uns das und schauen uns die Antwort-Header an, nachdem die Sticky Session aktiviert
wurde.
Gehen wir nun innerhalb des Load Balancers, speziell für den Application Load Balancer, zu der Zielgruppe,
die mit unserem ALB verbunden ist.
Es gibt nur eine Zielgruppe, die damit verbunden ist.
Bearbeiten Sie nun die Attribute der Zielgruppe, und Sie haben die Möglichkeit, die Klebrigkeit einzustellen.
Ermöglichen wir Klebrigkeit.
Und jetzt wird nach der Klebedauer gefragt, die zwischen einer Sekunde und sieben Tagen liegen kann.
Sie können die Dinge auch entsprechend auswählen.
Ich würde sagen, die Klebrigkeit eines Tages.
Ich werde also fortfahren und die Änderung speichern.
Da wir nun Sticky Sessions haben, wird die Anfrage nur für die Dauer der Sticky Session an eine bestimmte
EC Two Instanz weitergeleitet.
Lassen Sie uns das näher untersuchen.
Lassen Sie mich also die Seite aktualisieren.
Es wird eine zweite Website geben.
Lassen Sie uns noch einmal auffrischen.
Nochmals, Website zwei, aktualisieren wir zum dritten Mal die Website zwei, zum vierten Mal die Website zwei und zum fünften Mal die
Website zwei.
Das ist es also, was uns die Sticky Sessions ermöglichen.
Lassen Sie uns nun in ähnlicher Weise erneut einen Anruf anfordern.
Und jetzt sehen Sie in die Antwort-Header zwischen dem ersten und dem zweiten.
Eines der zusätzlichen Dinge, die hinzugefügt werden, ist ein Cookie.
Der Name des Cookies ist ein Pluszeichen AILBHE, und dann haben Sie die Cookie-bezogenen Informationen.
Wenn Sie also die Sticky Sessions aktivieren, müssen Sie auch ein Cookie hinzufügen.
Ein Cookie ist etwas, das Ihr Webbrowser an den Load Balancer zurücksendet.
Der Load Balancer liest das Cookie aus und erkennt, dass dieser Benutzer an die EC Two Instance One weitergeleitet wurde.
Sobald das Cookie also wieder ausgelesen wird, leitet es den Nutzer selbst zur zweiten EC-Instanz weiter.
Auf diese Weise weiß der Load Balancer, dass ein bestimmter Client an ein bestimmtes Server-Grid weitergeleitet werden
muss.
Beim Application Load Balancer können Sie die Sticky Session auf Zielgruppenebene
einstellen.
Für den klassischen Load Balancer können Sie jedoch weitermachen.
Und aktivieren Sie die Klebrigkeit.
Daher ist die Klebrigkeit derzeit deaktiviert.
Sie können die Klebrigkeit hier selbst aktivieren.
Ähnlich wie beim Anwendungs-Load-Balancer können Sie die Verfallszeit angeben.
Lassen Sie uns also den Arbeitsablauf schnell überarbeiten.
Wenn also ein Kunde eine Anfrage an den Load Balancer stellt, erstellt der Load Balancer ein Cookie.
In diesem Fall ist das Ziel des Cookies also gleich EC zwei eins.
Die Anfrage wird also an den EC zwei gerichtet, und das Cookie wird an den Kunden zurückgeschickt.
Wenn der Client nun die nächste Anfrage an den Load Balancer stellt, muss er das Cookie senden, das
ihm vom Load Balancer gesendet wurde.
Nachdem der Client das Cookie an den Load Balancer zurückgeschickt hat.
Der Load Balancer kann erkennen, dass dieses Cookie mit der EC zwei verbunden war, und die zweite Anfrage
wird ebenfalls an die EC gesendet.
Zwei eins.
Ob das Cookie wirklich nicht mehr gesendet wird, hängt von dem verwendeten Algorithmus ab.
Wenn das Cookie nicht wirklich gesendet wird, kann es sein, dass der Elastic Load Balancer dies nicht weiß und die Anfrage
auch an die EC-2-Instanz weiterleitet.
Dies ist also der Arbeitsablauf auf einer der Arten, wie die Sticky Sessions eingerichtet werden.
Schauen wir uns nun kurz die Vorteile von sticky sessions an.
Erstens müssen die Server bei der Verwendung von Sticky Sessions nicht unbedingt die Sitzungsdaten
austauschen, was den Datentransfer minimieren kann.
Andernfalls müssen Sitzungsdaten zwischen allen Servern ausgetauscht werden, damit sie sich daran erinnern können,
wozu der Benutzer gekommen ist.
Zweitens können Sticky Sessions eine bessere Nutzung des RAM-Caches ermöglichen, was zu einer besseren Reaktionsfähigkeit führen kann.
Lassen Sie uns nun auch einige der Nachteile betrachten.
Erstens kann bei Sticky Sessions der allgemeine Lastausgleich des Datenverkehrs zwischen Servern beeinträchtigt
werden.
Sehr wichtig.
Teil zwei Denken Sie daran, dass ein bestimmter Server überlastet sein kann, wenn sich zu viele Sitzungen ansammeln
oder wenn bestimmte sticky sessions eine hohe Anzahl von Ressourcen benötigen.
Wenn also zehn Nutzer auf die EC2-Instanz verwiesen werden, wird eine, sagen wir, sticky session für drei Tage
Dauer aktiviert.
Wenn jedoch alle zehn Server an die EC-2-Instanz eins gerichtet sind, ist die EC-2-Instanz
zwei völlig leer.
Es gibt keine Sitzungen oder es gibt überhaupt keine Verbindungen.
Was wird nun geschehen?
Die EC zwei Instanz eins ist überlastet, weil alle Benutzer, die das vorhandene Cookie hatten, zur EC zwei Instanz
eins geleitet werden.
Dies kann also ein Nachteil von sticky sessions sein.
Großartig.
Dies ist also ein sehr umfassender Überblick über die Grundlagen von Sticky Sessions und damit wird das heutige Video
abgeschlossen.