選取 Azure 區域以進行移轉

  • 發行項

當您將現有的環境移轉至 Azure 時，您必須選取 Azure 區域或一組區域來裝載已移轉的元件。 區域選取牽涉到下列高階步驟：

  • 檢閱核心 Azure 區域選取指引，以瞭解如何選取符合您需求的 Azure 區域。
  • 清查並記錄您環境的目前狀態 。
  • 實作移轉的一般方法 ，包括是否要在單一區域中執行、使用多個可用性區域，或使用多個區域。
  • 評估可能需要的程序變更 。
  • 規劃移轉程式。
  • 優化和升級程序變更。

本文提供如何選擇符合移轉需求的 Azure 區域指引。 如果您尚未這麼做，您可能需要擴充 登陸區域區域 以支援多區域方法。

注意

本文涵蓋工作負載移轉特有的考慮。 您也應該了解針對任何組織或工作負載選取 Azure 區域的一般原則。 如需詳細資訊，請參閱 選取 Azure 區域。

記錄您的案例複雜度

判斷您的案例是否需要檔和程式對齊。 下列方法可協助您評估潛在的挑戰，並建立一般動作：

  • 請考慮更健全的整備程度和治理實作。
  • 清查受影響的地理位置。 編譯受影響國家或地區的清單。
  • 記錄使用者基底。 雲端移轉會影響已識別國家或地區的員工、合作夥伴或客戶嗎？
  • 記錄數據中心和資產。 移轉工作是否包含已識別國家或地區的任何資產？
  • 記載區域產品版本可用性和故障轉移需求。
  • 記錄復原需求 ，以判斷是否需要可用性區域。 一般而言，您會考慮整個案例的復原需求，而不是針對個別區域。
  • 記錄您的主權需求和數據落地需求。 具有特定主權或數據落地需求的工作負載可能會影響您選擇的 Azure 區域。

在整個移轉過程中，請考慮如何調整各種案例和清查的變更。 下表顯示如何記錄各種案例的範例。

區域 國家/地區 當地員工 本機外部使用者 本機數據中心或資產 數據主權需求
北美洲 美國 Yes 合作夥伴和客戶 是 No
北美洲 加拿大 No 客戶 Yes Yes
歐洲 德國 Yes 合作夥伴和客戶 否 - 僅限網路 Yes
亞太地區 南韓 Yes 合作夥伴 是 No

為什麼使用者的位置相關？

支援多個國家或地區使用者的組織會開發解決使用者流量的技術解決方案。 在某些情況下，解決方案涉及資產的當地語系化。 在其他案例中，組織可能會選擇實作全球廣域網 （WAN） 解決方案，透過以網路為主的解決方案來解決不同的使用者基底。 不論是哪一種情況，不同使用者的使用量配置檔都可能會影響移轉策略。

例如，如果組織支援德國的員工、合作夥伴和客戶，但目前德國沒有數據中心，則組織可能會實作 租用線路 解決方案。 這種類型的解決方案會將流量路由傳送至其他國家/地區中的數據中心。 此現有路由對已移轉應用程式的感知效能造成重大風險。 在已建立且經過微調的全域 WAN 中插入更多躍點，即可在移轉後建立效能不佳應用程式的感知。 尋找並修正這些問題可能會對專案造成重大延遲。

下列各節都包含在評估、移轉和優化的必要條件和程式之間解決此複雜性的指引。 瞭解每個國家/地區中的使用者配置檔對於正確管理此複雜性至關重要。

為什麼數據中心的位置相關？

現有數據中心的位置可能會影響移轉策略。 請考慮下列因素：

架構決策：移轉策略設計的第一個步驟之一是判斷目標區域。 現有資產的位置通常會影響此判斷。 此外，雲端服務的可用性和這些服務的單位成本可能會因區域而異。 數據落地需求，包括主權需求，也可能會影響架構決策。 瞭解目前和未來資產的位置會影響架構決策，並可能會影響預算估計值。

數據中心相依性：在 [記錄您的案例複雜度] 區段中的數據表中，範例案例顯示您可能需要規劃各種全域數據中心之間的相依性。 在此規模上運作的組織可能不會記錄或清楚地了解這些相依性。 貴組織評估使用者配置檔的方法可協助您識別組織中的其中一些相依性。 您的小組也應該探索更多評定步驟，以協助降低相依性所產生的風險和複雜度。

實作一般方法

下列方法會使用數據驅動模型來解決全域移轉的複雜性。 如果移轉範圍包含多個區域，雲端採用小組應該評估下列整備考慮：

  • 判斷您是否符合您的商務需求：使用多個可用性區域來判斷高可用性、復原、效能和成本的需求。 如果不符合這些需求，請考慮您是否需要多重區域方法。

  • 評估數據主權：數據主權可能需要當地語系化某些資產，但許多資產不受這些合規性限制所控管。 記錄、報告、網路路由、身分識別和其他中央IT服務等服務可能有資格跨多個訂用帳戶或區域裝載為共用服務。 針對這些服務使用共用服務模型來評估數據主權。 如需此方法的概述，請參閱 具有共用服務的中樞輪輻拓撲參考架構。

  • 確定您的環境規模：如果您部署多個類似環境的實例，您可以為環境的移轉建立專用小組，以協助建立一致性、改善治理，以及加速部署。 複雜企業的治理指南會建立一種方法，以建立跨多個區域調整的環境。

數據驅動的必要條件

當小組熟悉基準方法和整備程度時，請考慮下列數據驅動的必要條件：

  • 完成一般探索：完成檔複雜度中的表格，以評估雲端採用策略的複雜性。

  • 分析每個受影響國家或地區的使用者配置檔：請務必在移轉程式中早期瞭解一般使用者路由。 變更全域租用線路，並將 Azure ExpressRoute 等連線新增至雲端數據中心，可能會導致網路延遲數月。 盡可能早地處理使用者路由。

  • 完成初始數字資產合理化：如果您將複雜性引入移轉策略，請完成初始數字資產合理化。 如需詳細資訊，請參閱 什麼是數字資產？。

  • 針對數字資產需求使用標記：建立標記原則，以識別受數據主權需求影響的任何工作負載。 請確定必要的標籤會從數位資產合理化開始，並繼續進行移轉的資產。

  • 評估中樞輪輻模型：分散式系統通常會共用一般相依性。 您通常可以藉由實作中樞輪輻模型來解決共用相依性。 雖然實作中樞輪輻模型的範圍不足移轉程式，但將模型標幟為在未來就緒進程的反覆項目期間要考慮的模型。

  • 排定移轉待辦專案優先順序：如果您需要網路變更以支援支援多個區域的工作負載生產部署，雲端策略小組應該追蹤及管理網路變更所產生的呈報。 這個較高層級的執行支援可藉由釋放策略小組來重新重排待辦專案，並確保網路變更不會封鎖全域工作負載，以協助加速變更。 只有在網路變更完成時，才會設定全域工作負載的優先順序。

這些必要條件有助於建立可在執行移轉策略期間解決複雜度的程式。

評估程序變更

如果您的移轉案例涉及全域資產和使用者基底複雜度，請新增重要活動來評估您的移轉候選專案。 這些活動會產生數據，以協助您釐清全球使用者和資產的障礙和結果。

評估程式期間的建議動作

評估跨數據中心相依性：Azure Migrate 中的相依性分析工具可協助您找出相依性。 在開始移轉之前，請先使用這些工具。 如果您的案例涉及全域複雜度，評估相依性是評估程式中的必要步驟。 您可以使用 相依性群組 ，將相依性可視化，並識別支援工作負載所需的任何資產的IP位址和埠。

重要

  • 您需要了解資產放置和IP位址架構的主題專家（SME），以識別位於次要資料中心的資產。
  • 評估視覺效果中的下游相依性和用戶端，以瞭解雙向相依性。

識別全域用戶影響：必要條件使用者配置檔分析的輸出應該識別受到全域使用者配置檔影響的任何工作負載。 如果移轉候選項目位於受影響的工作負載清單中，移轉架構設計人員應該諮詢網路和作業 SME。 這些專家可協助驗證網路路由和效能預期。 架構至少應包含最接近的網路作業中心和 Azure 之間的 ExpressRoute 連線。 ExpressRoute 連線的參考架構可協助您設定必要的網路連線。

合規性設計：必要條件使用者配置檔分析的輸出也應該識別受數據主權需求影響的任何工作負載。 在評估程式的架構活動中，指派的架構設計人員應諮詢合規性中小企業。 這些專家可協助架構設計人員瞭解跨多個區域移轉和部署的任何需求。 這些需求會大幅影響設計策略。 下列參考架構可協助設計：

警告

如果您使用 ExpressRoute 的參考架構或應用程式的參考架構，您可能需要從復寫程式中排除特定數據元素，以符合數據主權需求。 排除特定數據元素的工作會將步驟新增至升級程式。

移轉程序變更

如果您移轉必須部署到多個區域的應用程式，雲端採用小組必須考慮更多考慮。 Azure Site Recovery 保存庫和組態和進程伺服器的設計是其中兩項考慮。 另外兩個考慮是網路頻寬設計和數據同步處理。

移轉程式期間的建議動作

Site Recovery 保存庫設計：Site Recovery 是雲端原生復寫和將數位資產同步處理至 Azure 的建議工具。 Site Recovery 會將每個資產的相關數據復寫至 Site Recovery 保存庫。 此保存庫會系結至特定區域和 Azure 資料中心的特定訂用帳戶。 如果您將資產復寫到第二個區域，您可能也需要第二個 Site Recovery 保存庫。

組態和進程伺服器設計：Site Recovery 適用於系結至單一 Site Recovery 保存庫之組態和進程伺服器的本機實例。 當您使用此組態時，您可能需要在來源資料中心安裝這些伺服器的第二個實例，以利複寫。

網路頻寬設計：在復寫和進行中同步處理期間，您會透過網路將二進位數據從來源數據中心移至目標 Azure 資料中心的 Site Recovery 保存庫。 複寫和同步處理程式會耗用頻寬。 將工作負載複製至第二個區域會使耗用的頻寬量加倍。

在某些情況下，頻寬會受到限制。 在其他人中，工作負載牽涉到大量的設定或數據漂移。 在這些情況下，將數據復寫至第二個區域可能會干擾完成移轉所需的時間。 更重要的是，這些條件約束可能會影響仍相依於來源數據中心可用頻寬的使用者或應用程式體驗。

數據同步處理：最大的頻寬耗盡通常來自同步處理數據平臺。 如果您跨多個可用性區域部署，您可以使用區域備援資料服務，自動跨多個可用性區域同步處理您的數據。 跨多個區域的部署通常需要數據同步處理，才能讓應用程式保持一致。 此方法定義於多區域 Web 應用程式和多區域多層式應用程式的參考架構中。

如果讓應用程式保持同步處理是應用程式所需的作業狀態，您可能會想要將源數據平臺與每個雲端平臺同步處理。 在移轉應用程式和仲介層資產之前，請先執行這項同步處理。

Azure 到 Azure 災害復原：替代選項可能會進一步降低複雜性。 如果您使用雙步驟部署來符合時程表和數據同步處理需求， Azure 對 Azure 災害復原 可能是可接受的解決方案。 在此案例中，您會使用單一 Site Recovery 保存庫和設定和進程伺服器設計，將工作負載移轉至第一個 Azure 數據中心。 測試工作負載之後，您可以從移轉的資產將工作負載復原至第二個 Azure 資料中心。

此方法可減少對來源數據中心資源的影響。 Azure 對 Azure 災害復原也會利用 Azure 資料中心之間的快速傳送速率和高頻寬限制。

注意

Azure 到 Azure 災害復原方法可透過較高的輸出頻寬費用來增加短期移轉成本。

發行程序變更

當您在優化和升級期間解決全域複雜度時，您可能需要在您部署的每個區域中執行相同的工作。 如果您使用單一區域，可能仍然需要複寫商務測試和商務變更方案。

發行程式期間的建議動作

預先測試優化：初始自動化測試可以識別潛在的優化機會，如同任何移轉工作一樣。 對於全域工作負載，請獨立測試每個區域中的工作負載。 網路或所選 Azure 資料中心的次要設定變更可能會影響效能。

商務變更方案：針對任何複雜的移轉案例建立商務變更方案。 商務變更計劃有助於確保清楚溝通商務程式和用戶體驗的變更。 此計劃也有助於確保清楚溝通整合變更所需的工作時間。 在全域移轉工作中，方案應包含每個受影響地理位置中用戶的考慮。

商務測試：每個區域可能也需要商務測試。 商務測試可協助確保適當的效能，並遵循修改的網路路由模式。

升階正式發行前小眾測試版：升級通常會以單一活動的形式發生，而生產流量會立即重新路由傳送至已移轉的工作負載。 在全域發行工作中，您應該在稱為 正式發行前小眾測試版的用戶預先定義集合中傳遞升階。 促銷正式發行前小眾測試版可讓雲端策略小組和雲端採用小組有機會觀察效能，並改善對每個區域中用戶的支援。 您可以在網路層級控制促銷正式發行前小眾測試版。 具體而言，您可以將特定IP範圍的路由從來源工作負載資產變更為新移轉的資產。 移轉指定的使用者集合之後，您可以重新路由下一個群組。

正式發行前小眾測試版優化：促銷航班的其中一個優點是提供您更深入的觀察，並有機會將已部署的資產優化。 第一次正式發行前小眾測試版成功使用生產環境一段時間之後，您可以在IT作業程序支援時精簡移轉的資產。