day05-haproxy + cluster keepalived cluster de alta disponibilidade

day05-haproxy + cluster keepalived cluster de alta disponibilidade

Um, visão geral do Haproxy

Um software eficiente, confiável, gratuito de alta disponibilidade e balanceamento de carga, muito adequado para a solicitação de dados de sete camadas de sites de alta carga. O cliente obtém a página do site por meio do servidor proxy Haproxy, e o servidor proxy encaminha os dados da solicitação para o servidor real back-end de acordo com as regras de balanceamento de carga após receber a solicitação do cliente, que implementa um modelo de processo único orientado por eventos que pode suportar uma concorrência muito grande Número de conexões.

O mesmo cliente acessa o servidor, e Haproxy mantém três cenários para a sessão:

1. O Haproxy calcula e salva o Hash do ip do cliente, garantindo assim que o mesmo IP seja encaminhado para o mesmo servidor real.
2. O Haproxy depende das informações do cookie enviadas pelo servidor real ao cliente para retenção da sessão.
3. Haproxy salva a sessão e a identificação do servidor do servidor real para realizar a função de retenção da sessão.

Dois, modo proxy Haproxy

Proxy Tcp de quatro camadas: o Haproxy somente encaminha o tráfego em ambas as direções entre o cliente e o servidor, e pode ser usado para o servidor de comunicação de protocolo interno do serviço de e-mail, serviço Mysql, etc .;

Proxy de aplicação de sete camadas: Haproxy irá analisar o protocolo da camada de aplicação e pode controlar o protocolo executando, rejeitando, trocando, adicionando, modificando ou excluindo o conteúdo especificado na solicitação ou resposta. Pode ser usado para proxy HTTP ou proxy https.

Balanceamento de carga da camada 4

A maneira mais simples de balanceamento de carga é direcionar o tráfego de rede para vários servidores para usar o balanceamento de carga da Camada 4 (camada de transporte). Este método encaminhará o tráfego do usuário de acordo com o intervalo de IP e porta. Todos os servidores no back-end da web devem ter o mesmo conteúdo, caso contrário, os usuários podem encontrar inconsistência de conteúdo.

Balanceamento de carga de sete camadas

O uso de balanceamento de carga de 7 camadas para tráfego de rede significa que o balanceador pode encaminhar solicitações para diferentes servidores back-end de acordo com o conteúdo da solicitação do usuário. Este método permite que vários servidores de aplicativos da Web sejam executados no mesmo nome de domínio e porta. Ele pode realizar a distribuição de carga de acordo com o método "IP + porta", e também pode determinar a estratégia de balanceamento de carga de acordo com a URL do site, nome de domínio de acesso, categoria do navegador, idioma, etc.

Três, algoritmo de balanceamento de carga Haproxy

Existem 8 tipos de algoritmos de balanceamento de carga HaProxy, como segue:

• roundrobin: poll
• static-rr: pesquisa de peso
• leastconn: o menos conectado primeiro
• source: de acordo com o IP de origem da solicitação, é semelhante ao mecanismo ip_hash do Nginx
• ri: De acordo com o URI solicitado
• rl_param: De acordo com o parâmetro URI solicitado, 'balance url_param' requer um nome de parâmetro de URL;
• hdr (nome): bloqueia todas as solicitações HTTP de acordo com o cabeçalho da solicitação HTTP
• rdp-cookie (nome): bloqueia e hash cada solicitação TCP de acordo com o cookie

Quarto, a configuração do Haproxy

O processo de configuração do Haproxy é dividido em 3 partes principais:

• Parâmetros da linha de comando, esta é a primeira prioridade;

• seção global (global), definir parâmetros de nível de processo;

• A seção de configuração de proxy geralmente está localizada na forma de padrão, escuta, back-end. A sintaxe do arquivo de configuração consiste em uma palavra-chave seguida por um ou mais parâmetros opcionais (com espaços entre os parâmetros). Se a string contiver espaços, deve ser escapado com '\'.

  Existem cinco partes principais na configuração Haproxy:

• global: configuração de parâmetro global, nível de processo, usado para controlar alguns processos e configurações do sistema antes de iniciar o Haproxy.

• defaults: Configure alguns parâmetros padrão, que podem ser integrados e usados ​​por segmentos de front-end, back-end e escuta.

• frontend: usado para combinar o nome de domínio, uri, etc. solicitado pelo cliente receptor e processar diferentes solicitações para diferentes correspondências.

• backend: Defina o cluster de servidor de backend e defina alguns pesos, filas, número de conexões e outras opções para o cluster de servidor de backend, semelhante ao módulo upstream no nginx.

• listen: Pode ser entendido como uma combinação de front-end e back-end.

  Existem duas maneiras principais de configurar o arquivo de configuração do Haproxy: uma é composta de blocos de configuração de front-end e back-end e pode haver vários front-ends e back-ends. O segundo método é ter apenas um bloco de configuração de escuta para obter front-end e back-end. O método mais comumente usado e recomendado é o primeiro, ou seja, os modos front-end e back-end.

4.1 Parâmetros de configuração detalhados

global                                       # 全局参数global模块的设置
   log         127.0.0.1 local2              # log语法：log <address_1>[max_level_1] 
   # 全局的日志配置，使用log关键字，指定使用127.0.0.1上的syslog服务中的local0日志设备，记录日志等级为info的日志
   chroot      /var/lib/haproxy              #工作目录
   pidfile     /var/run/haproxy.pid          #进程pid文件
   maxconn     4000                          #最大连接数
   user        haproxy                       #所属用户
   group       haproxy                       #所属用户组
   daemon                                    #以守护进程方式运行haproxy
stats socket /var/lib/haproxy/stats          #定义socket套接字，针对在线维护很有帮助

defaults                                     # defaults模块的设置
   mode                    http              #默认的模式{ tcp|http|health},health只会返回OK
   log                     global            #应用全局的日志配置
   option                  httplog           #启用日志记录HTTP请求，默认不记录HTTP请求日志                                                                
   option                 dontlognull        # 启用该项，日志中将不会记录空连接。所谓空连接就是在上游的负载均衡器者监控系统为了探测该 服务是否存活可用时，需要定期的连接或者获取某一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；官方文档中标注，如果该服务上游没有其他的负载均衡器的话，建议不要使用该参数，因为互联网上的恶意扫描或其他动作就不会被记录下来
   option http-server-close                  #每次请求完毕后主动关闭http通道
   option forwardfor       except 127.0.0.0/8   #如果服务器上的应用程序想记录发起请求的客户端的IP地址，需要在HAProxy上配置此选项， 这样 HAProxy会把客户端的IP信息发送给服务器，在HTTP请求中添加"X-Forwarded-For"字段。启用 X-Forwarded-For，在requests头部插入客户端IP发送给后端的server，使后端server获取到客户端的真实IP。
   option                  redispatch       # 当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性；而此时，如果后端的服务器宕掉了， 但是客户端的cookie是不会刷新的，如果设置此参数，将会将客户的请求强制定向到另外一个后端server上，以保证服务的正常。
   retries                 3               # 定义连接后端服务器的失败重连次数，连接失败次数超过此值后将会将对应后端服务器标记为不可用
   timeout http-request    10s             #http请求超时时间
   timeout queue           1m              #一个请求在队列里的超时时间
   timeout connect         10s             #连接超时
   timeout client          1m              #客户端超时
   timeout server          1m              #服务器端超时
   timeout http-keep-alive 10s             #设置http-keep-alive的超时时间
   timeout check           10s             #检测超时
maxconn                 3000            #每个进程可用的最大连接数

listen stats                            #定义一个listen模块，用于状态检测
mode http                               #模式采用http
bind 0.0.0.0:8888                       #绑定本机的地址及端口
stats enable                            #启用状态检测功能
stats uri     /haproxy-status           #状态检测的URI
stats auth    haproxy:123456            #访问检测界面的用户名和密码

frontend  main *:80                     #frontend模块的设置，定义了一个前端
   acl url_static       path_beg       -i /static /images /javascript /stylesheets
   acl url_static       path_end       -i .jpg .gif .png .css .js      #这里定义了一个acl规则
   use_backend static   if  url_static   #如果匹配到了acl，则访问后端的static模块
default_backend             my_webserver #如果没有匹配到acl，则将请求丢给默认的模块

backend static                          #定义第一个后端模块，static
   balance     roundrobin               #负载均衡算法为轮询
server      static 127.0.0.1:80 check         #后端服务器地址

backend my_webserver                    #定第二个后端，my_wenserver
balance     roundrobin              #负载均衡算法
   server  web01 172.31.2.33:80  check inter 2000 fall 3 weight 30  #定义的多个后端
   server  web02 172.31.2.34:80  check inter 2000 fall 3 weight 30  #定义的多个后端
   server  web03 172.31.2.35:80  check inter 2000 fall 3 weight 30  #定义的多个后端

4.2 Verificação de saúde

Como Loadblance, o Haproxy oferece suporte à verificação de integridade do back-end para garantir que, quando o back-end não puder ser atendido, a solicitação do front-end seja alocada para outros back-ends que podem ser atendidos, garantindo assim a disponibilidade do serviço geral.

httpchk <method><uri><version>
option httpchk HEAD / HTTP/1.0
check：启动健康检测
inter：健康检测时间间隔
rise：检测服务可用的连接次数
fall：检测服务不可用的连接次数
error-limit：往server写数据连续失败次数的上限，执行on-error的设定
observe<mode>：把正常服务过程作为健康检测请求，即实时检测
on-error<mode>：满足error-limit后执行的操作（fastinter、fail-check、sudden-death、mark-down）。其中：
fastinter表示立即按照fastinter的检测延时进行；
fail-check表示改次error作为一次检测；
sudden-death表示模仿一次fatal，如果紧接着一次fail则server为down；
mark-down表示直接把server设置为down状态。

4.3 Método de detecção

4.3.1 Verificação de saúde através da porta de escuta

Nesse método de detecção, o haproxy só verifica a porta do servidor e não pode garantir que o serviço esteja realmente disponível.

listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2

4.3.2 Verificação de saúde via URI

Esse método de detecção usa a página da Web GET do servidor back-end, que basicamente representa a disponibilidade do serviço back-end.

listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk GET /index.html
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2

4.3.3 Correspondência com informações de cabeçalho obtidas por solicitação de detecção de saúde

Este método de detecção é baseado em alguns requisitos de monitoramento avançados e sofisticados, por meio da detecção de correspondência das informações do cabeçote acessadas pelo cabeçote de back-end.

listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk HEAD /index.jsp HTTP/1.1\r\n\Host:\www.xxx.com
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2

Five, instale Keepalived

Prepare três nós: lb1, lb2, lb3

Nó 5,1 lb1

yum install -y keepalived

vi /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     [email protected]          #接收人邮箱地址
   }
   notification_email_from [email protected] #发送人邮箱
   smtp_server 127.0.0.1            #邮箱服务器
   smtp_connect_timeout 30
   router_id lb1                    #主机名,每个节点不同
   vrrp_mcast_group4 224.0.100.100  #vrrp_strict  注释，不然严格遵守vvrp，访问不了vip

}

vrrp_instance VI_1 {
    state MASTER                     #主服务器
    interface ens160                #VIP 漂移到的网卡
    virtual_router_id 51            #多个节点必须相同
    priority 100                    #优先级，备服务器比这个低
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csdc456csdc
    }
    virtual_ipaddress {
        192.168.88.201/24           #vip
    }
}

5,2 lb2 nó

yum install -y keepalived

vi /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     [email protected]              #接收人邮箱地址
   }
   notification_email_from [email protected] #发送人邮箱
   smtp_server 127.0.0.1                #邮箱服务器
   smtp_connect_timeout 30
   router_id lb2                        #主机名,每个节点不同
   vrrp_mcast_group4 224.0.100.100      #vrrp_strict  注释，不然严格遵守vvrp，访问不了vip

}

vrrp_instance VI_1 {
    state BACKUP                        #备服务器
    interface ens160                    #VIP 漂移到的网卡
    virtual_router_id 51                #多个节点必须相同
    priority 90                         #优先级，备服务器比这个低
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csdc456csdc
    }
    virtual_ipaddress {
        192.168.88.201/24               #vip
    }
}

5,3 lb3 nó

yum install -y keepalived

vi /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     [email protected]                  #接收人邮箱地址
   }
   notification_email_from [email protected] #发送人邮箱
   smtp_server 127.0.0.1                    #邮箱服务器
   smtp_connect_timeout 30
   router_id lb3                            #主机名,每个节点不同
   vrrp_mcast_group4 224.0.100.100          #vrrp_strict  注释，不然严格遵守vvrp，访问不了vip

}

vrrp_instance VI_1 {
    state BACKUP                            #备服务器
    interface ens160                        #VIP 漂移到的网卡
    virtual_router_id 51                    #多个节点必须相同
    priority 80                             #优先级，备服务器比这个低
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass csdc456csdc
    }
    virtual_ipaddress {
        192.168.88.201/24                   #vip
    }
}

Execute os seguintes comandos nos nós lb0, lb1 e lb2 para iniciar o Keepalived

systemctl start keepalived
systemctl enable keepalived

Seis, instale o HAProxy

Prepare três nós: lb1, lb2, lb3

Nó de 6,1 lb1 lb2 lb3

yum install haproxy -y

vi /etc/haproxy/haproxy.cfg
#--------------------------------------------------------------------- 
# Example configuration for a possible web application.  See the       
# full configuration options online.                                   
#                                                                      
#   http://haproxy.1wt.eu/download/1.4/doc/configuration.txt           
#                                                                      
#--------------------------------------------------------------------- 

#--------------------------------------------------------------------- 
# Global settings                                                      
#--------------------------------------------------------------------- 
global                                                                 
    # to have these messages end up in /var/log/haproxy.log you will   
    # need to:                                                         
    #                                                                  
    # 1) configure syslog to accept network log events.  This is done  
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in           
    #    /etc/sysconfig/syslog                                         
    #                                                                  
    # 2) configure local2 events to go to the /var/log/haproxy.log     
    #   file. A line like the following can be added to                
    #   /etc/sysconfig/syslog                                          
    #                                                                  
    #    local2.*                       /var/log/haproxy.log           
    #                                                                  
    log         127.0.0.1 local2                                       

    chroot      /var/lib/haproxy                                       
    pidfile     /var/run/haproxy.pid                                   
    maxconn     4000                                                   
    user        haproxy                                                
    group       haproxy                                                
    daemon                                                             

    # turn on stats unix socket                                        
    stats socket /var/lib/haproxy/stats                                

#--------------------------------------------------------------------- 
# common defaults that all the 'listen' and 'backend' sections will    
# use if not designated in their block                                 
#--------------------------------------------------------------------- 
defaults                                                               
    mode                    tcp                                        
    log                     global                                     
    option                  httplog                                    
    option                  dontlognull                                
    option http-server-close                                           
    option forwardfor       except 127.0.0.0/8                         
    option                  redispatch                                 
    retries                 3                                          
    timeout http-request    10s                                        
    timeout queue           1m                                         
    timeout connect         10s                                        
    timeout client          1m                                         
    timeout server          1m                                         
    timeout http-keep-alive 10s                                        
    timeout check           10s                                        
    maxconn                 3000                                       

#--------------------------------------------------------------------- 
# main frontend which proxys to the backends                           
#--------------------------------------------------------------------- 
frontend  kubernetes                                                   
    bind *:6443                                                        
    mode tcp                                                           
    default_backend             kubernetes-master                      

#--------------------------------------------------------------------- 
# round robin balancing between the various backends                   
#--------------------------------------------------------------------- 
backend kubernetes-master                                              
    balance     roundrobin                                             
    server  master1 192.168.88.97:6443 check maxconn 2000              
    server  master2 192.168.88.98:6443 check maxconn 2000              
    server  master3 192.168.88.99:6443 check maxconn 2000  

Execute o seguinte comando para iniciar:

systemctl start haproxy
systemctl enable haproxy

Sete, a realização do cluster de sessão tomcat

7.1 Como manter uma sessão

Existem várias soluções para alcançar a unificação de sessão no sistema de cluster:

1. Solicitar localização precisa: sessionsticky, por exemplo, uma estratégia de hash baseada no ip de acesso, ou seja, as solicitações do usuário atual são concentradas em um servidor, de modo que um único servidor salva as informações de login da sessão do usuário. Se cair, equivale a um único servidor. Clique em Implementar, ele será perdido e a sessão não será copiada.

2. Replicação e compartilhamento de sessão: a replicação de sessão, como o compartilhamento de sessão do próprio tomcat, refere-se principalmente à sincronização de sessões entre vários servidores de aplicativos em um ambiente de cluster para manter as sessões consistentes e transparentes para o mundo externo. Se um dos servidores falhar, de acordo com o princípio do balanceamento de carga, o agendador irá percorrer para encontrar os nós disponíveis e distribuir as solicitações. Como a sessão está sincronizada, ele pode garantir que as informações da sessão do usuário não sejam perdidas e a sessão seja replicada.

As deficiências desta solução: deve ser feito entre o mesmo tipo de middleware (como: entre tomcat-tomcat).

A perda de desempenho causada pela replicação da sessão aumentará rapidamente, especialmente quando um objeto grande é salvo na sessão e o objeto muda rapidamente, a degradação do desempenho será mais significativa e consumirá o desempenho do sistema. Este recurso limita a expansão horizontal de aplicativos da web.

O conteúdo da sessão é sincronizado com os membros por meio de transmissão, o que causará gargalos de tráfego de rede, até mesmo gargalos de rede internos. Não funciona bem sob grande concorrência

3. Compartilhamento de sessão baseado em cache DB cache

Compartilhamento de sessão baseado em cache memcache / redis

Ou seja, use o cacheDB para acessar as informações da sessão, o servidor de aplicativos aceita novas solicitações e salva as informações da sessão no banco de dados do cache. Quando o servidor de aplicativos falha, o planejador percorre para localizar os nós disponíveis e distribuir os pedidos. Quando o servidor de aplicativos descobre que a sessão não está na memória local Quando chegar a hora, vá ao banco de dados do cache para pesquisar, se encontrado, copie para a máquina local, para que o compartilhamento de sessão e a alta disponibilidade sejam realizados.

7.2 nginx + tomcat + redis realizar compartilhamento de sessão

Hospedeiro	sistema operacional	endereço de IP
Nginx	7,5 centavos	192.168.6.240
Tomcat-1	7,5 centavos	192.168.6.241
Tomcat-1	7,5 centavos	192.168.6.242
Redis	7,5 centavos	192.168.6.243
MySQL	7,5 centavos	192.168.6.244

Breve descrição da topologia da arquitetura:

Como um proxy reverso, o Nginx realiza a separação de estático e dinâmico e atribui solicitações dinâmicas do cliente aleatoriamente a dois servidores Tomcat de acordo com o peso. Redis é usado como o servidor de dados de sessão compartilhada dos dois Tomcats e o MySQL é usado como o banco de dados back-end dos dois Tomcats.

7.3 Instalação e configuração do nginx

Use o Nginx como balanceador de carga do Tomcat, e os dados da sessão do Tomcat são armazenados no Redis, que pode atingir efeitos 7x24 com tempo de inatividade zero. Como a sessão é armazenada no Redis, o Nginx não precisa ser configurado para seguir um determinado método do Tomcat, para que possa realmente atingir vários balanceamento de carga do Tomcat em segundo plano.

yum install pcre pcre-devel -y 
yum install openssl openssl-devel -y
mkdir -p /home/oldboy/tools
cd /home/oldboy/tools/
wget -q http://nginx.org/download/nginx-1.6.2.tar.gz
useradd nginx -s /sbin/nologin -M
mkdir /application/
tar xf nginx-1.6.2.tar.gz 
cd nginx-1.6.2
./configure --user=nginx --group=nginx --prefix=/application/nginx1.6.2 --with-http_stub_status_module --with-http_ssl_module --with-http_realip_module
echo $?
make && make install
echo $?
ln -s /application/nginx1.6.2/ /application/nginx
cd ../

Configure o proxy reverso nginx: proxy reverso + balanceamento de carga + detecção de integridade, conteúdo do arquivo nginx.conf:

[root@linux-node1 ~]# cat /application/nginx/conf/nginx.conf
worker_processes  4;
events {
        worker_connections  1024;
}
    http {
        include       mime.types;
        default_type  application/octet-stream;
        sendfile        on;
        keepalive_timeout  65;
        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_forwarded_for"';

    #blog lb by oldboy at 201303
        upstream backend_tomcat {
        #ip_hash;
        server 192.168.6.241:8080   weight=1 max_fails=2 fail_timeout=10s;
        server 192.168.6.242:8080   weight=1 max_fails=2 fail_timeout=10s;
        #server 192.168.6.243:8080   weight=1 max_fails=2 fail_timeout=10s;
        }

        server {
            listen       80;
            server_name  www.98yz.cn;
            charset utf-8;
            location / {
                root html;
                index  index.jsp index.html index.htm;
                    }
            location ~* \.(jsp|do)$ {
            proxy_pass  http://backend_tomcat;
            proxy_redirect off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
                }
        }

    }

7.4 Instalar e implantar o tomcat

Instale o JDK nos nós tomcat-1 e tomcat-2

[root@linux-node2 ~]# yum install java -y
[root@linux-node2 ~]# java -version
openjdk version "1.8.0_201"
OpenJDK Runtime Environment (build 1.8.0_201-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)

[root@linux-node2 ~]# mkdir /soft/src -p
[root@linux-node2 ~]# cd /soft/src
[root@linux-node2 ~]# wget https://mirrors.aliyun.com/apache/tomcat/tomcat-9/v9.0.16/bin/apache-tomcat-9.0.16.tar.gz
[root@linux-node2 ~]# tar xf apache-tomcat-9.0.16.tar.gz -C /soft
[root@linux-node2 ~]# cd ..
[root@linux-node2 ~]# cp -r apache-tomcat-9.0.16/ tomcat-8080
[root@linux-node2 soft]# cd tomcat-8080/

Modifique o arquivo de configuração

[root@linux-node2 tomcat-8080]# vim conf/server.xml

Defina o host virtual padrão e aumente jvmRoute

<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat-1">

Modifique o host virtual padrão e aponte o caminho do arquivo do site para / web / webapp1 e adicione uma seção de contexto na seção de host

<Host name="localhost"  appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Context docBase="/web/webapp1" path="" reloadable="true"/>
</Host>

Aumente o diretório do documento e os arquivos de teste

[root@linux-node2 ~]# mkdir -p /web/webapp1
[root@linux-node2 ~]# cd /web/webapp1
[root@linux-node2 webapp1]# cat index.jsp 
<%@page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<html>
    <head>
        <title>tomcat-1</title>
    </head>
    <body>
        <h1><font color="red">Session serviced by tomcat</font></h1>
        <table aligh="center" border="1">
        <tr>
            <td>Session ID</td>
            <td><%=session.getId() %></td>
                <% session.setAttribute("abc","abc");%>
            </tr>
            <tr>
            <td>Created on</td>
            <td><%= session.getCreationTime() %></td>
            </tr>
        </table>
    tomcat-1
    </body>
<html>

A configuração do nó Tomcat-2 e do nó tomcat-1 são basicamente semelhantes, exceto que o jvmRoute é diferente. Além disso, para distinguir qual nó fornece acesso, o título da página de teste também é diferente (o conteúdo da web fornecido pelos dois servidores tomcat no ambiente de produção é o mesmo). As outras configurações são iguais.

Use um navegador para visitar o host nginx, verifique o equilíbrio de carga

Para verificar o método de verificação de saúde, você pode desligar um host tomcat e usar o navegador do cliente para testar o acesso.

A partir dos resultados acima, podemos ver que para as duas visitas, o nginx distribui as solicitações de acesso para o back-end tomcat-1 e tomcat-2, respectivamente. As solicitações de acesso do cliente têm balanceamento de carga, mas o id de sessão é o mesmo. Então, neste ponto, nossos preparativos estão todos concluídos, vamos configurar o tomcat para obter retenção de sessão por meio do redis.

7.5 Instalar redis (omitido)

7.6 sincronização redis da sessão do tomcat

Baixe o pacote TomcatRedisSessionManager-2.0.zip por meio de TomcatClusterRedisSessionManager, que oferece suporte ao modo cluster de redis3.0 https://github.com/ran-jit/tomcat-cluster-redis-session-manager, coloque-o em $ TOMCAT_HOMA / lib e descompacte-o

[root@linux-node2 ]# cd /soft/tomcat-8080/lib/
[root@linux-node2 lib]# wget https://github.com/ran-jit/tomcat-cluster-redis-session-manager/releases/download/2.0.4/tomcat-cluster-redis-session-manager.zip
[root@linux-node2 lib]# unzip tomcat-cluster-redis-session-manager.zip 
Archive:  tomcat-cluster-redis-session-manager.zip
   creating: tomcat-cluster-redis-session-manager/conf/
  inflating: tomcat-cluster-redis-session-manager/conf/redis-data-cache.properties  
   creating: tomcat-cluster-redis-session-manager/lib/
  inflating: tomcat-cluster-redis-session-manager/lib/commons-logging-1.2.jar  
  inflating: tomcat-cluster-redis-session-manager/lib/commons-pool2-2.4.2.jar  
  inflating: tomcat-cluster-redis-session-manager/lib/jedis-2.9.0.jar  
  inflating: tomcat-cluster-redis-session-manager/lib/tomcat-cluster-redis-session-manager-2.0.4.jar  
  inflating: tomcat-cluster-redis-session-manager/readMe.txt 
[root@linux-node4 lib]# cp tomcat-cluster-redis-session-manager/lib/* ./
[root@linux-node4 lib]# cp tomcat-cluster-redis-session-manager/conf/redis-data-cache.properties ../conf/

[root@linux-node2 lib]# cat ../conf/redis-data-cache.properties     
#-- Redis data-cache configuration
//远端redis数据库的地址和端口
#- redis hosts ex: 127.0.0.1:6379, 127.0.0.2:6379, 127.0.0.2:6380, ....
redis.hosts=192.168.6.244:6379
//远端redis数据库的连接密码
#- redis password (for stand-alone mode)
redis.password=pwd@123
//是否支持集群，默认的是关闭
#- set true to enable redis cluster mode
redis.cluster.enabled=false
//连接redis的那个库
#- redis database (default 0)
#redis.database=0
//连接超时时间
#- redis connection timeout (default 2000)
#redis.timeout=2000

//在这个<Context>标签里面配置
[root@linux-node4 lib]# vim ../conf/context.xml
<Valve className="tomcat.request.session.redis.SessionHandlerValve" />
<Manager className="tomcat.request.session.redis.SessionManager" />

Configure o tempo de expiração da sessão em ../conf/web.xml

<session-config>
<session-timeout>60</session-timeout>
</session-config>

Iniciar serviço tomcat

[root@linux-node2 lib]# ../bin/startup.sh

O nó Tomcat-2 tem a mesma configuração que o nó tomcat-1

Teste, toda vez que atualizamos à força seu ID de sessão é o mesmo, então pensamos que sua retenção de sessão foi concluída, você também pode escolher alterar o endereço IP do cliente para testar (192.168.6.240/index.jsp)