Te escucho.
Y bienvenidos de nuevo.
En el vídeo de hoy hablaremos de las sesiones pegajosas.
Ahora, antes de seguir adelante y entender sobre este tema, echemos un vistazo a un desafío típico.
Ahora, generalmente en una configuración basada en un balanceador de carga, el tráfico de los usuarios se distribuye entre múltiples servidores
backend.
Por ejemplo, supongamos que la primera petición que hace un usuario va al servidor uno.
La segunda petición que haga, podría ir al servidor dos y así sucesivamente.
Así que el tráfico se distribuye.
Lo mismo ocurre con el usuario.
Tres.
Ahora bien, si una solicitud posterior se dirige a servidores totalmente distintos, también se pierde la información
de la sesión.
Por ejemplo, supongamos que va a un banco.
Tienes algunos problemas.
Fuiste al banco, le explicaste todo el problema a una persona, una persona de ahora.
A le ha pedido que venga mañana para poder aplicar una solución adecuada.
Ahora, usted fue mañana y la persona no estaba allí.
¿Qué ha pasado?
Ahora has ido a una persona.
B, ahora la persona B no conoce realmente su problema.
Así que de nuevo, tienes que explicar todo el problema a la persona B Así que esto es lo que realmente sucede en la configuración
basada en el equilibrador de carga también.
Ahora bien, en general, para un sitio web estático, no crea realmente un gran problema porque un sitio web es estático.
Ambos servidores tienen el mismo conjunto de páginas para los sitios web dinámicos.
Realmente se convierte en un problema.
Ahora bien, una de las formas de solucionar esto es mediante la sesión pegajosa.
Sticky session se refiere a una característica de muchos balanceadores de carga para dirigir la solicitud de una sesión en particular
a la misma máquina física que atiende la primera solicitud de esa sesión.
Así que un usuario, una primera solicitud que hizo fue a la del servidor.
Ahora solicitud subsiguiente solicitud a solicitud tres para todas las solicitudes que hará.
Todas esas peticiones irán al servidor uno mismo.
De nuevo, tomando el ejemplo de un banco, fuiste el primer día, te reuniste con la persona A el segundo día, te reuniste con
la persona A el cuarto día, te reuniste con la persona A. Así que te reúnes con la misma persona en el banco y ella conoce
todos tus problemas actuales así como todos tus problemas pasados.
Así podrá ayudarte de forma mucho más eficaz.
Aquí es donde también entra en escena la sesión pegajosa.
Ahora, las sesiones pegajosas también se admiten en el lado de los equilibrios de carga.
Así que hablemos primero del balanceador de carga de aplicaciones.
Por lo tanto, por defecto, la carga de la aplicación equilibra cada solicitud de forma independiente a un objetivo registrado basado
en un algoritmo de equilibrio de carga elegido.
Muy similar a lo que estábamos discutiendo en la primera diapositiva con la solicitud podría ir primero al servidor uno, entonces
podría ir al servidor dos y así sucesivamente.
Sin embargo, en caso de que lo necesite, también puede hacer uso de una función de sesión fija para permitir que el equilibrador
de carga vincule la sesión de un usuario a un destino específico.
Ahora bien, si usted ve que tiene navegador web, un navegador web, dos navegadores web, uno hace una petición, uno o dos
son tres para el equilibrador de carga, equilibrador de carga dirigirá.
Todas las solicitudes son una o dos son tres a la misma instancia CE dos.
Ahora esta configuración es aplicable después de habilitar la sesión pegajosa.
De lo contrario, el equilibrador de carga podría dirigir la petición r uno a e.
c2122e.
c2232, e, c23 y así sucesivamente.
Así que hagamos una cosa.
Vamos a investigarlo.
Ahora para la configuración de hoy, tengo dos balanceadores de carga disponibles.
Uno es el balanceador de carga de aplicaciones y el segundo es el balanceador de carga clásico y veremos cómo
podemos habilitar las sesiones pegajosas aquí.
En primer lugar, vamos a explorar el equilibrador de carga de aplicaciones.
Ahora, en esta etapa no tienes realmente una sesión pegajosa habilitada.
Sigamos adelante y copiemos esto.
Ahora, antes de seguir adelante y explorar esto, permítanme mostrarles también las instancias.
Así que hay dos CE, dos instancias que se están ejecutando Motor X y el equilibrador de carga, tanto el clásico,
así como la aplicación están asociados con estos C dos instancias.
Así que permítanme seguir adelante y pegar la URL de la aplicación equilibrador de carga.
En primer lugar, fue a la instancia de la CE dos, número dos, que tiene una página web de clase a.
Si refresco se fue a la página web uno que es fácil de instancia.
Una vamos a refrescar.
Ahora pasó al sitio web dos.
Así que el estado clásico de equilibrio de carga en el que múltiples solicitudes se enrutan a diferentes servidores todos juntos.
Ahora digamos que en realidad no lo queremos.
Así que lo que podemos hacer, podemos habilitar sesiones pegajosas.
Sin embargo, antes de activar las sesiones pegajosas.
Permítame mostrarle las cabeceras de respuesta exactas de HTTP.
Así que estas son todas las cabeceras de respuesta.
Ahora tomaremos nota de ello y nos fijaremos en las cabeceras de respuesta después de habilitar la sesión
pegajosa.
Así que ahora dentro del balanceador de carga, específicamente para el balanceador de carga de aplicaciones, vamos al
grupo de destino que está asociado con nuestro ALB.
Sólo hay un grupo objetivo asociado.
Vamos a seguir adelante y editar los atributos del grupo objetivo y usted tiene una opción de pegajosidad.
Permitamos la pegajosidad.
Y ahora pide la duración de la adherencia, que puede ser de un segundo a siete días.
También puede seleccionar las cosas en consecuencia.
Permítanme decir pegajosidad de un día.
Así que seguiré adelante y guardaré el cambio.
Así que ahora que tenemos sesiones pegajosas, habilitar la solicitud irá a una específica CE dos instancias sólo para
la duración de nuestra sesión pegajosa.
Vamos a explorar eso.
Así que déjame refrescar la página.
Va a la web dos.
Refresquemos de nuevo.
De nuevo, página web dos, refresquemos tercera vez página web dos, cuarta vez página web dos y quinta vez página
web dos.
Esto es lo que nos permiten hacer las sesiones adhesivas.
Ahora, de forma similar, hagamos de nuevo una petición de llamada.
Y ahora ves en las cabeceras de respuesta entre la primera y la segunda.
Una de las cosas adicionales que se añade es una galleta.
El nombre de la cookie es un más AILBHE y a continuación tiene la información relacionada con la cookie.
Así que una vez que actives las sesiones pegajosas, también tienes que añadir una cookie.
Ahora, la cookie es algo que su navegador web enviará de vuelta al equilibrador de carga.
El balanceador de carga leerá la cookie e identificará que este usuario fue dirigido a la instancia uno de EC
two.
Así, una vez que vuelva a leer la cookie, dirigirá al usuario a la instancia EC dos uno mismo.
Así es como el equilibrador de carga sabe que un cliente específico necesita ser dirigido a una red de servidores específica.
Ahora, cuando se trata del equilibrador de carga de aplicaciones, puede establecer la sesión pegajosa en el nivel de
grupo de destino.
Sin embargo, para el equilibrador de carga clásico, puede seguir adelante.
Y activar la pegajosidad.
Así que actualmente la pegajosidad está desactivada.
Usted puede seguir adelante y habilitar la pegajosidad aquí mismo.
De forma similar al balanceador de carga de aplicaciones, puede especificar el periodo de expiración.
Así que revisemos rápidamente el flujo de trabajo.
Así, cada vez que un cliente realice una petición al equilibrador de carga, éste creará una cookie.
Así que en este caso, el objetivo de los estados cookie es igual a EC dos uno.
Así que la solicitud se dirige a la CE dos uno y la cookie se envía de vuelta al cliente.
Ahora, cuando el cliente realice la siguiente solicitud al equilibrador de carga, deberá enviar la cookie
que le envió el equilibrador de carga.
Después de que el cliente devuelva la cookie al equilibrador de carga.
El equilibrador de carga puede entender que esta cookie se asoció con la CE dos uno, y la segunda solicitud
también se enviará a la CE.
Dos uno.
Si realmente no se vuelve a enviar la cookie, depende del algoritmo utilizado.
Si la cookie no se envía realmente, es posible que el equilibrador de carga elástico no lo sepa y dirija esa
petición también a la instancia EC dos.
Así que este es el flujo de trabajo de alto nivel en una de las formas en que se establecen las sesiones pegajosas.
Veamos ahora las ventajas de las sesiones fijas.
La primera es que cuando se utilizan las sesiones pegajosas, los servidores no necesitan realmente intercambiar los datos
de sesión, lo que puede minimizar la transferencia de datos.
De lo contrario, es necesario intercambiar datos de sesión entre todos los servidores para que puedan recordar qué es exactamente
lo que el usuario había venido a buscar.
En segundo lugar, las sesiones fijas pueden permitir una mejor utilización de la caché de RAM, lo que puede mejorar la capacidad de respuesta.
Veamos también algunas de sus desventajas.
La primera es que con las sesiones pegajosas, el equilibrio de carga global del tráfico entre servidores puede verse afectado.
Muy importante.
Segunda parte Recuerde que puede ocurrir que un servidor concreto se sobrecargue si acumula demasiadas sesiones o
si determinadas sesiones pegajosas requieren un elevado número de recursos.
Por lo tanto, si diez usuarios se dirigen a la instancia EC2, se habilita una, digamos, sesión pegajosa durante
tres días de duración.
Y si todos los diez servidores se dirigen a la instancia uno de EC two, sin embargo, la instancia dos de EC two está
completamente vacía.
No hay sesiones o no hay ninguna conexión.
¿Y ahora qué pasará?
La EC dos instancia uno está sobrecargada porque todos los usuarios que tenían la cookie existente son dirigidos
a la EC dos instancia uno.
Así que esto puede ser una desventaja de las sesiones pegajosas.
Estupendo.
Así que esta es una visión general de muy alto nivel sobre los fundamentos de las sesiones pegajosas y con esto concluirá
el video de hoy.