Produktdokumentation
ADC
14.1 - Current Release 13.1 13.0 12.1
PDF anzeigen

Persistenz-Unterstützung für den virtuellen Server mit Content Switching

August 15, 2023
Beitrag von: 
C

Anwendungen bewegen sich von monolithischen Architekturen hin zu Microservices-Architekturen. Verschiedene Versionen derselben Anwendung können in der Microservices-Architektur koexistieren. Die NetScaler-Appliance muss die kontinuierliche Bereitstellung von Anwendungen unterstützen. Dies wird durch Plattformen erreicht, die Canary-Bereitstellungen durchführen (wie Spinnaker). Bei einer Continuous-Deployment-Setup wird eine neuere Version einer Anwendung automatisch bereitgestellt und schrittweise dem Client-Verkehr ausgesetzt, bis die Anwendung stabil ist und den gesamten Datenverkehr aufnehmen kann. Außerdem müssen unterbrechungsfreie Dienste für den Kunden verfügbar sein.

Die NetScaler Content Switching-Funktion ermöglicht es NetScaler, der Appliance, Client-Anforderungen auf mehrere virtuelle Load-Balancing-Server zu verteilen, basierend auf den Richtlinien, die an den virtuellen Content Switching-Server gebunden sind.

Bei kontinuierlichen Bereitstellungen wird Content Switching verwendet, um den virtuellen Lastausgleichsserver auszuwählen, der verschiedene Versionen einer Anwendung bedient.

Beim Content Switching ändert sich die Auswahl eines virtuellen Lastausgleichsservers für eine bestimmte Anwendungsversion zur Laufzeit aufgrund der Änderung der Inhaltswechselrichtlinien. Wenn während dieser Umstellung einige Sitzungen mit älteren Versionen der Anwendung vorhanden sind, darf dieser Datenverkehr weiterhin nur von älteren Versionen bereitgestellt werden. Um diese Anforderung zu unterstützen, sorgt die NetScaler-Appliance für die Persistenz mehrerer Load Balancing-Gruppen hinter einem virtuellen Content Switching-Server. Der virtuelle Server Persistence for Content Switching ermöglicht den nahtlosen Übergang von Clients von einer Version zur anderen.

Unterstützte Persistenztypen auf virtuellen Content Switching-Servern

Die folgenden Persistenztypen werden auf virtuellen Content Switching-Servern unterstützt.

Persistenzart Beschreibung
Quell-IP QUELLE/IP. Verbindungen von derselben Client-IP-Adresse sind Teil derselben Persistenzsitzung. Weitere Informationen finden Sie unter Persistenz der Quell-IP-Adresse.
HTTP-Cookie COOKIEINSERT. Verbindungen, die denselben HTTP-Cookie-Header haben, sind Teil derselben Persistenzsitzung. Das Format des Cookie, das die NetScaler-Appliance einfügt, ist: NSC_ = wobei NSC_XXXX die virtuelle Server-ID ist, die vom Namen des virtuellen Servers abgeleitet wird. Weitere Informationen finden Sie unter Persistenz von HTTP-Cookies.
SSL-Sitzung ID SSL-SITZUNG. Verbindungen mit derselben SSL-Sitzungs-ID sind Teil derselben Persistenzsitzung. Weitere Informationen finden Sie unter Persistenz der SSL-Sitzungs-ID.

Sie können einen Timeoutwert für Persistenz konfigurieren, der auf HTTP-Cookies basiert. Wenn Sie den Timeout-Wert auf 0 festlegen, gibt die ADC Appliance unabhängig von der verwendeten HTTP-Cookie-Version keine Ablaufzeit an. Die Ablaufzeit hängt dann von der Client-Software ab, und solche Cookies sind nur gültig, wenn die Software läuft.

Abhängig von der Art der Persistenz, die Sie konfiguriert haben, kann der virtuelle Server entweder 250.000 gleichzeitige persistente Verbindungen oder eine beliebige Anzahl persistenter Verbindungen unterstützen, bis die Grenzen liegen, die sich aus der Speichermenge auf Ihrer NetScaler-Appliance ergeben. Die folgende Tabelle zeigt, welche Arten von Persistenz in die einzelnen Kategorien fallen.

Persistenzart Anzahl der unterstützten gleichzeitigen persistenten Verbindungen
Quell-IP, SSL-Sitzungs-ID 250,000
HTTP-Cookie Speicherbegrenzung. Wenn in CookieInsert das Timeout nicht 0 ist, ist die Anzahl der Verbindungen durch den Speicher begrenzt.

Einige Arten der Persistenz sind spezifisch für bestimmte Arten von virtuellen Servern. In der folgenden Tabelle sind die einzelnen Persistenztypen aufgeführt und es wird angegeben, welche Arten von Persistenz auf welchen virtuellen Servertypen unterstützt werden.

Persistenzart HTTP HTTPS TCP UDP/IP SSL_Bridge SSL_TCP RTSP SIP_UDP
SOURCEIP Ja Ja Ja Ja Ja Ja Nein Nein
PLÄTZCHEN EINFÜGEN Ja Ja Nein Nein Nein Nein Nein Nein
SSL-SITZUNG Nein Ja Nein Nein Ja Ja Nein Nein

Unterstützung für Backup-Persistenz

Sie können den virtuellen Content Switching-Server so konfigurieren, dass er den Quell-IP-Persistenztyp als Backup-Persistenztyp verwendet, wenn der Cookie-Persistenztyp ausfällt. Es ist nützlich für Canary-Implementierungen in der Microservices-Architektur. Wenn der Cookie-Persistenztyp fehlschlägt, greift die Appliance nur dann auf die Quell-IP-basierte Persistenz zurück, wenn der Clientbrowser in der Anfrage kein Cookie zurückgibt. Wenn der Browser jedoch ein Cookie zurückgibt (nicht unbedingt das Persistenz-Cookie), wird davon ausgegangen, dass der Browser Cookies unterstützt und daher keine Backup-Persistenz ausgelöst wird. Sie können auch einen Timeout-Wert für die Backup-Persistenz festlegen. Timeout ist der Zeitraum, für den eine Persistenzsitzung aktiv ist.

So funktioniert die Persistenz beim virtuellen Server für Content Switching

Szenario 1: Ein virtueller Content-Switching-Server ohne Persistenz

Das folgende Beispiel veranschaulicht die Bereitstellung mehrerer Versionen einer Anwendung mit einem virtuellen Content Switching-Server ohne Persistenz.

persistence-cs1

Wenn der Client C1 eine Anfrage an die Anwendung sendet, wird die Anforderung an den virtuellen Content Switching-Server in der NetScaler-Appliance gesendet. Der virtuelle Content Switching-Server wertet die Richtlinie aus und leitet die Anfrage an den virtuellen Load-Balancing-Server (LB1) weiter, der Version v1 der Anwendung bereitstellt.

persistence-cs2

Stellen Sie sich vor, dass eine neue Version v2 der Anwendung bereitgestellt wird und einer Untergruppe von Benutzern zugänglich gemacht werden muss. Der neue virtuelle Load-Balancing-Server (LB2), der die v2-Version bereitstellt, ist durch die entsprechende Content Switching-Richtlinie an den virtuellen Content Switching-Server gebunden.

Wenn der Client C1 eine neue Anfrage sendet, wird die Richtlinie erneut ausgewertet und die Anfrage wird an den virtuellen Lastausgleichsserver LB2 weitergeleitet. Daher schlagen die Transaktionen für State-ful-Anwendungen fehl, wenn mehrere Versionen der Anwendung bereitgestellt werden.

Szenario 2: Virtueller Content-Switching-Server mit Persistenz

Das folgende Beispiel veranschaulicht die Bereitstellung mehrerer Versionen der Anwendung mit einem virtuellen Content Switching-Server mit Persistenz.

persistence-cs3

Wenn der Client C1 eine Anfrage an die Anwendung sendet, wird die Anforderung an den virtuellen Content Switching-Server in der NetScaler-Appliance gesendet. Der virtuelle Content Switching-Server wertet die Richtlinie aus, erstellt einen Persistenz-Sitzungseintrag und leitet die Anfrage an den virtuellen Lastausgleichsserver LB1 weiter, der Version v1 der Anwendung bereitstellt.

persistence-cs4

Derselbe Client C1 fordert erneut die Anwendung an, und die Anforderung wird an den virtuellen Content Switching-Server in der NetScaler-Appliance gesendet. Es wird nach der Persistenzsitzung gesucht, und der virtuelle Lastausgleichsserver LB1 wird aus der vorhandenen Persistenzsitzung übernommen und die Anfrage wird an LB1 weitergeleitet. Mit dieser Lösung kommt es zu keiner Unterbrechung der bestehenden Transaktion, sodass der statusmäßige Charakter der Anwendung erhalten bleibt.

persistence-cs5

Betrachten wir einen neuen Kunden C2. Die neue Anforderung C2 wird im Rahmen der Richtlinienauswertung an die neuere Version der Anwendung gesendet, da für diesen Client keine Persistenzsitzung vorhanden ist. Dies führt zu einer erfolgreichen Einführung der neueren Version der Anwendung, ohne deren Statement zu beeinträchtigen.

Aufgrund der Persistenzunterstützung können Kunden mehrere Inhalte oder verschiedene Versionen der Anwendung nahtlos bereitstellen, ohne die bestehenden Transaktionen zu beeinträchtigen, insbesondere bei Stateful-Anwendungen. Ohne Beharrlichkeit im Bild ist das nicht möglich.

Konfigurieren Sie den Persistenztyp auf dem virtuellen Content Switching-Server mithilfe der CLI

Geben Sie an der Eingabeaufforderung Folgendes ein:

set cs vserver <name> -PersistenceType <type> [-timeout <integer>]
<!--NeedCopy-->

Beispiel:

set cs vserver Vserver-CS-1 -persistenceType SOURCEIP -timeout 60
<!--NeedCopy-->

Konfigurieren Sie den Persistenztyp auf dem virtuellen Content Switching-Server mithilfe der GUI

  1. Navigieren Sie zu Traffic Management > Content Switching > Virtuelle Server und klicken Sie auf Hinzufügen.

  2. Konfigurieren Sie in den Grundeinstellungendie Persistenzdetails.

Persistenz-Unterstützung für den virtuellen Server mit Content Switching
August 15, 2023
Beitrag von: 
C
August 15, 2023
Beitrag von: 
C

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.