描述 Azure 移轉架構

已完成

您必須先考慮建立移轉計畫,才能開始將 Tailwind Traders 內部部署工作負載移轉至 Azure。 此計畫應該識別要移轉的工作負載,以及移轉期間要使用的適當服務或工具。 在理想的情況下,您的計劃也應該包含有關如何將已移轉服務最佳化的詳細資訊。

Azure 移轉架構可協助您開發計畫並完成移轉。 此架構包含四個階段: 評估移轉優化監視

階段 1:評估您的內部部署環境

在第一個階段中,您會評估目前的內部部署環境:

  • 識別您的應用程式及其相關伺服器、服務和資料,其位於移轉範圍內
  • 開始涉及專案關係人,例如 IT 部門和相關業務群組
  • 建立您打算移轉的伺服器、服務和應用程式的完整清查和相依性對應
  • 使用 Azure 擁有權總成本計算機 (TCO) 來估計成本節省
  • 識別可用來執行四個階段的適當工具和服務

移轉策略模式

將工作負載遷移至雲端有四種廣泛的策略模式:重新裝載、重構、重新架構和重建。 您採用的策略取決於商業誘因和移轉目標。 您可以考慮採用多個模式。 您可以選擇重新裝載對企業不重要的簡單應用程式或應用程式,但重新建構更複雜的應用程式與業務關鍵。

  • 重新裝載:重新裝載通常稱為隨即轉移。 此策略不需要變更程式碼,並可讓您快速將現有的工作負載移轉至 Azure。 每個工作負載都會保持現狀移轉,沒有與程式碼變更相關聯的風險和成本。

  • 重構:重構通常稱為 重新封裝。 重構需要對應用程式進行最少的變更,才能連線到 Azure 平臺即服務, (PaaS) 並使用雲端供應專案。 您可以將現有的應用程式移轉至Azure App 服務或Azure Kubernetes Service (AKS) 。 或者,您可以將關聯式和非關係資料庫重構為其他選項。 如果您的應用程式可以輕鬆地重新封裝以在 Azure) 中運作,請重構為Azure SQL 受控執行個體、適用於 MySQL 的 Azure 資料庫、適用於 PostgreSQL 的 Azure 資料庫和 Azure Cosmos DB (。

  • 重新架構:針對移轉重新架構著重于修改和擴充應用程式功能和程式碼基底,以優化適用于雲端延展性的應用程式架構。 您可以將整合型應用程式細分成一組微服務,這些微服務可一起運作並輕鬆地進行調整。 或者,您可以將關聯式和非關係資料庫重新架構為完全受控的資料庫解決方案。 重新架構以Azure SQL 受控執行個體、適用於 MySQL 的 Azure 資料庫、適用於 PostgreSQL 的 Azure 資料庫和 Azure Cosmos DB。

  • 重建:使用 Azure 雲端技術完全重建應用程式,以進一步進行重建。 您可以使用雲端原生技術建置綠色欄位應用程式,例如 Azure Functions、Azure AI、Azure SQL 受控執行個體和 Azure Cosmos DB。

下表列出使用四種模式的案例。

重新裝載 重構 重新架構 重建
將工作負載快速移至雲端

在不修改工作負載的情況下移動工作負載

針對在移轉後利用 Azure IaaS 延展性而設計的應用程式

當工作負載對您的業務很重要時,但您不需要立即變更應用程式功能
套用 Azure 所提供的創新 DevOps 做法

實作工作負載的 DevOps 容器策略

支援現有程式碼基底和可用開發技能的可攜性
您的應用程式需要重大修訂,才能納入新功能

您的應用程式需要重大修訂,才能在雲端平臺上有效運作

使用現有的應用程式投資

符合延展性需求

套用創新的 DevOps 做法

將虛擬機器的使用降到最低
快速開發

支援具有有限功能和生命週期的現有應用程式

使用 DevOps 做法加速業務創新

使用雲端原生技術來建置新的應用程式,例如 Azure Blockchain

將繼承應用程式重建為雲端中的「無程式碼應用程式」或「低應用程式」

階段 2:移轉您的工作負載

當您完成評量後,即可開始移轉目標應用程式及其相關服務和資料的流程。 移轉階段通常包含下列工作:

  • 部署雲端基礎結構目標。 您必須先建立必要的雲端基礎結構目標,才能移轉 Tailwind Traders 工作負載。 根據您用來執行移轉的工具,可能需先建立必要的 Azure 資源,才能開始移轉。 某些工具,例如 Azure Migrate 和 Azure 資料移轉服務 可以為您建立目標 Azure 資源。

  • 移轉工作負載。 試驗工作負載移轉,以及選擇試驗的非關鍵應用程式是個不錯的主意。 這種方法可讓您熟悉工具、取得流程和程式的經驗,以及在移轉大型或複雜的工作負載時降低風險。

  • 解除委任內部部署基礎結構:當您滿意來源應用程式和資料庫已成功移轉之後,您必須解除委任來源工作負載。 請考慮保留來源工作負載備份和封存的資料。 此資料可能會實際派上用場,因為它提供了歷史封存。 您可以將這些備份和封存儲存在Azure Blob 儲存體中。

階段 3:優化已移轉的工作負載

針對優化階段,有三個主要努力專注于您的規劃:

  • 分析工作負載的移轉成本
  • 檢閱降低成本的建議
  • 識別改善工作負載效能的選項

您可以在Azure 入口網站中使用 Microsoft 成本管理 (先前稱為 Azure 成本管理和計費) 來分析工作負載成本。 此工具適用于包含已移轉工作負載的 Azure 資源群組。 您可以在成本分析成本管理> 一節中找到工具。 下列螢幕擷取畫面顯示資源群組上一個計費期間 ContosoResourceGroup 的成本分析。 結果會根據服務名稱、區域和資源顯示成本。 您可以自訂顯示結果以符合您的需求。

顯示成本分析範例的螢幕擷取畫面,其中含有Azure 入口網站中的估計成本。

若要協助降低成本,您可以選擇 Advisor 建議,以使用 Azure Advisor 功能。 分析目前的成本並檢閱建議之後,您可以判斷改善工作負載效能的選項。

階段 4:監視您的工作負載

您可以使用 Azure 監視器,從 Azure 虛擬機器擷取健康情況和效能資訊。 在目標虛擬機器上安裝 Azure 監視器記錄 (先前稱為 Log Analytics) 代理程式,然後設定警示和報告。

注意

您可以在執行 Windows 或 Linux 的電腦上安裝 Azure 監視器記錄代理程式。

您可以根據資料來源範圍來設定警示:

  • 特定計量值,例如 CPU 使用量
  • 記錄檔中的特定文字
  • 健康情況計量
  • 自動調整計量