Compartilhar via

什么是Azure Resource Manager?

Azure Resource Manager是用于Azure的部署和管理服务。 它提供了一个管理层,可帮助你创建、更新和删除Azure帐户中的资源。 使用访问控制、锁和标签等管理功能,在部署后保护和组织您的资源。

一致的管理层

通过任何Azure API、工具或 SDK 发送请求时,Resource Manager收到请求。 在将请求转发到适当的Azure服务之前,它会对其进行身份验证和授权。 由于所有请求是通过同一个 API 处理的,因此在所有不同的工具中会看到一致的结果和功能。

下图显示了在Azure请求期间Resource Manager扮演的角色:

展示在Azure请求期间Resource Manager角色的图示。

Azure portal中提供的所有功能也可通过 PowerShell、Azure CLI、REST API 和客户端 SDK 使用。 当 API 引入新功能时,此功能会在首次发布后的 180 天内反映在门户中。

重要

Resource Manager将于 2025 年 3 月 1 日停止支持 TLS 1.2 之前的协议。 有关详细信息,请参阅 迁移至 TLS 1.2 针对 Azure 资源管理器

术语

如果你不熟悉Resource Manager,则可能不熟悉以下术语:

  • 资源 - 通过Azure提供的可管理项。 资源示例包括虚拟机、存储帐户、Web 应用程序、数据库和虚拟网络。 资源组、订阅、管理组和标记也是资源。

  • 资源组 - 一个容器,用于保存Azure解决方案的相关资源。 资源组包括你想要作为一个组进行管理的那些资源。 根据最适合组织的情况来决定哪些资源属于哪个资源组。 请参阅 什么是资源组?

  • 资源提供程序 - 提供Azure资源的服务。 例如,Microsoft.Compute 就是一个常见的资源提供程序,它提供虚拟机资源。 Microsoft.Storage是另一个常见的资源提供程序。 请参阅 Azure 资源提供程序和类型

  • 声明性语法 - 一种语法,允许声明“以下是我想要创建的项目”,而不需要编写一系列编程命令来进行创建。 ARM 模板和 Bicep 文件是声明性语法的示例。 在这些文件中,定义要部署到Azure的基础结构的属性。

  • ARM 模板 - 一个 JavaScript 对象表示法 (JSON) 文件,用于定义一个或多个要部署到资源组、订阅、管理组或租户的资源。 使用模板以一致方式反复部署资源。 请参阅什么是 ARM 模板?,获取有关如何部署模板的概述。

  • Bicep 文件 - 用于以声明方式部署Azure资源的文件。 Bicep 是一种语言,旨在为 Azure 中的基础结构即代码解决方案提供最佳创作体验。 请参阅什么是 Bicep?了解有关 Bicep 的详细信息。

  • 扩展资源 - 是扩展另一资源的功能的资源。 例如,角色分配就是一种扩展资源类型。 可将角色分配应用于其他任何资源,以指定访问权限。 请参阅扩展资源

有关更多Azure术语定义,请参阅 Azure 基本概念

使用Resource Manager的好处

使用 Resource Manager,可以:

  • 通过声明性模板而非脚本来管理基础结构。

  • 以组的形式部署、管理和监视解决方案的所有资源,而不是单独处理这些资源。

  • 在整个开发生命周期内重复部署解决方案,并确保以一致的状态部署资源。

  • 定义各资源之间的依赖关系,使其按正确的顺序进行部署。

  • 将访问控制应用于所有服务,因为Azure 基于角色的访问控制 (Azure RBAC) 集成到管理平台中。

  • 将标记应用到资源,以逻辑方式组织订阅中的所有资源。

  • 通过查看共享相同标记的资源组的成本来阐明组织的计费。

了解范围

Azure提供四个级别的管理范围:管理组、订阅、资源组和资源。 下图可视化了这些层:

该图表说明了Azure中的四个范围层级:管理组、订阅、资源组和资源。

将在上述任何级别的作用域中应用管理设置。 所选的级别确定应用设置的广泛程度。 较低级别继承较高级别的设置。 例如,将策略应用于订阅时,该策略将应用于订阅中的所有资源组和资源。 在资源组上应用策略时,该策略将应用于该资源组及其所有资源。 但是,其他资源组没有该策略分配。

请参阅 什么是 Microsoft Entra ID?,以深入了解如何在 Azure 中管理身份和访问权限。

可以将模板部署到租户、管理组、订阅或资源组。

什么是资源组?

资源组是用于管理Azure解决方案的相关资源的容器。 使用资源组可以帮助协调相关资源之间的变化。 例如,可以将更新部署到资源组,并确信资源将以协同方式进行更新。 或者,完成解决方案后,可以删除资源组并知晓所有资源都已删除。

定义资源组时需要考虑一些重要事项:

  • 资源组中的所有资源应该具有相同的生命周期。 一起部署、更新和删除它们。 例如,服务器是一个资源。 如果它需要采用不同的部署周期,则它应在另一个资源组中。

  • 每个资源只能存在于一个资源组中。

  • 随时可以在资源组添加或删除资源。

  • 可以将资源从一个资源组移到另一个组。 有关详细信息,请参阅 将 Azure 资源移动到新的资源组或订阅

  • 资源组中的资源可以位于与资源组不同的区域,但我们建议使用相同的位置。 请参阅 我应该对资源组使用哪个位置?

  • 资源组可用于将访问控制的范围限定为管理操作。 可以使用 Azure policiesrolessource locks 来管理资源组。

  • 可以对资源组应用标记。 资源组中的资源不会继承这些标记。

  • 资源可以连接到其他资源组中的资源。 以下情况很常见:两个资源相关,但不具有相同的生命周期。 例如,你可以有一个连接到不同资源组中数据库的 Web 应用。

  • 删除一个资源组时,该资源组中的所有资源也会被删除。 有关 Resource Manager 如何协调这些删除的信息,请参阅Azure Resource Manager 资源组和资源删除

  • 最多可在每个资源组中部署 800 个资源类型实例。 某些资源类型不受 800 个实例限制的约束。 有关详细信息,请参阅资源组限制

  • 某些资源可能存在于资源组之外。 这些资源将部署到订阅管理组租户。 这些范围仅支持特定的资源类型。

  • 若要创建资源组,请使用 Azure portalPowerShellAzure CLIARM 模板

我应该为资源组使用哪个位置?

创建资源组时,需要提供该资源组的位置。

你可能想知道为什么资源组需要一个位置,以及即使资源可以位于资源组之外,资源组的位置为何仍然如此重要。

资源组存储有关资源的元数据。 当指定资源组的位置时,也就指定了元数据的存储位置。 出于合规性原因,你可能需要确保你的数据存储在某一特定区域。

通过资源组的位置路由所有控制平面操作可帮助资源组保持一致状态。 选择资源组位置时,建议选择靠近控制操作发源的位置。 通常情况下,此位置最靠近你。 此路由要求仅适用于资源组的控制平面操作。 这不会影响发送到应用程序的请求。

如果资源组的区域暂时不可用,您的资源请求将会故障转移到次要区域。 但是,如果多个区域遇到服务中断或资源的位置也不可用,则仍可能会受到影响。 为了减轻区域中断造成的影响,建议将资源和资源组定位在同一区域。 请参阅 Azure Resource Graph 表和资源类型引用列表以查看Resource Manager管理的资源和元数据。

Azure Resource Manager在发生区域服务中断期间提升可靠性,确保读写操作的高可用性,并将对客户的影响降至最低。 仅当资源组的主区域和备份区域受到影响时,才会发生服务中断。

资源管理器的复原能力

Resource Manager专为复原和持续可用性而设计。 REST API 中的 Resource Manager 和控制平面操作(发送到 management.chinacloudapi.cn 的请求):

  • 跨区域分布。 Resource Manager在每个Azure区域中都有一个单独的实例,这意味着,如果Resource Manager实例在一个区域中失败,这不会影响服务在另一个区域中的可用性;这同样适用于其他Azure服务。 尽管Resource Manager分布在各个区域,但某些服务是区域性服务。 这种区别意味着,虽然控制平面操作的初始处理具有弹性,但请求在转发到服务时可能会容易受到区域中断的影响。

  • 在拥有多个可用区的位置中,跨可用区(及区域)进行分布。 此分布可确保当某个区域丢失一个或多个可用区时,Resource Manager 可以故障转移到另一个可用区或区域。 它继续为资源提供控制平面功能。

  • 不依赖于一个逻辑数据中心。

  • 不会因为维护活动而停机。

此复原能力适用于通过Resource Manager接收请求的服务。 Azure Key Vault是一项受益于此一致性的服务。

建议使用全局终结点 management.chinacloudapi.cn 进行Azure Resource Manager路由,因为它支持基于 DNS 的流量分布、自动故障转移和最接近或最健康的区域路由,从而提高全球用户的延迟和可靠性。 全局终结点通常会导致更快的响应时间,因为用户被定向到最近的可用区域,从而减少网络跃点和延迟。

解决并发操作

并发资源更新可能会导致意外结果。 当两个或多个作尝试同时更新同一资源时,Resource Manager检测到冲突,只允许一个作成功完成,阻止其他作,并返回错误。 此解决方案可确保更新是确定和可靠的;你可以了解资源的状态并避免任何不一致或数据丢失。

例如,如果有两个请求(A 和 B)尝试同时更新同一资源,而请求 A 在请求 B 之前完成,则请求 A 会成功,但请求 B 会失败。 请求 B 返回 409 错误。 获得此错误代码后,可以获取资源的更新状态,并确定是否要重新发送请求 B。

后续步骤