Linux Enterprise Cluster Notes -Ch11 LVS Introduction Theory

1. 本章介紹LVS的一些相關概念，調度策略和叢集架構類型。下一章開始講解LVS－NAT叢集

2. 從Linux核心2.4.23開始，加入了一個叫做IP Virtual Server(IPVS)的特性，這就使得我們可以把一台Linux機器作為一個load balancer來使用。LVS就是一個很好的構建Linux load balance叢集的軟體。

3. LVS Address Name Conventions. 這裡介紹一下LVS中會提到的多種IP的專有名稱，其實看圖就明白了：見附件1

OK，從圖上就能明白這些IP的意思了：

Virtual IP (VIP) address
The IP address the Director uses to offer services to client computers

Real IP (RIP) address
The IP address used on the cluster nodes Director's IP (DIP) address

Director's IP(DIP) address
The IP address the Director uses to connect to the D/RIP network

Client computer's IP (CIP) address
The IP address assigned to a client computer that it uses as a source IP address for requests sent to the cluster

4. LVS支援的load balance的方式共有三種：LVS-NAT, LVS-DR, LVS-TUN，本書重點講解LVS-DR, LVS-TUN不講，LVS-NAT簡單講解。其實LVS-TUN也不錯，網上有資料，他是通過IP Tunneling的技術來做，和VPN有點像。

5. LVS-NAT，先看這張圖：見附件1

可以看到，所有的請求和回應都要經過load balancer，無疑這是一個瓶頸，所以，一般小規模的用這種架構，因為搭建簡單。主要的特點如下：

(1)cluster nodes和director(load balancer)要位於同一網段。
(2)一般cluster node上都分配假IP地址，如192.x.x.x
(3)director架構request和response資訊
(4)一般來說，director的DIP也就是cluster nodes的網關IP
(5)這種架構下，director可以remap一個連接埠，如可以把來自用戶端的一個80連接埠請求映射到cluster某個node上的8080連接埠。（iptable嘛，自然可以）
(6)cluster nodes的OS可以自由選擇，可以不同
(7)director是整個系統的bottleneck

6. LVS-DR，先看圖：附件2

圖上可以看出，請求直接由cluster node返回給client。這種架構有如下特性：

(1)cluster node和director要在同一個網段內。
(2)cluster nodes的IP地址不一定要是假IP地址
(3)director只需承受request的請求
(4)cluster node一般不把director作為他們的gateway
(5)director不能remap連接埠
(6)cluster node的OS可以不同
(7)LVS-DR比LVS－NAT，可以接受更多的負載

7. LVS-TUN，看圖：附件3

從圖上可以看出，和LVS－DR不同，這裡利用了IP Tunneling的技術，這種技術是把一個包封裝在另外一個包內，這樣，接受端解開包後得到真正的那個包，就可以直接和包中的地址建立聯絡，和VPN有 點像，在LVS的官方中文網站有專門的詳細文章。這種架構的特點如下：

(1)cluster node和director不需要一定要在一個網段內，因為採用了IP Tunneling，可以讓兩個不同網段的IP直接通訊。所以，這是一種最鬆散的架構，director和cluster nodes可能位於internet上，不像前兩種，director和cluster nodes都在一個區域網路內。
(2)RIP不能是假IP地址
(3)director只需要處理request
(4)response的資訊不能經過director，換句話說，director不能是cluster nodes的gateway
(5)director不能remap連接埠
(6)cluster nodes的作業系統，必須要支援IP Tunneling protocol

8. LVS Scheduling Methods. 首先介紹第一種，Fixed(or Non-Dynamic) Scheduling Methods. 這其實是一類調度演算法，他們的共同特點就是靜態，一旦定義好了以後，不會根據具體情況做有邏輯的處理，這是呆板的根據調度定義來工作。比如這些演算法都是 Fixed類型：

(1)Round-robin(RR)－－當一個請求到來時，director根據round-robin伺服器的清單中挨個選擇下一個server來接受請求，完全不管這個server目前是否負載重，是否串連過多等，只是呆板的依次在清單中向下選擇，到尾了再返回。

(2)Weighted round-robin(WRR)－－在RR的基礎上，給cluster中每個伺服器賦予一個weight的東西以表示機器的效能。比如一台weight為2的伺服器就能接受兩個請求，而一個weight為1的機器只能接受一個請求。當然，weight為0的機器，director永遠不會將請求遞交給他，注意，即便是在動態調度策略中，將weight設定為0也是有用的，所以，如果你想維護一台機器，暫時不想讓這台機器接受請求的話，將他的weight設定為0即可。

(3)Destination Hashing. 每個請求都會有個目的IP地址，這種調度演算法下，相同的destination ip的請求，都會被調度到同一台cluster的server上。這種調度演算法，當cluster中的server都是proxy或cache server的時候特別有用，因為這些server對這些destination ip都有cache，能很快的處理完請求。

(4)Source Hashing. This method can be used when the Director needs to be sure the reply packets are sent back to the same router or firewall that the requests came from. This scheduling method is normally only used when the Director has more than one physical network connection, so that the Director knows which firewall or router to send the reply packet back through to reach the proper client computer.

9. Dynamic Scheduling Method. 和靜態調度策略最大的不同是，在動態調度演算法下，LVS會記錄cluster中每台伺服器當前的active和inactive的串連數量，根據每台服 務器當前的負載情況來決定下一個請求交給哪台伺服器處理。所謂一個active的connection，指的是一個TCP session保持在open（也就是ESTABLISHED狀態），比如telnet和ssh就一直會保持open狀態，除非該使用者退出。一個 inactive的connection，也就是不在ESTABLISH狀態的一個串連了，一般情況下，使用者關閉（發送了一個FIN packet），逾時都會導致一個inactive connection，LVS會在IPVS table中會保留一個connection即便該connection已經drop了，這是因為如果短時間內該connection又要建立的話，那就 可以直接建立了，效能很好（director和cluster node都會這樣做）。

10. OK，動態調度策略第一種：Least-Connection(LC)。這種調度策略邏輯是這樣的，顧名思義，connection最少的那個處理請求。 當一個串連來到時，director將cluster node上每個node當前active的connection 乘以 256，然後加上每個node上inactive connection的數量，得到一個數值，這個數值最小的那台伺服器處理該請求。

11. Weighted Least-Connection(WLC). WLC調度策略和LC一樣，只不過在LC調度方法中算出來的那個overload的數值，再除以每台機器的Weight，得到一個新數值，這個數值最小的 那台機器處理請求，如果大家的數值都一樣，那麼，LVS選擇在伺服器列表中的第一台機器處理請求。就是結合了weight和LC策略的一種策略，注意，這是LVS預設的調度策略，因為這種策略確實能應付不少場合。

12. shortest expected delay(sed). sed方法是最近加到LVS調度策略中的，這種方法比WLC稍微好一些，特別是處理很多串連是TCP長串連的場合（比如large batch job的場合，ssh或telnet一直開著）。他的演算法是這樣的，每台伺服器的active connection的數量 + 1, 然後除以每台機器的weight，算出來的數值最小的那台伺服器處理請求。注意這種演算法，它不考慮inactive connection的情況（這就是為什麼剛才提到這種演算法特別適合很多TCP長串連的情境），而且他通過在active connection上加1來類比該機器接受了新的串連後的情景。考慮這樣一個例子，如果演算法中不在active connection上加1：比如我們有兩台機器，一台weight是1，有10個active connection，一台weight是3，有30個active connection，如果不加1，那麼，這種演算法下兩台機器算下來的值都是10，那麼，LVS在server list中挑選第一條伺服器來處理請求，不確定到底是哪台；但是加了1以後，那麼，weight是1的機器算下來的數值是10，但是weight是3的機 器算下來的數值是10.34，由weight高的那台機器處理請求，這顯然是合理的。

但是這種演算法有一個缺陷，就是當某些server上沒有負載的時候，request卻不會被調度上去，比如，還是兩台機器，一個weight是 1，但是目前沒有active串連，一台weight是3，目前有一個active connection，此時來了一個請求，按照演算法，weight是1的機器算下來的值是1，weight是3的機器算下來是0.67－－還是 weight是3的機器處理請求，這就不合理了，應該讓沒有active connection的機器處理才對，基於此，下面一種調度策略（NQ）誕生了。

13. Never Queue(NQ)。這種策略就是對SED的一個改進，他規定如果某台機器上當前沒有active connection，那麼，不管SED計算的值如何，request都被調度到這台機器上。

14. Locality-Based Least-Connection(LBLC). 這種調度策略基於proxy/cache server的基礎，有點像靜態策略中的destination hashing, 他是這樣的，當一個請求（請求某個特定的IP地址，比如是一個web server）第一次來的時候，LVS根據WLC（確切的應該是一個稍微經過改動的WLC演算法）演算法選定一台proxy server（比如這台伺服器叫A）來處理該請求，那麼，下次請求再過來的時候（當然請求的目的地一樣，都是那台web server），那麼，LVS就將請求直接給這台A伺服器處理。這樣可以非常有效提高請求的cache命中率，提高請求處理效能。當然也不能一直這樣下 去，當LVS發現當前A伺服器的wlc值已經是最小的wlc值的2倍的時候，那麼，LVS會把請求再調度給wlc值最小的那台伺服器（假設叫B）處理，以 後這類請求就給B伺服器處理，如此迴圈往複。

15. Locality-Based Least-Connection with Replication Scheduling(LBLCR). 這種演算法也是對LBLC的一些改進，他建立了一個proxy server的set，這個set中有一批proxy server都能處理同樣一種destination是一樣的request，每次，LVS從這個SET中挑選active connection最少的那台伺服器來處理請求。流程是這樣的，首先請求來了，根據LBLC的演算法，有了一台A伺服器處理請求，當出現A伺服器的wlc 是最小wlc 2倍的情況時，根據LBLC演算法，新的最小wlc伺服器B開始接受請求，但是在LBLCR中，新的B伺服器被add到set中，和A伺服器列在一起，然後 由B開始處理請求（因為B的active connection還是最少的嘛），如此往複，這個set中就會有不少的機器羅列在內。那麼什麼時候proxy server會被從set中刪除呢？是這樣的，當LVS發現這個set中伺服器的清單在6分鐘內沒有變化時（這意味著6分鐘內沒有伺服器被add進去，也 沒有伺服器被刪除，這6分鐘一直是由這個set中的那些伺服器在“扛”），LVS就會把active connection最多的那台伺服器從set中刪除。

OK，結束本章，LVS的調度策略還是蠻精彩的，在實踐過程中可以常回來看看，對LVS肯定有更好的理解。