LVS 負載均衡
負載均衡集羣是 Load Balance 集羣。是一種將網絡上的訪問流量分佈於各個節點，以降低服務器壓力，更好的向客戶端提供服務的一種方式。常用
的負載均衡。
開源軟件有Nginx、LVS、Haproxy (ngnix和haproxy是七層負載均衡，LVS是四層負載均衡)
商業的硬件負載均衡設備F5、Netscale。
簡單的理解一下軟件負載均衡。①.所謂分層的負載均衡，都是以網絡的模型來說的。四層就是基於IP和端口的負載均衡，七層就是基於URL等應用
信息的負載均衡。所以簡單的說四層負載均衡就是通過IP和端口接收請求再分發至真實的服務器，七層是通過URL或主機名接收請求，然後分發至真實
的服務器。②.而七層的實現也是在四層的基礎上是實現的，沒有四層就不可能有七層。在第七層上可以做許多事情，比如可以根據七層的瀏覽器類別區
分是手機還是PC，將WEB服務器分爲2組，手機登陸專門的移動端網站。③.對客戶端來說，客戶端好像是訪問的同一臺主機。其實爲了有更好的用戶體
驗，從智能DNS入手，根據客戶端IP來源將域名解析到距離客戶端最近的一臺服務器或者訪問最快速的一臺服務器，但這些內容客戶端都是感覺不到的，
客戶端感覺到的只能是訪問網站很快。一.負載均衡LVS的介紹
負載均衡的原理很簡單，就是當客戶端發起請求時，請求直接發給Director Server（調度器），這時會根據設定
的調度算法，將請求按照算法的規定智能的分發到真正的後臺服務器。以達到將壓力均攤。但是我們知道，http的
連接時無狀態的，假設這樣一個場景，我登錄某寶買東西，當我看上某款商品時，我將它加入購物車，但是我刷新
了一下頁面，這時由於負載均衡的原因，調度器又選了新的一臺服務器爲我提供服務，我剛纔的購物車內容全都不
見了，這樣就會有十分差的用戶體驗。所以就還需要一個存儲共享，這樣就保證了用戶請求的數據是一樣的。所以
LVS負載均衡就分爲3層：☆ 第一層：負載調度器（load balancer/ Director），它是整個集羣的總代理，它在有兩個網卡，一個網卡面對訪問網站的客戶端，
一個網卡面對整個集羣的內部。負責將客戶端的請求發送到一組服務器上執行，而客戶也認爲服務是來自這臺主的。舉個生動
的例子，集羣是個公司，負載調度器就是在外接攬生意，將接攬到的生意分發給後臺的真正幹活的真正的主機們。當然需要將活
按照一定的算法分發下去，讓大家都公平的幹活。
☆第二層：服務器池（server pool/ Realserver），是一組真正執行客戶請求的服務器，可以當做WEB服務器。就是上面例子中的
小員工。
☆第三層：共享存儲（shared storage），它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相
同的服務。一個公司得有一個後臺賬目吧，這才能協調。不然客戶把錢付給了A，而換B接待客戶，因爲沒有相同的賬目。B說客戶
沒付錢，那這樣就不是客戶體驗度的問題了。
二.LVS的實現原理
三.LVS的組成
1.lvs分爲兩個部分，分別是內核模塊和lvs的管理工具。
目前來說，centos6及其以上的內核版本已經包括了ipvs的相關模塊了。
內核支持的ipvs模塊
上圖中的rr，wrr，lc，wlc，lblc等等都是lvs中調度器的調度算法，根據不同的調度算法可以更好的分配服務，實現負載均衡。
而ipvs(ip virtual server)：一段代碼工作在內核空間，實現調度。
ipvsadm客戶端管理工具
上圖是ipvsadm。負責爲ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器(Real Server)。
四.LVS的調度算法
前面已經說了，調度器（directory） 是通過一定的調度算法將服務請求一個一個的分發下去。現在瞭解一下調度算法
LVS一共有10種調度算法。
靜態調度算法（4個）
1.rr（輪叫調度）
輪叫調度：這種是最簡單的調度算法，就是將請求A一個，B一個，A一個，B一個 ...... 循環的發。就算A主機掛掉了，調度器還是會將請求發送到A。十分均衡。
2.wrr（加權輪叫）
加權輪叫調度：這種算法是在rr基礎上實現的，只不過加了權重，權重範圍爲1-100，假設A的服務器性能好，就給A的權重設置的高一點，設爲2，而B主機是1。這樣就實現A二個，B一個，A二個，B一個 ...... 循環的發。這樣照顧到了服務器性能。
3.sh（源地址哈希）
源地址散列：主要是實現將此前的session（會話）綁定。將此前客戶的源地址作爲散列鍵，從靜態的散列表中找出對應的服務器，只要目標服務器是沒有超負荷的就將請求發送過去。就是說某客戶訪問過A,現在這個客戶又來了，所以客戶請求會被髮送到服務過他的A主機。
4.dh（目的地址哈希）
目的地址散列：以目的地址爲關鍵字查找一個靜態hash表來獲得需要的RS。以目標地址爲標準挑選。 功能是和sh近似的，但應用場景不同
（dh舉個例子：假設1號客戶訪問了web集羣的一個動態頁面，調度器將請求轉發個A服務器，A服務器的PHP將這個動態請求運行了一遍，生成了緩存並回應1號客戶。這下2號客戶也訪問了這個動態頁面，調度器應該將請求發給A。畢竟A已經跑過這段程序了，有緩存，對吧。所以這既是dh算法）
接下來是動態算法，動態算法與靜態算法最大的區別就是動態算法考慮了服務器的壓力。
活動鏈接（active）：客戶與服務器建立連接並且有數據傳送
非活動鏈接（inactive）：只是建立連接，沒有數據傳送，沒有斷開連接
動態調度算法（6個）
1.lc（最少鏈接）
最少連接調度：這種算法是看A，和B的主機誰的連接少，請求就發給誰。
簡單算法：active*256+inactive （誰小發給誰）
2.wlc（加權最少鏈接）LVS的理想算法
加權最少鏈接：這種算法就是比lc多了一個加權。
簡單算法：( active*256+inactive )/weight (誰小就發給誰)
3.sed（最短期望延遲）
基於wlc算法，假設A，B的權重分別是1，2 。而A的鏈接數爲1，B的鏈接數爲2 。這樣的話，用wlc算法得出的結果一樣，而明顯B的權重大，B的能力較強。用sed算法的話，就可以避免wlc出現的問題。
簡單算法：（active+1)*256/weight （活動的連接數+1）*256/除以權重 誰小發給誰
A：（1+1）/1
B：（2+1）/2 （B小，交給B）
4.nq（用不排隊）
基於sed算法：在sed的基礎上，若誰的鏈接數爲0，直接將請求發送給他，沒二話
5.LBLC（基於局部性的最少連接）類似於dh，目標地址hash
這個算法主要用於Cache集羣系統，因爲Cache集羣的中客戶請求報文的目標IP地址的變化，將相同的目標URL地址請求調度到同一臺服務器，來提高服務器的訪問的局部性和Cache命中率。從而調整整個集羣的系統處理能力。但是，如果realserver的負載處於一半負載，就用最少鏈接算法，將請求發送給活動鏈接少的主機。
6.LBLCR（帶複製的基於局部性的最少鏈接）
該算法首先是基於最少鏈接的，當一個新請求收到後，一定會將請求發給最少連接的那臺主機的。但這樣又破壞了cache命中率。但這個算法中，集羣服務是cache共享的，假設A的PHP跑了一遍，得到緩存。但其他realserver可以去A那裏拿緩存，這是種緩存複製機制。
最後聊一下http這個協議，因爲上面都有一些包含會話（session），cookie等名詞新手可能會陌生。
當用戶訪問一臺web服務器時，服務器會返回一個客戶標示信息。這個信息就是cookie。cookie會被保存在客戶端的瀏覽器緩存中，那麼這個cookie是幹什麼的呢。
因爲http是無狀態的，服務器並不知道之前有誰訪問了自己。那這就出現了一個問題，假設客戶訪問了一個需要登錄的網頁，可http無狀態，剛登陸過的客戶，服務器又不知道他是誰了。爲了解決這個問題就出現了cookie。客戶端首次訪問時得到cookie，下次再訪問時拿着這個cookie去訪問服務器，服務器就認識客戶端了，知道他是已經登錄過的用戶。所以cookie就是服務器用來追蹤客戶端的身份的。
服務器端爲每一個客戶保存一個cookie和客戶端的對應，這就是回話（session）。session裏保存了客戶訪問的url，對應cookie等等。
在某些特殊場景中需要realserver做到session共享，同步session
五.LVS的工作原理
LVS 的工作模式分爲4中分別是 NAT，DR，TUN，FULL-NAT。其中做個比較，由於工作原理的關係的，NAT的配置最爲簡單，但是NAT對調度器的壓力太大了，導致其效率最低，DR和TUN的工作原理差不多，但是DR中，所有主機必須處於同一個物理環境中，而在TUN中，所有主機可以分佈在不同的位置，服務器一個在紐約，一個在深圳。最多應用的是FULL-NAT。
其中的專業術語
1. DS：Director Server。指的是前端負載均衡器。
2. RS：Real Server。後端真實的工作服務器。
3. VIP：向外部直接面向用戶請求，作爲用戶請求的目標的IP地址。
4. DIP：Director Server IP，主要用於和內部主機通訊的IP地址。
5. RIP：Real Server IP，後端服務器的IP地址。
6. CIP：Client IP，訪問客戶端的IP地址。
1.NAT模式
nat模式
客戶發出請求，發送請求給鏈接調度器的VIP，調度器將請求報文中的目標Ip地址改爲RIP。這樣服務器RealServer將請求的內容發給調度器，調度器再將報文中的源IP地址改爲VIP。
(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c). IPVS比對數據包請求的服務是否爲集羣服務，若是，修改數據包的目標IP地址爲後端服務器IP，然後將數據包發至POSTROUTING鏈。 此時報文的源IP爲CIP，目標IP爲RIP
(d). POSTROUTING鏈通過選路，將數據包發送給Real Server
(e). Real Server比對發現目標爲自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP爲RIP，目標IP爲CIP
(f). Director Server在響應客戶端前，此時會將源IP地址修改爲自己的VIP地址，然後響應給客戶端。 此時報文的源IP爲VIP，目標IP爲CIP
Nat模型的特點
1.很好配置，原理簡單易懂
2.由於調度器的工作量太大，很容易成爲整個集羣系統的瓶頸。
3.RS應該使用私有地址，RS的網關必須指向DIP
4.支持端口映射
2.DR模式
整個DR模式都是停留在第二層的數據鏈路層。直接修改MAC。實現報文的轉發。
dr模式
(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務，若是，將請求報文中的源MAC地址修改爲DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址
(d) 由於DS和RS在同一個網絡中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。
(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之後，將響應報文通過lo接口傳送給eth0網卡然後向外發出。 此時的源IP地址爲VIP，目標IP爲CIP
(f) 響應報文最終送達至客戶端
LVS-DR的特點
1.在前端路由器做靜態地址路由綁定，將對於VIP的地址僅路由到Director Server
2.arptables：在arp的層次上實現在ARP解析時做防火牆規則，過濾RS響應ARP請求。
修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在網卡接口的別名上，並限制其不能響應對VIP地址解析請求。
3.TUN模式
和DR模式差不多，但是比DR多了一個隧道技術以支持realserver不在同一個物理環境中。就是realserver一個在北京，一個工作在上海。
在原有的IP報文外再次封裝多一層IP首部，內部IP首部(源地址爲CIP，目標IIP爲VIP)，外層IP首部(源地址爲DIP，目標IP爲RIP
tun模式
(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 。
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。然後發至POSTROUTING鏈。 此時源IP爲DIP，目標IP爲RIP
(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因爲在外層封裝多了一層IP首部，所以可以理解爲此時通過隧道傳輸）。 此時源IP爲DIP，目標IP爲RIP
(e) RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，而且目標是自己的lo接口VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo接口送給eth0網卡，然後向外傳遞。 此時的源IP地址爲VIP，目標IP爲CIP
(f) 響應報文最終送達至客戶端
LVS-TUN的特點
1. RIP、VIP、DIP全是公網地址
2.RS的網關不會也不可能指向DIP
4.RS的系統必須支持隧道
六.LVS的DR實現
1，準備工作，3臺主機。一臺調度器（DS），2臺真實主機（RS）
其中VIP是虛擬IP，三個主機都要配置這個VIP,
2.給三個主機配置虛擬ip。每臺主機都需要配置。(三個主機都需要配置) realserver配置到lo接口上。
2臺realserver修改內核參數，防止VIP相應arp協議。
這裏必須說明一下，IP是屬於主機的，IP不屬於網卡，假如100這個IP在lo接口上，而11在eth0上。當局域網有人請求100的IP的arp請求時，雖然IP在lo上，該主機還是會相應的，只不過，100會流經可以相應的eth0這個網卡。所以，內核就有將arp請求屏蔽的不同級別。而某臺主機一接入局域網中，他就會向全局域網發廣播，我上線了。
arp_announce :
0: 將本機的IP通過任何接口向外界通告
1:試圖僅向目標網絡與其網絡匹配的地址
2:僅向與本地接口上的地址匹配的網絡進行通告
arp_ignore:
0:
1:僅在請求的目標地址配置請求到達接口上的時候，才相應
或者安裝arp防火牆，執行如下命令。
yum -y install arptable_jf
arptables -A IN -d 192.168.2.100 -j DROP
arptables -A OUT -s 192.168.2.100 -j mangle --mangle-ip-s 192.168.2.11
3.給調度器安裝ipvsadm
再配置相關ipvsadm 規則
查看效果
七.LVS+Heartbeat+ldirectory
這時需要加一個directory，在兩個directory中做負載均衡。需要在2個directory安裝heartbeat和ldirectory。
拷貝配置文件過來並，修改權限。
修改相關配置文件。具體可以參考 heartbeat集羣搭建
特別注意haresources要加上ldirectord這個服務的啓動腳本
配置 ldiectord
複製ldiectord的配置文件到/etc/ha.d下
修改成如下模式
啓動heartbeat。觀察效果。效果是，如果一個realserver掛了。他會自動不會轉發請求給掛掉的realserver
service heartbeat start
當正常時。還是上個實驗的結果
當realser1壞掉後。realser1 自動被移出集羣
當realser1和realser2都壞了的話。directory自動頂上去，並顯示web崩潰
八。LVS+keepalived集羣。
安裝源碼包編譯需要的工具。並下載keepalived的源碼包。 (兩個節點都需要做)
gcc 和 openssl-devel
wget http://www.keepalived.org/software/keepalived-1.2.5.tar.gz 這命令從keepalived官網下載keepalived源碼包。
解壓並且編譯。
黑色部分是重點
configure 後以後再 make和make install。這就不說了，編譯三部曲。
把配置文件都鏈接到正常的文件夾中。
軟鏈接
vi /etc/keepalived/keepalived.conf 編輯配置文件。（寫完了給備機一份，但有些個別地方要改改）
內容如下
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost#接受報警的郵箱
}
notification_email_from [email protected]#郵件的發送地址
smtp_server 127.0.0.1
smtp_connect_timeout 30#連接smtp的超時時間
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER#備機需要改爲BACKUP
interface eth0#HA的檢測網絡接口
virtual_router_id 51#主和備機的id必須一樣，且在0～255
priority 100#主機的優先級，備機應該此值小點
advert_int 1#主備之間的通告時間間隔秒數
authentication {
auth_type PASS#設置驗證類型
auth_pass 1111#設置驗證密碼
}
virtual_ipaddress {
192.168.2.100#VIP
}
}
virtual_server 192.168.2.100 80 {
delay_loop 4#每隔4秒查詢realserver的狀態
lb_algo rr#rr論叫算法
lb_kind DR#LVS的DR模式
# persistence_timeout 50 #保持會話使用的
protocol TCP
real_server 192.168.2.11 80 {
weight 1 #權重
TCP_CHECK { #realserver的狀態檢測設置部分
connect_timeout 3 #3秒無響應超時
nb_get_retry 3 #重試次數
delay_before_retry 3 #重試間隔
}
}
real_server 192.168.2.12 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
改完配置文件就可以直接啓動keepalived了，但有時還可能報錯，
[root@dirmaster ~]# service keepalived start
/etc/init.d/keepalived: Permission denied
chmod a+x /etc/init.d/keepalived 就好了。
現象：
當http出現問題後的現象。
