知識點036-Nginx的負載均衡和高可用LVS

時間 2019-12-11

標籤知識 nginx 負載均衡可用 lvs 欄目 Nginx 简体版

原文原文鏈接

1. Nginx負載均衡

1.1 搭建負載均衡服務的需求

把單臺計算機沒法承受的大規模併發訪問或數據流量分擔到多臺節點設備上，分別進行處理，減小用戶等待響應的時間，提高用戶體驗；html

單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度提升。linux

7*24小時的服務保證，任意一個或多個有限後面節點設備宕機，不能影響業務。nginx

1.2 Nginx負載均衡模塊詳解

實現Nginx負載均衡的組件主要有兩個：ngx_http_proxy_module（proxy代理模塊，用於把請求後拋給服務器節點或upstream服務器池。）ngx_http_upstream_module（負載均衡模塊，能夠實現網站的負載均衡功能及節點的健康檢查。）。web

Nginx的負載均衡功能依賴於ngx_http_upstream_module模塊,所支持的代理方式包括proxy_pass、fastcgi_pass、memcached_pass等。ng_http_upstream_module模塊容許Nginx定義一組或多組節點服務器組，使用時能夠經過proxy_pass代理方式把網站的請求發送到事先定義好的對應Upstream組的名字上，具體的寫法爲「proxy_pass http://www_server_pools」，其中www_server_pools就是一個Upstream節點服務器組名字。算法

1.2 Nginx負載均衡基本的配置

首先配置2臺同樣的web服務的Nginx.conf 的配置文件爲：sql

user root;

worker_processes  1;

events {

    worker_connections  1024;

}

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';



    keepalive_timeout  65;

  server {

        listen       80;

        server_name  bbs.carlton.com;

        location / {

            root   html/bbs;

            index  index.html index.htm;

        }

  access_log   logs/bbs_access.log   main;

}

  server {

        listen       80;

        server_name  www.123456.com;

        location / {

            root   html/bbs;

            index  index.html index.htm;

        }

  access_log   logs/bbs_access.log   main;

}

}

而且把另外一臺的服務器的Nginx.conf 文件也配置好windows

用第3臺服務器配置好負載均衡，而且把本地的hosts配置好域名解析後端

worker_processes  1;

events {

    worker_connections  1024;

}

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;





    upstream server_pools {

         server 10.0.137.143:80 weight=1;

         server 10.0.137.144:80 weight=1;

    }

    server {

         listen    80;

         server_name www.123456.com;

         location / {

             proxy_pass http://server_pools;

             proxy_set_header Host $host;

             proxy_set_header X-Forwarded-For $remote_addr;

         }

    }

    server {

         listen    80;

         server_name bbs.carlton.com;

         location / {

             proxy_pass http://server_pools;

             proxy_set_header Host $host;

             proxy_set_header X-Forwarded-For $remote_addr;

         }

}

配置完成後，訪問bbs.carlton.com,就會出現網頁不停的跳動頁面的現象緩存

1.3 upstream配置案例

1.3.1 基本的upstream配置案例

upstream www_server_pools{ #upstream是關鍵字必需要有，後面的www_server_pools爲一個upstream集羣組的名字，能夠本身起，調用時就用這個名字。服務器

server 10.0.0.7:80 weight=5; #server是關鍵字是固定的，後面能夠接域名或IP，若是不指定端口，默認是80端口，weight表明權重，數值越大被分配的請求越多，結尾要有分號

server 10.0.0.8:80 weight=10;

}

1.3.2 較完整的upstream配置案例

upstream blog_server_pool {

server 10.0.0.7; #這一行標籤和下一行等價的。

server 10.0.0.7:80 weight=1 max_fails=1 fail_timeout=10; #這一行標籤和上一行等價的，此行對於的部分就是默認配置，不寫也能夠。

server 10.0.0.8:80 weight=1 max_fails=2 fail_timeout=20 backup; #server最後能夠加不少參數

}

1.3.3 使用域名及socket的upstream配置案例

upstream backend {

server backend2.example.com:8080 #域名加端口，轉發到後端指定的端口上

server unix:/tmp/backend3; #指定socket文件

}

1.3.4 upstream模塊相關說明

upstream模塊的內容應防護nginx.conf配置的http{}標籤內，其默認調度節點算法是wrr（權重輪詢weighted round-robin）

1.3.5 upstream模塊內容server標籤參數說明

server標籤	參數說明
server 10.0.0.8:80	負載均衡後面的RS配置，能夠是IP或域名，若是端口不寫，默認是80端口。高併發場景下，IP可換成域名，經過DNS作負載均衡。
weight=1	表明服務器的權重，默認值是1。權重數字越大表示接受的請求比例越大。
max_fails=1	Nginx嘗試鏈接後端主機失敗的次數，這個數值是配合proxy_next_upstream、fastcgi_next_upstream和memcached_next_upstream這三個參數來使用的，當Nginx接收後端服務器返回這三個參數定義的狀態碼時，會將這個請求轉發給正常工做的後端服務器，例如40四、50二、50三、Max_fails的默認值是1；企業場景：建議2-3次、京東1次、藍汛10次，根據業務需求去配置。
backup	熱備配置，當前面激活的RS都失敗後會自動啓用熱備RS。這標誌着這個服務器做爲備份服務器，若主服務器所有宕機了，就會向它轉發請求；注意，當負載調度算法是ip_hash時，後端服務器在負載均衡調度中的姿態不能是weight和backup。
fail_timeout=10s	在max_fails定義的失敗次數後，距離下次檢查的間隔時間，默認是10s；若是max_fails是5，它就檢測5次，若是5此都是502.那麼，它就會根據fail_timeout的值，等待10s再去檢查，仍是隻檢查一次，若是持續502，在不從新加載nginx配置的狀況下，每隔10s都只檢測一次。常規業務2-3秒比較合理，例如京東3秒，藍汛3秒，可根據業務需求去配置。
down	這標誌着服務器永遠不可用，這個參數可配合ip_hash使用

1.4 upstream模塊調度算法

1.4.1 調度算法通常分爲兩類

第一類爲靜態調度算法，即負載均衡器根據自身設定的規則進行分配，不須要考慮後端節點服務器的狀況，例如：rr、wrr、ip_hash等都屬於靜態調度算法。

第二類爲動態調度算法，即負載均衡器會根據後端節點的當前狀態來決定是否分發請求，例如：鏈接數少的優先得到請求，響應時間短的優先得到請求。例如：least_conn、fair等都屬於動態調度算法

1.4.2 介紹常見的調度算法

rr輪詢（權重查詢，靜態調度算法）

wrr（權重查詢，靜態調度算法）

在rr輪詢算法的基礎上加上權重，即爲權重輪詢算法，當使用該算法時，權重和用戶訪問成正比，權重值越大，被轉發的請求也就越多。能夠根據服務器的配置和性能指定權重值大小，有效決絕新舊服務器性能不均帶來的請求分配問題。

ip_hash（靜態調度算法）

每一個請求按客戶端IP的hash結果分配，當新的請求到達時，先將其客戶端IP經過哈希算法哈希出一個值，在隨後的客戶端請求中，客戶IP的哈希值只要相同，就會被分配至同一臺服務器，該調度算法能夠解決動態網頁的session共享問題，但有時會致使請求分配不均，即沒法保證1:1的負載均衡，覺得在國內大多數公司都是NAT上網模式，多個客戶端會對應一個外部IP，因此，這些客戶端都會被分配到同一節點服務器，從而致使請求分配不均。

fair（動態調度算法）

此算法會根據後端節點服務器的響應時間來分配請求，響應時間短的優先分配。這是更加智能的調度算法。若是須要使用這種調度算法，必須下載Nginx的相關模塊upstream_fair

least_conn

least_conn算法會根據後端節點的鏈接數來決定分配狀況，哪一個機器鏈接數少就分發

url_hash算法

和ip_hash相似，這裏是根據訪問URL的hash結果來分配請求的，讓每一個URL定向到同一個後端服務器，後端服務器爲緩存服務器時效果顯著。在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method使用的是hash算法。url_hash按訪問URL的hash結果來分配請求，使每一個URL定向到同一個後端服務器，能夠進一步提升後端緩存服務器的效率命中率。Nginx自己是不支持url_hash的，若是須要使用這種調度算法，必須安裝Nginx的hash模塊軟件包。

一致性hash算法

一致性hash算法通常用於代理後端業務爲緩存服務的場景，經過將用戶請求的URI或者指定字符串進行計算，而後調度到後端的服務器上，此後任何用戶查找同一個URI或者指定字符串都會被調度到這一臺服務器上，所以後端的每一個節點緩存的內容都是不一樣的，一致性hash算法能夠解決後端某個或幾個節點宕機後，緩存的數據動盪最小。

1.5 反向代理之proxy模塊講解

1.5.1 proxy_pass指令介紹

proxy_pass指令屬於ngx_http_proxy_module模塊，此模塊能夠將請求轉發到另外一臺服務器，在實際的反向代理工做中，會經過location功能匹配指定的URI，而後把接收到的符合匹配URI的請求經過proxy_pass拋給定義好的upstream節點池。

proxy_pass的使用案例

將匹配URI的爲name的請求拋給http://127.0.0.1/remote/

location /name/ {

proxy_pass http://127.0.0.1/remote/

}

1.5.2 http proxy模塊相關參數

http proxy模塊相關參數	說明
proxy_set_header	設置http請求header項傳給後端服務器節點，例如：可實現讓代理後端的服務器節點獲取訪問客戶端用戶的真實IP地址。
client_body_buffer_size	用於指定客戶端請求主題緩衝區大小
proxy_connect_timeout	表示反向代理與後端節點服務器鏈接的超時時間，即發起握手等待響應的超時時間。
proxy_send_timeout	表示代理後端服務器的數據回傳時間，即在規定時間以內後端服務器必須傳完全部的數據，不然，nginx將斷開這個鏈接。
proxy_read_timeout	設置而nginx從代理的後端服務器獲取信息的時間，表示鏈接創建成功後，nginx等待後端訪問權的響應時間，實際上是nginx已經進入後端的排隊之中等待處理的時間。
proxy_buffer_size	設置緩衝區大小，默認該緩衝區大小等於指令proxy_buffers設置的大小
proxy_buffers	設置緩衝區的數量和大小。nginx從代理的後端服務器獲取的響應信息，會放置到緩衝區
proxy_busy_buffers_size	用於設置系統很忙時可使用的proxy_buffers大小，官方推薦的大小爲proxy_buffers*2
proxy_temp_file_write_size	指定proxy緩存臨時文件的大小

舒適提醒：ngx_upsteam_modeule模塊官方地址：

http://nginx.org/en/docs/http/ngx_http_upstream_module.html

2. LVS集羣及Keepalived管理LVS

2.1 搭建負載均衡服務的需求

負載均衡（Load Balance）集羣提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載、帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性。

那麼在上面狀況下，企業網站須要搭建負載均衡服務呢

單臺計算機沒法承受大規模的併發訪問或數據流量了，此時須要搭建負載均衡集羣把流量分攤到多臺節點設備上分別處理，即減小用戶等待響應的時間又提高了用戶體驗；

單個重負載的運算服務分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回，系統處理能力和效率獲得大幅度提升。

2.2 LVS（Linux Virtual Server）介紹

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統，能夠在UNIX/LINUX平臺下實現負載均衡集羣的功能。該項目在1998年5月由章文嵩博士組織成立，是中國國內最先出現的自由軟件項目之一。

LVS技術點小結：

真正實現調度的工具是IPVS，工做在linux內核層面。

LVS自帶的IPVS管理工具是ipvsadm。

keepalived實現管理IPVS及負載均衡器的高可用。

Red hat工具Piranha WEB管理實現調度的工具是IPVS

2.3 LVS的ip名詞解釋

名稱	縮寫	說明
虛擬IP地址（Virtual Ip Address）	VIP	VIP爲Director用於向客戶端計算機提供服務的IP地址。好比：www.123456.com域名就要解析到vip上提供服務。
真實IP地址（Real Server Ip Address）	RIP	在集羣下面節點上使用的IP地址，物理IP地址。
Director的IP地址（Director Ip Address）	DIP	Director用於鏈接內外網絡的IP地址，物理網卡上的IP地址，是負載均衡器上的IP。
客戶端主機IP地址（Client Ip Address）	CIP	客戶端用戶計算機請求集羣服務器的IP地址，該地址用作發送給集羣的請求的源IP地址

2.4 LVS的四種工做模式特色

2.4.1 DR模式的特色

經過調度器LB上修改數據包的目的MAC地址實現轉發。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。

請求的報文通過調度器，而RS響應處理後的報文無需通過調度器LB，所以，併發訪問量大時使用效率很高。

因DR模式是經過MAC地址的改寫機制實現的轉發，所以，全部RS節點和調度器LB只能在一個局域網LAN中（小缺點）

須要注意RS節點的VIP的綁定（ln：vip/32）和ARP抑制問題。

強調下：RS節點的默認網關不須要是調度器LB的DIP，而直接是IDC機房分配的上級路由器的IP（這是RS電郵外網IP地址的狀況），理論講：只要RS能夠出網便可，不是必需要配置外網IP。

因爲DR模式的調度器僅進行了目的MAC地址的改寫，所以，調度器LB沒法改變請求的報文的目的端口

當前，調度器LB支持幾乎全部的unix，linux系統，但目前不支持windows系統。真實服務器RS節點能夠是windows系統。

總的來講DR模式效率很高，可是配置也較麻煩，所以，訪問量不是特別大的公司能夠用haproxy/nginx取代之。這符合運維的原則：簡單、易用、高效。日1000-2000W PV或併發請求1萬如下均可以考慮用haproxy/nginx（LVS NAT模式）

直接對外的訪問業務，例如：web服務作RS節點，RS最好用公網IP地址。若是不直接對外的服務，例如：Mysql，存儲系統RS節點，最好只用內部IP地址。

2.4.2 NAT模式特色

NAT技術將請求的報文（經過DNAT方式改寫）和響應的報文（經過SNAT方式改寫），經過調度器地址重寫而後在轉發給內部的服務器，報文返回時再改寫成原來的用戶請求的地址。

只須要在調度器LB上配置WAN公網IP便可，調度器也要有私有LAN IP和內部RS節點通訊。

每臺內部RS節點的網關地址（LDIP），這樣才能確保數據報文返回時仍然通過調度器LB。

因爲請求和比響應的數據報文都通過調度器LB，所以，網站訪問量大時調度器LB有較大瓶頸，通常要求最多10-20臺節點。

NAT模式支持對IP和端口的轉換，即用戶請求10.0.0.1:80，能夠經過調度器轉換到RS節點的10.0。0.2:8080（DR和TUN模式不具有的）

全部NAT內部RS節點只需配置私有LAN IP便可。

因爲數據包來回都須要通過調度器，所以，要開啓內核轉發net，ipv4，ip_forward=1，固然也包括iptables防火牆的forward功能（DR和TUN模式不須要）。

2.4.3 TUN模式的特色

負載均衡器經過把請求的報文經過IP隧道的方式（請求的報文不通過原目的地址的改寫包括MAC，而是直接封裝成另外的IP報文）轉發至真實服務器，而真實服務器將響應處理後直接返回給客戶端用戶。

因爲真實服務器將響應處理後的報文直接返回給客戶端用戶，所以，最好RS有一個外網IP地址，這樣效率纔會更高。理論上：只要能出網便可，無需外網IP地址。

因爲調度器LB只處理入站請求的報文。所以，此集羣系統的吞吐量能夠提升10倍以上，但隧道模式也會帶來必定的系統開銷。TUN模式適合LAN/WAN。

TUN模式的LAN環境轉發不如DR模式效率高，並且還要考慮系統對IP隧道的支持問題

全部的RS服務器都要綁定VIP，抑制ARP，配置複雜。

LAN環境通常採用DR模式，WAN環境能夠用TUN模式，可是當前在WAN環境下，請求裝發更多的被haproxy/nginx/DNS調度等代理取代。所以，TUN模式在國內公司實際應用的已經不多。跨機房應用要麼拉光纖成局域網，要麼DNS調度，底層數據還得同步。

直接對外的訪問業務員，例如：web服務器作RS節點，最好用公網IP地址。不直接對外的業務，例如：Mysql，存儲系統RS節點，最好用內部IP地址。

2.4.4 FULLNAT模式的特色

在LVS的FULLNAT轉發模式下, LVS對數據包同時作SNAT和DNAT，將數據包的源IP、源端口更換爲LVS本地的IP和端口，將數據包的目的IP和目的端口修改成RS的IP和端口，從而再也不依賴特定網絡拓樸轉發數據包。

3. 安裝並配置lvs

lb01和lb02操做以下

yum install ipvsadm -y

ln -s /usr/src/kernels/`uname -r` /usr/src/linux

3.2 配置負載均衡服務

lb01和lb02操做（10.0.137.143）

ip addr add 10.0.137.142/24 dev eth0 label eth0:0

ipvsadm -C

ipvsadm -A -t 10.0. 137.142:80 -s wrr

ipvsadm -a -t 10.0. 137.142:80 -r 10.0. 137.143:80 -g -w 1

ipvsadm -a -t 10.0. 137.142:80 -r 10.0.0. 137.144 -g -w 1

節點web1 和web2 服務器上操做以下

ip addr add 10.0. 137.142/32 dev lo label lo:0

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

3.3 使用keepalived管理LVS

lb01和lb02都安裝keepalived後，修改lb0的keepalived配置爲以下

! Configuration File for keepalived

global_defs {

   router_id LVS_DEVEL

}

vrrp_instance VI_1 {

    state MASTER

    interface eth0

    virtual_router_id 51

    priority 150

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

    }

    virtual_ipaddress {

         10.0. 137.142/24 dev eth0 label eth0:1

    }

}

#ipvsadm -A -t 10.0.0.3:80 -s wrr

virtual_server 10.0. 137.142 80 {

    delay_loop 6

    lb_algo rr

    lb_kind DR

    nat_mask 255.255.255.0

    persistence_timeout 50

    protocol TCP

#ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.7:80 -g -w 1

    real_server 10.0. 137.143 80 {

        weight 1

         TCP_CHECK {

         connect_timeout 5

         nb_get_retry 3

         delay_before_retry 3

         connect_port 80

         }

      }

#ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.8:80 -g -w 1

    real_server 10.0. 137.144 80 {

        weight 1

        TCP_CHECK {

        connect_timeout 5

        nb_get_retry 3

        delay_before_retry 3

        connect_port 80

        }

      }

}

修改lb02服務器keepalived配置爲以下

! Configuration File for keepalived

global_defs {

   router_id LVS_DEVEL1

}

vrrp_instance VI_1 {

    state BACKUP

    interface eth0

    virtual_router_id 51

    priority 100

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

    }

    virtual_ipaddress {

         10.0. 137.142/24 dev eth1 label eth1:1

    }

}

#ipvsadm -A -t 10.0.0.3:80 -s wrr

virtual_server 10.0. 137.142 80 {

    delay_loop 6

    lb_algo rr

    lb_kind DR

    nat_mask 255.255.255.0

    persistence_timeout 50

    protocol TCP

#ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.7:80 -g -w 1

    real_server 10.0. 137.143 80 {

        weight 1

         TCP_CHECK {

         connect_timeout 5

         nb_get_retry 3

         delay_before_retry 3

         connect_port 80

         }

      }

#ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.8:80 -g -w 1

    real_server 10.0. 137.144 80 {

        weight 1

        TCP_CHECK {

        connect_timeout 5

        nb_get_retry 3

        delay_before_retry 3

        connect_port 80

        }

      }

}

配置完重啓keepalived便可