規劃 ExpressRoute 部署以用於 Microsoft Power Platform
既然您已決定將 ExpressRoute 用於 Microsoft Power Platform，那麼進行規劃部署以滿足您的需求和環境非常重要。
ExpressRoute 的先決條件
設定 ExpressRoute 需要考慮和設定幾個先決條件。 這可能會造成意外的成本和活動，如果不進行規劃，則可能會影響專案和其他服務的持續運作。
外部先決條件
ExpressRoute 本身不提供實體連線; 它透過已建立的實體連線提供私人連線。 實體連線必須先由連線提供者設定。 有許多方法可讓您與現有的 ExpressRoute 合作夥伴建立這種連線。 ExpressRoute 文件提供選項與目前可用合作夥伴的詳細解釋。
在規劃階段，您必須考慮以下事項：
地理：我們將在稍後詳細討論，瞭解在地理位置上需要建立一或多個連線時，會影響整體規劃。
成本：連線提供者將會在建立私人連線時收取費用。 這可能會是一筆鉅額的成本; 這會根據所需的連線類型和數量而有所不同。
設定時間：在某些案例中，需要設定物理硬體。 這段設定時間將需要納入實作排程。
設定技巧和資源：大部分的設定複雜性在於設定網路中的內部路由。 您必須確保有熟練的人員可以執行此動作。
Microsoft 先決條件
在物理連線就緒後，您可以繼續設定 ExpressRoute 連線本身。 這會需要：
在其中佈建和計費 ExpressRoute 線路的 Azure 訂閱。
ExpressRoute 線路的 Azure 訂閱中的設定，可透過 Azure 工具完成。
為 ExpressRoute 間 Microsoft Power Platform 的流量規劃路由設定
規劃路由 Microsoft Power Platform 流量時，您必須考慮各種類型的流量，這要視您的設定和使用 Microsoft Power Platform 的方式而定。
若要瞭解如何為 Microsoft Power Platform 設定 ExpressRoute，您必須考慮 Microsoft Power Platform 的不同使用方式和連線，這要視您使用的服務和功能而定。
路由設定
路由設定是根據提供的連線類型，由連線提供者或客戶來完成。
雖然 ExpressRoute 連線本身位於資料中心之間，但是實際的網路連線大多是來自使用者的用戶端裝置 (通常是分佈在更廣泛的 WAN 上，例如分散的銀行分支)。 這表示連線是從用戶端裝置的位置經由 WAN 路由至資料中心，然後通過 ExpressRoute 線路。 這需要仔細的設定。 WAN 的設定方式如下：
透過子網路進行的路由是針對 ExpressRoute 設定的。
or
優先選擇容錯移轉線路，而不是公用網際網路來連線到 Microsoft Power Platform。
因此，必須確定網路中的哪些子網路應成為主要和遞補邊界閘道協定 (BGP) 工作階段連線的目標，以確定 Microsoft Power Platform 首碼傾向該路由。 因為透過此連線公佈 IP 子網路/首碼，所以並不需要專門設定每一端的服務。 發出要求時，路由演算法會將直接 BGP 連線視為連線至 ExpressRoute 線路之子網路流量的首選路由，並以此方式引導流量。
為分散的使用者設定 ExpressRoute
ExpressRoute 旨在提供從您的環境到 Microsoft 網路的私人、專用且可預測的連線。 當您使用連線提供者到 Microsoft 的專用和直接連線時，您就可以減少在連線提供者網路的共用連線上與其他流量爭用的可能性。 不必使用 ExpressRoute 來透過連線提供者實現這種連接品質，但是這是一種協助確保連線的方式。
在以下範例中，分支中的使用者連線可透過 WAN 路由至 ExpressRoute 的客戶資料中心連線。
若客戶具有高度分散的使用者網路 (例如分佈於國家/地區的辦事處分支網路)，則需要從多個高度分散的地理位置有效地連線網路流量。 典型的方式是透過 WAN 將裝置路由至連線到 ExpressRoute 的區域網路，如下圖所示。
如果用戶端與 ExpressRoute 之間的連線較差，或者在某種程度上達到飽和或效率不佳，則 ExpressRoute 將無法解決此問題，因為進入 ExpressRoute 進入點的連線問題仍然會影響使用者體驗。 在這種情況下，您應該考慮使用 ExpressRoute Direct，這樣就能直接連線到 Microsoft 的全域網路。
當連線至雲端服務，並受到具挑戰性的 WAN 連線限制時，從本機分支建立區域網路節點可能是有益的。 這可避免較慢的 WAN 連線，並利用連線提供者的覆蓋範圍來實現更直接的雲端服務連線。
您可以透過區域網路節點，從多個位置設定 ExpressRoute 線路，甚至可以到各個分支位置，如下圖所示。
透過 WAN 將分支位置連線至中央資料中心，並在客戶與 Microsoft 資料中心之間建立 ExpressRoute 線路的方法，通常比嘗試從每個分支位置建立 ExpressRoute 連線更好，更實用。 如果需要在許多地方都這樣做，那麼安裝和維護的成本會叫昂貴且複雜。
另一種方法是在相同的 IP VPN 上連接所有的分支辦公室和客戶資料中心，並讓 IP VPN 服務提供者在 ExpressRoute 位置連線至 Microsoft。
如果本機 WAN 連線有困難，通常可透過取得額外頻寬或最佳化路由等方式來進行最佳化，而不是嘗試從每個位置建立 ExpressRoute 連線。
對於分散在廣泛地理區域中的網路，最好將多個中樞連接至 ExpressRoute 以盡量減少所需的 ExpressRoute 連線數量，同時仍為每位使用者提供更多本機連線點。 在這種情況下，務必確保透過每個 ExpressRoute 線路發佈唯一公用 IP; 這些子網路中的每一個都必須是不同的，這要求您擁有與 ExpressRoute 連線一樣多的公用子網路。
若不同的操作區域位於很多不同的地理區域中，或區域之間的網路連線受到限制，可以為每個區域建立更直接的連線這一點就顯得特別有幫助。
不同地區也可能有不同的隱私權要求，不需要因為一個地區使用 ExpressRoute，就所有地區就都跟著使用。 部分連線可能會透過網際網路直接進行路由，而其他連線則可以透過 ExpressRoute 路由，如下圖所示。
ExpressRoute (standard) 只能在特定的地理區域中提供連線; 必須使用 ExpressRoute Premium 才能從單一 ExpressRoute 連線點提供多個地理位置存取。 例如，如果客戶擁有美國辦事處和歐洲辦事處，那麼所有辦事處都使用單一 Microsoft Power Platform 環境。 如果客戶的 Microsoft Power Platform 租用戶部署在美國，則他們在歐洲的 ExpressRoute 線路必須是 Premium SKU。 如果他們的 Microsoft Power Platform 租用戶在歐洲，則他們的美國線路必須是 Premium。
避免非對稱路由
需要注意的一項挑戰是非對稱路由，客戶網路中的路由設定會直接透過網際網路將流量路由到 Microsoft 資料中心，但隨後傳回的流量會決定回覆應該透過 ExpressRoute 線路來路由。 這通常會觸發防火牆拒絕接收流量，因為其在沒有傳送要求套件的情況下接收回覆套件。
如果用戶端的區域網路判斷到 Microsoft 雲端服務的最有效路由是透過公用網際網路，而不是透過 WAN 到私人 ExpressRoute 線路，就可能會發生此問題。 但是如果用戶端 IP 位址是公用 IP 位址，或是透過 NAT 對應至透過 ExpressRoute 宣告的公用 IP 位址，則透過 ExpressRoute 上的 BGP 工作階段可能是返回該 IP 的最有效路由。 您可以在網際網路邊緣和 ExpressRoute 邊緣使用不同的 NAT IP。 使用不同的來源位址，傳回流量將明確地返回到同一邊緣。
如果同一客戶設定多個透過單一線路進行輸出流量路由的 ExpressRoute 線路，但返回路由通過另一條線路，其中防火牆檢查可以封鎖返回路徑的流量時，也可能發生這種情況。 若要避免輸出路徑和輸入路徑跨越不同的 ExpressRoute 連路的非對稱路由，請務必確保每個線路都發佈唯一的公用 IP。
如您所見，判斷如何在 WAN 中管理路由，並仔細考慮進出 Microsoft 雲端服務的路徑非常重要。
Microsoft Power Platform 的外部連線
從客戶位置連線到 Microsoft Power Platform 時，需要考慮多種流量類型。 這可能會造成兩種對等互連類型 (Microsoft 對等互連和私人對等互連)，且相同的 ExpressRoute 線路可用於這些對等互連類型，如下圖所示。
Microsoft Power Platform 服務與外部網路之間存在不同的連線類型。 例如，使用伺服器端同步處理的 Exchange Web 服務連線時，會使用 ExpressRoute 將網路流量從 Microsoft 網路傳遞至客戶網路。 Web 服務連線將 ExpressRoute 用於 Microsoft 網路的輸入和輸出流量。 對於 HTTPS 用戶端，ExpressRoute 連線用於從客戶網路存取 Microsoft 網路。 下圖說明這些範例。
輸出流量 (來自 Microsoft Power Platform 服務的流量)
從 Microsoft Power Platform 服務直接到客戶服務可能發生多種類型的輸出流量。 請務必要注意，客戶服務必須可透過 Microsoft Power Platform 服務用公共 DNS 解析公用 IP，才能公開定址。
此 IP 位址也需要透過 ExpressRoute 宣告給 Microsoft，才能讓 Microsoft Power Platform 服務中的內部網路路由透過該 ExpressRoute 連線來路由。
Microsoft Power Platform 服務無法指定哪個服務執行個體或客戶組織可以向哪個 IP 位址發出要求。 因此，將輸入到公司網路的要求視為來自網際網路並加以保護是非常重要的。
下表描述來自 Microsoft Power Platform 服務的輸出流量。
| 描述 | 流量類型和方向 | 對等互連類型 | 用途 |
|---|---|---|---|
| Web 服務 | 來自 Microsoft Power Platform 服務的 HTTPS 輸出 | Microsoft 對等互連 在 ExpressRoute 設定的子網路中發佈公用 IP 位址上的 Web 服務 |
自訂外掛程式和工作流程活動可將向外部服務發出 Web 服務要求 |
| Exchange 整合：混合模式 | 來自 Microsoft Power Platform 服務的 HTTPS 輸出 | Microsoft 對等互連 需在 ExpressRoute 設定的子網路中發佈公用 IP 位址上的 Web 服務 |
來自伺服器端同步處理混合部署的 Exchange Web 服務要求 (Microsoft Power Platform 服務、Exchange 內部部署) |
| 連接器 | 來自 Microsoft Power Platform 服務的 HTTPS 輸入 | Microsoft 對等互連 | 使用內部部署的資料閘道透過連接器的 Azure API 管理服務從 Microsoft Power Platform 服務發出要求 |
| Azure 轉送 | 來自 Microsoft Power Platform 服務的 HTTPS 輸出 | Microsoft 對等互連 在 ExpressRoute 設定的子網路中發佈公用 IP 位址上的 Web 服務 |
Power Automate 雲端流程與桌面流程之間的直接連線能力 |
輸入流量 (流量到 Microsoft Power Platform 服務)
以下輸入流量可能來自客戶網絡的 Microsoft Power Platform 服務。
| 描述 | 流量類型和方向 | 對等互連類型 | 用途 |
|---|---|---|---|
| 用戶端連線 | HTTPS 輸入到 Microsoft Power Platform 服務 | Microsoft 對等互連 由 Azure 內容傳遞網路所提供之靜態內容的直接網際網路連線 |
客戶端對 Microsoft Power Platform 服務 UI 的要求 |
| Web 服務 | HTTPS 輸入到 Microsoft Power Platform 服務 | Microsoft 對等互連 | 透過 Web 服務 API (SOAP、WEB API) 對 Microsoft Power Platform 服務的要求。 來自標準或自訂用戶端應用程式 |
| 連接器 | HTTPS 輸入到 Microsoft Power Platform 服務 | Microsoft 對等互連 | 使用內部部署的資料閘道透過連接器 APIM 回覆至 Microsoft Power Platform 服務 |
Microsoft Power Platform 服務中的內部雲端連線
Microsoft Power Platform 服務會使用 Microsoft 365 和 Azure 中託管的其他多個 Microsoft 線上服務並與之整合。
| 描述 | 流量類型和方向 | 目的 |
|---|---|---|
| Exchange 整合 | HTTPS 輸出至 Microsoft 365 | 從伺服器端同步處理到 Exchange Online 的 Exchange Web 服務要求 |
| SharePoint 整合 | HTTPS 輸出至 Microsoft 365 | 從 Microsoft Power Platform 服務到 SharePoint 線上的 SharePoint Web 服務要求 |
| 服務匯流排 | HTTPS 輸出至 Azure 服務匯流排 | 將事件做為標準事件註冊或從自訂外掛程式和工作流程活動推送到 Azure 服務匯流排 |
| 資料同步 | 來自 Azure 的 HTTPS 輸入 | 資料服務同步處理的輸入變更追蹤要求，包括搜尋/離線/客戶見解 |
| 驗證 | HTTPS 輸出至 Azure Active Directory (Azure AD) | 大多數驗證都是透過被動重定向和宣告代用文字完成的，但是部分資料是直接同步 Azure AD |
| 資料流程 | HTTPS 輸出至 Azure Data Lake Storage | 提供分析功能並允許存取包含來自 Microsoft Power Platform 服務和其他來源之資料的大型資料解決方案，以及可從分析得到的見解。 |
| 連接器 | HTTPS 輸出至 Azure PaaS 服務 | 與各種 Azure PaaS 服務的連線 |
| Desktop flows | HTTPS 傳出 Azure 轉送 | 桌面版 Power Automate 中 Power Automate 雲端流程和桌面流程之間建立的直接連線能力。 |
這些服務之間的實際連線 (在 Microsoft 或客戶 Azure 訂閱中託管) 由 Microsoft 處理。 ExpressRoute 不適用於與這些服務的連線。
當事件推送到服務匯流排上時，Microsoft Power Platform 服務與 Azure 之間的連線會在內部處理。 另外，客戶可以向服務匯流排要求擷取資訊，這可以透過 Microsoft 對等互連來管理。
與 Microsoft Power Platform 服務之間的客戶公用和私人雲端連線
Microsoft Power Platform 服務也允許與公用或私人 Azure 資源直接整合：
來自外部來源，透過使用 Microsoft Dataverse Web 服務 API。
到外部來源，透過使用 Web 服務提出要求。
到外部來源，透過使用連接器。
在 ExpressRoute 路由中需要考慮這項影響。
| 描述 | 流量類型和方向 | 對等互連類型 | 用途 |
|---|---|---|---|
| 入口網站 | 到 Azure 的 HTTPS 輸入 | 資料中心的內部，除靜態內容外，它使用內容傳遞網路。 (由於 ExpressRoute 不支援內容傳遞網路，因此靜態內容將透過公用網際網路傳輸。) | 託管對外公開的服務。 在某些案例中，內部員工可以存取這些資源，因此您可能希望流量透過 ExpressRoute 傳輸，而不是公用網際網路 |
| 學習路徑 | 到 Azure 的 HTTPS 輸入 | 使用 ExpressRoute 不支援的內容傳遞網路，因此內容將透過公用網際網路傳輸 | 這託管於公開服務上，因為它不包含私人客戶資料。 出於可預測性目的，在某些情況下，您可能會希望透過 ExpressRoute 進行路由 |
| 服務匯流排 | HTTPS 輸入至 Azure 服務匯流排 | 內部到資料中心 | 從既有的 Azure 服務匯流排，將事件提取為標準事件註冊或從自訂外掛程式或工作流程活動 |
| Web 服務要求 | 從 Azure IaaS/PaaS 輸入 | 內部到資料中心 | 客戶可以在 Azure 中託管自訂應用程式，並提出 Microsoft Power Platform Web 服務要求 |
| Web 服務要求 | 輸出至 Azure IaaS/PaaS | 內部到資料中心 | 客戶可以執行提出 Azure 託管服務要求的自訂外掛程式和工作流程活動 |
| 資料流程 | 資料連線至 Azure Data Lake Storage | 內部到資料中心 | 提供分析功能並允許存取包含來自 Microsoft Power Platform 服務和其他來源之資料的大型資料解決方案，以及可從分析得到的見解。 |
| Azure Data Lake | 資料連線至 Azure Data Lake Storage | 內部到資料中心 | 提供分析功能並允許存取包含來自 Microsoft Power Platform 服務和其他來源之資料的大型資料解決方案，和從分析得到的見解。 |
| Azure SQL | 資料連線到 Azure SQL 服務 | 內部到資料中心 | 有了「匯出至資料倉儲」等功能，用 Azure SQL 執行個體來存放 Microsoft Dataverse 資料複本，以用於報表或複製的頻率將增加。 保護這些資源與 ExpressRoute 間的連線可能很重要。 |
將來可能會有其他的公用服務因為使用了其他 Azure 功能，而在內部連接至資料中心。