Persistance de session d'équilibreur de charge
Utilisez la persistance des sessions avec un équilibreur de charge pour diriger toutes les demandes provenant d'un seul client logique vers un seul serveur Web back-end.
La persistance de session est une méthode permettant d'acheminer toutes les demandes provenant d'un même client logique vers le même serveur Web back-end. Les serveurs back-end qui utilisent la mise en cache pour améliorer les performances, ou pour activer des sessions de connexion ou des paniers, peuvent bénéficier de la persistance de session.
Vous pouvez activer la persistance de session lorsque vous créez un équilibreur de charge ou un ensemble de back-ends. Vous pouvez également modifier un ensemble de back-ends existant pour activer, désactiver ou modifier la configuration de la persistance de session.
Cookies persistants
Le service Load Balancer offre deux configurations basées sur un cookie et mutuellement exclusives pour l'activation de la persistance de session :
Persistance de session basée sur une adresse IP
Certains produits proposent une prise en charge de la persistance de session sans cookie. Ces produits se basent sur l'adresse IP de la demande entrante. Les proxies des fournisseurs de service Internet et les passerelles de sortie des entreprises peuvent émettre plusieurs demandes à partir d'une même adresse IP. Dans ce cas, un important trafic de données peut être acheminé vers un même serveur back-end. Votre parc de back-ends peut ainsi se retrouver saturée, un serveur à la fois, même lorsque vous avez les moyens d'assurer un équilibrage de charge efficace.
Un autre défaut de la persistance de session basée sur l'adresse IP est que l'adresse IP d'origine est susceptible d'être modifiée. Auquel cas, la persistance de session peut être perdue ou la demande peut être réacheminée vers le mauvais serveur back-end.
Affectation de cookie d'application
Pour configurer la persistance de session de cookie d'application, indiquez le nom du cookie et choisissez de désactiver ou non le basculement pour les serveurs non disponibles.
Le service Load Balancer active les persistances de session des cookies d'application (affectation) lorsqu'un serveur back-end envoie un en-tête Set-Cookie de réponse contenant un nom de cookie reconnu. Le nom du cookie doit correspondre au nom indiqué dans la configuration de l'ensemble de back-ends. Si la configuration indique un modèle de correspondance générique "*", n'importe quel cookie défini par le serveur active la persistance de session. Si le serveur back-end n'active pas la persistance de session, le service suit la stratégie d'équilibrage de charge indiquée lors de la création de l'équilibreur de charge.
Conditions requises :
- L'équilibreur de charge doit fonctionner en mode HTTP pour prendre en charge la persistance de session côté serveur basée sur un cookie.
- L'ordinateur client doit accepter les cookies pour que la fonctionnalité de persistance de session de Load Balancer puisse fonctionner.
Le service Load Balancer calcule un hachage du cookie configuré et d'autres paramètres de demande, puis envoie cette valeur au client dans un cookie. La valeur stockée dans le cookie permet le service d'acheminer les demandes client ultérieures vers le serveur back-end approprié. Si vos serveurs back-end modifient les cookies définis, le service recalcule la valeur du cookie et la renvoie au client.
Nous vous recommandons de traiter les données de cookie comme une entité opaque. Ne l'utilisez pas dans vos applications.
Le serveur back-end peut mettre fin à la persistance de cookie d'application en supprimant le cookie de persistance de session. Si vous utilisez le modèle générique, tous les cookies doivent être supprimés. Vous pouvez supprimer des cookies en envoyant un en-tête de réponse Set-Cookie qui comporte une date d'expiration passée. Le service Load Balancer achemine les demandes suivantes à l'aide de la stratégie d'équilibrage de charge configurée.
Affectation de cookie d'équilibreur de charge
Lorsque vous configurez l'affectation d'un cookie d'équilibreur de charge, l'équilibreur de charge insère un cookie dans la réponse. L'affectation de session est activée par les paramètres configurés au sein du cookie. Cette méthode est utile lorsque des applications et des services Web back-end ne peuvent générer leurs propres cookies.
Pour configurer la persistance de session de cookie d'équilibreur de charge, vous devez indiquer les éléments suivants :
- Nom de cookie.
Si vous n'indiquez aucune valeur de cookie, le nom par défaut est
X-Oracle-BMC-LBS-Route.Remarque
Assurez-vous que le nom des cookies utilisés dans les serveurs d'application back-end est différent du nom des cookies utilisés dans l'équilibreur de charge. Pour réduire les risques de conflit de noms, nous vous recommandons d'utiliser un préfixe tel queX-Oracle-OCI-.Si un serveur back-end et l'équilibreur de charge insèrent des cookies portant le même nom, le comportement du client ou du navigateur peut varier en fonction de la valeur de domaine associée au cookie. Si les valeurs de nom et de domaine de l'en-tête
Set-cookie(généré par un serveur back-end) sont identiques à celles de l'en-têteSet-cookie(généré par l'équilibreur de charge), le client ou le navigateur les considère comme un même cookie. Le client ne renvoie qu'une seule des valeurs du cookie dans les demandes ultérieures. Si les deux noms deSet-cookiesont identiques, mais que les noms de domaine sont différents, le client ou le navigateur les considère comme deux cookies différents. - Domaine dans lequel le cookie est valide. L'en-tête
Set-cookieinséré par l'équilibreur de charge contient un attribut de domaine ayant la valeur spécifiée.Cet attribut n'a pas de valeur par défaut. Si vous n'indiquez pas de valeur, l'équilibreur de charge n'insère aucune valeur dans l'en-tête
Set-cookie.Remarque
- La norme 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 de l'en-tête
Set-cookie.Si la valeur de l'attribut
Domainestexample.comdans l'en-têteSet-cookie, le client inclut le même cookie dans l'en-têteCookielorsqu'il effectue des demandes HTTP versexample.com,www.example.cometwww.abc.example.com. Si l'attributDomainn'est pas présent, le client renvoie le cookie uniquement pour le domaine auquel la demande d'origine a été adressée. - Assurez-vous que cet attribut indique la valeur de domaine correcte. Si l'attribut
Domaindans l'en-têteSet-cookien'inclut pas le domaine auquel la demande d'origine a été sollicitée, le client ou Le navigateur peut rejeter le cookie. Conformément à la norme RFC 6265, le client accepte un cookie comportant la valeur d'attributDomainexample.comouwww.example.comenvoyée à partir dewww.example.com. Il n'accepte pas le cookie comportant l'attributDomainabc.example.comouwww.abc.example.comqui sont envoyés à partir dewww.example.com.
- La norme 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 de l'en-tête
- Chemin d'URI dans lequel le cookie est valide. L'en-tête
Set-cookieinséré par l'équilibreur de charge contient un attributPathayant la valeur spécifiée.Les clients incluent le cookie dans une demande HTTP uniquement si la partie chemin de
request-uricorrespond à l'attributPathdu cookie ou à un sous-répertoire de ce dernier.La valeur par défaut est "/".
- Durée pendant laquelle le cookie reste valide. L'en-tête
Set-cookieinséré par l'équilibreur de charge contient un attributMax-Ageayant la valeur spécifiée.La valeur spécifiée doit être d'au moins une seconde. Il n'existe pas de valeur par défaut pour cet attribut. Si vous n'indiquez aucune 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 cookie jusqu'à ce que la session en cours se termine, comme indiqué par le client. - Présence ou absence de l'attribut
Securedans l'en-têteSet-cookie. L'attributSecureindique au client ou au navigateur qu'il doit envoyer le cookie uniquement via un protocole sécurisé.Remarque
Si vous définissez ce champ avec la valeur True, vous ne pouvez plus associer l'ensemble de back-ends correspondant aux processus d'écoute HTTP.
- Présence ou absence de l'attribut
HttpOnlydans l'en-têteSet-cookie. L'attributHttpOnlylimite la portée du cookie aux demandes HTTP. Cet attribut indique au client ou au navigateur qu'il doit omettre le cookie lorsqu'il fournit l'accès à des cookies via des API non HTTP. Par exemple, il empêche le cookie d'être communiqué sur les canaux JavaScript. - Activation ou désactivation du basculement pour les serveurs non disponibles.
Les règles de routage par chemin sont prioritaires pour décider du serveur back-end cible. L'équilibreur de charge vérifie que l'affectation de session est activée pour le serveur back-end et que la configuration de cookie est valide pour la cible. Le système ignore les cookies non valides.
Basculement
Par défaut, le service Load Balancer achemine le trafic d'un client de session persistante vers un autre serveur back-end lorsque le serveur d'origine n'est pas disponible. Vous pouvez configurer l'ensemble de back-ends de sorte à désactiver ce comportement de basculement. Lorsque vous désactivez le basculement, l'équilibreur de charge ne peut pas traiter la demande et renvoie un code HTTP 502. Le service continue à renvoyer le code HTTP 502 jusqu'à ce que le client ne contienne plus de cookie de session persistante.
Si la date d'expiration est lointaine, les cookies dont la date d'expiration est lointaine peuvent entraîner une coupure du client.
Le service Load Balancer considère un serveur marqué comme drain 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.