私人網路連接器和應用程式的高可用性和負載平衡
本文說明流量分佈如何與應用程式 Proxy 部署搭配運作。 了解如何將流量分佈於使用者和連接器之間，以及將連接器效能最佳化的祕訣。 了解流量如何在連接器和後端應用程式伺服器之間流動，以及在多部後端伺服器之間進行負載平衡的建議。
連接器之間的流量分佈
連接器會根據高可用性的準則來建立連線。 不保證流量會平均分佈到各個連接器，而且沒有工作階段親和性。 不過，使用方式各不相同，而且要求會隨機傳送至應用程式 Proxy 服務執行個體。 因此，流量通常幾乎會平均分佈於連接器之上。 圖表和步驟說明如何在使用者與連接器之間建立連線。
- 用戶端裝置上的使用者會嘗試存取透過應用程式 Proxy 發佈的內部部署應用程式。
- 要求會通過 Azure Load Balancer，來判斷哪一個應用程式 Proxy 服務執行個體應該取得要求。 有數十個執行個體可接受區域中所有流量的要求。 此方法有助於將流量平均分佈於服務執行個體之上。
- 要求會傳送至服務匯流排。
- 服務匯流排會向可用的連接器發出訊號。 然後，連接器會從服務匯流排中挑選該要求。
- 在步驟 2 中，要求會移至不同的應用程式 Proxy 服務執行個體，因此，更可能使用不同的連接器來建立連線。 因此，幾乎會在群組內平均使用連接器。
- 連接器會將要求傳遞至應用程式的後端伺服器。 然後，應用程式會將回應傳回給連接器。
- 連接器會透過開啟提出要求的服務執行個體輸出連線來完成回應。 然後會立即關閉此連線。 根據預設，每個連接器的限制為 200 個並行輸出連線。
- 接著會從服務執行個體中，將回應傳回給用戶端。
- 後續來自相同連線的要求都會重複執行這些步驟。
應用程式通常具有許多資源，而且會在載入時開啟多個連線。 每個連線都會經歷遭配置給服務執行個體的步驟。 如果連線未與連接器配對，請選取新的可用連接器。
針對連接器高可用性的最佳做法
由於基於高可用性在連接器之間發佈流量的方式，一個連接器群組中一律至少必須有兩個連接器。 最好使用三個連接器，在連接器之間提供額外的緩衝區。 若要判斷您所需的正確連接器數目，請遵循容量規劃文件。
將連接器放置於不同的輸出連線上，以避免發生單一失敗點。 如果連接器使用相同的輸出連線，則與該連線相關的網路問題會影響使用其所有連接器。
避免在連線到實際執行的應用程式時強制將連接器重新啟動。 這樣做可能會對連接器之間的流量分佈造成負面影響。 重新啟動連接器會導致更多連接器無法使用，並強制連線到剩餘的可用連接器。 結果就是一開始未平均使用連接器。
避免在連接器與 Azure 之間的輸出傳輸層安全性 (TLS) 通訊上進行所有形式的內嵌檢查。 此類型的內嵌檢查會導致通訊流程降級。
確保會為您的連接器保持執行自動更新。 如果私人網路連接器更新程式服務正在執行，您的連接器便會自動更新並接收最新的升級。 若在伺服器上沒有看到連接器更新程式服務，則需要重新安裝您的連接器以取得任何更新。
在連接器和後端應用程式伺服器之間的流量流動
另一個會將高可用性當成要素的關鍵領域是連接器與後端伺服器之間的連線。 當應用程式透過 Microsoft Entra 應用程式 Proxy 發佈時，從使用者到應用程式的流量會流過三個躍點：
- 使用者會連線至 Azure 上的 Microsoft Entra 應用程式 Proxy 服務公用端點。 此連線建立於用戶端的原始用戶端 IP 位址 (公用) 和應用程式 Proxy 端點的 IP 位址之間。
- 私人網路連接器會從應用程式 Proxy 服務提取用戶端的 HTTP 要求。
- 私人網路連接器會連線到目標應用程式。 連接器會使用自己的 IP 位址來建立連線。
X-Forwarded-For 標頭欄位的考量
在某些情況下 (例如稽核、負載平衡等)，需要與內部部署環境共用外部用戶端的原始 IP 位址。 若要滿足需求，Microsoft Entra 私人網路連接器會將具有原始用戶端 IP 位址 (公用) 的 X-Forwarded-For 標頭欄位新增至 HTTP 要求。 適當的網路裝置 (負載平衡器、防火牆) 或者 Web 伺服器或後端應用程式接著就能讀取及使用資訊。
在多個應用程式伺服器之間進行負載平衡的最佳做法
當指派給應用程式 Proxy 應用程式的連接器群組有兩個以上的連接器時，負載平衡很重要。 在多部伺服器上執行後端 Web 應用程式時，負載平衡也很重要。
案例 1：後端應用程式不需要工作階段持續性
最簡單的情況就是後端 Web 應用程式不需要綁定工作階段 (工作階段持續性)。 後端應用程式執行個體會處理伺服器陣列中的使用者要求。 您可以使用第 4 層負載平衡器，並將它設定為無親和性。 部分選項包括 Microsoft 網路負載平衡和 Azure Load Balancer，或另一家廠商所提供的負載平衡器。 或者，設定循環配置網域名稱系統 (DNS) 策略。
案例 2：後端應用程式要求工作階段持續性
在此案例中，後端 Web 應用程式在經過驗證的工作階段期間要求綁定工作階段 (工作階段持續性)。 後端應用程式執行個體會處理使用者要求。 要求會在伺服器陣列中的相同伺服器上執行。 此案例可能更複雜，因為用戶端通常會建立多個與應用程式 Proxy 服務的連線。 透過不同連線的要求可能會到達伺服器陣列中不同的連接器和伺服器。 由於每個連接器都使用自己的 IP 位址進行此通訊，因此，負載平衡器無法確保會根據連接器的 IP 位址來綁定工作階段。 來源 IP 親和性也不能使用。 以下是一些適用於案例 2 的選項：
選項 1：以負載平衡器所設定的工作階段 Cookie 作為工作階段持續性的基礎。 建議使用此選項，因為它可將負載更平均地分散於後端伺服器之間。 它要求具有此功能的第 7 層負載平衡器，而其可以處理 HTTP 流量並終止 TLS 連線。 您可以使用 Azure 應用程式閘道 (工作階段親和性) 或另一家廠商所提供的負載平衡器。
選項 2：以 X-Forwarded-For 標頭欄位作為工作階段持續性的基礎。 此選項要求具有此功能的第 7 層負載平衡器，而其可以處理 HTTP 流量並終止 TLS 連線。
選項 3：將後端應用程式設定為不需要工作階段持續性。
若要了解後端應用程式的負載平衡需求，請參閱軟體廠商的文件。