Layer-7-Content Switchings konfigurieren

NetScaler Application Delivery Management (ADM) koordiniert mit OpenStack die Layer-7- (L7) -Switching- oder Content-Based-Switching-Funktionen auf NetScaler-Instanzen. Content Switching unterscheidet sich vom einfachen Lastausgleich dadurch, dass bestimmte Arten von Anforderungen an bestimmte Server weitergeleitet 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 stellt Content Switching und Responder-Konfigurationen entsprechend den L7-Konfigurationen bereit. Die NetScaler-Instanzen können dann Benutzeranfragen auf der Grundlage der Eigenschaften der Anforderungen auf Anwendungsebene verteilen und den Lastenausgleich vornehmen.

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

Beim L7-Switching wird ein Load Balancer als virtueller Content Switching-Server implementiert, der HTTP-Anforderungen von Benutzern akzeptiert und diese Anforderungen an die Anwendungsserver verteilt. L7-Switching oder Content Switching ermöglicht Ihnen einen zentralen Zugang für den Zugriff auf eine Vielzahl von Back-End-Diensten (z. B. nicht nur auf Webanwendungen, Webservice-Portale, Webmails, sondern auch mobile Verwaltung, Inhalte in verschiedenen Sprachen usw.). Das heißt, Sie können eine öffentliche IP-Adresse für alle Dienste angeben, die Sie Ihren Benutzern anbieten.

Im Gegensatz zum Load Balancing auf niedrigerer Ebene erfordert Layer-7-Switching nicht, dass alle Server im Pool denselben Inhalt haben. Eine Load Balancer-Konfiguration, die L7-Switching verwendet, geht davon aus, dass die Anwendungs- oder Backend-Server aus verschiedenen Pools unterschiedliche Inhalte haben. L7-Switches können Anfragen auf der Grundlage von URI, Host, HTTP-Headern oder irgendetwas anderes in der Anwendungsnachricht richten. Die Anwendungsserver dienen im Wesentlichen bestimmten Arten von Inhalten. Zum Beispiel kann ein Server nur Images bereitstellen, ein anderer kann serverseitige Skriptsprachen wie PHP und ASP ausführen, und ein anderer kann statische Inhalte wie HTML, CSS und JavaScript bereitstellen.

L7 Regeln

Die folgenden Attribute werden in einer Regel für die Auswertung des Datenverkehrs definiert und mit den in der Regel definierten Werten verglichen:

• Hostname: Der Hostname in der HTTP-Anforderung wird mit dem Wertparameter in der Regel verglichen. Zum Beispiel “www.example-sports.com”.

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

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

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

• Cookie: Das nach dem Schlüsselparameter benannte Cookie wird mit dem Wertparameter in der Regel verglichen. Der Wert des Cookie-Anforderungsheader-Felds enthält ein Paar von Informationen aus Namen und Werten, die für diese URL gespeichert sind. Die allgemeine Syntax lautet wie folgt: Cookie: name=value. Beispielsweise sieht eine Regel, die nach einem Cookie namens “stores” mit dem Wert, der mit “football-“ beginnt, wie folgt aus: 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: Übereinstimmung mit regulären Ausdrücken vom Typ Perl

• starts_with: Zeichenfolge beginnt mit

• ends_with: Die Zeichenfolge endet mit

• enthält: Zeichenfolge enthält

• equal_to: Zeichenfolge entspricht

Hinweis

Der Hostname, der Pfad, der Header und die Cookie-Attribute unterstützen alle Vergleichstypen, aber das Attribut file_type unterstützt nur Regex und equal_to.

L7 Richtlinien

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

In jeder L7-Richtlinie werden alle Regeln logisch mit einem AND-Operator verknüpft. Eine Anfrage muss allen Regeln entsprechen, damit die Richtlinie einen „wahren“ Wert zurückgibt. Die vom Load Balancer ergriffenen Maßnahmen basieren 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, in der die eingehende HTTP-Anforderung die Wörter “EXAMPLE-SPORTS”, “SPORTS-FOOTBALL” oder “EXAMPLE-FOOTBALL” enthalten kann, damit der Load Balancer diese Anforderungen an den Server-Pool des Example-Sports weiterleitet. E-Commerce-Unternehmen, um die angeforderten Inhalte zu bedienen. Sie können eine andere Richtlinie erstellen, die dieselbe Aktion ausführt, aber mit “Beispielsportarten”, “Beispielsportfußball” oder “Beispielfußball” übereinstimmt. Wenn ein Benutzer eine HTTP-Anfrage mit einem dieser sechs Schlüsselwörter sendet, leitet der Load Balancer 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:

• An Pool umleiten — Leiten Sie die Anfrage an den Anwendungsserver-Pool weiter, der anhand der mit der L7-Richtlinie verknüpften Regeln identifiziert wird. Das heißt, Sie können eine Anwendungsregel erstellen, um Anfragen entsprechend dem Domainnamen an einen bestimmten Load Balancer-Pool weiterzuleiten. 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 weiterleitet.

• Zur URL weiterleiten — Senden Sie dem Client eine HTTP-Umleitungsantwort, in der der Location-Antwort-Header den neuen Standort enthält. Der Browser aktualisiert die Adressleiste mit dem neuen Standort und stellt eine neue Anfrage. Die Anwendungsfälle sind vielfältig. Wenn sich beispielsweise die Adresse einer Website geändert hat, können Sie Anfragen an die neue Adresse weiterleiten, anstatt sie zu löschen. Oder Sie können die Benutzer während der Wartung der Website auf eine schreibgeschützte Website umleiten.

• Ablehnen - Ablehnt die Anforderung ab und ergreift keine weiteren Maßnahmen. Sie können beispielsweise eine 401 Unautorisierte Antwort zurückgeben, um den Benutzern den Zugriff auf eingeschränkte Webseiten zu verweigern.

Eine Content Switching-Konfiguration besteht aus einem virtuellen Content Switching-Server, einem Load Balancing-Setup, bestehend aus virtuellen Servern und Diensten für den Lastenausgleich und Richtlinien für Content Switching. Nachdem Sie den virtuellen Server und die Richtlinien für Content Switching erstellt haben, binden Sie jede Richtlinie an den virtuellen Content Switching-Server. Wenn Sie die Richtlinie an den virtuellen Server für die Content Switching binden, geben Sie den virtuellen Ziel-Lastausgleichsserver an. Wenn eine Anforderung den virtuellen Content Switching-Server erreicht, wendet der virtuelle Server die zugeordneten Content Switching-Richtlinien auf diese Anforderung an. Die Priorität der Richtlinie definiert die Reihenfolge, in der die an den virtuellen Content Switching-Server gebundenen Richtlinien ausgewertet werden.

Jeder Pool mit der Listener-ID kann als Standardpool virtueller Server zugewiesen werden, an die der Datenverkehr umgeleitet wird. Der Pool ist lose an einen Listener gebunden und wird erst durch die Implementierung einer L7-Richtlinie mit einem Listener verknüpft. Ein Pool kann auch direkt unter einem Load Balancer erstellt werden, ohne dass er unbedingt an einen Listener gebunden ist. In einem solchen Fall wird der Pool im Status „pending_create“ erstellt. Da die L7-Richtlinien eng mit den Listenern verknüpft sind, muss eine L7-Richtlinie mit der Pool-ID erstellt und implementiert werden, damit der Pool „aktiv“ wird und Datenverkehrsanfragen empfängt.

Ein Pool kann von mehreren L7-Richtlinien bedient werden, verbleibt jedoch im Status „aktiv“, wenn ihm mindestens eine Richtlinie zugeordnet ist. Wenn die letzte Richtlinie entfernt wird, wechselt der Pool wieder in den Status „pending_create“, bis eine weitere Richtlinie erstellt und ihr zugeordnet wird. Wenn der Pool selbst entfernt wird, werden alle HTTP-Anfragen, die er sonst empfangen hätte, an den Standardpool umgeleitet.

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

Wenn die Aktion einer L7-Richtlinie, die als „wahr“ ausgewertet wird, den Datenverkehr an einen Pool umleitet, der sich im Status „create_pending“ befindet, implementiert NetScaler ADM den angegebenen Pool zusammen mit einem virtuellen Lastausgleichsserver. NetScaler ADM erstellt eine Content Switching-Richtlinie aus der L7-Richtlinie und verwendet die entsprechende Content Switching-Aktion, um die Anforderungen an den virtuellen Lastausgleichsserver umzuleiten, der diesem Pool zugeordnet ist. Wenn eine zweite L7-Richtlinie an denselben Pool umgeleitet wird, erstellt NetScaler ADM eine Content Switching-Richtlinie und eine Content Switching-Aktion, um den Datenverkehr an den vorhandenen virtuellen Lastausgleichsserver umzuleiten, der dem Pool zugeordnet ist.

Politische Positionierung

Die Bewertung von L7-Richtlinien in OpenStack wird von ihren Prioritäten bestimmt. In OpenStack werden den Richtlinien standardmäßig Prioritäten in der Reihenfolge zugewiesen, in der sie erstellt wurden. Die zuerst erstellte Richtlinie wird mit „1“ nummeriert, und die anschließend erstellten 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 bewertet. 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, erhält die neue Richtlinie diese Priorität. Die Priorität der bestehenden Richtlinie wird herabgesetzt. Falls erforderlich, werden auch die Prioritäten anderer Richtlinien herabgestuft, um die Reihenfolge beizubehalten, in der die Richtlinien bewertet werden.

• 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 Richtlinien, die sich bereits in der Liste befinden, wird die neue Richtlinie an die Liste angehängt, d. h. die neue Richtlinie hat immer die nächste verfügbare Priorität. Wenn es beispielsweise drei Richtlinien A, B und C mit den Prioritäten 1, 2 und 3 gibt und Sie eine Richtlinie erstellen und eine Priorität von 8 zuweisen, wird die Priorität der neuen Richtlinie auf 4 festgelegt.

• Wenn Sie der Liste eine Richtlinie hinzufügen oder eine Richtlinie aus der Liste löschen, werden die Policy-Positionswerte von 1 aus neu angeordnet, ohne Zahlen zu überspringen. Beispiel: Wenn Richtlinie A, B, C und D Positionswerte von 1, 2, 3 und 4 haben und wenn Sie Richtlinie B aus der Liste löschen, nimmt Richtlinie C nun die zweite Position ein, und Richtlinie D nimmt die dritte Position ein.

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

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

In NetScaler ADM gibt es immer eine Standardrichtlinie, die csvserver mit einer Priorität von 1 verknüpft ist. Diese Standardrichtlinie gibt die Anzahl der TCP-Verbindungen an, die zu einem bestimmten Zeitpunkt lbvserver verarbeitet werden. Wenn die entsprechenden Responder-Richtlinien und Content-Switching-Richtlinien in NetScaler erstellt werden, wird ihnen daher immer eine Priorität 1 zugewiesen, die größer ist als die Priorität der entsprechenden L7-Richtlinie. Wenn beispielsweise eine L7-Richtlinie mit der Priorität 1 ausgewertet wird und eine Content Switching-Richtlinie mit der Priorität 2 erstellt wird. In ähnlicher Weise wird eine L7-Richtlinie mit einer Priorität von 2 ausgewertet und eine Responderrichtlinie 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” ausgewertet. In NetScaler werden die Responderrichtlinien immer zuerst ausgewertet, um entweder die Anforderung zu löschen oder dem Benutzer eine umgeleitete Webadresse zu präsentieren, und die Content Switching-Richtlinien werden zuletzt ausgewertet. Diese Reihenfolge der Auswertung führt normalerweise zu keinem Konflikt, wenn sich die Content Switching- und Responder-Richtlinien 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 anderen Ausdruck, um Anfragen an “example-sports-football.com” zuzulassen. Erstellen Sie die L7-Richtlinien, so dass alle Responder-Richtlinien, die die Anforderung ablehnen, oben in der Evaluierungsliste angeordnet sind, gefolgt von den Responder-Richtlinien für Web Direct, gefolgt von den Content Switching-Richtlinien.

Konfigurationsaufgaben

Die L7-Richtlinien- und Aktionsimplementierungen werden über Neutron LBaaS-Befehle ausgeführt.

Legen Sie die Umgebungsvariablen in OpenStack fest und erstellen Sie den Load Balancer (z. B. LB1). Nachdem der Load Balancer 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. Beispielsweise ist P1 der Standardpool für L1, während P2 der Pool ist, der an LB1 gebunden ist und die Anwendungsserver verwaltet.

Weitere Informationen zum Konfigurieren von LBaaS V2 mithilfe der Befehlszeile finden Sie unter Konfigurieren von LBaaS V2 mit der Befehlszeile.

Mit den folgenden Befehlen werden die Richtlinien erstellt und die spezifischen Aktionen definiert:

L7-Richtlinie erstellen, um Anforderungen zu löschen

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 Policy11, eine Responder-Richtlinie, und bindet sie an den Content Switching-Server, um Anfragen abzulehnen. Da für diese Richtlinie keine Regel erstellt wurde, wird die Richtlinie als „falsch“ ausgewertet und die Anfrage wird abgelehnt.

Erstellen einer L7-Richtlinie, um Anforderungen an eine bestimmte URL umzuleiten

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 Responderaktion, um Anforderungen an eine URL umzuleiten, erstellt eine Responderrichtlinie mit Aktion und bindet diese Richtlinie an den virtuellen Content Switching-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 oben genannten Regeln können mit einem AND-Operator verbunden werden, um den Ausdruck für die Responderrichtlinie abzuleiten.

Erstellen einer L7-Richtlinie zum Umleiten von Anforderungen 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 Anforderungen an LB1 um. Wenn P2 bereits vorhanden ist, erstellt der Befehl die Content Switching-Umleitungsaktion und leitet die Anforderungen an LB1 um.