規劃資料移轉

  • 7 分鐘

資料平台現代化專案有五個階段，通常會依序完成。

在我們的全球性零售商案例中，您的董事會已核准現代化專案，您開始組織工作人員和其他資源。 為了最佳方式設定和指派工作，您需要深入瞭解專案階段。

在此單元中，您將更加分別深入探索這五個階段。

資料現代化的五個階段圖表:探索、評量、規劃、轉換和驗證。

起始及探索

起始資料平台現代化專案的目的，通常是為了符合商務或法律需求。 因此，請務必考量這些需求，並從資深管理取得支援。 第一個步驟是完成由下列考量要素組成的探索練習：

  • 評估目前的環境

    許多 IT 基礎結構通常會在許多年甚至是數十年內演進。 在這段時間內，企業和員工可能會有極大的變化，導致組織可能不再擁有系統專家。 在罕見的情況下，組織可能甚至會忘記他們仍然還有一些系統存在。

  • 檢查現有應用程式與資料庫之間的相依性

    您應該花一點時間瞭解您的應用程式如何與您網路中現有的資料庫互動。 此外，您也應該瞭解任何可能存在的資料庫間相依性，讓您可以將資料庫共同組成邏輯群組。 透過進行此練習，您將會使用資料庫的邏輯群組做為將它們當作一個單位移轉至 Azure 的基礎。

  • 列出系統的工作負載類型

    針對已識別的資料庫伺服器列出工作負載類型可提供其使用量的見解。 工作負載可以根據讀取或密集寫入，分類為分析 (OLAP) 或交易式 (OLTP)。 這有助於決定要移轉技術至哪些資料平台。 進一步分類可能包括批次或決策支援工作負載。

評量

在評量階段，探索階段收集的資訊是用來進行已識別工作負載的完整評估，以建立下列事項：

  • 任何可能的移轉障礙
  • 任何需要移轉後修正的重大變更
  • 工作負載可使用的 Azure 功能

您可以透過完成目前的工作負載評量和工作負載準則評估來建立此項：

  • 目前的工作負載評量

    識別的資料庫伺服器和應用程式被分類並確認以建立下列項目：資料量和預期的成長率、平均資源使用量，以及其對企業的重要度。 此階段也提供一個機會來考慮合併或解除委任內部部署資料庫，以減少要移轉的資料庫數目，並降低擁有權總成本。

  • 工作負載準則評量

    在工作負載準則評量中，您會使用目前工作負載評量的結果，並定義執行已找出的工作負載的移轉後準則。

    假設您在尖峰時段識別出大量使用，但在離峰時段時為低使用量的交易式資料庫伺服器。 在工作負載準則評量中，您會定義移轉後準則，例如移轉至具有自動調整功能的 Azure SQL Database，以處理尖峰負載。

規劃

資料平台現代化專案的規劃階段牽涉到判斷任何計劃性或非計劃性中斷的目標平台、移轉方法和風險降低計畫。

在資料平台現代化程式的規劃階段中，有七個詞彙可說明如何處理應用程式和資料從現有內部部署環境轉換到新的雲端架構環境 (無論公開或私人)：

# 階段 動作 描述
1. 保持 不執行任何動作 持續現代化，同時考慮剩餘內部部署服務的長期選項。
2. 重新裝載 移轉至 IaaS 這種方法免除了資料中心管理的需求，並透過較低的擁有權總成本 (TCO) 提供更高的投資報酬率 (ROI)。
3. 重構 透過最低限度的應用程式變更移轉至 IaaS 或 PaaS 這種方法免除了資料中心管理的需求，並透過較低的擁有權總成本 (TCO) 提供更高的投資報酬率 (ROI)。 此外可透過合併資料庫來降低管理額外費用。
4. 重新架構 重寫應用程式的核心層面以使用雲端技術 它可讓您使用新式元件、減少程式碼部署，以及促進基礎結構和服務的 DevOps 部署。
5. 重建 重建應用程式以使用 PaaS 或無伺服器技術 較新的技術重建資料平台和應用程式，可讓您使用 Azure 的內建高可用性、增加應用程式可攜性和延展性，並將所用技術與支援/開發應用程式人員之間的潛在技能差距降到最低。
6. Replace 將應用程式取代為較新的應用程式或 SaaS 解決方案 當應用程式相依於連結至伺服器的實體裝置，或與內部部署基礎結構緊密整合時，請考慮取代方法。
7. 停用不再需要的應用程式 當舊版應用程式和資料庫已無法滿足商務或法律需求時，應該考慮將其淘汰。

下圖顯示每個詞彙所需的工作量，與企業從移轉中獲得價值的比較。

  • 平台目標選項

    選擇目標平台時，有兩個高階選擇可供您使用。

    • 基礎結構即服務 (IaaS)：在此方法中，您會將資料移轉至已安裝 SQL Server 的虛擬機器。

    • 平台即服務 (PaaS)：在此方法中，您會將資料移轉到適合您工作負載的資料平台服務。 針對交易式工作負載，這將使用 Azure SQL Database 或 Azure SQL 受控執行個體。 針對線上分析處理 (OLAP) 類型工作負載，這將使用 Azure Synapse Analytics。

  • 依功能選擇目標平台

    • Azure SQL Database - 如果應用程式介面區是資料庫範圍則使用。 SQL Database 提供的低維護解決方案，對於某些工作負載而言可能是絕佳的選項。

    • Azure SQL Database 彈性集區 - 彈性集區可讓您將儲存體和計算資源配置給資料庫群組，而不必個別管理每個資料庫的資源。 此外，彈性集區比單一資料庫更容易調整，因為對彈性集區已做出變更，而不再需要調整個別資料庫。

    • Azure SQL Database 無伺服器 - 對於降低開發和測試環境中的成本有效用。 自動暫停延遲功能可讓您在資料庫自動暫停之前設定非使用期間。 您可以選擇 1 小時到 7 天或停用。 再次存取資料庫時，它會繼續執行，而且只會在暫停期間產生儲存體費用。

    • Azure SQL 受控執行個體 - 適用於應用程式介面區是以執行個體為範圍，且需要 Azure SQL Database 中未提供的功能，例如：

      • SQL Agent
      • MSDTC
      • DQS
      • MDS
      • Database Mail
      • PolyBase
      • 連結的伺服器支援
      • 支援新的 Azure 雲端服務，例如威脅偵測

    • Azure 虛擬機器上的SQL Server - 如果應用程式介面區已設定實例範圍，且需要 Azure SQL 受控執行個體中無法使用的功能，例如SQL Server Reporting Services (SSRS)，SQL Server Analysis Services (SSAS) 和 SQL Server Integration Services (SSIS)。

    • Azure Synapse Analytics - 如果您的應用程式會在大量資料中執行複雜的查詢，且利用大量平行處理 (MPP) 來減少查詢處理時間。

若要檢視每個適用於 SQL 的 PaaS 供應項目所支援的功能清單，請參閱功能比較：Azure SQL 資料庫和 Azure SQL 受控執行個體。

  • 依成本選擇目標平台

    • Azure SQL Database - Azure SQL Database 的平台即服務本質大幅降低 Azure IaaS 拓撲上較為傳統的 SQL Server 的系統管理和管理成本，因為大部分的必要工作會在背景由 Microsoft Operations 以無訊息方式完成。 在規模上可以節省大量時間和精力。

    • Azure SQL Database 彈性集區 - Azure SQL Database 彈性集區可協助多個具有無法預測使用需求的資料庫大幅節省成本。 共用計算資源，避免過度佈建，並降低伺服器維護和管理的成本。

    • Azure SQL 受控執行個體 - SQL 受控執行個體提供給想要完全受控服務的客戶，讓他們可以輕鬆地隨即轉移其內部部署環境，並減少設定變更。 此環境提供最少 8 核心和最多 8 TB 的儲存空間，而且位於隔離的虛擬網路中。 這項供應項目非常適合想要快速進入雲端，而且想要避免維護虛擬機器管理費用的客戶。

    • Azure 虛擬機器上的SQL Server - 相較於 PaaS 供應項目，SQL Server 在 Azure 虛擬機器上執行的計算、儲存體和管理成本較高，但可對 SQL Server 和基礎結構提供更大的控制權。

    • Azure Synapse Analytics - Azure Synapse Analytics 可利用 MPP 架構在數分鐘內處理複雜查詢，無須耗費數小時。

  • 離線移轉與線上移轉的比較

    在規劃階段中，您會想要考慮是否要進行離線或線上移轉。 若使用離線移轉，在移轉開始的同時，應用程式也會開始停機。 若要將停機時間限制在移轉完成後切換至新環境的所需時間，請使用線上移轉。 建議您測試離線移轉以判斷停機時間是否在可容忍的範圍內；如果太長，請執行線上移轉。 此外，視所選的 Azure 平台而定，線上與離線選項可能無法使用。

轉換和最佳化

您的評量和規劃應已找出出您的應用程式和資料庫的各個層面，而這些層面將需要針對一項功能進行轉換或最佳化的轉移後工作，以確保移轉成功。 轉換通常需要您進行修正或變更資料庫層面的作業。

最佳化通常牽涉到針對已移轉的資料庫進行修改，以便運用某項功能，或在 Azure 中最佳化其使用方式。

例如，轉換可能涉及修改預存程序或 SQL 查詢，其中包含目標資料庫中不支援的語法。 這需要調整語法，以確保與新的資料庫平台的相容性，確保預存程式或查詢不會在目標環境中發生任何問題，並順利執行。

  • 轉換

    若要確保一個成功的移轉後體驗，可能需要對資料庫進行下列一或多項變更。

    • 安裝移轉前版本升級

    • 修正移轉評量工具找出的所有錯誤

    • 實作資料庫結構變更

    • 將現有的整合式資料庫服務移轉至 Azure

    • 處理雲端中的 SSIS 工作負載

  • 最佳化

    在移轉期間，建議您遵循下列一或多個最佳化指導方針，以確保您的組織充分發揮其在 Azure 中的投資。

    • 評量目標平台上可能提供的新功能

    • 重新調整工作負載，使其成為更具成本效益或效能效益的集合

    • 在移轉期間選擇最高的服務等級和效能層級，並在移轉完成後降低

    • 確保工作負載的大小正確

    • 盡量縮短 BACPAC 檔案和目的地資料中心之間的距離

    • 在移轉期間停用自動統計資料

    • 分割區資料表與索引

    • 捨棄索引檢視表，在移轉完成後重新建立

移轉、驗證和補救

這個階段牽涉到移轉本身，而且確認成功移轉所需的驗證步驟和補救步驟相當重要。 先前的規劃、評量和轉換階段可確保所有項目都已就緒，可進行移轉並在移至 Azure 後正常運作。 剩下的工作就是準備所需的移轉工具、完成移轉，然後執行移轉後功能和效能驗證，以確保和來源資料庫的資料一致性。

移轉、驗證和補救考量要點

您可以使用各種工具來移轉至選取的目標平台。 這些工具將在其他的課程模組中說明。 同時，完成移轉時請務必考量下列事項：

  • 以瞭解您的工作負載需求作為起點
  • 選取非關鍵性工作負載或低優先順序資料庫作為初始移轉
  • 執行測試移轉
  • 測試資料庫找出問題
  • 測試計劃以降低與停機時間和相容性問題相關的風險
  • 以中斷情況為依據來評定移轉工具，以協助降低資料庫停機的風險
  • 持續逐一查看您的移轉程式
  • 把將進行移轉的應用程式和資料庫的可用維護視窗納入考量
  • 讓舊的資料庫和應用程式離線
  • 協力廠商應用程式
  • 建立新的災害復原和維護計畫