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

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

Elastic Load Balancing 的運作

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

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

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

  • Application Load Balancer

  • 網路負載平衡器

  • 閘道負載平衡器

  • Classic Load Balancer

負載平衡器類型的設定方式有關鍵的差異。若採用 Application 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% 的用戶端流量路由到其可用區域內的目標。

停用跨區域負載平衡時

使用應用程式負載平衡器，跨區域負載平衡器一律會在負載平衡器層級啟用。在目標群組層級，可停用跨區域負載平衡。如需詳細資訊，請參閱 Ap plication Load Balancer 使用者指南中的關閉跨區域負載平衡器。

若採用 Network Load Balancer 和 Gateway Load Balancer，預設會停用跨區域負載平衡器。建立負載平衡器後，您隨時可以啟用或停用跨區域負載平衡。

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

區域轉移

區域轉移是亞馬遜 Route 53 應用程序恢復控制器（路線 53 ARC）中的一種功能。透過區域轉移，您可以透過單一動作，將負載平衡器資源從受損的可用區域移開。如此一來，您就可以繼續從AWS 區域.

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

僅在關閉跨區域負載平衡的情況下，應用程式負載平衡器和網路負載平衡器支援區域偏移。如果您開啟跨區域負載平衡，就無法啟動區域偏移。如需詳細資訊，請參閱 Amazon Route 53 Application Recovery Controller 開發人員指南中的區域轉移支援的資源。

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

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

  • 當您在中使用應用程式負載平衡器做為加速器端點時，不支援區域移位AWS Global Accelerator。

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

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

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

如需詳細指引和資訊，請參閱 Amazon Route 53 應用程式復原控制器開發人員指南中的 Route 53 ARC 區域變更的最佳實務。

要求路由

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

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

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

路由演算法

使用應用程式負載平衡器時，接收要求的負載平衡器節點會使用下列程序：

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

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

使用網路負載平衡器時，接收連線的負載平衡器節點會使用下列程序：

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

    • 通訊協定

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

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

    • TCP 序號

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

使用傳統負載平衡器時，接收要求的負載平衡器節點會選取已註冊的執行個體，如下所示：

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

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

HTTP 連線

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

應用程式負載平衡器和傳統負載平衡器支援前端連線上的管線 HTTP。它們在後端連線上不支援管道式 HTTP。

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

根據預設，應用程式負載平衡器會在後端連線 (負載平衡器到註冊目標) 上使用 HTTP/1.1。不過，您可以使用通訊協定版本，使用 HTTP/2 或 gRPC 將要求傳送至目標。如需詳細資訊，請參閱 Protocol Protocol Re 默認情況下，後端連接支持keep-alive標頭。對於來自用戶端而沒有主機標頭的 HTTP/1.0 請求，負載平衡器會針對後端連線上傳送的 HTTP/1.1 請求，產生主機標頭。主機標頭包含負載平衡器的 DNS 名稱。

傳統負載平衡器在前端連線 (用戶端到負載平衡器) 上支援下列通訊協定：HTTP/0.9、HTTP/1.0 和 HTTP/1.1。他們在後端連接（負載平衡器到註冊目標）上使用 HTTP/1.1。默認情況下，後端連接支持keep-alive標頭。對於來自用戶端而沒有主機標頭的 HTTP/1.0 請求，負載平衡器會針對後端連線上傳送的 HTTP/1.1 請求，產生主機標頭。主機標頭包含負載平衡器節點的 IP 位址。

HTTP 標頭

應用程式負載平衡器和傳統負載平衡器會自動將 X 轉送用於、X 轉送原型和 X 轉送連接埠標頭新增至要求。

應用程式負載平衡器將 HTTP 主機標頭中的主機名稱轉換為小寫，然後再將它們傳送至目標。

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

應用程式負載平衡器和傳統負載平衡器會在將回應代理回應至用戶端後，接受來自傳入用戶端要求的連線標頭。

當應用程式負載平衡器和傳統負載平衡器收到預期標頭時，它們會立即使用 HTTP 100 Continue 回應用戶端，而不測試內容長度標頭、移除 Exp ect 標頭，然後路由傳送要求。

HTTP 標頭

應用程式負載平衡器的下列大小限制是無法變更的硬性限制：

  • 請求行：16 K

  • 單一標頭：16 K

  • 整個回應標頭：32 K

  • 整個請求標頭：64 K

負載平衡器方案

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

EC2-Classic 網路於 2022 年 8 月 15 日淘汰，建議您將 Classic Load Balancer 從 EC2-Classic 網路遷移至 VPC。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的從 EC2-Classic 遷移至 VPC，以及部落格文章 EC2-Classic Networking is Retiring – Here’s How to Prepare 。

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

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

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

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

負載平衡器的網路 MTU

網路連線的最大傳輸單位 (MTU) 係允許通過該連線的最大封包大小 (以位元組為單位)。連線的 MTU 越大，單一封包能傳遞的資料也越多。乙太網路封包內含訊框 (即您實際傳送的資料) 和環繞的網路成本資訊。透過網際網路閘道傳送的流量，其限制為 1500 MTU。這表示若封包超過 1500 位元組將被切割為片段，若其 IP 標頭設有Don't Fragment旗標，則會將其捨棄。

負載平衡器節點上的 MTU 大小無法設定。Jumbo Frame (9001 MTU) 是 Application Load Balancer、Network Load Balancer 和 Classic Load Balancer 的標準。閘道負載平衡器支援 8500 MTU。如需詳細資訊，請參閱 Gateway Load Balancer 使用者指南中的最大傳輸裝置 (MTU)。

路徑 MTU 是原始主機和接收主機之間的路徑上支援的最大封包尺寸。路徑 MTU 探索 (PMTUD) 可用於確認兩個裝置間的路徑 MTU。如果用戶端或目標不支援 Jumbo 框架，路徑 MTU 探索尤其重要。

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

如果繼續捨棄大於用戶端或目標介面 MTU 大小的封包，則可能是路徑 MTU 探索 (PMTUD) 無法運作。若要避免這種情況，請確定 Path MTU 探索是以端對端運作，而且您已在用戶端和目標上啟用 Jumbo 框架。如需詳細瞭解路徑 MTU 探索和啟用巨型訊框，請參閱 Amazon EC2 使用者指南中的路徑 MTU 探索。