Documentation Produit
ADC
Current Release 13.0 12.1
Voir PDF

Prise en charge de la persistance du serveur virtuel de commutation de contenu

October 4, 2021
Contributeur: 
C

Les applications passent des architectures monolithiques à l’architecture microservices. Différentes versions d’une même application peuvent coexister dans l’architecture des microservices. L’appliance Citrix ADC doit prendre en charge le déploiement continu des applications. Il est réalisé par des plates-formes qui effectuent des déploiements Canaries (tels que 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 pour prendre le trafic complet. De plus, il doit y avoir des services ininterrompus au client.

La fonctionnalité de commutation de contenu Citrix ADC permet à l’appliance Citrix ADC de distribuer les demandes client 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 permet de sélectionner le serveur virtuel d’équilibrage de charge desservant différentes versions d’une application.

Dans la commutation de contenu, la sélection d’un serveur virtuel d’équilibrage de charge pour une version d’application spécifique change au moment 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 des versions plus anciennes de l’application, ce trafic doit continuer à être servi uniquement par des versions plus anciennes. Pour prendre en charge cette exigence, l’appliance Citrix ADC maintient la persistance sur 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 transparente 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 à partir de la même adresse IP du client font partie de la même session de persistance. Pour plus de détails, voir 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 Citrix ADC insère est le suivant : **NSC_ <vid_str of CSvserver> = <vid_str of Lbvserver> où NSC_XXXX est l’ID du serveur virtuel dérivé du nom du serveur virtuel. Pour plus de détails, voir persistance des cookies 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, voir persistance des ID de session SSL.

Vous pouvez configurer une valeur de délai d’attente 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 n’importe quel nombre de connexions persistantes jusqu’à concurrence des limites imposées par la quantité de mémoire de votre appliance Citrix ADC. Le tableau suivant montre quels types de persistance appartiennent à 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’expiration n’est pas 0, le nombre de connexions est limité par la mémoire.

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

Type de persistance HTTP HTTPS TCP UDP/IP SSL_Pont 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

Prise en charge de la persistance des sauvegardes

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

Fonctionnement de 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 dans l’appliance Citrix ADC. 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

Considérons qu’une nouvelle version v2 de l’application est déployée et doit ê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 avec état échouent si plusieurs versions de l’application sont déployées.

Scénario 2 : Changement de contenu serveur virtuel 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 dans l’appliance Citrix ADC. 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 dans l’appliance Citrix ADC. 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 transférée à LB1. Aucune rupture de la transaction existante ne se produit avec cette solution ; par conséquent, le maintien du caractère étatique 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 se traduit par un déploiement réussi de la version la plus récente de l’application sans rompre son état d’apatridie.

En raison de la prise en charge de la persistance, les clients peuvent déployer plusieurs contenus ou différentes versions de l’application de manière transparente sans affecter les transactions existantes, en particulier pour les applications avec état. Ce 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 du serveur virtuel de commutation de contenu
October 4, 2021
Contributeur: 
C
October 4, 2021
Contributeur: 
C

Dans cet article

Commentaires sur le site | 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.