LVS就是一種實現負載均衡的解決方案。
什麼是服務器集羣？爲什麼要建立服務集羣？
通常服務集羣劃分爲幾大類？又分別適用於什麼場景？每一種服務集羣構建的代表方案有哪些？
個人的理解，以一種通俗易懂的方式講述出來，如果有哪些地方說的不正確的話，希望大家留言指出來。筆者會非是常的感謝！
Cluster服務器集羣，直接理解爲一些單一的服務器的集合通過某種方式組合起來，爲客戶端提供服務。
現今的服務器面臨三個問題：
1、 併發請求數量大，這就要求服務器容量要足夠大2、 在線訪問量大，要求服務器不能中
3、 總體的訪問量龐大，禪理性能要足夠的強
面對這些問題我們以往採取的方式是Scale up:(向上擴展),即是將當前使用的服務器，用比它性能更好的服務器替換掉（新機替換掉老機）。服務器單一管理起來非常方便，但是,要知道換上的新機比老機提升了的性能和在這個新機上的花銷可不是成比增長的，並且還會造成對老機的浪費。所以就有了Scale out(向外擴展)即是以增加機器的方式來提升服務器的性能，這其實就是Cluster“集羣”。
針對以上的三個問題，按服務集羣的功能能將其分爲三個類別：
1、負載均衡集羣（LB,load Balance Cluster）
2、高可用集羣（HA,High Available Cluster）
3、高性能集羣（HP，High Performance Cluster）
負載均衡集羣在Linux中的軟件實現方式：LVS
高可用集羣在Linux中的軟件實現方式:heartbeat corosync
高性能集羣在Linux中的軟件實現方式：hadoop
負載均衡集羣：通過硬件實現的方式，常用到的調度器有F5的BIG IP可處理的併發請求數量高達1000萬，IBM的A10併發請求數量可達600萬，Citrix，Netscaler可處理併發請求數量爲500萬，都可以滿足我們的需求，但是都太貴了，而我們的軟件實現方式很好的彌補了這個缺憾哈！而其中最具代表性之一的解決方案即是淘寶的章文嵩博士創立的LVS。
-----------------------------------LVS框架圖-------------------------------------------
LVS（Linux Vitual Server）---虛擬服務器，在工作當中它是作爲一個前段的Director（調度器）工作的，Director它本身不提供任何的服務，只是將接收到的請求轉發給後端的Real Seerver處理，然後在響應給客戶端。所以我們也稱LVS爲“4 layer switch/route"。LVS本身的兩個基本的組件就是：ipvs和ipvsadm。而ipvs是一個工作在內核當中的,它其實就是相當於做成了netfilter框架的一個模塊。就像netfilter當中有filter表、net表、mangle表，而你現在又加入了Ipvs表，主要是用於讓定義好的規則生效，ipvsadm是工作在用戶空間，用來定義LVS的轉發規則。LVS是工作在INPUT鏈上的。
-------------------------------------轉發過程圖----------------------------------------
Director（調度器）即是負載均衡器，一個合格的Director要滿足以下的要求。
1、考慮服務器負載能力通過某種調度方法，調度後端服務器。
2、考慮後端服務器是否正常工作，這也是需要一種機制來完成，我們稱其爲後端主機健康狀態測。
3、考慮Director本身如果出故障，整個服務癱瘓的問題。這裏不得不用到高可用集羣。即在添加一個Director.
4、爲多臺的Real Server提供一個共享存儲。說到共享存儲就不得不說到DAS、NAS、SAN。
DAS：直接輔加存儲，即直接連接到主機總線上的存儲設備。優點在於存儲容量擴展方便，實施起來很簡單，但是這種方式太過於限制，它必須要和服務器在同一個機架上。
NAS：網絡輔加存儲，雙方共享文件服務器，只要連接到NAS上就可以實現共享存儲。並且Real Server同時寫入的時候不會崩潰，因爲它是文件系統級別的，但是DNS最多隻能同時爲十臺服務器提供共享存儲。
SAN：存儲區域網絡，這種可以說是分佈式文件鎖的機制，
FC SAN光驅動
IP SAN（iSISC）
每個Real Sever都有RIP VIP
每個Drector都有DIP VIP
LVS的三種工作模型：NAT模型-----DR模型-----TUN模型,其中DR模型應用最廣。
NAT模型：網絡地址轉換模型，
NAT模型的特點：
1、Diretor和Real Server(RS)必須在同一個子網中。
2、RIP通常使用私有地址，僅限於本地通信
3、Director工作在Clients和RS中間，負責處理進出的全部報文
4、RS網關要指向DIP
5、可以實現端口轉換（映射）
6、RS可以是任何操作系統
7、Director可能成爲性能瓶頸，所以不適用於教大規模的負載均衡場景
net模型詳解：
net模型圖示：
DR模型：直接路由模型
DR模型的特點：
1、RS跟Director必須在同一物理網上（即中間不能隔路由設備）。
2、RIP可以使用公網地址
3、Director僅處理請求報文
4、RS的網關不能指向DIP
5、不能使用端口映射
6、大多數操作系統可以用於RS
7、一般DR模型的Director能處理比NAT模型多的多的請求
DR模型詳解：
CIP向VIP發出請求，CIP經由路由設備，到達局域網，它的目的是想和Director的VIP通信，但是它不知道VIP的MAC，在局域網內部通訊看的是MAC地址，所以它要發廣播，所有收到廣播包的都會迴應此廣播，此時就會產生問題了，RS1、RS2也會迴應因爲他們也有同樣的VIP啊，那交換機怎麼知道，哪個是Director的MAC呢？所以我們這裏必須要控制RS1和RS2不迴應此廣播包，這就不得不提到兩個內核參數，arp_ignor和arp_annouce，在RS1和RS2上均對這兩個參數給與定義，則RS1和RS2就不會迴應由交換髮出的這個找VIP的對應的MAC的廣播包了。此時數據包就可以到達Director了，Director通過某種調度方法計算髮現RS1符合這個要求，所以它要把這個請求包交給RS1來處理，但是它也不知道RS1的MAC啊，所以它也要發起廣播消息，此時Director發起的廣播是在其內部發起的,每個RS的這個私有的地址都是不一樣的。所以當RS1收到這個廣播的時候發現時找它的，它就會迴應，則此時Director就得到了RS1的MAC，它將請求報文的目標MAC地址換成RS1的MAC地址，然後在將這個請求包返回給交換機，此時交換機就認爲這個請求是發給RS1的，它就會將其發給RS1,RS1收到請求包，直接用自己的VIP給予迴應，不再經由Director.所以這就需要在RS1中定義一條路由"route add -host VIP dev lo:0"明確告知RS1，只要是請求VIP的，我就用lo:0這個上面的VIP來給予迴應。
注意：1、RS和DR都是單網卡的哦，每個RS的VIP是設置在lo:0上的，這個lo:0是虛擬的哈。DR的VIP是在eth0:0上面配置的。
2、由DR發出的廣播包不被RS屏蔽掉的原因是因爲它是廣播的RIP這是他們的私有網絡的地址，剛剛設置的參數arp_ignor和arp_annouce,只是針對VIP的哈
DR模型圖示：
TUN模型：隧道模型
TUN模型的特點
1、RS跟Director不必在同一個物理網絡中
2、RIP一定不能使用私有地址
3、多數情況下Director僅處理請求報文
4、正常情況下響應報文不能經過Director
5、不能使用端口映射
6、僅允許支持隧道協議的操作系統用於RS
___________________________________________________________________
LVS的十種調度方法，分爲靜態和動態兩類。
靜態四種；僅根據算法本身調度，不關心RS上當前的連接狀態。
1、RR
根據規則依次論調,不考慮RS的性能。輪到誰就轉發給誰。
2、WRR
加權輪詢，加入了weight（權重），可以根據RS的性能爲其設置權重值，權重越大功能越強，但是不能發硬當前的服務器的運行的情況。
3、DH
目標地址hash，適用於前段是一個drector後端是幾個緩存服務器，當客戶端第一次訪問到的是RS1的時候，DH這種算法保證，在客戶端刷新後還是訪問的是RS1。
4、SH
源地址hash，用於保證響應的報文和請求的報文是同一個路徑。
動態六種：要將RS得連接狀態計入調度考量標準。
1、LC
least connection，當一個用戶請求過來的時候，就計算下哪臺RS的鏈接誰最小，那麼這臺RS就獲得了下次響應客戶端請求的機會，計算的方法Overhead=active*256+inactive,如果兩者的結果是相同的則從LVS中的規則依次往下選擇RS。這種算法也是不考慮服務器的性能的。
2、WLC
這個就是加了權重的LC，考慮了RS的性能，即是性能好的就給的權重值大一些，不好的給的權重值小一些。缺點就是如果Overhead相同，則會按規則表中的順序，由上而下選擇RS，Overhead=(active*256+inactive)/weight
3、SED
就是對WLC的情況的補充，Overhead=(active+1)*256/weight，加一，就是爲了讓其能夠比較出大小。
4、NQ
never queue 基本和SED相同，避免了SED當中的性能差的服務器長時間被空閒的弊端，它是第一個請求給性能好的服務器，第二個請求一定是給的空閒服務器不論它的性能的好與壞。以後還是會把請求給性能好的服務器
5、LBLC
它就是動態DH和LC的組合，適用於cache羣，對於從來沒有來過的那些新的請求會分給當前連接數較少的那臺服務器。
6、LBLCR
帶有複製功能的LBLC，它的適用場景這裏舉例說明一下，比如說現在又RS1和RS2,第一次訪問RS1的5個請求第二次又來了，理所應到Director將會將其交給RS1，而此時在RS2是非常閒的，所以此時最好的處理方法就是可以將後來的這5個請求分別交給RS1和RS2，所以此時就需要把客戶端第一次請求的資源複製下來。（特殊情況）
活動鏈接active和非活動鏈接inactive小解：
這裏以http爲例，http本身是一種無狀態的鏈接，當客戶端請求訪問的時候，有個等待響應過程，這個時段可以稱其爲活動鏈接active狀態.當服務器端給與響應後，請求因爲keepalive而並未斷開，則此段時間的狀態就是非活動鏈接狀態。
無連接狀態即是無追蹤
cookie即是個標識用於追蹤用戶訪問過哪個資源，追蹤用戶的身份，這種單一的cookie是不安全的
session結合cookie或者url完成用戶跟蹤，客戶端的cookie只需要保留session id敏感信息保留在服務器端.
持久連接是靠director上的持久模板來完成的，模板上的條目用hash保存.
防火牆標記服務，將兩種服務標記成一種服務，用mangle給某數據報文一個標記MARK，但是不具有永久性，所以需要使用持久連接
LVS中的持久連接類型：
PCC
來自同一個用戶端的所有的集羣服務請求通通轉發給後端的某個特定的Real
Server
PPC
將某客戶端的特定的服務請求通過某種算法，轉發給後端的某個特定的Real Server
PFWM
將兩種服務綁定，即這兩種服務都是通過後端所指定的某個Real Sever響應即是將多個PPC和並起來，但是並未達到PCC標準
-p定義持久連接超時時間的，默認是5分鐘
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-O] [-M netmask]
ipvsadm -Ln --persistent-conn這是用於查看長連接的超時時常的
【管理集羣服務】
1、增加集羣服務
ipvsadm -A|E -t|u|f service-address [-s scheduler]
-s sheduler 指定調度方法，如果不指定的話默認是WLC
-t|u|f 分別表示tcp|udp|firemark
2、刪除集羣服務
ipvsadm -D -t|u|f service-address
【管理集羣服務中的RS】
1、增加集羣服務的RS
ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m]
[-w weight]
a|e 其中a表示的是增加 e表示修改
[-g|i|m] -g表示DR模型(gatewaying) -i表示的TUN隧道模型（ipip） m表示的是nat模型(masquerading) ，如果默認不指定的話是DR模型.
2、刪除集羣服務當中的RS
ipvsadm -d -t|u|f service-address -r server-address
【查看服務信息（規則）】
ipvsadm -L|l
-n 不進行反解
-c 查看連接個數
--stats 查看統計總數
--rate 查看連接速率
ipbsadm -Z 清空計數器
【清空所有定義的規則】
ipvsadm -C
【保存集羣服務的規則】
ipvsadm -R = ipvsadm-restore
ipvsadm -S = ipvsadm-save
service ipvsadm save
高可用集羣（High Availabitity Cluster）
高可用集羣的軟件實現方式是：heartbeat corosycn
在SAN共享存儲中用到了HA Cluster,HA的實現即是相當於做一個冗餘
高可用集羣通常會採用可用性來衡量基實際效果。計算機系統的可用性是通過平均無故障時間(MTTF)及平均維修時間(MTTR)來度量。