Citrix Application Delivery Management 13.0

Konfigurieren des Layer-7-Inhaltswechsels

Citrix Application Delivery Management (ADM) orchestriert mit OpenStack, um die Layer 7 (L7) -Switching oder inhaltsbasierte Switching-Funktionen auf Citrix ADC Instanzen zu konfigurieren. Inhaltsumschaltung 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 Citrix ADC Instanz als Anbieter erstellt werden, weist Citrix ADM eine Citrix ADC-Instanz zu und stellt Content Switching und Respder-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 es Ihnen, einen Einpunkt-Eintrag zu haben, um auf eine Vielzahl von Back-End-Diensten zuzugreifen (z. B. nicht nur Webanwendungen, Web-Service-Portale, Web-Mails, 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 zu Load Balancing auf niedrigerem Level erfordert das Layer-7-Switching nicht, dass alle Server im Pool denselben Inhalt haben. Eine Load Balancer-Konfiguration mit L7-Switching erwartet, dass die Anwendung oder Back-End-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”.

  • path: Der Pfadteil des HTTP-URI wird mit dem Wert Parameter in der Regel verglichen. Beispiel: “www.beispiel-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: Der durch den Schlüsselparameter benannte Cookie wird mit dem Wert Parameter in der Regel verglichen. Der Cookie-Request-Header-Feldwert enthält ein Name-Wert-Paar von Informationen, 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 = fußball-.

Vergleichstypen

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

  • regex: Passend für reguläre Ausdrücke vom Perl-Typ

  • starts_with: String beginnt mit

  • ends_with: String endet mit

  • enthält: String 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-Datenverkehr und gibt einen “true” -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 Anforderung muss mit allen Regeln übereinstimmen, damit die Richtlinie einen “true” -Wert zurückgibt. Die vom Load Balancer durchgeführte 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, in der die eingehende HTTP-Anforderung die Wörter “EXAMPLE-SPORTS”, “SPORTS-FOOTBALL” oder “EXAMPLE-FOTBALL” 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-Anforderung mit einem dieser sechs Schlüsselwörter sendet, leitet der Load Balancer die Anforderung an den Example-Sport-Server weiter.

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

  • Umleiten zum Pool - leiten Sie die Anforderung an den Anwendungsserverpool weiter, der durch die Regeln der L7-Richtlinie identifiziert wird. Das heißt, Sie können eine Anwendungsregel erstellen, um Anforderungen entsprechend dem Domänennamen an einen bestimmten Load Balancer-Pool weiterzuleiten. Sie können beispielsweise eine Regel erstellen, die einige Anforderungen an example-football.com an pool_1 weiterleitet, und andere Anforderungen an example-sports-online_purchase.com an pool_2.

  • Umleiten an URL - Senden Sie dem Client eine HTTP-Umleitung, in der der Positionsantwort-Header den neuen Speicherort enthält. Der Browser aktualisiert die Adressleiste mit dem neuen Speicherort und stellt eine neue Anforderung aus. Die Anwendungsfälle sind vielfältig. Wenn sich beispielsweise eine Websiteadresse geändert hat, können Sie Anforderungen an die neue Adresse umleiten, anstatt sie zu löschen. Oder während der Websitewartung können Sie die Benutzer 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 den Inhaltswechsel. Nachdem Sie den virtuellen Server und die Richtlinien für den Content Switching erstellt haben, binden Sie jede Richtlinie an den Content Switching Virtual Server. Wenn Sie die Richtlinie an den virtuellen Content Switching-Server binden, geben Sie den virtuellen Zielserver für den Lastenausgleich an. Wenn eine Anforderung den virtuellen Server für die Inhaltsvermittlung erreicht, wendet der virtuelle Server die zugeordneten Inhaltswechselrichtlinien auf diese Anforderung an. Die Priorität der Richtlinie definiert die Reihenfolge, in der die Richtlinien ausgewertet werden, die an den virtuellen Server des Inhaltswechsels gebunden sind.

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 nur durch die Implementierung einer L7-Richtlinie einem Listener zugeordnet. Ein Pool kann auch direkt unter einem Load Balancer erstellt werden, ohne notwendigerweise an einen Listener gebunden zu sein. In einem solchen Fall wird der Pool in einem “pending_create” -Zustand erstellt. Da die L7-Richtlinien eng an die Listener gebunden sind, muss eine L7-Richtlinie mit der Pool-ID erstellt und implementiert werden, damit der Pool “aktiv” wird und damit beginnt, Datenverkehrsanfragen zu empfangen.

Ein Pool kann von mehreren L7-Richtlinien bedient werden, bleibt jedoch im Status “aktiv”, wenn mindestens eine Richtlinie an ihn angehängt ist. Wenn die letzte Richtlinie entfernt wird, wechselt der Pool in den Status “pending_create” zurück, bis eine andere Richtlinie erstellt und mit ihr verknüpft ist. Wenn der Pool selbst entfernt wird, werden alle HTTP-Anforderungen, die er sonst erhalten 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 Aktion REDIRECT_TO_POOL Richtlinie zum Umschalten von Inhalten > Aktion zum Wechseln von Inhalten Citrix 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 Aktion REDIRECT_TO_URL Responderrichtlinie > Responder-Aktion Citrix 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 REJECT Responderrichtlinie > Anforderung löschen Citrix 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. Citrix ADM erstellt eine Inhaltswechselrichtlinie aus der L7-Richtlinie und verwendet die entsprechende Inhaltsumschalteraktion, um die Anforderungen an den virtuellen Lastausgleichsserver umzuleiten, der diesem Pool zugeordnet ist. Wenn eine zweite L7-Richtlinie an denselben Pool umgeleitet wird, erstellt Citrix ADM eine Inhaltswechselrichtlinie und eine Inhaltsumschalteraktion, um den Datenverkehr an den vorhandenen virtuellen Lastausgleichsserver umzuleiten, der dem Pool zugeordnet ist.

Positionierung von Richtlinien

Die Bewertung von L7-Richtlinien in OpenStack hängt von ihren Prioritäten ab. In OpenStack werden den Richtlinien standardmäßig Prioritäten in der Reihenfolge zugewiesen, in der sie erstellt werden. Die zuerst erstellte Richtlinie wird mit “1” nummeriert 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 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 zuweisen wie einer vorhandenen Richtlinie, hat die neue Richtlinie diese Priorität. Die Priorität der bestehenden Richtlinie wird gesenkt. Gegebenenfalls werden auch die Prioritäten anderer Richtlinien herabgesetzt, um die Reihenfolge, in der die Richtlinien bewertet werden, beizubehalten.

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

  • Wenn Sie der Liste eine Richtlinie hinzufügen oder eine Richtlinie aus der Liste löschen, werden die Richtlinienpositionswerte von 1 neu sortiert, ohne dass Zahlen übersprungen werden. 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 Citrix 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 Richtlinie zum Umschalten von Inhalten 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 Citrix 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 Richtlinien für die Inhaltsvermittlung werden zuletzt ausgewertet. Diese Reihenfolge der Auswertung führt normalerweise zu keinem Konflikt, wenn sich die Richtlinien zum Umschalten von Inhalten und Respondern 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 Richtlinien für die Inhaltsvermittlung.

In Citrix 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 Richtlinie zum Umschalten von Inhalten 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 Citrix 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 Richtlinien für die Inhaltsvermittlung werden zuletzt ausgewertet. Diese Reihenfolge der Auswertung führt normalerweise zu keinem Konflikt, wenn sich die Richtlinien zum Umschalten von Inhalten und Respondern 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 Richtlinien für die Inhaltsvermittlung.

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 über die Befehlszeile finden Sie unter Konfigurieren von LBaaS V2 über die 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 und bindet policy11, eine Responderrichtlinie, an den Content Switching-Server, um Anforderungen abzulehnen. Da für diese Richtlinie keine Regel erstellt wurde, wird die Richtlinie als “false” ausgewertet, und die Anforderung 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 Server für den Content Switching.

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

neutron lbaas-l7rule-create —type PATH —compare-type enthält —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 Umleitungsaktion für den Inhaltswechsel und leitet die Anforderungen an LB1 um. Wenn P2 bereits vorhanden ist, erstellt der Befehl die Umleitungsaktion für die Inhaltsumschaltung und leitet die Anforderungen an LB1 um.

Konfigurieren des Layer-7-Inhaltswechsels