集羣的基本概念
隨着計算機科學的發展，對計算機的性能要求越來越高，比如在很多流量比較大的門戶網站以及科學實驗環境中需要海量計算的環境，這時候就迫切需要後端的服務器性能有提升。而對於提升後端服務器性能所採用的方式有兩種，其一爲提升服務器本身的性能，即向上擴展，通過增加服務器的內存，CPU核心數等來實現；其二就是向外擴展，一臺服務器不能完成的任務就使用兩臺、三臺甚至更多。在此，以不同的方式把許多服務器組合起來的服務器組就是集羣。
集羣的分類
按照集羣功能的不同，可以把集羣分爲以下三類：
LB集羣
LB即Load Balancing的首字母縮寫，即負載均衡。其主要實現的目的是爲了降低後端服務器的壓力，通過不同的調度方式把來自客戶端的請求發給後端的終端服務器，也就是後端有多臺此種集羣主要用於高併發請求且請求都類似的環境,如WEB服務。
HA集羣
HA（High Availability），即高可用集羣，此類集羣強調的是可靠性，例如在負載均衡集羣實現上，通常會採用一臺調度器對客戶端的請求作出決策，所以此時若調度器出現故障則會成爲整個WEB站點的瓶頸，此時就可以對LB集羣做高可用，通過添加多個冗餘的調度器來降低其因爲單點故障造成的站點整體宕機。
HP集羣
HP( high Performance)，即高性能集羣，也被稱爲科學集羣，此類集羣，該類集羣常見於科學計算中，比如，需要計算海量數據時，一臺服務器無法勝任就採取多臺服務器構建集羣來實現，所以此類集羣就被稱爲科學集羣。
集羣的實現方式
集羣的實現方式有多種，從結構上來說可以分爲以下幾類：
NAT
NAT（Network Addiress Translate）即網絡地址轉換，使用NAT方式的原理非常簡單，通常需要一臺單獨的服務器作爲整個集羣服務的“總指揮官”，負責把前端客戶端發來的請求報文發送到後端真實服務器上，而現實的方式也就是把請求報文首部的目標地址修改爲後端相應真實服務器的地址，然後當後端服務器處理完請求後生成響應報文發給前端調度器，調度器又把響應報文的報文首部的源地址改爲自己的，讓客戶以爲響應自己請求的就是自己請求的那臺服務器。其基本框架如下圖所示：
圖1 NAT模型示意圖
從其工作原理上來說使用NAT有一下幾個特點：
調度器（director）必須有兩塊網卡，一塊網卡配置有公網IP，負責接收前端客戶端發送過來的請求。而另一塊配置私網IP，負責和後端真實服務器（Real Server）組通信。
由於前端客戶端發送過來的請求還需要經過調度器處理，所以可把響應的端口映射爲非客戶端初始請求服務的端口。
由於不管是客戶端發送請求的報文，還是後端真實服務器響應的響應報文都需要調度器的處理，所以調度器性能要求一般非常高，且容易成爲整個集羣服務器組的瓶頸。
由於後端服務器組只要求能對客戶端的請求做出響應即可，所以後端服務器可安裝任意操作系統即可。
DR
DR爲Director Route的縮寫，即直連路由。其工作原理大致爲，當前端客戶端發送來請求報文時，調度器接收到，並識別出此請求報文所請求的服務是自己管轄服務器所提供的服務，隨即把報文再次封裝，添加新的報文首部，源地址不變，把目標地址改爲調度器隨機選取的真實服務器的MAC地址，並廣播出去，後端真實服務器接收到該報文後作出響應，響應時，Real Server會使用調度器的VIP，然後把響應報文直接發給客戶端，不再經過調度器即可完成。其大體結構如下圖所示：
圖2 DR模型示意圖
根據其工作原理，DR有以下幾個特點：
由於調度器要直接與真實服務器通信，所以調度器和後端真實服務器的各個節點必須在同一網絡內。
後端節點可使用公網IP，以此方便管理與維護。由於調度器並未修改請求報文的報文首部，而是直接再次封裝，所以後端真實服務器可以直接響應給客戶端，因此調度器只負責處理前端客戶端請求，不負責處理後端響應。
相對NAT來說，由於DR模式是由後端真實服務器直接響應，所以不能完成端口映射。
TUN
TUN爲Tunneling的縮寫，即隧道技術。其工作原理和NAT模式相似，但是調度器在處理請求報文是是通過二次封裝請求報文來實現，封裝時使用調度器的地址爲源地址，目標地址即爲Real Server的地址，當Real Server收到該報文後會把該報文拆分，獲得客戶端地址，響應時就直接和客戶端交互，不會經過Virtual Server。因此，使用隧道技術會大大降低調度器的壓力，其工作流程如下圖所示：
圖 3 TUN模型示意圖
TUN主要特點如下：
集羣中的節點，即後端真實服務器可以跨越互聯網，因此，調度器的位置和真實服務器的位置更加靈活多變。但是跨越互聯網卻使用更多的公有IP，造成共有IP的大量浪費，在當今共有IP比較緊缺的前提下，跨越互聯網的TUN模型並不是明智的選擇。
和DR一樣，隧道技術可實現端口映射。且調度器只負責處理前端的客戶所發請求報文，而響應報文則由真實服務器直接發送給客戶端。
由於需要具有隧道技術的Real Server才能響應客戶端，所以後端Real Server的操作系統必須爲具備隧道技術的操作系統。
Full NAT
正如名字一樣，Full NAT模型就是完全地址轉換的意思，在NAT模型中，來自客戶端的請求會被調度器修改其目標地址，然後轉發給後端的真實服務器。而Full NAT不僅會修改其目標地址且會修改其源地址爲調度器的地址，然後通過真實服務器處理返回後再經由調度器修改其源地址和目標地址，響應給客戶端。其結構模型和NAT基本相似，就不再贅述。
LVS介紹
LVS（ Linux Virtual Server），是由現任阿里巴巴集團副總裁的章文嵩博士發起和領導的，它是基於Linux系統的服務器集羣解決方案,其實現目標是創建一個具有良好的擴展性高可靠性高性能和高可用性的體系許多商業的集羣產品,比如RedHat的Piranha Turbo Linux公司的Turbo Cluster等,都是基於LVS的核心代碼的體系結構，使用LVS架設的服務器集羣系統從體系結構上看是透明的,最終用戶只會感覺到一個虛擬服務器物理服務器之間可以通過高速的LAN或分佈在各地的WAN相連最前端是負載均衡器,它負責將各種服務請求分發給後面的物理服務器,讓整個集羣表現像一個服務於同一IP地址的虛擬服務器而在Linux中LVS和NetFilter一樣分爲兩個部分，內核中如要支持LVS功能則必須在編譯時把ipvs模塊編譯進內核，而在用戶空間則使用管理工具對ipvsadm進行管理。
LVS調度方法介紹
靜態方法
僅考慮方法本身，不考慮後端真實服務器的負載情況，包括以下幾類：
（1）RR輪叫調度（Round Robin），此類方法適合用於服務器硬件性能一致，且用戶請求數據大小相差不大的環境中，採用此類調度方式，可以把用戶請求按照順序平均地分給後端服務器。
（2) WRR加權輪叫調度算法（Weighted Round Robin），使用此類調度算法，可以讓調度器根據服務器的性能來對調度的順序做修改，如在真實環境中有甲乙兩臺服務器，甲服務器處理數據能力是乙的兩倍，我們即可設置把用戶請求發兩次給甲，而第三次才發給乙。
（3） DH目標地址散列（Destination Hashing）該算法使用客戶端請求的目標ip地址作爲散列鍵（Hash Key）從靜態分配的散列表中找出該服務器，若服務器鏈接未超過負載則把請求發到該服務器，若該服務器超過負載則返回空值。
（4） SH源地址散列（Source Hashing）和dh相似，只是sh把源地址作爲散列鍵。
動態方法
調度器不僅要考慮調度方法，還要考慮後端服務器的負載情況。主要包括以下幾種：
（1） LC最少鏈接（Least Connections），此調度算法會對當前後端服務器的鏈接數量進行計算，把請求發給正處於空閒或者鏈接客戶端數量較少的服務器。
（2）WLC加權最少鏈接（Weighted Least Connections），和加權輪叫調度算法相一致，此算法會根據服務器性能差異然後加上鍊接客戶端數量加以判斷，然後再轉發用戶請求。
（3）LBLC 基於局部性的最少鏈接（Locality-Based Least Connections），此種算法根據請求的目標ip地址來找出最近使用的服務器，若該服務器可用，未超過負載，則把該請求發到該服務器；若該服務器不可用或超出負載則選擇現在鏈接最少的服務器，將該請求發到選中的服務器上。
（4） LBLCR 帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）：此種算法實現方式和lblc相似，但是lblc針對的是從一個ip到一臺服務器的映射，而lblcr則是一個ip到一組服務器的映射，當從調度器客戶端發來的請求目標ip曾是此組服務器中一臺服務器的ip時，調度器就會判斷所控制Real Server中哪一臺是“最少鏈”，然後就把該請求發到該Real server。
（5）SED 最短期望延遲（Shorted Expectation delay），該方法在調度時會根據當前連接數和權重來衡量，通常使用其活動鏈接數加上1然後乘以256再除以權重，算出來的值進行比較，每個鏈接發送過來後根據算出來的值，選擇其值最大的併發送過去
（6）NQ 永不排隊（Never Queue），此方法會根據後端服務器的負載情況，把請求發給空閒的服務器，其算法也是基於WLC，但是當選擇的的服務器不空時，就不會發往該服務器。
本來打算做個實例，把基於NAT模型和DR模型的負載均衡集羣做出來寫在後面，但是感覺太長了，所以將在下一篇博客中實現，有寫得不妥的還望指正！