首頁>Club>
7
回覆列表
  • 1 # 科學史話

      LVS是Linux Virtual Server的簡稱,也就是Linux虛擬伺服器, 是一個由章文嵩博士發起的自由軟體專案,現在已經是 Linux標準核心的一部分。LVS是一種叫基於TCP/IP的負載均衡技術,轉發效率極高,具有處理百萬計併發連線請求的能力。

      LVS的IP負載均衡技術是透過IPVS模組實現的。IPVS模組是LVS叢集的核心軟體模組,它安裝在LVS叢集作為負載均衡的主節點上,虛擬出一個IP地址和埠對外提供服務。使用者透過訪問這個虛擬服務(VS),然後訪問請求由負載均衡器(LB)排程到後端真實伺服器(RS)中,由RS實際處理使用者的請求給返回響應。

    DR模式(Direct Routing)

      DR模式下,客戶端的請求包到達負載均衡器的虛擬服務IP埠後,負載均衡器不會改寫請求包的IP和埠,但是會改寫請求包的MAC地址為後端RS的MAC地址,然後將資料包轉發;真實伺服器處理請求後,響應包直接回給客戶端,不再經過負載均衡器。所以DR模式的轉發效率是最高的,特別適合下行流量較大的業務場景,比如請求影片等大檔案。

      DR模式的特點:

    每臺RS上都必須在環回網絡卡上繫結LB的虛擬服務IP

      因為LB轉發時並不會改寫資料包的目的IP,所以RS收到的資料包的目的IP仍是LB的虛擬服務IP。為了保證RS能夠正確處理該資料包,而不是丟棄,必須在RS的環回網絡卡上繫結LB的虛擬服務IP。這樣RS會認為這個虛擬服務IP是自己的IP,自己是能夠處理這個資料包的。否則RS會直接丟棄該資料包!

    RS上的業務程序必須監聽在環回網絡卡的虛擬服務IP上,且埠必須和LB上的虛擬服務埠一致

      因為LB不會改寫資料包的目的埠,所以RS服務的監聽埠必須和虛擬服務埠一致,否則RS會直接拒絕該資料包。

    RS處理完請求後,響應直接回給客戶端,不再經過LB

      因為RS收到的請求資料包的源IP是客戶端的IP,所以理所當然RS的響應會直接回給客戶端,而不會再經過LB。這時候要求RS和客戶端之間的網路是可達的。

    LB和RS須位於同一個子網

      因為LB在轉發過程中需要改寫資料包的MAC為RS的MAC地址,所以要能夠查詢到RS的MAC。而要獲取到RS的MAC,則需要保證二者位於一個子網,否則LB只能獲取到RS閘道器的MAC地址。

      2. NAT模式(Network Address Translation)

      NAT模式下,請求包和響應包都需要經過LB處理。當客戶端的請求到達虛擬服務後,LB會對請求包做目的地址轉換(DNAT),將請求包的目的IP改寫為RS的IP。當收到RS的響應後,LB會對響應包做源地址轉換(SNAT),將響應包的源IP改寫為LB的IP。

      NAT模式的特點:

    LB會修改資料包的地址

      對於請求包,會進行DNAT;對於響應包,會進行SNAT。

    需要將RS的預設閘道器地址配置為LB的浮動IP地址

      因為RS收到的請求包源IP是客戶端的IP,為了保證響應包在返回時能走到LB上面,所以需要將RS的預設閘道器地址配置為LB的虛擬服務IP地址。當然,如果客戶端的IP是固定的,也可以在RS上新增明細路由指向LB的虛擬服務IP,不用改預設閘道器。

    LB和RS須位於同一個子網,並且客戶端不能和LB/RS位於同一子網

      因為需要將RS的預設閘道器配置為LB的虛擬服務IP地址,所以需要保證LB和RS位於同一子網。

      又因為需要保證RS的響應包能走回到LB上,則客戶端不能和RS位於同一子網。否則RS直接就能獲取到客戶端的MAC,響應包就直接回給客戶端了,不會走閘道器,也就走不到LB上面了。這時候由於沒有LB做SNAT,客戶端收到的響應包源IP是RS的IP,而客戶端的請求包目的IP是LB的虛擬服務IP,這時候客戶端無法識別響應包,會直接丟棄。

      3. FULLNAT模式

      FULLNAT模式下,LB會對請求包和響應包都做SNAT+DNAT。

      FULLNAT模式的特點:

    LB和RS對於組網結構沒有要求

      不同於NAT和DR要求LB和RS位於一個子網,FULLNAT對於組網結構沒有要求。只需要保證客戶端和LB、LB和RS之間網路互通即可。

      雖然FULLNAT模式的效能比不上DR和NAT,但是FULLNAT模式沒有組網要求,允許LB和RS部署在不同的子網中,這給運維帶來了便利。並且 FULLNAT模式具有更好的可拓展性,可以透過增加更多的LB節點,提升系統整體的負載均衡能力。

    三、IPVS支援的排程演算法

      對於後端的RS叢集,LB是如何決策應該把訊息排程到哪個RS節點呢?這是由負載均衡排程演算法決定的。IPVS常用的排程演算法有:

    輪詢(Round Robin)

      LB認為叢集內每臺RS都是相同的,會輪流進行排程分發。從資料統計上看,RR模式是排程最均衡的。

    加權輪詢(Weighted Round Robin)

      LB會根據RS上配置的權重,將訊息按權重比分發到不同的RS上。可以給效能更好的RS節點配置更高的權重,提升叢集整體的效能。

    最小連線數(Least Connections)

      LB會根據和叢集內每臺RS的連線數統計情況,將訊息排程到連線數最少的RS節點上。在長連線業務場景下,LC演算法對於系統整體負載均衡的情況較好;但是在短連線業務場景下,由於連線會迅速釋放,可能會導致訊息每次都排程到同一個RS節點,造成嚴重的負載不均衡。

    加權最小連線數(Weighted Least Connections)

      最小連線數演算法的加權版~

    地址雜湊(Address Hash)

      LB上會儲存一張雜湊表,透過雜湊對映將客戶端和RS節點關聯起來。

  • 中秋節和大豐收的關聯?
  • 發憤識遍天下字,下句是什麼?