评估 - 常见问题

本文解答了有关Azure Migrate评估的常见问题。如果你遇到其他问题，请查看以下资源：

使用Azure Migrate进行发现和评估支持哪些地理区域？

使用一个设备可以发现多少个服务器？

可以使用单个设备从 VMware 环境发现多达 10,000 台服务器、从 Hyper-V 环境发现多达 5,000 台服务器，以及多达 1,000 台物理服务器。如果您有更多的服务器，请阅读有关扩展 Hyper-V 评估、扩展 VMware 评估或扩展物理服务器评估。

如何选择评估类型？

使用 Azure VM 评估 来评估从本地 VMware 和 Hyper-V 环境以及物理服务器的服务器，以便迁移到 Azure VM。了解详细信息。

您可以只使用拥有 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 Solution 评估中的性能数据收集问题。执行以下步骤:

转到 Azure Migrate >Windows、Linux 和 SQL Server>迁移目标，在发现和评估工具上选择 解决问题。
选择评估旁边的 受影响的对象 ，然后选择错误 ID 列中的链接以查看错误详细信息和修正作。

您还可以在“选择服务器以评估”步骤中创建评估时，或在现有评估的就绪情况选项卡中查看这些错误/问题。如果在评估中没有看到任何错误/问题，但在“解决问题”选项卡中看到非零错误，请重新计算评估才能在“评估”选项卡中看到问题。

为什么评估的性能覆盖率较低？

性能覆盖率是根据计算评估所需的可用数据点百分比计算基于性能的评估。下面是为什么评估可能会获得较低置信度分级的原因：

在创建评估的时段，您没有对环境进行配置分析。例如，如果您创建一个性能持续时间设置为一周的评估，则需在开始数据点发现后，至少等待一周，才能收集到所有数据点。如果无法等待这么久，请将性能持续时间缩短，并重新计算评估。
评估无法在评估期内收集部分或所有服务器的性能数据。若要获得高置信度评级，请确保：
- 服务器在评估期间处于开机状态
- 允许端口 443 上的出站连接
- 对于Hyper-V服务器，已启用动态内存
- Azure Migrate中代理的连接状态为“已连接”，并且需要检查最近一次的心跳信号。
- 对于 Azure SQL 评估中，检测到的 SQL 实例部分显示所有 SQL 实例的 Azure Migrate 连接状态为连接。
请重新计算评估以反映置信度评级的最新更改。
在进行 Azure VM 评估时，发现过程开始后创建了少量服务器。例如，如果您正在为过去一个月的性能历史记录创建评估，而环境中的一些服务器仅在一周前才创建。在这种情况下，整个评估过程中将无法使用新服务器的性能数据，而且置信度评级会较低。了解详细信息。

为什么我的 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 评估数不正确

若要解决此问题，请选择“评估总览”以查看所有评估，并重新计算 Azure VM 或 AVS 的评估。然后，发现和评估工具就会显示该评估类型的正确计数。

为什么我的 Web 应用在 Azure 应用服务评估中被标记为“有条件的就绪”或“未就绪”？

当给定的 Web 应用的一个或多个技术检查失败时，就会出现此情况。你可以选择 Web 应用的就绪性状态，以了解有关检查失败的详细信息和修正情况。

我的所有 SQL 实例的就绪性为何标记为未知？

如果你的发现是最近启动的并仍在进行，则你可能会看到某些或所有 SQL 实例的就绪性标记为未知。建议稍等一段时间，待设备对环境进行分析，然后再重新计算评估。 SQL 发现每 24 小时执行一次；可能需要等待一天，最新的配置更改才会反映出来。

我的某些 SQL 实例的就绪性为何标记为未知？

可能的原因包括：

发现仍在进行。建议稍等一段时间，待设备对环境进行分析，然后再重新计算评估。
需要在“错误和通知”中解决一些与发现相关的问题。

SQL 发现每 24 小时执行一次；可能需要等待一天，最新的配置更改才会反映出来。

我的评估处于“过时”状态

Azure VM 评估

如果对已评估的组中的服务器进行了本地更改，则评估将标记为过时。可能会由于在以下属性中进行了一项或多项更改而将评估标记为“过时”：

处理器核心数
分配的内存
启动类型或固件
操作系统名称、版本和体系结构
磁盘数目
网络适配器数目
磁盘空间更改（已分配的 GB）
NIC 属性更新。例如，更改 Mac 地址、添加 IP 地址等。

请重新计算评估以在评估中反映最新更改。

Azure SQL评估

如果对已评估的组中的本地 SQL 实例和数据库进行了更改，则评估将标记为“过时”：

已在服务器中添加或删除 SQL 实例
已在 SQL 实例中添加或删除 SQL 数据库
SQL 实例中的总数据库大小更改超过 20%
更改了处理器核心数和/或分配的内存

请重新计算评估以在评估中反映最新更改。

为何建议使用特定的目标部署类型？

Azure Migrate建议与 SQL 实例兼容的特定Azure SQL部署类型。迁移到 Azure 推荐的目标可减少整体迁移工作量。考虑 SQL 实例及其管理的数据库的性能特征后，建议使用此Azure SQL配置（SKU）。如果多个Azure SQL配置符合条件，建议使用最经济高效的配置。了解详细信息。

如果我的 SQL 实例已准备好Azure SQL DB 和 Azure SQL MI，应选择哪些部署目标？

如果您的实例已准备好用于 Azure SQL DB 和 Azure SQL MI，我们建议选择 Azure SQL 配置估计成本较低的目标部署类型。

即使实例是评估的一部分，我在我的评估中也看不到某些数据库

Azure SQL评估仅包括处于联机状态的数据库。如果数据库处于任何其他状态，评估将不计算此类数据库的就绪性、大小和成本。如果你希望评估此类数据库，请更改数据库的状态，在一段时间后再重新计算评估。

Azure SQL评估中的存储成本为零

对于 Azure SQL 托管实例，前 32 GB/实例/月的存储不收取存储费用，额外的存储费用按每 32 GB 增量计算。了解详细信息。

我的服务器大小已更改。是否可以再次运行评估？

Azure Migrate设备持续收集有关本地环境的信息。评估是本地服务器的时间点快照。如果更改了要评估的服务器上的设置，请使用“重新计算”选项，以使用最新更改来更新评估。

如何发现多租户环境中的服务器？

VMware：如果环境在多个租户之间共享，而你不希望发现另一个租户的订阅中的租户服务器，请创建只能访问你要发现的服务器的 VMware vCenter Server 凭据。然后，在 Azure Migrate 设备中启动发现时使用这些凭据。
Hyper-V：发现过程使用Hyper-V主机凭据。如果服务器共享相同的Hyper-V主机，则目前无法分离发现。

是否需要 vCenter Server？

是的，在 VMware 环境中，Azure Migrate 需要 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。
基于性能的大小调整会推荐具有 2 个核心和 4 GB 内存的 VM SKU，因为它考虑到了利用率百分比。

同样，磁盘大小调整取决于大小调整条件和存储类型：

如果大小调整条件是“基于性能的”，并且存储类型是自动的，则Azure Migrate在标识目标磁盘类型（标准磁盘、高级磁盘或超级磁盘）时考虑磁盘的 IOPS 和吞吐量值。
如果大小调整标准为“与本地相同”，并且存储类型为“高级”，那么Azure Migrate将根据本地磁盘的大小建议使用高级磁盘SKU。当大小调整类似于本地且存储类型为标准、高级或超高级磁盘时，同样的逻辑将用于磁盘大小调整。

性能历史记录和利用率是否会影响Azure VM 评估中的大小调整？

是的，性能历史记录和利用率会影响Azure VM评估中的规模评估。

性能历史记录

对于基于性能的大小调整，Azure Migrate收集本地计算机的性能历史记录，然后使用它来推荐Azure中的 VM 大小和磁盘类型：

设备持续分析本地环境，每隔 20 秒收集一次实时利用率数据。
设备汇总收集的 20 秒样本，并每隔 15 分钟使用这些样本创建单个数据点。
为了创建数据点，设备会选择所有 20 秒样本中的峰值。
设备将数据点发送到Azure。

使用率

在Azure中创建评估时，根据设置的性能持续时间和性能历史记录百分位值，Azure Migrate计算有效利用率值，然后使用它进行大小调整。

例如，如果将性能持续时间设置为一天，并将百分位值设置为第 95 百分位，则Azure Migrate按升序对收集器发送的 15 分钟样本点进行排序。它选取第 95 百分位值作为有效利用率。

使用第 95 百分位值可确保忽略离群值。如果 Azure Migrate 使用第 99 百分位，离群值可能会被包括在内。要在不遗漏任何离群值的情况下选择该时间段的使用峰值，请将 Azure Migrate 设置为使用第 99 百分位数。

基于导入的评估与使用发现源作为设备的评估有何不同？

基于导入的 Azure VM 评估是指通过使用 CSV 文件将计算机导入 Azure Migrate 所创建的评估。只有四个字段是必须导入的字段：服务器名称、核心数、内存和操作系统。下面是需要注意的几个事项：

在基于导入的评估中，启动类型参数的就绪性条件不那么严格。如果未提供启动类型，则假定计算机采用 BIOS 启动类型，并且计算机未标记为“有条件就绪”。在使用发现源作为设备的评估中，如果缺少启动类型，则就绪性将标记为“有条件就绪”。就绪性计算之所以存在这种差异，是因为在完成基于导入的评估后，用户在早期的迁移规划阶段中可能尚未在计算机上准备好所有信息。
性能导向的导入评估使用用户提供的利用率值来进行适当的大小调整计算。由于利用率值由用户提供，因此在评估属性中禁用了“性能历史记录”和“百分位利用率”选项。在使用发现源作为设备的评估中，所选百分位值选取自设备所收集的性能数据。

是否可以将评估数据从第三方工具上传到Azure Migrate？

否，无法从第三方工具上传评估数据。可以使用 CSV 文件上传清单，但必须在Azure Migrate项目中完成所有评估。

是否可以为特定时间间隔创建 Azure Migrate 评估？

不能基于特定时间间隔创建评估。但是，可以在一段时间内部署Azure Migrate设备，例如 1 天或 1 周。然后，使用该时间收集的清单数据来创建评估。

后续步骤

详细了解如何发现 VMware VM、Hyper-V VM 和物理服务器。

Last updated on 2026-03-06