全部產品
Search

搜尋本產品

    Server Load Balancer：網路虛擬設備與網關型負載平衡整合指南

    文件中心

    Server Load Balancer：網路虛擬設備與網關型負載平衡整合指南

    更新時間：Mar 20, 2025

    網關型負載平衡 GWLB（Gateway Load Balancer）適用於需要部署、擴充和管理第三方網路虛擬設備（如防火牆、入侵檢測、流量鏡像、深度報文檢測等）的情境。由於網關型負載平衡 GWLB在OSI參考模型第三層以透明模式運行，所以在該負載平衡後部署網路虛擬設備時，需要做一些適配工作。本文為您介紹GWLB的工作原理，以及網路虛擬設備的整合方法。

    什麼是網關型負載平衡

    網關型負載平衡 GWLB是一種工作在OSI參考模型第三層（即網路層）的負載平衡，可協助公司專屬應用程式部署、擴充和管理各類第三方網路虛擬設備，例如：防火牆、入侵檢測、流量鏡像、深度報文檢測等。GWLB提供以下能力：

    • 支援多台第三方網路虛擬設備的部署。

    • 可提高第三方網路虛擬設備部署的可靠性。

    • 可實現第三方網路虛擬設備的跨可用性區域服務能力。

    • 結合PrivateLink，可實現第三方網路虛擬設備的跨VPC、跨帳號服務能力。

    • 為第三方網路虛擬設備廠商的SaaS服務提供基礎。

    網關型負載平衡的工作原理

    工作流程

    如下圖所示，GWLB通常與另一個VPC的網關負載平衡器終端節點 GWLBe（Gateway Load Balancer Endpoint）共同工作，其中，GWLBe是一種特殊類型的VPC終端節點。一個GWLB支援串連多個GWLBe。

    GWLB工作流程如下：

    序號

    工作流程說明

    ①

    用戶端訪問服務端的流量被路由至GWLBe。

    ②

    GWLBe通過PrivateLink將流量轉寄至關聯的GWLB。

    ③

    GWLB將原始報文通過Geneve隧道封裝，然後根據流量調度演算法將流量轉寄至健康的後端網路虛擬設備。網路虛擬設備會根據Geneve隧道攜帶的64位GWLBe ID等資訊來識別流量的不同來源。

    ④

    網路虛擬設備做完相應處理之後，再次使用Geneve隧道將報文轉寄到GWLB。

    ⑤

    GWLB會通過PrivateLink將流量轉寄至相應的GWLBe。

    ⑥

    GWLBe會根據目的地址尋找路由，將流量轉寄至服務端相應的目的伺服器。

    流量調度方式

    GWLB支援基於五元組（源IP、目的IP、傳輸協議、源連接埠、目的連接埠）、三元組（源IP、目的IP、傳輸協議）和二元組（源IP、目的IP）的一致性雜湊演算法來調度流量，GWLB會將具有相同特徵的流量路由到相同後端伺服器。

    通常情況下：

    • 對於TCP/UDP流量，可以選擇基於五元組雜湊演算法。

    • 對於非TCP/UDP流量，可以選擇基於三元組的雜湊演算法。

    健全狀態檢查機制

    GWLB根據您所定義的時間間隔定期運行健全狀態檢查。GWLB通過向後端網路虛擬設備發送TCP、HTTP或HTTPS資料包，並根據後端網路虛擬設備是否響應來判定後端網路虛擬設備是否健康：

    • TCP：GWLB與後端網路虛擬設備正常建立TCP串連，則認為後端網路虛擬設備是健康的。

    • HTTP或HTTPS：GWLB向後端網路虛擬設備發起HTTP或HTTPS請求，後端網路虛擬設備響應HTTP狀態代碼為2xx或3xx，則認為後端網路虛擬設備是健康的；否則，認為後端網路虛擬設備是不健康的。GWLB不會對傳入的認證進行主機名稱驗證，因此，任何未到期的認證（包括自我簽署憑證）都可以生效。

    說明

    • 健全狀態檢查時所發送的資料包不通過Geneve封裝。

    • 網路虛擬設備必須在GWLB的健全狀態檢查響應逾時時間內響應才有效，否則判定為健全狀態檢查失敗。

    網路虛擬設備整合

    整合方式

    GWLB和後端網路虛擬設備使用Geneve協議進行通訊。GWLB通過對每個資料包封裝Geneve TLV（Type-Length-Value）向網路虛擬設備發送額外的資訊（如GWLBe ID、Flow Cookie）。網路虛擬設備收到的Geneve報文可能包含一個或者多個Geneve TLV（Type-Length-Value）。

    其中：

    • GWLBe ID：分配給GWLBe的64位ID。網路虛擬設備可以使用此ID將資料包與其配置關聯；此外，此ID可用於確定流量的來源。

    • Flow Cookie：GWLB在流表中建立流條目時，為流產生的32位隨機數。每個流都有唯一的cookie。網路虛擬設備必須原樣將此cookie傳回，即僅當GWLB從網路虛擬設備所接收資料包中的cookie與分配給該流的cookie匹配時，才會進一步轉寄資料包。如果cookie不匹配或沒有cookie，則丟棄資料包。

    網路虛擬設備通常的響應流程如下：

    1. 將未經處理資料包封裝在Geneve前序中。

    2. 交換外層IPv4前序中的源IP地址（網路虛擬設備IP地址）和目標IP地址（GWLB IP地址）。

    3. 保留原始連接埠，不交換外層IPv4前序中的源連接埠和目標連接埠。

    4. 更新外層IPv4前序中的IP校正和。

    5. Geneve前序中所有欄位原樣返回，不進行修改。

    6. Geneve Option中的所有TLV欄位（GWLBe ID、Flow Cookie），原樣返回，不進行修改。

    Geneve報文格式

    Geneve資料包格式如下，有關Geneve的說明，請參見Geneve協議（RFC 8926）。

    Outer IPv4 Header:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |Protocol=17 UDP|         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Outer Source IPv4 Address                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Outer Destination IPv4 Address              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Source Port = xxxx      |    Dest Port = 6081 Geneve    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          UDP length           |         UDP Checksum          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outer Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|Opt Len = 8|O|C|    Rsvd.  | EtherType = 0x0800 or 0x86DD  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Virtual Network Identifier (VNI) = 0       |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outer Geneve Options: Alibaba Cloud Gateway Load Balancer TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Option Class = 0x0139 (Ali)|    Type = 1   |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      64-bit GWLBe ID                          | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Option Class = 0x0139 (Ali)|    Type = 3   |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     32-bit Flow Cookie                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Customer payload follows…
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 
|   Customer payload identified by EtherType in Geneve header   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+