Konfigurieren des Layer-7-Content-Switchings

NetScaler Application Delivery Management (ADM) orchestriert mit OpenStack die Konfiguration der Layer-7 (L7)-Switching- oder inhaltsbasierten Switching-Funktionalitäten auf NetScaler-Instanzen. Content-Switching unterscheidet sich vom einfachen Lastausgleich dadurch, dass spezifische Anfragetypen an bestimmte Server geleitet werden können. Wenn die L7-Konfigurationen in OpenStack mit einer NetScaler-Instanz als Anbieter erstellt werden, weist NetScaler ADM eine NetScaler-Instanz zu und implementiert Content-Switching- und Responder-Konfigurationen, die den L7-Konfigurationen entsprechen. Die NetScaler-Instanzen können dann Benutzeranfragen auf der Grundlage von Anwendungsschichtmerkmalen der Anfragen verteilen und den Lastausgleich durchführen.

Die OpenStack Layer 7 (L7) Lastausgleichsfunktion kombiniert Lastausgleich und Content-Switching, um eine optimierte Bereitstellung spezifischer Inhaltstypen zu ermöglichen. Dies verbessert die Leistung des Lastausgleichs, indem nur die Richtlinien ausgeführt werden, die für den Inhalt relevant sind. Der Layer-7-Lastausgleich erleichtert auch die Steigerung der Effizienz der Anwendungsinfrastruktur. Die Möglichkeit, Inhalte nach Typ, URI oder Daten zu trennen, ermöglicht eine bessere Zuweisung physischer Ressourcen in der Anwendungsinfrastruktur. Zum Beispiel wird ein Endbenutzer, der http://example-sports.com/about-us aufruft, von einem Pool von Servern bedient, die Inhalte über das Unternehmen und die Dienstleistungen hosten, während ein Benutzer, der http://example-sports.com/shopping-cart-football aufruft, von einem anderen Pool von Servern bedient wird, der es den Benutzern ermöglicht, Online-Einkäufe zu tätigen.

Beim L7-Switching wird ein Lastausgleich als Content-Switching-Virtual-Server implementiert, der HTTP-Anfragen von Benutzern annimmt und diese Anfragen an die Anwendungsserver verteilt. L7-Switching oder Content-Switching ermöglicht einen einzigen Zugangspunkt, um eine Vielzahl von Backend-Diensten zu nutzen (z. B. nicht nur Webanwendungen, Webdienstportale, Webmails, sondern auch mobiles Management, Inhalte in verschiedenen Sprachen usw.). Das heißt, Sie können eine öffentliche IP-Adresse für alle Dienste bereitstellen, die Sie Ihren Benutzern anbieten.

Im Gegensatz zum Lastausgleich auf niedrigerer Ebene erfordert Layer-7-Switching nicht, dass alle Server im Pool denselben Inhalt haben. Eine Lastausgleichskonfiguration, die L7-Switching verwendet, erwartet, dass die Anwendungs- oder Backend-Server aus verschiedenen Pools unterschiedliche Inhalte haben. L7-Switches können Anfragen basierend auf URI, Host, HTTP-Headern oder allem anderen in der Anwendungsnachricht weiterleiten. Die Anwendungsserver dienen im Wesentlichen spezifischen Inhaltstypen. Zum Beispiel kann ein Server nur Bilder bereitstellen, ein anderer könnte serverseitige Skriptsprachen wie PHP und ASP ausführen, und ein weiterer kann statische Inhalte wie HTML, CSS und JavaScript bereitstellen.

L7-Regeln

Die folgenden Attribute werden in einer Regel zur Auswertung des Datenverkehrs definiert und mit den in der Regel definierten Werten verglichen:

• Host-Name: Der Host-Name in der HTTP-Anfrage wird mit dem Wertparameter in der Regel verglichen. Zum Beispiel „www.example-sports.com“.

• Pfad: Der Pfadteil des HTTP-URI wird mit dem Wertparameter in der Regel verglichen. Zum Beispiel „www.example-sports.com/shopping-cart/football_pump.html“.

• Dateityp: Der letzte Teil des URI wird mit dem Wertparameter in der Regel verglichen. Zum Beispiel txt, html, jpg, PNG, xls und andere.

• Header: Der im Schlüsselparameter definierte Header wird mit dem Wertparameter in der Regel verglichen.

• Cookie: Das durch den Schlüsselparameter benannte Cookie wird mit dem Wertparameter in der Regel verglichen. Der Wert des Cookie-Anfrage-Header-Feldes enthält ein Name-Wert-Paar von Informationen, die für diese URL gespeichert sind; die allgemeine Syntax ist wie folgt: Cookie: name=value. Zum Beispiel würde eine Regel, die nach einem Cookie namens „stores“ mit einem Wert sucht, der mit „football-“ beginnt, so aussehen: type = Cookie, compare_type=StartsWith, key = stores value = football-.

Vergleichstypen

Bei der Auswertung des Datenverkehrs vergleicht die L7-Richtlinie die folgenden Ausdrücke mit den in der Regel definierten Attributen.

• regex: Perl-Typ regulärer Ausdrucksabgleich

• starts_with: Zeichenfolge beginnt mit

• ends_with: Zeichenfolge endet mit

• contains: Zeichenfolge enthält

• equal_to: Zeichenfolge ist gleich

Hinweis

Die Attribute Host-Name, Pfad, Header und Cookie unterstützen alle Vergleichstypen, aber das Attribut Dateityp unterstützt nur Regex und Equal_to.

L7-Richtlinien

Eine L7-Richtlinie verarbeitet den eingehenden HTTP-Verkehr und gibt einen „true“-Wert zurück, wenn alle in der Richtlinie definierten Regeln übereinstimmen.

In jeder L7-Richtlinie sind alle Regeln logisch mit einem UND-Operator verknüpft. Eine Anfrage muss alle Regeln erfüllen, damit die Richtlinie einen „true“-Wert zurückgibt. Die vom Lastausgleich vorgenommene Aktion basiert auf dem von der Richtlinie zurückgegebenen Wert. Sie können eine zweite Richtlinie mit derselben Aktion erstellen, um eine logische ODER-Operation zwischen den Regeln zu erreichen.

Sie können beispielsweise eine Richtlinie erstellen, bei der die eingehende HTTP-Anfrage die Wörter „EXAMPLE-SPORTS“, „SPORTS-FOOTBALL“ oder „EXAMPLE-FOOTBALL“ enthalten kann, sodass der Lastausgleich die entsprechende Aktion des Weiterleitens dieser Anfragen an den Serverpool des E-Commerce-Unternehmens Example-sports vornimmt, um den angeforderten Inhalt bereitzustellen. Sie können eine weitere Richtlinie erstellen, die dieselbe Aktion ausführt, aber „example-sports“, „example-sports-football“ oder „example-football“ abgleicht. Wenn ein Benutzer eine HTTP-Anfrage mit einem dieser sechs Schlüsselwörter sendet, leitet der Lastausgleich die Anfrage an den Example-Sports-Server weiter.

Abhängig von den in der Richtlinie definierten Regeln kann eine L7-Richtlinie eine der folgenden Aktionen ausführen:

• Umleiten an Pool – Leitet die Anfrage an den Anwendungsserverpool weiter, der durch die mit der L7-Richtlinie verbundenen Regeln identifiziert wird. Das heißt, Sie können eine Anwendungsregel erstellen, um Anfragen basierend auf dem Domänennamen an einen bestimmten Lastausgleichspool zu leiten. Sie können beispielsweise eine Regel erstellen, die einige Anfragen an example-football.com an pool_1 und andere Anfragen an example-sports-online_purchase.com an pool_2 leitet.

• Umleiten an URL – Sendet dem Client eine HTTP-Umleitungsantwort, bei der der Location-Antwort-Header den neuen Speicherort enthält. Der Browser aktualisiert die Adressleiste mit dem neuen Speicherort und sendet eine neue Anfrage. Die Anwendungsfälle sind vielfältig. Wenn sich beispielsweise eine Website-Adresse geändert hat, können Sie Anfragen an die neue Adresse umleiten, anstatt sie zu verwerfen. Oder während der Website-Wartung können Sie die Benutzer auf eine schreibgeschützte Website umleiten.

• Ablehnen – Lehnt die Anfrage ab und führt keine weiteren Aktionen aus. Sie können beispielsweise eine 401 Unauthorized-Antwort zurückgeben, um Benutzern den Zugriff auf eingeschränkte Webseiten zu verweigern.

Eine Content-Switching-Konfiguration besteht aus einem Content-Switching-Virtual-Server, einem Lastausgleichs-Setup, das aus Lastausgleichs-Virtual-Servern und -Diensten besteht, sowie Content-Switching-Richtlinien. Nachdem Sie Ihren Content-Switching-Virtual-Server und Ihre Richtlinien erstellt haben, binden Sie jede Richtlinie an den Content-Switching-Virtual-Server. Beim Binden der Richtlinie an den Content-Switching-Virtual-Server geben Sie den Ziel-Lastausgleichs-Virtual-Server an. Wenn eine Anfrage den Content-Switching-Virtual-Server erreicht, wendet der Virtual-Server die zugehörigen Content-Switching-Richtlinien auf diese Anfrage an. Die Priorität der Richtlinie definiert die Reihenfolge, in der die an den Content-Switching-Virtual-Server gebundenen Richtlinien ausgewertet werden.

Jeder Pool, der die Listener-ID besitzt, kann als Standardpool von virtuellen Servern zugewiesen werden, an die der Datenverkehr umgeleitet wird. Der Pool ist lose an einen Listener gebunden und wird nur durch die Implementierung einer L7-Richtlinie mit einem Listener verknüpft. Ein Pool kann auch direkt unter einem Lastausgleich erstellt werden, ohne notwendigerweise an einen Listener gebunden zu sein. In einem solchen Fall wird der Pool im Status „pending_create“ erstellt. Da die L7-Richtlinien eng an die Listener gebunden sind, muss eine L7-Richtlinie, die die Pool-ID enthält, erstellt und implementiert werden, damit der Pool „aktiv“ wird und Anfragen empfängt.

Ein Pool kann von mehreren L7-Richtlinien bedient werden, bleibt aber im Status „aktiv“, wenn mindestens eine Richtlinie daran angehängt ist. Wenn die letzte Richtlinie entfernt wird, kehrt der Pool in den Status „pending_create“ zurück, bis eine weitere Richtlinie erstellt und damit verknüpft wird. Wenn der Pool selbst entfernt wird, werden alle HTTP-Anfragen, die er sonst erhalten hätte, an den Standardpool umgeleitet.

Zuordnung zwischen OpenStack L7-Richtlinien und NetScaler-Entitäten

Wenn die Aktion einer L7-Richtlinie, die zu „true“ ausgewertet wird, den Datenverkehr an einen Pool umleitet, der sich im Status „create_pending“ befindet, implementiert NetScaler ADM den angegebenen Pool zusammen mit einem Lastausgleichs-Virtual-Server. NetScaler ADM erstellt eine Content-Switching-Richtlinie aus der L7-Richtlinie und verwendet die entsprechende Content-Switching-Aktion, um die Anfragen an den mit diesem Pool verbundenen Lastausgleichs-Virtual-Server umzuleiten. Wenn eine zweite L7-Richtlinie an denselben Pool umleitet, erstellt NetScaler ADM eine Content-Switching-Richtlinie und eine Content-Switching-Aktion, um den Datenverkehr an den vorhandenen Lastausgleichs-Virtual-Server umzuleiten, der mit dem Pool verbunden ist.

Richtlinienpositionierung

Die Auswertung von L7-Richtlinien in OpenStack wird durch ihre Prioritäten bestimmt. In OpenStack werden die Richtlinien standardmäßig in der Reihenfolge ihrer Erstellung Prioritäten zugewiesen. Die zuerst erstellte Richtlinie erhält die Nummer „1“, und anschließend erstellte Richtlinien werden fortlaufend nummeriert. Sie können jedoch die Prioritäten der Richtlinien ändern und ihnen unterschiedliche Prioritäten zuweisen. Die Richtlinien werden immer in der Reihenfolge ihrer Prioritäten ausgewertet. Die erste Richtlinie, die einer bestimmten Anfrage entspricht, wird immer zuerst ausgeführt.

Beachten Sie beim Erstellen von Richtlinien die folgenden Punkte:

• Wenn Sie einer neuen Richtlinie dieselbe Priorität wie einer vorhandenen Richtlinie zuweisen, übernimmt die neue Richtlinie diese Priorität. Die Priorität der vorhandenen Richtlinie wird gesenkt. Falls erforderlich, werden auch die Prioritäten anderer Richtlinien gesenkt, um die Reihenfolge der Richtlinienauswertung beizubehalten.

• Wenn Sie eine neue Richtlinie erstellen, ohne eine Position anzugeben, wird die neue Richtlinie einfach an die Liste angehängt.

• Wenn Sie eine neue Richtlinie erstellen und ihr eine Position zuweisen, die größer ist als die Anzahl der bereits in der Liste vorhandenen Richtlinien, wird die neue Richtlinie an die Liste angehängt, d. h., die neue Richtlinie nimmt immer die nächste verfügbare Priorität ein. Wenn es beispielsweise drei Richtlinien A, B und C mit den Prioritäten 1, 2 und 3 gibt und Sie eine Richtlinie erstellen und ihr eine Priorität von 8 zuweisen, wird die Priorität der neuen Richtlinie 4.

• Wenn Sie eine Richtlinie zur Liste hinzufügen oder eine Richtlinie aus der Liste löschen, werden die Positionswerte der Richtlinien ab 1 neu geordnet, ohne Zahlen zu überspringen. Wenn beispielsweise die Richtlinien A, B, C und D die Positionswerte 1, 2, 3 und 4 haben und Sie Richtlinie B aus der Liste löschen, nimmt Richtlinie C nun die zweite Position und Richtlinie D die dritte Position ein.

In NetScaler ADM ist immer eine Standardrichtlinie mit einem csvserver mit einer Priorität von 1 verknüpft. Diese Standardrichtlinie gibt die Anzahl der TCP-Verbindungen an, die ein lbvserver zu einem bestimmten Zeitpunkt verarbeitet. Wenn daher die entsprechenden Responder-Richtlinien und Content-Switching-Richtlinien in NetScaler erstellt werden, wird ihnen immer eine Priorität zugewiesen, die um 1 höher ist als die Priorität der entsprechenden L7-Richtlinie. Wenn beispielsweise eine L7-Richtlinie mit einer Priorität von 1 ausgewertet wird, wird eine Content-Switching-Richtlinie mit einer Priorität von 2 erstellt. Ähnlich wird, wenn eine L7-Richtlinie mit einer Priorität von 2 ausgewertet wird, eine Responder-Richtlinie mit einer Priorität von 3 erstellt.

In OpenStack wird zuerst die Richtlinie „reject“ oder „redirect_to_url“ ausgewertet und dann die Richtlinie „redirect_to_pool“. In einer NetScaler-Instanz werden die Responder-Richtlinien immer zuerst ausgewertet, um entweder die Anfrage zu verwerfen oder dem Benutzer eine umgeleitete Webadresse zu präsentieren, und die Content-Switching-Richtlinien werden zuletzt ausgewertet. Diese Auswertungsreihenfolge führt normalerweise zu keinem Konflikt, wenn die Content-Switching- und Responder-Richtlinien sich gegenseitig ausschließen. Das heißt, zwei L7-Richtlinien dürfen keine identischen Ausdrücke haben. Die abgeleiteten Ausdrücke werden in den Responder- und Content-Switching-Richtlinien hinzugefügt, um solche Konflikte zu vermeiden. Schreiben Sie beispielsweise einen Ausdruck, um alle Anfragen an „sports-football.com“ abzulehnen, und einen weiteren Ausdruck, um Anfragen an „example-sports-football.com“ zuzulassen. Erstellen Sie die L7-Richtlinien so, dass alle Responder-Richtlinien zum Ablehnen der Anfrage oben in der Auswertungsliste angeordnet sind, gefolgt von den Responder-Richtlinien für die direkte Web-Umleitung, gefolgt von den Content-Switching-Richtlinien.

In NetScaler ADM ist immer eine Standardrichtlinie mit einem csvserver mit einer Priorität von 1 verknüpft. Diese Standardrichtlinie gibt die Anzahl der TCP-Verbindungen an, die ein lbvserver zu einem bestimmten Zeitpunkt verarbeitet. Wenn daher die entsprechenden Responder-Richtlinien und Content-Switching-Richtlinien in NetScaler erstellt werden, wird ihnen immer eine Priorität zugewiesen, die um 1 höher ist als die Priorität der entsprechenden L7-Richtlinie. Wenn beispielsweise eine L7-Richtlinie mit einer Priorität von 1 ausgewertet wird, wird eine Content-Switching-Richtlinie mit einer Priorität von 2 erstellt. Ähnlich wird, wenn eine L7-Richtlinie mit einer Priorität von 2 ausgewertet wird, eine Responder-Richtlinie mit einer Priorität von 3 erstellt.

In OpenStack wird zuerst die Richtlinie „reject“ oder „redirect_to_url“ ausgewertet und dann die Richtlinie „redirect_to_pool“. In NetScaler werden die Responder-Richtlinien immer zuerst ausgewertet, um entweder die Anfrage zu verwerfen oder dem Benutzer eine umgeleitete Webadresse zu präsentieren, und die Content-Switching-Richtlinien werden zuletzt ausgewertet. Diese Auswertungsreihenfolge führt normalerweise zu keinem Konflikt, wenn die Content-Switching- und Responder-Richtlinien sich gegenseitig ausschließen. Das heißt, keine zwei L7-Richtlinien haben ähnliche Ausdrücke. Ähnliche abgeleitete Ausdrücke werden in den Responder- und Content-Switching-Richtlinien hinzugefügt, um solche Konflikte zu vermeiden. Schreiben Sie beispielsweise einen Ausdruck, um alle Anfragen an „sports-football.com“ abzulehnen, und einen weiteren Ausdruck, um Anfragen an „example-sports-football.com“ zuzulassen. Erstellen Sie die L7-Richtlinien so, dass alle Responder-Richtlinien zum Ablehnen der Anfrage oben in der Auswertungsliste angeordnet sind, gefolgt von den Responder-Richtlinien für die direkte Web-Umleitung, gefolgt von den Content-Switching-Richtlinien.

Konfigurationsaufgaben

Die Implementierung von L7-Richtlinien und -Aktionen erfolgt über Neutron LBaaS-Befehle.

Legen Sie die Umgebungsvariablen in OpenStack fest und erstellen Sie den Lastausgleich (z. B. LB1). Nachdem der Lastausgleich erfolgreich erstellt wurde, erstellen Sie den Listener und die Pools (z. B. L1, P1 und P2) und fügen Sie den Pools Mitglieder und Monitore hinzu. Zum Beispiel ist P1 der Standardpool für L1, während P2 der an LB1 gebundene Pool ist, der die Anwendungsserver verwaltet.

Weitere Informationen zur Konfiguration von LBaaS V2 über die Befehlszeile finden Sie unter Konfigurieren von LBaaS V2 über die Befehlszeile.

Die folgenden Befehle erstellen die Richtlinien und definieren die spezifischen Aktionen:

Erstellen einer L7-Richtlinie zum Verwerfen von Anfragen

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action<action-name>

Beispiel:

neutron lbaas-l7policy-create –name policy11 –action REJECT –listener L1

Der obige Befehl erstellt und bindet policy11, eine Responder-Richtlinie, an den Content-Switching-Server, um Anfragen abzulehnen. Da für diese Richtlinie keine Regel erstellt wurde, wird die Richtlinie zu „false“ ausgewertet und die Anfrage abgelehnt.

Erstellen einer L7-Richtlinie zum Umleiten von Anfragen an eine bestimmte URL

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action <action-name> --redirect-url <redirect-url>

Beispiel:

neutron lbaas-l7policy-create –name policy12 –action REDIRECT_TO_URL –listener admin-list1 –redirect-url http://example-sports/about-us.html

Der obige Befehl erstellt eine Responder-Aktion zum Umleiten von Anfragen an eine URL, erstellt eine Responder-Richtlinie mit Aktion und bindet diese Richtlinie an den Content-Switching-Virtual-Server.

neutron lbaas-l7rule-create --type HOST_NAME --compare-type CONTAINS --value <value-string> <L7 policy name>

neutron lbaas-l7rule-create --type PATH --compare-type CONTAINS --value <value-string> <L7 policy name>

Die beiden obigen Regeln können mit einem UND-Operator verbunden werden, um den Ausdruck für die Responder-Richtlinie abzuleiten.

Erstellen einer L7-Richtlinie zum Umleiten von Anfragen an einen Pool

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action <action-name> --redirect-pool <redirect-pool>

Beispiel:

neutron lbaas-l7policy-create –name policy13 –action REDIRECT_TO_POOL –listener admin-list1 –redirect-pool admin-pool2

Wenn dies die erste L7-Richtlinie ist, implementiert der obige Befehl P2 zusammen mit LB1, erstellt die Content-Switching-Umleitungsaktion und leitet die Anfragen an LB1 um. Wenn P2 bereits existiert, erstellt der Befehl die Content-Switching-Umleitungsaktion und leitet die Anfragen an LB1 um.