IP調度伺服器是啥東西

㈠ LVS四種工作模式原理

LVS 是 Linux Virtual Server ：Linux 虛擬伺服器；是一個虛擬的伺服器集群【多台機器 LB IP】。

負載調度器(load balancer) ：它是整個LVS 集群對外的前端機器，負責將client請前孫求發送到一組伺服器[多台LB IP]上執行，而client端認為是返回來一個同一個IP【通常把這個IP 稱為虛擬IP/VIP】
伺服器池(server pool) ：一組真正執行client 請求的伺服器，一般是我們的web伺服器；除了web，還有FTP，MAIL，DNS
共享存儲(shared stored) ：它為 server pool 提供了一個共享的存儲區，很容易讓伺服器池擁有相同的內容，提供相同的服務

常用術語

VS：Virtual Server #虛擬服務，一個抽象的服務，用於最開始接收 web 請求的服務
Director, Balancer #負載均衡器、分發器
RS：Real Server # 真正提供服務的伺服器
CIP: Client IP #用戶端IP，發起請求的客戶端 IP，一般是公網 IP
VIP：Director Virtual IP #負載均衡器虛擬IP
DIP：Director IP #負載均衡器IP
RIP：Real Server IP #真正提供 web 服務的伺服器的 IP

（1）直接路由模式（LVS-DR）
互聯網使用比較多的一種模式
DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實伺服器的，而真實伺服器響應後的處理結果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統的伸縮性。而且DR模式沒有IP隧道的開銷，對集群中的真實伺服器也沒有必要必須支持IP隧道協議的要求。但是要求調度器LB與真實伺服器RS都有一塊網卡連接到同一物理網脊爛段上，必須在同一個區域網環境。

DR模式特點
優點：和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比，VS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做為物理伺服器。
缺點：（不能說缺點，只能說是不足）要求負載均衡器的網卡必須與物理網卡在一個物理段上。

（2）NAT模式（LVS-NAT）
NAT模式是通過網路地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度演算法決定將請求發送給哪個後端的真實伺服器（RS）。然後調度就把客戶端發送的請求數據包的目標IP地址及埠改成後端真實伺服器的IP地址（RIP）,這樣真實伺服器（RS）就能夠接收到客戶的請求數據包了。真實伺服器響應完請求後，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB伺服器。）把響應後的數據包發送給LB,LB再接收到響應包後，把包的源慧野鏈地址改成虛擬地址（VIP）然後發送回給客戶端。

NAT模式特點：
1、NAT技術將請求的報文和響應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸，一般要求最多之能10-20台節點
2、只需要在LB上配置一個公網IP地址就可以了。
3、每台內部的節點伺服器的網關地址必須是調度器LB的內網地址。
4、NAT模式支持對IP地址和埠進行轉換。即用戶請求的埠和真實伺服器的埠可以不一致。

（3）Full NAT模式（LVS-FullNAT）
客戶端對VIP發起請求，Director接過請求發現是請求後端服務。Direcrot對請求報文做full-nat，把源ip改為Dip，把目標ip轉換為任意後端RS的rip，然後發往後端，rs接到請求後，進行響應，響應源ip為Rip，目標ip還是DIP，又內部路由路由到Director,Director接到響應報文，進行full-nat。將源地址為VIP，目標地址改為CIP
請求使用DNAT，響應使用SNAT

Full NAT模式特點：
FULL NAT 模式也不需要 LBIP 和realserver ip 在同一個網段；
full nat 跟nat 相比的優點是：保證RS回包一定能夠回到LVS；因為源地址就是LVS==> 不確定
full nat 因為要更新sorce ip 所以性能正常比nat 模式下降 10%

(4）IP隧道模式（LVS-Tunnel）
採用NAT模式時，由於請求和響應的報文必須通過調度器地址重寫，當客戶請求越來越多時，調度器處理能力將成為瓶頸。為了解決這個問題，調度器把請求的報文通過IP隧道轉發到真實的伺服器。真實的伺服器將響應處理後的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，由於一般網路服務應答數據比請求報文大很多，採用VS/TUN模式後，集群系統的最大吞吐量可以提高10倍。
它和NAT模式不同的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel裡面，然後發送給RS節點伺服器，節點伺服器接收到之後解開IP tunnel後，進行響應處理。並且直接把包通過自己的外網地址發送給客戶不用經過LB伺服器。

ip隧道模式特點：
負載均衡器只負責將請求包分發給後端節點伺服器，而RS將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一台負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。
隧道模式的RS節點需要合法IP，這種方式需要所有的伺服器支持」IP Tunneling」(IP Encapsulation)協議，伺服器可能只局限在部分Linux系統上。

四種模式性能比較：
因為DR模式 IP TUNELL 模式都是在package in 時經過LVS ，在package out是直接返回給client，所以二者的性能比NAT 模式高，但IP TUNNEL 因為是TUNNEL 模式比較復雜，其性能不如DR模式；
FULL NAT 模式因為不僅要更換 DST IP 還更換 SOURCE IP 所以性能比NAT 下降10%
4種模式的性能如下：DR ==> IP TUNNEL ==>NAT ==>FULL NAT

㈡ ip地址調度規則列表

本質上講，網路負載平衡是分布式作業調度系統的一種實現。平衡器作為網路請求分配的控制者，要根據集群節點的當前處理能力，採用集中或分布策略對網路服務請求進行調配，並且在每個服務請求的生命周期里監控各個節點的有效狀態。一般的說，平衡器對請求的調度具備以下的特徵：

網路服務請求必須是可管理的
請求的分配對用戶是透明的
最好能夠提供異構系統的支持
能夠依據集群節點的資源情況進行動態分配和調整
負載平衡器在集群的各個服務節點中分配工作負載或網路流量。可以靜態預先設置或根據當前的網路狀態來決定負載分發到哪個特定的節點，節點在集群內部可以互相連接，但它們必須與平衡器直接或間接相連。
網路平衡器可以認為是網路層次上的作業調度系統，大多數網路負載平衡器能夠在網路的相應層次上實現單一系統映像，整個集群能夠體現為一個單一的IP地址被用戶訪問，而具體服務的節點對用戶而言是透明的。這里，平衡器可靜態或動態配置，用一種或多種演算法決定哪個節點獲得下一個網路服務請求。

2．網路平衡原理

在TCP/IP協議中，數據包含有必要的網路信息，因而在網路緩存或網路平衡的具體實現演算法里，數據包的信息很重要。但由於數據包是面向分組的（IP）和面向連接的（TCP），且經常被分片，沒有與應用有關的完整信息，特別是和連接會話相關的狀態信息。因此必須從連接的角度看待數據包——從源地址的埠建立到目的地址埠的連接。

平衡考慮的另一個要素就是節點的資源使用狀態。由於負載平衡是這類系統的最終目的，那麼及時、准確的把握節點負載狀況，並根據各個節點當前的資源使用狀態動態調整負載平衡的任務分布，是網路動態負載平衡集群系統考慮的另一關鍵問題。

一般情況下，集群的服務節點可以提供諸如處理器負載，應用系統負載、活躍用戶數、可用的網路協議緩存以及其他的資源信息。信息通過高效的消息機制傳給平衡器，平衡器監視所有處理節點的狀態，主動決定下個任務傳給誰。平衡器可以是單個設備，也可以使一組平行或樹狀分布的設備。

3．基本的網路負載平衡演算法

平衡演算法設計的好壞直接決定了集群在負載均衡上的表現，設計不好的演算法，會導致集群的負載失衡。一般的平衡演算法主要任務是決定如何選擇下一個集群節點，然後將新的服務請求轉發給它。有些簡單平衡方法可以獨立使用，有些必須和其它簡單或高級方法組合使用。而一個好的負載均衡演算法也並不是萬能的，它一般只在某些特殊的應用環境下才能發揮最大效用。因此在考察負載均衡演算法的同時，也要注意演算法本身的適用面，並在採取集群部署的時候根據集群自身的特點進行綜合考慮，把不同的演算法和技術結合起來使用。

3．1 輪轉法：

輪轉演算法是所有調度演算法中最簡單也最容易實現的一種方法。在一個任務隊列里，隊列的每個成員（節點）都具有相同的地位，輪轉法簡單的在這組成員中順序輪轉選擇。在負載平衡環境中，均衡器將新的請求輪流發給節點隊列中的下一節點，如此連續、周而復始，每個集群的節點都在相等的地位下被輪流選擇。這個演算法在DNS域名輪詢中被廣泛使用。

輪轉法的活動是可預知的，每個節點被選擇的機會是1/N，因此很容易計算出節點的負載分布。輪轉法典型的適用於集群中所有節點的處理能力和性能均相同的情況，在實際應用中，一般將它與其他簡單方法聯合使用時比較有效。

3．2 散列法

散列法也叫哈希法（HASH），通過單射不可逆的HASH函數，按照某種規則將網路請求發往集群節點。哈希法在其他幾類平衡演算法不是很有效時會顯示出特別的威力。例如，在前面提到的UDP會話的情況下，由於輪轉法和其他幾類基於連接信息的演算法，無法識別出會話的起止標記，會引起應用混亂。

而採取基於數據包源地址的哈希映射可以在一定程度上解決這個問題：將具有相同源地址的數據包發給同一伺服器節點，這使得基於高層會話的事務可以以適當的方式運行。相對稱的是，基於目的地址的哈希調度演算法可以用在Web Cache集群中，指向同一個目標站點的訪問請求都被負載平衡器發送到同一個Cache服務節點上，以避免頁面缺失而帶來的更新Cache問題。

3．3 最少連接法

在最少連接法中，平衡器紀錄目前所有活躍連接，把下一個新的請求發給當前含有最少連接數的節點。這種演算法針對TCP連接進行，但由於不同應用對系統資源的消耗可能差異很大，而連接數無法反映出真實的應用負載，因此在使用重型Web伺服器作為集群節點服務時（例如Apache伺服器），該演算法在平衡負載的效果上要打個折扣。為了減少這個不利的影響，可以對每個節點設置最大的連接數上限（通過閾值設定體現）。

3．4 最低缺失法

在最低缺失法中，平衡器長期紀錄到各節點的請求情況，把下個請求發給歷史上處理請求最少的節點。與最少連接法不同的是，最低缺失記錄過去的連接數而不是當前的連接數。

3．5 最快響應法

平衡器記錄自身到每一個集群節點的網路響應時間，並將下一個到達的連接請求分配給響應時間最短的節點，這種方法要求使用ICMP包或基於UDP包的專用技術來主動探測各節點。

在大多數基於LAN的集群中，最快響應演算法工作的並不是很好，因為LAN中的ICMP包基本上都在10ms內完成回應，體現不出節點之間的差異；如果在WAN上進行平衡的話，響應時間對於用戶就近選擇伺服器而言還是具有現實意義的；而且集群的拓撲越分散這種方法越能體現出效果來。這種方法是高級平衡基於拓撲結構重定向用到的主要方法。

3．6 加權法

加權方法只能與其他方法合用，是它們的一個很好的補充。加權演算法根據節點的優先順序或當前的負載狀況（即權值）來構成負載平衡的多優先順序隊列，隊列中的每個等待處理的連接都具有相同處理等級，這樣在同一個隊列里可以按照前面的輪轉法或者最少連接法進行均衡，而隊列之間按照優先順序的先後順序進行均衡處理。在這里權值是基於各節點能力的一個估計值。

4、動態反饋負載均衡

當客戶訪問集群資源時，提交的任務所需的時間和所要消耗的計算資源是千差萬別的，它依賴於很多因素。例如：任務請求的服務類型、當前網路帶寬的情況、以及當前伺服器資源利用的情況等等。一些負載比較重的任務需要進行計算密集的查詢、資料庫訪問、很長響應數據流；而負載比較輕的任務請求往往只需要讀一個小文件或者進行很簡單的計算。

對任務請求處理時間的不同可能會導致處理結點利用率的傾斜（Skew），即處理結點的負載不平衡。有可能存在這樣情況，有些結點已經超負荷運行，而其他結點基本是閑置著。同時，有些結點已經忙不過來，有很長的請求隊列，還不斷地收到新的請求。反過來說，這會導致客戶長時間的等待，而集群整體的服務質量下降。因此，有必要採用一種機制，使得平衡器能夠實時地了解各個結點的負載狀況，並能根據負載的變化做出調整。

具體的做法上採用了基於負反饋機制的動態負載均衡演算法，該演算法考慮每一個結點的實時負載和響應能力，不斷調整任務分布的比例，來避免有些結點超載時依然收到大量請求，從而提高單一集群的整體吞吐率。

在集群內，負載均衡器上運行服務端監控進程，監控進程負責監視和收集集群內各個結點的負載信息；而每個結點上運行客戶端進程，負責定時向均衡器報告自身的負載狀況。監控進程根據收到的全部結點的負載信息來進行同步操作，既對將要分配的任務按照權值得比例重新進行分布。權值得計算主要根據各個結點的CPU利用率、可用內存以及磁碟I/O狀況計算出新的權值，若新權值和當前權值的差值大於設定的閥值，監控器採用新的權值對集群范圍內的任務重新進行分布，直到下一次的負載信息同步到來之前。均衡器可以配合動態權值，採用加權輪詢演算法來對接受的網路服務請求進行調度。

4．1 加權輪詢調度

加權輪詢調度（Weighted Round-Robin Scheling）演算法用相應的權值表示結點的處理性能。該演算法根據權值的高低順序並按照輪詢的方式將任務請求分配到各結點。權值高的結點比權值低的結點處理更多的任務請求，相同權值的結點處理相同份額的請求。加權輪詢的基本原理可描述為：

假設某集群內有一組結點N = {N0, N1, …, Nn-1}，W(Ni)表示結點Ni的權值，
一個指示變數i表示上一次選擇的伺服器，T（Ni）表示結點Ni當前所分配的任務量。

∑T(Ni) 表示當前同步周期需要處理的任務總量。

∑W(Ni) 表示結點的權值總和。

則： W(Ni)/ ∑W(Ni)= T(Ni)/ ∑T(Ni)
表示任務的分配是按照各個結點權值占權值總數的比例來進行分配。

4.2 權值計算

當集群的結點初次投入系統中使用時，系統管理員根據結點的硬體配置情況對每個結點都設定一個初始權值DW（Ni）（通常根據結點的硬體配置來定義，硬體配置越高的結點默認值越高），在負載均衡器上也先使用這個權值。然後，隨著結點負載的變化，均衡器對權值進行調整。

動態權值是由結點運行時各方面的參數計算出來的。我們在實驗中選取了最重要幾項，包括：CPU資源，內存資源，當前進程數，響應時間等信息作為計算公式的因子。結合每個結點當前的權值，可以計算出新的權值的大小。動態權值目的是要正確反映結點負載的狀況，以預測結點將來可能的負載變化。對於不同類型的系統應用，各個參數的重要程度也有所不同。典型的Web應用環境下，可用內存資源和響應時間就非常重要；如果用戶以長的資料庫事務為主，則CPU使用率和可用內存就相對重要一些。為了方便在系統運行過程中針對不同的應用對各個參數的比例進行適當調整，我們為每一個參數設定一個常量系數 Ri ，用來來表示各個負載參數的重要程度，其中∑ Ri = 1。因此，任何一個結點Ni的權值公式就可以描述為：

LOAD(Ni)=R1*Lcpu(Ni)+R2*Lmemory(Ni)+R3*Lio(Ni)+R4*Lprocess(Ni)+R5*Lresponse(Ni)

其中Lf(Ni) 表示結點Ni 當前某一項參數的負載值，

上述公式中依次表示為：CPU使用率、內存使用率、
磁碟I/O訪問率、進程總數以及響應時間。

例如，在WEB伺服器集群中，我們採用以系數{0.1, 0.4, 0.1, 0.1, 0.3}，這里認為伺服器的內存和請求響應時間較其他參數重要一些。若當前的系數Ri不能很好地反映應用的負載，系統管理員可以對系數不斷地修正，直到找到貼近當前應用的一組系數。

另外，關於採集權值的周期置，雖然很短的周期可以更確切地反映各個結點的負載，但是很頻繁地採集（如1秒1次或者多次）會給均衡器和結點帶來負擔，也可能增加不必要的網路負荷。另外，由於採集器是在採集時刻進行負載計算的，經實驗證明，均衡器反映出來各個結點的負載信息會出現劇烈的抖動，均衡器無法准確捕捉結點真實的負載變化趨勢。因此解決這些問題，一方面要適當地調整採集負載信息的周期，一般在5～10秒；另一方面，可以使用移動平均線或者是滑動窗口來避免抖動，使得均衡器收集到的負載信息表現為平滑曲線，這樣在負反饋機制的調整效果上就會比較好。

均衡器的動態權值採集程序周期性地運行，若預設權值不為零，則查詢該結點的各負載參數，並計算出動態權值LOAD(Ni) 。我們引入以下權值計算公式，結合結點的初始權值和採集的動態權值來計算最終的權值結果。

Wi = A*DW(Ni)+B*(LOAD(Ni)-DW(Ni))1/3

在公式中，如果動態權值恰好等於初始權值，最終權值不變，則說明系統的負載狀況剛好達到理想狀況，等於初始權值DW(Ni)。如果動態權值計算結果高於初始權值，最終權值變高，則說明系統負載很輕，均衡器將會增加分配給該結點的任務比率。如果動態權值低於初始權值，最終權值變低，說明系統開始處於重載狀況，均衡器將會減少對該結點分配的任務。在實際使用中，若發現所有結點的權值都小於他們的DW(Ni)，則說明當前個集群處於超載狀態，這時需要加入新的結點到集群中來處理部分負載；反之，若所有結點的權值大大高於DW(Ni)，則說明當前系統的負載都比較輕。

5、總結

網路負載平衡是集群作業調度系統的具體實現。由於其處理的作業單元是TCP/IP協議下的網路連接，因此可以採用面向網路連接的集中基本調度演算法。考慮集群負載不平衡的可能，採取了動態獲取服務節點的權值並使用負反饋機制調整平衡器對網路服務請求的分布，以適應服務節點在運行過程中資源的變化。筆者也在LVS集群系統的基礎上，配合原有的輪詢演算法對其進行改進，增加了採集動態權值的程序並實時反饋到負載平衡器的調度系統上。實踐證明，採用動態平衡在集群系統的整體吞吐量方面有所提高，特別是在集群各個節點性能不一，集群提供的網路服務程序所訪問的資源多樣化的情況下，負反饋機制的效果尤其明顯。在其他類型的集群中，負反饋機制的動態負載平衡也能夠得到很好的應用，只是平衡器所處理的作業單元不同於網路連接，而具體的負載演算法上也將有所不同。

㈢ Nginx做負載均衡，調度是使用ip_hash 我用不同機器每次都登陸的是同一個伺服器請問是什麼問題

這個是很正常的，ip_hash的負載均衡是以客戶端的ip地址作為hash錯作的key進而計算hash值得。這種策略能保證一個ip訪問到的永遠是同一台機器。
（1）但是有一種情況就是多個ip的hash值是相同的，在這種情況下，這幾個不同的ip訪問到的就是同一台機器了。
（2）還有一種情況就是，雖然你每次用不同的機器，但是這些機器都是通過一個相同的出口ip來訪問伺服器，這時，你訪問到的也永遠是一台伺服器。