Linux企業運維——LVS負載均衡
(臨時筆記,以后會詳細修補)
文章目錄
- Linux企業運維——LVS負載均衡
- 1、LVS簡介
- 2、DR模式
- 3、使用DR模式實作負載均衡
- 4、問題解決
- 5、LVS的10個調度演算法簡介
1、LVS簡介
LVS(Linux Virtual Server)即Linux虛擬服務器,是一個虛擬的服務器集群系統,可以在unix/linux平臺下實作負載均衡集群功能,LVS是一種集群(Cluster)技術,采用IP負載均衡技術和基于內容請求分發技術,調度器具有很好的吞吐率,將請求均衡地轉移到不同的服務器上執行,且調度器自動屏蔽掉服務器的故障,從而將一組服務器構成一個高性能的、高可用的虛擬服務器,整個服務器集群的結構對客戶是透明的,而且無需修改客戶端和服務器端的程式,
根據LVS作業模式的不同,真實服務器會選擇不同的方式將用戶需要的資料發送到終端用戶,LVS作業模式分為NAT模式、TUN模式、以及DR模式,
2、DR模式
- DR模式:通過直接路由實作虛擬服務器,DR模式是通過改寫請求報文的目標MAC地址,將請求發給真實服務器的,而真實服務器回應后的處理結果直接回傳給客戶端用戶,DR模式可以極大的提高集群系統的伸縮性,而且DR模式沒有IP隧道的開銷,對集群中的真實服務器也沒有必要必須支持IP隧道協議的要求,但是要求調度器與真實服務器都有一塊網卡連接到同一物理網段上,必須在同一個局域網環境,
- 原理:LVS通過控制IP來實作負載均衡,ipvsadm是其具體的實作模塊,
- ipvsadm的主要作用:安裝在調度器上面,在調度器上虛擬一個對外訪問的IP(VIP),用戶訪問VIP,到達調度器,調度器根據一定的規則選擇一個真實服務器,處理完成后然后回傳給客戶端資料,
3、使用DR模式實作負載均衡
(1)實驗環境:server1為調度器,負載流量均衡(基于4層即傳輸層進行調度,調度演算法有WRR/WLC等,傳輸協議為TCP/UDP),server2和server3為真實服務器節點,
(2)server1安裝ipvsadm(用于用戶端管理LVS的策略規則)

(3)書寫策略:在server1上添加虛擬一個對外訪問的IP:172.25.33.100(vip),即提供虛擬服務的ip地址,也可以直接用原有IP,但最好獨立出來


(4)ipvsadm -A 添加規則;-t tcp協議;-s 調度;rr 輪叫
- -a向tcp虛擬服務添加
- -r real server
- -g 直連即DR模式
ipvsadm -ln:查看當前連接情況(-ln不用決議),
Forward:轉發方式,當前是路由轉發;
Weight:權重;
ActiveConn:當前活躍的連接數;
InActConn:當前不活躍的連接數

(5)server2和server3安裝httpd服務,并開啟


此時真機使用curl 172.25.33.2可以顯示server的發布頁面,但curl 172.25.33.100沒有反應,這是因為LVS-DR集群型別要求,當用戶向vip發起請求時,調度器和真實服務器上必須都要有vip,因此需要給server2和server3添加虛擬IP,


(6)server2和server3分別添加vip


此時真機使用curl 172.25.33.100,出現輪叫

(7)ARP協議是將IP地址映射為MAC地址的協議,其在協議上使用ARP請求及ARP應答報文來實作
arp -d是洗掉ARP快取串列的命令,可以洗掉所有的ARP快取,也可以洗掉指定的ARP快取
此時使用arp -an查看本地ARP快取的172.25.33.100對應的MAC地址為調度器server1的地址,當真機執行arp -d 洗掉指定虛擬IP的ARP快取后,此時不能過濾得到172.25.33.100的MAC地址,再次Ping之后又可以得到,但是是server3的地址,不是調度器的地址(誰先回應就快取誰的MAC地址)



此時curl 172.25.33.100,只出現了server3的發布頁面,說明此時客戶端向vip發起請求時,并沒有經過調度器直接到達了真實服務器

(8)為了解決這一問題,需要給server2和server3安裝ARP防火墻arptables(用于管理內核中的ARP包過濾規則表)

設定APR配置規則,DR模式要求服務器節點應該禁掉設備的APR回應
arptable_filter 只有一個表 filter ,不指定 -t 表名時默認就是 filter 表,
filter表有三個鏈,一個是INPUT,表示外面發進來的ARP包;另外一個是OUTPUT,表示本機發出的ARP包;第三個是FORWARD,轉發ARP包,
-A:向規則鏈中追加規則;
-d:指定要匹配ARP包的目的IP地址;
-j:指定滿足添加的規則時執行的動作;
-s:指定要匹配ARP包的源ip地址;
-g:直連
-r:真實服務器地址
當資料包的目的地址時100時就丟棄該資料包,當從本機發送出的資料包IP是100時,mangle轉換資料包源地址,偽裝源地址IP為172.25.0.2,

設定完畢,保存arptables規則,此時重啟arptables服務后,即可看到所添加的規則,


此時當真機執行arp -d 洗掉指定的虛擬IP,ping 之后,過濾得到172.25.33.100的MAC地址是server1的MAC地址,此時使用curl 172.25.33.100,可以輪叫


【 client->DR-RS->clinet】
1:DR和RS在同一個vlan(局域網)中,DR和RS的vip會沖突,資料包必須在DR修改mac,丟棄RS的vip,mac在二層資料鏈路層,不支持路由,所以DR和RS需要在同一vlan
2:DR>Tunnel(隧道模式)>NAT(dnat和snat,進出各1此,資料是原路經回傳)>fullNAT(進2次出2次)
3:ipvs和iptables,iptables>ipvs,firewall不需要地址轉換
4、問題解決
1、某臺REALServer down 了,怎么辦

此時curl 172.25.33.100 已經無法訪問server2,客戶端curl 172.25.33.100會報錯

但是在server1中ipvsadm -ln 仍能檢測到server2

解決辦法:
使調度策略實時更新
server1:
(1)yum install keepalived (健康檢測)
ipvsadm沒有健康檢測功能,即檢測策略對應的后端服務是否正常,因此我們需要安裝keepalived

(2)yum install postfix mailx

(3)修改keepalived的主組態檔/etc/keepalived/keepalived.conf
(vrrp虛擬路由冗余協議,keepalived利用這一協議實作了高可用)
notification_email:設定通知郵件,出了問題給誰發送郵件notification_email_from:由誰發送
超時
路由id
注釋vrrp_strict,這一引數功能是在出問題時抓取資料包

主虛擬路由MASTER:向所有備用虛擬路由BACKUP發送“心跳包”,備用虛擬路由只負責接收,當備用虛擬路由接收不到時,priority優先級最高的備用虛擬路由代替MASTER提供虛擬服務,數字越高,優先級越高,所以MASTER優先級數字一定要最大
虛擬路由id:確認哪些虛擬路由是同一個LVS集群的; 修改vip:改成自己設定的vip;

虛擬服務陳述句塊:
delay_loop:每s/次健康檢測;
lb_algo:調度演算法;
persistence_timeout:持久連接,即在多長時間內DR會將所有連接請求持續調度給一個后端;(80埠沒必要) 寫真實服務器模塊
(之后的刪掉)

(4)此時刪掉server1上手動設定的虛擬ip172.25.33.100,ipvsadm -C清除設定的規則,啟動keepalived軟體

ipvsadm -ln 能看到虛擬ip172.25.33.100由keepalived自動生成

stop server2的httpd服務

查看日志,查看日志提示的郵件,可以知道哪臺真實主機up或者down;ipvsadm -ln 將檢測不到server





注意:如果server1也安裝了httpd服務,curl 172.25.33.100不會訪問server1的80
2、lvs down怎么辦(LVS冗余,高可用):
(1)server1停止httpd服務

(2)創建虛擬機快照檔案server4(高可用(master>backup)),同樣的修改其主機名和IP
server4安裝keepalived,并拷貝server1的keepalived.conf檔案


(3)在server4上修改BACKUP、優先級

重啟keepalived服務,之后安裝ipvsadm(用于管理LVS的策略規則)

ipvsadm -ln:查看當前連接情況

查看server4的日志,可以看到此時的server4是BACKUP

當server1停止keepalived服務后,再次查看server4的日志,可以看到此時的server4是MASTER


過濾得到172.25.33.100的MAC地址是server4的MAC地址


再次開啟server1的 keepalived服務后,過濾得到172.25.0.100的MAC地址是server1的MAC地址,此時server4為BACKUP



5、LVS的10個調度演算法簡介
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.源地址散列調度(Source Hashing 簡稱’SH’)演算法先根據請求的源IP地址,作為散列鍵(Hash Key)從靜態分配的散串列找出對應的服務器,若該服務器是可用的且并未超載,將請求發送到該服務器,否則回傳空,它采用的散列函式與目標地址散列調度演算法的相同,它的演算法流程與目標地址散列調度演算法的基本相似,
9.最短期望的延遲調度(Shortest Expected Delay 簡稱’SED’)演算法基于WLC演算法,舉個例子,ABC三臺服務器的權重分別為1、2、3 ,那么如果使用WLC演算法的話一個新請求進入時它可能會分給ABC中的任意一個,使用SED演算法后會進行一個運算
A:(1+1)/1=2
B:(1+2)/2=3/2
C:(1+3)/3=4/3
就把請求交給得出運算結果最小的服務器,
10.最少佇列調度(Never Queue 簡稱’NQ’)演算法,無需佇列,如果有realserver的連接數等于0就直接分配過去,不需要在進行SED運算,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/289801.html
標籤:其他
