Elastic Load Balancing 的運作方式 - Elastic Load Balancing
可用區域和負載平衡器節點要求路由負載平衡器機制IP 地址類型網路 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，跨區域負載平衡預設為停用。建立負載平衡器後，您隨時可以啟用或停用跨區域負載平衡。如需詳細資訊，請參閱 Network Load Balancer 使用者指南中的跨區域負載平衡。

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

區域轉移

區域轉移是 Amazon Application Recovery Controller （ARC） （） 中的功能ARC。透過區域轉移，您可以透過單一動作，將負載平衡器資源從受損的可用區域轉移。如此一來，您就可以繼續從 AWS 區域中其他運作狀況良好的可用區域進行操作。

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

只有在關閉跨區域負載平衡的情況下，Application Load Balancer 和 Network Load Balancer 才支援區域轉移。如果您開啟跨區域負載平衡，就無法啟動區域轉移。如需詳細資訊，請參閱 Amazon Application Recovery Controller （ARC） 開發人員指南 中的區域轉移支援的資源。

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

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

  • 當您在 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 Application Recovery Controller （ARC） 開發人員指南 中的使用 Route 53 ARC 區域轉移的最佳實務。

要求路由

在用戶端將請求傳送至負載平衡器之前，它會使用網域名稱系統 （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 項目也會指定 time-to-live 60 秒的 （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回應中設定HTTPkeep-alive標頭以停用Connection: close標頭。

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

Application Load Balancer 支援下列HTTP請求方法：GET、HEAD、POST、PUT、DELETE、 OPTIONS和 PATCH。

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

Application Load Balancer 預設會在後端連線 （負載平衡器到已註冊目標） 上使用 HTTP/1.1。不過，您可以使用通訊協定版本，使用 HTTP/2 或 g 將請求傳送至目標RPC。如需詳細資訊，請參閱 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 、主機 、X-Amzn-Trace-Id 、升級 和連線 。所有其他標頭名稱都是小寫。

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

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

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

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 伺服器會從面向網際網路的負載平衡器接收請求，並將對於應用程式伺服器的請求傳送到內部負載平衡器。應用程式伺服器會接收來自內部負載平衡器的請求。

IP 地址類型

您為負載平衡器指定的 IP 地址類型決定用戶端如何與負載平衡器通訊。

  • IPv4 僅限 - 用戶端使用公有和私有IPv4地址進行通訊。您為負載平衡器選取的子網路必須具有IPv4地址範圍。

  • Dualstack – 用戶端使用公有和私有IPv4和IPv6地址進行通訊。您為負載平衡器選取的子網路必須具有 IPv4和 IPv6 地址範圍。

  • 無公有的雙堆疊 IPv4 – 用戶端使用公有和私有IPv6地址和私有IPv4地址進行通訊。您為負載平衡器選取的子網路必須具有 IPv4和 IPv6 地址範圍。internal 負載平衡器方案不支援此選項。

下表說明每個負載平衡器類型支援的 IP 地址類型。

負載平衡器類型 IPv4 僅限 Dualstack 無公有的雙堆疊 IPv4
Application Load Balancer 是 是 是
Network Load Balancer 是 是 否
Gateway Load Balancer 是 是 否
Classic Load Balancer 是 否 否

您為目標群組指定的 IP 地址類型決定負載平衡器如何與目標通訊。

  • IPv4 僅限 – 負載平衡器使用私有IPv4地址進行通訊。您必須使用具有目標群組IPv4的地址註冊IPv4目標。

  • IPv6 僅限 – 負載平衡器使用IPv6地址進行通訊。您必須向目標群組註冊具有IPv6地址IPv6的目標。目標群組必須與雙堆疊負載平衡器搭配使用。

下表說明每個目標群組通訊協定支援的 IP 地址類型。

目標群組通訊協定 IPv4 僅限 IPv6 僅限
HTTP 和 HTTPS 是 是
TCP 是 是
TLS 是 是
UDP 和 TCP_UDP 是 否
GENEVE - -

負載平衡器MTU的網路

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

負載平衡器節點上的MTU大小無法設定。巨型訊框 （9001MTU） 是 Application Load Balancer、Network Load Balancer 和 Classic Load Balancer 跨負載平衡器節點的標準。Gateway Load Balancer 支援 8500 MTU。如需詳細資訊，請參閱 Gateway Load Balancer 使用者指南中的最大傳輸單位 （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探索。