Configurer la commutation de contenu de couche 7

NetScaler Application Delivery Management (ADM) s’orchestre avec OpenStack pour configurer les fonctionnalités de commutation de couche 7 (L7) ou de commutation basée sur le contenu sur les instances NetScaler. La commutation de contenu diffère de l’équilibrage de charge simple en ce que des types spécifiques de requêtes peuvent être dirigés vers des serveurs spécifiques. Lorsque les configurations L7 sont créées dans OpenStack avec une instance NetScaler comme fournisseur, NetScaler ADM alloue une instance NetScaler et déploie des configurations de commutation de contenu et de répondeur correspondant aux configurations L7. Les instances NetScaler peuvent alors distribuer et équilibrer la charge des requêtes utilisateur en fonction des caractéristiques de la couche application des requêtes.

La fonctionnalité d’équilibrage de charge de couche 7 (L7) d’OpenStack combine l’équilibrage de charge et la commutation de contenu pour offrir une livraison optimisée de types de contenu spécifiques. Cela améliore les performances de l’équilibreur de charge en n’exécutant que les politiques applicables au contenu. L’équilibrage de charge de couche 7 facilite également l’augmentation de l’efficacité de l’infrastructure d’application. La capacité à séparer le contenu par type, URI ou données permet une meilleure allocation des ressources physiques dans l’infrastructure d’application. Par exemple, un utilisateur final naviguant vers http://example-sports.com/about-us est servi par un pool de serveurs hébergeant du contenu sur l’entreprise et les services, tandis qu’un utilisateur naviguant vers http://example-sports.com/shopping-cart-football est servi par un pool de serveurs différent qui permet aux utilisateurs d’effectuer des achats en ligne.

Dans la commutation L7, un équilibreur de charge est implémenté comme un serveur virtuel de commutation de contenu qui accepte les requêtes HTTP des utilisateurs et distribue ces requêtes aux serveurs d’application. La commutation L7 ou commutation de contenu vous permet d’avoir un point d’entrée unique pour accéder à une variété de services back-end (par exemple, pas seulement des applications web, des portails de services web, des messageries web, mais aussi la gestion mobile, le contenu dans différentes langues, etc.). Autrement dit, vous pouvez fournir une seule adresse IP publique pour tous les services que vous offrez à vos utilisateurs.

Contrairement à l’équilibrage de charge de niveau inférieur, la commutation de couche 7 n’exige pas que tous les serveurs du pool aient le même contenu. Une configuration d’équilibreur de charge utilisant la commutation L7 s’attend à ce que les serveurs d’application ou back-end de différents pools aient un contenu différent. Les commutateurs L7 peuvent diriger les requêtes en fonction de l’URI, de l’hôte, des en-têtes HTTP ou de tout autre élément du message de l’application. Les serveurs d’application servent essentiellement des types de contenu spécifiques. Par exemple, un serveur peut ne servir que des images, un autre peut exécuter des langages de script côté serveur, tels que PHP et ASP, et un autre peut servir du contenu statique tel que HTML, CSS et JavaScript.

Règles L7

Les attributs suivants sont définis dans une règle pour évaluer le trafic et sont comparés aux valeurs définies dans la règle :

• Nom d’hôte : Le nom d’hôte de la requête HTTP est comparé au paramètre de valeur dans la règle. Par exemple, « www.example-sports.com ».

• Chemin : La partie chemin de l’URI HTTP est comparée au paramètre de valeur dans la règle. Par exemple, « www.example-sports.com/shopping-cart/football_pump.html ».

• Type de fichier : La dernière partie de l’URI est comparée au paramètre de valeur dans la règle. Par exemple, txt, html, jpg, PNG, xls, et autres.

• En-tête : L’en-tête défini dans le paramètre clé est comparé au paramètre de valeur dans la règle.

• Cookie : Le cookie nommé par le paramètre clé est comparé au paramètre de valeur dans la règle. La valeur du champ d’en-tête de requête de cookie contient une paire nom et valeur d’informations stockées pour cette URL ; la syntaxe générale est la suivante : Cookie: name=value. Par exemple, une règle qui recherche un cookie nommé « stores » avec la valeur commençant par « football- » ressemblera à : type = Cookie, compare_type=StartsWith, key = stores value = football-.

Types de comparaison

Lors de l’évaluation du trafic, la politique L7 compare les expressions suivantes aux attributs définis dans la règle.

• regex : Correspondance d’expression régulière de type Perl

• starts_with : La chaîne commence par

• ends_with : La chaîne se termine par

• contains : La chaîne contient

• equal_to : La chaîne est égale à

Remarque

Les attributs de nom d’hôte, de chemin, d’en-tête et de cookie prennent en charge tous les types de comparaison, mais l’attribut file_type ne prend en charge que regex et equal_to.

Politiques L7

Une politique L7 traite le trafic HTTP entrant et renvoie une valeur « true » lorsque toutes les règles définies dans la politique sont respectées.

Dans toute politique L7, toutes les règles sont logiquement jointes par un opérateur AND. Une requête doit correspondre à toutes les règles pour que la politique renvoie une valeur « true ». L’action entreprise par l’équilibreur de charge est basée sur la valeur renvoyée par la politique. Vous pouvez créer une deuxième politique avec la même action pour réaliser une opération OR logique entre les règles.

Par exemple, vous pouvez créer une politique où la requête HTTP entrante peut contenir les mots « EXAMPLE-SPORTS », « SPORTS-FOOTBALL » ou « EXAMPLE-FOOTBALL », afin que l’équilibreur de charge prenne l’action appropriée de transférer ces requêtes vers le pool de serveurs de la société de commerce électronique Example-sports pour servir le contenu demandé. Vous pouvez créer une autre politique qui prend la même action mais correspond à « example-sports », « example-sports-football » ou « example-football ». Lorsqu’un utilisateur envoie une requête HTTP avec l’un de ces six mots-clés, l’équilibreur de charge transfère la requête au serveur Example-Sports.

Selon les règles définies dans la politique, une politique L7 peut prendre l’une des actions suivantes :

• Rediriger vers le pool : Transférer la requête vers le pool de serveurs d’application identifié par les règles associées à la politique L7. Autrement dit, vous pouvez créer une règle d’application pour diriger les requêtes vers un pool d’équilibrage de charge spécifique en fonction du nom de domaine. Par exemple, vous pouvez créer une règle qui dirige certaines requêtes vers example-football.com vers pool_1, et d’autres requêtes vers example-sports-online_purchase.com vers pool_2.

• Rediriger vers l’URL : Envoyer au client une réponse HTTP de redirection dans laquelle l’en-tête de réponse de localisation contient la nouvelle localisation. Le navigateur mettra à jour la barre d’adresse avec la nouvelle localisation et émettra une nouvelle requête. Les cas d’utilisation sont nombreux. Par exemple, si une adresse de site web a changé, vous pouvez rediriger les requêtes vers la nouvelle adresse au lieu de les abandonner. Ou, pendant la maintenance du site web, vous pouvez rediriger les utilisateurs vers un site en lecture seule.

• Rejeter : Rejette la requête et ne prend aucune autre action. Par exemple, vous pouvez renvoyer une réponse 401 Non autorisé pour refuser l’accès aux utilisateurs pour les pages web restreintes.

Une configuration de commutation de contenu se compose d’un serveur virtuel de commutation de contenu, d’une configuration d’équilibrage de charge comprenant des serveurs virtuels et des services d’équilibrage de charge, et de politiques de commutation de contenu. Après avoir créé votre serveur virtuel de commutation de contenu et vos politiques, vous liez chaque politique au serveur virtuel de commutation de contenu. Lors de la liaison de la politique au serveur virtuel de commutation de contenu, vous spécifiez le serveur virtuel d’équilibrage de charge cible. Lorsqu’une requête atteint le serveur virtuel de commutation de contenu, le serveur virtuel applique les politiques de commutation de contenu associées à cette requête. La priorité de la politique définit l’ordre dans lequel les politiques liées au serveur virtuel de commutation de contenu sont évaluées.

Tout pool ayant l’ID d’écouteur peut être attribué comme pool par défaut de serveurs virtuels vers lequel le trafic est détourné. Le pool est faiblement lié à un écouteur et ne lui est associé que par l’implémentation d’une politique L7. Un pool peut également être créé directement sous un équilibreur de charge sans être nécessairement lié à un écouteur. Dans un tel cas, le pool est créé dans un état « pending_create ». Étant donné que les politiques L7 sont étroitement liées aux écouteurs, une politique L7 contenant l’ID du pool doit être créée et implémentée pour que le pool devienne « actif » et commence à recevoir des requêtes de trafic.

Un pool peut être desservi par plusieurs politiques L7, mais reste à l’état « actif » si au moins une politique y est attachée. Lorsque la dernière politique est supprimée, le pool retourne à l’état « pending_create » jusqu’à ce qu’une autre politique soit créée et associée à celui-ci. Si le pool lui-même est supprimé, toutes les requêtes HTTP qu’il aurait autrement reçues sont redirigées vers le pool par défaut.

Mappage entre les politiques L7 d’OpenStack et les entités NetScaler

Si l’action d’une politique L7 qui évalue à « true » redirige le trafic vers un pool en état « create_pending », NetScaler ADM implémente le pool spécifié avec un serveur virtuel d’équilibrage de charge. NetScaler ADM crée une politique de commutation de contenu à partir de la politique L7 et utilise l’action de commutation de contenu correspondante pour rediriger les requêtes vers le serveur virtuel d’équilibrage de charge associé à ce pool. Si une deuxième politique L7 redirige vers le même pool, NetScaler ADM crée une politique de commutation de contenu et une action de commutation de contenu pour rediriger le trafic vers le serveur virtuel d’équilibrage de charge existant associé au pool.

Positionnement des politiques

L’évaluation des politiques L7 dans OpenStack est déterminée par leurs priorités. Dans OpenStack, par défaut, les politiques se voient attribuer des priorités dans l’ordre de leur création. La politique créée en premier est numérotée « 1 », et les politiques créées ultérieurement sont numérotées consécutivement. Mais vous pouvez modifier les priorités des politiques et leur attribuer des priorités différentes. Les politiques sont toujours évaluées dans l’ordre de leurs priorités. La première politique qui correspond à une requête spécifique est toujours exécutée en premier.

Lors de la création de politiques, notez les points suivants :

• Si vous attribuez à une nouvelle politique la même priorité qu’une politique existante, la nouvelle politique prend cette priorité. La priorité de la politique existante est abaissée. Si nécessaire, les priorités des autres politiques sont également abaissées pour conserver l’ordre dans lequel les politiques sont évaluées.

• Si vous créez une nouvelle politique sans spécifier de position, la nouvelle politique sera simplement ajoutée à la liste.

• Si vous créez une nouvelle politique et lui attribuez une position supérieure au nombre de politiques déjà présentes dans la liste, la nouvelle politique sera ajoutée à la liste, c’est-à-dire que la nouvelle politique prend toujours la prochaine priorité disponible. Par exemple, s’il existe trois politiques A, B et C avec les priorités 1, 2 et 3, et si vous créez une politique et lui attribuez une priorité de 8, la priorité de la nouvelle politique devient 4.

• Si vous ajoutez une politique à la liste ou supprimez une politique de la liste, les valeurs de position des politiques sont réordonnées à partir de 1 sans sauter de numéros. Par exemple, si les politiques A, B, C et D ont des valeurs de position de 1, 2, 3 et 4, et si vous supprimez la politique B de la liste, la politique C prend maintenant la deuxième position, et la politique D prend la troisième position.

Dans NetScaler ADM, il y a toujours une politique par défaut associée à un csvserver avec une priorité de 1. Cette politique par défaut spécifie le nombre de connexions TCP qu’un lbvserver traite à un moment donné. Par conséquent, lorsque les politiques de répondeur et les politiques de commutation de contenu correspondantes sont créées dans NetScaler, elles se voient toujours attribuer une priorité supérieure de 1 à la priorité de la politique L7 correspondante. Par exemple, lorsqu’une politique L7 avec une priorité de 1 est évaluée et qu’une politique de commutation de contenu est créée avec une priorité de 2. De même, lorsqu’une politique L7 avec une priorité de 2 est évaluée et qu’une politique de répondeur est créée avec une priorité de 3.

Dans OpenStack, la politique « reject » ou « redirect_to_url » est d’abord évaluée, puis la politique « redirect_to_pool » est évaluée. Dans une instance NetScaler, les politiques de répondeur sont toujours évaluées en premier pour soit rejeter la requête, soit présenter à l’utilisateur une adresse web redirigée, et les politiques de commutation de contenu sont évaluées en dernier. Cet ordre d’évaluation ne cause généralement aucun conflit si les politiques de commutation de contenu et de répondeur sont mutuellement exclusives. Autrement dit, deux politiques L7 ne doivent pas avoir d’expressions identiques. Les expressions dérivées sont ajoutées dans les politiques de répondeur et de commutation de contenu pour éviter de tels conflits. Par exemple, écrivez une expression pour rejeter toutes les requêtes vers « sports-football.com » et une autre expression pour autoriser les requêtes vers « example-sports-football.com ». Créez les politiques L7 de manière à ce que toutes les politiques de répondeur pour rejeter la requête soient organisées en haut de la liste d’évaluation, suivies des politiques de répondeur pour la redirection web, suivies des politiques de commutation de contenu.

Dans NetScaler ADM, il y a toujours une politique par défaut associée à un csvserver avec une priorité de 1. Cette politique par défaut spécifie le nombre de connexions TCP qu’un lbvserver traite à un moment donné. Par conséquent, lorsque les politiques de répondeur et les politiques de commutation de contenu correspondantes sont créées dans NetScaler, elles se voient toujours attribuer une priorité supérieure de 1 à la priorité de la politique L7 correspondante. Par exemple, lorsqu’une politique L7 avec une priorité de 1 est évaluée et qu’une politique de commutation de contenu est créée avec une priorité de 2. De même, lorsqu’une politique L7 avec une priorité de 2 est évaluée et qu’une politique de répondeur est créée avec une priorité de 3.

Dans OpenStack, la politique « reject » ou « redirect_to_url » est d’abord évaluée, puis la politique « redirect_to_pool » est évaluée. Dans NetScaler, les politiques de répondeur sont toujours évaluées en premier pour soit rejeter la requête, soit présenter à l’utilisateur une adresse web redirigée, et les politiques de commutation de contenu sont évaluées en dernier. Cet ordre d’évaluation ne cause généralement aucun conflit si les politiques de commutation de contenu et de répondeur sont mutuellement exclusives. Autrement dit, aucune des deux politiques L7 n’a d’expressions similaires. Des expressions dérivées similaires sont ajoutées dans les politiques de répondeur et de commutation de contenu pour éviter de tels conflits. Par exemple, écrivez une expression pour rejeter toutes les requêtes vers « sports-football.com » et une autre expression pour autoriser les requêtes vers « example-sports-football.com ». Créez les politiques L7 de manière à ce que toutes les politiques de répondeur pour rejeter la requête soient organisées en haut de la liste d’évaluation, suivies des politiques de répondeur pour la redirection web, suivies des politiques de commutation de contenu.

Tâches de configuration

Les implémentations des politiques et actions L7 sont effectuées via les commandes Neutron LBaaS.

Définissez les variables d’environnement dans OpenStack et créez l’équilibreur de charge (par exemple, LB1). Une fois l’équilibreur de charge créé avec succès, créez l’écouteur et les pools (par exemple, L1, P1 et P2), et ajoutez des membres et des moniteurs aux pools. Par exemple, P1 est le pool par défaut pour L1, tandis que P2 est le pool lié à LB1 et gérant les serveurs d’application.

Pour plus d’informations sur la configuration de LBaaS V2 à l’aide de la ligne de commande, consultez Configuration de LBaaS V2 à l’aide de la ligne de commande.

Les commandes suivantes créent les politiques et définissent les actions spécifiques :

Créer une politique L7 pour rejeter les requêtes

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

Exemple :

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

La commande ci-dessus crée et lie policy11, une politique de répondeur, au serveur de commutation de contenu pour rejeter les requêtes. Comme aucune règle n’a été créée pour cette politique, la politique évalue à « false » et la requête est rejetée.

Créer une politique L7 pour rediriger les requêtes vers une URL particulière

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

Exemple :

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

La commande ci-dessus crée une action de répondeur pour rediriger les requêtes vers une URL, crée une politique de répondeur avec action, et lie cette politique au serveur virtuel de commutation de contenu.

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>

Les deux règles ci-dessus peuvent être connectées avec un opérateur AND pour dériver l’expression de la politique de répondeur.

Créer une politique L7 pour rediriger les requêtes vers un pool

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

Exemple :

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

S’il s’agit de la première politique L7, la commande ci-dessus implémente P2 avec LB1, crée l’action de redirection de commutation de contenu et redirige les requêtes vers LB1. Si P2 existe déjà, la commande crée l’action de redirection de commutation de contenu et redirige les requêtes vers LB1.