共用方式為

Azure 上任務關鍵性工作負載的網路和連線能力

  • 發行項

鑒於建議的全域分散式主動-主動設計方法，網路是任務關鍵性應用程式的基本領域。

此設計區域會探索應用層級的各種網路拓撲主題，並考慮必要的連線能力和備援流量管理。 更具體來說，它會特彆強調重要考慮和建議，以告知設計任務關鍵性應用程式的安全且可調整的全域網路拓撲。

重要

本文是 Azure 架構完善的任務關鍵性工作負載系列的一部分。 如果您不熟悉此系列，建議您從什麼是任務關鍵性工作負載開始 ？

全域流量路由

使用多個作用中的區域部署戳記需要全域路由服務，才能將流量散發至每個作用中的戳記。

Azure Front Door、Azure 流量管理員 和 Azure Standard Load Balancer 提供所需的路由功能，以管理跨多區域應用程式的全域流量。

或者，可以考慮第三方全域路由技術。 這些選項幾乎可以順暢地交換，以取代或使用 Azure 原生全域路由服務。 熱門選擇包括 CDN 提供者的路由技術。

本節會探索 Azure 路由服務的主要差異，以定義每個路由服務如何用來優化不同的案例。

設計考量

  • 系結至單一區域的路由服務代表單一失敗點，以及區域性中斷的重大風險。

  • 如果應用程式工作負載包含用戶端控制，例如行動或桌面用戶端應用程式，則有可能在用戶端路由邏輯內提供服務備援。

    • 多個全域路由技術，例如 Azure Front Door 和 Azure 流量管理員，可平行考慮備援，且用戶端已設定在符合特定失敗條件時故障轉移至替代技術。 引進多個全域路由服務，會針對邊緣快取和 Web 應用程式防火牆 功能，以及 SSL 卸除的憑證管理，以及輸入路徑的應用程式驗證，帶來顯著的複雜性。
    • 您也可以考慮第三方技術，為所有層級的 Azure 平台失敗提供全域路由復原能力。

  • Azure Front Door 與 流量管理員 之間的功能差異表示，如果兩種技術彼此並排進行備援，則需要不同的輸入路徑或設計變更，以確保維護一致且可接受的服務等級。

  • Azure Front Door 和 Azure 流量管理員 是具有內建多區域備援和可用性的全域分散式服務。

    • 規模足以威脅這些復原式路由服務全球可用性的假設性失敗案例，在串聯和相互關聯的失敗方面，對應用程式構成更廣泛的風險。
      • 此規模失敗案例只能由共用基礎服務所造成，例如 Azure DNS 或 Microsoft Entra ID，這幾乎可作為所有 Azure 服務的全域平臺相依性。 如果套用了多餘的 Azure 技術，則次要服務可能也會發生無法使用或降級的服務。
      • 全域路由服務失敗案例極有可能透過服務間相依性大幅影響許多用於主要應用程式元件的其他服務。 即使使用第三方技術，應用程式也可能會處於狀況不良的狀態，因為基礎問題的影響更大，這表示無論如何，路由至 Azure 上的應用程式端點會提供很少的價值。

  • 全域路由服務備援可為極少量的假設性失敗案例提供風險降低，其中全域中斷的影響受限於路由服務本身。

    若要為全域中斷案例提供更廣泛的備援，可以考慮多重雲端主動-主動部署方法。 多雲端主動-主動部署方法引進了顯著的作業複雜度，這會造成重大的復原風險，可能遠遠超過全球中斷的假設風險。

  • 針對無法控制用戶端的案例，必須在單一全域路由服務上取得相依性，才能為所有作用中部署區域提供統一的進入點。

    • 隔離使用時，它們代表因全域相依性而導致服務層級的單一失敗點，即使提供內建的多區域備援和可用性也一樣。
    • 所選全域路由服務所提供的 SLA 代表可達到的複合 SLO 上限，不論有多少部署區域都考慮在內。

  • 當用戶端控制無法執行時，如果全域中斷停用主要服務，則可以考慮作業風險降低措施來定義移轉至次要全域路由服務的程式。 從一個全域路由服務移轉至另一個路由服務通常是持續數小時的冗長程式，特別是考慮 DNS 傳播的位置。

  • 某些第三方全域路由服務提供 100% SLA。 不過，這些服務提供的歷史和可達到 SLA 通常低於 100%。

    • 雖然這些服務為無法使用提供財務賠償，但當無法使用的影響很重要時，就沒有什麼意義了，例如，人類生命最終處於危險之中的安全關鍵案例。 因此，即使公告的法律 SLA 為 100%，仍應考慮技術備援或足夠的作業風險降低措施。

Azure Front Door

  • Azure Front Door 使用具有分割 TCP 的 Anycast 通訊協定，提供全域 HTTP/S 負載平衡和優化連線，以利用Microsoft全域骨幹網路。

    • 每個後端端點都會維護一些連線。
    • 傳入用戶端要求會先在最接近原始客戶端的邊緣節點終止。
    • 進行任何必要的流量檢查之後，要求會透過Microsoft骨幹轉送至適當的後端，並使用現有的連線，或從邊緣節點的內部快取提供服務。
    • 這種方法在後端連線上分散大量流量時很有效率。

  • 提供內建快取，提供來自邊緣節點的靜態內容。 在許多使用案例中，這也可以消除專用 內容傳遞網路 （CDN） 的需求。

  • Azure Web 應用程式防火牆 （WAF） 可用於 Azure Front Door，因為它已部署到全球各地的 Azure 網路邊緣位置，因此 Front Door 所傳遞的每個傳入要求都會在網路邊緣檢查。

  • Azure Front Door 會使用 Azure DDoS 保護基本來保護應用程式端點免受 DDoS 攻擊。 Azure DDoS Standard 提供額外的進階保護和偵測功能，並可新增為 Azure Front Door 的額外層。

  • Azure Front Door 提供完全受控的憑證服務。 啟用端點的 TLS 連線安全性，而不需要管理憑證生命週期。

  • Azure Front Door Premium 支援私人端點，讓流量直接從因特網流向 Azure 虛擬網路。 這樣就不需要在 VNet 上使用公用 IP，才能透過 Azure Front Door Premium 存取後端。

  • Azure Front Door 依賴依間隔呼叫的健康情況探查和後端健康情況端點 （URL），以傳回 HTTP 狀態代碼，反映後端是否正常運作，且 HTTP 200 （OK） 回應會反映狀況良好狀態。 一旦後端反映狀況不良的狀態，從特定邊緣節點的觀點來看，該邊緣節點就會停止在該處傳送要求。 因此，狀況不良的後端會以透明的方式從流量流通中移除，而不會有任何延遲。

  • 僅支援 HTTP/S 通訊協定。

  • Azure Front Door WAF 和 應用程式閘道 WAF 提供稍微不同的功能集，不過同時支援內建和自定義規則，而且可以設定為在偵測模式或預防模式中運作。

  • Front Door 後端 IP 空間可能會變更，但Microsoft可確保與 Azure IP 範圍和服務卷標整合。 您可以訂閱 Azure IP 範圍和服務標籤，以接收任何變更或更新的相關通知。

  • Azure Front Door 支持各種 負載散發組態：

    • 以延遲為基礎：將流量從用戶端路由傳送至「最接近」後端的預設設定;根據要求延遲。
    • 優先順序型：適用於主動-被動設定，除非流量無法使用，否則流量必須一律傳送至主要後端。
    • 加權：適用於將特定百分比流量傳送至特定後端的 Canary 部署。 如果多個後端指派了相同的權數，則會使用以延遲為基礎的路由。

  • 根據預設，Azure Front Door 會使用以延遲為基礎的路由，根據用戶端的來源而定，某些後端會取得比其他後端更多的連入流量的情況。

  • 如果一系列用戶端要求必須由相同的後端處理， 則可以在前端上設定會話親和性 。 它會使用用戶端 Cookie 將後續要求傳送至與第一個要求相同的後端，前提是後端仍可使用。

Azure 流量管理員

  • Azure 流量管理員 是 DNS 重新導向服務。

    • 不會處理實際的要求承載，但 流量管理員 會根據所選流量路由方法的已設定規則，傳回集區中其中一個後端的 DNS 名稱。
    • 然後，後端 DNS 名稱會解析為客戶端後續直接呼叫的最終 IP 位址。

  • 用戶端會快取 DNS 回應，並在指定的存留時間 （TTL） 期間重複使用，而在此期間提出的要求會直接移至後端端點，而不需要 流量管理員 互動。 消除與 Front Door 相較之下提供成本效益的額外連線步驟。

  • 由於要求會直接從用戶端對後端服務提出，因此可以運用後端所支援的任何通訊協定。

  • 與 Azure Front Door 類似，Azure 流量管理員 也依賴健康情況探查來瞭解後端是否狀況良好且正常運作。 如果傳回另一個值或未傳回任何值，則路由服務會辨識進行中的問題，並會停止將要求路由傳送至該特定後端。

    • 不過，與 Azure Front Door 不同的是，移除狀況不良的後端並不立即，因為客戶端會繼續建立與狀況不良後端的連線，直到 DNS TTL 到期，並從 流量管理員 服務要求新的後端端點。
    • 此外，即使 TTL 到期，也不能保證公用 DNS 伺服器會接受此值，因此 DNS 傳播實際上可能需要更長的時間才會發生。 這表示流量可能會持續一段時間繼續傳送至狀況不良的端點。

Azure Standard Load Balancer

重要

跨區域標準 Load Balancer 可在預覽版中取得，但有 技術限制。 不建議針對任務關鍵性工作負載使用此選項。

設計建議

  • 使用 Azure Front Door 作為 HTTP/S 案例的主要全域流量路由服務。 Azure Front Door 強烈建議用於 HTTP/S 工作負載，因為它提供優化的流量路由、透明故障轉移、私人後端端點（搭配進階 SKU）、邊緣快取和與 Web 應用程式防火牆 整合（WAF）。

  • 針對可能進行用戶端控制的應用程式案例，請套用用戶端路由邏輯，以考慮主要全域路由技術失敗的故障轉移案例。 如果單一服務 SLA 不夠，則應該平行放置兩或多個全域路由技術，以備援新增。 需要客戶端邏輯，才能在發生全域服務失敗時路由傳送至備援技術。

    • 應該使用兩個不同的 URL，其中一個套用至每個不同的全域路由服務，以簡化故障轉移的整體憑證管理體驗和路由邏輯。
    • 優先使用第三方路由技術作為次要故障轉移服務，因為這可降低全球失敗案例的最大數目，而領先業界的 CDN 提供者所提供的功能將允許一致的設計方法。
    • 也應該考慮直接路由至單一區域戳記，而不是個別的路由服務。 雖然這會導致服務等級降低，但它代表更簡單的設計方法。

此影像顯示使用 Azure Front Door 作為主要全域負載平衡器的用戶端故障轉移備援全域負載平衡器組態。

任務關鍵全域負載平衡器組態

重要

若要真正降低 Azure 平臺內全域失敗的風險，應考慮多雲端主動-主動部署方法，並採用裝載於兩個或多個雲端提供者的作用中部署戳記，以及用於全域路由的備援第三方路由技術。

Azure 可以有效地與其他雲端平臺整合。 不過，強烈建議不要套用多重雲端方法，因為它引進了顯著的作業複雜度，且在不同雲端平臺上有不同的部署戳記定義和作業健康情況表示法。 這種複雜性反過來又在應用程式的正常作業中引進了許多復原風險，遠遠大於全球平臺中斷的假設風險。

  • 雖然不建議使用 HTTP（s） 工作負載使用 Azure 流量管理員 將全域路由備援卸除至 Azure Front Door，請考慮將 Web 應用程式防火牆 （WAF） 卸除至 應用程式閘道，以取得可接受的流量流經 Azure Front Door。
    • 這會將額外的失敗點引入標準輸入路徑、管理及調整的額外關鍵路徑元件，也會產生額外的成本，以確保全球高可用性。 不過，它會藉由透過 Azure Front Door 和 Azure 流量管理員 提供可接受的和無法接受輸入路徑之間的一致性，大幅簡化失敗案例，無論是 WAF 執行還是私人應用程式端點。
    • 失敗案例中的邊緣快取遺失會影響整體效能，這必須與可接受的服務層級或降低設計方法一致。 若要確保服務層級一致，請考慮將邊緣快取卸載至這兩個路徑的第三方 CDN 提供者。

建議您考慮第三方全域路由服務，以取代兩個 Azure 全域路由服務。 這可提供最大層級的錯誤風險降低和更簡單的設計方法，因為大多數業界領先的CDN提供者都提供與 Azure Front Door 所提供的邊緣功能大致一致。

Azure Front Door

  • 使用 Azure Front Door 受控憑證服務來啟用 TLS 連線，並移除管理憑證生命週期的需求。

  • 使用 Azure Front Door Web 應用程式防火牆 （WAF） 在邊緣提供保護，避免常見的 Web 惡意探索和弱點，例如 SQL 插入。

  • 使用 Azure Front Door 內建快取，從邊緣節點提供靜態內容。

    • 在大部分情況下，這也會消除專用 內容傳遞網路 （CDN） 的需求。

  • 使用 X-Azure-FDID 設定應用程式平臺輸入點，透過標頭型篩選來驗證傳入要求，以確保所有流量都流經已設定的 Front Door 實例。 也請考慮使用 Front Door 服務標籤來設定 IP ACLing，以驗證來自 Azure Front Door 後端 IP 位址空間和 Azure 基礎結構服務的流量。 這可確保流量會流經服務層級的 Azure Front Door，但仍然需要標頭型篩選，以確保使用已設定的 Front Door 實例。

  • 定義自定義 TCP 健康情況端點，以驗證區域部署戳記內的重要下游相依性，包括數據平台複本，例如基礎參考實作所提供的範例中的 Azure Cosmos DB。 如果一或多個相依性變成狀況不良，健康情況探查應該會在傳回的回應中反映此情況，以便將整個區域戳記從流通中取出。

  • 確定已記錄健康情況探查回應，並將 Azure Front Door 公開的所有作業數據擷取到全域 Log Analytics 工作區，以利整個應用程式統一的數據接收和單一作業檢視。

  • 除非工作負載非常延遲敏感，否則會將流量平均分散到所有已考慮的區域戳記，以最有效地使用已部署的資源。

    • 若要達成此目的，請將 「Latency Sensitivity （Additional Latency）」 參數設定為足夠高的值，以滿足後端不同區域之間的延遲差異。 請確定應用程式工作負載對於整體用戶端要求延遲可接受的容錯。

  • 除非應用程式需要會話親和性，否則請勿啟用會話親和性，因為它可能會對流量分配的平衡產生負面影響。 使用完全無狀態的應用程式，如果遵循建議的任務關鍵性應用程式設計方法，任何要求都可以由任何區域部署處理。

Azure 流量管理員

  • 將 流量管理員 用於非 HTTP/S 案例，以取代 Azure Front Door。 功能差異將推動快取和 WAF 功能的不同設計決策，以及 TLS 憑證管理。

  • 使用 Azure 應用程式閘道，應該在每個區域中考慮 WAF 功能，以使用 流量管理員 輸入路徑。

  • 設定適當較低的 TTL 值，以優化在後端變成狀況不良時，從迴圈中移除狀況不良後端端點所需的時間。

  • 與 Azure Front Door 類似，應該定義自定義 TCP 健康情況端點，以驗證區域部署戳記內的重要下游相依性，這應該反映在健康情況端點所提供的回應中。

    不過，針對 流量管理員 應將額外的考慮提供給服務等級區域故障轉移。 例如「狗腿腿」，以減輕因相依性失敗而移除狀況不良後端的潛在延遲，特別是無法為 DNS 記錄設定低 TTL 時。

  • 您應該考慮第三方 CDN 提供者，以便在使用 Azure 流量管理員 做為主要全域路由服務時實現邊緣快取。 第三方服務也會提供邊緣 WAF 功能時，應考慮簡化輸入路徑，並可能移除 應用程式閘道 的需求。

應用程式傳遞服務

任務關鍵性應用程式的網路輸入路徑也必須考慮應用程式傳遞服務，以確保安全、可靠且可調整的輸入流量。

本節會藉由探索重要的應用程式傳遞功能，考慮 Azure Standard Load Balancer、Azure 應用程式閘道 和 Azure API 管理 等相關服務，以全域路由建議為基礎。

設計考量

  • TLS 加密對於確保傳入使用者流量到任務關鍵性應用程式的完整性至關重要，且 TLS 卸除 只會套用在戳記輸入點以解密連入流量。 TLS 卸除 需要 TLS 憑證的私鑰才能解密流量。

  • Web 應用程式防火牆 提供保護，以防止常見的Web惡意探索和弱點，例如SQL插入式或跨網站腳本，而且對於達到任務關鍵性應用程式的最大可靠性願望至關重要。

  • Azure WAF 會使用受控規則集，針對前 10 個 OWASP 弱點提供現用的保護。

    • 您也可以新增自定義規則來擴充受控規則集。
    • Azure WAF 可以在 Azure Front Door、Azure 應用程式閘道 或 Azure CDN 內啟用（目前為公開預覽版）。
      • 每個服務上提供的功能稍有不同。 例如，Azure Front Door WAF 提供速率限制、地理篩選和 Bot 保護，這些保護尚未在 應用程式閘道 WAF 內提供。 不過，它們全都支援內建和自定義規則，而且可以設定為以偵測模式或預防模式運作。
      • Azure WAF 的藍圖可確保在所有服務整合中都提供一致的 WAF 功能集。

  • Kubernetes 內的第三方 WAF 技術，例如 NVA 和進階輸入控制器，也可以考慮提供必要的弱點保護。

  • 不論使用的技術為何，最佳 WAF 組態通常需要微調。

    Azure Front Door

  • Azure Front Door 只接受 HTTP 和 HTTPS 流量，而且只會處理具有已知 Host 標頭的要求。 此通訊協定封鎖有助於減輕通訊協定和埠之間分散的大量攻擊，以及 DNS 放大和 TCP 有害攻擊。

  • Azure Front Door 是全域 Azure 資源，因此設定會全域部署至所有 邊緣位置。

    • 資源設定可以大規模散發，以每秒處理數十萬個要求。
    • 設定的更新，包括路由和後端集區，是順暢的，而且不會在部署期間造成任何停機時間。

  • Azure Front Door 提供完全受控的憑證服務和用戶端面向 SSL 憑證的自備憑證方法。 完全受控的憑證服務提供簡化的操作方法，並藉由在解決方案的單一區域內執行憑證管理，協助降低整體設計的複雜性。

  • Azure Front Door 會在憑證到期前至少 60 天自動輪替「受控」憑證，以防止過期的憑證風險。 如果使用自我管理憑證，更新的憑證應該不會晚於現有憑證到期前 24 小時部署，否則用戶端可能會收到過期的憑證錯誤。

  • 只有在 Azure Front Door 切換為「受控」和「使用您自己的憑證」時，憑證更新才會造成停機時間。

  • Azure Front Door 受到 Azure DDoS 保護基本保護，預設會整合到 Front Door 中。 這可提供 Always-On 流量監視、實時風險降低，以及防禦常見的第 7 層 DNS 查詢洪水或第 3/4 層大量攻擊。

    • 即使遇到 DDoS 攻擊，這些保護仍有助於維護 Azure Front Door 可用性。 分散式阻斷服務 （DDoS） 攻擊可能會讓目標資源無法使用，因為會讓目標資源遭到非法流量的壓倒。

  • Azure Front Door 也會在全域流量層級提供 WAF 功能，而 應用程式閘道 WAF 必須在每個區域部署戳記內提供。 功能包括防火牆規則集，以防止常見的攻擊、地理篩選、位址封鎖、速率限制和簽章比對。

    Azure Load Balancer

  • Azure Basic Load Balancer SKU 不受 SLA 支援，而且相較於標準 SKU，有數個功能限制。

設計建議

  • 盡可能少地執行 TLS 卸除，以維護安全性，同時簡化憑證管理生命週期。

  • 從 TLS 卸除發生到實際應用程式後端的點使用加密連線（例如 HTTPS）。 使用者看不到應用程式端點，因此 Azure 受控網域，例如 azurewebsites.net 或 cloudapp.net，可以搭配受控憑證使用。

  • 針對 HTTP（S） 流量，請確定 WAF 功能會在所有公開的端點的輸入路徑內套用。

  • 在單一服務位置啟用 WAF 功能，無論是全域搭配 Azure Front Door，還是透過 Azure 應用程式閘道 進行區域性功能，因為這可簡化設定微調，並優化效能和成本。

    在預防模式中設定WAF以直接封鎖攻擊。 只有在偵測模式的效能降低太高時，才在偵測模式中使用WAF（亦即記錄但不封鎖可疑要求）。 必須完全瞭解隱含的額外風險，並符合工作負載案例的特定需求。

  • 優先使用 Azure Front Door WAF，因為它提供最豐富的 Azure 原生功能集，並在全域邊緣套用保護，以簡化整體設計並進一步提高效率。

  • 只有在向外部用戶端或不同的應用程式小組公開大量 API 時，才使用 Azure API 管理。

  • 針對微服務工作負載內的任何內部流量散發案例，使用 Azure Standard Load Balancer SKU。

    • 在跨 可用性區域 部署時，提供 99.99% 的 SLA。
    • 提供診斷或輸出規則等重要功能。

  • 使用 Azure DDoS 網路保護來協助保護裝載於每個應用程式虛擬網路內的公用端點。

快取和靜態內容傳遞

特殊處理靜態內容，例如影像、JavaScript、CSS 和其他檔案，可能會對整體用戶體驗以及解決方案的整體成本產生重大影響。 在邊緣快取靜態內容可以加速用戶端載入時間，這會導致更好的用戶體驗，也可以降低涉及後端服務之流量、讀取作業和運算能力的成本。

設計考量

  • 並非解決方案透過因特網提供的所有內容都會動態產生。 應用程式同時提供靜態資產（影像、JavaScript、CSS、當地語系化檔案等）和動態內容。
  • 經常存取靜態內容的工作負載可大幅受益於快取，因為它可減少後端服務上的負載，並減少使用者的內容存取延遲。
  • 快取可以使用 Azure Front Door 或 Azure 內容傳遞網路 （CDN） 在 Azure 內原生實作。
    • Azure Front Door 提供 Azure 原生邊緣快取功能和路由功能，以分割靜態和動態內容。
      • 藉由在 Azure Front Door 中建立適當的路由規則， /static/* 流量可以透明地重新導向至靜態內容。
    • 您可以使用 Azure CDN 服務來實作更複雜的快取案例，為重要的靜態內容磁碟區建立完整的內容傳遞網路。
      • Azure CDN 服務可能會更具成本效益，但不會提供相同的進階路由和 Web 應用程式防火牆 （WAF） 功能，這些功能建議用於應用程式設計的其他領域。 不過，它確實提供進一步的彈性，以整合來自第三方解決方案的類似服務，例如 Akamai 和 Verizon。
    • 比較 Azure Front Door 和 Azure CDN 服務時，應該探索下列決策因素：
      • 可以使用規則引擎來完成必要的快取規則。
      • 預存內容和相關聯的成本大小。
      • 執行規則引擎的每月價格（針對 Azure Front Door 的每個要求收費）。
      • 輸出流量需求（價格因目的地而異）。

設計建議

  • 產生的靜態內容，例如從未或只很少變更的映像檔大小複本，也可以受益於快取。 快取可以根據 URL 參數和具有不同快取持續時間來設定。
  • 將靜態和動態內容傳遞至使用者，並從快取傳遞相關內容，以降低後端服務對終端使用者的效能優化。
  • 鑒於強式建議（網路和連線設計區域）使用 Azure Front Door 進行全域路由和 Web 應用程式防火牆 （WAF） 用途，建議除非存在差距，否則建議優先使用 Azure Front Door 快取功能。

虛擬網路整合

任務關鍵性應用程式通常會包含與其他應用程式或相依系統整合的需求，這些系統可以裝載於 Azure、另一個公用雲端或內部部署數據中心。 此應用程式整合可透過網路層級整合，使用面向公用的端點和因特網，或專用網來完成。 最後，達成應用程式整合的方法會對解決方案的安全性、效能和可靠性產生重大影響，並嚴重影響其他設計領域的設計決策。

任務關鍵性應用程式可以在三個整體網路組態的其中一個內部署，以決定應用程式整合在網路層級的方式。

  1. 沒有公司網路連線的公用應用程式。
  2. 具有公司網路連線功能的公用應用程式。
  3. 具有公司網路連線的私人應用程式。

警告

在 Azure 登陸區域內部署時，設定 1。 應該部署在在線登陸區域內，而 2） 和 3） 都應該部署在公司連線登陸區域內，以利網路層級整合。

本節將探討這些網路整合案例、適當地使用 Azure 虛擬網絡 和周圍的 Azure 網路服務，以確保最符合整合需求。

設計考量

沒有虛擬網路

  • 最簡單的設計方法是不要在虛擬網路內部署應用程式。

    • 所有已考慮的 Azure 服務之間的連線將完全透過公用端點和Microsoft Azure 骨幹來提供。 在 Azure 上裝載的公用端點之間的連線只會周遊Microsoft骨幹，而且不會經過公用因特網。
    • 公用因特網會提供與 Azure 外部任何外部系統的連線。

  • 此設計方法採用「身分識別為安全性周邊」，以提供各種服務元件與相依解決方案之間的訪問控制。 對於對安全性較不敏感的案例，這可能是可接受的解決方案。 所有應用程式服務和相依性都可透過公用端點存取，使其容易受到以取得未經授權存取為導向的其他攻擊向量。

  • 此設計方法也適用於所有 Azure 服務，因為許多服務，例如 AKS，對於基礎虛擬網路有硬性需求。

隔離的虛擬網路

  • 若要降低與不必要的公用端點相關聯的風險，應用程式可以在未連線到其他網路的獨立網路中部署。

  • 連入用戶端要求仍然需要公用端點公開至因特網，不過，所有後續的通訊都可以使用私人端點在虛擬網路內。 使用 Azure Front Door Premium 時，可以直接從邊緣節點路由至私人應用程式端點。

  • 雖然應用程式元件之間的私人聯機會透過虛擬網路發生，但與外部相依性的所有連線仍會依賴公用端點。

    • 如果支援，可以使用私人端點來建立與 Azure 平臺服務的連線。 如果 Azure 上有其他外部相依性，例如另一個下游應用程式，則會透過公用端點和Microsoft Azure 骨幹來提供連線能力。
    • 公用因特網會提供與 Azure 外部任何外部系統的連線。

  • 針對沒有外部相依性網路整合需求的案例，在隔離的網路環境中部署解決方案可提供最大的設計彈性。 沒有與更廣泛的網路整合相關聯的尋址和路由條件約束。

  • Azure Bastion 是完全平臺管理的 PaaS 服務，可部署在虛擬網路上，並提供 Azure VM 的安全 RDP/SSH 連線。 當您透過 Azure Bastion 連線時，虛擬機不需要公用 IP 位址。

  • 使用應用程式虛擬網路會在 CI/CD 管線中引進大量部署複雜度，因為需要數據平面和控制平面存取專用網上裝載的資源，才能協助應用程式部署。

    • 必須建立安全專用網路徑，以允許 CI/CD 工具執行必要的動作。
    • 私人組建代理程式可以在應用程式虛擬網路內部署，以 Proxy 存取虛擬網路所保護的資源。

線上虛擬網路

  • 針對外部網路整合需求的案例，應用程式虛擬網路可以使用各種連線選項，連線到 Azure 內的其他虛擬網路、另一個雲端提供者或內部部署網路。 例如，某些應用程式案例可能會考慮應用層級與內部部署公司網路內私下裝載的其他企業營運應用程式整合。

  • 應用程式網路設計必須與更廣泛的網路架構一致，特別是關於尋址和路由等主題。

  • 在考慮網路整合時，跨 Azure 區域或內部部署網路的重疊 IP 位址空間將會建立主要爭用。

    • 虛擬網路資源可以更新以考慮其他位址空間，不過，當對等互連網路的虛擬網路位址空間變更 對等互連連結上的同步處理時，這會暫時停用對等互連。
    • Azure 會在每個子網內保留五個IP位址，這在判斷應用程式虛擬網路和包含的子網的適當大小時，應考慮此位址。
    • 某些 Azure 服務需要專用子網，例如 Azure Bastion、Azure 防火牆 或 Azure 虛擬網絡 閘道。 這些服務子網的大小非常重要，因為它們應該夠大，足以支援所有目前服務實例，考慮未來的規模需求，但不會像不必要的浪費位址一樣大。

  • 需要內部部署或跨雲端網路整合時，Azure 會提供兩種不同的解決方案來建立安全的連線。

    • ExpressRoute 線路可重設大小，以提供高達 100 Gbps 的頻寬。
    • 虛擬專用網 （VPN） 可調整大小，在中樞和輪輻網路中提供高達 10 Gbps 的匯總頻寬，以及 Azure 虛擬 WAN 中最多 20 Gbps。

注意

在 Azure 登陸區域內部署時，請注意登陸區域實作應該提供與內部部署網路的任何必要連線。 此設計可以使用虛擬 WAN 或中樞輪輻網路設計，在 Azure 中使用 ExpressRoute 和其他虛擬網路。

  • 包含其他網路路徑和資源會為應用程式帶來額外的可靠性和操作考慮，以確保維護健康情況。

設計建議

  • 建議您在 Azure 虛擬網路內部署任務關鍵性解決方案，以盡可能移除不必要的公用端點，限制應用程式受攻擊面，以最大化安全性和可靠性。

    • 使用私人端點連線至 Azure 平台服務。 針對不支援 Private Link 的服務，可以考慮服務端點，前提是數據外泄風險是可接受的，或透過替代控件減輕。

  • 針對不需要公司網路連線的應用程式案例，請將所有虛擬網路視為在進行新的區域部署時所取代的暫時資源。

  • 連線到其他 Azure 或內部部署網路時，應用程式虛擬網路不應該被視為暫時性，因為它會造成虛擬網路對等互連和虛擬網路網關資源所關注的重大複雜問題。 虛擬網路內所有相關的應用程式資源應該會持續暫時，而平行子網則用來協助更新區域部署戳記的藍綠部署。

  • 在需要公司網路連線才能協助透過專用網進行應用程式整合的案例中，請確定用於區域應用程式虛擬網路的 IPv4 位址空間不會與其他連線網路重疊，且大小正確，以方便所需的調整，而不需要更新虛擬網路資源併產生停機時間。

    • 強烈建議只針對私人因特網使用位址配置中的IP位址（RFC 1918）。
      • 針對具有私人IP位址有限可用性的環境（RFC 1918），請考慮使用IPv6。
      • 如果需要使用公用IP位址，請確定只使用擁有的位址區塊。
    • 與 Azure 中 IP 尋址的組織方案一致，以確保應用程式網路 IP 位址空間不會與其他跨內部部署位置或 Azure 區域的網路重疊。
    • 請勿建立不必要的大型應用程式虛擬網路，以確保不會浪費IP位址空間。

  • 優先使用 Azure CNI 進行 AKS 網路整合，因為它 支援更豐富的功能集。

    • 針對具有有限可用IP位址的案例，請考慮 Kubenet，以符合受限地址空間內的應用程式。

    • 優先使用 Azure CNI 網路外掛程式進行 AKS 網路整合，並針對有限可用 IP 位址範圍的案例考慮 Kubenet。 如需詳細資訊，請參閱 微分割和 Kubernetes 網路 原則。

  • 針對需要內部部署網路整合的案例，請優先使用 Express Route 以確保安全且可調整的連線能力。

    • 請確定套用至 Express Route 或 VPN 的可靠性層級完全符合應用程式需求。
    • 應該考慮多個網路路徑，視需要提供額外的備援，例如跨連線的 ExpressRoute 線路或使用 VPN 作為故障轉移連線機制。

  • 請確定重要網路路徑上的所有元件都符合相關聯使用者流程的可靠性與可用性需求，無論中央IT小組的應用程式小組是否要管理這些路徑和相關聯的元件。

    注意

    在 Azure 登陸區域內部署並與更廣泛的組織網路拓撲整合時，請考慮 網路指引 ，以確保基礎網路符合Microsoft最佳做法。

  • 使用 Azure Bastion 或 Proxy 的私人連線來存取 Azure 資源的數據平面，或執行管理作業。

網際網路輸出

因特網輸出是任務關鍵性應用程式的基本網路需求，可協助在下列內容中進行外部通訊：

  1. 直接應用程式用戶互動。
  2. 應用程式與 Azure 外部相依性整合。
  3. 存取應用程式所使用的 Azure 服務所需的外部相依性。

本節探討如何實現因特網輸出，同時確保維護安全性、可靠性和可持續效能，並強調任務關鍵性內容中建議服務的重要輸出需求。

設計考量

  • 許多 Azure 服務都需要存取公用端點，才能依預期運作各種管理和控制平面功能。

  • Azure 針對虛擬網路上的虛擬機或計算實例，提供不同的直接因特網輸出 連線方法，例如 Azure NAT 閘道或 Azure Load Balancer。

  • 當來自虛擬網路內部的流量流向因特網時，必須進行網路位址轉換（NAT）。 這是在網路堆疊內發生的計算作業，因此可能會影響系統效能。

  • 當 NAT 以小規模進行時，效能影響應該微不足道，不過，如果可能會發生大量的輸出要求網路問題。 這些問題通常以「來源 NAT （或 SNAT） 埠耗盡」的形式出現。

  • 在多租用戶環境中，例如 Azure App 服務，每個實例可用的輸出埠數目有限。 如果這些埠用完，則無法起始新的輸出連線。 此問題可藉由減少私人/公用邊緣周游的數目，或使用更可調整的 NAT 解決方案，例如 Azure NAT 閘道來緩和。

  • 除了 NAT 限制之外，輸出流量也可能受限於必要的安全性檢查。

    • Azure 防火牆 提供適當的安全性功能來保護網路輸出。

    • Azure 防火牆（或對等 NVA）可用來保護 Kubernetes 輸出需求，方法是提供對輸出流量的細微控制。

  • 大量的因特網輸出將會產生 數據傳輸費用。

Azure NAT 閘道

  • Azure NAT 閘道針對每個指派的輸出IP位址支援64,000個 TCP 和UDP連線。

    • 最多可以指派 16 個 IP 位址給單一 NAT 閘道。
    • 預設 TCP 閑置逾時為 4 分鐘。 如果閑置逾時變更為較高的值，流量會保留較長的時間，這會增加 SNAT 埠清查的壓力。

  • NAT 閘道無法提供現用的區域性隔離。 若要取得區域性備援，包含區域資源的子網必須與對應的區域 NAT 閘道一致。

設計建議

  • 將連出因特網連線數目降至最低，因為這樣會影響NAT效能。

    • 如果需要大量的因特網系結連線，請考慮使用 Azure NAT 閘道 來抽象輸出流量流程。

  • 使用 Azure 防火牆 控制及檢查輸出因特網流量的需求。

    • 請確定 Azure 防火牆 不會用來檢查 Azure 服務之間的流量。

注意

在 Azure 登陸區域內部署時，請考慮使用基礎平臺 Azure 防火牆 資源（或對等的 NVA）。 如果在因特網輸出的中央平臺資源上採用相依性，則該資源與相關聯網路路徑的可靠性層級應與應用程式需求緊密配合。 資源中的作業數據也應該提供給應用程式，以在失敗案例中通知潛在的作業動作。

如果有與輸出流量相關聯的高延展性需求，則應考慮任務關鍵性應用程式的專用 Azure 防火牆 資源，以降低與使用集中共用資源相關聯的風險，例如嘈雜的鄰近案例。

  • 在虛擬 WAN 環境中部署時，應該考慮防火牆管理員，以集中管理專用應用程式 Azure 防火牆 實例，以確保透過全域防火牆原則觀察到組織安全性狀態。
  • 請確定累加式防火牆原則會透過角色型訪問控制委派給應用程式安全性小組，以允許應用程式原則自主性。

區域間和區域間連線能力

雖然應用程式設計強烈建議獨立區域部署戳記，但許多應用程式案例仍可能需要在不同區域或 Azure 區域內部署的應用程式元件之間進行網路整合，即使只有在服務降級的情況下。 達成區域間和區域間通訊的方法，對整體效能和可靠性具有重大影響，本節將透過考慮和建議進行探索。

設計考量

  • 任務關鍵性應用程式的應用程式設計方法支援使用獨立的區域部署，並在單一區域內的所有元件層級套用區域性備援。

  • 可用性區域 （AZ） 是 Azure 區域內實體個別的數據中心位置，可提供高達單一數據中心層級的實體和邏輯錯誤隔離。

    保證跨區域通訊的來回延遲小於 2 毫秒。 區域在區域之間會有一小段延遲差異，因為區域之間的距離和光纖路徑會有所不同。

  • 可用性區域連線取決於區域特性，因此透過邊緣位置進入區域的流量可能需要在區域之間路由傳送，才能到達目的地。 這會在區域間路由和「光線速度」限制下新增 ~1 毫秒-2 毫秒的延遲，但這應該只有超敏感工作負載的承載。

  • 可用性區域 會視為單一訂用帳戶內容內的邏輯實體，因此不同的訂用帳戶可能會有不同區域對應。 例如，訂用帳戶 A 中的區域 1 可以對應到與訂用帳戶 B 中區域 2 相同的實體數據中心。

  • 在應用程式元件之間非常閒聊的應用程式案例中，跨區域分散應用層可能會帶來顯著的延遲和更高的成本。 藉由將部署戳記限制為單一區域，並跨不同區域部署多個戳記，即可在設計中減輕此問題。

  • 不同 Azure 區域之間的通訊會產生每個 GB 頻寬的較大 數據傳輸費用 。

    • 適用的數據傳輸率取決於已考慮的 Azure 區域大陸。
    • 數據周遊大陸的收費速率要高得多。

  • Express Route 和 VPN 連線方法也可用來針對特定案例或甚至不同的雲端平臺，直接將不同的 Azure 區域連線在一起。

  • 服務對服務通訊 Private Link 的服務，可用於使用私人端點進行直接通訊。

  • 流量可以透過用於內部部署連線的 Express Route 線路進行釘選，以利在 Azure 區域內的虛擬網路與相同地理位置內的不同 Azure 區域之間進行路由。

    • 透過 Express Route 釘選流量會略過與虛擬網路對等互連相關聯的數據傳輸成本，因此可用來將成本優化。
    • 這種方法需要額外的網路躍點，以在 Azure 內進行應用程式整合，進而帶來延遲和可靠性風險。 從 Azure/內部部署擴充 Express Route 和相關聯的閘道元件角色，以包含 Azure/Azure 連線能力。

  • 當服務之間需要子百萬延遲時， 可以使用鄰近放置群組 ，當使用的服務支援時。

設計建議

  • 使用虛擬網路對等互連來連線區域內和跨不同區域的網路。 強烈建議您避免在 Express Route 內釘選毛髮。

  • 使用 Private Link 直接在相同區域或跨區域的服務之間建立通訊（區域 A 中的服務與區域 B 中的服務通訊。

  • 對於元件之間非常閒聊的應用程式工作負載，請考慮將部署戳記限制為單一區域，並跨不同區域部署多個戳記。 這可確保區域性備援維持在封裝的部署戳記層級，而不是單一應用程式元件。

  • 可能的話，請將每個部署戳記視為獨立且與其他戳記中斷連線。

    • 使用數據平台技術跨區域同步處理狀態，而不是使用直接網路路徑在應用層級達到一致性。
    • 除非必要，否則請避免不同區域之間的「狗腿」流量，即使在失敗案例中也是如此。 使用全域路由服務和端對端健康情況探查，在單一關鍵元件層失敗時，將整個流出迴圈，而不是將該錯誤元件層級的流量路由傳送到另一個區域。

  • 針對超延遲敏感性應用程式案例，請優先使用區域與區域網路網關，以優化輸入路徑的網路等待時間。

微分割和 Kubernetes 網路原則

微分割是一種網路安全性設計模式，用來隔離及保護個別應用程式工作負載，並套用原則以根據 零信任 模型限制工作負載之間的網路流量。 它通常適用於減少網路攻擊面、改善入侵內含專案，以及透過原則驅動應用層級網路控制加強安全性。

任務關鍵性應用程式可以在使用 Azure Kubernetes Service （AKS） 時，使用子網或網路介面層級的網路安全組、服務 存取控制 清單（ACL）和網路原則，強制執行應用層級的網路安全性。

本節會探索這些功能的最佳使用方式，並提供達成應用層級微分割的重要考慮和建議。

設計考量

  • AKS 可以部署在兩個不同的 網路模型中：

    • Kubenet 網路： AKS 節點會整合在現有的虛擬網路內，但 Pod 存在於每個節點上的虛擬網路重疊網路中。 不同節點上Pod之間的流量會透過 kube-proxy 路由傳送。
    • Azure 容器網路介面 （CNI） 網路功能： AKS 叢集會整合在現有的虛擬網路內，以及其節點、Pod 和服務從叢集節點所連結的相同虛擬網路接收的 IP 位址。 這與需要從 Pod 直接連線的各種網路案例相關。 不同的節點集區可以部署到 不同的子網。

    注意

    相較於 Kubenet，Azure CNI 需要更多的 IP 位址空間。 需要適當的預先規劃和調整網路大小。 如需詳細資訊，請參閱 Azure CNI 檔。

  • 根據預設，Pod 是非隔離的，並接受來自任何來源的流量，而且可以將流量傳送至任何目的地;Pod 可以與指定 Kubernetes 叢集中的所有其他 Pod 通訊;Kubernetes 不會確保任何網路層級隔離，也不會隔離叢集層級的命名空間。

  • Pod 與命名空間之間的通訊可以使用網路原則來隔離。 網路原則是一種 Kubernetes 規格，其定義 Pod 之間通訊的存取原則。 使用網路原則時，可以定義一組已排序的規則，以控制傳送/接收流量的方式，並套用至符合一或多個標籤選取器之 Pod 集合。

    • AKS 支援兩個實作網路原則、 Azure 和 Calico 的外掛程式。 這兩個外掛程式都會使用 Linux IPTable 來強制執行指定的原則。 如需詳細資訊，請參閱 Azure 和 Calico 原則之間的差異及其功能 。
    • 網路原則不會衝突，因為它們是加總的。
    • 若要允許兩個 Pod 之間的網路流程，來源 Pod 上的輸出原則和目的地 Pod 上的輸入原則都必須允許流量。
    • 網路原則功能只能在叢集具現化時啟用。 您無法在現有的 AKS 叢集上啟用網路原則。
    • 無論使用 Azure 還是 Calico，網路原則的傳遞都是一致的。
    • Calico 提供 更豐富的功能集，包括支援 Windows 節點和支援 Azure CNI 以及 Kubenet。

  • AKS 支援建立不同的節點集區，以使用具有不同硬體和軟體特性的節點來分隔不同的工作負載，例如具有和不含 GPU 功能的節點。

    • 使用節點集區不提供任何網路層級隔離。
    • 節點集區可以在相同的虛擬網路內使用不同的子網。 NSG 可以在子網層級套用，以在節點集區之間實作微分割。

設計建議

  • 在所有考慮的子網上設定NSG，以提供IP ACL來保護輸入路徑，並根據零信任模型隔離應用程式元件。

    • 在包含 Azure Front Door 內定義之應用程式後端的所有子網上使用 Front Door 服務標籤，因為這會驗證來自合法 Azure Front Door 後端 IP 位址空間的流量。 這可確保流量會流經服務層級的 Azure Front Door，但仍然需要標頭型篩選，以確保使用特定的 Front Door 實例，並降低「IP 詐騙」的安全性風險。

    • 在所有適用的 NSG 上，都應該在 RDP 和 SSH 埠上停用公用因特網流量。

    • 優先使用 Azure CNI 網路外掛程式，並針對有限範圍的可用 IP 位址的案例考慮 Kubenet，以符合受限地址空間內的應用程式。

      • AKS 支援同時使用 Azure CNI 和 Kubenet。 此網路選擇是在部署時間選取的。
      • Azure CNI 網路外掛程式是更健全且可調整的網路外掛程式，而且建議在大部分情況下使用。
      • Kubenet 是較輕量型的網路外掛程式，建議在有限範圍的可用IP位址的情況下使用。
      • 如需詳細資訊，請參閱 Azure CNI 。

  • Kubernetes 中的網路原則功能應該用來定義叢集中 Pod 之間的輸入和輸出流量規則。 定義細微的網路原則，以限制和限制跨 Pod 通訊。

    • 在部署時啟用 Azure Kubernetes Service 的網路 原則。
    • 優先使用 Calico ，因為它提供更豐富的功能集，並提供更廣泛的社群採用和支援。

後續步驟

檢閱量化和觀察應用程式健康情況的考慮。

健康情況模型化和可觀察性