Documentation Produit
ADC
14.1 - Current Release 13.1 13.0 12.1
Voir PDF

Prise en charge de la persistance pour le serveur virtuel de commutation de contenu

August 11, 2023
Contributeur: 
C

Les applications passent d’architectures monolithiques à une architecture de microservices. Différentes versions d’une même application peuvent coexister dans l’architecture des microservices. L’appliance NetScaler doit prendre en charge le déploiement continu d’applications. Cela est possible grâce à des plateformes qui exécutent des déploiements Canary (comme Spinnaker). Dans une configuration de déploiement continu, une version plus récente d’une application est déployée automatiquement et exposée au trafic client par étapes jusqu’à ce que l’application soit stable et prenne en charge la totalité du trafic. De plus, les services au client doivent être ininterrompus.

La fonction de commutation de contenu NetScaler permet à l’appliance NetScaler de répartir les demandes des clients sur plusieurs serveurs virtuels d’équilibrage de charge en fonction des stratégies liées au serveur virtuel de commutation de contenu.

Pour les déploiements continus, la commutation de contenu est utilisée pour sélectionner le serveur virtuel d’équilibrage de charge desservant différentes versions d’une application.

Lors de la commutation de contenu, la sélection d’un serveur virtuel d’équilibrage de charge pour une version d’application spécifique change lors de l’exécution en raison de la modification des stratégies de commutation de contenu. Au cours de cette transition, si certaines sessions sont présentes avec d’anciennes versions de l’application, ce trafic doit continuer à être desservi uniquement par les anciennes versions. Pour répondre à cette exigence, l’appliance NetScaler maintient la persistance entre plusieurs groupes d’équilibrage de charge derrière un serveur virtuel de commutation de contenu. La persistance du serveur virtuel de commutation de contenu permet une transition fluide des clients d’une version à l’autre.

Types de persistance pris en charge sur le serveur virtuel de commutation de contenu

Les types de persistance suivants sont pris en charge sur les serveurs virtuels de commutation de contenu.

Type de persistance Description
IP source SOURCEIP. Les connexions provenant de la même adresse IP client font partie de la même session de persistance. Pour plus de détails, consultez la section Persistance de l’adresse IP source.
Cookie HTTP COOKIEINSERT. Les connexions qui ont le même en-tête de cookie HTTP font partie de la même session de persistance. Le format du cookie que l’appliance NetScaler insère est le suivant  : NSC_ = où NSC_XXXX est l’ID du serveur virtuel dérivé du nom du serveur virtuel. Pour plus de détails, consultez la section Persistance des cookie HTTP.
ID de session SSL SSLSESSION. Les connexions qui ont le même ID de session SSL font partie de la même session de persistance. Pour plus de détails, consultez la section Persistance des ID de session SSL.

Vous pouvez configurer une valeur de délai d’expiration pour la persistance basée sur les cookies HTTP. Si vous définissez la valeur du délai d’expiration sur 0, l’appliance ADC ne spécifie pas le délai d’expiration, quelle que soit la version du cookie HTTP utilisée. Le délai d’expiration dépend alors du logiciel client, et ces cookies ne sont valides que si le logiciel est en cours d’exécution.

Selon le type de persistance que vous avez configuré, le serveur virtuel peut prendre en charge 250 000 connexions persistantes simultanées ou un nombre quelconque de connexions persistantes dans les limites imposées par la quantité de mémoire de votre appliance NetScaler. Le tableau suivant indique les types de persistance qui entrent dans chaque catégorie.

Type de persistance Nombre de connexions persistantes simultanées prises en charge
IP source, ID de session SSL 250,000
Cookie HTTP Limite de mémoire. Dans CookieInsert, si le délai d’attente n’est pas égal à 0, le nombre de connexions est limité par la mémoire.

Certains types de persistance sont spécifiques à certains types de serveurs virtuels. Le tableau suivant répertorie chaque type de persistance et indique quels types de persistance sont pris en charge sur chaque type de serveur virtuel.

Type de persistance HTTP HTTPS TCP UDP/IP SSL_Bridge SSL_TCP RTSP SIP_UDP
SOURCEIP Oui Oui Oui Oui Oui Oui Non Non
COOKIEINSERT Oui Oui Non Non Non Non Non Non
SSLSESSION Non Oui Non Non Oui Oui Non Non

Support de persistance des sauvegardes

Vous pouvez configurer le serveur virtuel de commutation de contenu pour qu’il utilise le type de persistance de l’adresse IP source comme type de persistance de sauvegarde lorsque le type de persistance des cookie échoue. Il est utile pour les déploiements Canary dans l’architecture des microservices. Lorsque le type de persistance des cookies échoue, l’appliance revient à la persistance basée sur l’adresse IP source uniquement lorsque le navigateur client ne renvoie aucun cookie dans la demande. Toutefois, si le navigateur renvoie un cookie (pas nécessairement le cookie de persistance), il est supposé qu’il prend en charge les cookies et que la persistance des sauvegardes n’est donc pas déclenchée. Vous pouvez également définir une valeur de délai d’expiration pour la persistance des sauvegardes. Le délai d’expiration est la période pendant laquelle une session de persistance est en vigueur.

Comment fonctionne la persistance sur le serveur virtuel de commutation de contenu

Scénario 1 : un serveur virtuel de commutation de contenu sans persistance

L’exemple suivant illustre le déploiement de plusieurs versions d’une application avec un serveur virtuel de commutation de contenu sans persistance.

persistence-cs1

Lorsque le client C1 envoie une demande à l’application, la demande est envoyée au serveur virtuel de commutation de contenu de l’appliance NetScaler. Le serveur virtuel de commutation de contenu évalue la stratégie et transmet la demande au serveur virtuel d’équilibrage de charge (LB1) qui dessert la version v1 de l’application.

persistence-cs2

Supposons qu’une nouvelle version v2 de l’application soit déployée et doive être exposée à un sous-ensemble d’utilisateurs. Le nouveau serveur virtuel d’équilibrage de charge (LB2) desservant la version v2 est lié au serveur virtuel de commutation de contenu par la stratégie de commutation de contenu appropriée.

Lorsque le client C1 envoie une nouvelle demande, la stratégie est à nouveau évaluée et la demande est transmise au serveur virtuel d’équilibrage de charge LB2. Ainsi, les transactions pour les applications statiques échouent si plusieurs versions de l’application sont déployées.

Scénario 2 : serveur virtuel de commutation de contenu avec persistance

L’exemple suivant illustre le déploiement de plusieurs versions de l’application avec un serveur virtuel de commutation de contenu avec persistance.

persistence-cs3

Lorsque le client C1 envoie une demande à l’application, la demande est envoyée au serveur virtuel de commutation de contenu de l’appliance NetScaler. Le serveur virtuel de commutation de contenu évalue la stratégie, crée une entrée de session de persistance et transmet la demande au serveur virtuel d’équilibrage de charge LB1 qui fournit la version v1 de l’application.

persistence-cs4

Le même client C1 demande à nouveau l’application, et la demande est envoyée au serveur virtuel de commutation de contenu de l’appliance NetScaler. Une recherche de la session de persistance est effectuée, et le serveur virtuel d’équilibrage de charge LB1 est extrait de la session de persistance existante et la demande est transmise à LB1. Aucune rupture de la transaction existante ne se produit avec cette solution, préservant ainsi le caractère dynamique de l’application.

persistence-cs5

Considérons un nouveau client C2. La nouvelle demande C2 est envoyée à la version la plus récente de l’application par le biais d’une évaluation de stratégie, car il n’y a pas de session de persistance existante pour ce client. Il en résulte un déploiement réussi de la nouvelle version de l’application sans en altérer le caractère dynamique.

Grâce à la prise en charge de la persistance, les clients peuvent déployer plusieurs contenus ou différentes versions de l’application de manière fluide sans affecter les transactions existantes, en particulier pour les applications statiques. Cela n’est pas possible sans persistance dans l’image.

Configurer le type de persistance sur le serveur virtuel de commutation de contenu à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

set cs vserver <name> -PersistenceType <type> [-timeout <integer>]
<!--NeedCopy-->

Exemple :

set cs vserver Vserver-CS-1 -persistenceType SOURCEIP -timeout 60
<!--NeedCopy-->

Configurer le type de persistance sur le serveur virtuel de commutation de contenu à l’aide de l’interface graphique

  1. Accédez à Gestion du trafic > Commutation de contenu > Serveurs virtuels, puis cliquez sur Ajouter .

  2. Dans Paramètres de base, configurez les détails de persistance.

Prise en charge de la persistance pour le serveur virtuel de commutation de contenu
August 11, 2023
Contributeur: 
C
August 11, 2023
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.