Layer-7-Content Switchings konfigurieren
Citrix Application Delivery Management (ADM) orchestriert mit OpenStack, um die Layer 7 (L7) -Switching oder inhaltsbasierte Switching-Funktionen auf Citrix ADC Instanzen zu konfigurieren. 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 ADC Instanz als Anbieter erstellt werden, weist NetScaler ADM eine NetScaler ADC-Instanz zu und stellt Content Switching und Responder-Konfigurationen entsprechend den L7-Konfigurationen bereit. Die Citrix ADC Instanzen können dann Benutzeranforderungen auf der Grundlage der Anwendungsschicht-Merkmale der Anforderungen verteilen und ausgleichen.
Die OpenStack Layer 7 (L7)-Lastausgleichsfunktion kombiniert Lastausgleich und Content Switching, um eine optimierte Bereitstellung bestimmter Inhaltstypen zu ermöglichen. Dadurch wird die Leistung des Load Balancers verbessert, 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-ussollte ein Endbenutzer, der nach sucht, von einem Serverpool bedient werden, der Inhalte über das Unternehmen und die Dienste hostet, während ein Benutzer, der nach sucht, von einem anderen Serverpool bedient werden http://example-sports.com/shopping-cart-footballsollte, der ermöglicht es den Benutzern, 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 sollten im Wesentlichen bestimmte Inhaltstypen bereitstellen. Beispielsweise könnte ein Server nur Bilder bereitstellen, ein anderer Server kann serverseitige Skriptsprachen wie PHP und ASP ausführen, und ein anderer könnte 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 value Parameter 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
Die Hostname-, Pfad-, Header- und Cookie-Attribute unterstützen alle Vergleichstypen, aber das file_type-Attribut 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 Nicht autorisierte Antwort zurückgeben, um den Benutzern den Zugriff für 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 Citrix ADC Entitäten
| OpenStack | Citrix ADC Entität | Beschreibung |
| L7-Richtlinie mit der Aktion REDIRECT_TO_POOL | Content Switching-Richtlinie > Content Switching-Aktion | NetScaler ADM erstellt eine Content Switching-Richtlinie, die an den virtuellen Content Switching-Server gebunden ist und einer Content Switching-Aktion zugeordnet ist, die den Zielpool von Anwendungsservern für den Inhaltsabruf und die Präsentation für den Benutzer angibt. |
| L7-Richtlinie mit der Aktion REDIRECT_TO_URL | Responder-Richtlinie > Responder-Aktion | NetScaler ADM erstellt eine Responderrichtlinie, die an den virtuellen Content Switching-Server gebunden ist und einer Responderaktion zugeordnet ist, die die Ziel-URL angibt, die den Benutzern angezeigt werden soll. |
| L7-Richtlinie mit Aktion ABLEHNEN | Responder-Richtlinie > Anfrage löschen | NetScaler ADM erstellt eine Responderrichtlinie, die an den virtuellen Content Switching-Server gebunden ist und einer Responderaktion zugeordnet ist, die die Anforderung löscht. |
Wenn die Aktion einer L7-Richtlinie, die als “true” ausgewertet wird, Datenverkehr an einen Pool umleitet, der sich im Status “create_pending” befindet, implementiert Citrix ADM den angegebenen Pool zusammen mit einem virtuellen Lastenausgleichsserver. 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 Anforderung 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 ist immer eine Standardrichtlinie mit einem csvserver mit der Priorität 1 zugeordnet. Diese Standardrichtlinie gibt die Anzahl der TCP-Verbindungen an, die ein lbvserver zu einem bestimmten Zeitpunkt verarbeiten soll. Wenn die entsprechenden Responderrichtlinien und Inhaltswechselrichtlinien in Citrix ADC 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 werden zuerst die Richtlinien “reject” und/oder “redirect_to_url” ausgewertet und dann die Richtlinie “redirect_to_pool” ausgewertet. In einer NetScaler ADC 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 sollten keine identischen Ausdrücke haben. Die abgeleiteten Ausdrücke sollten in den Responder- und Inhaltswechselrichtlinien hinzugefügt werden, 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 ist immer eine Standardrichtlinie mit einem csvserver mit der Priorität 1 zugeordnet. Diese Standardrichtlinie gibt die Anzahl der TCP-Verbindungen an, die ein lbvserver zu einem bestimmten Zeitpunkt verarbeiten soll. Wenn die entsprechenden Responder- und Content Switching-Richtlinien in NetScaler ADC 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 werden zuerst die Richtlinien “reject” und/oder “redirect_to_url” ausgewertet und dann die Richtlinie “redirect_to_pool” ausgewertet. In NetScaler ADC 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 sollten ähnliche Ausdrücke haben. Ähnliche abgeleitete Ausdrücke sollten in den Responder- und Inhaltswechselrichtlinien hinzugefügt werden, 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.