keepalived heartbeat lvs haproxy

一, keeplived @

　　01,keeplived 是什麼?

　　　　　Keepalived起初是爲LVS設計的，專門用來監控集羣系統中各個服務節點的狀態，它根據TCP/IP參考模型的第3、第四層、第五層交換機制檢測每一個服務節點的狀態，若是某個服務器節點出現異常，或者工做出現故障，Keepalived將檢測到，並將出現的故障的服務器節點從集羣系統中剔除，這些工做所有是自動完成的，不須要人工干涉，須要人工完成的只是修復出現故障的服務節點。後來Keepalived又加入了VRRP的功能，VRRP（Vritrual Router Redundancy Protocol,虛擬路由冗餘協議)出現的目的是解決靜態路由出現的單點故障問題，經過VRRP能夠實現網絡不間斷穩定運行，所以Keepalvied 一方面具備服務器狀態檢測和故障隔離功能，另一方面也有HA cluster功能.

　　02,keeplived 工做原理

　　　　　　Keepalived工做在TCP/IP 參考模型的 三層、四層、五層，也就是分別爲：網絡層，傳輸層和應用層，根據TCP、IP參數模型隔層所能實現的功能，Keepalived運行機制以下：

     在網絡層：咱們知道運行這4個重要的協議，互聯網絡IP協議，互聯網絡可控制報文協議ICMP、地址轉換協議ARP、反向地址轉換協議RARP，在網絡層Keepalived在網絡層採用最多見的工做方式是經過ICMP協議向服務器集羣中的每個節點發送一個ICMP數據包(有點相似與Ping的功能)，若是某個節點沒有返回響應數據包，那麼認爲該節點發生了故障，Keepalived將報告這個節點失效，並從服務器集羣中剔除故障節點。

     在傳輸層：提供了兩個主要的協議：傳輸控制協議TCP和用戶數據協議UDP，傳輸控制協議TCP能夠提供可靠的數據輸出服務、IP地址和端口，表明TCP的一個鏈接端，要得到TCP服務，須要在發送機的一個端口和接收機的一個端口上創建鏈接，而Keepalived在傳輸層裏利用了TCP協議的端口鏈接和掃描技術來判斷集羣節點的端口是否正常，好比對於常見的WEB服務器80端口。或者SSH服務22端口，Keepalived一旦在傳輸層探測到這些端口號沒有數據響應和數據返回，就認爲這些端口發生異常，而後強制將這些端口所對應的節點從服務器集羣中剔除掉。

在應用層：能夠運行FTP，TELNET，SMTP，DNS等各類不一樣類型的高層協議，Keepalived的運行方式也更加全面化和複雜化，用戶能夠經過自定義Keepalived工做方式，例如：能夠經過編寫程序或者腳原本運行Keepalived，而Keepalived將根據用戶的設定參數檢測各類程序或者服務是否容許正常，若是Keepalived的檢測結果和用戶設定的不一致時，Keepalived將把對應的服務器從服務器集羣中剔除

　　03,keeplived主配置文件詳解

　　　　　　keepalived主要有三個模塊，分別是core、check和vrrp。core模塊爲keepalived的核心，負責主進程的啓動、維護以及全局配置文件的加載和解析。check負責健康檢查，包括常見的各類檢查方式。vrrp模塊是來實現VRRP協議的。keepalived只有一個配置文件keepalived.conf，裏面主要包括如下幾個配置區域，
分別是global_defs、static_ipaddress、static_routes、vrrp_script、vrrp_instance和virtual_server。

　　             配置文件實例介紹:　　

 1 global_defs {
 2     notification_email {   #故障發生時給誰發郵件通知。
 3         a@abc.com  
 4         b@abc.com
 5         ...
 6     }
 7     notification_email_from alert@abc.com   #通知郵件從哪一個地址發出。
 8     smtp_server smtp.abc.com   #通知郵件的smtp地址。
 9     smtp_connect_timeout 30 # 鏈接smtp服務器的超時時間。
10     enable_traps   #鏈接smtp服務器的超時時間。
11     router_id host163 #標識本節點的字條串，一般爲hostname，但不必定非得是hostname。故障發生時，郵件通知會用到。
12 }
13 
14 
15 static_ipaddress {
16     10.210.214.163/24 brd 10.210.214.255 dev eth0 配置的是是本節點的IP和路由信息
17     ...
18 }
19 
20 
21 static_routes {
22     10.0.0.0/8 via 10.210.214.1 dev eth0  配置的是是本節點的IP和路由信息
23     ...
24 }
25 
26 vrrp_script chk_http_port {    #用來作健康檢查的，當時檢查失敗時會將vrrp_instance的priority減小相應的值。
27 
28     script "</dev/tcp/127.0.0.1/80"
29     interval 1
30     weight -10
31 }
32 
33 
34 vrrp_sync_group VG_1 {  
35     group {
36         inside_network   # name of vrrp_instance (below)
37         outside_network  # One for each moveable IP.
38         ...
39     }
40     notify_master /path/to_master.sh   #分別表示切換爲主/備/出錯時所執行的腳本
41     notify_backup /path/to_backup.sh 
42     notify_fault "/path/fault.sh VG_1"
43     notify /path/notify.sh
44     smtp_alert    表示是否開啓郵件通知
45 }
46 vrrp_instance VI_1 {
47     state MASTER   #能夠是MASTER或BACKUP，不過當其餘節點keepalived啓動時會將priority比較大的節點選 舉爲MASTER，所以該項其實沒有實質用途。
48     interface eth0   #節點固有IP（非VIP）的網卡，用來發VRRP包。
49     use_vmac <VMAC_INTERFACE>  #是否使用VRRP的虛擬MAC地址。
50     dont_track_primary  $#忽略VRRP網卡錯誤
51     track_interface { #監控如下網卡，若是任何一個不通就會切換到FALT狀態
52         eth0 
53         eth1
54     }
55     mcast_src_ip <IPADDR>   #修改vrrp組播包的源地址，默認源地址爲master的IP。（因爲是組播，所以即便修改了源地址，該master仍是能收到迴應的）
56     lvs_sync_daemon_interface eth1     #綁定lvs syncd的網卡。
57     garp_master_delay 10   #當切爲主狀態後多久更新ARP緩存，默認5秒
58     virtual_router_id 1  #取值在0-255之間，用來區分多個instance的VRRP組播。
59     priority 100  #用來選舉master的，要成爲master，那麼這個選項的值最好高於其餘機器50個點，該項取值範圍是1-255（在此範圍以外會被識別成默認值100）
60     advert_int 1   #發VRRP包的時間間隔，即多久進行一次master選舉（能夠認爲是健康查檢時間間隔）。
61     authentication {   #認證區域，認證類型有PASS和HA（IPSEC），推薦使用PASS（密碼只識別前8位）。
62         auth_type PASS   
63         auth_pass 12345678
64     }
65     virtual_ipaddress {    
66         10.210.214.253/24 brd 10.210.214.255 dev eth0
67         192.168.1.11/24 brd 192.168.1.255 dev eth1
68     }
69     virtual_routes { #虛擬路由，當IP漂過來以後須要添加的路由信息。
70         172.16.0.0/12 via 10.210.214.1
71         192.168.1.0/24 via 192.168.1.1 dev eth1
72         default via 202.102.152.1
73     }
74     track_script {  腳本
75         chk_http_port 
76     } 
77     nopreempt   #容許一個priority比較低的節點做爲master，即便有priority更高的節點啓動
78     preempt_delay 300   #啓動多久以後進行接管資源（VIP/Route信息等），並提是沒有nopreempt選項。
79     debug
80     notify_master <STRING>|<QUOTED-STRING>
81     notify_backup <STRING>|<QUOTED-STRING>
82     notify_fault <STRING>|<QUOTED-STRING>
83     notify <STRING>|<QUOTED-STRING>
84     smtp_alert
85 }

View Code

二, heartbeat @

　  　01,heartbeat 是什麼?

　　　　　　Linux-HA的全稱是High-Availability Linux，它是一個開源項目，這個開源項目的目標是：經過社區開發者的共同努力，提供一個加強linux可靠性（reliability）、可用性（availability）和可服務性（serviceability）（RAS）的羣集解決方案。其中Heartbeat就是Linux-HA項目中的一個組件，也是目前開源HA項目中最成功的一個例子，它提供了全部 HA 軟件所須要的基本功能，好比心跳檢測和資源接管、監測羣集中的系統服務、在羣集中的節點間轉移共享 IP 地址的全部者等，經過它能夠將資源（IP及程序服務等資源）從一臺故障計算機快速轉移到另外一臺運轉正常的機器繼續提供服務, 版本下載的話能夠從Linux-HA的官方網站www.linux-ha.org下載到Heartbeat的最新版本。

　　　02,heartbeat 原理

　　　　經過修改配置文件，指定哪一臺Heartbeat服務器做爲主服務器，則另外一臺將自動成爲備份服務器。而後在指定備份服務器上配置Heartbeat守護進程來監聽來自主服務器的心跳。若是備份服務器在指定時間內未監聽到來自主服務器的心跳，就會啓動故障轉移程序，並取得主服務器上的相關資源服務全部權，接替主服務器繼續不間斷的提供服務，從而達到資源服務高可用性的目的。
以上描述的是Heartbeat主備的模式，Heartbeat還支持主主模式，即兩臺服務器互爲主備，這時它們之間會相互發送報文來告訴對方本身當前的狀態，若是在指定的時間內爲收到對方發送的心跳報文，那麼久認爲對方失效或者宕機了，這時就會啓動自身的資源接管模塊來接管運行在對方主機上的資源或者服務，繼續對用戶提供服務。正常狀況下，能夠較好的實現主機故障後，業務仍不間斷的持續運行。
keepalived主要控制IP飄移，配置應用簡單，並且分層，layer3，4，5，各自配置極爲簡單。heartbeat不但能夠控制IP飄移，更擅長對資源服務的控制，配置，應用比較複雜。lvs的高可用建議用keepavlived；業務的高可用用heartbeat。

　　  03,headbeat 模塊詳解

　　　　😊ha.cg配置文件:

debugfile /var/log/ha-debug  #用於記錄heartbeat的調試信息
logfile /var/log/ha-log  #用於記錄heartbeat的日誌信息
logfacility local0  #系統日誌級別
keepalive 2  #設定心跳(監測)間隔時間，默認單位爲秒
warntime 10  #＃警告時間，一般爲deadtime時間的一半
deadtime 30  # 超出30秒未收到對方節點的心跳，則認爲對方已經死亡
initdead 120  #網絡啓動時間，至少爲deadtime的兩倍。
hopfudge 1  #可選項：用於環狀拓撲結構,在集羣中總共跳躍節點的數量
udpport 694  #使用udp端口694 進行心跳監測
ucast eth1 192.168.9.6  #採用單播，進行心跳監測，IP爲對方主機IP
auto_failback on  #on表示當擁有該資源的屬主恢復以後，資源遷移到屬主上
node srv5.localdomain  #設置集羣中的節點，節點名須與uname –n相匹配
node srv6.localdomain  #節點2
ping 192.168.8.2 192.168.9.7  #ping集羣之外的節點，這裏是網關和另外一臺機器，用於檢測網絡的鏈接性
respawn root /usr/lib/heartbeat/ipfail
apiauth ipfail gid=root uid=root  #設置所指定的啓動進程的權限

View Code

　　　　　😊認證文件authkeys:

 　　　　　　　　用於配置心跳的加密方式，該文件主要是用於集羣中兩個節點的認證，採用的算法和密鑰在集羣 中節點上必須相同，目前提供了3種算法：md5,sha1和crc。其中crc不可以提供認證，它只能 夠用於校驗數據包是否損壞，而sha1,md5須要一個密鑰來進行認證。三種認證方式的安全性依次提升，可是佔用的系統資源也依次增長。若是heartbeat集羣運行在安全的網絡上，可使用crc方式，若是HA每一個節點的硬件配置很高，建議使用sha1，這種認證方式安全級別最高，若是是處於網絡安全和系統資源之間，可使用md5認證方式。 

　　　　　😊 資源文件(/etc/ha.d/haresources):　

　　　　　　　　Haresources文件用於指定雙機系統的主節點、集羣IP、子網掩碼、廣播地址以及啓動的服務等集羣資源，文件每一行能夠包含一個或多個資源腳本名，資源之間使用空格隔開，參數之間使用兩個冒號隔開，在兩個HA節點上該文件必須徹底一致，此文件的通常格式爲：
node-name network
node-name表示主節點的主機名，必須和ha.cf文件中指定的節點名一致，network用於設定集羣的IP地址、子網掩碼、網絡設備標識等，須要注意的是，這裏指定的IP地址就是集羣對外服務的IP地址，resource-group用來指定須要heartbeat託管的服務，也就是這些服務能夠由heartbeat來啓動和關閉，若是要託管這些服務，必須將服務寫成能夠經過start/stop來啓動和關閉的腳步，而後放到/etc/init.d/或者/etc/ha.d/resource.d/目錄下，heartbeat會根據腳本的名稱自動去/etc/init.d或者/etc/ha.d/resource.d/目錄下找到相應腳步進行啓動或關閉操做。

三, haproxy

　　01,什麼是haproxy?

　　　　　　haproxy是一款負載均衡軟件，它工做在7層模型上，能夠分析數據包中的應用層協議，並按規則進行負載。一般這類7層負載工具也稱爲反向代理軟件，nginx是另外一款著名的反向代理軟件。HAProxy提供了L4(TCP)和L7(HTTP)兩種負載均衡能力(反向代理)

　　02,haproxy的特性?

　　　　　　特性有:　

　　　　　　　　負載均衡：L4(僞四層)和L7兩種模式，支持RR/靜態RR/LC/IP Hash/URI Hash/URL_PARAM Hash/HTTP_HEADER Hash等豐富的負載均衡算法
　　　　　　　　健康檢查：支持TCP和HTTP兩種健康檢查模式
　　　　　　　　會話保持：對於未實現會話共享的應用集羣，可經過Insert Cookie/Rewrite Cookie/Prefix Cookie，以及上述的多種Hash方式實現會話保持
　　　　　　　　SSL：HAProxy能夠解析HTTPS協議，並可以將請求解密爲HTTP後向後端傳輸
　　　　　　　　HTTP請求重寫與重定向
　　　　　　　　監控與統計：HAProxy提供了基於Web的統計信息頁面，展示健康狀態和流量數據。基於此功能，使用者能夠開發監控程序來監控HAProxy的狀態

　　　　 😊會話保持:

　　　　　　　任何一個反向代理軟件，都必須具有這個基本的功能。這主要針對後端是應用服務器的狀況，若是後端是靜態服務器或緩存服務器，無需實現會話保持，由於它們是"無狀態"的。若是反向代理的後端提供的是"有狀態"的服務或協議時，必須保證請求過一次的客戶端能被引導到同義服務端上。只有這樣，服務端才能知道這個客戶端是它曾經處理過的，能查到並獲取到和該客戶端對應的上下文環境(session上下文)，有了這個session環境才能繼續爲該客戶端提供後續的服務。這個可能不太好去理解,那咱們就來簡單舉個例子。

　　　　　　　　　客戶端A向服務端B請求將C商品加入它的帳戶購物車，加入成功後，服務端B會在某個緩存中記錄下客戶端A和它的商品C，這個緩存的內容就是session上下文環境。而識別客戶端的方式通常是設置session ID(如PHPSESSID、JSESSIONID)，並將其做爲cookie的內容交給客戶端。客戶端A再次請求的時候(好比將購物車中的商品下訂單)只要攜帶這個cookie，服務端B就能夠從中獲取到session ID並找到屬於客戶端A的緩存內容，也就能夠繼續執行下訂單部分的代碼。假如這時使用負載均衡軟件對客戶端的請求進行負載，若是這個負載軟件只是簡單地進行負載轉發，就沒法保證將客戶端A引導到服務端B，可能會引導到服務端X、服務端Y，可是X、Y上並無緩存和客戶端A對應的session內容，固然也沒法爲客戶端A下訂單。所以，反向代理軟件必須具有將客戶端和服務端"綁定"的功能，也就是所謂的提供會話保持，讓客戶端A後續的請求必定轉發到服務端B上。

　　 03,配置文件詳解

　　　　　　 主配置文件:

    global：參數是進程級的，一般是和操做系統相關。這些參數通常只設置一次，若是配置無誤，就不須要再次進行修改；
    defaults：配置默認參數，這些參數能夠被用到frontend，backend，Listen組件；
    frontend：接收請求的前端虛擬節點，Frontend能夠更加規則直接指定具體使用後端的backend；
    backend：後端服務集羣的配置，是真實服務器，一個Backend對應一個或者多個實體服務器；
    Listen Fronted和backend的組合體。


global # 全局參數的設置
    log 127.0.0.1 local0 info 
# log語法：log <address_1>[max_level_1] # 全局的日誌配置，使用log關鍵字，指定使用127.0.0.1上的syslog服務中的local0日誌設備，記錄日誌等級爲info的日誌 
    user haproxy 
    group haproxy 
# 設置運行haproxy的用戶和組，也可以使用uid，gid關鍵字替代之 
    daemon 
# 以守護進程的方式運行 
    nbproc 16 
# 設置haproxy啓動時的進程數，根據官方文檔的解釋，我將其理解爲：該值的設置應該和服務器的CPU核心數一致，即常見的2顆8核心CPU的服務器，即共有16核心，則能夠將其值設置爲：<=16 ，建立多個進程數，能夠減小每一個進程的任務隊列，可是過多的進程數也可能會致使進程的崩潰。這裏我設置爲16 
    maxconn 4096 
# 定義每一個haproxy進程的最大鏈接數 ，因爲每一個鏈接包括一個客戶端和一個服務器端，因此單個進程的TCP會話最大數目將是該值的兩倍。 
    #ulimit -n 65536 
# 設置最大打開的文件描述符數，在1.4的官方文檔中提示，該值會自動計算，因此不建議進行設置 
    pidfile /var/run/haproxy.pid 
# 定義haproxy的pid

defaults # 默認部分的定義 
    mode http 
# mode語法：mode {http|tcp|health} 。http是七層模式，tcp是四層模式，health是健康檢測，返回OK 
    log 127.0.0.1 local3 err 
# 使用127.0.0.1上的syslog服務的local3設備記錄錯誤信息 
    retries 3 
# 定義鏈接後端服務器的失敗重連次數，鏈接失敗次數超過此值後將會將對應後端服務器標記爲不可用 
    option httplog 
# 啓用日誌記錄HTTP請求，默認haproxy日誌記錄是不記錄HTTP請求的，只記錄「時間[Jan 5 13:23:46] 日誌服務器[127.0.0.1] 實例名已經pid[haproxy[25218]] 信息[Proxy http_80_in stopped.]」，日誌格式很簡單。 
    option redispatch 
# 當使用了cookie時，haproxy將會將其請求的後端服務器的serverID插入到cookie中，以保證會話的SESSION持久性；而此時，若是後端的服務器宕掉了，可是客戶端的cookie是不會刷新的，若是設置此參數，將會將客戶的請求強制定向到另一個後端server上，以保證服務的正常。 
    option abortonclose 
# 當服務器負載很高的時候，自動結束掉當前隊列處理比較久的連接 
    option dontlognull 
# 啓用該項，日誌中將不會記錄空鏈接。所謂空鏈接就是在上游的負載均衡器或者監控系統爲了探測該服務是否存活可用時，須要按期的鏈接或者獲取某一固定的組件或頁面，或者探測掃描端口是否在監聽或開放等動做被稱爲空鏈接；官方文檔中標註，若是該服務上游沒有其餘的負載均衡器的話，建議不要使用該參數，由於互聯網上的惡意掃描或其餘動做就不會被記錄下來 
    option httpclose # 這個參數我是這樣理解的：使用該參數，每處理完一個request時，haproxy都會去檢查http頭中的Connection的值，若是該值不是close，haproxy將會將其刪除，若是該值爲空將會添加爲：Connection: close。使每一個客戶端和服務器端在完成一次傳輸後都會主動關閉TCP鏈接。與該參數相似的另一個參數是「option forceclose」，該參數的做用是強制關閉對外的服務通道，由於有的服務器端收到Connection: close時，也不會自動關閉TCP鏈接，若是客戶端也不關閉，鏈接就會一直處於打開，直到超時。 
    contimeout 5000
 # 設置成功鏈接到一臺服務器的最長等待時間，默認單位是毫秒，新版本的haproxy使用timeout connect替代，該參數向後兼容 
    clitimeout 3000 
# 設置鏈接客戶端發送數據時的成功鏈接最長等待時間，默認單位是毫秒，新版本haproxy使用timeout client替代。該參數向後兼容 
    srvtimeout 3000 
# 設置服務器端迴應客戶度數據發送的最長等待時間，默認單位是毫秒，新版本haproxy使用timeout server替代。該參數向後兼容
listen status # 定義一個名爲status的部分 
    bind 0.0.0.0:1080 
# 定義監聽的套接字 
    mode http 
# 定義爲HTTP模式
    log global 
# 繼承global中log的定義 
    stats refresh 30s 
# stats是haproxy的一個統計頁面的套接字，該參數設置統計頁面的刷新間隔爲30s
    stats uri /admin?stats 
# 設置統計頁面的uri爲/admin?stats 
    stats realm Private lands 
# 設置統計頁面認證時的提示內容 
    stats auth admin:password 
# 設置統計頁面認證的用戶和密碼，若是要設置多個，另起一行寫入便可 
    stats hide-version 
# 隱藏統計頁面上的haproxy版本信息 
frontend http_80_in # 定義一個名爲http_80_in的前端部分 
    bind 0.0.0.0:80 
# http_80_in定義前端部分監聽的套接字 
    mode http 
# 定義爲HTTP模式 
    log global 
# 繼承global中log的定義 
    option forwardfor 
# 啓用X-Forwarded-For，在requests頭部插入客戶端IP發送給後端的server，使後端server獲取到客戶端的真實IP 
    acl static_down nbsrv(static_server) lt 1 
# 定義一個名叫static_down的acl，當backend static_sever中存活機器數小於1時會被匹配到 
    acl php_web url_reg /*.php$ 
    #acl php_web path_end .php 
# 定義一個名叫php_web的acl，當請求的url末尾是以.php結尾的，將會被匹配到，上面兩種寫法任選其一 
    acl static_web url_reg /*.(css|jpg|png|jpeg|js|gif)$ 
    #acl static_web path_end .gif .png .jpg .css .js .jpeg 
# 定義一個名叫static_web的acl，當請求的url末尾是以.css、.jpg、.png、.jpeg、.js、.gif結尾的，將會被匹配到，上面兩種寫法任選其一 
    use_backend php_server if static_down 
# 若是知足策略static_down時，就將請求交予backend php_server 
    use_backend php_server if php_web 
# 若是知足策略php_web時，就將請求交予backend php_server 
    use_backend static_server if static_web 
# 若是知足策略static_web時，就將請求交予backend static_server 
backend php_server #定義一個名爲php_server的後端部分 
    mode http 
# 設置爲http模式 
    balance source 
# 設置haproxy的調度算法爲源地址hash 
    cookie SERVERID 
# 容許向cookie插入SERVERID，每臺服務器的SERVERID可在下面使用cookie關鍵字定義 
    option httpchk  GET /test/index.php 
# 開啓對後端服務器的健康檢測，經過GET /test/index.php來判斷後端服務器的健康狀況 
    server php_server_1 10.12.25.68:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2 
    server php_server_2 10.12.25.72:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1 
    server php_server_bak 10.12.25.79:80 cookie 3 check inter 1500 rise 3 fall 3 backup 
# server語法：server [:port] [param*] # 使用server關鍵字來設置後端服務器；爲後端服務器所設置的內部名稱[php_server_1]，該名稱將會呈如今日誌或警報中、後端服務器的IP地址，支持端口映射[10.12.25.68:80]、指定該服務器的SERVERID爲1[cookie 1]、接受健康監測[check]、監測的間隔時長，單位毫秒[inter 2000]、監測正常多少次後被認爲後端服務器是可用的[rise 3]、監測失敗多少次後被認爲後端服務器是不可用的[fall 3]、分發的權重[weight 2]、最後爲備份用的後端服務器，當正常的服務器所有都宕機後，纔會啓用備份服務器[backup] 
backend static_server 
    mode http 
    option httpchk GET /test/index.html 
    server static_server_1 10.12.25.83:80 cookie 3 check inter 2000 rise 3 fall 3    

 　　04,算法

 1     1.balance roundrobin # 輪詢，軟負載均衡基本都具有這種算法
 2      
 3     2.balance static-rr # 根據權重，建議使用
 4      
 5     3.balance leastconn # 最少鏈接者先處理，建議使用
 6      
 7     4.balance source # 根據請求源IP，建議使用
 8      
 9     5.balance uri # 根據請求的URI
10      
11     6.balance url_param，# 根據請求的URl參數'balance url_param' requires an URL parameter name
12      
13     7.balance hdr(name) # 根據HTTP請求頭來鎖定每一次HTTP請求
14      
15     8.balance rdp-cookie(name) # 根據據cookie(name)來鎖定並哈希每一次TCP請求

四,LVS @

　　01,LVS是什麼?

　　　　　LVS的英文全稱是Linux Virtual Server，即Linux虛擬服務器。它是咱們國家的章文嵩博士的一個開源項目。在linux內存2.6中，它已經成爲內核的一部分，在此以前的內核版本則須要從新編譯內核。主要用於多服務器的負載均衡。它工做在網絡層，能夠實現高性能，高可用的服務器集羣技術。它廉價，可把許多低性能的服務器組合在一塊兒造成一個超級服務器。它易用，配置很是簡單，且有多種負載均衡的方法。它穩定可靠，即便在集羣的服務器中某臺服務器沒法正常工做，也不影響總體效果。另外可擴展性也很是好。

　　02,LVS的工做原理?

　　　　　LVS 有兩核心組成, ipvs與ipvsadm

　　　　　　　　ipvs: LVS核心實現,更具定義好的集羣規則進行工做

　　　　　　　　ipvsadm:LVS管理工具,管理員經過ipvsadm定義或管理集羣規則

　　　　　LVS能夠分爲三大部分:

　　　　1.Load Balancer：這是LVS的核心部分，它比如咱們網站MVC模型的Controller。它負責將客戶的請求按照必定的算法分發到下一層不一樣的服務器進行處理，本身自己不作具體業務的處理。另外該層還可用監控下一層的狀態，若是下一層的某臺服務器不能正常工做了，它會自動把其剔除，恢復後又可用加上。該層由一臺或者幾臺Director Server組成。

　　　　2.Server Array：該層負責具體業務。可有WEB Server、mail Server、FTP Server、DNS Server等組成。注意，其實上層的Director Server也能夠當Real server用的。

　　　　3.Shared Storage：主要是提升上一層數據和爲上一層保持數據一致

　　　03,三種類型

　　　　😀LVS-DR:

　　　　　　

原理簡述
當客戶端向VIP發起請求時，[源CIP;目的VIP]數據包經過路由器發送到Director。而後Director不修改其源IP目
的iP。通過調度後將目的MAC改成RS的MAC，RS收到數據以後發現目的IP爲本機的L0接口就將其收下，而後找
到數據再將源IP改成L0目的IP爲CIP直接經過公網返回給客戶端
架構特性
1.必須保證前端路由經過ARP地址解析將數據轉發至Director，數據不能被RS接收
2.RS可使用私網地址，也可使用公網IP
3.Director只負責調度。
4.Director與RS必須在同一物理段中
5.不支持端口映射
6.RS的網關爲前端路由，不能爲Director
7.RS支持大多出OS(能夠拒絕ARP響應的系統)

　　　　😀LVS-NAT:

原理簡述
    客戶端向VIP發起請求鏈接，Director在通過調度以後選取RS，將本地端口與RS的端口作映射，而後RS
返還數據Director將數據返還客戶端
LVS-NAT特性
    1.RIP的網關必須與網關指向DIP
    2.可使用端口映射；即Director將客戶端請求的IP端口轉換爲真是服務器的iP與端口
    3.Director會成爲系統的瓶頸所在，
    4.RS能夠爲任意的操做系統
    5.每臺後端服務器的網關必須爲調度器的內網地址

　　　　😀LSV-TUN:　　

原理簡述
客戶端向VIP發送請求時，[源CIP；目的VIP]，Director通過調度輪詢後選擇一個RS後使用隧道技術再次封裝後
向RS發送【源DIP；目的RIP [源CIP；目的VIP]】，RS經過隧道收到請求後拆開數據後獲得[源CIP；目的VIP]，
發現目的IP爲本身L0接口的IP得，後就把數據收下，找到數據後將數據直接經過公網返還給客戶端[源VIP；目的
CIP]
特性
1.RIP、DIP、VIP必須爲公網IP
2.RS網關不指向Director
3.請求報文由Director轉發至RS，回覆報文由RS直接發送至客戶端
4.不支持端口映射
5.RS的OS必須支持隧道技術
6.Director與RS、RS與RS能夠跨網段、跨機房。

　　04,LVS十種算法:

　　　　　1.輪詢調度

　　輪詢調度（Round Robin 簡稱'RR'）算法就是按依次循環的方式將請求調度到不一樣的服務器上，該算法最大的特色就是實現簡單。輪詢算法假設全部的服務器處理請求的能力都同樣的，調度器會將全部的請求平均分配給每一個真實服務器。

　　　　   2.加權輪詢調度

　　加權輪詢（Weight Round Robin 簡稱'WRR'）算法主要是對輪詢算法的一種優化與補充，LVS會考慮每臺服務器的性能，並給每臺服務器添加一個權值，若是服務器A的權值爲1，服務器B的權值爲2，則調度器調度到服務器B的請求會是服務器A的兩倍。權值越高的服務器，處理的請求越多。

　　　　    3.最小鏈接調度

　　最小鏈接調度（Least Connections 簡稱'LC'）算法是把新的鏈接請求分配到當前鏈接數最小的服務器。最小鏈接調度是一種動態的調度算法，它經過服務器當前活躍的鏈接數來估計服務器的狀況。調度器須要記錄各個服務器已創建鏈接的數目，當一個請求被調度到某臺服務器，其鏈接數加1；當鏈接中斷或者超時，其鏈接數減1。

（集羣系統的真實服務器具備相近的系統性能，採用最小鏈接調度算法能夠比較好地均衡負載。)

　　　　     4.加權最小鏈接調度

　　加權最少鏈接（Weight Least Connections 簡稱'WLC'）算法是最小鏈接調度的超集，各個服務器相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員能夠動態地設置服務器的權值。加權最小鏈接調度在調度新鏈接時儘量使服務器的已創建鏈接數和其權值成比例。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。

　　　　      5.基於局部的最少鏈接

　　基於局部的最少鏈接調度（Locality-Based Least Connections 簡稱'LBLC'）算法是針對請求報文的目標IP地址的 負載均衡調度，目前主要用於Cache集羣系統，由於在Cache集羣客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器均可以處理任一請求，算法的設計目標是在服務器的負載基本平衡狀況下，將相同目標IP地址的請求調度到同一臺服務器，來提升各臺服務器的訪問局部性和Cache命中率，從而提高整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工做負載，則使用'最少鏈接'的原則選出一個可用的服務器，將請求發送到服務器。

　　　　      6.帶複製的基於局部性的最少鏈接

　　帶複製的基於局部性的最少鏈接（Locality-Based Least Connections with Replication  簡稱'LBLCR'）算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統，它與LBLC算法不一樣之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。按'最小鏈接'原則從該服務器組中選出一一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按'最小鏈接'原則從整個集羣中選出一臺服務器，將該服務器加入到這個服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

　　　　       7.目標地址散列調度

　　目標地址散列調度（Destination Hashing 簡稱'DH'）算法先根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且並未超載，將請求發送到該服務器，不然返回空。

　　　　      8.源地址散列調度U

　　源地址散列調度（Source Hashing  簡稱'SH'）算法先根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且並未超載，將請求發送到該服務器，不然返回空。它採用的散列函數與目標地址散列調度算法的相同，它的算法流程與目標地址散列調度算法的基本類似。

　　　　      9.最短的指望的延遲

　　最短的指望的延遲調度（Shortest Expected Delay 簡稱'SED'）算法基於WLC算法。舉個例子吧，ABC三臺服務器的權重分別爲一、二、3 。那麼若是使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED算法後會進行一個運算A：（1+1）/1=2   B：（1+2）/2=3/2   C：（1+3）/3=4/3   就把請求交給得出運算結果最小的服務器。

　　　　     1 0.最少隊列調度

　　最少隊列調度（Never Queue 簡稱'NQ'）算法，無需隊列。若是有realserver的鏈接數等於0就直接分配過去，不須要在進行SED運算。

五,聯繫

　　   01,keepalived+haproxy+web

　　　　

　　　　02,keepalived+lvs+web

 　　　　

          03, heartbeat+haproxy+web

　　　　後續其實相差無幾

 

　主要是haproxy與lvs區別

　　　　lvs的是經過vrrp協議進行數據包轉發的，提供的是4層的負載均衡。特色是效率高，機器網卡比較吃的緊張。
haproxy能夠提供4層或7層的數據轉發服務，能作到7層的好處是能夠根據服務所處的狀態等進行負載。

　　　　LVS優點:

　　　　　　一、 抗負載能力強，由於lvs工做方式的邏輯是很是之簡單，並且工做在網絡4層僅作請求分發之用，沒有流量，因此在效率上基本不須要太過考慮。在我手裏的 lvs，僅僅出過一次問題：在併發最高的一小段時間內均衡器出現丟包現象，據分析爲網絡問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。

 　　　　　　二、配置性低，這一般是一大劣勢，但同時也是一大優點，由於沒有太多可配置的選項，因此除了增減服務器，並不須要常常去觸碰它，大大減小了人爲出錯的概率

　　　　　　 三、工做穩定，由於其自己抗負載能力很強，因此穩定性高也是瓜熟蒂落，另外各類lvs都有完整的雙機熱備方案，因此一點不用擔憂均衡器自己會出什麼問題，節點出現故障的話，lvs會自動判別，因此係統總體是很是穩定的。

　　　　　    四、無流量，上面已經有所說起了。lvs僅僅分發請求，而流量並不從它自己出去，因此能夠利用它這點來作一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

　　　　　    五、基本上能支持全部應用，由於lvs工做在4層，因此它能夠對幾乎全部應用作負載均衡，包括http、數據庫、聊天室等等。

　　　　haproxy:

　　　　　　1,HAProxy支持TCP協議的負載均衡轉發，能夠對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，你們能夠用LVS+Keepalived對MySQL主從作負載均衡。

　　　　　　 2,支持Session的保持，Cookie的引導；同時支持經過獲取指定的url來檢測後端服務器的狀態　

　　　　　　3,HAProxy負載均衡策略很是多，HAProxy的負載均衡算法如今具體有以下8種：　

　　　　　　　　① roundrobin，表示簡單的輪詢，這個很少說，這個是負載均衡基本都具有的；
　　　　　　　　② static-rr，表示根據權重，建議關注；
　　　　　　　　③ leastconn，表示最少鏈接者先處理，建議關注；
　　　　　　　　④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制相似，咱們用其做爲解決session問題的一種方法，建議關注；
　　　　　　　　⑤ ri，表示根據請求的URI；
　　　　　　　　⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name；
　　　　　　　　⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
　　　　　　　　⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。

 

 

六, 三大負載均衡器特色:

　　　　LVS的特色是：
　　　　　　一、抗負載能力強、是工做在網絡4層之上僅做分發之用，沒有流量的產生；
　　　　　　二、配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率；
　　　　　　三、工做穩定，自身有完整的雙機熱備方案；
　　　　　　四、無流量，保證了均衡器IO的性能不會收到大流量的影響；
　　　　　　五、應用範圍比較廣，能夠對全部應用作負載均衡；
　　　　　　六、LVS須要向IDC多申請一個IP來作Visual IP，所以須要必定的網絡知識，因此對操做人的要求比較高。
　　　　 Nginx的特色是：
　　　　　　一、工做在網絡的7層之上，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構；
　　　　　　二、Nginx對網絡的依賴比較小；
　　　　　　三、Nginx安裝和配置比較簡單，測試起來比較方便；
　　　　　　四、也能夠承擔高的負載壓力且穩定，通常能支撐超過1萬次的併發；
　　　　　　五、Nginx能夠經過端口檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點，不過其中缺點就是不支持url來檢測；
　　　　　　六、Nginx對請求的異步處理能夠幫助節點服務器減輕負載；
　　　　　　七、Nginx能支持http和Email，這樣就在適用範圍上面小不少；
　　　　　　八、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡算法。
　　　　HAProxy的特色是：　　　　　　一、HAProxy是工做在網絡7層之上。　　　　　　二、可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做　　　　　　三、支持url檢測後端的服務器出問題的檢測會有很好的幫助。　　　　　　四、更多的負載均衡策略好比：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現　　　　　　五、單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。　　　　　　六、HAProxy能夠對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡