針對評量進行疑難解答 - 常見問題

本文提供一些關於針對評量問題進行疑難解答的常見問題的解答。 請參閱針對評量和支援案例的問題進行疑難解答文章，以針對評量進行疑難解答。

為什麼建議的 Azure 磁碟 SKU 大於 Azure VM 評量中的內部部署？

Azure VM 評量可能會根據評量類型來建議較大的磁碟：

• 磁碟調整大小取決於兩個評估屬性：調整大小準則和儲存體類型。
• 如果重設大小準則是以 效能為基礎 ，且記憶體類型設定為 [自動]，則識別目標磁碟類型時會考慮磁碟的 IOPS 和輸送量值（標準 HDD、標準 SSD、進階或 Ultra 磁碟）。 接著會建議使用磁碟類型中的磁碟 SKU，並考量內部部署磁碟的大小需求。
• 如果重設大小準則是以 效能為基礎 ，且記憶體類型為 Premium，則建議使用 Azure 中的進階磁碟 SKU，以內部部署磁碟的 IOPS、輸送量和大小需求為基礎。 當調整大小準則是 [內部部署形式]，且儲存體類型為 [標準 HDD]、[標準 SSD]、[進階] 或 [Ultra 磁碟] 時，也會使用相同的邏輯來執行磁碟的大小調整。

例如，假設您的內部部署磁碟具有 32 GB 的記憶體，但磁碟的彙總讀取和寫入 IOPS 為 800 IOPS。 Azure VM 評量建議進階磁碟，因為 IOPS 需求較高。 其也會建議可支援所需 IOPS 和大小的磁碟 SKU。 在此範例中最接近的相符項目為 P15 (256 GB、1100 IOPS)。 即使內部部署磁碟所需的大小為 32 GB，Azure VM 評量建議較大的磁碟，因為內部部署磁碟的 IOPS 需求較高。

為什麼我的評量報告中遺失某些或所有 VM 的效能資料？

進行 [以效能為基礎] 的評量時，當 Azure Migrate 設備無法收集內部部署 VM 的效能資料時，評量報告匯出會顯示 'PercentageOfCoresUtilizedMissing' 或 'PercentageOfMemoryUtilizedMissing'。 請務必檢查：

• VM 在您建立評量的持續時間內是否開啟電源。
• 如果只有記憶體計數器遺失，而且您想要評估 Hyper-V VM，那麼請檢查您是否已在這些 VM 上啟用動態記憶體。 由於已知問題，目前 Azure Migrate 設備無法對此類 VM 收集記憶體使用量。
• 如果遺失所有效能計數器，請確定符合評量的連接埠存取需求。 深入了解 VMware、Hyper-V 和實體評量的連接埠存取需求。 如果遺漏任何性能計數器，Azure Migrate：探索和評量會回復到已配置的核心/記憶體內部部署，並據此建議 VM 大小。

為什麼我的 Azure VM 或 Azure VMware 解決方案評量報表中，缺少部分或所有伺服器的效能資料？

進行 [以效能為基礎] 的評量時，當 Azure Migrate 設備無法收集內部部署伺服器的效能資料時，評量報告匯出會顯示 PercentageOfCoresUtilizedMissing 或 PercentageOfMemoryUtilizedMissing。 請務必檢查：

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

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

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

  注意

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

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

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

• SQL 伺服器在您建立評量的持續時間內是否開啟電源。
• 在 Azure Migrate 中，SQL 代理程式的連線狀態為 [已連線]，還要檢查最後一個活動訊號。
• 如果在探索到的 SQL 執行個體窗格中，所有 SQL 執行個體的 Azure Migrate 連線狀態為 [已連線]。
• 如果遺失了所有效能計數器，請確定您已允許連接埠 443 上的輸出連線 (HTTPS)。

如果缺少任何效能計數器，Azure SQL 評量會建議使用該執行個體或資料庫的最小 Azure SQL 設定。

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

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

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

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

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

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

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

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

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

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

作業系統授權是否包含在 Azure VM 評量中？

Azure VM 評量目前僅考慮 Windows 伺服器的作業系統授權成本。 目前不會考慮 Linux 伺服器的授權成本。

以效能為基礎的重設大小如何在 Azure VM 評量中運作？

Azure VM 評量會持續收集內部部署伺服器的效能資料，並用這些資料來建議 Azure 中的 VM SKU 和磁碟 SKU。 深入了解如何收集以效能為基礎的資料。

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

否。 目前 Azure Migrate 和 Azure Site Recovery 皆不支援移轉至 Ultra 磁碟。 深入了解部署 Ultra 磁碟。

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

根據每個官方定價頁面，Ultra 磁碟依佈建的大小、佈建的 IOPS 及佈建的輸送量收費。 例如，如果您使用 20,000 IOPS 和 1,000 MB/秒佈建 200-GiB Ultra 磁碟並在 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 大小。

為什麼我的評量顯示警告，其以不正確供應項目所建立？

您的評量是使用不再有效的供應項目所建立，因此會停用 [編輯] 和 [重新計算] 按鈕。 您可以使用任何有效的供應項目建立新的評量 - 隨用隨付、隨用隨付開發/測試，以及 Enterprise 合約。 您也可以使用 [折扣 (%)] 欄位，以在 Azure 供應項目上方指定任何自訂折扣。 深入了解。

為什麼我的評量會顯示已使用淘汰的目標 Azure 位置所建立的警告？

您的評量是以已遭到取代的 Azure 區域所建立，因此會停用 [編輯] 和 [重新計算] 按鈕。 您可以使用任何有效的目標位置來建立新的評量。 深入了解。

為什麼我的評量顯示警告，其是使用保留執行個體、VM 運作時間和折扣 (%) 的不正確組合所建立？

當您選取 [保留執行個體] 時，[折扣 (%)] 和 [VM 運作時間] 屬性不適用。 當您的評量是使用這些屬性的不正確組合所建立時，會停用 [編輯] 和 [重新計算] 按鈕。 建立新評量。 深入了解。

為什麼我的部分評量標示為「要升級至最新評量版本」？

重新計算您的評量，以檢視升級的 Azure SQL 評量體驗，以識別跨 Azure SQL 受控執行個體、Azure VM 上 SQL Server，以及 Azure SQL DB 上 SQL 部署的理想移轉目標：

• 我們建議根據 Azure 最佳做法，將執行個體移轉至 Azure VM 上的 SQL Server。
• 正確大小的隨即轉移 - 伺服器到 Azure VM 上的 SQL Server。 當無法使用 SQL Server 認證時，建議您這樣做。
• 增強的使用者體驗，其涵蓋一個評量中 SQL 部署多個移轉目標的整備程度和成本預估。

建議您在重新計算之前匯出現有評量。

我在實體伺服器上看不到某些網路介面卡的效能資料

如果實體伺服器已啟用 Hyper-V 虛擬化，則可能發生此問題。 在這些伺服器上，由於產品間隙，Azure Migrate 目前會探索實體和虛擬網路介面卡。 只會在探索到的虛擬網路介面卡上擷取網路輸送量。

我的實體伺服器的建議 Azure VM SKU 過大

如果實體伺服器已啟用 Hyper-V 虛擬化，則可能發生此問題。 在這些伺服器上，Azure Migrate 目前會探索實體和虛擬網路介面卡。 因此，探索到的網路介面卡數目高於實際數目。 Azure VM 評量會挑選可支援所需網路介面卡數目的 Azure VM，這可能會導致過大的 VM。 深入了解網路介面卡數目對調整大小的影響。 未來將解決此產品間隙。

整備程度類別已針對我的實體伺服器標示為「尚未就緒」

在已啟用 Hyper-V 虛擬化的實體伺服器的情況下，整備程度類別可能未正確標示為 [尚未就緒]。 在這些伺服器上，由於產品間隙，Azure Migrate 目前會探索實體和虛擬介面卡。 因此，探索到的網路介面卡數目高於實際數目。 在 [內部部署形式] 和 [以效能為基礎] 的評量中，Azure VM 評量會挑選可支援所需網路介面卡數目的 Azure VM。 如果探索到的網路介面卡數目高於 32，即 Azure VM 上支援的 NIC 數目上限，伺服器將會標示為 [尚未就緒]。 深入了解 NIC 對調整大小的影響。

探索到的 NIC 數目高於實體伺服器的實際數目

如果實體伺服器已啟用 Hyper-V 虛擬化，則可能發生此問題。 在這些伺服器上，Azure Migrate 目前會探索實體和虛擬介面卡。 因此，探索到的 NIC 數目高於實際數目。

擷取網路流量

若要收集網路流量記錄：

1. 登入 Azure 入口網站。
2. 選取 F12 啟動 Developer Tools。 如有需要，請清除 [清除瀏覽的項目] 設定。
3. 選取 [網路] 索引標籤，並開始擷取網路流量：
   • 在 Chrome 中，選取 [保留記錄]。 記錄應該會自動啟動。 紅色圓圈表示正在擷取流量。 如果紅色圓圈未出現，請選取要啟動的黑色圓圈。
   • 在 Microsoft Edge 和 Internet Explorer 中，錄製應該會自動啟動。 如果未啟動，請選取綠色播放按鈕。
4. 嘗試重現錯誤。
5. 您在記錄時發生錯誤之後，請停止錄製，並儲存一份記錄的活動：
   • 在 Chrome 中，按一下滑鼠右鍵並選取 [內容另存為 HAR]。 此動作會將記錄壓縮並匯出為 .har 檔案。
   • 在 Microsoft Edge 或 Internet Explorer 中，選取 [匯出擷取的流量] 選項。 此動作會壓縮並匯出記錄。
6. 選取 [主控台] 索引標籤，檢查是否有任何警告或錯誤。 若要儲存主控台記錄：
   • 在 Chrome 中，以滑鼠右鍵按一下主控台記錄的任何位置。 選取 [另存新檔]，以匯出並壓縮記錄。
   • 在 Microsoft Edge 或 Internet Explorer 中，以滑鼠右鍵按一下錯誤，然後選取 [全部複製]。
7. 關閉 Developer Tools。

我的評量中的作業系統資料是從哪裡探索到的？

• 針對 VMware VM，根據預設，其是由 vCenter Server 提供的作業系統資料。
  • 針對 VMware Linux VM，如果已啟用應用程式探索，則會從來賓 VM 擷取 OS 詳細資料。 若要檢查評量中的 OS 詳細資料，請移至 [探索到的伺服器] 檢視，並將滑鼠停留在 [作業系統] 資料行中的值上。 在快顯的文字中，您可以看到您看到的 OS 資料是透過使用 VM 認證從 vCenter Server 或來賓 VM 收集。
  • 針對 Windows VM，作業系統詳細資料一律會從 vCenter Server 進行擷取。
• 針對 Hyper-V VM，會從 Hyper-V 主機收集作業系統資料。
• 針對實體伺服器，其會從伺服器擷取。

下一步

建立或自訂評量。