Elastic Load Balancing 的運作方 - Elastic Load Balancing

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Elastic Load Balancing 的運作方

負載平衡器接受來自用戶端的傳入流量,並將請求路由傳送到在一或多個可用區域中註冊的目標 (例如 EC2 執行個體)。負載平衡器還會監控其已註冊目標的運作狀態,並確保只將流量路由到運作狀態良好的目標。當負載平衡器偵測到狀況不良的目標時,它會停止將流量路由到該目標。然後,當它偵測到目標狀況良好時,它會繼續將流量路由到該目標。

您可以指定一或多個接聽程式,以將負載平衡器設定為接受傳入流量。接聽程式是檢查連線請求的程序。使用通訊協定以及連接埠號碼為用戶端與負載平衡器間的連線進行設定。同樣地,它也設定了從負載平衡器到目標之間連線的通訊協定和連接埠號碼。

Elastic Load Balancing 支援以下類型的負載平衡器:

  • Application Load Balancer

  • 網路負載平衡器

  • 閘道負載平衡器

  • Classic Load Balancer

負載平衡器類型的設定方式有關鍵的差異。若採用 Aplication Load Balancer、Network Load Balancer 和 Gateway Load Balancer,執行個體會在目標羣組註冊目標,並將流量路由到目標羣組。使用 Classic Load Balancer 時,您會向負載平衡器註冊執行個體。

可用區域和負載平衡器節點

當您啟用負載平衡器的可用區域時,Elastic Load Balancing 會在該可用區域內建立負載平衡器節點。如果您在可用區域內註冊目標,但未啟用該可用區域,這些已註冊的目標不會收到流量。當您確認每個已啟用的可用區域擁有至少一個登錄的目標,您的負載平衡器會展現最高效率。

我們建議為所有負載均衡器啟用多個可用區。但是,使用 Application Load Balancer,您需要啟用至少兩個或更多可用區。此組態有助於確保負載平衡器可繼續路由流量。如果一個可用區域變成無法使用或沒有運作狀態良好的目標,負載平衡器可以將流量路由到另一個可用區域內運作狀態良好的目標。

當您停用可用區域之後,該可用區域內的目標仍註冊到負載平衡器。不過,即使它們仍保持註冊,負載平衡器不會將流量路由傳送給它們。

跨區域負載平衡 (Cross-zone load balancing)

負載平衡器的節點會將請求從用戶端分發到已註冊的目標。啟用跨區域負載平衡時,每個負載平衡器節點會將流量分發到所有已啟用可用區域內的已註冊目標。停用跨區域負載平衡時,每個負載平衡器節點只會將流量分發到其可用區域內已註冊的目標。

下圖演示了使用循環傳送方式進行跨區域負載平衡的效果。有兩個已啟用的可用區域,兩個目標在可用區域 A,八個目標在可用區域 B。用户端傳送請求,Amazon Route 53 會以其中一個負載平衡器節點的 IP 地址來回應每個請求。根據循環路由演算法,流量會進行分佈,以便每個負載平衡器節點會收到來自客户端的 50% 的流量。每個負載平衡器節點會將其流量份額分發到其範圍內已註冊的目標。

如果跨區域負載平衡已啟用,則 10 個目標各接收 10% 的流量。這是因為每個負載平衡器節點可以將其 50% 的用戶端流量路由到所有 10 個目標。


                    啟用跨區域負載平衡時

如果停用跨區域負載平衡時:

  • 可用區域 A 中的兩個目標都會收到各 25% 的流量。

  • 可用區域 B 中的八個目標都會收到各 6.25% 的流量。

這是因為每個負載平衡器節點只能將其 50% 的用戶端流量路由到其可用區域內的目標。


                    停用跨區域負載平衡時

使用 Application Load Balancer 時,會始終啟用跨區域負載平衡。

使用網路負載平衡器和閘道負載平衡器時,預設會停用跨區域負載平衡。建立負載平衡器後,您隨時可以啟用或停用跨區域負載平衡。

當您建立 Classic Load Balancer 時,跨區域負載平衡的預設值取決於您如何建立負載平衡器。使用 API 或 CLI 時,預設會停用跨區域負載平衡。使用 AWS Management Console 時,預設會選擇啟用跨區域負載平衡。建立 Classic Load Balancer 後,您隨時可以啟用或停用跨區域負載平衡。如需詳細資訊,請參閱「」啟用跨區域負載平衡中的Classic Load Balancer 使用者指南

要求路由

在用戶端將請求傳送到負載平衡器之前,它會先使用網域名稱系統 (DNS) 伺服器解析負載平衡器的網域名稱。DNS 項目由 Amazon 控制,因為您的負載平衡器位於 amazonaws.com 網域。Amazon DNS 伺服器傳回一個或多個 IP 地址給用戶端。這些是您的負載平衡器之負載平衡器節點的 IP 地址。使用網路負載平衡器時,Elastic Load Balancing 會為您啟用的每個可用區域建立網路界面。可用區域中的每個負載平衡器節點皆使用此網路界面來取得靜態 IP 地址。當您建立負載平衡器時,您可以選擇性地將一個彈性 IP 地址與每個網路界面建立關聯。

當應用程式的流量隨著時間發生變化時,Elastic Load Balancing 會擴展您的負載平衡器並更新 DNS 條目。DNS 條目還指定 time-to-live (TTL) 為 60 秒。這有助於確保 IP 地址可以快速重新對應,以回應變更的流量。

用戶端會決定用於將請求傳送到負載平衡器的 IP 地址。收到請求的負載平衡器節點會選取已註冊且運作狀態良好的目標,並使用目標的私有 IP 地址將請求傳送到目標。

路由演算法

搭配Application Load Balancer使用時,接收請求的負載平衡器節點會使用下列程序:

  1. 以優先順序評估接聽程序的規則,以決定要套用哪個規則。

  2. 使用為目標群組設定的路由演算法,從目標群組中選取規則動作的目標。預設的路由算法是循環配置路由演算法。即使一個目標向多個目標群組註冊,每個目標群組的路由都是獨立運作。

搭配網路負載平衡器使用時,接收連線的負載平衡器節點會使用下列程序:

  1. 使用流量雜湊演算法,從目標群組中選取預設規則的目標。演算法是基於:

    • 通訊協定

    • 來源 IP 地址和來源連接埠

    • 目的地 IP 地址和目的地連接埠

    • TCP 序號

  2. 在連線的有效期內,將每個單獨的 TCP 連線路由至單個目標。來自用戶端的 TCP 連線具有不同的來源連接埠和序號,可以路由至不同的目標。

搭配Classic Load Balancer如下所示,接收請求的負載平衡器節點會選取已註冊的執行個體:

  • TCP 接聽程式使用的循環配置路由演算法

  • HTTP 和 HTTPS 接聽程式使用的最少未完成的請求路由演算法

HTTP 連接

傳統負載均衡器使用預打開連接,但應用程序負載均衡器不使用。經典負載均衡器和應用程序負載均衡器都使用連接多路複用。這表示在多個前端連線上來自多個用戶端的請求,可以透過單一後端連線而路由到指定的目標。連線多工可縮短延遲並降低應用程式的負載。若要防止連線多工,請停用 HTTPkeep-alive頭文件,方法是設置Connection: close頭文件。

Application Load Balancer 和 Classic Load Balancer 在前端連線上支援管道式 HTTP。它們在後端連線上不支援管道式 HTTP。

Application Load Balancer 在前端連線上支援以下通訊協定:HTTP/0.9, HTTP/1.0, HTTP/1.0, HTTP/1.1 和 HTTP/2. 您只能將 HTTP/2 搭配 HTTPS 接聽程式一起使用,而使用一個 HTTP/2 連線時可 parallel 傳送最多 128 個請求。應用程序負載均衡器還支持從 HTTP 到 WebSockets 的連接升級。但是,如果存在連接升級,則應用程序負載平衡器偵聽器路由規則和AWS WAF集成不再適用。

預設情況下,Application Load Balancer 會在後端連線上 (負載平衡器到註冊目標) 使用 HTTP/1.1。但是,您可以使用協議版本將請求發送到使用 HTTP/2 或 gRPC 的目標。如需詳細資訊,請參閱「」協定版本。所以此keep-alive默認情況下,後端連接支持標頭。對於來自用戶端而沒有主機標頭的 HTTP/1.0 請求,負載平衡器會針對後端連線上傳送的 HTTP/1.1 請求,產生主機標頭。主機標頭包含負載平衡器的 DNS 名稱。

Classic Load Balancer 在前端連線上 (客户端到負載平衡器) 支援以下通訊協定:HTTP/0.9, HTTP/1.0 和 HTTP/1.1. 它們會在後端連線上 (負載平衡器到註冊目標) 使用 HTTP/1.1。所以此keep-alive默認情況下,後端連接支持標頭。對於來自用戶端而沒有主機標頭的 HTTP/1.0 請求,負載平衡器會針對後端連線上傳送的 HTTP/1.1 請求,產生主機標頭。主機標頭包含負載平衡器節點的 IP 地址。

HTTP 標頭

Application Load Balancer 和 Classic Load Balancer 會自動添加X-Forwarded-ForX-Forwarded-Proto,和X-Forwarded-Port請求標頭。

應用程序負載均衡器將 HTTP 主機標頭中的主機名轉換為小寫,然後再將它們發送到目標。

對於使用 HTTP/2 的前端連線,標頭名稱是小寫。在使用 HTTP/1.1 將請求傳送到目標之前,以下標頭名稱會轉換為大小寫混合:X-Forwarded-ForX-Forwarded-ProtoX-Forwarded-PortHost (主機)X-Amzn-Trace-ID升級,和Connection (連線)。所有其他標頭名稱都是小寫。

在代理將回應傳回給用户端之後,就會遵守來自傳入用户端請求的連線標頭。

當 Application Load Balancer 和 Classic Load Balancer 收到expect標頭時,它們會立即回應用户端 HTTP 100 Continue,而不測試內容長度標頭、移除expect標頭,然後路由請求。

HTTP 標頭限制

以下 Application Load Balancer 的大小限制是無法變更的硬性限制。

HTTP/1.x 標頭

  • 請求列:16 K

  • 單一標頭:16 K

  • 整個標頭:64 K

HTTP/2 標頭

  • 請求列:16 K

  • 單一標頭:16 K

  • 整個標頭:64 K

負載平衡器方案

當您建立負載平衡器時,您必須選擇將它當做內部負載平衡器或面向網際網路的負載平衡器。請注意,當您在 EC2-Classic 中建立 Classic 負載平衡器時,它必須是面向網際網路的負載平衡器。

面向網際網路負載平衡器的節點具有公有 IP 地址。面向網際網路負載平衡器之 DNS 名稱可公開解析為節點的公有 IP 地址。因此,面向網際網路的負載平衡器可透過網際網路來路由用戶端請求。

內部負載平衡器的節點僅具有私有 IP 地址。內部網際網路負載平衡器之 DNS 名稱可公開解析為節點的私有 IP 地址。因此,內部負載平衡器只能使用負載平衡器的 VPC 存取來路由用戶端請求。

面向網際網路和內部的負載平衡器都使用私有 IP 地址,將請求路由到您的目標。因此,您的目標不需要公有 IP 地址,就能收到來自內部或面向網際網路的負載平衡器的請求。

如果您的應用程式有多個層級,您可以設計同時使用內部和面向網際網路的負載平衡器的架構。例如,如果您的應用程式使用必須連接到網際網路的 Web 伺服器,以及只連接到 Web 伺服器的應用程式伺服器都是如此。建立面向網際網路的負載平衡器,並向它註冊 Web 伺服器。建立內部負載平衡器,並向它註冊應用程式伺服器。Web 伺服器會從面向網際網路的負載平衡器接收請求,並將對於應用程式伺服器的請求傳送到內部負載平衡器。應用程式伺服器會接收來自內部負載平衡器的請求。

適用於您的負載均衡器的網絡 MTU

網路連線的最大傳輸單位 (MTU) 係允許通過該連線的最大封包大小 (以位元組為單位)。連線的 MTU 越大,單一封包能傳遞的資料也越多。乙太網路封包內含訊框 (即您實際傳送的資料) 和環繞的網路成本資訊。通過網際網路閘道傳送的流量,其限制為 1500 MTU。這意味着,若數據包超過 1500 位元組將被切割為片段,或者如果Don't Fragment標頭會設定 IP 標頭。

負載均衡器節點上的 MTU 大小不可配置。巨型幀 (9001 MTU) 是針對 Aplication Load Balancer、Network Load Balancer 和 Classic Load Balancer 的標準裝置。網關負載均衡器支持 8500 MTU。如需詳細資訊,請參閱「」最大傳輸單位 (MTU)中的閘道負載平衡器的使用者指南

路徑 MTU 是原始主機與接收主機之間的路徑上支援的最大封包大小。路徑 MTU 探索 (PMTUD) 可用於確認兩個裝置間的路徑 MTU。如果客户端或目標不支持巨型幀,則路徑 MTU 發現尤其重要。

若主機傳送的封包大小大於接收主機的 MTU,或是大於路徑上裝置的 MTU,則接收主機或裝置便會丟棄封包,然後傳回下列 ICMP 訊息:Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4)。 這會指示傳輸主機將負載拆分為多個較小的封包,然後重新傳輸它們。

如果大於客户端或目標接口的 MTU 大小的數據包繼續被丟棄,則路徑 MTU 發現 (PMTUD) 可能無法正常工作。為避免這種情況,請確保路徑 MTU 發現正在端到端工作,並且您已在客户端和目標上啟用了巨型幀。有關路徑 MTU 發現和啟用巨型幀的詳細信息,請參閲路徑 MTU 探索中的Amazon EC2 使用者指南