Ouça você.
E bem-vindo de volta.
Agora, no vídeo de hoje, estaremos discutindo sobre as sessões adesivas.
Agora, antes de prosseguirmos e compreendermos sobre este tópico, vamos analisar um desafio típico.
Agora, geralmente em uma configuração baseada em balanceador de carga, o tráfego dos usuários é distribuído entre vários servidores
backend.
Por exemplo, digamos que um usuário que faz um primeiro pedido, pode ir ao servidor um.
O segundo pedido que ele faz, pode ir para o servidor dois e assim por diante.
Assim, o tráfego é distribuído.
O mesmo vale para o usuário também.
O mesmo vale para o usuário.
Três.
Agora, se uma solicitação subseqüente for encaminhada para servidores diferentes, então a informação da sessão também
será perdida.
Por exemplo, digamos que você está indo a um banco.
Você tem alguns problemas.
Você foi ao banco, você explicou todo o problema a uma pessoa, uma pessoa agora.
A pediu que você venha amanhã para que uma solução apropriada possa ser aplicada.
Agora, você foi amanhã e a pessoa não estava lá.
Então, o que aconteceu?
Agora você foi a uma pessoa.
B, agora a pessoa B não sabe realmente sobre seu problema.
Portanto, mais uma vez, você tem que explicar todo o problema à pessoa B. Portanto, isto é o que realmente acontece na configuração
baseada no balanceador de carga também.
Agora, geralmente para website estático, isso não cria realmente um grande problema porque um website é estático.
Ambos os servidores possuem o mesmo conjunto de páginas para os sites dinâmicos.
Isso realmente se torna um problema.
Agora uma das formas de resolver isto é através da sessão pegajosa.
Então Sticky session refere-se a uma característica de muitos equilibradores de carga para enraizar o pedido de uma determinada
sessão na mesma máquina física que atende o primeiro pedido daquela sessão.
Então, um usuário, um primeiro pedido que ele fez, foi para o servidor.
Agora, solicitação subseqüente para solicitar três solicitações para todas as solicitações que ele fará.
Todas essas solicitações irão para o próprio servidor.
Novamente, tomando um exemplo de um banco, você foi no primeiro dia, você conheceu uma pessoa no segundo dia novamente, você conheceu
uma pessoa no segundo dia novamente, você conheceu uma pessoa A Então você está conhecendo a mesma pessoa no banco e ele sabe de todos
os seus problemas em andamento, bem como de todos os seus problemas passados.
Assim ele será capaz de ajudá-lo de uma maneira muito mais eficiente.
Portanto, é aqui que a sessão pegajosa também entra em cena.
Agora, as sessões pegajosas também são suportadas em lado das balanças de carga.
Portanto, vamos discutir primeiro sobre o balanceador de carga de aplicação.
Portanto, por padrão, a carga da aplicação equilibra cada pedido independentemente para um alvo registrado com base em
um algoritmo de equilíbrio de carga escolhido.
Muito semelhante ao que estávamos discutindo no primeiro slide com o pedido pode primeiro ir para o servidor um, depois
pode ir para o servidor dois e assim por diante.
No entanto, caso seja necessário, você também pode fazer uso de um recurso de sessão pegajosa para permitir que o equilibrador
de carga prenda a sessão de um usuário a um alvo específico.
Agora, se você vê que tem um web browser, um web browser, dois web browser, um faz um pedido, um ou dois são três para
o equilibrador de carga, o equilibrador de carga irá direcionar.
Todas as solicitações são uma ou duas são três para a mesma CE duas instâncias.
Agora esta configuração é aplicável após a sessão adesiva ser ativada.
Caso contrário, o equilibrador de carga poderia direcionar o pedido r um para e.
c2122e.
c2232, e, c23 e assim por diante.
Portanto, vamos fazer uma coisa.
Vamos em frente e analisar o assunto.
Agora, para a configuração de hoje, tenho dois balanceadores de carga disponíveis.
Um é o equilibrador de carga de aplicação e o segundo é o clássico equilibrador de carga e vamos analisar
como podemos permitir sessões pegajosas aqui.
Primeiro, vamos em frente e explorar o balanceador de carga de aplicação.
Agora, nesta fase, você não tem realmente uma sessão pegajosa habilitada.
Vamos em frente e copiar isto.
Agora, antes de prosseguirmos e explorarmos isto, deixe-me também mostrar-lhe as instâncias.
Portanto, há duas CE, duas instâncias que estão rodando Motor X e o equilibrador de carga, tanto o clássico
como a aplicação estão associados a estas duas instâncias C.
Portanto, deixe-me ir em frente e colar o URL do equilibrador de carga da aplicação.
Primeiro, ela foi para a CE duas instâncias, a número dois, que tem um site de classe de página para.
Se eu o atualizasse, iria para o site, o que é fácil de exemplificar.
Um vamos refrescar.
Agora foi para o site dois.
Tão clássico estado de equilíbrio de carga onde múltiplas solicitações são encaminhadas para diferentes servidores, todos juntos.
Agora digamos que realmente não o queremos.
Assim, o que podemos fazer, podemos permitir sessões pegajosas.
No entanto, antes de permitirmos as sessões pegajosas.
Deixe-me mostrar-lhe os cabeçalhos exatos de resposta do HTTP.
Portanto, todos estes são os cabeçalhos de resposta.
Agora vamos anotar e vamos analisar os cabeçalhos de resposta depois que a sessão pegajosa
for ativada.
Portanto, agora dentro do equilibrador de carga, especificamente para a aplicação do equilibrador de carga, vamos
para o grupo alvo que está associado ao nosso ALB.
Há apenas um grupo alvo que está associado.
Vamos em frente e edite os atributos do grupo alvo e você tem uma opção de pegajosidade.
Vamos permitir a aderência.
E agora está pedindo a duração da pegajosidade, que pode ser de um segundo a sete dias.
Você também pode selecionar as coisas de acordo.
Deixe-me dizer que um dia foi pegajoso.
Portanto, eu vou em frente e vou salvar a mudança.
Assim, agora que temos sessões pegajosas, habilitaremos o pedido a um CE específico em duas instâncias apenas durante
a duração de nossa sessão pegajosa.
Vamos em frente e explorar isso.
Portanto, deixe-me atualizar a página.
Vai para o site dois.
Vamos refrescar novamente.
Mais uma vez, site dois, vamos atualizar o site dois pela terceira vez, site dois pela quarta vez e site dois pela
quinta vez.
Então é isto que as sessões pegajosas nos permitem fazer.
Agora, de maneira semelhante, vamos novamente fazer um pedido de chamada.
E agora você vê dentro dos cabeçalhos de resposta entre o primeiro e o segundo.
Uma das coisas adicionais que é adicionada é um cookie.
O nome do cookie é um plus AILBHE e então você tem as informações relacionadas ao cookie.
Assim, uma vez ativadas as sessões adesivas, você também tem que adicionar um cookie.
Agora, o cookie é algo que seu navegador web enviará de volta ao equilibrador de carga.
O equilibrador de carga lerá o cookie e identificará que este usuário foi direcionado para a CE duas instâncias
um.
Assim, uma vez lido o cookie novamente, ele direcionará o usuário para as duas instâncias da própria CE.
Então é assim que o equilibrador de carga sabe que um cliente específico precisa ser direcionado para uma grade de servidores específica.
Agora, quando se trata do balanceador de carga da aplicação, você pode definir a sessão pegajosa no nível
do grupo alvo.
No entanto, para o clássico equilibrador de carga, você pode ir em frente.
E permitir a aderência.
Portanto, atualmente a viscosidade é desativada.
Você pode ir em frente e habilitar a pegajosidade aqui mesmo.
Similar ao equilibrador de carga de aplicação, você pode especificar o período de expiração.
Portanto, vamos rever rapidamente o fluxo de trabalho.
Assim, sempre que um cliente faz um pedido ao equilibrador de carga, o equilibrador de carga criará um cookie.
Portanto, neste caso, o objetivo do cookie é igual a dois um CE.
Assim, o pedido é dirigido ao CE dois um e o cookie é enviado de volta para o cliente.
Agora, quando ele faz o próximo pedido ao equilibrador de carga, o cliente precisa enviar o biscoito que lhe
foi enviado pelo equilibrador de carga.
Depois que o cliente envia de volta o biscoito para o equilibrador de carga.
O equilibrador de carga pode entender que este cookie foi associado ao CE dois, e o segundo pedido
também será enviado ao CE.
Dois um.
Se o cookie não for realmente enviado novamente, ele depende do algoritmo utilizado.
Se o biscoito não for realmente enviado, o equilibrador de carga elástica pode não saber realmente e pode direcionar esse
pedido para as duas instâncias da CE também.
Portanto, este é o fluxo de trabalho de alto nível em uma das formas em que as sessões pegajosas são estabelecidas.
Agora vamos analisar rapidamente as vantagens das sessões pegajosas.
A primeira é que quando as sessões pegajosas são usadas, os servidores não precisam realmente trocar os dados
da sessão, o que pode minimizar a transferência de dados.
Caso contrário, os dados de uma sessão precisam ser trocados entre todos os servidores para que eles possam se lembrar exatamente
o que o usuário tinha vindo buscar.
Em segundo lugar, as sessões pegajosas podem permitir uma melhor utilização de seu cache RAM que pode levar a uma melhor capacidade de resposta.
Agora, vamos também analisar algumas das desvantagens.
A primeira é que com sessões pegajosas, o balanceamento de carga geral do tráfego entre servidores pode ser afetado.
Muito importante.
Parte dois Lembre-se, pode acontecer que um servidor específico possa ser sobrecarregado se ele acumular muitas sessões
ou se sessões específicas pegajosas exigirem um grande número de recursos.
Assim, se dez usuários forem direcionados para a instância EC2, uma sessão pegajosa é ativada por três
dias de duração.
E se todos os dez servidores forem direcionados para o CE dois instância um, no entanto, o CE dois instância dois
está completamente vazio.
Não há sessões ou não há nenhuma conexão.
Então, o que acontecerá agora?
A segunda instância da CE está sobrecarregada porque todos os usuários que tinham o cookie existente são direcionados para
a segunda instância da CE.
Portanto, isto pode ser uma desvantagem das sessões pegajosas.
Ótimo.
Portanto, esta é uma visão geral de alto nível sobre os princípios básicos das sessões pegajosas e com isto concluirá
o vídeo de hoje.