Elastic Load Balancing 的運作方式 - Elastic Load Balancing
可用區域和負載平衡器節點要求路由負載平衡器機制網路 MTU

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

Elastic Load Balancing 的運作方式

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

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

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

  • Application Load Balancer

  • Network Load Balancer

  • 閘道負載平衡器

  • Classic Load Balancer

負載平衡器類型的設定方式有關鍵的差異。使用 Application Load Balancer、Network Load Balancer 和 Gateway Load Balancer，您可以在目標群組中註冊目標，並將流量路由到目標群組。使用 Classic Load Balancer，您可以在負載平衡器中註冊執行個體。

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

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

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

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

跨區域負載平衡

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

下列圖表示範以循環配置作為預設路由演算法的跨區域負載平衡效果。有兩個已啟用的可用區域，可用區域 A 有兩個目標，可用區域 B 有八個目標。用戶端傳送請求，Amazon Route 53 會以其中一個負載平衡器節點的 IP 地址來回應每個請求。根據循環配置路由演算法，流量會經過分散，以便每個負載平衡器節點接收來自用戶端的 50% 流量。每個負載平衡器節點會將其流量份額分發到其範圍內已註冊的目標。

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

啟用跨區域負載平衡時

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

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

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

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

停用跨區域負載平衡時

如果使用的是 Application Load Balancer，跨區域負載平衡一律會在負載平衡器層級啟用。在目標群組層級，可以停用跨區域負載平衡。如需詳細資訊，請參閱 User Guide for Application Load Balancers 中的 Turn off cross-zone load balancing。

如果使用的是 Network Load Balancer 和 Gateway Load Balancer，跨區域負載平衡預設為停用。建立負載平衡器後，您隨時可以啟用或停用跨區域負載平衡。

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

區域轉移

區域轉移是 Amazon Route 53 應用程式復原控制器 (Route 53 ARC) 中的一個功能。透過區域轉移，您可以透過單一動作，將負載平衡器資源從受損的可用區域轉移。如此一來，您就可以繼續從 AWS 區域中其他運作狀況良好的可用區域進行操作。

當您啟動區域轉移時，負載平衡器會停止將資源的流量傳送至受影響的可用區域。Route 53 ARC 會立即建立區域轉移。不過，可能需要很短的時間 (通常最多幾分鐘)，才能完成受影響可用區域中現有正在進行中的連線。如需詳細資訊，請參閱《Amazon Route 53 應用程式復原控制器開發人員指南》中的區域轉移如何運作：運作狀態檢查和區域 IP 地址。

只有在關閉跨區域負載平衡的情況下，Application Load Balancer 和 Network Load Balancer 才支援區域轉移。如果您開啟跨區域負載平衡，就無法啟動區域轉移。如需詳細資訊，請參閱《Amazon Route 53 應用程式復原控制器開發人員指南》中的支援區域轉移的資源。

在使用區域轉移之前，請檢閱以下內容：

  • 區域轉移不支援跨區域負載平衡。您必須關閉跨區域負載平衡才能使用此功能。

  • 當您在 AWS Global Accelerator中使用 Application Load Balancer 做為加速器端點時，不支援區域轉移。

  • 您只能針對單一可用區域，啟動特定負載平衡器的區域轉移。您無法為多個可用區域啟動區域轉移。

  • AWS 當多個基礎結構問題影響服務時，會主動移除 DNS 中的區域負載平衡器 IP 位址。在啟動區域轉移之前，請務必檢查目前的可用區域容量。如果您的負載平衡器已關閉跨區域負載平衡，而您使用區域轉移來移除區域負載平衡器 IP 地址，則受區域轉移影響的可用區域也會失去目標容量。

  • 當 Application Load Balancer 是 Network Load Balancer 的目標時，請務必從 Network Load Balancer 啟動區域轉移。如果您從 Application Load Balancer 啟動區域轉移，Network Load Balancer 將無法辨識轉移，並繼續將流量傳送至 Application Load Balancer。

如需詳細指南和資訊，請參閱 Amazon Route 53 Application Recovery Controller Developer Guide 中的 Best practices with Route 53 ARC zonal shifts。

要求路由

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

當應用程式的流量隨著時間而變化時，Elastic Load Balancing 會調整負載平衡器的規模，並更新 DNS 項目。DNS 項目也會指定 60 秒的 time-to-live (TTL)。這有助於確保 IP 地址可以快速重新對應，以回應變更的流量。

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

如需詳細資訊，請參閱《Amazon Route 53 開發人員指南》中的將流量路由到 ELB 負載平衡器。

路由演算法

如果使用的是 Application Load Balancer，接收請求的負載平衡器節點會使用下列程序：

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

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

如果使用的是 Network Load Balancer，接收連線的負載平衡器節點會使用下列程序：

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

    • 通訊協定

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

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

    • TCP 序號

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

如果使用的是 Classic Load Balancer，接收請求的負載平衡器節點會選取已註冊的執行個體，如下所示：

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

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

HTTP 連線

Classic Load Balancer 會使用預先開啟的連線，但 Application Load Balancer 不會。Classic Load Balancer 和 Application Load Balancer 都會使用連線多工。這表示在多個前端連線上來自多個用戶端的請求，可以透過單一後端連線而路由到指定的目標。連線多工可縮短延遲並降低應用程式的負載。若要防止連線多工，請在 HTTP 回應中設定 Connection: close 標頭以停用 HTTP keep-alive 標頭。

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

應用程式負載平衡器支援下列 HTTP 要求方法：GET、HEAD、POST、置入、刪除、選項和修補程式。

Application Load Balancer 在前端連線上支援以下通訊協定：HTTP/0.9、HTTP/1.0、HTTP/1.1 和 HTTP/2。您只能將 HTTP/2 與 HTTPS 接聽程式一起搭配使用，而使用一個 HTTP/2 連線時可平行傳送最多 128 個請求。應用程式負載平衡器也支援從 HTTP 到 WebSockets的連線升級。不過，如果有連線升級，Application Load Balancer 接聽程式路由規則和 AWS WAF 整合將不再適用。

根據預設，Application Load Balancer 會在後端連線 (負載平衡器到已註冊目標) 上使用 HTTP/1.1。您可以使用通訊協定版本，透過 HTTP/2 或 gRPC 將請求傳送至目標。如需詳細資訊，請參閱 Protocol versions。根據預設，後端連線支援 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-For、X-Forwarded-Proto 和 X-Forwarded-Port 標頭新增至請求。

Application Load Balancer 會將 HTTP 主機標頭中的主機名稱轉換為小寫，然後再將它們傳送至目標。

對於使用 HTTP/2 的前端連線，標頭名稱是小寫。在使用 HTTP/1.1 將請求傳送到目標之前，以下標頭名稱會轉換為大小寫混合：X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Port、Host、X-Amzn-Trace-ID、Upgrade 和 Connection。所有其他標頭名稱都是小寫。

Application Load Balancer 和 Classic Load Balancer 在代理將回應傳回給用戶端之後，就會遵守來自傳入用戶端請求的連線標頭。

使用 HTTP/1.1 的 Application Load Balancer 和 Classic Load Balancer 收到 Expect: 100-Continue 標頭後，它們會立即回應 HTTP/1.1 100 Continue，而不測試內容長度標頭。Expect: 100-Continue 請求標頭不會轉送到目標。

使用 HTTP/2 時，Application Load Balancer 不支援用戶端請求的 Expect: 100-Continue 標頭。Application Load Balancer 不會回應 HTTP/2 100 Continue 或將此標頭轉送至目標。

HTTP 標頭限制

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

  • 請求行：16 K

  • 單一標頭：16 K

  • 整個回應標頭：32 K

  • 整個請求標頭：64 K

負載平衡器機制

當您建立負載平衡器時，您必須選擇將它當做內部負載平衡器或面向網際網路的負載平衡器。

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

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

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

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

負載平衡器的網路 MTU

最大傳輸單位 (MTU) 決定可透過網路傳送的封包大小上限 (以位元組為單位)。連線的 MTU 越大，單一封包能傳遞的資料也越多。乙太網幀內含封包 (或您實際傳送的資料) 和環繞的網路額外負荷資訊。透過網際網路閘道傳送的流量 MTU 為 1500。這意味著，如果一個封包超過 1500 個位元組，它會被分段，以多個訊框傳送；如果在 IP 標頭中設置 Don't Fragment，則封包會被丟棄。

負載平衡器節點上的 MTU 大小無法設定。Application Load Balancer、Network Load Balancer 和 Classic Load Balancer 的負載平衡器節點上所使用的標準是巨型訊框 (9001 MTU)。Gateway Load Balancer 支援 8500 MTU。如需詳細資訊，請參閱 User Guide for Gateway Load Balancers 中的 Maximum transmission unit (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 探索和啟用巨型訊框的詳細資訊，請參閱《Amazon EC2 使用者指南》中的路徑 MTU 探索。