共用方式為

無代理程式移轉架構

  • 發行項

本文說明在使用移轉和現代化工具的無代理程式移轉方法以移轉 VMware VM 時的複寫概念。

注意

此端對端 VMware 移轉案例檔目前為預覽狀態。 如需使用 Azure Migrate 的詳細資訊，請參閱 Azure Migrate 產品檔。

複寫程序

無代理程式複寫選項的運作方式，是使用 VMware 快照集和 VMware 變更區塊追蹤 (CBT) 技術從虛擬機器磁碟複寫資料。 下列方塊圖顯示在您使用移轉和現代化工具來移轉虛擬機器時所涉及的各個步驟。

移轉步驟。

針對虛擬機器設定複寫時，會先進行初始複寫階段。 在初始複寫期間，會建立 VM 快照集，而快照集磁碟中的完整資料複本會複寫到目標訂用帳戶中的受控磁碟。

VM 的初始複寫完成後，複寫程序會轉換至累加複寫 (差異複寫) 階段。 在累加複寫階段中，自上次完成的複寫週期開始後發生的資料變更會複寫並寫入至複本受控磁碟，藉以讓複寫與 VM 上發生的變更保持同步。

VMware 變更區塊追蹤 (CBT) 技術可用來追蹤複寫週期之間的變更。 複寫週期開始時，會建立 VM 快照集，並使用變更區塊追蹤來取得目前的快照集與上次成功複寫的快照集之間的變更。 只會複製自上一個完成的複製週期以來發生變更的資料，以保持虛擬機器的複製同步。在每個複寫週期結束時，會釋放快照集，並對虛擬機器執行快照集合併。

當您在複寫虛擬機器上執行移轉作業時，會有一個隨需差異複寫週期，複寫自上次複寫週期以來的其餘變更。 隨需週期完成後，對應至虛擬機器的複本受控磁碟會用來在 Azure 中建立虛擬機器。 在觸發移轉/容錯移轉之前，您必須先關閉內部部署虛擬機器。 關閉虛擬機器可確保在移轉期間不會遺失任何資料。

移轉成功且 VM 在 Azure 中開機後，請務必停止 VM 的複寫。 停止複寫將會刪除在資料複寫期間建立的中繼磁碟 (種子磁碟)，同時也可避免產生與這些磁碟上的儲存體交易相關聯的額外費用。

複寫週期

注意

請確定檢查先前的複寫嘗試或其他第三方應用程式的快照集是否存在。 如果 VM 的快照集已存在，即無法在 VM 上啟用變更追蹤。 在 VM 上刪除現有的快照集，或啟用變更區塊追蹤。

複寫週期是指將資料從內部部署環境傳輸到 Azure 受控磁碟的定期程序。 完整複寫週期包含下列步驟：

  1. 為每個與 VM 相關聯的磁碟建立 VMware 快照集
  2. 將資料上傳至 Azure 中的記錄儲存體帳戶
  3. 發行快照集
  4. 合併 VMware 磁碟

磁碟合併後，週期即告完成。

複寫所涉及的元件

內部部署元件：Azure Migrate 設備具有下列負責處理複寫的元件

  • DRA 代理程式
  • 閘道代理程式

Azure 元件：下表摘要說明了使用 VMware VM 移轉的無代理程式方法時所建立的各種 Azure Artifacts。

元件 區域 訂用帳戶 描述
復原服務保存庫 Azure Migrate 專案的區域 Azure Migrate 專案的訂用帳戶 用來協調資料複寫
服務匯流排 目標區域 Azure Migrate 專案的訂用帳戶 用於雲端服務與 Azure Migrate 設備之間的通訊
記錄儲存體帳戶 目標區域 Azure Migrate 專案的訂用帳戶 用來儲存複寫資料，供服務讀取並套用至客戶的受控磁碟
閘道儲存體帳戶 目標區域 Azure Migrate 專案的訂用帳戶 用來儲存複寫期間的機器狀態
金鑰保存庫 目標區域 Azure Migrate 專案的訂用帳戶 管理服務匯流排的連接字串，以及記錄儲存體帳戶的存取金鑰
Azure 虛擬機器 目標區域 目標訂用帳戶 在您移轉時建立於 Azure 中的 VM
Azure 受控磁碟 目標區域 目標訂用帳戶 連結至 Azure VM 的受控磁碟
網路介面卡 目標區域 目標訂用帳戶 連結至在 Azure 中建立之 VM 的 NIC

需要的權限

第一次開始複寫時，必須為登入的使用者指派下列角色：

  • Azure Migrate 專案資源群組和目標資源群組的擁有者或參與者和使用者存取管理員

針對後續複寫，必須為登入的使用者指派下列角色：

  • Azure Migrate 專案資源群組和目標資源群組的擁有者或參與者

除了上述角色以外，登入的使用者還需具備訂用帳戶層級的下列權限 - Microsoft.Resources/subscriptions/resourceGroups/read

資料完整性

每個複寫週期都有兩個階段，可確保內部部署磁碟 (來源磁碟) 與 Azure 中的複本磁碟 (目標磁碟) 之間的資料完整性。

  1. 首先，我們會驗證每個在來源磁碟中有所變更的磁區是否已複寫到目標磁碟。 驗證使用點陣圖來執行。 來源磁碟會分割成 512 位元組的磁區。 來源磁碟中的每個磁區分別對應於點陣圖中的一個位元。 資料複寫開始時，會為來源磁碟中需要複寫的所有變更區塊 (在差異週期中) 建立點陣圖。 同樣地，當資料傳輸至目標 Azure 磁碟時，也會建立點陣圖。 資料傳輸順利完成後，雲端服務會比較這兩個點陣圖，以確定未遺漏任何已變更的區塊。 如果點陣圖之間有任何不符之處，就會將週期視為失敗。 由於每個週期都會重新同步處理，因此下一個週期就會修正不相符的狀況。

  2. 接下來，我們會確定傳輸至 Azure 磁碟的資料與複寫自來源磁碟的資料相同。 上傳的每個變更區塊都會經過壓縮和加密，再寫入作為記錄儲存體帳戶中的 Blob。 我們會在壓縮之前計算此區塊的總和檢查碼。 此總和檢查碼會以中繼資料的形式與壓縮的資料一起儲存。 解壓縮時，將會計算資料的總和檢查碼，並將其與來源環境中計算的總和檢查碼進行比較。 如果不相符，資料就不會寫入至 Azure 磁碟，而週期將被視為失敗。 由於每個週期都會重新同步處理，因此下一個週期就會修正不相符的狀況。

安全性

Azure Migrate 設備會在資料上傳前加以壓縮和加密。 資料會經由安全通訊通道透過 HTTPS 傳輸，並使用 TLS 1.2 或更新版本。 此外，Azure 儲存體會在將資料保存於雲端時自動加密 (待用加密)。

複寫狀態

VM 進行複寫 (資料複製) 時，會有幾個可能的狀態：

  • 初始複寫已排入佇列：VM 已排入佇列等待複寫 (或移轉)，因為可能有其他 VM 正在使用內部部署資源 (在複寫或移轉期間)。 一旦資源可供使用，就會處理此 VM。
  • 初始複寫進行中：正在排程 VM 的初始複寫。
  • 初始複寫：VM 正在進行初始複寫。 當 VM 進行初始複寫時，您無法繼續進行測試移轉和移轉。 在此階段您只能停止複寫。
  • 初始複寫 (x%)：初始複寫運作中，且進度已達 x%。
  • 差異同步：VM 可能正處於差異複寫週期，在複寫自上次複寫週期以來的其餘資料流失。
  • 正在暫停：VM 正處於作用中的差異複寫週期，且即將暫停。
  • 已暫停：複寫週期已暫停。 執行繼續複寫作業即可繼續複寫週期。
  • 繼續複寫已排入佇列：VM 已排入佇列等待繼續複寫，因為目前有其他 VM 正在使用內部部署資源。
  • 繼續複寫進行中 (x%)：VM 正在繼續進行複寫週期，且進度已達 x%。
  • 正在停止複寫：複寫清除正在進行中。 當您停止複寫時，將會刪除在複寫期間建立的中繼受控磁碟 (種子磁碟)。 深入了解。
  • 正在完成移轉：移轉清除正在進行中。 當您完成移轉時，將會刪除在複寫期間建立的中繼受控磁碟 (種子磁碟)。 深入了解。
  • –：當 VM 已成功移轉和/或您已停止複寫時，狀態會變更為 "-"。 當您停止複寫/完成移轉，且作業順利完成後，VM 就會從複寫機器清單中移除。 您可以在複寫精靈的虛擬機器索引標籤中尋找 VM。

其他狀態

  • 初始複寫失敗：無法複製 VM 的初始資料。 請依照補救指引加以解決。
  • 修復擱置中：複寫週期中發生問題。 您可以選取連結，以了解可能的原因和補救動作 (如果適用)。 如果您在觸發 VM 的複寫時選取 [是] 而選擇了 [自動修復複寫]，則此工具會嘗試為您修復。 否則，請選取 VM，然後選取 [修復複寫]。 如果您先前未選擇 [自動修復複寫]，或上述步驟不適用於您，請停止虛擬機器的複寫、重設虛擬機器上的變更區塊追蹤，然後重新設定複寫。
  • 修復複寫已排入佇列：VM 已排入佇列以進行複寫修復，因為有其他 VM 正在使用內部部署資源。 一旦資源可供使用，就會處理 VM 以進行修復複寫。
  • 重新同步 (x%)：VM 正在進行資料重新同步處理。 如果在資料複寫期間發生問題/不符的狀況，就可能出現此狀態。
  • 停止複寫/完成移轉失敗：選取連結以了解失敗的可能原因和補救動作 (如果適用)。

注意

某些 VM 會進入已排入佇列狀態，以確保能盡量避免因儲存體 IOPS 使用量而對來源環境造成影響。 這些 VM 會根據下一節所說明的排程邏輯進行處理。

移轉/測試移轉狀態

  • 測試移轉擱置中：VM 處於差異複寫階段，此時您可以執行測試移轉 (或移轉)。
  • 測試移轉清除擱置中：測試移轉完成之後，請執行測試移轉清除，以避免產生 Azure 的費用。
  • 移轉準備就緒：VM 已準備好要移轉至 Azure。
  • 進行中的移轉已排入佇列：VM 已排入佇列等待移轉，因為可能有其他 VM 正在使用內部部署資源 (在複寫或移轉期間)。 一旦資源可供使用，就會處理 VM。
  • 測試移轉/移轉進行中：VM 正在進行測試移轉/移轉。 您可以選取連結以查看進行中的移轉作業。
  • 日期、時間戳記：移轉/測試移轉的日期和時間戳記。
  • –：初始複寫進行中。 在複寫程序轉換至差異同步 (累加複寫) 階段後，您可以執行移轉或測試移轉。

其他狀態

  • 已完成並產生資訊：移轉/測試移轉作業已完成，並產生資訊。 您可以選取連結，以查看最後一個移轉作業的可能原因和補救動作 (如果適用)。
  • 失敗：移轉/測試移轉作業失敗。 您可以選取連結，以查看最後一個移轉作業的可能原因和補救動作。

排程邏輯

為 VM 設定複寫時，會排程初始複寫。 隨後則是累加複寫 (差異複寫)。

差異複寫週期的排程如下：

  • 第一個差異複寫週期的排程會緊接在初始複寫週期完成後
  • 下一個差異複寫週期會根據下列邏輯來排程：min[max[1 hour, (Previous delta replication cycle time/2)], 12 hours]

也就是說，下一次差異複寫將安排在不早於 1 小時且不晚於 12 小時的時間。 例如，如果 VM 進行差異複寫週期需要四小時，則下一個差異複寫週期會排程於兩小時後，而不是一小時後。

注意

初始複寫完成後，排程邏輯會有所不同。 第一個差異週期的排程會緊接在初始複寫完成之後，而後續週期將依循前述的排程邏輯。

  • 當您觸發移轉時，在移轉之前，將會對 VM 執行隨需差異複寫週期 (容錯移轉前的差異複寫週期)。

VM 複寫在不同階段的優先順序

  • 進行中的 VM 複寫優先順序高於排程的複寫 (新的複寫)
  • 容錯移轉前 (隨需差異複寫) 週期具有最高優先順序，其次是初始複寫週期。 差異複寫週期的優先順序最低。

也就是說，每當觸發移轉作業時，就會排程 VM 的隨需複寫週期，這時其他進行中的複寫若爭用資源，將會遭到延後。

條件約束：

我們使用下列條件約束，確保不會超過 SAN 的 IOPS 限制。

  • 每個 Azure Migrate 設備支援平行複寫 52 個磁碟
  • 每個 ESXi 主機支援 8 個磁碟。 每個 ESXi 主機各有 32 MB 的 NFC 緩衝區。 因此，我們可以在主機上安排 8 個磁碟 (每個磁碟使用 4 MB 的緩衝區進行 IR 或 DR)。
  • 每個資料存放區最多可以有 15 個磁碟快照集。 唯一的例外，是 VM 已連結了超過 15 個磁碟時。

擴增複寫

Azure Migrate 支援 500 個虛擬機器的並行複寫。 如果您打算複寫超過 300 個虛擬機器，就必須部署擴增設備。 擴增設備類似於 Azure Migrate 主要設備，但僅包含閘道代理程式以利將資料傳輸至 Azure。 下圖顯示使用擴增設備的建議方式。

向外延展設定。

您可以在設定主要設備之後隨時部署擴增設備，但若非有 300 個 VM 要同時複寫，就無此必要。 有 300 個 VM 要同時複寫時，就必須部署擴增設備才行。

停止複寫/完成移轉

當您停止複寫時，將會刪除在複寫期間建立的中繼受控磁碟 (種子磁碟)。 您只能在作用中的複寫期間停止複寫。 您可以選取 [完成移轉]，以在 VM 移轉之後停止複寫。

停止複寫的 VM，可再次啟用複寫以進行複寫。 如果 VM 已移轉，則可以再繼續複寫和移轉。

最佳做法是，您應一律在 VM 成功移轉至 Azure 之後完成移轉，以確保中繼受控磁碟 (種子磁碟) 上的儲存體交易不會產生額外費用。 在某些情況下，您會發現停止複寫需要一些時間。 這是因為每當停止複寫時，進行中的複寫週期都會在刪除成品之前完成 (只有在 VM 處於差異同步狀態時)。

流失的影響

在排程下一個週期之前，我們會讓資料盡可能折疊，使每個複寫週期中的資料傳輸量降到最低。 由於無代理程式複寫會摺疊資料，因此流失模式會比流失率更重要。 反覆寫入檔案時，流失率不會有太大的影響。 不過，間隔寫入磁區的模式，會導致下一個週期出現高流失率。

複寫管理

節流

您可以使用 NetQosPolicy 來增加或減少複寫頻寬。在 NetQosPolicy 中要使用的 AppNamePrefix 為 "GatewayWindowsService.exe"。

您可以在 Azure Migrate 設備上建立如下原則，藉以節流來自該設備的複寫流量：

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

注意

這適用於從 Azure Migrate 設備同時進行複寫的所有 VM。

您也可以使用範例指令碼，根據排程來增加和減少複寫頻寬。

停止運作時段

Azure Migrate 提供以設定為基礎的機制，讓客戶可據以指定一段暫停進行任何複寫的時間間隔。 此時間間隔稱為停止運作時段。 在許多情況下都可能產生停止運作時段的需求，例如，當來源環境的資源有限，或客戶希望僅在非上班時間進行複寫等等。

注意

  • 停止運作時段開始時，會先完成現有複寫週期，複寫才會暫停。
  • 對於在停止運作時段起始的任何移轉，最終複寫將不會執行，移轉將因而失敗。

您可以在 C:\ProgramData\Microsoft Azure\Config 中建立/更新 GatewayDataWorker.json 檔案，藉以為設備指定停止運作時段。一般檔案的格式如下：

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

停止運作時段清單是以 "|" 分隔的字串，採用 "DayOfWeek;StartTime;Duration" 的格式。 持續時間可用日、小時和分鐘為單位來指定。 例如，停止運作時段可以指定為：

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

上述範例中的第一個值，表示在當地時間每週一早上 7:00 (設備上的時間) 開始、持續 7 小時的停止運作時段。

使用這些內容建立/更新 GatewayDataWorker.json 之後，必須重新啟動設備上的閘道服務，這些變更才會生效。

在擴增案例中，主要設備與擴增設備各有本身的停止運作時段。 最佳做法是，我們建議各設備保有一致的時段。

下一步

使用無代理程式移轉來移轉 VMware VM。