通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

评估 - 常见问题

  • 项目

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

Azure Migrate 的发现和评估功能支持哪些地理区域？

查看公有云和政府云支持的地理位置。

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

使用单个设备最多可以发现 VMware 环境中的 10,000 个服务器、Hyper-V 环境中的 5,000 个服务器，以及 1,000 个物理服务器。 如果你有更多的服务器，请了解如何扩展 Hyper-V 评估、扩展 VMware 评估或扩展物理服务器评估。

如何选择评估类型？

  • 若要评估本地 VMware 和 Hyper-V 环境中要迁移到 Azure VM 的服务器以及要迁移到 Azure VM 的物理服务器，请使用“Azure VM 评估”。 了解详细信息。
  • 若要评估 VMware、Microsoft Hyper-V 和物理/裸机环境中要迁移到 Azure VM 上的 SQL Server、Azure SQL 数据库或 Azure SQL 托管实例的本地 SQL Server 以及 AWS、GCP 等其他公有云的 IaaS 服务器，请使用 Azure SQL 评估类型。 了解详细信息。
  • 评估 VMware 环境中在 IIS Web 服务器上运行的本地 ASP.NET Web 应用以便迁移到 Azure 应用服务时，请使用评估类型“Azure 应用服务”。 了解详细信息。
  • 若要评估要迁移到 Azure VMware 解决方案 (AVS) 的本地 VMware VM，请使用“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 应用”>“迁移目标”，选择发现和评估工具上的“解决问题”。
  • 选择评估旁边的“受影响的对象”，然后选择错误 ID 列中的链接，查看错误详细信息和修正操作。

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

为什么我的 Azure SQL 评估中的部分/全部 SQL 实例/数据库缺少性能数据？

要确保会收集性能数据，请检查：

  • 是否在创建评估期间启动了 SQL Server。
  • Azure Migrate 中 SQL 代理的连接状态是否为“已连接”，并检查上一个检测信号。
  • “已发现的 SQL 实例”部分中所有 SQL 实例的 Azure Migrate 连接状态是否均为“已连接”。
  • 如果所有性能计数器均丢失，确保允许端口 443 (HTTPS) 上的出站连接。

如果缺少任何性能计数器，Azure SQL 评估会回退到本地大小调整，并基于本地分配的核心、内存和数据库总大小建议 Azure SQL 配置。

为什么置信度评级不适用于 Azure 应用服务评估？

系统不会为 Azure 应用服务评估捕获性能数据，因此，你不会看到此评估类型的置信度评级。 在执行评估计算时，Azure 应用服务评估会考虑 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 应用服务评估

目前，对 VMware 环境中运行的 .NET Web 应用的发现和评估功能以预览版提供。 请先查看此教程。 如果要在现有项目中试用此功能，请确保已完成本文中的先决条件。

创建 Azure SQL 评估时，我看不到某些服务器

  • 只能在发现了 SQL 实例的服务器上执行 Azure SQL 评估。 如果看不到需要评估的服务器和 SQL 实例，请等待一段时间以便发现，然后再创建评估。
  • 如果在创建评估时无法看到先前创建的组，请从组中删除所有没有 SQL 实例的服务器。
  • 如果是首次在 Azure Migrate 中运行 Azure SQL 评估，建议创建一组新的服务器。

创建 Azure 应用服务评估时，我看不到某些服务器

  • Azure 应用服务评估只能在已发现 Web 服务器角色的服务器上完成。 如果看不到想要评估的服务器，请等待一段时间以完成发现，然后再创建评估。
  • 如果在创建评估时看不到之前创建的组，请从组中删除所有非 VMware 服务器或所有没有 Web 应用的服务器。
  • 如果是首次在 Azure Migrate 中运行 Azure 应用服务评估，建议创建一组新的服务器。

我的实例的就绪性是如何计算得出的？

在对目标 Azure SQL 部署类型（Azure VM 上的 SQL Server、Azure SQL 托管实例或 Azure SQL 数据库）执行功能兼容性检查后，计算了你的 SQL 实例的就绪性。 了解详细信息。

我的 Web 应用的就绪性是如何计算得出的？

Web 应用的就绪性是通过运行一系列技术检查来计算的，以确定你的 Web 应用是否会在 Azure 应用服务中成功运行。 此处介绍了这些检查。

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

当给定的 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 托管实例上运行 SQL 实例的成本

可以创建单个 Azure SQL 评估，其中包括 VMware、Microsoft Hyper-V 和物理/裸机环境中的所需 SQL 服务器，以及 AWS、GCP 等其他公有云的 IaaS 服务器。单个评估涵盖了 Azure 中所有可用 SQL 迁移目标（Azure SQL 托管实例、Azure SQL 数据库和 Azure VM 上的 SQL Server）的准备情况、SKU、估计成本和迁移障碍。 然后，可以比较所需目标的评估输出。 了解详细信息

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

对于 Azure SQL 托管实例，第一个 32 GB/实例/月的存储不会增加存储成本，而是以 32 GB 为增量增加额外的存储成本。 了解详细信息。

在创建 Azure VMware 解决方案 (AVS) 评估时看不到某些组

  • 可以对只有 VMware 计算机的组进行 AVS 评估。 如果要执行 AVS 评估，请从组中删除任何非 VMware 计算机。
  • 如果是首次在 Azure Migrate 中运行 AVS 评估，建议创建一组新的 VMware 计算机。

有关超级磁盘的查询

能否使用 Azure Migrate 将磁盘迁移到超级磁盘？

不是。 目前，Azure Migrate 和 Azure Site Recovery 均不支持迁移到超级磁盘。 可在此处找到部署超级磁盘的步骤

为何超级磁盘中的预配 IOPS 和吞吐量超过本地 IOPS 和吞吐量？

根据官方定价页，超级磁盘的费用根据预配的大小、预配的 IOPS 和预配的吞吐量进行计算。 根据提供的示例：

如果预配了 200 GiB 的超级磁盘（IOPS 为 20,000，1,000 MB/秒），并在 20 小时后将其删除，则它会映射到 256 GiB 的磁盘大小，并且将按 256 GiB 大小收取 20 个小时（IOPS 为 20,000，1,000 MB/秒）的费用。

要预配的 IOPS = (发现的吞吐量) *1024/256

超级磁盘建议是否考虑延迟？

否，目前仅磁盘大小、总吞吐量和总 IOPS 用于大小调整和成本计算。

并非所有支持超级磁盘的 VM 大小都存在于所有支持超级磁盘的区域，所以可能会出现此情况。 更改目标评估区域，获取此服务器的 VM 大小。

在 Azure 政府版中看不到某些 VM 类型和大小

评估和迁移支持的 VM 类型和大小取决于它们在 Azure 政府版位置中的可用性。 可以查看并比较 Azure 政府版中的 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。
  • 基于性能的大小调整会推荐具有 2 个核心和 4 GB 内存的 VM SKU，因为它考虑到了利用率百分比。

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

  • 如果大小调整条件“基于性能”并且存储类型为“自动”，则 Azure Migrate 在标识目标磁盘类型（“标准”、“高级”或“超级磁盘”）时，将考虑磁盘的 IOPS 和吞吐量值。
  • 如果大小调整条件“与本地相同”并且存储类型为“高级”，则 Azure Migrate 会基于本地磁盘大小推荐一个高级磁盘 SKU。 当大小调整条件为“与本地相同”并且存储类型为“标准”、“高级”或“超级磁盘”时，将对磁盘大小调整应用相同的逻辑。

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

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

性能历史记录

仅对于基于性能的大小调整而言，Azure Migrate 会收集本地计算机的性能历史记录，然后使用它来针对 Azure 中的 VM 大小和磁盘类型提出建议：

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

使用率

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

例如，如果将性能持续时间设置为 1 天，将百分位值设置为第 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 和物理服务器的更多信息。