所謂的linux集羣-其實可以so easy

所謂的集羣知識—只需要簡單的梳理

（圖可能較多，筆者喜歡用圖形的排版方式來梳理知識而告別繁瑣的文字）

   剛解除集羣，這東西龐而多雜的概念，各種集羣的架構：負載均衡、高可用、高性能等等，難免或讓人眼花繚亂。當然想要快速掌握他們，需要的只是從簡單到複雜。那麼筆者同大家一起進行這些知識的梳理，告別繁瑣的文字的束縛，由淺入深，來一層一層剝離他們的關係。

如上圖，我們告別繁瑣的書面信息（這些東西從哪裏來，怎麼得來，由誰搞出來等），先來大致認識下集羣及其分類，大致功能。這些掌握ok再去尋根問底。

---

---

LB負載均衡集羣詳解

定義（本人解釋方法）：

1 2	如果一臺服務器，某個時間點接受了N多用戶的請求，那麼它肯定會出現處理不了導致響應緩慢的問題，而硬件提升服務器太昂貴或者已經達到頂峯，那麼LB的作用就在這裏體現了。 當用戶（大量）請求到來時，由負載均衡器接收，而將這些請求分攤發放給由它管理的服務器上。讓M多服務器同時來承受這些用戶的請求（這些服務器的功能是相同的也就好比同一臺服務器的影分身）。

瞭解了他的大致作用，來看下圖，它的分類

到這裏，我們大致要對LB有個思維上的理解，那麼開始詳解他們的功能

---

---

四層LVS詳解：

LVS由前端的負載均衡器(Load Balancer，LB)和後端的真實服務器(Real Server，RS)羣組成。RS間可通過局域網或廣域網連接。LVS的這種結構對用戶是透明的，用戶只能看見一臺作爲LB的虛擬服務器(Virtual Server)，而看不到提供服務的RS羣。

當用戶的請求發往虛擬服務器，LB根據設定的包轉發策略和負載均衡調度算法將用戶請求轉發給RS。RS再將用戶請求結果返回給用戶。同請求包一樣，應答包的返回方式也與包轉發策略有關。

---

LVS轉發策略：三種模式

(ps：這裏我們需要說明一下具體的一些名詞：)

1 2 3 4 5

Director：複製調度集羣的主機 VIP(virtual ip) 向外提供服務的IP RIP（real ip）後端真正提供接點的ip DIP（Director‘s ip）及負載均衡器（Loader balance，LB）上連接D/RIP的地址（向內部的IP通信的IP，在Director主機上） CIP(custom ip)用戶請求的ip

1、NAT 地址轉換

1 2 3 4 5 6 7 8 9 10

1.集羣節點跟director(引向器)必須在同一個IP網絡中 2.RIP通常是私有地址，僅用於各集羣節點通訊 3.director位於client和real server之間，並負責處理進出的所有通信 4.realserver必須將網關指向DIP 5.支持端口映射 6.realserver可以使用任意操作系統(OS) 7.使用在較大規模應用場景中，director易成爲系統瓶頸（進口出口都在DIP） PS： Director上只需要一個網卡，然後利用別名來配置兩個IP：VIP和DIP。Director在接受到外部主機的請求的時候轉發給Real Server。 Real Server進行回覆時，將請求先交給DIP，然後由VIP轉發給交換機實現通信。

2、DR直接路由 (最常用的)

1 2 3 4 5 6 7 8 9 10 11

1.集羣節點跟directr必須在同一個物理網絡中； 2.RIP可以使用公網地址，實現便捷的遠程管理和監控； 3.director僅負責處理入站請求，響應報文則由realserver直接發往客戶端； 4.realserver不能將網關指向DIP； 5.不支持端口映射； 6.realserver隱藏自己的DIP PS： Director如NAT模型 每個Real Server上都有兩個IP：VIP和RIP，但是VIP是隱藏的，只是用來做請求回覆的（暫時可以這麼理解）。 Director在接受到外部主機的請求的時候轉發給Real Server的時候並不更改目標地址，只是進行一次封裝然後轉給Real Server Real Server在接受到信息以後拆除第一層封裝，並且丟掉，只保留原始的SIP（CIP），然後直接回復給CIP

3、TUN 隧道模型

這個模型跟DR模型有些相似，只不過Real Server跟DIP不在同一物理網絡中。Real Server回覆模式同DR模型相似。DIP向RIP傳送的時候同樣也是進行了一次包裝而裏面保留了CIP的SIP（source ip）。圖不在繼續畫。

1 2 3 4 5 6

集羣節點可以跨越互聯網； RIP必須是公網地址； director僅負責處理入站請求，響應報文則由realserver直接發往客戶端； realserver不能將網關指向DIP； 只有支持隧道功能的OS才能用於realserver； 不支持端口映射

---

LVS的調度算法

LVS是一個L4轉發，因爲他是根據用戶請求的服務不同，提供轉發的，所以他是使用四層的端口進行轉發的，對用戶來說是透明的。

靜態調度方法

1 2 3 4 5 6 7 8

rr： 輪叫，輪詢輪循着,它將請求依次分配不同的RS，也就是在RS中均攤請求。這種算法簡單，但是隻適合於RS處理性能相差不大的情況； wrr: Weight, 加權輪調，它將依據不同RS的權值分配任務。權值較高的RS將優先獲得任務，並且分配到的連接數將比權值較低的RS更多。相同權值的RS得到相同數目的連接數； sh: sourcehash, 源地址hash將來自同一個用戶的請求，始終轉發到特定的路由器或防火牆（平均內網負載），從而保證cookie與session等進行會話綁定； dh: destination hash根據服務的請求轉發到特定的服務器，跟用戶建立粘性，提高緩存命中率。主要用於緩存服務器；

動態調度方法

1 2 3 4 5 6 7 8 9 10 11 12

lc: (least-connect)最少連接，檢查active和inactive，連接數（overhead）最少的接受請求。公式：active*256+inactive 誰小給誰 wlc （weight least-connect）加權最小連接數（集羣最好的算法），公式：（active*256+inactive)/weight誰小給誰（權值表示服務器的性能，越好權值越高。）默認 sed: shortest expected delay （SED）最短期望延遲（誰響應最快給誰），不考慮非活動狀態，在計算overhead之前，把非活動狀態的總數加上1 。公式：(active+1)*256/weight nq: （never query）基於sed, 只要有空閒的，不考慮算法的接受請求； LBLC: (locality-based-least-connect:DH)支持權重(Real server是緩存服務器的),基於地址的最小連接數調度(Locality-Based Least-Connection) , 如果這臺服務器尚未滿負荷，將來自同一目的地址的請求分配給同一臺RS(realserver)，否則分配給連接數最小的RS，並以它爲下一次分配的首先考慮； LBLCR: (帶複製功能的最少連接) （locality-based-least-connect with replication scheduling）是對LBLC的改進，對於某一目的地址，對應有一個RS子集。對此地址的請求，爲它分配子集中連接數最小的RS；如果子集中所有的服務器均已滿負荷，則從集羣中選擇一個連接數較小的服務器，將它加入到此子集並分配連接（同時從本應連接的那臺服務器中複製過來用戶的信息）；若一定時間內，這個子集未被做任何修改，則將子集中負載最大的節點從子集刪除；

---

LVS的命令介紹

1 2 3

ipvsadm：管理集羣服務的命令行工具，工作於用戶空間 ipvs：爲lvs提供服務的內核模塊，工作於內核空間 PS：在linux內核2.4.23之前的內核中模塊默認是不存在的，需要自己手動打補丁，然後把此模塊編譯進內核纔可以正常使用：確定內核中是否有ipvs模塊，grep-i 'ip_vs'/boot/config-2.6.18-308.el5

ipvsadm命令

ipvsadm 功能及使用：

1 2 3 4 5 6 7 8 9 10 11 12

1.定義集羣服務默認方法：wlc ipvsadm -A|-E -t|-u|-f VIP:PORT {tcp|udp|firewall mark} [-s scheduler調度算法] -A 添加 -t: TCP協議的集羣 -u：UDP協議的集羣 service-address:IP:PORT -f：FWM 防火牆標記fileware mark server-address： Mark Number -E 修改 -D 刪除 ipvsadm -D -t|-u|-f VIP:PORT 刪除定義的集羣 # ipvsadm -A -t 172.16.100.1:80 -s rr

2.要爲集羣服務定義realserver

1 2 3 4 5 6 7 8 9 10 11 12 13 14

ipvsadm -a|-e -t|-u VIP:port -r REALSERVER:port -g|-i|-m(模型) [-w weitht] -a 添加 -t|-u|-f service-address：實現定義好的某集羣服務 -r server-address: 某RS的地址，在NAT模型中，可使用IP:PORT實現端口映射 -e 修改 -w 權重 -d 刪除 ipvsadm -d -t|-u VIP:port -r REALSERVER:PORT -C 情況規則 -R 恢復 -S 保存 其中模式中的-g|-i|-m分別用於dr|tun|nat # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.8 -m # ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.9 -m

3.查看

1 2 3 4 5 6 7 8 9

ipvsadm -l|-L|--list -n 數字的方式來顯示主機地址和端口號 --stats顯示統計的數據信息 --rate 顯示統計的速率 --timeout: 顯示tcp、tcpin和udp的會話超時時長 --sort：根據協議、地址和蹲坑進行排序 -c：顯示當前ipvs連接狀況 -Z: 清空，重新計數

4.刪除所有集羣服務

1	-C：清空ipvs規則

5.保存規則

1 2 3 4 5 6 7

-S # service ipvsadm save 在 /etc/sysconfig/ipvsadm.web 或者 # ipvsadm -S > /path/to/somefile 載入此前的規則： -R # ipvsadm -R < /path/from/somefile

實驗：

由於實驗環境約束，將對NAT模型及DR模型進行演示。

由於實驗過程加起來有點長，本人將在後邊的博客中進行貼出。此處留位子以便以後進行編輯。

---

---

HA高可用集羣詳解

什麼是高可用集羣

高可用集羣是指以減少服務中斷時間爲目的的服務器集羣技術。它通過保護用戶的業務程序對外不間斷提供的服務，把因軟件/硬件/人爲造成的故障對業務的影響降低到最小程度。高可用集羣的應用系統有多樣化發展趨勢，用途也越來越多樣化，同時帶來了配置及可操作性方面的複雜性，因此選擇好的高可用軟件至關重要。

PS：上邊是學術界給出的說法，筆者覺得一句話就可以了：保證服務不間斷安全運行的方式。

少一點文字，直接上關係圖：

結合什麼是高可用集羣的概念與這張圖。大概可以劃分下其中大致關係：

split-brain:腦裂：

腦裂擾亂心跳信息的傳遞，集羣節點無法有效獲取其它節點的狀態信息，產生腦裂

什麼是狀態信息，他們怎麼傳播狀態信息？

1 2 3

節點A B爲主從關係（1個掛掉由另外一個接替關係），但是爲了更好的確保他們是否知道對方是否出現故障（掛掉），雙方（當然節點多的情況下你懂的）要進行通信（也就是發送狀態信息），也可以將之稱之爲（heartbeat），這個傳播的通道即爲 Messaging Layer。 腦裂的後果之一： 搶佔共享存儲：假如節點A B都連接到一臺MySQL，如果A正在寫入數據到表中，但是突然發生了腦裂，B默認接收不到A的信息自然會認爲A壞掉了，從而接管A的位子，正式連接到MySQL，恰巧連接到了A正在寫入數據的表中，那麼雙方都在寫入，如果都進行存儲，勢必會發生文件系統崩潰。當然如果是三個節點，ABC，如果AB可以通信。C他們都連接不到，那麼自然會認爲是C壞掉了，然後幹掉C。

避免腦裂的方式：

1 2 3 4 5 6

1、在A和B之間連接一個硬盤，讓他們不停的往裏面寫數據，當檢測到對方停止寫數據時，自然認爲他壞掉了。於是幹掉。 2、當節點爲多節點的時候，可以引入“仲裁機制”：比如2個節點的場景，A節點性能好，給他2位的權位，B位1位的。如果通信不到，A就幹掉B。多節點的情況類似。 without_quorum_policy“法定票數”不夠仲裁的情況下：（根據權重票數分法不同）資源隔離設備： freeze：凍結 stop：關閉停止 ignore：忽略，

CRM: Cluster Resource Manager: 集羣資源管理器（CRM是運行在節點上的）

搜索每一個資源的狀態，來計算出來資源節點應該運行的級別上，DC。

1 2 3 4 5 6 7 8 9

DC: Designated Coordinator : 指定的協調器（計算粘性的） （DC:PE,TE) PE：策略引擎 Policy Engine ：得出結果 TE：事務引擎Transaction：指揮執行 LRM: Local Resource Manager: 本地資源管理器 接受TE的指揮，從而在某個節點上運行 LSB：linux Standard Base 符合linux標準庫的腳本： RA：Resource Agent資源代理（俗稱腳本） RG：Resource Group 資源組（將VIP 和IPVS 定義在一個資源組）

資源約束：Constraint （資源粘性）

1 2 3 4 5 6 7 8 9 10

排列約束：coloationconstraint 資源是否能夠運行於同一節點 score: 正值：可以在一起負值：不能在一起 -inf：負無窮 inf：正無窮 位置約束：location constraint , score(分數) 正值：傾向於此節點 負值：傾向於逃離此節點 順序約束(order constraint) 定義資源啓動或關閉時的次序 VIP-IPVS