Load Balancer 中的可靠性

本文針對 Load Balancer 提供具體的可靠性建議，並詳細說明 Load Balancer 區域復原與可用性區域，以及跨區域災害復原和商務持續性。

有關 Azure 可靠性的結構概觀，請參閱 Azure 可靠性。

可靠性建議

本節內含成功復原和可用性的建議。 每個建議都屬以下其中一類 (共兩類)：

• 健康情況項目涵蓋的領域包括設定項目，以及構成 Azure 工作負載 (例如 Azure 資源組態設定、與其他服務的相依性等) 的主要元件的正確函式。

• 風險項目涵蓋的領域包括可用性和復原需求、測試、監視、部署等其他項目，若不解決，環境將經常出現問題。

可靠性建議優先順序矩陣

每個建議都根據以下優先順序矩陣標記：

映像	優先順序	描述
	高	需要立即修正。
	中	在 3-6 個月內修正。
	低	需要檢閱。

可靠性建議摘要

類別	優先順序	建議
可用性		確定 Standard Load Balancer 是區域備援
		確定後端集區至少包含兩個執行個體
系統效率		使用 NAT 閘道，而不是生產工作負載的輸出規則
		使用 Standard Load Balancer SKU

可用性

確定 Standard Load Balancer 是區域備援

在支援可用性區域的區域中，應該使用區域備援來部署 Standard Load Balancer。 區域備援 Load Balancer 可讓流量由可承受區域失敗的單一前端 IP 位址提供。 不論區域為何，前端 IP 都可以用來連線到所有 (非受影響的) 後端集區成員。 如果可用性區域失敗，只要區域中的剩餘區域維持良好狀況，資料路徑就可以存留。 如需詳細資訊，請參閱區域備援負載平衡器。

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

確定後端集區至少包含兩個執行個體

在後端部署至少有兩個執行個體的 Load Balancer。 單一執行個體可能會導致單一失敗點。 為了針對調整而建置，您可能會想要將負載平衡器與虛擬機器擴展集配對。

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

系統效率

使用 NAT 閘道，而不是生產工作負載的輸出規則

輸出規則會將固定數量的 SNAT 連接埠配置給後端集區中的每個虛擬機器執行個體。 這種配置方法可能會導致 SNAT 連接埠耗盡，尤其是在不平均的流量模式導致特定虛擬機器傳送較大量的傳出連線時。 針對生產工作負載，建議您將 Standard Load Balancer 或任何子網路部署與 Azure NAT 閘道結合在一起。 NAT 閘道會動態配置子網路中所有虛擬機器執行個體的 SNAT 連接埠，進而降低 SNAT 連接埠耗盡的風險。

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

使用 Standard Load Balancer SKU

Standard SKU Load Balancer 支援可用性區域和區域復原功能，而基本 SKU 則不支援。 當區域關閉時，您的區域備援 Standard Load Balancer 將不會受到影響，而且您的部署能夠承受區域內的區域失敗。 此外，Standard Load Balancer 支援跨區域負載平衡，以確保您的應用程式不會受到區域失敗的影響。

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

可用性區域支援

Azure 可用性區域是每個 Azure 區域內至少三個實體上獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻和網路基礎結構。 可用性區域的作用是在一個區域受影響時 (例如本機區域失敗時)，讓其餘兩個區域支援區域服務、容量和高可用性。

這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 Azure 服務的備援和邏輯隔離功能可以容錯。 如需深入了解 Azure 的可用性區域，請參閱區域和可用性區域。

已啟用 Azure 可用性區域的服務是設計來提供正確的可靠性和彈性層級。 您可以透過兩種方式加以設定。 可採用區域備援 (可跨區域自動複寫) 或分區 (將執行個體釘選在特定區域)。 兩種方法可以結合使用。 如需區域與區域備援結構的詳細資訊，請參閱使用可用性區域和區域的建議。

Azure Load Balancer 支援可用性區域情節。 您可以使用 Standard Load Balancer 來調整資源並分散到多個區域，在整個情節中提高可用性。 請檢閱本文件以了解這些概念，以及基本案例的設計指引。

雖然建議您部署具有區域備援的 Load Balancer，但 Load Balancer可以是區域備援、區區或非區域。 負載平衡器的可用性區域選取項目與其前端 IP 的區域選取項目同義。 針對公用負載平衡器，如果負載平衡器前端的公用 IP 是區域備援，則負載平衡器也是區域備援。 如果負載平衡器前端的公用 IP 是區域性的，則負載平衡器也會被指定至相同的區域。 若要為您的負載平衡器設定區域相關的屬性，請選取前端所需的適當類型。

必要條件

• 若要搭配 Load Balancer 使用可用性區域，您必須在支援可用性區域的區域中建立負載平衡器。 若要查看哪些區域支援可用性區域，請參閱支援區域清單。

• 針對負載平衡器使用 Standard SKU，而針對可用性區域支援使用公用 IP。

• 不支援基本 SKU 類型。

• 若要建立您的資源，您必須具備網路參與者角色或更高角色。

限制

• 建立之後，就無法變更、更新或建立資源的區域。
• 資源在建立之後，無法從區域性更新為區域備援，反之亦然。

區域備援負載平衡器

在具有可用性區域的區域中，Standard Load Balancer 可以是區域備援，流量是由單一 IP 位址所提供。 單一前端 IP 位址經得起區域失效。 不論區域如何，前端 IP 都可用來觸達所有 (不受影響的) 後端集區成員。 最多可有一個可用性區域失敗，且只要區域中剩餘的區域維持良好狀況，資料路徑就得以存留。

前端的單一 IP 位址由多個可用性區域中的多個獨立基礎結構部署來同時提供服務。 在不受區域失效所影響的其他區域中，任何重試或重新建立都會成功。

負載平衡器後端集區中的成員通常會與單一區域 (例如區域虛擬機器) 相關聯。 生產工作負載的常見設計就是具有多個區域資源。 例如，將來自區域 1、2 和 3 的虛擬機器放在具有區域備援前端的負載平衡器後端，符合此設計原則。

分區負載平衡器

您可以選擇由前端來保障單一區域，稱為區域性。 在此案例中，區域中的單一區域會提供所有輸入或輸出流程。 您的前端共享與區域的健康情況息息相關。 資料路徑不受保證區域以外區域的失敗所影響。 您可以使用區域性前端依據每個可用性區域來公開 IP 位址。

此外，也支援在每個區域內，直接針對負載平衡的端點使用區域性前端。 您也可以使用此設定來公開每個區域的負載平衡端點，以個別監視每個區域。 針對公用端點，您可以將其與 DNS 負載平衡產品 (例如流量管理員) 整合，並使用單一 DNS 名稱。

對於公用負載平衡器前端，請將 zones 參數新增至公用 IP。 個別規則所使用的前端 IP 設定會參考此公用 IP。

對於內部負載平衡器前端，請將 zones 參數新增至內部負載平衡器前端 IP 設定。 區域性前端會保障特定區域的子網路中都有 IP 位址。

非區域性負載平衡器

您也可以使用「非區域」前端，在非區域性設定中建立負載平衡器。 在這些案例中，公用負載平衡器將會使用公用 IP 或公用 IP 前置詞，而內部負載平衡器將會使用私人 IP。 此選項不保證提供備援。

SLA 改善項目

可用性區域在實體上是獨立的，提供不同的電源、網路和冷卻，因此 SLA (服務等級協定) 可能會增加。 如需詳細資訊，請參閱線上服務的服務等級協定 (SLA)。

建立已啟用可用性區域的資源

若要了解如何使用 Load Balancer 對區域內或多個區域內的 VM 進行負載平衡，請參閱快速入門：建立公用負載平衡器以負載平衡 VM。

容錯

虛擬機器可以容錯移轉到叢集的另一台伺服器，VM 的作業系統會在新的伺服器上重新啟動。 您應該參閱災害復原的容錯移轉流程、收集復原規劃中的虛擬機器，以及執行災害復原演練，以確保其容錯解決方案成功。

如需詳細資訊，請參閱站台復原流程。

區域關閉體驗

區域備援不隱含表示無中斷的資料平面或控制平面。 區域備援流量可以使用任何區域，且您的流量將使用區域中所有健康情況良好的區域。 在區域失敗中，使用狀況良好的區域的流量不會受到影響。

在區域失敗時使用區域的流量會受到影響，但應用程式可以復原。 當 Azure 因區域失敗而彙集時，流量會在區域內狀況良好的區域中繼續。

檢閱 Azure 雲端設計模式，以改善應用程式對失敗案例的復原能力。

多個前端

使用多個前端可讓您對多個連接埠和/或 IP 位址的流量進行負載平衡。 設計架構時，請確定您考慮區域備援如何與多個前端互動。 如果您的目標是一律讓每個前端都具有從失敗復原的能力，則指派為前端的所有 IP 位址都必須是區域備援。 如果一組前端要與單一區域相關聯，則該集合的每個 IP 位址都必須與該特定區域相關聯。 不需要每個區域中都有一個負載平衡器。 相反地，每個區域前端或一組區域性前端可以與後端集區中屬於該特定可用性區域的虛擬機器相關聯。

安全部署技術

檢閱 Azure 雲端設計模式，以改善應用程式對失敗案例的復原能力。

移轉至可用性區域支援

如果區域已擴增為具有可用性區域，則任何現有的 IP 都會保持非區域性，就像用於負載平衡器前端的 IP 一樣。 為了確保您的架構可以利用新的區域，建議您建立新的前端 IP。 建立之後，您可以將現有的非區域前端取代為新的區域備援前端。 若要了解如何將 VM 移轉至可用性區域支援，請參閱將 Load Balancer 移轉至可用性區域支援。

跨區域災害復原和商務持續性

災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始制定災害復原方案之前，請參閱設計災害復原策略的建議。

Microsoft 在災害復原方面，採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時許多 Azure 服務不會自動複寫資料，或從故障區域恢復並交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合您工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務，都有提供支援災害復原的功能和指導，您可以使用特定服務功能快速復原，制定災害復原方案。

Azure Standard Load Balancer 支援跨區域負載平衡，可實現異地備援高可用性情節，例如：

• 來自多個區域的傳入流量。
• 立即全域容錯移轉至下一個最佳的區域部署。
• 負載跨區域分散至超低延遲的最近 Azure 區域。
• 能夠在單一端點後方擴大/縮小。
• 靜態的任一傳播全域 IP 位址
• 用戶端 IP 保留
• 基於現有的負載平衡器解決方案，免除學習曲線

跨區域負載平衡器的前端 IP 設定是靜態，並公告於大部分 Azure 區域。

多區域地理位置的災害復原

區域備援

將跨區域負載平衡器無縫地連結到現有的區域負載平衡器，來設定區域備援。

如果一個區域失敗，流量會路由至下一個最接近狀況良好的區域負載平衡器。

跨區域負載平衡器的健全狀態探查每隔 5 秒會收集一次每個區域負載平衡器的可用性相關資訊。 如果有一個區域負載平衡器的可用性降至 0，跨區域負載平衡器會偵測到失敗。 然後，該區域負載平衡器就會退出輪替。

超低延遲

地理位置鄰近性負載平衡演算法以使用者所在地理位置和區域部署為基礎。

始於用戶端的流量會到達最接近的參與區域，然後經過 Microsoft 全球網路骨幹抵達最接近的區域部署。

例如，假設您有一個跨區域負載平衡器，而標準負載平衡器位於下列 Azure 區域：

• 美國西部
• 北歐

如果流程始於西雅圖，則流量會進入美國西部。 此區域是西雅圖最接近的參與區域。 流量會路由傳送至最接近的區域負載平衡器，也就是美國西部。

Azure 跨區域負載平衡器使用地理位置鄰近性負載平衡演算法來決定路由。

當地理位置鄰近性用到多個區域負載平衡器時，將由區域負載平衡器已設定的負載分散模式做出路由最終決定。

如需詳細資訊，請參閱設定 Azure Load Balancer 的分送模式。

輸出流量會遵循區域負載平衡器上設定的路由喜好設定。

能夠在單一端點後方擴大/縮小

當您向客戶公開跨區域負載平衡器的全域端點時，您可以在全域端點後方新增或移除區域部署，而不會導致運作中斷。

靜態的任一傳播全域 IP 位址

跨區域負載平衡器隨附靜態公用 IP，可確保 IP 位址維持不變。 若要深入了解靜態 IP，請看這裡

用戶端 IP 保留

跨區域負載平衡器是第 4 層傳遞網路負載平衡器。 此傳遞保留封包的原始 IP。 原始 IP 可供虛擬機器上執行的程式碼使用。 這項保留可讓您套用 IP 位址專屬的邏輯。

浮動 IP

浮動 IP 可以同時在全域 IP 層級和區域 IP 層級設定。 如需詳細資訊，請造訪多個 Azure Load Balancer 前端

請務必注意，在 Azure 跨區域負載平衡器上設定的浮動 IP 操作時，與後端區域負載平衡器上的浮動 IP 設定無關。 如果在跨區域負載平衡器上啟用了浮動 IP，則必須將適當的回送介面新增至後端 VM。

健全狀態探查

Azure 跨區域負載平衡器會在決定將流量分散到何處時，利用後端區域負載平衡器的健康情況。 如果使用者已在其區域負載平衡器上設定健全狀態探查，則跨區域負載平衡器每隔 5 秒便會執行健康情況檢查。

在現有 Azure Load Balancer 上建立跨區域解決方案

跨區域負載平衡器的後端集區包含一或多個區域負載平衡器。

將現有的負載平衡器部署新增至跨區域負載平衡器，以實現高可用性的跨區域部署。

主要區域是全域層跨區域負載平衡器或公用 IP 位址的部署位置。 此區域不影響流量的路由方式。 如果主要區域停止運作，流量不受影響。

主要區域

• 美國中部
• 東亞
• 美國東部 2
• 北歐
• 東南亞
• 英國南部
• US Gov 維吉尼亞州
• 西歐
• 美國西部

參與區域是公告負載平衡器全域公用 IP 的地方。

始於使用者的流量會經過 Microsoft 核心網路，到達最接近的參與區域。

跨區域負載平衡器將流量路由傳送至適當的區域負載平衡器。

參與區域

• 澳大利亞東部
• 澳大利亞東南部
• 印度中部
• 美國中部
• 東亞
• 美國東部
• 美國東部 2
• 日本東部
• 美國中北部
• 北歐
• 美國中南部
• 東南亞
• 英國南部
• US DoD 中部
• US DoD 東部
• US Gov 亞利桑那州
• US Gov 德克薩斯州
• US Gov 維吉尼亞州
• 美國中西部
• 西歐
• 美國西部
• 美國西部 2

限制

• 跨區域前端 IP 設定僅限公用。 目前不支援內部前端。

• 私人或內部負載平衡器無法新增至跨區域負載平衡器的後端集區

• 目前不支援 NAT64 轉譯。 前端和後端 IP 的類型必須相同 (v4 或 v6)。

• IPv6 的跨區域負載平衡器不支援 UDP 流量。

• 跨區域負載平衡器不支援連接埠 3 上的 UDP 流量

• 跨區域負載平衡器不支援輸出規則。 如需輸出連線，請利用區域負載平衡器或 NAT 閘道上的輸出規則。

定價和 SLA

跨區域負載平衡器共用標準負載平衡器的 SLA。

下一步

• Azure 中的可靠性
• 請參閱教學課程：使用 Azure 入口網站建立跨區域負載平衡器，以建立跨區域負載平衡器。
• 深入了解跨區域負載平衡器。
• 深入了解 Azure Load Balancer。