day05-haproxy + Keepalived-Cluster Hochverfügbarkeitscluster

day05-haproxy + Keepalived-Cluster Hochverfügbarkeitscluster

Erstens, Haproxy-Übersicht

Eine effiziente, zuverlässige, kostenlose Hochverfügbarkeits- und Lastausgleichssoftware, die sich sehr gut für die siebenschichtige Datenanforderung von Standorten mit hoher Last eignet. Der Client erhält die Standortseite über den Haproxy-Proxyserver, und der Proxyserver leitet die Anforderungsdaten nach Erhalt der Clientanforderung gemäß den Lastausgleichsregeln an den realen Back-End-Server weiter, der ein ereignisgesteuertes Einzelprozessmodell implementiert, das sehr große Parallelität unterstützen kann Anzahl der Verbindungen.

Derselbe Client greift auf den Server zu, und Haproxy verwaltet drei Szenarien für die Sitzung:

1. Haproxy berechnet und speichert den Hash der Client-IP und stellt so sicher, dass dieselbe IP an denselben realen Server weitergeleitet wird.
2. Haproxy stützt sich auf die Cookie-Informationen, die vom realen Server zur Aufbewahrung der Sitzung an den Client gesendet werden.
3. Haproxy speichert die Sitzungs- und Server-ID des realen Servers, um die Sitzungsaufbewahrungsfunktion zu realisieren.

Zweitens, Haproxy-Proxy-Modus

Vierschichtiger TCP-Proxy: Haproxy leitet den Datenverkehr nur in beide Richtungen zwischen dem Client und dem Server weiter und kann für den internen Protokollkommunikationsserver des Mail-Dienstes, des MySQL-Dienstes usw. Verwendet werden.

Siebenschichtiger Anwendungsproxy: Haproxy analysiert das Anwendungsschichtprotokoll und kann das Protokoll steuern, indem der angegebene Inhalt in der Anforderung oder Antwort ausgeführt, abgelehnt, ausgetauscht, hinzugefügt, geändert oder gelöscht wird. Kann für HTTP-Proxy oder https-Proxy verwendet werden.

Schicht 4 Lastausgleich

Der einfachste Weg zum Lastausgleich besteht darin, den Netzwerkverkehr auf mehrere Server zu leiten, um den Lastausgleich der Schicht 4 (Transportschicht) zu verwenden. Diese Methode leitet den Benutzerverkehr entsprechend dem IP-Bereich und dem Port weiter. Alle Server im Web-Backend sollten denselben Inhalt haben, da Benutzer sonst möglicherweise auf Inhaltsinkonsistenzen stoßen.

Siebenschichtiger Lastausgleich

Die Verwendung des 7-Layer-Lastausgleichs für den Netzwerkverkehr bedeutet, dass der Balancer Anforderungen entsprechend dem Anforderungsinhalt des Benutzers an verschiedene Back-End-Server weiterleiten kann. Mit dieser Methode können mehrere Webanwendungsserver auf demselben Domänennamen und Port ausgeführt werden. Es kann eine Lastverteilung basierend auf der "IP + Port" -Methode durchführen und die Lastausgleichsstrategie basierend auf der URL der Website, dem Zugriff auf den Domainnamen, der Browserkategorie, der Sprache usw. bestimmen.

Drei, Haproxy-Lastausgleichsalgorithmus

Es gibt 8 Arten von HaProxy-Lastausgleichsalgorithmen:

• Roundrobin: Umfrage
• static-rr: Gewichtsabfrage
• Leastconn: Der am wenigsten verbundene zuerst
• source: Laut IP der Anforderungsquelle ähnelt dies dem ip_hash-Mechanismus von Nginx
• ri: Gemäß der angeforderten URI
• rl_param: Entsprechend dem angeforderten URI-Parameter erfordert 'balance url_param' einen URL-Parameternamen.
• hdr (Name): Sperren Sie jede HTTP-Anforderung gemäß dem HTTP-Anforderungsheader
• rdp-cookie (name): sperrt und hasht jede TCP-Anfrage gemäß dem Cookie

Viertens die Konfiguration von Haproxy

Der Konfigurationsprozess von Haproxy ist in drei Hauptteile unterteilt:

• Befehlszeilenparameter, dies ist die erste Priorität;

• globaler (globaler) Abschnitt, Parameter auf Prozessebene festlegen;

• Der Proxy-Konfigurationsabschnitt befindet sich normalerweise in der Form Standard, Listen, Backend. Die Syntax der Konfigurationsdatei besteht aus einem Schlüsselwort, gefolgt von einem oder mehreren optionalen Parametern (mit Leerzeichen zwischen den Parametern). Wenn die Zeichenfolge Leerzeichen enthält, muss sie mit '\' maskiert werden.

  Die Haproxy-Konfiguration besteht aus fünf Hauptteilen:

• global: Globale Parameterkonfiguration, Prozessebene, mit der einige Prozesse und Systemeinstellungen vor dem Start von Haproxy gesteuert werden.

• Standardeinstellungen: Konfigurieren Sie einige Standardparameter, die von Frontend-, Backend- und Listen-Segmenten integriert und verwendet werden können.

• Frontend: Wird verwendet, um den vom empfangenden Client angeforderten Domainnamen, die URL usw. abzugleichen und unterschiedliche Anforderungen für unterschiedliche Übereinstimmungen zu verarbeiten.

• Backend: Definieren Sie den Backend-Servercluster und legen Sie einige Gewichte, Warteschlangen, Anzahl der Verbindungen und andere Optionen für den Backend-Servercluster fest, ähnlich dem Upstream-Modul in Nginx.

• listen: Es kann als eine Kombination aus Frontend und Backend verstanden werden.

  Es gibt zwei Möglichkeiten, die Haproxy-Konfigurationsdatei zu konfigurieren: Eine besteht aus Frontend- und Backend-Konfigurationsblöcken, und es können mehrere Frontends und Backends vorhanden sein. Die zweite Methode besteht darin, nur einen Listen-Konfigurationsblock zu haben, um sowohl Front-End als auch Back-End zu erreichen. Die am häufigsten verwendete und empfohlene Methode ist die erste, nämlich der Frontend- und der Backend-Modus.

4.1 Detaillierte Konfigurationsparameter

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 Gesundheitscheck

Als Loadblance unterstützt Haproxy die Integritätsprüfung des Backends, um sicherzustellen, dass die Anforderung vom Frontend anderen Backends zugewiesen wird, die bedient werden können, wenn das Backend nicht bedient werden kann, wodurch die Verfügbarkeit des gesamten Dienstes sichergestellt wird.

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 Erkennungsmethode

4.3.1 Integritätsprüfung über den Überwachungsport

Bei dieser Erkennungsmethode überprüft Haproxy nur den Server-Port und kann nicht garantieren, dass der Dienst wirklich verfügbar ist.

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 Integritätsprüfung über URI

Diese Erkennungsmethode verwendet die GET-Webseite des Back-End-Servers, die im Wesentlichen die Verfügbarkeit des Back-End-Dienstes darstellt.

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 Abgleich mit Header-Informationen, die auf Anfrage zur Erkennung des Zustands erhalten wurden

Diese Erkennungsmethode basiert auf einigen erweiterten und ausgefeilten Überwachungsanforderungen durch übereinstimmende Erkennung der Kopfinformationen, auf die der Back-End-Kopf zugreift.

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

Fünftens installieren Sie Keepalived

Bereiten Sie drei Knoten vor: lb1, lb2, lb3

5.1 lb1 Knoten

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 Knoten

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 Knoten

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
    }
}

Führen Sie die folgenden Befehle auf den Knoten lb0, lb1 und lb2 aus, um Keepalived zu starten

systemctl start keepalived
systemctl enable keepalived

Sechs, installieren Sie HAProxy

Bereiten Sie drei Knoten vor: lb1, lb2, lb3

6.1 lb1 lb2 lb3 Knoten

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  

Führen Sie zum Starten den folgenden Befehl aus:

systemctl start haproxy
systemctl enable haproxy

Sieben, die Realisierung von Tomcat Session Cluster

7.1 So pflegen Sie eine Sitzung

Es gibt verschiedene Lösungen, um eine Sitzungsvereinigung unter dem Clustersystem zu erreichen:

1. Fordern Sie den genauen Speicherort an: sessionsticky, z. B. eine auf der Zugriffs-IP basierende Hash-Strategie, dh die Anforderungen des aktuellen Benutzers konzentrieren sich auf einen Server, sodass ein einzelner Server die Anmeldeinformationen des Benutzers speichert. Wenn diese ausfallen, entspricht dies einem einzelnen Server. Klicken Sie auf Bereitstellen. Es geht verloren und die Sitzung wird nicht kopiert.

2. Sitzungsreplikation und -freigabe: Die Sitzungsreplikation, z. B. die Tomcat-eigene Sitzungsfreigabe, bezieht sich hauptsächlich auf die Synchronisierung von Sitzungen zwischen mehreren Anwendungsservern in einer Clusterumgebung, um Sitzungen konsistent und für die Außenwelt transparent zu halten. Wenn einer der Server gemäß dem Prinzip des Lastausgleichs ausfällt, durchsucht der Scheduler nach verfügbaren Knoten und verteilt Anforderungen. Da die Sitzung synchronisiert ist, kann sichergestellt werden, dass die Sitzungsinformationen des Benutzers nicht verloren gehen und die Sitzung repliziert wird.

Die Mängel dieser Lösung: Sie muss zwischen derselben Art von Middleware erfolgen (z. B. zwischen Tomcat und Tomcat).

Der durch die Sitzungsreplikation verursachte Leistungsverlust steigt schnell an. Insbesondere wenn ein großes Objekt in der Sitzung gespeichert wird und sich das Objekt schnell ändert, ist der Leistungsabfall signifikanter und beeinträchtigt die Systemleistung. Diese Funktion begrenzt die horizontale Erweiterung von Webanwendungen.

Der Sitzungsinhalt wird per Broadcast mit den Mitgliedern synchronisiert, was zu Engpässen im Netzwerkverkehr und sogar zu internen Engpässen im Netzwerk führt. Funktioniert bei großer Parallelität nicht gut

3. Sitzungsfreigabe basierend auf dem Cache-DB-Cache

Sitzungsfreigabe basierend auf Memcache / Redis-Cache

Verwenden Sie also cacheDB, um auf Sitzungsinformationen zuzugreifen. Der Anwendungsserver akzeptiert neue Anforderungen und speichert die Sitzungsinformationen in der Cache-Datenbank. Wenn der Anwendungsserver ausfällt, sucht der Scheduler nach verfügbaren Knoten und verteilt Anforderungen. Wenn der Anwendungsserver feststellt, dass sich die Sitzung nicht im lokalen Speicher befindet Wenn es Zeit ist, gehen Sie zur Cache-Datenbank, um zu suchen, ob gefunden, kopieren Sie auf den lokalen Computer, damit Sitzungsfreigabe und hohe Verfügbarkeit realisiert werden.

7.2 nginx + tomcat + redis realisieren die Sitzungsfreigabe

Gastgeber	Betriebssystem	IP Adresse
Nginx	7,5 Cent	192.168.6.240
Tomcat-1	7,5 Cent	192.168.6.241
Tomcat-1	7,5 Cent	192.168.6.242
Redis	7,5 Cent	192.168.6.243
MySQL	7,5 Cent	192.168.6.244

Kurzbeschreibung der Architekturtopologie:

Als Reverse-Proxy erkennt Nginx die Trennung von statisch und dynamisch und weist zwei Tomcat-Servern nach dem Gewicht zufällig dynamische Kundenanforderungen zu. Redis wird als gemeinsam genutzter Sitzungsdatenserver der beiden Tomcats und MySQL als Back-End-Datenbank der beiden Tomcats verwendet.

7.3 Installation und Konfiguration von Nginx

Verwenden Sie Nginx als Load Balancer für Tomcat, und die Sitzungssitzungsdaten von Tomcat werden in Redis gespeichert, wodurch 7x24-Effekte ohne Ausfallzeiten erzielt werden können. Da die Sitzung in Redis gespeichert ist, muss Nginx nicht so konfiguriert werden, dass es sich an eine bestimmte Tomcat-Methode hält, damit im Hintergrund tatsächlich mehrere Tomcat-Lastausgleiche erzielt werden können.

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 ../

Konfigurieren Sie den Nginx-Reverse-Proxy: Reverse-Proxy + Lastausgleich + Integritätserkennung, Inhalt der Datei 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 Tomcat installieren und bereitstellen

Installieren Sie JDK auf den Knoten Tomcat-1 und 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/

Ändern Sie die Konfigurationsdatei

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

Legen Sie den virtuellen Standardhost fest und erhöhen Sie jvmRoute

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

Ändern Sie den virtuellen Standardhost, verweisen Sie den Pfad der Website-Datei auf / web / webapp1 und fügen Sie im Host-Bereich einen Kontextabschnitt hinzu

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

Erhöhen Sie das Dokumentverzeichnis und die Testdateien

[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>

Die Konfiguration des Tomcat-2-Knotens und des Tomcat-1-Knotens ist grundsätzlich ähnlich, mit der Ausnahme, dass die jvmRoute unterschiedlich ist. Um zu unterscheiden, welcher Knoten Zugriff bietet, unterscheidet sich auch der Titel der Testseite (der von den beiden Tomcat-Servern in der Produktionsumgebung bereitgestellte Webinhalt ist derselbe). Die anderen Konfigurationen sind gleich.

Verwenden Sie einen Browser, um den Nginx-Host zu besuchen und den Lastausgleich zu überprüfen

Um die Integritätsprüfungsmethode zu überprüfen, können Sie einen Tomcat-Host deaktivieren und den Zugriff mithilfe des Client-Browsers testen.

Aus den obigen Ergebnissen können wir ersehen, dass nginx für die beiden Besuche die Besuchsanforderungen an das Back-End Tomcat-1 bzw. Tomcat-2 verteilt. Die Besuchsanforderungen des Clients sind lastausgeglichen, aber die Sitzungs-ID ist dieselbe. An diesem Punkt sind alle Vorbereitungen abgeschlossen. Konfigurieren Sie Tomcat so, dass die Sitzungserhaltung durch Redis erreicht wird.

7.5 Redis installieren (weggelassen)

7.6 Tomcat-Sitzung redis Synchronisation

Laden Sie das TomcatRedisSessionManager- 2.0.zip-Paket über TomcatClusterRedisSessionManager herunter, das den Cluster-Modus von redis3.0 unterstützt https://github.com/ran-jit/tomcat-cluster-redis-session-manager, legen Sie es unter $ TOMCAT_HOMA / lib ab und entpacken Sie es

[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" />

Konfigurieren Sie die Ablaufzeit der Sitzung in ../conf/web.xml

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

Starten Sie den Tomcat-Dienst

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

Der Tomcat-2-Knoten hat dieselbe Konfiguration wie der Tomcat-1-Knoten

Test: Jedes Mal, wenn wir seine Sitzungs-ID zwangsweise aktualisieren, ist dieselbe identisch. Wir sind daher der Meinung, dass die Sitzungsaufbewahrung abgeschlossen ist. Sie können auch die Client-IP-Adresse in test ändern (192.168.6.240/index.jsp).