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 de disposer d’un point d’entrée unique pour accéder à divers services dorsaux (par exemple, non seulement aux applications Web, aux portails de services Web, aux courriers électroniques, mais également à la gestion mobile, au contenu dans différentes langues, etc.). En d’autres termes, 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 disposent du même contenu. Une configuration d’équilibreur de charge utilisant la commutation L7 s’attend à ce que les applications ou les serveurs principaux 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 ».

• chemin : 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 d’en-tête de demande de cookie contient une paire nom/valeur d’informations stockées pour cette URL ; la syntaxe générale est la suivante : Cookie : nom=valeur. Par exemple, une règle qui recherche un cookie nommé « stores » dont la valeur commence par « football- » ressemblera à ceci : type = Cookie, compare_type=startsWith, key = stores 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’expressions régulières de type Perl

• starts_with : chaîne commençant par

• ends_with : La chaîne se termine par

• contains : 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.

Stratégies L7

Une stratégie L7 traite le trafic HTTP entrant et renvoie une valeur « vraie » 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 associées à un opérateur AND. Une demande doit respecter toutes les règles pour que la stratégie renvoie une valeur « vraie ». 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 OR 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 transmettre ces demandes au pool de serveurs de la société de commerce électronique Example-Sports pour diffuser 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 demande 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 : transmettez la demande au pool de serveurs d’applications identifié par les règles associées à la stratégie L7. En d’autres termes, vous pouvez créer une règle d’application pour diriger les demandes vers un pool d’équilibreurs de charge spécifique en fonction du nom de domaine. Par exemple, vous pouvez créer une règle qui dirige certaines demandes vers example-football.com vers pool_1, et d’autres demandes vers example-sports-online_purchase.com vers pool_2.

• Redirection vers une URL : envoyez au client une réponse HTTP de redirection dans laquelle l’en-tête de la réponse de localisation 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 l’adresse d’un site Web a changé, vous pouvez rediriger les demandes vers la nouvelle adresse au lieu de les supprimer. 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 doté de l’ID d’écouteur peut être affecté en tant que pool par défaut de serveurs virtuels vers lesquels le trafic est redirigé. Le pool est étroitement lié à un écouteur et n’est associé à un auditeur que par la mise en œuvre d’une stratégie L7. Un pool peut également être créé directement sous un équilibreur de charge sans nécessairement être lié à un auditeur. Dans ce cas, le pool est créé dans un état « pending_create ». Les stratégies L7 étant étroitement liées aux auditeurs, une stratégie L7 contenant l’ID du pool doit être créée et mise en œuvre pour que le pool devienne « actif » et commence à recevoir des demandes de trafic.

Un pool peut être desservi par plusieurs stratégies L7, mais il 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 revient à l’état « pending_create » jusqu’à ce qu’une autre stratégie soit créée et associée à celle-ci. 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 stratégies OpenStack L7 et les entités NetScaler

Si l’action d’une stratégie L7 dont la valeur est « vraie » 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 stratégie 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 stratégie 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 stratégies

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. Vous pouvez toutefois modifier les priorités des stratégies et leur attribuer des priorités différentes. Les stratégies 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 stratégie existante est abaissée. Si nécessaire, les priorités des autres stratégies sont également abaissées afin de conserver l’ordre dans lequel les stratégies sont évaluées.

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

• Si vous créez une nouvelle stratégie et que vous lui attribuez une position supérieure au nombre de stratégies figurant déjà dans la liste, la nouvelle stratégie sera ajoutée à la liste, c’est-à-dire qu’elle aura toujours la priorité disponible suivante. Par exemple, s’il existe trois stratégies A, B et C avec les priorités 1,2 et 3, et si vous créez une stratégie et que vous attribuez une priorité de 8, la priorité de la nouvelle stratégie devient 4.

• Si vous ajoutez une stratégie à la liste ou si vous supprimez une stratégie de la liste, les valeurs de position de la stratégie sont réorganisées à partir de 1 sans omettre de chiffres. 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 stratégie par défaut associée à csvserver avec une 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 stratégies 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 stratégie 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 stratégies du répondeur sont toujours évaluées en premier pour supprimer la demande ou présenter à l’utilisateur une adresse Web redirigée, et les stratégies de commutation de contenu sont évaluées en dernier. Cet ordre d’évaluation ne provoque généralement aucun conflit si les stratégies 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 stratégie par défaut associée à csvserver avec une 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 stratégies de répondeur et de commutation de contenu correspondantes sont créées dans NetScaler, une priorité 1 supérieure à la priorité de la stratégie L7 correspondante leur est toujours attribuée. 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 stratégies 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 stratégies de commutation de contenu sont évaluées en dernier. Cet ordre d’évaluation ne provoque généralement aucun conflit si les stratégies 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 la stratégie et des 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 correctement créé, créez le module d’écoute et les pools (par exemple, L1, P1 et P2), puis 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, celle-ci est considérée comme « fausse » 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 en même temps que LB1, crée l’action de redirection de commutation de contenu et redirige les demandes 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.