漫漫運維路——集羣基礎知識

集羣的基本概念

隨着計算機科學的發展，對計算機的性能要求愈來愈高，好比在不少流量比較大的門戶網站以及科學實驗環境中須要海量計算的環境，這時候就迫切須要後端的服務器性能有提高。而對於提高後端服務器性能所採用的方式有兩種，其一爲提高服務器自己的性能，即向上擴展，經過增長服務器的內存，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模型的負載均衡集羣作出來寫在後面，可是感受太長了，因此將在下一篇博客中實現，有寫得不妥的還望指正！