Configurer la commutation de contenu de couche 7

Dernière publication : Sep 25, 2026
NetScaler Console 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 la simple répartition de charge en ce sens 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 Console 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 fournir une livraison optimisée de types de contenu spécifiques. Cela améliore les performances de l'équilibreur de charge en exécutant uniquement 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é de séparer le contenu en fonction du type, de l'URI ou des 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'applications. 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 courriers web, mais aussi la gestion mobile, du 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'applications 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 d'application. Les serveurs d'applications servent essentiellement des types de contenu spécifiques. Par exemple, un serveur peut servir uniquement 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 ils sont comparés aux valeurs définies dans la règle :
  • Nom d'hôte : Le nom d'hôte dans 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'expressions régulières de type Perl
  • starts\_with: Chaîne commence par
  • ends\_with: Chaîne se termine par
  • contains: Chaîne contient
  • equal\_to: 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 les expressions régulières et equal\_to.

Stratégies L7

Une stratégie L7 traite le trafic HTTP entrant et renvoie une valeur « true » lorsque toutes les règles définies dans la stratégie sont respectées.
Dans toute stratégie L7, toutes les règles sont logiquement jointes par un opérateur ET. Une requête doit correspondre à toutes les règles pour que la stratégie renvoie une valeur « true ». L'action entreprise par l'équilibreur de charge est basée sur la valeur renvoyée par la stratégie. Vous pouvez créer une deuxième stratégie avec la même action pour réaliser une opération OU logique entre les règles.
Par exemple, vous pouvez créer une stratégie 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 stratégie qui effectue 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 stratégie, une stratégie L7 peut effectuer l'une des actions suivantes :
  • Rediriger vers le pool - Transférer la requête vers le pool de serveurs d'applications identifié par les règles associées à la stratégie 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 le nouvel emplacement. Le navigateur mettra à jour la barre d'adresse avec le nouvel emplacement et émettra une nouvelle requête. Les cas d'utilisation sont nombreux. Par exemple, si l'adresse d'un 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 n'entreprend 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 comprend un serveur virtuel dédié à cette fonction, une configuration d'équilibrage de charge (composée de serveurs virtuels et de services d'équilibrage de charge) et des stratégies de commutation de contenu. Une fois votre serveur virtuel de commutation de contenu et ses stratégies créés, vous liez chaque stratégie à ce dernier. Lors de la liaison de la stratégie à ce serveur virtuel, vous spécifiez le serveur virtuel d'équilibrage de charge cible. Lorsqu'une requête atteint le serveur virtuel de commutation de contenu, il applique les stratégies de commutation de contenu associées à cette requête. La priorité de la stratégie définit l'ordre d'évaluation des stratégies liées au serveur virtuel de commutation de contenu.
Tout pool ayant l'ID d'écouteur peut être attribué comme pool par défaut de serveurs virtuels vers lesquels le trafic est redirigé. Le pool est lié de manière lâche à un écouteur et n'est associé à un écouteur que par la mise en œuvre 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 mise en œuvre pour que le pool devienne "actif" et commence à recevoir les requêtes de trafic.
Un pool peut être desservi par plusieurs politiques L7, mais reste à l'état "actif" si au moins une politique lui 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 OpenStack et les entités NetScaler
OpenStack Entité NetScaler Description
Politique L7 avec action REDIRECT_TO_POOL Politique de commutation de contenu > Action de commutation de contenu NetScaler Console crée une politique de commutation de contenu qui est liée au serveur virtuel de commutation de contenu et associée à une action de commutation de contenu qui spécifie le pool cible de serveurs d'applications pour la récupération et la présentation du contenu à l'utilisateur.
Politique L7 avec action REDIRECT_TO_URL Politique de répondeur > Action de répondeur NetScaler Console crée une politique de répondeur qui est liée au serveur virtuel de commutation de contenu et associée à une action de répondeur qui spécifie l'URL cible à présenter aux utilisateurs.
Politique L7 avec action REJECT Politique de répondeur > Rejeter la requête NetScaler Console crée une politique de répondeur qui est liée au serveur virtuel de commutation de contenu et associée à une action de répondeur qui rejette la requête.
Si l'action d'une politique L7 qui évalue à « true » redirige le trafic vers un pool en état « create\_pending », NetScaler Console implémente le pool spécifié avec un serveur virtuel d'équilibrage de charge. NetScaler Console 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 Console 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 par la suite 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 Console, il existe 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 évaluée en premier, 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 abandonner 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. C'est-à-dire que deux politiques L7 ne doivent pas avoir des 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 placé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 Console, il existe 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 évaluée en premier, puis la politique « redirect\_to\_pool » est évaluée. Dans NetScaler, les politiques de répondeur sont toujours évaluées en premier pour soit abandonner 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. C'est-à-dire qu'aucune deux politiques L7 n'ont 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 placé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'applications.
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 stratégies et définissent les actions spécifiques :

Créer une stratégie 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 stratégie 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 stratégie, la stratégie est évaluée à « false » et la requête est rejetée.

Créer une stratégie 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 stratégie de répondeur avec action et lie cette stratégie 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 ET pour dériver l'expression de la stratégie de répondeur.

Créer une stratégie 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 stratégie 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.