移轉和現代化：常見問題

本文將回答有關移轉和現代化工具的常見問題。 如果您有其他問題，請參閱下列資源：

• 關於 Azure Migrate 的一般問題
• Azure Migrate 設備的相關問題
• 探索、評估和相依性視覺效果的相關問題
• 在 Azure Migrate 論壇 得到問題的解答

警告

本文參考 CentOS，這是處於終止服務 (EOL) 狀態的 Linux 發行版。 請據此考慮您的使用方式和規劃。 如需詳細資訊，請參閱 CentOS 生命週期結束指導。

一般問題

移轉和現代化中的移轉選項為何？

移轉和現代化工具提供兩個選項，可將來源伺服器和虛擬機器移轉至 Azure：無代理程式移轉和代理程式型移轉。

不論選擇的移轉選項為何，使用移轉和現代化工具移轉伺服器的第一個步驟是啟動對伺服器的複寫。 這會執行 VM/伺服器資料至 Azure 的初始複寫。 完成初始複寫之後，會建立進行中的複寫 (進行中的差異同步)，以將增量資料移轉至 Azure。 一旦作業到達差異同步階段，您便可以選擇隨時移轉至 Azure。

以下是在決定移轉選項時要記住的一些考量。

無代理程式移轉不需要任何軟體 (代理程式) 部署在要移轉的來源 VM/伺服器上。 無代理程式選項會整合虛擬化提供者所提供的功能來協調複寫。 無代理程式複寫選項適用於 VMware VM 和 Hyper-V VM。

代理程式型移轉需要 Azure Migrate 軟體 (代理程式) 安裝在要移轉的來源 VM/機器上。 代理程式型選項不會依賴虛擬化平台來進行複寫功能。 因此，該選項可與執行 x86/x64 架構和代理程式型複寫方法所支援作業系統版本的任何伺服器搭配使用。

代理程式型移轉選項可用於 VMware VM、Hyper-V VM、實體伺服器、在 AWS 上執行的 VM、在 GCP 上執行的 VM，或在不同虛擬化提供者上執行的 VM。 代理程式型移轉會將您的機器視為實體伺服器以進行移轉。

雖然無代理程式移轉針對支援的案例 (VMware 和 Hyper-V) 提供比代理程式型複寫選項方便且簡單的方式，但您可以考慮針對下列使用案例使用代理程式型案例：

• IOPS 限制的環境：無代理程式複寫會使用快照集，並取用儲存體 IOPS/頻寬。 如果您的環境中儲存體/IOPS 有條件約束，建議您使用代理程式型移轉方法。
• 如果您沒有 vCenter Server，則可以將 VMware VM 視為實體伺服器，並使用代理程式型移轉工作流程。

若要深入了解，請檢閱本文以比較 VMware 移轉的移轉選項。

Azure Migrate 支援哪些地理位置進行移轉？

請檢閱公用和政府雲端支援的地理位置。

我可以使用相同的 Azure Migrate 專案來移轉至多個區域嗎？

雖然您可以在 Azure Migrate 專案中建立多個區域的評量，但一個 Azure Migrate 專案只能用來將伺服器移轉至一個 Azure 區域。 您可以為每個需要移轉的區域建立額外的 Azure Migrate 專案。

• 針對無代理程式 VMware 移轉，一旦您啟用第一個複寫，目的地區域就會鎖定。
• 若為代理程式型移轉 (VMware、實體伺服器，以及來自其他雲端的伺服器)，當設定複寫設備時，在入口網站上選取 [建立資源] 按鈕後，就會鎖定目的地區域。
• 針對無代理程式 Hyper-V 移轉，當設定 Hyper-V 複寫提供者時，在入口網站上選取 [建立資源] 按鈕後，就會鎖定目的地區域。

我可以使用相同的 Azure Migrate 專案來移轉至多個訂用帳戶嗎？

是的，您可以使用 Azure Migrate 專案，移轉至相同目的地區域中的多個訂用帳戶 (相同的 Azure 租用戶)。 您可以在啟用一台機器或一組機器的複寫時選取目標訂用帳戶。 目的地區域會針對無代理程式 VMware 移轉在第一次複寫後鎖定，針對代理程式型移轉在複寫設備期間鎖定，以及針對無代理程式 Hyper-V 移轉在 Hyper-V 提供者安裝期間鎖定。

Azure Migrate 是否支援 Azure Resource Graph？

目前，Azure Migrate 並未與 Azure Resource Graph 整合。 它確實支援執行 ARG 相關的查詢。

如何將資料從內部部署環境傳輸到 Azure？ 是否在傳輸之前加密？

無代理程式複寫案例中的 Azure Migrate 設備會在上傳之前壓縮資料並加密。 資料會使用 https 透過安全通道傳輸，並使用 TLS 1.2 或更新版本。 此外，Azure 儲存體會在將資料保存於雲端時自動加密 (待用加密)。

我可以使用 Azure Migrate 針對災害復原案例所建立的復原服務保存庫嗎？

不建議使用 Azure Migrate 針對災害復原案例所建立的復原服務保存庫。 這樣做可能會導致 Azure Migrate 中的開始複寫失敗。

測試移轉和移轉作業之間的差異為何？

測試移轉提供在實際移轉之前測試及驗證移轉的方法。 測試移轉的運作方式是讓您在實際移轉之前，使用 Azure 中的沙箱環境來測試虛擬機器。 沙箱環境是由您指定的測試虛擬網路所區分。 測試移轉作業非干擾性，前提是測試 VNet 已充分地隔離。 此處的隔離 VNet 表示輸入和輸出連線規則是設計來避免不必要的連線。 例如，內部部署機器的連線受到限制。

應用程式可以在來源繼續執行，同時讓您在隔離沙箱環境中對複製的複本執行測試。 您可以視需要執行多個測試，以驗證移轉、執行應用程式測試，並在實際移轉之前解決任何問題。

Azure Migrate 是否有復原選項？

您可以使用 [測試移轉] 選項來驗證 Azure 中的應用程式功能和效能。 您可以執行任意數目的測試移轉，並在透過測試移轉作業建立信賴度之後執行最終移轉。 測試移轉不會影響內部部署機器，該機器會維持運作狀態並繼續複寫，直到您執行實際的移轉為止。 如果在測試移轉 UAT 期間發生任何錯誤，您可以選擇延後最終移轉，並將來源 VM/伺服器保持執行並複寫至 Azure。 解決錯誤後，您可以重新嘗試最終移轉。 注意：當您執行最終移轉至 Azure 且內部部署來源機器已關閉之後，就無法執行從 Azure 復原至內部部署環境。

我可以選取要用於測試移轉的虛擬網路和子網路嗎？

您可以選取要用於測試移轉的虛擬網路。 系統會根據下列邏輯自動選取子網路：

• 如果在啟用複寫時將 (預設以外的) 目標子網路指定為輸入，則 Azure Migrate 會在針對測試移轉選取的虛擬網路中，使用具有相同名稱的子網路來設定優先順序。
• 如果找不到具有相同名稱的子網路，則 Azure Migrate 會依字母順序選取不是閘道/應用程式閘道/防火牆/堡壘主機子網路的第一個可用子網路。

為什麼我的伺服器停用 [測試移轉] 按鈕？

在下列案例中，測試移轉按鈕可能處於停用狀態：

• 在 VM 完成初始複寫 (IR) 之前，您無法開始測試移轉。 測試移轉按鈕將會停用，直到 IR 流程完成為止。 一旦 VM 處於差異同步階段，您就可以執行測試移轉。
• 如果測試移轉已完成，但未針對該 VM 執行測試移轉清除，則可以停用按鈕。 請執行測試移轉清除，然後重試作業。

如果我未清除測試移轉，會發生什麼事？

測試移轉會使用複寫的資料建立測試 Azure VM 來模擬實際移轉。 伺服器將會以複寫資料的時間點複本部署到目標資源群組 (在啟用複寫時選取)，尾碼為「-test」。 測試移轉的目的是要驗證服務器功能，以便將移轉後的問題降到最低。 如果測試移轉未在測試後清除，則測試虛擬機器將會繼續在 Azure 中執行，並會產生費用。 若要在測試移轉後進行清除，請移至移轉和現代化工具中的複寫機器檢視，然後在機器上使用「清除測試移轉」動作。

如何知道我的 VM 是否已成功移轉？

成功移轉 VM/伺服器之後，您可以從 [虛擬機器] 頁面檢視和管理 VM。 連線到已遷移的 VM 來進行驗證。 或者，您可以檢閱作業的「作業狀態」，以檢查移轉是否已順利完成。 如果您看到任何錯誤，請加以解決，然後重試移轉作業。

如果我在移轉後未停止複寫，會發生什麼事？

當您停止複寫時，移轉和現代化工具會清除為複寫建立的訂用帳戶中的受控磁碟。

如果我在移轉之後未完成移轉，會發生什麼事？

當您完成移轉時，移轉和現代化工具會清除為複寫建立的訂用帳戶中的受控磁碟。 如果您在移轉之後未選取 [完成移轉]，您將會繼續產生這些磁碟的費用。 完整移轉不會影響已移轉至機器的磁碟。

如何將 UEFI 型機器移轉至 Azure 作為 Azure 第 1 代 VM？

移轉和現代化工具會將 UEFI 型機器移轉至 Azure 作為 Azure 第 2 代 VM。 如果您想要將其移轉至 Azure 第 1 代 VM，請先將開機類型轉換為 BIOS，再開始複寫，然後使用 移轉和現代化工具來移轉至 Azure。

Azure Migrate 會將 UEFI 型機器轉換為 BIOS 型機器，並將其移轉至 Azure 作為 Azure 第 1 代 VM 嗎？

移轉和現代化工具會將所有 UEFI 型機器移轉至 Azure 作為 Azure 第 2 代 VM。 我們不再支援將 UEFI 型 VM 轉換為 BIOS 型 VM。 所有 BIOS 型機器只會移轉至 Azure 第 1 代 VM。

哪些作業系統支援將 UEFI 型機器移轉至 Azure？

注意

如果無代理程式移轉支援操作系統的主要版本，則會自動支援所有次要版本和核心。

UEFI 型機器支援的作業系統	無代理程式 VMware 至 Azure	無代理程式 Hyper-V 至 Azure	代理程式型 VMware、實體和其他雲端至 Azure
Windows Server 2022、2019、2016、2012 R2、2012	Y	Y	Y
Windows 10 專業版、Windows 10 企業版	Y	Y	Y
SUSE Linux Enterprise Server 15 SP1， SP2， SP3， SP4， SP5， SP6	Y	Y	Y
SUSE Linux Enterprise Server 12 SP4	Y	Y	Y
Ubuntu Server 16.04、18.04、19.04、19.10	Y	Y	Y
RHEL 9.x、8.1、8.0、7.8、7.7、7.6、7.5、7.4、7.0、6.x	Y	Y	Y
CentOS 資料流	Y	Y	Y
Oracle Linux 7.7、7.7-CI	Y	Y	Y

是否可以使用 Azure Migrate 移轉 Active Directory 網域控制站？

移轉和現代化工具與應用程式無關，適用於大部分的應用程式。 當您使用移轉和現代化工具來移轉伺服器時，伺服器上安裝的所有應用程式都會隨其一起移轉。 不過，對於某些應用程式，移轉和現代化以外的替代移轉方法可能更適合移轉。 針對 Active Directory，如果內部部署網站連線到 Azure 環境的混合式環境，您可以藉由在 Azure 中新增額外的網域控制站並設定 Active Directory 複寫，將目錄延伸至 Azure。 如果您要移轉至 Azure 中的隔離環境，而該環境需要自己的網域控制站 (或在沙箱環境中測試應用程式)，您可以使用移轉和現代化工具來移轉伺服器。

是否可以在移轉時升級我的 OS？

移轉和現代化工具現在支援在移轉期間的 Windows 作業系統升級。 Linux 目前無法使用此選項。 Windows 作業系統升級的其他詳細資料。

我需要 VMware vCenter 才能移轉 VMware VM 嗎？

若要使用 VMware 代理程式型或無代理程式移轉來移轉 VMware VM，VM 所在的 ESXi 主機必須由 vCenter Server 管理。 如果您沒有 vCenter Server，可以將 VMware VM 移轉作為實體伺服器來移轉。 深入了解。

是否可以在移轉時將多個來源 VM 合併成一個 VM？

移轉和現代化功能目前支援同等條件移轉。 我們不支援合併伺服器作為移轉的一部分。

移轉之後，Azure 是否會支援 Windows Server 2008 和 2008 R2？

您可以將內部部署 Windows Server 2008 和 2008 R2 伺服器移轉至 Azure 虛擬機器，並在終止支援日期之後取得 3 年的延伸安全性更新，且不會在執行虛擬機器的成本外增加額外費用。 您可以使用移轉和現代化工具來移轉 Windows Server 2008 和 2008 R2 工作負載。

如何將 VMware/Hyper-V 上執行的 Windows Server 2003 移轉至 Azure？

Windows Server 2003 延伸支援已於 2015 年 7 月 14 日終止。 Azure 支援小組會繼續協助針對在 Azure 上執行 Windows Server 2003 的問題進行疑難排解。 不過，這項支援僅限於不需要 OS 層級疑難排解或修補程式的問題。 建議將應用程式移轉至執行較新版本 Windows Server 的 Azure 執行個體，以確保您能有效地使用 Azure 雲端的彈性和可靠性。

不過，如果您選擇將 Windows Server 2003 移轉至 Azure，則可以使用移轉和現代化工具。如果您的 Windows Server 是 VMware 或 Hyper-V 上執行的 VM，請檢閱本文以準備 Windows Server 2003 機器以進行移轉。

無代理程式的 VMware 移轉

無代理程式的移轉如何運作？

移轉和現代化工具提供無代理程式複寫選項，可用於移轉執行 Windows 或 Linux 的 VMware 虛擬機器和 Hyper-V 虛擬機器。 此工具也為 Windows 和 Linux 伺服器提供另一個代理程式型的複寫選項，可用來移轉實體伺服器，以及 VMware、Hyper-V、AWS、GCP 等上的 x86/x64 虛擬機器。代理程式型的複寫選項需要在要移轉的伺服器/虛擬機器上安裝代理程式軟體，而在無代理程式選項中，不需要在虛擬機器本身上安裝任何軟體，因此比代理程式型的複寫選項提供了更多的便利性和簡單性。

無代理程式複寫選項的運作方式是使用虛擬化提供者 (VMware、Hyper-V) 所提供的機制。 在 VMware 虛擬機器的情況下，無代理程式複寫機制會使用 VMware 快照集和 VMware 變更的區塊追蹤技術，從虛擬機器磁碟複寫資料。 這項機制類似許多備份產品所使用的機制。 在 Hyper-V 虛擬機器的情況下，無代理程式複寫機制會使用 VM 快照集和 Hyper-V 複本的變更追蹤功能，從虛擬機器磁碟複寫資料。

針對虛擬機器設定複寫時，會先進行初始複寫階段。 在初始複寫期間，系統會建立 VM 快照集，而快照集磁碟中的完整資料複本會複寫到訂用帳戶中的受控磁碟。 VM 的初始複寫完成之後，複寫流程會轉換為累加複寫 (差異複寫) 階段。 在累加複寫階段中，自上次完成的複寫週期以來發生的資料變更會定期複寫並套用至複本受控磁碟，藉此讓複寫與 VM 上發生的變更保持同步。 在 VMware 虛擬機器的情況下，VMware 變更的區塊追蹤技術可用來追蹤複寫週期之間的變更。 複寫週期開始時，會建立 VM 快照集，並使用變更區塊追蹤來取得目前的快照集與上次成功複寫的快照集之間的變更。 這樣，只需要複寫自上次完成的複寫週期以來已變更的資料，以保持 VM 的複寫同步。在每個複寫週期結束時，會釋放快照集，並對虛擬機器執行快照集合併。 同樣地，在 Hyper-V 虛擬機器的情況下，Hyper-V 複本變更追蹤引擎是用來追蹤連續複寫週期之間的變更。

當您在複寫虛擬機器上執行移轉作業時，您可以選擇關閉內部部署虛擬機器，並執行最後一次的累加複寫，以確保不會遺失資料。 在執行移轉時，對應至虛擬機器的複本受控磁碟會用來在 Azure 中建立虛擬機器。

若要開始使用，請參閱 VMware 無代理程式移轉和 Hyper-V 無代理程式移轉教學課程。

如何量測移轉的頻寬需求？

將資料複寫至 Azure 的頻寬取決於各種因素，以及內部部署 Azure Migrate 設備讀取和複寫資料至 Azure 的速度。 複寫有兩個階段：初始複寫和差異複寫。

當 VM 複寫開始時，就會發生初始複寫週期，該週期中會複寫磁碟的完整複本。 完成初始複寫之後，累加複寫週期 (差異週期) 會定期排程，以傳輸自上一個複寫週期以來發生的任何變更。

您可以根據在波中移動所需的資料量，找出頻寬需求和您希望初始複寫完成的時間 (最好在實際移轉時間範圍之前至少 3-4 天完成初始複寫，以便您有足夠的時間在實際時間範圍之前執行測試移轉，並將停機時間保持在最低)。

您可以使用下列公式來估計無代理程式 VMware VM 移轉所需的頻寬或時間：

完成初始複寫的時間 = {磁碟大小 (或使用的大小，如果適用) * 0.7 (假設有 30% 的壓縮平均 – 保守估計)}/可用於複寫的頻寬。

如何使用 Azure Migrate 設備進行無代理程式 VMware 複寫的節流複寫？

您可以使用 NetQosPolicy 進行節流。 請注意，此節流僅適用於來自 Azure Migrate 設備的輸出連線。 例如：

在 NetQosPolicy 中使用的 AppNamePrefix 為 「GatewayWindowsService.exe」。 您可以在 Azure Migrate 設備上建立原則，並藉由建立如下的原則以節流來自設備的複寫流量：

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

若要根據排程增加和減少複寫頻寬，您可以利用 Windows 排程工作視需要調整頻寬。 一個工作將用來減少頻寬，另一個工作將用來增加頻寬。 注意：您必須在執行下列命令之前，先建立如上所述的 NetQosPolicy。

#Replace with an account part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) will be used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the Scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

流失率如何影響無代理程式複寫？

因為無代理程式複寫會在資料中摺疊，所以流失模式比流失率更重要。 反覆寫入檔案時，流失率不會有太大的影響。 不過，寫入其他磁區的模式會在下一個週期中造成高流失。 由於我們將傳輸的資料量降至最低，因此在排程下一個週期之前，我們允許資料盡可能摺疊。

複寫週期排程的頻率如何？

排程下一個複寫週期的公式 (先前的週期時間/2) 或一小時，無論時間較高。

例如，如果 VM 需要四小時的時間進行差異迴圈，則下一個週期會排程為兩小時後，而不是在下一小時。 當第一個差異週期立即排程時，此流程會在初始複寫之後立即不同。

我部署了兩個 (或更多) 設備，以探索 vCenter Server 中的 VM。 然而，當我嘗試移轉 VM 時，只看到對應至其中一個 VM 的伺服器。

如果已設定多個設備，則在提供的 vCenter 帳戶中的多個 VM 之間不可以有重疊的情況。 若有這類重疊，則不支援探索。

無代理程式複寫如何影響 VMware 伺服器？

無代理程式複寫會對 VMware vCenter Server 和 VMware ESXi 主機造成一些效能影響。 因為無代理程式複寫使用快照集，所以會在儲存體上使用 IOPS，因此需要一些 IOPS 儲存體頻寬。 如果您的環境中有儲存體或 IOP 限制，則不建議使用無代理程式複寫。

我可以使用 Azure Migrate 將 Web 應用程式移轉至 Azure App 服務嗎？

您可以在 ASP.NET Web 應用程式進行大規模無代理程式移轉，該應用程式在 VMware 環境中裝載於 Windows OS 的 IIS Web 服務器上執行。 深入了解。

代理程式型移轉

如何將 AWS EC2 執行個體移轉至 Azure？

請檢閱文章，以探索、評估並將 AWS EC2 執行個體移轉至 Azure。

代理程式型移轉如何運作？

除了 VMware 虛擬機器和 Hyper-V 虛擬機器的無代理程式移轉選項之外，移轉和現代化工具還提供代理程式型移轉選項，可移轉在實體伺服器上執行或在 VMware、Hyper-V、AWS、Google Cloud Platform 上執行為 x86/x64 虛擬機器的 Windows 和 Linux 伺服器。

代理程式型移轉方法會使用安裝在要移轉伺服器上的代理程式軟體，將伺服器資料複寫至 Azure。 複寫流程會使用卸載架構，代理程式會在該架構中將複寫資料轉送至稱為複寫設備或組態伺服器 (或向外延展處理序伺服器) 的專用複寫伺服器。 深入了解代理程式型移轉選項的運作方式。

注意：複寫設備與 Azure Migrate 探索設備不同，且必須安裝在個別/專用機器上。

應該在哪裡安裝代理程式型移轉的複寫設備？

複寫設備應該安裝在專用機器上。 複寫設備不應該安裝在您想要複寫的來源機器上，也不應該安裝在您先前已安裝的 Azure Migrate 設備 (用於探索和評估) 上。 如需詳細資訊，請參閱教學課程。

我可以移轉執行 Amazon Linux 作業系統的 AWS VM 嗎？

執行 Amazon Linux 的 VM 無法依原樣移轉，因為只有 AWS 支援 Amazon Linux OS。 若要遷移在 Amazon Linux 上執行的工作負載，您可以在 Azure 中啟動 CentOS/RHEL VM，並使用相關的工作負載移轉方法，遷移在 AWS Linux 電腦上執行的工作負載。 例如，視工作負載而定，可能有工作負載專屬的工具可協助移轉，例如適用於 Web 伺服器的資料庫或部署工具。

如何量測移轉的頻寬需求？

將資料複寫至 Azure 的頻寬取決於各種因素，以及內部部署 Azure Migrate 設備讀取和複寫資料至 Azure 的速度。 複寫有兩個階段：初始複寫和差異複寫。

當 VM 複寫開始時，就會發生初始複寫週期，該週期中會複寫磁碟的完整複本。 完成初始複寫之後，累加複寫週期 (差異週期) 會定期排程，以傳輸自上一個複寫週期以來發生的任何變更。

針對代理程式型複寫方法，部署規劃工具可協助分析資料變換的環境，並協助預測必要的頻寬需求。 若要深入了解，請參閱這篇文章

無代理程式的 Hyper-V 移轉

無代理程式的移轉如何運作？

移轉和現代化工具提供無代理程式複寫選項，可用於移轉執行 Windows 或 Linux 的 VMware 虛擬機器和 Hyper-V 虛擬機器。 此工具也為 Windows 和 Linux 伺服器提供額外的代理程式型的複寫選項，可用來移轉實體伺服器，以及 VMware、Hyper-V、AWS、GCP 等上的 x86/x64 虛擬機器。代理程式型的複寫選項需要在要移轉的伺服器/虛擬機器上安裝代理程式軟體，而在無代理程式選項中，不需要在虛擬機器本身上安裝任何軟體，因此比代理程式型的複寫選項提供了額外的便利性和簡單性。

無代理程式複寫選項的運作方式是使用虛擬化提供者 (VMware、Hyper-V) 所提供的機制。 在 Hyper-V 虛擬機器的情況下，無代理程式複寫機制會使用 VM 快照集和 Hyper-V 複本的變更追蹤功能，從虛擬機器磁碟複寫資料。

針對虛擬機器設定複寫時，會先進行初始複寫階段。 在初始複寫期間，系統會建立 VM 快照集，而快照集磁碟中的完整資料複本會複寫到訂用帳戶中的受控磁碟。 VM 的初始複寫完成之後，複寫流程會轉換為累加複寫 (差異複寫) 階段。 在累加複寫階段中，自上次完成的複寫週期以來發生的資料變更會定期複寫並套用至複本受控磁碟，藉此讓複寫與 VM 上發生的變更保持同步。 在 VMware 虛擬機器的情況下，VMware 變更的區塊追蹤技術可用來追蹤複寫週期之間的變更。 複寫週期開始時，會建立 VM 快照集，並使用變更區塊追蹤來取得目前的快照集與上次成功複寫的快照集之間的變更。 這樣，只需要複寫自上次完成的複寫週期以來已變更的資料，以保持 VM 的複寫同步。在每個複寫週期結束時，會釋放快照集，並對虛擬機器執行快照集合併。 同樣地，在 Hyper-V 虛擬機器的情況下，Hyper-V 複本變更追蹤引擎是用來追蹤連續複寫週期之間的變更。

當您在複寫虛擬機器上執行移轉作業時，您可以選擇關閉內部部署虛擬機器，並執行最後一次的累加複寫，以確保不會遺失資料。 在執行移轉時，對應至虛擬機器的複本受控磁碟會用來在 Azure 中建立虛擬機器。

若要開始使用，請參閱 Hyper-V 無代理程式移轉教學課程。

如何量測移轉的頻寬需求？

將資料複寫至 Azure 的頻寬取決於各種因素，以及內部部署 Azure Migrate 設備讀取和複寫資料至 Azure 的速度。 複寫有兩個階段：初始複寫和差異複寫。

當 VM 複寫開始時，就會發生初始複寫週期，該週期中會複寫磁碟的完整複本。 完成初始複寫之後，累加複寫週期 (差異週期) 會定期排程，以傳輸自上一個複寫週期以來發生的任何變更。

您可以根據在波中移動所需的資料量，找出頻寬需求和您希望初始複寫完成的時間 (最好在實際移轉時間範圍之前至少 3-4 天完成初始複寫，以便您有足夠的時間在實際時間範圍之前執行測試移轉，並將停機時間保持在最低)。

下一步

深入了解如何移轉 VMware VM、Hyper-V VM 和實體伺服器。