Nginx負載均衡高可用---架構

1. Nginx負載均衡高可用

首先介紹一下Keepalived，它是一個高性能的服務器高可用或熱備解決方案，Keepalived主要來防止服務器單點故障的發生問題，能夠經過其與Nginx的配合實現web服務端的高可用。

Keepalived以VRRP協議爲實現基礎，用VRRP協議來實現高可用性（HA）.VRRP (Virtual Router Redundancy Protocol)協議是用於實現路由器冗餘的協議，VRRP協議將兩臺或多臺路由器設備虛擬成一個設備，對外提供虛擬路由器IP（一個或多個），以下圖所示：

這張圖的意思是，咱們使用keepalived來管理兩臺設備的Nginx，並虛擬出一個IP，咱們如今兩臺裝有Nginx的設備分別是192.168.101.3和192.168.101.4，那麼咱們能夠虛擬出一個192.168.156.xx的IP，外界請求直接訪問虛擬IP而不是真正的Nginx，讓虛擬IP去訪問提供服務的Nginx（注意：高可用是指同一時間提供服務的只有一臺設備，提供服務的設備掛掉以後，備份服務器便開始提供服務），而後再由Nginx去訪問tomcat。

要實現nginx的高可用，須要實現備份機。

咱們拿兩臺虛擬機來搭建nginx高可用環境，這兩臺設備分別是192.168.101.3（主機名是nginx1）和192.168.101.4（主機名是nginx2）。

1.1. 什麼是負載均衡高可用

nginx做爲負載均衡器，全部請求都到了nginx（對外服務的惟一入口，惟一公網IP），可見nginx處於很是重點的位置，若是nginx服務器宕機後端web服務將沒法提供服務，影響嚴重。

爲了屏蔽負載均衡服務器的宕機，須要創建一個備份機。主服務器和備份機上都運行高可用（High Availability）監控程序，經過傳送諸如「I am alive」這樣的信息來監控對方的運行情況。當備份機不能在必定的時間內收到這樣的信息時，它就接管主服務器的服務IP並繼續提供負載均衡服務；當備份管理器又從主管理器收到「I am alive」這樣的信息時，它就釋放服務IP地址，這樣的主服務器就開始再次提供負載均衡服務。

1.2. keepalived+nginx實現主備

一般說的雙機熱備是指兩臺機器都在運行，但並非兩臺機器都同時在提供服務。

當提供服務的一臺出現故障的時候，另一臺會立刻自動接管而且提供服務，並且切換的時間很是短。

1.2.1. 什麼是keepalived

keepalived是集羣管理中保證集羣高可用的一個服務軟件，用來防止單點故障。

Keepalived的做用是檢測web服務器的狀態（健康監測），若是有一臺web服務器死機，或工做出現故障，Keepalived將檢測到，並將有故障的web服務器從系統中剔除，當web服務器工做正常後Keepalived自動將web服務器加入到服務器羣中，這些工做所有自動完成，不須要人工干涉，須要人工作的只是修復故障的web服務器。

1.2.2. keepalived工做原理

keepalived是以VRRP協議爲實現基礎的，VRRP全稱Virtual Router Redundancy Protocol，即虛擬路由冗餘協議。

虛擬路由冗餘協議，能夠認爲是實現路由器高可用的協議，即將N臺提供相同功能的路由器組成一個路由器組，這個組裏面有一個master和多個backup，master上面有一個對外提供服務的vip（VIP = Virtual IP Address，虛擬IP地址，該路由器所在局域網內其餘機器的默認路由爲該vip），master會發組播，當backup收不到VRRP包時就認爲master宕掉了，這時就須要根據VRRP的優先級來選舉一個backup當master。這樣的話就能夠保證路由器的高可用了。

keepalived主要有三個模塊，分別是core、check和VRRP。core模塊爲keepalived的核心，負責主進程的啓動、維護以及全局配置文件的加載和解析。check負責健康檢查，包括常見的各類檢查方式。VRRP模塊是來實現VRRP協議的。

詳細參考：Keepalived權威指南中文.pdf

1.2.3. keepalived+nginx實現主備過程

nginx和keepalived實現nginx高可用：

https://blog.csdn.net/u012453843/article/details/69668663

1.2.3.1. 初始狀態：

初始時候，nginx主服務器正常，將vip綁定到自身，對外提供服務，從服務器始終與主服務器保持通訊，監測主服務器的健康狀態。

1.2.3.2. 主機宕機：

當nginx主服務器宕機或發生異常，總之以任何理由形成服務器上的健康監測程序發生異常，沒法和從服務器上的健康監測程序通訊，此時從服務器上的健康監測機制就會認爲主服務器掛了，從而將vip綁定到自身，成功上位，充當主服務器的角色。

1.2.3.3. 主機恢復：

在keepalive機制中，主服務器終究是主服務器，一旦主服務器恢復，邊重新綁定vip，繼續充當主服務器，而從服務器又成爲了熱備。

1.2.4. 高可用環境

兩臺nginx，一主一備：192.168.101.3和192.168.101.4

兩臺tomcat服務器：192.168.101.五、192.168.101.6

1.2.5. 安裝keepalived

一、分別在主備nginx上安裝keepalived，參考「安裝筆記」進行安裝：

二、Keepalived安裝與配置：

https://blog.csdn.net/xyang81/article/details/52554398

1.2.6. 配置keepalived

修改主和備nginx服務器上的keepalived 配置文件 /etc/keepalived/keepalived.conf 文件

1.2.6.1. 主nginx

修改主nginx下/etc/keepalived/keepalived.conf文件

! Configuration File for keepalived  #全局配置 global_defs { notification_email { #指定keepalived在發生切換時須要發送email 到的對象，一行一個 XXX@XXX.com } notification_email_ from XXX@XXX.com #指定發件人 #smtp_ server XXX. smtp.com #指定smtp服務器地址 #smtp _connect_timeout 30 #指定smtp鏈接超時時間 router_ id LVS_DEVEL #運行 keepalived機器的一個標識 }  vrrp_instance VI_1 {  state MASTER #標示狀態爲MASTER 備份機爲BACKUP interface eth0 #設置實例綁定的網卡 virtual_ router_id 51 #同一實例下virtual_router_id必須相同 priority 100 #MASTER權重要高於BACKUP 好比BACKUP爲99  advert_ int 1 #MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位是秒 authentication { #設置認證 auth_type PASS #主從服務器驗證方式 auth_pass 8888 } virtual_ipaddress { #設置vip 192.168.101.100 #能夠多個虛擬IP，換行便可 } }

1.2.6.2. 備nginx

修改備nginx下 /etc/keepalived /keepalived.conf文件

配置備nginx時須要注意：須要修改state爲BACKUP , priority比MASTER低，virtual_router_id和master的值一致

! Configuration File for keepalived  #全局配置 global_defs { notification_email { #指定keepalived在發生切換時須要發送email到的對象，一行一個 XXX@XXX.com } notification_email_ from XXX@XXX.com #指定發件人 #smtp_server XXX. smtp.com #指定smtp服務器地址 #smtp_connect_ timeout 30 #指定smtp鏈接超時時間 router_id LVS_ DEVEL #運行keepalived機器的一個標識 }  vrrp_instance VI_1 {  state BACKUP #標示狀態爲MASTER 備份機爲BACKUP interface eth0 #設置實例綁定的網卡 virtual_router_id 51 #同一實例下virtual_router_id必須相同 priority 99 #MASTER權重要高於BACKUP 好比BACKUP爲99  advert_int 1 #MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位是秒 authentication { #設置認證 auth_type PASS #主從服務器驗證方式 auth_pass 8888 } virtual_ipaddress { #設置vip 192.168.101.100 #能夠多個虛擬IP，換行便可 } }

1.2.7. 測試

主備nginx都啓動keepalived及nginx。

service keepalived start

./nginx

1.2.7.1. 初始狀態

查看主nginx的eth0設置：

vip綁定在主nginx的eth0上。

查看備nginx的eth0設置：

vip沒有綁定在備nginx的eth0上。

訪問ccc.test.com，能夠訪問。

1.2.7.2. 主機宕機

將主nginx的keepalived中止或將主nginx關機(至關於模擬宕機)，查看主nginx的eth0：

eth0沒有綁定vip

注意這裏模擬的是中止 keepalived進程沒有模擬宕機，因此還要將nginx進程也中止表示主nginx服務沒法提供。

查看備nginx的eth0：

vip已經漂移到備nginx。

訪問ccc.test.com，能夠訪問。

1.2.7.3. 主機恢復

將主nginx的keepalived和nginx都啓動。

查看主nginx的eth0：

查看備nginx的eth0：

vip漂移到主nginx。

查看備nginx的eth0：

eth0沒有綁定vip

訪問：ccc.test.com，正常訪問。

注意：主nginx恢復時必定要將nginx也啓動（一般nginx啓動要加在開機啓動中），不然即便vip漂移到主nginx也沒法訪問。

1.2.8. 解決nginx進程和keepalived不一樣時存在問題

1.2.8.1. 問題描述

keepalived是經過檢測keepalived進程是否存在判斷服務器是否宕機，若是keepalived進程在可是nginx進程不在了那麼keepalived是不會作主備切換，因此咱們須要寫個腳原本監控nginx進程是否存在，若是nginx不存在就將keepalived進程殺掉。

1.2.1.2. nginx進程檢測腳本

在主nginx上須要編寫nginx進程檢測腳本（check_nginx.sh），判斷nginx進程是否存在，若是nginx不存在嘗試重啓nginx，若沒法啓動，就將keepalived進程殺掉，check_nginx.sh內容以下：

#!/bin/sh # 若是進程中沒有nginx，嘗試重啓nginx進程，若仍是沒有，則將keepalived進程kill掉、 A=`ps -C nginx --no-header |wc -l` ## 查看是否有nginx進程 把值賦給變量A  if [ $A -eq 0 ];then  /usr/local/nginx/sbin/nginx　　　　## 重啓nginx進程  sleep 2　　　　　　　　　　　　　　　　## 等待時間 if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then　　## 仍是沒有nginx進程  killall keepalived　　　　　　　## 殺掉keepalived fi fi

將check_nginx.sh拷貝至/etc/keepalived下，

腳本測試：

將nginx中止，將keepalived啓動，執行腳本：sh /etc/keepalived/check_nginx.sh

從執行能夠看出自動將keepalived進程kill掉了。

1.2.8.3. 修改keepalived.conf

修改主nginx的keepalived.conf，添加腳本定義檢測：參考keepalived之vrrp_script詳解；

注意下邊紅色標識地方：

#全局配置  global_defs {  notification_email { #指定keepalived在發生切換時須要發送email到的對象，一行一個  XXX@XXX.com  }  notification_email_from miaoruntu@itcast.cn #指定發件人  #smtp_server XXX.smtp.com #指定smtp服務器地址  #smtp_connect_timeout 30 #指定smtp鏈接超時時間  router_id LVS_DEVEL #運行keepalived機器的一個標識  } ## keepalived會定時執行腳本並對腳本執行的結果進行分析,動態調整vrrp_instance的優先級。  ##若是腳本執行結果爲0,而且weight配置的值大於0,則優先級相應的增長。若是腳本執行結果非0,  ##而且weight配置的值小於 0,則優先級相應的減小。其餘狀況,維持本來配置的優先級,即配置文件中priority對應的值。 vrrp_script check_nginx {  script "/etc/keepalived/check_nginx.sh" ##監控腳本  interval 2 ##時間間隔，2秒  weight -20 ##權重  }  vrrp_instance VI_1 {  state MASTER #標示狀態爲MASTER 備份機爲BACKUP  interface eth0 #設置實例綁定的網卡  virtual_router_id 51 #同一實例下virtual_router_id必須相同  priority 100 #MASTER權重要高於BACKUP 好比BACKUP爲80  advert_int 1 #MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位是秒  authentication { #設置認證  auth_type PASS #主從服務器驗證方式  auth_pass 8888  }  track_script {  check_nginx #監控腳本  }  virtual_ipaddress { #設置vip  192.168.101.100 #能夠多個虛擬IP，換行便可  }  }

修改後重啓keepalived

接着看下面這段配置，這段配置的意思是，每隔2秒中去執行/etc /keepalived /nginx_check.sh 腳本一次，這項檢查從開始便一直進行，interval表示間隔時間，weight -20的意思是，腳本執行成功後把當前節點的優先級下降20。

vrrp_script chk_nginx { script "/etc/keepalived/nginx_check.sh" interval 2 weight -20 }

state MASTER表示該節點角色定義爲MASTER，interface eth0是指虛擬機的網卡是eth0。virtual _ router _ id 51這項配置很是重要，兩個節點的這項配置的值必須同樣，不然會出現亂七八糟的問題，這裏我把virtual_router_id的值設置爲51。mcast_src_ip 192.168.101.3這項配置是指定當前節點的真實IP。priority 100的意思是優先級，這裏暫且設置爲100，固然也能夠是其它值。優先級在keepalived實現高可用方面起着相當重要的做用，keepalived服務器就是根據優先級來選擇當前提供服務的設備的，192.168.101.3剛開始設置的優先級是100,192.168.101.4 剛開始設置的優先級是 90，這樣keepalived 一開始去檢查優先級，發現192.168.101.3 這臺設備的優先級高，因而便讓該設備對外提供服務，當192.168.101.3這臺設備的nginx掛掉後，因爲nginx_check.sh 腳本每兩秒執行一次，發現192.168.101.3這個節點沒有nginx進程後便嘗試進行從新啓動nginx，若是從新啓動仍是不行的話，就殺掉全部的keepalived進程，並告訴keepalived服務器192.168.101.3 這個節點的nginx 掛掉了同時會把這個節點的優先級減20，從而優先級變爲了80，這樣下次keepalived 來檢查優先級發現192.168.101.4這個節點的優先級比較高（90），因而便讓192.168.101.4 這個節點對外提供服務，同理，這個節點發生故障的話，也會再去讓另一個節點來提供服務，這就實現了高可用。

Keepalived中Master和Backup角色選舉策略：https://www.linuxidc.com/Linux/2014-08/ 105884 . htm

1.2.8.4. Keepalived中Master和Backup角色選舉策略

在Keepalived集羣中，其實並無嚴格意義上的主、備節點，雖然能夠在Keepalived配置文件中設置「state」選項爲「MASTER」狀態，可是這並不意味着此節點一直就是Master角色。控制節點角色的是Keepalived配置文件中的「priority」值，但並它並不控制全部節點的角色，另外一個能改變節點角色的是在vrrp_script模塊中設置的「weight」值，這兩個選項對應的都是一個整數值，其中「weight」值能夠是個負整數，一個節點在集羣中的角色就是經過這兩個值的大小決定的。

在一個一主多備的Keepalived集羣中，「priority」值最大的將成爲集羣中的Master節點，而其餘都是Backup節點。在Master節點發生故障後，Backup節點之間將進行「民主選舉」，經過對節點優先級值「priority」和「「weight」的計算，選出新的Master節點接管集羣服務。

在vrrp_script模塊中，若是不設置「weight」選項值，那麼集羣優先級的選擇將由Keepalived配置文件中的「priority」值決定，而在須要對集羣中優先級進行靈活控制時，能夠經過在vrrp_script模塊中設置「weight」值來實現。下面列舉一個實例來具體說明。

假定有A和B兩節點組成的Keepalived集羣，在A節點keepalived.conf文件中，設置「priority」值爲100，而在B節點keepalived.conf文件中，設置「priority」值爲80，而且A、B兩個節點都使用了「vrrp_script」模塊來監控nginx服務，同時都設置「weight」值爲10，那麼將會發生以下狀況：

在兩節點都啓動Keepalived服務後，正常狀況是A節點將成爲集羣中的Master節點，而B自動成爲Backup節點，此時將A節點的nginx服務關閉，經過查看日誌發現，並無出現B節點接管A節點的日誌，B節點仍然處於Backup狀態，而A節點依舊是Master狀態，在這種狀況下整個HA集羣將失去意義。

1. 「weight」值爲正數時

2. 「weight」值爲負數時

以上兩種狀況的更新策略參考博文：keepalived之vrrp_script詳解

1.2.8.5 測試

回到負載均衡高可用的初始狀態，保證主、備上的keepalived、nginx所有啓動。

中止主nginx服務

觀察keepalived日誌：

tail -f /var/log/keepalived.log

查看keepalived進程已經不存在。

查看eth0已經沒有綁定vip。