評量 - 常見問題

本文會提供 Azure Migrate 中關於評量的常見問題之解答。 如果您有其他問題，請參閱下列資源：

• 關於 Azure Migrate 的一般問題
• Azure Migrate 設備的相關問題
• 關於移轉和現代化的問題
• 在 Azure Migrate 論壇 得到問題的解答

Azure Migrate 的探索和評量支援哪些地理位置？

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

我可以使用設備來探索多少部伺服器？

您可以從 VMware 環境探索最多 10,000 部伺服器、Hyper-V 環境最多 5,000 部伺服器，以及最多 1,000 部實體伺服器。 如果您擁有更多伺服器，請閱讀 調整 Hyper-V 評量、調整 VMware 評量 或 調整實體伺服器評量。

如何選擇評量類型?

• 若要從內部部署 VMware 與 Hyper-V 環境以及實體伺服器評估伺服器以移轉至 Azure VM，請使用 Azure VM 評量。 深入了解。
• 當您想要在 VMware、Microsoft Hyper-V 和實體/裸機環境中評估內部部署 SQL Server，以及 AWS、GCP 等其他公用雲端的 IaaS 伺服器，以便移轉至 Azure VM 或 Azure SQL Database 或 Azure SQL 受控執行個體上的 SQL Server 時，請使用評量類型 Azure SQL。 深入了解。
• 當您想要從 VMware 環境評估在 IIS Web 服務器上執行的內部部署 ASP.NET Web 應用程式，以移轉至Azure App Service 時，請使用評量類型 Azure App Service。 深入了解。
• 若要使用此評量類型來評估內部部署 VMware VM 以移轉至 Azure VMware 解決方案 (AVS)，請使用 Azure VMware 解決方案 (AVS) 評量。 深入了解。
• 您只能使用與 VMware 機器相同的通用群組來執行這兩種類型的評量。 如果您是第一次在 Azure Migrate 中執行 AVS 評量，建議您建立新的 VMware 機器群組。

為什麼我的 Azure VM 和/或 AVS 評量報告中遺失某些/所有伺服器的效能資料？

針對「以效能為基礎的」評估，當 Azure Migrate 設備無法收集內部部署伺服器的效能數據時，評量報告導出會顯示 「PercentageOfCoresUtilizedMissing」 或 “PercentageOfMemoryUtilizedMissing”。 您可以檢查 Azure Migrate 中樞頁面上的 [解決問題 ] 索引標籤以取得詳細問題，或手動檢查下列問題：

• 伺服器在您建立評量的持續時間內是否開啟電源

• 如果只有記憶體計數器遺失，而且您嘗試評估 Hyper-V 環境中的伺服器。 在此案例中，請在伺服器上啟用動態記憶體，並「重新計算」評量以反映最新的變更。 只有當伺服器已啟用動態記憶體時，設備才能收集 Hyper-V 環境中的伺服器記憶體使用率值。

• 如果遺失了所有效能計數器，請確定您已允許連接埠 443 上的輸出連線 (HTTPS)。

  注意

  如果遺失任何效能計數器，Azure Migrate：伺服器評量會回復為已配置的內部部署核心/記憶體，並據此建議 VM 大小。

如何了解造成效能資料收集問題的錯誤詳細資料?

現在，您明白自己需要補救哪些錯誤，才能解決 Azure VM 和 Azure VMware 解決方案評量中的效能資料收集問題。 執行下列步驟:

• 移至 [Azure Migrate >伺服器、資料庫和 Web 應用程式>移轉目標]，在 [探索和評量工具] 上選取 [解決問題]。
• 選取評量旁 [受影響的物件]，然後選取錯誤識別碼資料行中的連結，以檢閱錯誤詳細資料和補救動作。

當您在 [選取伺服器來評估] 步驟中或在現有評量的整備索引標籤中建立評量時，您也可以檢閱這些錯誤/問題。 如果您沒有在評定中看到任何錯誤/問題，但在 [解決問題] 索引標籤中看到非零錯誤，請重新計算評量以查看 [評定] 索引卷標內的問題。

為什麼在我的 Azure SQL 評估中，部分/所有的 SQL 執行個體/資料庫遺失效能資料？

為確保會收集效能資料，請檢查：

• SQL Server 在您建立評量的持續時間內是否開啟電源。
• 如果 Azure Migrate 中 SQL 代理程式的連線狀態為「已連線」，並檢查最後一個活動訊號。
• 如果在探索到的 SQL 實例區段中，所有 SQL 實例的 Azure Migrate 連線狀態為「已連線」。
• 如果遺失了所有效能計數器，請確定您已允許連接埠 443 上的輸出連線 (HTTPS)。

如果遺漏任何性能計數器，Azure SQL 評量會回復為[內部部署大小]，並根據內部部署所配置的核心、記憶體和資料庫大小總計來建議 Azure SQL 組態。

為什麼信賴度評等不適用於 Azure App Service 評量？

系統不會針對 Azure App Service 評量擷取效能資料，因此您不會看到此評量類型的信賴度評等。 Azure App Service 評量會在執行評量計算時，考慮 Web 應用程式的設定資料。

為何我的評量信賴評等偏低？

系統會根據計算評量所需的可用資料點百分比，為「以效能為基礎的」評量計算信賴評等。 以下是評量會獲得低信賴評等的原因：

• 您未針對正在建立評估的持續時間剖析環境。 例如，如果您要建立將效能持續時間設定為一週的評量，您需要至少等待一週後再開始探索，才能收集到所有資料點。 如果您無法等待該持續時間，請將效能持續時間變更為較短的期間，並重新計算評估。

• 在評量期間內，評量程序無法收集部分或所有伺服器的效能資料。 如需高信賴度評等，請確定：

  • 伺服器在評量期間內均開啟電源
  • 允許連接埠 443 上的輸出連線
  • 已針對 Hyper-V 伺服器啟用動態記憶體
  • Azure Migrate 中代理程式的連線狀態為「已連線」，並檢查最後一個活動訊號
  • 針對 Azure SQL 評量，在探索到的 SQL 執行個體區段中，所有 SQL 執行個體的 Azure Migrate 連線狀態為「已連線」。

  重新計算評量，以反映信賴評等的最新變更。

• 針對 Azure VM 和 AVS 評量，在探索啟動之後會建立少數伺服器。 例如，如果您要建立過去一個月的效能記錄評量，但是少數伺服器在一週前才建立在環境中。 在此情況下，將無法取得新的伺服器在這整段期間內的效能資料，且信賴評等將會偏低。 深入了解。

• 針對 Azure SQL 評量，在探索啟動之後，會建立幾個 SQL 實例或資料庫。 例如，如果您要建立過去一個月的效能記錄評量，但是在一週前才在環境中建立部分 SQL 執行個體或資料庫。 在此情況下，將無法取得新的伺服器在這整段期間內的效能資料，且信賴評等將會偏低。 深入了解。

為什麼我的 RAM 使用率大於 100%？

根據設計，在 Hyper-V 中，如果布建的記憶體上限小於 VM 所需的記憶體，評定會顯示記憶體使用率超過 100%。

我在評量上看到橫幅，表示評量現在也會考慮處理器參數。 重新計算評量的影響為何?

評量現在會考慮處理器參數 (例如作業核心數目、通訊端等)，並計算其在模擬環境中一段時間內的最佳效能。 這是為了基準測試所有處理器型可用的處理器資訊。 重新計算您的評量，以查看更新的建議。

在考慮資源使用率時會一起考慮處理器基準數量，以確保我們符合內部部署 VMware、Hyper-V 和實體伺服器的處理器效能，並據此建議目標 Azure SKU 大小。 這是進一步改善評量建議的方式，以更緊密地符合您的效能需求。

因此，目標 Azure VM 成本可能會與您先前對相同目標進行的評量不同。 此外，如果目標的處理器效能能與内部部署 VMware、Hyper-V 和實體伺服器相符，則目標 Azure SKU 中配置的核心數量也可能會有所不同。

對於客戶選擇「作爲內部部署」的案例，處理器基準測試是否有任何影響?

否，不會有任何影響，因為我們不會將其視為內部部署案例。

在重新計算評量之後，我會看到每月成本增加嗎？ 這是最佳化的成本嗎?

如果您在評量設定中選取 [VM 系列] 的所有可用選項，將會為您的 VM 取得最佳化的成本建議。 不過，如果您只為 VM 系列選擇一些可用的選項，建議可能會在指派 Azure VM SKU 時跳過最佳化的選項，同時符合處理器效能的數量。

為什麼我在 Azure VM 評量屬性中看不到所有 Azure VM 系列？

可能有兩個原因:

• 您已選擇不支援特定系列的 Azure 區域。 Azure VM 評量屬性中顯示的 Azure VM 系列取決於所選 Azure 位置、記憶體類型和保留實例中的 VM 系列可用性。
• 評量不支援 VM 系列，也不在評量的考慮邏輯中。 我們目前不支援 B 系列高載、加速和高效能 SKU 系列。 我們正嘗試讓 VM 系列保持更新，而提及的部分則位於我們的藍圖上。

探索和評量工具上的 Azure VM 或 AVS 評量數目不正確

若要補救此問題，請選取要瀏覽至所有評量的評量總數，然後重新計算 Azure VM 或 AVS 評量。 接著，探索和評量工具會顯示該評量類型的正確計數。

我想要試用新的 Azure SQL 評量功能

針對您 VMware、Microsoft Hyper-V 和實體/裸機環境中執行的 SQL Server 執行個體和資料庫，以及 AWS、GCP 等其他公用雲端的 IaaS 伺服器的探索和評量目前為預覽狀態。 開始使用本教學課程。 如果您想要在現有的專案中試用這項功能，請確定您已完成本文中的必要條件。

我想要試用新的 Azure App Service 評量功能

在 VMware 環境中執行的 .NET Web 應用程式探索和評量現在為預覽狀態。 開始使用本教學課程。 如果您想要在現有的專案中試用這項功能，請確定您已完成本文中的必要條件。

我在建立 Azure SQL 評估時看不到某些伺服器

• Azure SQL 評估只能在探索到 SQL 執行個體的伺服器上執行。 如果您沒有看到想要評估的伺服器和 SQL 執行個體，請等候一段時間讓探索完成，然後再建立評估。
• 如果您在建立評估時看不到先前建立的群組，請從群組中移除任何沒有 SQL 執行個體的伺服器。
• 如果您是第一次在 Azure Migrate 中執行 Azure SQL 評估，建議您建立新的伺服器群組。

當我建立 Azure App 服務 評估時，我看不到某些伺服器

• Azure App Service 評量只能在探索到 Web 服務器角色的伺服器上完成。 如果您沒有看到想要評估的伺服器，請等候一段時間讓探索完成，然後再建立評估。
• 如果您在建立評估時看不到先前建立的群組，請從群組中移除任何非 VMware 伺服器或沒有 Web 應用程式的伺服器。
• 如果您是第一次在 Azure Migrate 中執行 Azure App Service 評量，建議您建立新的伺服器群組。

我想要深入了解執行個體的整備程度是如何計算的？

使用目標 Azure SQL 部署類型 (Azure VM 上的 SQL Server 或 Azure SQL 受控執行個體或 Azure SQL Database) 執行功能相容性檢查後，就已計算好 SQL 執行個體的整備程度。 深入了解。

我想要深入了解 Web 應用程式的整備程度是如何計算的？

Web 應用程式的整備程度是藉由執行一系列技術檢查來計算，以判斷 Web 應用程式是否會在 Azure App Service 中順利執行。 這些檢查記載於此處。

為什麼我的 Web 應用程式在 Azure App Service 評量中標示為「有條件就緒」或「尚未就緒」？

當指定 Web 應用程式的一或多個技術檢查失敗時，就會發生這種情況。 您可以選取 Web 應用程式的整備狀態，以找出失敗檢查的詳細資料和補救。

為什麼我的所有 SQL 執行個體的整備程度標示為未知？

如果您的探索最近啟動且仍在進行中，您可能會看到部分或所有 SQL 執行個體的整備程度為未知。 建議您等候一段時間讓設備分析環境，然後再重新計算評估。 SQL 探索的執行頻率為每 24 小時一次，您最多可能需要等候一天的時間，最新的設定變更才會反映到系統上。

為什麼我的某些 SQL 執行個體的整備程度標示為未知？

此狀況的原因可能是：

• 探索仍在進行中。 建議您等候一段時間讓設備分析環境，然後再重新計算評估。
• 在 [錯誤和通知] 中，有一些需要修正的探索問題。

SQL 探索的執行頻率為每 24 小時一次，您最多可能需要等候一天的時間，最新的設定變更才會反映到系統上。

我的評估處於「已過期」狀態

Azure VM/AVS 評量

如果在已評估的群組中，伺服器的內部部署有所變更，則會將評量標示為過期。 評量可能因下列一或多個下列屬性的變更而標示為「過期」：

• 處理器核心數目
• 配置的記憶體
• 開機類型或韌體
• 作業系統名稱、版本和架構
• 磁碟數目
• 網路介面卡數目
• 磁碟大小變更 (配置的 GB 數)
• Nic 屬性更新。 範例：Mac 位址變更、IP 位址新增等等。

重新計算評量，以反映評量的最新變更。

Azure SQL 評估

如果在已評估的群組中，內部部署 SQL 執行個體和資料庫有變更，則會將評估標示為已過期：

• 已在伺服器中新增或移除 SQL 執行個體
• 已在 SQL 執行個體中新增或移除 SQL 資料庫
• SQL 執行個體中的資料庫大小總計變更超過 20%
• 處理器核心和/或已配置的記憶體數量有所變更

重新計算評量，以反映評量的最新變更。

為何建議我使用特定的目標部署類型？

Azure Migrate 建議使用與 SQL 執行個體相容的特定 Azure SQL 部署類型。 遷移至 Microsoft 建議的目標可減少整個移轉工作。 在考量 SQL 執行個體的效能特性和其所管理的資料庫之後，系統建議您使用此 Azure SQL 設定 (SKU)。 如果符合資格的 Azure SQL 設定很多，建議您使用最符合成本效益的設定。 深入了解。

如果 SQL 執行個體已準備好用於 Azure SQL DB 和 Azure SQL MI，應選擇何種部署目標？

如果您的執行個體已準備好用於 Azure SQL DB 和 Azure SQL MI，建議您使用 Azure SQL 設定預估成本較低的目標部署類型。

即使執行個體是評估的一部分，評估中還是看不到某些資料庫

Azure SQL 評估只包含處於線上狀態的資料庫。 如果資料庫處於任何其他狀態，則評估會忽略這類資料庫而不計算其整備程度、規模和成本。 如果您想要評估這類資料庫，請變更資料庫的狀態，並在一段時間後重新計算評估。

我想要比較在 Azure VM 上以及在 Azure SQL Database/Azure SQL 受控執行個體上執行 SQL 執行個體的成本

您可以建立單一 Azure SQL 評定，其中包含跨 VMware、Microsoft Hyper-V 和實體/裸機環境所需的 SQL 伺服器，以及 AWS、GCP 等其他公用雲端的 IaaS 伺服器。單一評估涵蓋 Azure 中所有可用 SQL 移轉目標的整備程度、SKU、估計成本和移轉封鎖程式 - azure VM 上的 Azure SQL 受控執行個體、Azure SQL 資料庫 和 SQL Server。 然後，您可以比較所需目標的評量輸出。 深入瞭解

我的 Azure SQL 評量中的儲存體成本為零

針對 Azure SQL 受控執行個體，前 32 GB/執行個體/每月儲存體不會新增任何儲存體成本，額外的儲存體成本則會以 32 GB 的遞增方式新增成本。 深入了解。

當我建立 Azure VMware 解決方案 （AVS） 評量時，我看不到某些群組

• 您可以在只有 VMware 電腦的群組上進行 AVS 評估。 如果要執行 AVS 評量，請從群組中移除所有非 VMware 機器。
• 如果您是第一次在 Azure Migrate 中執行 AVS 評量，建議您建立新的 VMware 機器群組。

關於 Ultra 磁碟的查詢

我可以使用 Azure Migrate 將磁碟移轉至 Ultra 磁碟嗎？

否。 目前 Azure Migrate 和 Azure Site Recovery 皆不支援移轉至 Ultra 磁碟。 在這裡尋找部署 Ultra 磁碟的步驟

為什麼在我的 Ultra 磁碟中，佈建的 IOPS 和輸送量超過我的內部部署 IOPS 和輸送量？

根據每個官方定價頁面，Ultra 磁碟依佈建的大小、佈建的 IOPS 及佈建的輸送量收費。 根據每個提供的範例：

若您佈建了一部 200 GiB 的 Ultra 磁碟、20,000 IOPS 及每秒 1,000 MB，然後在使用了 20 個小時之後將其刪除。這部磁碟將會對應到 256 GiB 的磁碟大小方案，並會以 256 GiB、20,000 IOPS 及每秒 1,000 MB 的計算方式，向您收取 20 小時的費用。

要佈建的 IOPS = (探索到的輸送量) *1024/256

Ultra 磁碟建議是否考慮延遲？

否，目前只會使用磁碟大小、總輸送量和總 IOPS 來調整大小和成本。

我可以看到 M 系列支援 Ultra 磁碟，但在我的評量中，建議使用 Ultra 磁碟，但指出「找不到此位置的 VM」？

這是有可能的，因為並非所有支援 Ultra 磁碟的區域中均顯示所有支援 Ultra 磁碟的 VM 大小。 變更目標評定區域以取得這部伺服器的 VM 大小。

我在 Azure Government 中看不到某些 VM 類型和大小

支援評量和移轉的 VM 類型和大小取決於 Azure Government 位置的可用性。 您可以在 Azure Government 中檢閱和比較 VM 類型。

我的伺服器大小已變更。 我可以再次執行評量嗎？

Azure Migrate 設備會持續收集內部部署環境的相關資訊。 評量是內部部署伺服器的時間點快照集。 如果您在您想要評估的伺服器上變更設定，請使用重新計算選項，以最新的變更來更新評量。

我該如何探索多租用戶環境中的伺服器？

• VMware：如果環境跨租用戶共用，而您不想探索另一個租用戶訂用帳戶中的租用戶伺服器，請建立只存取您想要探索伺服器的 VMware vCenter Server 認證。 然後，當您在 Azure Migrate 設備中開始探索時，請使用這些認證。
• Hyper-V：探索會使用 Hyper-V 主機認證。 如果伺服器共用相同的 Hyper-V 主機，目前無法分隔探索。

我需要 vCenter Server 嗎？

是，Azure Migrate 需要 VMware 環境中的 vCenter Server 才能執行探索。 Azure Migrate 不支援探索不是由 vCenter Server 管理的 ESXi 主機。

Azure VM 評量中的調整大小選項為何？

使用內部部署大小調整時，Azure Migrate 不會針對評量考慮伺服器效能資料。 Azure Migrate 會根據內部部署設定來評估 VM 大小。 使用以效能為基礎的調整大小時，調整大小是以使用率資料為基礎。

例如，若內部部署的伺服器具有 4 個核心和 8 GB 的記憶體，且 CPU 和記憶體利用率均為 50%：

• 則內部部署大小調整建議具有 4 核心和 8 GB 記憶體的 Azure VM SKU。
• 由於會考慮使用率百分比，以效能為基礎的大小調整建議具有 2 個核心和 4 GB 記憶體的 VM SKU。

同樣地，磁碟調整大小取決於調整大小準則和儲存體類型：

• 如果重設大小準則是以「效能為基礎」且記憶體類型為自動，則 Azure Migrate 會在識別目標磁碟類型（標準、進階或 Ultra 磁碟）時，將磁碟的 IOPS 和輸送量值納入考慮。
• 如果重設大小準則為「內部部署」，且記憶體類型為進階，Azure Migrate 會根據內部部署磁碟的大小來建議進階磁碟 SKU。 當重設大小為內部部署且記憶體類型為標準、進階或 Ultra 磁碟時，相同的邏輯會套用至磁碟大小調整。

效能歷程記錄和使用率是否會影響 Azure VM 評量的大小？

是，效能歷程記錄和使用率是否會影響 Azure VM 評量的大小。

效能歷程記錄

僅適用於以效能為基礎的調整大小，Azure Migrate 會收集內部部署機器的效能記錄，然後將其用來建議在 Azure 中的 VM 大小和磁碟類型：

1. 設備會持續分析內部部署環境，每 20 秒便收集一次即時使用情況資料。
2. 設備會彙總 20 秒的樣本，並將其用來每 15 分鐘建立一個單一資料點。
3. 為了建立資料點，設備會從所有 20 秒的樣本中選取尖峰值。
4. 設備會將資料點傳送至 Azure。

使用率

當您在 Azure 中建立評估時，取決於設定的效能持續時間和效能記錄的百分位數值，Azure Migrate 會計算有效的使用率值，然後將其用於調整大小。

例如，如果您將效能持續時間設定為一天，並將百分位數值設定為第 95 個百分位數，則 Azure Migrate 會以遞增順序排序收集器針對過去一天傳送的 15 分鐘樣本點。 其會挑選第 95 個百分位數值作為有效使用率。

使用第 95 個百分位數值可確保忽略極端值。 如果您的 Azure Migrate 使用第 99 個百分位數，則可能會包含極端值。 若要挑選期間尖峰使用量而不遺漏任何極端值，請將 Azure Migrate 設定為使用第 99 個百分位數。

以匯入為基礎的評量與探索來源作為設備的評量有何不同？

以匯入為基礎的 Azure VM 評量是使用 CSV 檔案匯入至 Azure Migrate 的電腦所建立的評量。 只有四個欄位是匯入的必要欄位：伺服器名稱、核心、記憶體和作業系統。 這裡有幾個注意事項：

• 在開機類型參數的匯入型評定中，整備準則較不嚴格。 如果未提供開機類型，則會假設電腦具有 BIOS 開機類型，且電腦未標示為有條件就緒。 在探索來源作為設備的評量中，如果缺少開機類型，整備程度會標示為有條件就緒。 整備計算的這項差異是因為在完成匯入型評量時，使用者在移轉規劃的早期階段中，可能沒有關於機器的所有資訊。
• 以效能為基礎的匯入評量會使用使用者提供的使用率值來正確調整計算大小。 由於使用率值是由使用者提供，因此評量屬性中會停用 [效能歷程記錄] 和 [百分位數使用率] 選項。 在探索來源作為設備的評量中，系統會從設備所收集的效能資料中挑選所選百分位數值。

為什麼以匯入為基礎的 AVS 評量中建議的移轉工具標示為未知？

針對透過 CSV 檔案匯入的電腦，AVS 評量中預設的移轉工具是未知的。 但對於 VMware 機器，建議使用 VMware 混合式雲端擴充功能 (HCX) 解決方案。 深入了解。

下一步

深入了解探索 VMware VM、Hyper-V VM 和實體伺服器。