評定 - 常見問題

本文會回答 Azure Migrate 中評量的相關常見問題。 如果您有其他問題，請檢查下列資源：

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

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

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

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

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

如何? 選擇評量類型嗎？

• 當您要從內部部署 VMware 和 Hyper-V 環境評估伺服器，以及移轉至 Azure VM 的實體伺服器時，請使用 Azure VM 評量。 深入了解。
• 當您想要在 VMware、Microsoft Hyper-V 和實體/裸機環境中評估內部部署 SQL Server，以及 AWS、GCP 等其他公用雲端的 IaaS 伺服器，以便移轉至 Azure VM 或 Azure SQL 資料庫 或 Azure SQL 受控執行個體 上的 SQL Server 時，請使用評量類型 Azure SQL。 深入了解。
• 當您想要從 VMware 環境評估 IIS 網頁伺服器上執行的內部部署 ASP.NET Web 應用程式，以移轉至 Azure App 服務 時，請使用評量類型 Azure App 服務。 深入了解。
• 當您想要評估內部部署 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 服務 評量？

效能數據不會擷取 Azure App 服務 評定，因此您看不到此評量類型的信賴評等。 Azure App 服務 評估會在執行評量計算時，將 Web 應用程式的組態資料用於考慮。

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

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

• 您未針對正在建立評估的持續時間剖析環境。 例如，如果您要建立效能持續時間設定為一周的評定，則必須在開始探索之後至少等候一周，以收集所有數據點。 如果您無法等候持續時間，請將效能持續時間變更為較小的期間，然後 重新計算 評量。

• 評定無法收集評估期間中部分或所有伺服器的效能數據。 針對高信賴評等，請確定：

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

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

• 針對 Azure VM 和 AVS 評量，在探索啟動之後，會建立少數伺服器。 例如，如果您要為過去一個月的效能歷程記錄建立評量，但一周前才在環境中建立少數伺服器。 在此情況下，新伺服器的效能數據將無法在整個期間使用，信賴評等會很低。 深入了解。

• 針對 Azure SQL 評估，在探索開始之後便已建立少數 SQL 執行個體或資料庫。 例如，如果您要為過去一個月的效能歷程記錄建立評量，但一周前才在環境中建立幾個 SQL 實例或資料庫。 在此情況下，新伺服器的效能數據將無法在整個期間使用，信賴評等會很低。 深入了解。

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

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

我在評定上看到橫幅，評定現在也會考慮處理器參數。 重新計算評量會有什麼影響？

評估現在會考慮處理器參數，例如操作核心數目、套接字等，並在模擬環境中計算其最佳效能。 這是為了基準檢驗所有處理器型可用的處理器資訊。 重新計算您的評量，以查看更新的建議。

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

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

對於客戶選擇「內部部署」的案例，處理器效能評定是否有任何影響？

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

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

如果您在評量設定中選取了「VM 系列」的所有可用選項，您將會獲得 VM 最優化的成本建議。 不過，如果您只為 VM 系列選擇一些可用的選項，建議可能會在指派 Azure VM SKU 時略過最優化的選項，同時符合處理器效能號碼。

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

可能有兩個原因：

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

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

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

我想要試用新的 Azure SQL 評量

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

我想嘗試新的 Azure App 服務 評估

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

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

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

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

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

我想要瞭解如何計算實例的整備程度？

在針對目標 Azure SQL 部署類型執行功能相容性檢查之後，已計算 SQL 實例的整備程度（Azure VM 上的 SQL Server 或 Azure SQL 受控執行個體 或 Azure SQL 資料庫）。 深入了解。

我想要瞭解如何計算 Web 應用程式的整備程度？

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

為什麼我的 Web 應用程式在 Azure App 服務 評定中標示為 [就緒] 或 [尚未就緒] ？

當指定 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 上執行 SQL 實例的成本與 Azure SQL 資料庫/Azure 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 的磁碟大小供應專案，而您將針對 20 小時 256 GiB、20,000 IOPS 和 1,000 MB/秒計費。

要布建的 IOPS = （探索到輸送量） *1024/256

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

否，目前只有磁碟大小、輸送量總計和 IOPS 總計用於重設大小和成本。

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

並非所有支援 Ultra 磁碟的 VM 大小都存在於所有 Ultra 磁碟支援區域中。 變更目標評定區域以取得這部伺服器的 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%， 記憶體使用率為 50%：

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

同樣地，磁碟重設大小取決於重設大小準則和記憶體類型：

• 如果重設大小準則是以「效能為基礎」且記憶體類型為自動，則 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 開機類型，且計算機未標示為 條件式就緒。 在探索來源為設備評量中，如果開機類型遺失，整備程度會標示為 有條件地就緒 。 整備計算的這項差異是因為使用者在完成匯入型評估時，在移轉規劃的早期階段，可能沒有計算機的所有資訊。
• 以效能為基礎的匯入評估會使用使用者提供的使用率值來進行正確的大小計算。 由於使用率值是由使用者提供， 因此評估屬性中會停用效能歷程記錄 和 Percentile 使用率 選項。 在以探索來源作為設備的評量中，會從設備所收集的效能資料中挑選所選百分位數值。

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

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

下一步

閱讀 Azure Migrate 概觀 。