Je vous écoute.
Et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons parler des sessions collantes.
Avant d'aller plus loin et de comprendre ce sujet, examinons un défi typique.
En général, dans une configuration basée sur un équilibreur de charge, le trafic des utilisateurs est réparti entre plusieurs serveurs
dorsaux.
Par exemple, disons que la première requête d'un utilisateur est envoyée au serveur 1.
La deuxième demande qu'il fait, elle peut aller au serveur deux et ainsi de suite.
Le trafic est donc distribué.
Il en va de même pour l'utilisateur.
Trois.
Or, si les demandes suivantes sont acheminées vers des serveurs différents, les informations de session sont également
perdues.
Par exemple, disons que vous vous rendez dans une banque.
Vous avez des problèmes.
Vous êtes allé à la banque, vous avez expliqué tout le problème à une personne, une personne maintenant.
A vous a demandé de venir demain afin qu'une solution appropriée puisse être appliquée.
Maintenant, vous y êtes allé demain et la personne n'était pas là.
Alors, que s'est-il passé ?
Vous êtes maintenant allé vers une personne.
B, maintenant la personne B ne connaît pas vraiment votre problème.
Donc, une fois de plus, vous devez expliquer l'ensemble du problème à la personne B. C'est donc ce qui se passe réellement dans la configuration
basée sur un équilibreur de charge.
En général, pour les sites web statiques, cela ne pose pas vraiment de problème, car un site web est statique.
Les deux serveurs ont le même ensemble de pages pour les sites dynamiques.
Cela devient vraiment un problème.
L'une des façons de résoudre ce problème est de recourir à la séance de collage.
Sticky session fait donc référence à une fonctionnalité de nombreux équilibreurs de charge qui permet d'attribuer la demande d'une session
particulière à la même machine physique qui a traité la première demande de cette session.
Donc un utilisateur, la première requête qu'il fait va au serveur.
Maintenant, demande suivante demande à demande trois demande pour toutes les demandes qu'il fera.
Toutes ces demandes iront au serveur un lui-même.
Encore une fois, en prenant l'exemple d'une banque, vous êtes allé un jour, vous avez rencontré la personne A ; le deuxième jour, vous avez
rencontré la personne A ; le troisième jour, vous avez rencontré la personne A. Vous rencontrez donc la même personne dans la banque
et elle connaît tous vos problèmes actuels ainsi que tous vos problèmes passés.
Il sera donc en mesure de vous aider de manière beaucoup plus efficace.
C'est donc ici que la séance de collage entre en jeu.
Désormais, les sessions collantes sont également prises en charge du côté des équilibres de charge.
Parlons d'abord de l'équilibreur de charge d'application.
Ainsi, par défaut, l'application répartit la charge de chaque demande indépendamment vers une cible enregistrée, sur la base
d'un algorithme de répartition de la charge choisi.
C'est très similaire à ce que nous avons discuté dans la première diapositive avec la demande qui pourrait d'abord aller
au serveur un, puis au serveur deux et ainsi de suite.
Toutefois, en cas de besoin, vous pouvez également utiliser une fonction de session collante pour permettre à l'équilibreur
de charge de lier la session d'un utilisateur à une cible spécifique.
Maintenant, si vous voyez que vous avez un navigateur web, un navigateur web, deux navigateurs web, un fait une demande, un ou deux
sont trois à l'équilibreur de charge, l'équilibreur de charge va diriger.
Toutes les demandes sont une ou deux sont trois à la même instance CE deux.
Maintenant, cette configuration est applicable après que la session collante soit activée.
Sinon, l'équilibreur de charge pourrait diriger la demande r un vers e.
c2122e.
c2232, e, c23 et ainsi de suite.
Alors faisons une chose.
Allons-y et examinons la question.
Pour la configuration d'aujourd'hui, j'ai deux équilibreurs de charge disponibles.
L'un est l'équilibreur de charge d'application et le second est l'équilibreur de charge classique et nous allons voir comment
nous pouvons activer les sessions collantes ici.
Tout d'abord, allons-y et explorons l'équilibreur de charge d'application.
À ce stade, vous n'avez pas vraiment activé la session collante.
Allons-y et copions ça.
Maintenant, avant d'aller plus loin et d'explorer cela, laissez-moi aussi vous montrer les instances.
Il y a donc deux EC, deux instances qui exécutent le moteur X et l'équilibreur de charge, tant le classique
que l'application sont associés à ces deux instances.
Donc, laissez-moi aller de l'avant et coller l'URL de l'équilibreur de charge d'application.
D'abord, il est allé à l'instance EC deux, numéro deux, qui a une page site web de classe à.
Si je rafraîchis la page, je me retrouve sur le site web qui est facile à consulter.
Rafraîchissons-nous un peu.
Maintenant, il est passé au site web 2.
Il s'agit donc de l'état classique de l'équilibrage de la charge, où les demandes multiples sont acheminées vers des serveurs différents tous ensemble.
Disons maintenant que nous ne le voulons pas vraiment.
Donc ce que nous pouvons faire, nous pouvons activer les sessions collantes.
Cependant, avant d'activer les sessions collantes.
Laissez-moi vous montrer les en-têtes de réponse exactes de HTTP.
Voici donc tous les en-têtes de réponse.
Maintenant, nous allons en prendre note et nous examinerons les en-têtes de réponse après l'activation de la
session collante.
Maintenant, dans l'équilibreur de charge, plus précisément pour l'équilibreur de charge d'application,
allons au groupe cible associé à notre ALB.
Il n'y a qu'un seul groupe cible qui est associé.
Continuons et modifions les attributs du groupe cible et vous avez une option d'adhérence.
Permettons l'adhérence.
Et maintenant, il demande la durée d'adhérence, qui peut aller d'une seconde à sept jours.
Vous pouvez également sélectionner les choses en conséquence.
Permettez-moi de dire que c'est un jour d'adhérence.
Donc je vais aller de l'avant et je vais enregistrer le changement.
Maintenant que nous avons des sessions collantes, la demande sera envoyée à deux instances EC spécifiques uniquement
pour la durée de notre session collante.
Allons-y et explorons cela.
Alors laissez-moi rafraîchir la page.
Il y aura deux sites web.
Rafraîchissons-nous encore.
Encore une fois, le site web deux, rafraîchissons une troisième fois le site web deux, une quatrième fois le site web deux et une cinquième fois
le site web deux.
C'est donc ce que les sessions collantes nous permettent de faire.
Maintenant, de la même manière, faisons à nouveau une demande d'appel.
Et maintenant vous voyez dans les en-têtes de réponse entre le premier et le second.
Une des choses supplémentaires qui est ajoutée est un cookie.
Le nom du cookie est un plus AILBHE et ensuite vous avez les informations relatives au cookie.
Donc, une fois que vous avez activé les sessions collantes, vous devez également ajouter un cookie.
Maintenant, le cookie est quelque chose que votre navigateur web va renvoyer à l'équilibreur de charge.
L'équilibreur de charge lira le cookie et identifiera que cet utilisateur a été dirigé vers l'instance EC two
one.
Ainsi, lorsqu'il lira à nouveau le cookie, il dirigera lui-même l'utilisateur vers l'EC two instance one.
C'est ainsi que l'équilibreur de charge sait qu'un client spécifique doit être dirigé vers une grille de serveurs spécifique.
Maintenant, lorsqu'il s'agit de l'équilibreur de charge d'application, vous pouvez définir la session collante au niveau
du groupe cible.
Cependant, pour l'équilibreur de charge classique, vous pouvez aller de l'avant.
Et permettre le collage.
Donc, actuellement, l'adhérence est désactivée.
Vous pouvez aller de l'avant et activer l'adhérence ici même.
Comme pour l'équilibreur de charge d'application, vous pouvez spécifier la période d'expiration.
Donc, révisons rapidement le flux de travail.
Ainsi, chaque fois qu'un client fait une demande à l'équilibreur de charge, ce dernier crée un cookie.
Donc dans ce cas, le cookie indique que la cible est égale à EC deux un.
La demande est donc dirigée vers le EC two one et le cookie est renvoyé au client.
Maintenant, lorsqu'il fait sa prochaine demande à l'équilibreur de charge, le client doit envoyer le cookie qui
lui a été envoyé par l'équilibreur de charge.
Après que le client ait renvoyé le cookie à l'équilibreur de charge.
L'équilibreur de charge peut comprendre que ce cookie a été associé à l'EC deux un, et la deuxième demande
sera également envoyée à l'EC.
Deux un.
Si le cookie n'est pas vraiment renvoyé, cela dépend de l'algorithme utilisé.
Si le cookie n'est pas réellement envoyé, l'équilibreur de charge élastique pourrait ne pas le savoir et diriger cette
demande vers l'instance EC two également.
Il s'agit donc d'un flux de travail de haut niveau sur l'une des façons dont les sessions collantes sont établies.
Examinons maintenant rapidement les avantages des sessions collantes.
La première est que lorsque les sessions collantes sont utilisées, les serveurs n'ont pas vraiment besoin d'échanger les
données de session, ce qui peut minimiser le transfert de données.
Dans le cas contraire, des données de session doivent être échangées entre tous les serveurs afin qu'ils puissent se souvenir de ce que l'utilisateur
était venu chercher exactement.
Deuxièmement, les sessions adhésives permettent une meilleure utilisation de la mémoire cache de votre RAM, ce qui peut conduire à une meilleure réactivité.
Maintenant, examinons également certains de ses inconvénients.
La première est qu'avec les sessions collantes, l'équilibrage global de la charge du trafic entre les serveurs peut être affecté.
Très important.
Deuxième partie N'oubliez pas qu'il peut arriver qu'un serveur spécifique soit surchargé s'il accumule trop de sessions ou
si des sessions collantes spécifiques nécessitent un nombre élevé de ressources.
Ainsi, si dix utilisateurs sont dirigés vers l'instance EC2, une session, disons collante, est activée pour une
durée de trois jours.
Et si les dix serveurs sont dirigés vers l'instance un de l'EC deux, l'instance deux de l'EC deux
est complètement vide.
Il n'y a pas de sessions ou il n'y a pas de connexions du tout.
Alors maintenant, que va-t-il se passer ?
Le CE deux instance un est surchargé car tous les utilisateurs qui avaient le cookie existant sont dirigés vers
le CE deux instance un.
Cela peut donc être un inconvénient des sessions collantes.
Super.
Il s'agit donc d'une vue d'ensemble de très haut niveau sur les principes de base des sessions adhésives, ce qui conclura la vidéo
d'aujourd'hui.