Linux cluster
一個Linux集群(cluster)就是一組計算機,它們作為一個整體向用戶提供特定的服務。這些單個的計算機系統就是集群的節點(node)。那么問題來了,我們為啥要使用集群技術?它的優點如下:
- 易于擴展,管理員可很方便的增加或刪除集群系統中的節點。
- 高可用性,當集群中某一個節點失效時,其負責的任務可以傳遞給其他節點,有效避免單點故障。
- 高性能,負載均衡的集群系統能夠承擔極大的并發客戶請求。
- 高性價比,可以使用相對廉價的硬件構造出高性能的系統。
既然集群的好處多多,那么常見的集群有哪些呢?
1.LB:load balancing:負載均衡集群
負載均衡集群中有調度器(Director),它處在多臺內部服務器的上層,根據定義的調度方式從下層的服務器組中選擇一臺來響應客戶端發送的請求。
2.HA:highavailability 高可用
顧名思義就是服務的可用性比較高,當某臺服務器故障后不會造成所提供的服務中斷。集群自動將客戶的訪問請求轉交給一個正常工作的服務器。
3.HP:Hight Performance 高性能
高性能的集群是當某一項任務計算量非常大的時候,由一個計算機集群共同來完成這項任務。這種 處理方式我們稱為并行處理機制。一般高性能集群用于科研工作方面。
常見的系統擴展類型有:
scale up(縱向擴展):通過增加硬件資源,即增加更好的設備來滿足性能消耗的需求。但是此方式性價比很低。
scale out(橫向擴展):通過硬件或軟件的方式,將由單一服務器負責的業務需求轉為一組節點服務器來進行處理,此種方式易于擴展且性價比高。
以上是cluster的初步概念,接下來介紹一下由章文嵩博士研究出的負載均衡集群技術LVS。
Linux Virtual Server
一般來說,LVS采用三層結構:調度器、服務器池、共享存儲。LVS工作在OSI七層模型的第四層,所以LVS又有一個別名是四層交換機。因此LVS需要在內核的TCP/IP協議棧對數據流進行過濾篩選,這就需要有內核的模塊來支持,而這樣的過濾轉發規則又是由管理員用戶進行定義的,所以,LVS就是兩段式的架構,在內核空間中工作的是”ipvs”, 而在用戶空間中工作的,用來定義集群服務規則的是”ipvsadm”。
LVS集群類型中的術語:
調度器:director,dispatcher,balancer
VS:Virtual Server, Director, Dispatcher, Balancer
RS:Real Server, upstream server, backend server
CIP:Client IP, VIP: Virtual serve ip , DIP: Director IP,RIP: Real server IP
lvs集群的類型:
lvs-nat:修改請求報文的目標IP; MASQUERADE類型
lvs-dr(direct routing):重新封裝新的MAC地址,默認使用的類型; GATEWAY類型
lvs-tun(ip tunneling):在原請求IP報文之外新加一個IP首部;IPIP類型
lvs-fullnat:修改請求報文的源和目標IP;
lvs-nat:
多目標IP的DNAT,通過將請求報文中的目標地址和目標端口修改為某挑出的RS的RIP和PORT實現轉發;
(1)RIP和DIP必須在同一個IP網絡,且應該使用私網地址;RS的網關要指向DIP;
(2)請求報文和響應報文都必須經由Director轉發;極高負載的場景中,Director可能成為系統瓶頸;
(3)支持端口映射,可修改請求報文的目標PORT;
(4)vs必須是Linux系統,rs可以是任意系統;
lvs-dr:lvs的默認模式
Direct Routing,直接路由;
通過為請求報文重新封裝一個MAC首部進行轉發,源MAC是DIP所在的接口的MAC,目標MAC是某挑選出的RS的RIP所在接口的MAC地址;源IP/PORT,以及目標IP/PORT均保持不變;
Director和各RS都得配置使用VIP;
(1) 確保前端路由器將目標IP為VIP的請求報文發往Director:
在RS上修改內核參數以限制arp通告及應答級別;arp_announce及arp_ignore
(2) RS的RIP可以使用私網地址,也可以是公網地址;RIP與DIP在同一IP網絡;RIP的網關不能指向DIP,以確保響應報文不會經由Director,在RS的lo別名網卡上配置vip地址;
VIP配置在DR上的時候,應該是在eth0:0上,在RS上配置VIP的時候,就必須是lo:0了,否則達不到讓RS不響應VIP的ARP通告的效果。
(3) RS跟Director要在同一個物理網絡即同一廣播域;
(4) 請求報文要經由Director,但響應不能經由Director,而是由RS通過網關直接發往Client;
(5) 不支持端口映射;
lvs-tun:
轉發方式:不修改請求報文的IP首部(源IP為CIP,目標IP為VIP),而在原IP報文之外再封裝一個IP首部(源IP是DIP,目標IP是RIP),將報文發往挑選出的目標RS;可能會因MTU產生分片問題。
(1) DIP, VIP, RIP都應該是公網地址;
(2) RS的網關不能,也不可能指向DIP,在RS的lo別名網卡上配置vip地址;
(3) 請求報文要經由Director,但響應不能經由Director;
(4) 不支持端口映射;
(5) RS的OS得支持隧道功能;
客戶端請求:
client—–CIP VIP——->director——–CIP VIP DIP RIP———realserver(在lo別名上配置vip);
服務器響應請求:
realserver——VIP CIP———client
lvs-fullnat:
通過同時修改請求報文的源IP地址和目標IP地址進行轉發;
CIP –> DIP
VIP –> RIP
(1) VIP是公網地址,RIP和DIP是私網地址,且通常不在同一IP網絡;因此,RIP的網關一般不會指向DIP;
(2) RS收到的請求報文源地址是DIP,因此,只需響應給DIP;但Director還要將其發往Client;
(3) 請求和響應報文都經由Director;
(4) 支持端口映射;
注意:lvs-fullnat型lvs默認不支持需更換支持的內核。
靜態調度算法:根據算法本身進行調度;
rr:roundrobin,輪詢,調度器將外部請求輪流分配到集群中的節點中。 wrr:Weighted RR,加權輪詢,調度器根據事先設置的權重來分配外部請求到集群中的節點。 sh:Source Hashing,實現session sticky,源IP地址hash;將來自于同一個IP地址的請求始終發往第一次挑中的真實服務器Ip,從而實現會話綁定; dh:Destination Hashing;目標地址哈希,將發往同一個目標地址的請求始終轉發至第一次挑中的真實服務器IP,典型使用場景是正向代理緩存場景中的負載均衡;
動態調度算法:根據真實服務器當前的負載狀態及調度算法進行調度。
lc:least connections,調度器通過lc調度算法動態地將網絡請求調度到已建立連接最少的服務器上。 wlc:Weighted Least Connections,調度器通過wlc調度算法根據事先設置的權重優化負載均衡調度。具有較高權重的服務器將承受較大比例的連接請求。 sed:Shortest Expection Delay,在WLC基礎上改進,Overhead = (activeconns+1)*256/權重,不再考慮非活動狀態,把當前處于活動狀態的數目+1來實現,數目最小的,接受下次請求,+1的目的是為了考慮加權的時候,非活動連接過多缺陷:當權重過大的時候,會導致空閑服務器一直處于無連接狀態。 NQ:Never Queue Scheduling NQ,如果有臺 realserver的連接數=0就直接分配過去,不需要再進行sed運算,保證不會有一個主機很空閑。 lblc:基于地址的最小連接數調度(locality-based least-connection):將來自同一個目的地址的請求分配給同一臺RS,此時這臺服務器是尚未滿負荷的。否則就將這個請求分配給連接數最小的RS,并以它作為下一次分配的首先考慮。 LBLCR:Locality-Based Least Connections with Replication,帶復制的基于局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡,目前主要用于Cache集群系統?它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射,而LBLC算法維護從一個目標IP地址到一臺服務器的映射?該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組,按“最小連接”原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載,則按“最小連接”原則從這個集群中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器?同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以降低復制的程度。
本文來自投稿,不代表Linux運維部落立場,如若轉載,請注明出處:http://www.www58058.com/101543