災害復原設計
Azure 虛擬 WAN 可讓您彙總、連線、集中管理及保護所有全域部署。 您的全域部署可能包含不同分支、存在點 (PoP)、私人使用者、辦公室、Azure 虛擬網路和其他多雲端部署的任何組合。 您可以使用 SD-WAN、站對站 VPN、點對站 VPN 和 ExpressRoute，將您的不同網站連線到虛擬中樞。 如果您有多個虛擬中樞，所有中樞在標準虛擬 WAN 部署中會以完整網狀連線。
在本文中，讓我們深入了解如何建構虛擬 WAN 在災害復原中支援的各種網路即服務連線選項。
虛擬 WAN 的網路即服務連線選項
虛擬 WAN 支援下列後端連線選項：
- 遠端使用者連線
- 分支/辦公室/SD-WAN/站對站 VPN
- 私人連線能力 (ExpressRoute 私人對等互連)
針對每個連線選項，虛擬 WAN 會在虛擬中樞內部署另一組閘道執行個體。
本質上，虛擬 WAN 旨在提供電訊廠商等級的高可用性網路彙總解決方案。 為了達到高可用性，當這幾種不同的閘道都部署在虛擬 WAN 中樞內時，虛擬 WAN 會具現化多個執行個體。 若要深入了解 ExpressRoute 高可用性，請參閱使用 ExpressRoute 設計高可用性。
使用點對站 VPN 閘道時，部署的執行個體數目下限是兩個。 使用點對站 VPN 閘道時，您選擇點對站閘道的彙總輸送量容量，還會自動為您佈建多個執行個體。 您根據可連線到虛擬中樞的用戶端或使用者數目來選擇彙總容量。 從用戶端連線能力的觀點來看，點對站 VPN 閘道執行個體隱藏在閘道的完整網域名稱 (FQDN) 背後。
針對站對站 VPN 閘道，閘道的兩個執行個體會部署在虛擬中樞內。 部署的每個閘道執行個體都有自己一組公用和私人 IP 位址。 下列螢幕擷取畫面顯示與範例站對站 VPN 閘道組態兩個執行個體相關聯的 IP 位址。 換句話說，這兩個執行個體會提供兩個獨立通道端點，以從分支建立站對站 VPN 連線。 若要達到最高可用性，請參閱跨多個 ISP 連結的 Azure 路徑選取。
網路架構達到最高可用性是商務持續性和災害復原 (BCDR) 的關鍵第一步。 在本文的其餘部分，如先前所述，讓我們在高可用性之外，討論如何建構 BCDR 的虛擬 WAN 連線網路。
災害復原設計的需求
隨時隨地都可能發生災害。 在雲端提供者區域或網路、服務提供者網路或內部部署網路內都可能發生災害。 因為自然傷害、人為錯誤、戰、碰撞或設定錯誤等特定因素，雲端或網路服務的區域影響很難排除。為確保業務關鍵應用程式的持續性，您需要具備災害復原設計。 為了打造完整的災害復原設計，您必須識別端對端通訊路徑中可能失敗的所有相依性，並為每個相依性建立非重疊的備援。
無論是在 Azure 區域、內部部署或其他任何地方執行任務關鍵性應用程式，您都可以使用另一個 Azure 區域作為容錯移轉網站。 下列文章說明從應用程式和前端存取角度進行的災害復原：
使用備援連線的挑戰
當您使用一個以上的連線來互連同一組網路時，您會在網路之間引進平行路徑。 未正確架構的平行路徑可能會導致非對稱式路由。 如果您在路徑中有具狀態實體 (例如 NAT、防火牆)，非對稱路由可能會封鎖流量。 在私人連線上，您通常不會有或遇到具狀態實體，例如 NAT 或防火牆。 因此，私人連線上的非對稱式路由不一定會封鎖流量。
不過，如果您在異地備援平行路徑之間平衡流量負載，因為平行連線的實體路徑不同，您會遇到不一致的網路效能。 因此，在災害復原設計中，我們必須考慮穩定狀態 (非失敗狀態) 和失敗狀態期間的網路流量效能。
存取網路備援
大部分的 SD-WAN 服務 (受控解決方案或其他) 透過多個傳輸類型 (例如網際網路寬頻、MPLS、LTE)，為您提供網路連線能力。 若要防止傳輸網路失敗，請選擇透過多個傳輸網路連線。 針對住家使用者情況，您可以考慮將行動網路當作寬頻網路連線能力的備用方案。
如果不可能透過不同傳輸類型取得網路連線能力，請選擇透過多個服務提供者取得網路連線能力。 如果您透過多個服務提供者取得連線能力，請確定服務提供者維護非重疊的獨立存取網路。
遠端使用者連線能力考量
遠端使用者連線能力是透過終端裝置到網路之間的點對站 VPN 建立。 在網路失敗之後，終端裝置會卸除並嘗試重新建立 VPN 通道。 因此，針對點對站 VPN，災害復原設計的目標應該是將失敗後的復原時間縮到最短。 下列網路備援有助於將復原時間縮短最短。 視連線有多重要而定，您可以選擇其中部分或全部選項。
- 存取網路備援 (上述)。
- 管理點對站 VPN 終端的備援虛擬中樞。 當您有多個虛擬中樞搭配點對站閘道時，VWAN 會提供全域設定檔來列出所有點對站端點。 透過全域設定檔，您的終端裝置可以連線到最接近的可用虛擬中樞，這提供最佳的網路效能。 如果您的所有 Azure 部署都位於單一區域，且連線的終端裝置與區域接近，則可以在區域內擁有多餘的虛擬中樞。 如果您的部署和終端裝置分散到多個區域，則可以在您選取的每個區域部署具有點對站閘道的虛擬中樞。 虛擬 WAN 有內建的流量管理員，可自動為遠端使用者連線能力選取最佳中樞。
下圖顯示在一個區域內管理備援虛擬中樞及其各自點對站閘道的概念。
在上圖中，綠色實線顯示主要點對站 VPN 連線，黃色虛線顯示待命備用連線。 VWAN 點對站全域設定檔會根據網路效能選取主要和備用連線。 如需全域設定檔的進一步資訊，請參閱下載使用者 VPN 用戶端的全域設定檔。
站對站 VPN 考量事項
讓我們考慮以下圖表中討論的範例站對站 VPN 連線。 若要建立具有高可用性主動-主動通道的站對站 VPN 連線，請參閱教學課程：使用 Azure 虛擬 WAN 建立站對站連線。
注意
為協助您輕鬆了解本節所討論的概念，我們不重複討論站對站 VPN 閘道的高可用性功能，該功能針對您設定的每個 VPN 連結，讓您建立兩個通道前往兩個不同端點。 然而，在部署本節中建議的任何架構時，請記得為您建立的每個連結設定兩個通道。
多連結拓撲
為了防範分支網站的 VPN 客戶內部部署設備 (CPE) 故障，您可以從分支網站的平行 CPE 裝置，設定平行 VPN 連結通往 VPN 閘道。 此外，為了防範最後一哩路服務提供者到分公司的網路失敗，您可以透過不同服務提供者網路設定不同的 VPN 連結。 下圖顯示多個 VPN 連結，源自分支網站的兩個不同 CPE，並以相同 VPN 閘道為終點。
從虛擬中樞 VPN 閘道到分支網站最多可設定四個連結。 當您設定分支網站的連結時，您可以識別與連結相關聯的服務提供者和輸送量速度。 當您設定分支網站與虛擬中樞之間的平行連結時，VPN 閘道預設會平衡平行連結之間的流量負載。 流量的負載平衡是根據每個流程的相同成本多重路徑 (ECMP)。
多中樞多連結拓撲
多連結拓撲防範內部部署分支位置的 CPE 裝置故障和服務提供者網路失敗。 此外，為了防範虛擬中樞 VPN 閘道的任何停機，多中樞多連結拓撲有幫助。 下圖顯示拓撲，其中在區域內的虛擬 WAN 執行個體下設定多個虛擬中樞：
在上述拓撲中，由於中樞之間的連線上內部 Azure 區域延遲很小，因此您可以在內部部署與處於主動-主動狀態的兩個虛擬中樞之間，將輪輻 VNet 分散到中樞，以使用所有站對站 VPN 連線。 在拓撲中，內部部署和輪輻 VNET 之間的流量在穩定狀態期間，預設直接周遊於輪輻 VNET 所連線的虛擬中樞，並只在失敗狀態期間使用另一個虛擬中樞作為備用。 在穩定狀態下，流量會周遊於直接的連線中樞，因為相較於備用中樞，直接連線的中樞所公告的 BGP 路由有較短的 AS 路徑。
多中樞多連結拓撲可防範大部分的失敗情況，維持商務持續性。 不過，如果重大失敗導致整個 Azure 區域停止運作，您需要「多區域多重連結拓撲」，才能經得起失敗。
多區域多重連結拓撲
除了我們先前討論的多中樞多連結拓撲所提供的保護之外，多區域多連結拓撲更能防範整個區域的重大失敗。 下圖顯示多區域多連結拓撲。 在相同的虛擬 WAN 執行個體下可以設定不同區域中的虛擬中樞。
從流量工程的觀點來看，您需要考慮備援中樞在一個區域與備用中樞在另一個區域這兩者的顯著差異。 差異在於主要區域與次要區域之間的實際距離所產生的延遲。 因此，您可能想要將穩定狀態的服務資源部署在最接近分支/終端使用者的區域，而遠端區域只是當作備用。
如果內部部署分支位置分散在兩個以上的 Azure 區域，則在穩定狀態期間，多區域多連結拓撲較有助於分散負載和獲得更好的網路體驗。 下圖顯示分支位於不同區域的多區域多連結拓撲。 在這種情況下，拓撲額外提供有效的商務持續性和災害復原 (BCDR)。
ExpressRoute 考量事項
ExpressRoute 私人對等互連的災害復原考量事項會在使用 ExpressRoute 私人對等互連設計災害復原中討論。 如本文所述，該文章中所述的概念同樣適用於虛擬中樞內建立的 ExpressRoute 閘道。 如下圖所示，在區域內使用備援虛擬中樞是中小型內部部署網路考量中唯一建議的拓撲增強功能。
在上圖中，ExpressRoute 2 的終點在區域內第二個虛擬中樞內的另一個 ExpressRoute 閘道。
下一步
在本文中，我們已討論虛擬 WAN 災害復原設計。 下列文章說明從應用程式和前端存取角度進行的災害復原：
若要建立 Virtual WAN 的點對站連線，請參閱教學課程：使用 Azure Virtual WAN 建立使用者 VPN 連線。 若要建立站對站到虛擬 WAN 的連線，請參閱教學課程：使用 Azure 虛擬 WAN 建立站對站連線。 若要將 ExpressRoute 線路與虛擬 WAN 建立關聯，請參閱教學課程：使用 Azure 虛擬 WAN 建立 ExpressRoute 關聯。