本文介绍了如何在 Azure 现成虚拟机上构建的最佳做法。 它包括可部署的示例方案。 现成虚拟机（现成 VM）以低于常规 VM 的价格提供对计算容量的访问。 对于想要优化成本的组织来说，这种折扣使他们成为一个不错的选择。 但储蓄是折衷的。 随时可以逐出现成 VM，这意味着它们无法访问计算资源。 在现成 VM 上运行的工作负荷必须能够处理计算中的这些中断。 正确的工作负荷和灵活的业务流程机制是成功的关键。 以下建议介绍如何在现成 VM 上生成。
了解现成 VM
在技术级别，现成 VM 与常规 VM 相同。 它们使用相同的映像、硬件和磁盘来转换为相同的性能。 现成 VM 和常规 VM 之间的主要区别在于其优先级和可用性。 现成 VM 没有访问计算容量的优先级，在访问该计算容量后，它们没有可用性保证。
无优先级访问。 常规 VM 具有对计算容量的优先级访问权限。 请求计算容量时，可以访问计算容量。 但是，仅当存在备用计算容量时，才会部署现成 VM。 仅当常规 VM 不需要基础硬件时，它们才会继续运行。
无可用性保证。 现成 VM 没有任何可用性保证或服务级别协议（SLA）。 现成 VM 可能会立即失去对计算容量的访问权限，也可以在部署或逐出后随时失去对计算容量的访问权限。 现成 VM 更便宜，因为它们可以逐出。 当 Azure 需要计算容量回来时，将发送逐出通知并逐出现成 VM。 在实际逐出之前，Azure 至少提前 30 秒发出通知。 有关详细信息，请参阅 持续监视逐出。
了解现成 VM 定价
现成 VM 最多可以比常规即用即付 VM 便宜 90%。 折扣因需求、VM 大小、部署区域和操作系统而异。 若要获得成本节省估算，请参阅 Azure 现成虚拟机定价工具 和 现成虚拟机定价概述。 还可以查询 Azure 零售价格 API，以编程方式获取任何 SKU 的现成定价。
了解可中断的工作负荷
现成 VM 非常适合可中断的工作负载，这些工作负荷共享多个常见特征。 可中断的工作负载具有最少的时间限制、低组织优先级和较短的处理时间。 它们运行进程，这些进程可能会突然停止，以后恢复，而不会损害必要的组织流程。 可中断工作负荷的示例包括批处理应用程序、数据分析和工作负荷，这些应用程序、数据分析和工作负荷为非生产环境创建持续集成和持续部署代理。 这些功能与具有 SLA、粘滞会话和有状态数据的常规工作负荷或任务关键型工作负荷进行比较。
可以在不可中断的工作负荷中使用现成 VM，但它们不应是唯一的计算容量源。 根据需要使用任意数量的常规 VM 来满足运行时间要求。
了解逐出
创建后，现成 VM 没有 SLA，并且可以随时失去对计算的访问权限。 我们将此计算损失称为 逐出。 计算供求驱动逐出。 当特定 VM 大小的需求超过特定级别时，Azure 会逐出现成 VM，使计算可供常规 VM 使用。 需求特定于位置。 例如，区域 A 中的需求增加不会影响区域 B 中的现成 VM。
现成 VM 有两个影响逐出的配置选项。 这些配置是现成 VM 的 逐出类型 和 逐出 策略。 创建现成 VM 时设置这些配置。 逐出类型定义逐出的条件。 逐出策略确定逐出对现成 VM 执行的操作。
逐出类型
容量更改或价格更改会导致逐出。 容量和价格更改影响现成 VM 的方式取决于创建 VM 时选择的逐出类型。 逐出的类型定义逐出的条件。 逐出类型 仅限容量的逐出，价格或容量逐出。
仅限容量的逐出： 此逐出类型在不再可用的超额计算容量时触发逐出。 默认情况下，价格上限为即用即付率。 如果不想支付超过即用即付 VM 价格，请使用此逐出类型。
价格或容量逐出： 此逐出类型具有两个触发器。 Azure 在不再可用计算容量或 VM 的成本超过你设置的最大价格时，会逐出现成 VM。 通过此逐出类型，可以设置远远低于即用即付价格的最大价格。 使用此逐出类型设置自己的价格上限。
逐出策略
为现成 VM 选择的逐出策略会影响其业务流程。 业务流程是处理逐出的过程，本文稍后将对此进行讨论。 逐出策略是 停止/解除分配策略 和 删除策略。
停止/解除分配策略：当工作负荷可以等待同一位置和 VM 类型内的释放容量时， 停止/解除分配策略是理想的。 停止/解除分配策略会停止 VM，并使用基础硬件结束其租约。 停止和解除分配现成 VM 与停止和解除分配常规 VM 相同。 VM 在 Azure 中仍可访问，稍后可以重启同一 VM。 VM 使用停止/解除分配策略丢失计算容量和非静态 IP 地址。 但是，VM 数据磁盘会保留并继续产生费用。 VM 还会占用订阅中的核心。 即使 VM 已停止或解除分配，也无法从其区域或区域移动。 有关详细信息，请参阅 电源状态和计费。
删除策略：如果工作负荷可以更改位置或 VM 大小， 使用“删除”策略。 更改位置或 VM 大小可使 VM 更快地重新部署。 删除策略将删除 VM 和任何数据磁盘。 VM 在订阅中不占用核心。 有关详细信息，请参阅 逐出策略。
灵活业务流程的设计
业务流程是在逐出后替换现成 VM 的过程。 它是构建可靠中断工作负荷的基础。 良好的业务流程系统具有内置的灵活性。 灵活性意味着设计业务流程以具有选项、使用多个 VM 大小、部署到不同区域、具有逐出意识，并考虑不同的逐出方案以提高工作负荷可靠性和速度。
速度设计
对于在现成 VM 上运行的工作负荷，计算容量至关重要。 由于可能逐出，请确保了解分配的计算时间，以便你可以做出明智的设计决策，确定工作负荷速度的优先级。 通常，应优化计算时间。 生成预装了所有所需软件的 VM 映像。 预安装的软件有助于最大程度地减少逐出和完全操作应用程序之间的时间。 避免对不参与工作负荷目的的进程使用计算时间。 例如，数据分析的工作负荷应将大部分计算时间集中在数据处理上，并尽可能少地收集逐出元数据。 从应用程序消除无性进程。
使用多个 VM 大小和位置
若要提高灵活性，请生成业务流程以使用多个类型和大小的 VM。 目标是提供业务流程选项来替换逐出的 VM。 Azure 具有不同类型的 VM 和大小，可提供相同价格的类似功能。 筛选最小 vCPU 或核心数、VM 的最低 RAM 和最高价格。 此过程可帮助你找到适合预算的多个 VM，并且有足够的能力来运行工作负荷。
每种类型的 VM 都有一个逐出率，其表示为百分比范围，例如 0%-5%、5%-10%、10%-15%、15%-20%或 20+%。 逐出率可能因区域而异。 对于不同区域中的相同类型的 VM，可能会发现更好的逐出率。 可以在门户中的“基本信息”选项卡下找到每种 VM 的逐出率。在 大小旁边，选择 查看定价历史记录 或 查看所有大小。 还可以使用 Azure Resource Graph 以编程方式获取现成 VM 数据。
在业务流程系统中，请考虑使用现成放置分数功能来评估单个现成部署成功的可能性。
有关详细信息，请参阅以下资源：
逐出率 - Resource Graph
- 现成放置分数
使用最灵活的逐出策略
被逐出的现成 VM 的逐出策略会影响更换过程。 例如，删除策略比停止/解除分配策略更灵活。
首先考虑删除策略：如果工作负荷可以处理删除策略， 使用删除策略。 删除允许业务流程将替换现成 VM 部署到新区域和区域。 此部署灵活性可帮助工作负荷更快地找到备用计算容量，而不是已停止或解除分配的 VM。 已停止或解除分配的 VM 必须等待其创建所在的同一区域中的备用计算容量。 对于“删除”策略，需要一个外部进程来监视逐出和安排到不同区域的部署、使用不同的 VM SKU，或者同时监视这两者。
了解停止/解除分配策略： 停止/解除分配策略的灵活性低于删除策略。 现成 VM 必须位于同一区域和区域中。 无法将已停止或解除分配的 VM 移到另一个位置。 由于 VM 具有固定位置，因此当计算容量可用时，需要准备好一些内容来重新分配 VM。 无法预测计算容量的可用性。 因此，应使用自动化计划管道在逐出后尝试重新部署。 逐出应触发计划管道，重新部署尝试应持续检查计算容量，直到其可用为止。
| 政策 | 何时使用策略 |
|---|---|
| 删除策略 | - 临时计算和数据 - 不想为数据磁盘付费 - 最小预算 |
| 停止/解除分配策略 | - 需要特定的 VM 大小 - 无法更改位置 - 长应用程序安装过程 - 无限期等待时间 - 不由成本节省驱动 |
持续监视逐出
监视是现场 VM 上的工作负荷可靠性的关键。 创建后，现成 VM 没有 SLA，可以随时逐出。 提高现场 VM 的工作负荷可靠性的最佳方式是预测何时将逐出它们。 如果有此信息，可以尝试正常关闭工作负荷并触发自动化来协调替换。
使用计划事件： 为每个 VM 使用计划事件服务。 当基础结构维护会影响 VM 时，Azure 会向 VM 发送信号。 逐出符合基础结构维护条件。 Azure 将
Preempt信号发送到所有 VM 至少 30 秒，然后才被逐出。 通过计划事件服务，可以通过在静态、不可路由的 IP 地址169.254.169.254查询终结点来捕获此Preempt信号。使用频繁的查询： 查询计划事件终结点通常足以协调正常关闭。 最多可以查询一秒的“计划事件”终结点，但对于所有用例来说，可能不需要一秒的频率。 这些查询必须来自在现成 VM 上运行的应用程序。 查询不能来自外部源。 因此，查询会消耗 VM 计算容量，并从主工作负荷中窃取处理能力。 你需要平衡那些相互竞争的优先级以满足你的特定情况。
自动执行业务流程： 收集
Preempt信号后，业务流程应处理该信号。 鉴于时间限制，Preempt信号应尝试正常关闭工作负荷，并启动一个取代现成 VM 的自动化过程。 有关详细信息，请参阅以下资源：
生成部署系统
业务流程需要自动化管道才能在逐出后部署新的现成 VM。 管道应在可中断的工作负荷外部运行，以帮助确保运行。 部署管道应根据为现成 VM 选择的逐出策略工作。
对于删除策略，建议生成一个管道，该管道使用不同的 VM 大小并部署到不同的区域。 对于停止/解除分配策略，部署管道需要两个不同的操作。 若要初始创建 VM，管道需要将适当大小的 VM 部署到正确的位置。 对于逐出的 VM，管道需要尝试重启 VM，直到 VM 正常工作。 Azure Monitor 警报和 Azure 函数的组合是自动执行部署系统的一种方法。 管道可以使用 bicep 模板。 它们是声明性的和幂等的，是基础结构部署的最佳做法。
准备立即逐出
Azure 可以在创建现成 VM 后以及在工作负荷运行之前立即逐出一个现成 VM。 在某些情况下，可能有足够的容量来创建现成 VM，但不会持续。 创建后，现成 VM 没有可用性保证或 SLA。 业务流程需要考虑立即逐出。
Preempt 信号提供至少 30 秒的逐出通知。
将 VM 运行状况检查合并到业务流程中，以准备立即逐出。 即时逐出的业务流程不能依赖于计划事件 Preempt 信号。 只有 VM 本身可以查询 Preempt 信号，并且没有足够的时间来启动应用程序、查询计划事件终结点并正常关闭。 因此，运行状况检查需要驻留在工作负荷环境之外。 运行状况检查需要监视现成 VM 的状态，并在状态更改为 解除分配 或 停止时替换现成 VM 的部署管道。
规划多个同时逐出
如果运行一组现成 VM，请构建工作负荷，以承受多个同时逐出。 可以同时逐出工作负荷中的多个现成 VM。 同时逐出多个 VM 可能会影响应用程序的吞吐量。 为防止这种情况，部署管道应能够收集来自多个 VM 的信号，并同时部署多个替换 VM。
设计正常关闭
VM 关闭过程应小于 30 秒，并允许 VM 在逐出之前关闭。 关闭所需的时间取决于工作负荷查询计划事件终结点的频率。 查询终结点的频率越长，关闭过程就越长。 关闭过程应释放资源、清空连接和刷新事件日志。 应定期创建和保存检查点以保留上下文并构建更高效的恢复策略。 检查点只是有关下一个 VM 需要启动哪些进程或事务的信息。 它们应指示 VM 是否应恢复上一个 VM 关闭的位置，或者新 VM 是否应还原更改并重新启动整个过程。 将检查点存储在现成 VM 环境之外，例如在存储帐户中。
测试业务流程
模拟逐出事件以在开发/测试环境中测试业务流程。 有关详细信息，请参阅 模拟逐出。
设计幂等工作负荷
建议设计幂等工作负荷。 多次处理事件的结果应与一次处理事件的结果相同。 尽管努力确保正常关闭，但逐出可能会导致强制关闭。 强制关闭可以在完成之前终止进程。 幂等工作负荷可以多次接收相同的消息，而无需更改结果。 有关详细信息，请参阅 幂等性。
使用应用程序预热期
大多数可中断的工作负荷运行应用程序。 应用程序需要时间来安装和启动。 它们还需要时间连接到外部存储并从检查点收集信息。 在允许应用程序开始处理之前，请具有应用程序预热期。 在预热期间，应用程序应启动、建立连接并准备参与。 仅允许应用程序在验证应用程序的运行状况后开始处理数据。
配置用户分配的托管标识
分配用户分配的托管标识以简化身份验证和授权过程。 通过用户分配的托管标识，可以避免将凭据放入代码中，并且不会绑定到单个资源（如系统分配的托管标识）。 用户分配的托管标识包含来自 Microsoft Entra ID 的权限和访问令牌，这些令牌可以在业务流程期间重复使用并分配给发现 VM。 跨现成 VM 的令牌一致性有助于简化业务流程，并简化对现成 VM 拥有的工作负荷资源的访问。
如果使用系统分配的托管标识，新的现成 VM 可能会从 Microsoft Entra ID 获取不同的访问令牌。 如果需要使用系统分配的托管标识，使工作负荷能够复原 403 Forbidden Error 响应。 业务流程需要从具有适当权限的 Microsoft Entra ID 获取令牌。 有关详细信息，请参阅 托管标识。
示例方案
示例方案部署一个队列处理应用程序，该应用程序限定为可中断的工作负荷。 方案中的脚本充当示例。 此方案指导你完成一次性手动推送以部署资源。 此实现没有部署管道。 但是，部署管道对于自动化业务流程至关重要。 下图显示了示例方案的体系结构。
以下工作流对应于上图：
VM 应用程序定义： 在 Azure 计算库中创建 VM 应用程序定义。 它定义应用程序名称、位置、操作系统和元数据。 应用程序版本是 VM 应用程序定义的编号版本。 应用程序版本表示 VM 应用程序。 它需要与现成 VM 位于同一区域。 应用程序版本链接到存储帐户中的源应用程序包。
存储帐户： 存储帐户存储源应用程序包。 在此体系结构中，它是一个名为
worker-0.1.0.tar.gz的压缩 tar 文件。 它包含两个文件。 一个文件是安装 .NET 辅助角色应用程序的orchestrate.shbash 脚本。现成 VM： 现成 VM 部署。 它必须与应用程序版本位于同一区域。 部署后，它将
worker-0.1.0.tar.gz下载到 VM。 bicep 模板在标准系列 VM 上部署 Ubuntu 映像。 这些配置满足此应用程序的需求，不是应用程序的一般建议。存储队列： .NET 辅助角色中运行的其他服务包含消息队列逻辑。 Microsoft Entra ID 使用基于角色的访问控制向用户分配的标识授予对 Azure 队列存储中的存储队列的现成 VM 访问权限。
.NET 辅助角色应用程序：
orchestrate.sh脚本安装运行两个后台服务的 .NET 辅助角色应用程序。 第一个服务查询计划事件终结点，查找Preempt信号，并将此信号发送到第二个服务。 第二个服务处理来自存储队列的消息，并侦听第一个服务的Preempt信号。 当第二个服务收到信号时，它会中断存储队列处理并开始关闭。查询计划事件终结点： API 请求发送到静态不可路由 IP 地址
169.254.169.254。 API 请求查询计划事件终结点以获取基础结构维护信号。Application Insights： 体系结构仅使用 Application Insights 进行学习。 它不是可中断工作负荷业务流程的基本组件，但允许你验证 .NET 辅助角色应用程序中的遥测数据。 .NET 辅助角色应用程序将遥测数据发送到 Application Insights。 有关详细信息，请参阅 从 .NET 应用程序启用实时指标。
部署此方案
有一个名为 可中断工作负荷的 GitHub 存储库，该存储库在现场 具有模板、脚本和部署此体系结构的分步说明。
下一步
相关资源
- 多租户解决方案中成本管理和分配的体系结构方法
- 在 Azure 上运行 Windows VM
- 在 Azure 上运行 Linux VM