Microsoft AZ-104: Azure 虚拟机和计算 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

属于 Microsoft Azure Administrator Associate AZ-104 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 虚拟机 (VM) 为 Windows 和 Linux 工作负载提供弹性的计算能力，并能对大小、存储、可用性、网络、安全性和生命周期管理进行精细控制。管理员必须了解大小系列、可用性构造、规模自动化、spot 容量、扩展、存储模型、专用主机、备份和安全访问模式，以满足可靠性、性能和成本目标。

计算选项和大小调整

VM 大小系列针对不同的工作负载配置文件。通用型（Dv、Ev、B 系列可突发）平衡了 vCPU 与内存的比率，适用于 Web 服务器、小型数据库和应用服务器。计算优化型（Fsv2、用于 HPC CPU 密集型工作负载的 HB/HBv2）最大化了每 GB 的 vCPU 数量，并针对高时钟速度进行了优化，适用于无状态 API 层、批处理工作程序和游戏服务器。内存优化型（Ev5、Mv2/Mv3）提供更高的每 vCPU 内存，支持内存中缓存、分析引擎和大型数据库。GPU VM（用于可视化的 NV、NVv4；用于 CUDA/AI 训练和推理的 NC/ND）包含 NVIDIA GPU，部分 SKU 支持 vGPU 分区以提高密度和成本效益；应通过扩展来验证和固定驱动程序及框架的兼容性。

升级和重设大小操作受目标集群中硬件可用性的限制；如果容量受限，重设可用性集中某个 VM 的大小可能会因分配错误而失败。通过允许跨硬件进行放置，先解除分配该集中的所有 VM，然后再重设大小通常会成功。当需要静态内部 IP 时，应在 Azure 的 NIC 配置中分配，而不是在来宾操作系统内部。

Azure Dedicated Hosts 将您的 VM 放置在单租户物理服务器上，以实现主机级别的隔离、合规性和可预测性。主机组定义了一个区域中的主机集合，可以跨可用区和主机容错域，以分散主机故障和维护的风险。主机组内的主机容错域可确保 VM 分布在不同的物理机架上。许可权益包括通过 Software Assurance 或 Azure Hybrid Benefit 引入 Windows Server/SQL Server 许可证，以及选择按主机（对 SQL Enterprise/Windows Datacenter 有用）而非按 VM 许可，这可能降低密集整合的成本。

可用性、规模和成本优化

可用性集可防止数据中心内的硬件故障和计划内维护。VM 分布在不同的容错域（独立的电源/机架）和更新域（维护批次）中。典型限制是最多 3 个容错域和 20 个更新域；部署至少两个实例以获得 99.95% 的 SLA。可用区通过将资源放置在同一区域内物理上独立的数据中心建筑中来提供更高的弹性；跨区域部署两个或更多 VM 可获得 99.99% 的 VM SLA。可用区需要区域感知的资源，跨区域流量使用 Standard SKU 的负载均衡器或应用程序网关；需要规划区域内的数据传出费用。

Virtual Machine Scale Sets (VMSS) 可编排具有集成自动缩放和健康管理功能的同构或异构 VM 群集。统一业务流程使用具有单个 VM 配置文件的规模集模型，并与 Azure Load Balancer 或 Application Gateway 本机集成。灵活业务流程支持多样化的 VM SKU 和实例个性化，可与可用性集/可用区结合使用，适用于有状态或混合角色的工作负载。升级模式决定了部署行为：手动（管理员触发升级）、自动（模型更改时平台更新所有实例）和滚动（分批进行，带有健康探测、批次间暂停和故障阈值）。自动缩放策略响应指标（CPU、通过 AMA 获取的内存、队列长度、自定义指标）、计划或两者；定义最小/最大/期望容量、冷却时间和缩减策略（例如，优先缩减最新的 VM）以控制实例抖动。对于大规模的入站管理，请在公共或内部 Standard Load Balancer 上使用负载均衡器入站 NAT 池。健康探测应针对实际的服务端口和协议；对于使用内部负载均衡器的 SQL Always On，应在侦听器端口上使用 TCP 探测而不是 HTTP。

Azure Spot VM 利用未使用的 Azure 容量，以极大的折扣提供，但没有可用性保证。当容量被回收或市场价格超过您的最高价格时，会发生逐出；您可以将逐出策略设置为“解除分配”（保留磁盘以便在有容量时重新启动）或“删除”（逐出时销毁）。它们与 VMSS 和 Standard Load Balancer 集成，用于无状态扩展。合适的用例包括批处理、CI/CD 运行器、渲染、模糊测试以及可容忍中断的大规模无状态 Web 场。避免将 Spot 用于单实例生产环境或没有检查点机制的有状态层。价格上限可防止支付超过您的阈值；如果需求激增，预计会有更高的逐出率。

实践中的可用性构造与 SLA

当您需要数据中心内冗余和共享存储后端，且不需要区域性放置时，请选择可用性集。对于要求楼宇级故障隔离和更高 SLA 的任务关键型服务，请选择可用性区域。对于横向扩展服务，将 VMSS 与区域结合使用以实现均匀分布和自动修复；将健康探针固定到工作负载端口，并利用滚动升级来降低风险。请理解，单个 VM（即使配备 Premium SSD）提供的 SLA 也低于多实例部署。对于成本敏感的无状态层，可在 Standard Load Balancer 后面整合一个 Spot VM 池，并设置保守的逐出和缩减策略以保护基线容量。

实际问题场景

Contoso Ltd. 运营一个多层 Web 应用程序，该程序包含一个无状态 API、一个有状态 Redis 缓存和一个 SQL Server Always On 可用性组。他们必须提高对区域性中断的恢复能力，降低 API 层的计算成本，在没有公共 IP 的情况下保护管理员访问安全，并标准化监控和备份。

在中心-辐射型拓扑中创建三个子网：一个共享管理子网（中心）、一个 Web/API 子网（辐射）和一个数据子网（辐射）。在中心的 AzureBastionSubnet (/26) 中部署 Azure Bastion Standard，并配备一个 Standard 公共 IP。理由：Bastion 支持通过 TLS 进行 RDP/SSH 连接，而无需在任何 VM 上暴露公共 IP，并且 Standard SKU 支持跨对等 VNet 的基于 IP 的连接，从而集中化管理员访问。
将 API 层部署为跨可用性区域 1、2 和 3 的 VM Scale Set (Uniform)，并配备一个 Standard Load Balancer。启用加速网络并设置自动缩放规则，在平均 CPU > 65% 持续 10 分钟时增加实例，在 < 35% 时移除实例，并设置冷却时间。在同一规模集内使用 Flexible 编排或一个配套规模集添加一个辅助 Spot VM 池，配置最高价格和 Deallocate 逐出策略。理由：VMSS 加区域可提供 99.99% 的 SLA 和自动修复；Spot 容量可削减突发负载的成本，而 Deallocate 策略则保留磁盘以便快速重用。
在一个可用性集中部署 2 个以上实例的 Redis 缓存 VM，并使用 Premium SSD。将故障域固定为 2 个，并依赖平台的 20 个更新域。理由：缓存是有状态的但可以复制；可用性集提供机架和维护隔离，而不会产生跨区域延迟的代价。
在每个区域（区域 1 和 2）部署两台参与 Always On 可用性组的 SQL Server VM。将它们放置在跨越两个区域和两个主机故障域的主机组内的 Azure Dedicated Hosts 上。为 AG 侦听器配置一个内部 Standard Load Balancer，并在侦听器端口（例如 1433）上设置 TCP 探针。理由：Dedicated Hosts 提供主机级别的隔离和许可效率（按主机计算 SQL 许可），而区域性放置和 TCP 健康探测则与 SQL 侦听器的要求保持一致。
通过包含强化版操作系统镜像的 Azure Compute Gallery 来标准化镜像。使用 Custom Script Extension 安装应用程序先决条件，并使用 DSC 扩展来强制执行 Windows 功能状态和注册表基线。理由：Gallery 镜像确保一致的预配；扩展可实现可重复的配置和漂移控制。
通过 Data Collection Rules 配置 Azure Monitor Agent，以将访客指标和日志发送到 Log Analytics 工作区。根据需要启用连接监控和依赖关系图。理由：AMA 是当前的代理，支持精细路由，并且是现代监控功能和超越 CPU 的 VMSS 指标驱动自动缩放所必需的。
在一个 Recovery Services 保管库中使用 Azure Backup 保护所有 VM，采用两种策略：Tier-1 策略，为 API/缓存提供每日备份和 30 天保留期；Tier-0 策略，为 SQL 提供每日加每周/每月保留期，并采用应用程序一致性快照。通过对跳转 VM 执行文件级恢复以及对过渡网络执行完整 VM 恢复来测试还原。理由：分离的策略与数据关键性和 RPO/RTO 相匹配；文件恢复和 VM 恢复涵盖了勒索软件和灾难场景。
在 Azure NIC 级别为 SQL 和 Redis 的 NIC 分配静态私有 IP；将 API 实例保持在负载均衡器后面的动态状态。在每个子网上应用单个 NSG 以强制执行统一规则。在繁忙的层上启用加速网络。理由：NIC 级别的静态分配为有状态层保留了地址；子网级别的 NSG 最大限度地减少了规则蔓延；加速网络减少了延迟和 CPU 开销。

该设计通过恰当组合区域和可用性集，利用 Spot 实现无状态扩展，通过 Bastion 强制执行零信任管理访问，以及跨各层标准化配置、监控和备份，从而满足了可用性、成本、安全性和运营目标。

← Azure 订阅、治理和成本管理 · 所有领域 · Azure 虚拟网络 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →