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 du simple équilibrage 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 ADM attribue une instance NetScaler et déploie des configurations de commutation de contenu et de répondeur correspondant aux configurations L7. Les instances NetScaler peuvent ensuite distribuer et équilibrer la charge des demandes des utilisateurs sur la base des caractéristiques des demandes au niveau de la couche application.

La fonction d’équilibrage de charge de la couche 7 (L7) d’OpenStack combine l’équilibrage de charge et la commutation de contenu pour optimiser la diffusion de types spécifiques de contenu. Cela améliore les performances de l’équilibreur de charge en exécutant uniquement les stratégies applicables au contenu. L’équilibrage de charge de couche 7 facilite également l’efficacité de l’infrastructure applicative. La possibilité 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 applicative. 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 différent de serveurs qui permet aux utilisateurs d’effectuer des achats en ligne.

Dans la commutation L7, un équilibreur de charge est implémenté en tant que serveur virtuel de commutation de contenu qui accepte les requêtes HTTP des utilisateurs et les distribue aux serveurs d’applications. La commutation L7 ou la commutation de contenu vous permet d’avoir une entrée unique pour accéder à une variété de services back-end (par exemple, pas seulement les applications Web, les portails de services Web, les courriels Web, mais aussi la gestion mobile, le contenu dans différentes langues, etc.). Autrement dit, vous pouvez fournir une 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 ne nécessite pas que tous les serveurs du pool aient le même contenu. Une configuration d’équilibrage de charge utilisant la commutation L7 s’attend à ce que l’application ou les serveurs back-end de différents pools aient un contenu différent. Les commutateurs L7 peuvent diriger les requêtes sur la base de l’URI, de l’hôte, des en-têtes HTTP ou tout autre élément du message de l’application. Les serveurs d’applications servent essentiellement des types spécifiques de contenu. Par exemple, un serveur ne peut 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 dans la requête HTTP est comparé au paramètre value de la règle. Par exemple, « www.example-sports.com ».

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

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

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

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

Types de comparaison

Lors de l’évaluation du trafic, la stratégie 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 : Chaîne commence par

• ends_with : La chaîne se termine par

• contient : La chaîne contient

• equal_to : Chaîne égale à

Remarque

Les attributs nom d’hôte, chemin d’accès, en-tête et 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 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 appariées.

Dans toute stratégie L7, toutes les règles sont logiquement jointes à un opérateur AND. Une requête doit correspondre à toutes les règles afin 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 dans laquelle la requête HTTP entrante peut contenir les mots « EXAMPLE-SPORTS », « SPORTS-FOOTBALL » ou « EXAMPLE-FOOTBALL », afin que l’équilibreur de charge prenne les mesures appropriées pour transférer ces demandes au pool de serveurs de l’Example-Sports entreprise de commerce électronique pour servir le contenu demandé. Vous pouvez créer une autre stratégie qui prend la même action, mais qui correspond à « exemple sport », « exemple sports-football » ou « exemple football. » Lorsqu’un utilisateur envoie une requête HTTP avec l’un de ces six mots-clés, l’équilibreur de charge transmet 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 demande 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 URL - Envoie au client une réponse HTTP de redirection dans laquelle l’en-tête de réponse d’emplacement contient le nouvel emplacement. Le navigateur mettra à jour la barre d’adresse avec le nouvel emplacement et émettra une nouvelle demande. Les cas d’utilisation sont nombreux. Par exemple, si une adresse de site Web a changé, vous pouvez rediriger les demandes 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 demande et n’effectue aucune autre action. Par exemple, vous pouvez renvoyer une réponse 401 non autorisée 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 consistant en serveurs et services virtuels d’équilibrage de charge, et de stratégies de commutation de contenu. Après avoir créé votre serveur virtuel de commutation de contenu et vos stratégies, vous liez chaque stratégie au serveur virtuel de commutation de contenu. Lorsque vous liez la stratégie au serveur virtuel de commutation de contenu, vous spécifiez le serveur virtuel d’équilibrage de charge cible. Lorsqu’une demande atteint le serveur virtuel de commutation de contenu, le serveur virtuel applique les stratégies de commutation de contenu associées à cette demande. La priorité de la stratégie définit l’ordre dans lequel les stratégies liées au serveur virtuel de commutation de contenu sont évaluées.

Tout pool ayant l’ID du processus d’écoute peut être affecté en tant que pool par défaut de serveurs virtuels vers lesquels le trafic est détourné. Le pool est lié de manière lâche à un écouteur et devient associé à un écouteur uniquement par l’implémentation d’une stratégie L7. Un pool peut également être créé directement sous un équilibreur de charge sans nécessairement être lié à un écouteur. Dans ce cas, le pool est créé dans un état « pending_create ». Étant donné que les stratégies L7 sont étroitement liées aux écouteurs, une stratégie L7 contenant l’ID de pool doit être créée et implémentée pour que le pool devienne « actif » et commence à recevoir des demandes de trafic.

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

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

Si l’action d’une politique L7 évaluée comme « true » redirige le trafic vers un pool dont l’état est « create_pending », NetScaler ADM implémente le pool spécifié ainsi qu’un serveur virtuel d’équilibrage de charge. NetScaler ADM crée une politique de commutation de contenu à partir de la stratégie L7 et utilise l’action de commutation de contenu correspondante pour rediriger les demandes vers le serveur virtuel d’équilibrage de charge associé à ce pool. Si une deuxième stratégie 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 stratégies L7 dans OpenStack est déterminée par leurs priorités. Dans OpenStack, par défaut, les stratégies se voient attribuer des priorités dans l’ordre dans lequel elles sont créées. La stratégie créée en premier est numérotée « 1 », et les stratégies 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 stratégie qui correspond à une requête spécifique est toujours exécutée en premier.

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

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

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

• Si vous créez une nouvelle stratégie et lui attribuez un poste supérieur au nombre de stratégies déjà dans la liste, la nouvelle stratégie sera ajoutée à la liste, c’est-à-dire que la nouvelle stratégie prend toujours la priorité disponible suivante. 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 stratégie et attribuez une priorité de 8, la priorité de la nouvelle stratégie devient 4.

• Si vous ajoutez une stratégie à la liste ou supprimez une stratégie de la liste, les valeurs de position de stratégie sont réordonnées à partir de 1 sans ignorer les nombres. Par exemple, si la stratégie A, B, C et D a des valeurs de position de 1, 2, 3 et 4 et si vous supprimez la stratégie B de la liste, la stratégie C prend désormais la deuxième position et la stratégie D prend la troisième position.

Dans NetScaler ADM, il existe toujours une politique par défaut associée à une csvserver priorité de 1. Cette stratégie 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éponse et les stratégies de commutation de contenu correspondantes sont créées dans NetScaler, elles se voient toujours attribuer une priorité 1 supérieure à la priorité de la politique L7 correspondante. Par exemple, lorsqu’une stratégie L7 avec une priorité de 1 est évaluée et qu’une stratégie de commutation de contenu est créée avec une priorité de 2. De même, lorsqu’une stratégie L7 avec une priorité de 2 est évaluée et qu’une stratégie de réponse est créée avec une priorité de 3.

Dans OpenStack, la stratégie « rejet » ou « redirect_to_url » est d’abord évaluée, puis la stratégie « redirect_to_pool » est évaluée. Dans une instance NetScaler, les politiques du répondeur sont toujours évaluées en premier pour rejeter la demande ou pour 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 provoque généralement aucun conflit si les politiques de changement de contenu et de réponse s’excluent mutuellement. En d’autres termes, deux stratégies L7 ne doivent pas avoir des expressions identiques. Les expressions dérivées sont ajoutées dans les stratégies de répondeur et de changement de contenu pour éviter de tels conflits. Par exemple, écrivez une expression pour rejeter toutes les demandes sur “sports-football.com” et une autre expression pour autoriser les requêtes à “example-sports-football.com.” Créez les stratégies L7 de sorte que toutes les stratégies de réponse pour rejeter la demande soient organisées en haut de la liste d’évaluation, suivies des stratégies de réponse pour le web direct, suivies des stratégies de changement de contenu.

Dans NetScaler ADM, il existe toujours une politique par défaut associée à une csvserver priorité de 1. Cette stratégie 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éponse et les stratégies de commutation de contenu correspondantes sont créées dans NetScaler, elles se voient toujours attribuer une priorité 1 supérieure à la priorité de la politique L7 correspondante. Par exemple, lorsqu’une stratégie L7 avec une priorité de 1 est évaluée et qu’une stratégie de commutation de contenu est créée avec une priorité de 2. De même, lorsqu’une stratégie L7 avec une priorité de 2 est évaluée et qu’une stratégie de réponse est créée avec une priorité de 3.

Dans OpenStack, la stratégie « rejet » ou « redirect_to_url » est d’abord évaluée, puis la stratégie « redirect_to_pool » est évaluée. Dans NetScaler, les politiques de réponse sont toujours évaluées en premier pour rejeter la demande ou pour 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 provoque généralement aucun conflit si les politiques de changement de contenu et de réponse s’excluent mutuellement. En d’autres termes, il n’y a pas deux stratégies L7 qui ont des expressions similaires. Des expressions dérivées similaires sont ajoutées dans les stratégies de répondeur et de changement de contenu pour éviter de tels conflits. Par exemple, écrivez une expression pour rejeter toutes les demandes sur “sports-football.com” et une autre expression pour autoriser les requêtes à “example-sports-football.com.” Créez les stratégies L7 de sorte que toutes les stratégies de réponse pour rejeter la demande soient organisées en haut de la liste d’évaluation, suivies des stratégies de réponse pour le web direct, suivies des stratégies de changement de contenu.

Tâches de configuration

Les implémentations de stratégie et d’action L7 sont effectuées via les commandes LBaaS Neutron.

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éé, créez le processus d’écoute 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 façon de configurer 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 supprimer les demandes

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 demandes. Aucune règle n’ayant été créée pour cette stratégie, la stratégie est évaluée à « false » et la demande est rejetée.

Créer une stratégie L7 pour rediriger les demandes 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 demandes 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 à un opérateur AND pour dériver l’expression de la stratégie de répondeur.

Créer une stratégie L7 pour rediriger les demandes 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.