Persistance de session de l'équilibreur de charge
Utilisez la persistance de session avec un équilibreur de charge pour diriger toutes les demandes provenant d'un seul client logique vers un seul serveur Web dorsal.
La persistance de session est une méthode qui consiste à diriger toutes les demandes provenant d'un seul client logique vers un seul serveur Web dorsal. Les serveurs dorsaux qui utilisent la mise en mémoire cache pour améliorer la performance ou pour activer des sessions de connexion ou des paniers, peuvent tirer parti de la persistance de session.
Vous activez la persistance de session lors de la création d'un équilibreur de charge ou lors de la création d'un jeu dorsal. Vous pouvez également modifier un jeu dorsal existant pour activer, désactiver ou modifier la configuration de persistance de session.
Témoins persistants
Le service Équilibreur de charge offre deux configurations mutuellement exclusives basées sur des témoins pour l'activation de la persistance de session :
Persistance de session orientée adresse IP
Certains produits offrent une prise en charge de la persistance de session sans témoin. Ces produits dépendent de l'adresse IP de la demande entrante. Les mandataires de fournisseur de service Internet et les passerelles de sortie d'entreprise peuvent émettre de nombreuses demandes à partir d'une seule adresse IP. Dans ce cas, un seul serveur dorsal peut être soumis à des volumes de trafic importants. Même s'il est possible d'équilibrer efficacement la charge, chaque serveur du parc dorsal pourrait, tout à tour, être surchargé.
Une autre faiblesse de la persistance de session orientée adresse IP est que l'adresse IP d'origine peut changer. Dans ce cas, la persistance de session peut être perdue ou la demande redirigée vers un serveur dorsal incorrect.
Persistance des témoins d'application
Pour configurer la persistance de session des témoins d'application, vous spécifiez un nom de témoin et décidez s'il faut ou non désactiver le traitement de secours pour les serveurs non disponibles.
Le service Équilibreur de charge active la conservation de session des témoins d'application lorsqu'un serveur dorsal envoie un en-tête de réponse Set-Cookie contenant un nom de témoin reconnu. Le nom du témoin doit correspondre au nom indiqué dans la configuration du jeu dorsal. Si la configuration spécifie un modèle de correspondance globale, '*', tout témoin défini par le serveur active la persistance de session. Le service suit la politique d'équilibrage de charge spécifiée lors de la création de l'équilibreur de charge, sauf si un serveur dorsal active la persistance de session.
Exigences :
- Votre équilibreur de charge doit fonctionner en mode HTTP pour prendre en charge la persistance de session côté serveur basée sur des témoins.
- L'ordinateur client doit accepter les témoins pour que la fonction de persistance de session du service Équilibreur de charge fonctionne.
Le service Équilibreur de charge calcule un hachage du témoin configuré et d'autres paramètres de demande, et envoie cette valeur au client dans un témoin. La valeur stockée dans le témoin permet au service d'acheminer les demandes de client ultérieures vers le serveur dorsal correct. Si vos serveurs dorsaux modifient l'un des témoins définis, le service recalcule la valeur du témoin et la renvoie au client.
Nous vous recommandons de traiter les données de témoin comme une entité opaque. Ne l'utilisez pas dans vos applications.
Le serveur dorsal peut arrêter la persistance de témoin d'application en supprimant le témoin de persistance de session. Si vous avez utilisé le modèle de correspondance globale, il doit supprimer tous les témoins. Vous pouvez supprimer les témoins en envoyant un en-tête de réponse Set-Cookie avec une date d'expiration passée. Le service d'équilibreur de charge achemine les demandes ultérieures à l'aide de la politique d'équilibrage de charge configurée.
Persistance des témoins d'équilibreur de charge
Lorsque vous configurez la persistance des témoins d'équilibreur de charge, l'équilibreur de charge insère un témoin dans la réponse. Les paramètres configurés dans le témoin activent la persistance de session. Cette méthode s'applique lorsque vous disposez d'applications et de services Web dorsaux qui ne peuvent pas générer leurs propres témoins.
Pour configurer la persistance de session des témoins de l'équilibreur de charge, vous spécifiez :
- Le nom du témoin.
Si vous ne spécifiez pas de nom de témoin, le nom par défaut est
X-Oracle-BMC-LBS-Route.Note
Assurez-vous que le nom de témoin utilisé dans les serveurs d'applications dorsaux est différent du nom de témoin utilisé dans l'équilibreur de charge. Pour éviter la collision de nom, nous vous recommandons d'utiliser un préfixe tel queX-Oracle-OCI-.Si un serveur dorsal et l'équilibreur de charge insèrent des témoins portant le même nom, le comportement du client ou du navigateur peut varier en fonction de la valeur du domaine associé au témoin. Si les valeurs de nom et de domaine de l'en-tête
Set-cookie(générées par un serveur dorsal) et si celles de l'en-têteSet-cookie(générées par l'équilibreur de charge) sont identiques, le client ou le navigateur les traite comme un seul témoin. Le client ne retourne qu'une des valeurs de témoin dans les demandes ultérieures. Si les deux nomsSet-cookiesont identiques, mais que les noms de domaine sont différents, le client ou le navigateur les traite comme deux témoins différents. - Le domaine dans lequel le témoin est valide. L'en-tête
Set-cookieinséré par l'équilibreur de charge contient un attribut de domaine avec la valeur spécifiée.Cet attribut n'a pas de valeur par défaut. Si vous ne spécifiez pas de valeur, l'équilibreur de charge n'insère pas l'attribut de domaine dans l'en-tête
Set-cookie.Note
- La RFC 6265 - Mécanisme de gestion d'état HTTP décrit le comportement du client et du navigateur lorsque l'attribut de domaine est présent ou absent dans l'en-tête
Set-cookie.Si la valeur de l'attribut
Domainestexample.comdans l'en-têteSet-cookie, le client insère le même témoin dans l'en-têteCookielorsqu'il soumet des demandes HTTP pourexample.com,www.example.cometwww.abc.example.com. Si l'attributDomainn'est pas présent, le client retourne le témoin uniquement pour le domaine pour lequel la demande initiale a été soumise. - Assurez-vous que cet attribut indique la valeur de domaine correcte. Si l'attribut
Domaindans l'en-têteSet-cookien'inclut pas le domaine pour lequel la demande initiale a été soumise, le client ou le navigateur peut rejeter le témoin. Comme spécifié dans la RFC 6265, le client accepte un témoin avec la valeur d'attributDomainexample.comouwww.example.comenvoyée à partir dewww.example.com. Il n'accepte pas un témoin avec l'attributDomainabc.example.comouwww.abc.example.comenvoyé depuiswww.example.com.
- La RFC 6265 - Mécanisme de gestion d'état HTTP décrit le comportement du client et du navigateur lorsque l'attribut de domaine est présent ou absent dans l'en-tête
- Le chemin de l'URI dans lequel le témoin est valide. L'en-tête
Set-cookieinséré par l'équilibreur de charge contient un attributPathavec la valeur spécifiée.Les clients incluent le témoin dans une demande HTTP uniquement si la partie du chemin
request-uricorrespond à, ou est un sous-répertoire de, l'attributPathdu témoin.La valeur par défaut est `/`.
- La durée de validité du témoin. L'en-tête
Set-cookieinséré par l'équilibreur de charge contient un attributMax-Ageavec la valeur spécifiée.La valeur spécifiée doit être d'au moins une seconde. Il n'existe aucune valeur par défaut pour cet attribut. Si vous ne spécifiez pas de valeur, l'équilibreur de charge n'inclut pas l'attribut
Max-Agedans l'en-têteSet-cookie. En général, le client ou le navigateur conserve le témoin jusqu'à la fin de la session courante, qui est définie par le client. - S'il faut que l'en-tête
Set-cookiecontienne ou non l'attributSecure. L'attributSecureindique au client ou au navigateur de n'envoyer le témoin qu'au moyen d'un protocole sécurisé.Note
Si vous réglez ce champ à Vrai, vous ne pouvez pas associer le jeu dorsal correspondant à un module d'écoute HTTP.
- S'il faut que l'en-tête
Set-cookiecontienne ou non l'attributHttpOnly. L'attributHttpOnlylimite la portée du témoin aux demandes HTTP. Cet attribut indique au client ou au navigateur d'omettre le témoin lorsque l'accès aux témoins est fourni au moyen d'API non HTTP. Par exemple, il restreint le témoin pour les canaux JavaScript. - S'il faut désactiver le traitement de secours pour les serveurs non disponibles.
Les règles d'itinéraire de chemin d'accès sont prioritaires pour déterminer le serveur dorsal cible. L'équilibreur de charge vérifie que la persistance de session est activée pour le serveur dorsal et que la configuration des témoins est valide pour la cible. Le système ignore les témoins non valides.
Traitement de secours
Par défaut, le service Équilibreur de charge dirige le trafic d'un client de session persistante vers un autre serveur dorsal lorsque le serveur initial n'est pas disponible. Vous pouvez configurer le jeu dorsal pour désactiver ce comportement de secours. Lorsque vous désactivez le traitement de secours, l'équilibreur de charge place la demande en échec et retourne un code HTTP 502. Le service continue de retourner une erreur HTTP 502 jusqu'à ce que le client ne présente plus de témoin de persistance de session.
Si le traitement de secours est désactivé, les témoins avec une date d'expiration future éloignée peuvent provoquer une interruption du client.
Le service Équilibreur de charge considère qu'un serveur marqué en tant que drain est disponible pour les sessions persistantes existantes. Les nouvelles demandes qui ne font pas partie d'une session persistante existante ne sont pas envoyées à ce serveur.