初識Linux集群

Linux集群

Linux集群（cluster）就是一組Linux電腦，它們作為一個整體向用戶提供一組網路資源，這些單個的電腦系統就是集群的節點（node）。一個理想的集群，用戶是不會意識到集群系統底層的節點的，在他們看來，集群是一個系統，而非多個電腦系統，並且集群系統的管理員可以隨意增加和刪改集群系統的節點。
　　Linux集群系統的優點主要有4方面：
1、易於擴展，管理員可很方便的增加或刪除集群系統中的節點。
2、高可用性，當集群中某一個節點失效時，其負責的任務可以傳遞給其他節點，有效避免單點故障。
3、高性能，負載均衡的集群系統能夠承擔極大的併發客戶請求。
4、高性價比，可以使用相對廉價的硬體構造出高性能的系統。
　　常見的Linux集群類型包括：
1、LB：Load Balancing，負載均衡集群
負載均衡集群中有調度器（Director），它處在多台內部伺服器的上層，根據定義的調度方式從下層的伺服器組中選擇一臺來響應客戶端發送的請求。
2、HA:High Availability，高可用性集群
顧名思義就是服務的可用性比較高，當某台伺服器故障後不會造成所提供的服務中斷，集群自動將客戶的訪問請求轉交給一個正常工作的伺服器。
3、HP:Hight Performance，高性能
高性能的集群是當某一項任務計算量非常大的時候，由一個電腦集群共同來完成這項任務，這種 處理方式我們稱為並行處理機制。一般高性能集群用於科研工作方面。
　　常見的Linux集群擴展類型（組建方式）有：
1、scale up（縱向擴展）：通過增加硬體資源，即增加更好的設備來滿足性能消耗的需求。但是此方式性價比很低。
2、scale out（橫向擴展）：通過硬體或軟體的方式，將由單一伺服器負責的業務需求轉為一組節點伺服器來進行處理，此種方式易於擴展且性價比高。

LVS，Linux Virtual Server

初步認識Linux Cluster後，我們進一步介紹負載均衡集群技術LVS（Linux Virtual Server）。

　　LVS是章文嵩博士發起的自由軟體項目，它的官方站點是http://www.linuxvirtualserver.org。LVS工作在內核空間，實現TCP/IP協議群的四層路由，在Linux2.4內核以前，使用LVS時必須要重新編譯內核以支持LVS功能模塊，但從Linux2.4內核以後已經完全內置了LVS的各個功能模塊，無需給內核打任何補丁，可以直接使用LVS提供的各種功能。
　　LVS採用三層結構：調度器、伺服器池、共用存儲，結構如下圖：

負載調度器（load balancer/Director）：由一臺或多台負載調度器組成，主要作用類似一個路由器，將用戶請求分發給伺服器池上的real server；
伺服器池（server pool/Realserver）：一組真正執行客戶請求的伺服器，執行的服務一般有WEB、MAIL、FTP和DNS等。
共用存儲（shared storage）：為伺服器池提供一個共用的存儲區，能使得伺服器池擁有相同的內容，提供相同的服務。

　　LVS需要在內核的TCP/IP協議棧對數據流進行過濾篩選，這就需要有內核的模塊來支持，而這樣的過濾轉發規則又是由用戶進行定義的，我們可以認為LVS是兩段式的架構，在內核空間中工作的是”ipvs”，而在用戶空間中工作的，用來定義集群服務規則的是”ipvsadm”。

　　LVS集群類型相關術語：

　　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可以是任意系統
圖解：

1、客戶端訪問集群的VIP，請求WEB資源(請求報文：源地址為CIP，目標地址為VIP)；
2、Director收到客戶端的請求報文，會修改請求報文中的目標地址(VIP)為RIP，並且將請求根據相應的調度演算法送往後端WEB伺服器(請求報文：源地址CIP，目標地址為RIP)；
3、WEB伺服器收到請求，檢查報文是訪問自己的而自己也提供WEB服務，就會響應這個請求報文，併發送給Director(響應報文：源地址RIP，目標地址CIP)；
4、Director收到WEB伺服器的響應報文，會根據自己內部的追蹤機制，判斷出用戶訪問的是VIP，此時會修改源地址為VIP並響應客戶端請求(響應報文：源地址VIP，目標地址CIP)。

　nat模型優劣勢：
　　優勢：節點伺服器使用私有IP地址，與負載調度器位於同一個物理網路，安全性比DR模式和TUN模式要高。
　　劣勢：調度器位於客戶端和集群節點之間，並負責處理進出的所有通信(壓力大的根本原因)，大規模應用場景中，調度器容易成為系統瓶頸。

lvs-dr：lvs的預設模式
通過為請求報文重新封裝一個MAC首部進行轉發，源MAC是DIP所在的介面的MAC，目標MAC是某挑選出的RS的RIP所在介面的MAC地址；源IP/PORT，以及目標IP/PORT均保持不變。
要點：
（1）Director和各RS都得配置使用VIP；
（2）確保前端路由器將目標IP為VIP的請求報文發往Director：通過在RS上修改內核參數以限制arp通告及應答級別(arp_announce及arp_ignore)；
（3）RS的RIP可以使用私網地址，也可以是公網地址；RIP與DIP在同一IP網路；RIP的網關不能指向DIP，以確保響應報文不會經由Director；VIP配置在DR上的時候，應該是在eth0:0上，在RS上配置VIP的時候，就必須是lo:0了，否則達不到讓RS不響應VIP的ARP通告的效果。
（4）RS跟Director要在同一個物理網路即同一廣播域；
（5）請求報文要經由Director，但響應不能經由Director，而是由RS通過網關直接發往Client；
（6）不支持埠映射
圖解：

1、客戶端CIP的請求發送給Director調度器的VIP；
2、Director調度器收到客戶端的請求包後，將數據包的MAC地址改成Director調度器選擇的某一臺RS的MAC地址，並通過交換機(數據鏈路層)發送給RS伺服器(因為MAC地址是RS的MAC地址，所以，RS可以接收到該數據報)，註意：此時數據包的目的及源IP地址沒有發生任何改變；
3、 (1) RS的數據鏈路層收到發送來的數據報文請求後，會從鏈路層往上傳給IP層，此時IP層需要驗證請求的目標IP地址。因為包的目標IP(即VIP)並不是像常規數據報那樣為RS的本地IP，而僅僅目的MAC地址是RS的。所以，在RS上需要配置一個VIP的LoopbackDevice，是因為LoopbackDevice是伺服器本地使用的網路介面，對外是不可見的，不會跟Director的VIP衝突；
(2) RS處理數據包完成後，將應答直接返回給客戶端(源IP為VIP，目標IP為CIP)，響應的數據報不再經過Director調度器。因此如果對外提供LVS負載均衡服務，則RS需要連上互聯網才能將應答包返回給客戶端。RS最好為帶公網IP的伺服器，這樣可以不經過網關直接回應客戶；如果多個RS使用了同一網關出口，網關會成為LVS架構的瓶頸，會大大降低LVS的性能。

　dr模型優劣勢：
　　優勢：負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端，大大提高了伺服器併發能力。
　　劣勢：(1) LVS-RS間必須在同一個VLAN； (2) RS上綁定VIP，風險大。

lvs-tun：
轉發方式：不修改請求報文的IP首部（源IP為CIP，目標IP為VIP），而是在原IP報文之外再封裝一個IP首部（源IP是DIP，目標IP是RIP），將報文發往挑選出的目標RS；RS直接響應給客戶端（源IP是VIP，目標IP是CIP）。
要點：
（1）DIP，VIP，RIP都應該是公網地址；
（2）RS的網關不能，也不可能指向DIP，在RS的lo別名網卡上配置vip地址；
（3）請求報文要經由Director，但響應不能經由Director；
（4）不支持埠映射；
（5）RS的OS得支持隧道功能
圖解：

1、用戶發送請求到Director的VIP請求服務；
2、當用戶請求到達Director的時候，根據調度演算法選擇一臺RS進行轉發，這時使用隧道（tun）封裝兩個IP首部，此時源IP是DIP，目標IP是RIP；
3、當RS接收到數據報後，看到外層的IP首部，目標地址是自己，就會拆開封裝，解析完畢後，發送響應報文，源IP是VIP，目標IP是CIP。

　tun模型優劣勢：

　　優勢：實現了異地容災，避免了一個機房故障導致網站無法訪問。
　　劣勢：RS配置複雜。

lvs-fullnat：
通過同時修改請求報文的源IP地址和目標IP地址進行轉發
要點：
（1）VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網路；因此，RIP的網關一般不會指向DIP；
（2）RS收到的請求報文源地址是DIP，因此，只需響應給DIP；但Director還要將其發往Client；
（3）請求和響應報文都經由Director；
（4）支持埠映射；
（5）lvs-fullnat型lvs預設不支持需更換支持的內核
圖解：

1、客戶端將請求發送給Director的VIP請求服務；
2、VIP通過調度演算法，將請求發送給後端的RS，這個時候源地址改成DIP，目標地址改成RIP；
3、RS接收到請求後，由於源地址是DIP，則一定會對DIP進行回應；
4、Director收到RS的響應後，修改數據報的源地址為VIP，目標地址為CIP進行響應。

註意：此調度方式還沒有正式被Linux官方錄入系統標準庫，所以如果向使用此模式，需要去lvs官網下載源碼，並且需要重新編譯系統內核才可使用。

　　LVS的調度演算法：

靜態調度演算法：根據演算法本身進行調度
rr：roundrobin，輪詢，調度器將外部請求輪流分配到集群中的節點中；
wrr：Weighted RR，加權輪詢，調度器根據事先設置的權重來分配外部請求到集群中的節點；
sh：Source Hashing，實現session sticky，源IP地址hash，將來自同一個IP的請求始終發往第一次挑中的真實伺服器IP，從而實現會話綁定；
dh：Destination Hashing，目標地址hash，將發往同一個目標地址的請求始終轉發至第一次挑中的真實伺服器IP，典型使用場景是正向代理緩存場景中的負載均衡

動態調度演算法：根據真實伺服器當前的負載狀態及調度演算法進行調度
lc：least connections，調度器通過lc調度演算法動態地將網路請求調度到已建立連接最少的伺服器上；
wlc：Weighted Least Connections，調度器通過wlc調度演算法根據事先設置的權重優化負載均衡調度，具有較高權重的伺服器將承受較大比例的連接請求；
sed：Shortest Expection Delay，在wlc基礎上改進，Overhead=(activeconns+1)*256/權重；
nq：Never Queue Scheduling，如果有台 realserver的連接數＝0就直接分配過去，不需要再進行sed運算，保證不會有一個主機很空閑；
lblc：locality-based least-connection，基於地址的最小連接數調度，將來自同一個目的地址的請求分配給同一臺RS，此時這台伺服器是尚未滿負荷的。否則就將這個請求分配給連接數最小的RS，並以它作為下一次分配的首先考慮；
lblcr：Locality-Based Least Connections with Replication，帶複製的基於局部性最少鏈接”調度演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統，它與lblc演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的映射，而lblc演算法維護從一個目標IP地址到一臺伺服器的映射。