Share via

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

  • 發行項

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

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

重要

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

全域流量路由

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

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識別碼，這幾乎是所有 Azure 服務的全域平臺相依性。 如果套用備援 Azure 技術，則次要服務可能也會發生無法使用或已降級的服務。
      • 全域路由服務失敗案例很可能大幅影響透過服務間相依性用於重要應用程式元件的其他許多服務。 即使使用協力廠商技術，應用程式可能處於狀況不良的狀態，因為基礎問題的影響較廣，這表示仍會提供很少價值路由至 Azure 上的應用程式端點。

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

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

  • 對於無法進行用戶端控制的情況，必須針對單一全域路由服務採取相依性，為所有作用中的部署區域提供統一的進入點。

    • 隔離時，它們代表服務層級因為全域相依性而造成單一失敗點，即使提供內建的多區域備援和可用性也一樣。
    • 所選全域路由服務所提供的 SLA 代表可取得的最大複合 SLA，不論考慮多少部署區域。

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

  • 某些協力廠商全域路由服務提供 100% SLA。 不過，這些服務提供的歷史和可取得 SLA 通常低於 100%。

    • 雖然這些服務為無法使用提供財務補償，但當無法使用的影響很重要時，就很少重要，例如，在人類生活最終有利害關係的安全關鍵案例中。 因此，即使公告的法律 SLA 為 100%，仍應該考慮技術備援或足夠的作業風險降低措施。

Azure Front Door

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

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

  • 提供內建快取，以從邊緣節點提供靜態內容。 在許多使用案例中，這也不需要專用的內容傳遞網路 (CDN) 。

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

  • Azure Front Door 會使用 Azure DDoS 保護基本來保護應用程式端點免于遭受 DDoS 攻擊。 Azure DDoS 標準提供額外的進階保護和偵測功能，並可新增為 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 位址。

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

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

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

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

Azure 標準負載平衡器

重要

跨區域Standard Load Balancer在預覽版中提供技術限制。 不建議針對任務關鍵性工作負載使用此選項。

設計建議

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

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

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

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

任務關鍵全域Load Balancer設定

重要

為了真正降低 Azure 平臺內全域失敗的風險，應該考慮多雲端主動-主動部署方法，並考慮裝載于兩個或多個雲端提供者的主動式部署戳記，以及用於全域路由的備援協力廠商路由技術。

Azure 可以有效地與其他雲端平臺整合。 不過，強烈建議不要套用多雲端方法，因為它引進了顯著的作業複雜度，而不同部署戳記定義和跨不同雲端平臺的作業健康情況標記法。 此複雜度接著會在應用程式的正常作業中引進許多復原風險，這遠超過全球平臺中斷的假設風險。

  • 雖然不建議使用 Azure 流量管理員對 Azure Front Door 進行全域路由備援的 HTTP) (工作負載，請考慮將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 ALing，以驗證來自 Azure Front Door 後端 IP 位址空間和 Azure 基礎結構服務的流量。 這可確保流量會流經服務層級的 Azure Front Door，但仍然需要標頭型篩選，以確保使用已設定的 Front Door 實例。

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

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

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

    • 若要達成此目的，請將 「延遲敏感度 (其他延遲) 」 參數設定為足以滿足後端不同區域之間延遲差異的值。 請確定應用程式工作負載對於整體用戶端要求延遲可接受的容錯。

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

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 弱點提供現用的保護。

    • 您也可以新增自訂規則來擴充 Managed 規則集。
    • 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 中。 這可提供一律開啟的流量監視、即時防護功能，以及防禦常見的第 7 層 DNS 查詢攻擊或第 3/4 層大量攻擊。

    • 即使面臨 DDoS 攻擊，這些保護也有助於維護 Azure Front Door 可用性。 分散式阻斷服務 (DDoS) 攻擊，可能會讓目標資源變得無法使用，方法是讓資源變得不具惡意流量。

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

    Azure Load Balancer

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

設計建議

  • 盡可能在少數位置執行 TLS 卸載，以維持安全性，同時簡化憑證管理生命週期。

  • 使用加密連線 (例如 HTTPS) ，從 TLS 卸載發生到實際應用程式後端的點。 使用者看不到應用程式端點，因此 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 Virtual WAN中最多 20 Gbps。

注意

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

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

設計建議

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

    • 使用私人端點連線到 Azure 平臺服務。 服務端點可以考慮支援Private Link的服務，前提是資料外泄風險可接受或透過替代控制項降低。

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

  • 連線到其他 Azure 或內部部署網路時，不應將應用程式虛擬網路視為暫時性，因為它會建立虛擬網路對等互連和虛擬網路閘道資源相關的重大複雜性。 虛擬網路內所有相關的應用程式資源都應該是暫時的，使用平行子網來加速更新區域部署戳記的藍綠部署。

  • 在需要公司網路連線才能協助應用程式透過私人網路進行應用程式整合的情況下，請確定用於區域應用程式虛擬網路的 IPv4 位址空間不會與其他連線網路重迭，並且已適當調整大小，以協助必要的調整，而不需要更新虛擬網路資源並產生停機時間。

    • 強烈建議您只針對私人網際網路 (RFC 1918) 使用位址配置中的 IP 位址。
      • 對於私人 IP 位址可用性有限的環境， (RFC 1918) ，請考慮使用 IPv6。
      • 如果需要使用公用 IP 位址，請確定只使用擁有的位址區塊。
    • 配合 Azure 中 IP 定址的組織計畫，以確保應用程式網路 IP 位址空間不會與內部部署位置或 Azure 區域的其他網路重迭。
    • 請勿建立不必要的大型應用程式虛擬網路，以確保不會浪費 IP 位址空間。

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

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

    • 優先使用適用于 AKS 網路整合的 Azure CNI 網路外掛程式，並針對有限可用 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 防火牆資源，以降低與使用集中共用資源相關聯的風險，例如雜訊鄰近案例。

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

區域間和區域間連線能力

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

設計考量

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

  • 可用性區域 (AZ) 是 Azure 區域內的實體個別資料中心位置，可提供實體和邏輯錯誤隔離，最多可達到單一資料中心的層級。

    在區域間通訊中，保證往返延遲少於 2 毫秒。 區域在區域之間會有不同的距離和光纖路徑，會有較小的延遲差異。

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

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

  • 區域內區域之間的通訊會產生每 GB 頻寬的 資料傳輸費用 。

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

  • 不同 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 網路原則

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

任務關鍵性應用程式可以在子網或網路介面層級、服務存取控制列出 (ACL) ，Azure Kubernetes Service (以及使用 AKS) 時，使用網路安全性群組 (NSG) ，強制執行應用層級的網路安全性。

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

設計考量

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

    • Kubenet 網路功能： AKS 節點會整合到現有的虛擬網路內，但 Pod 存在於每個節點上的虛擬重迭網路中。 不同節點上 Pod 之間的流量會透過 kube-proxy 路由傳送。
    • Azure Container Networking Interface (CNI) networking： 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，以提供 IP ACL 來保護輸入路徑，並根據零信任模型隔離應用程式元件。

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

    • 應該在所有適用的 NSG 上停用 RDP 和 SSH 埠上的公用網際網路流量。

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

      • AKS 支援使用 Azure CNI 和 Kubenet。 它會在部署時間選取。
      • Azure CNI 網路外掛程式是更強固且可調整的網路外掛程式，建議用於大部分案例。
      • Kubenet 是較輕量型的網路外掛程式，建議用於有限可用 IP 位址範圍的案例。
      • 如需詳細資訊 ，請參閱 Azure CNI 。

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

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

後續步驟

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

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