Microsoft Azure 资源组：简介与最佳实践
Azure 资源组是一项 Microsoft Azure 服务，需要对所有 Azure 虚拟机 (VM) 进行分组。在本文中，我们将深入探讨这一组结构的实际含义，以及如何利用它来实现更好的治理，并更有效地管理基础设施中的 Azure 资源。
首先，让我们简要概览一下如何通过 Azure Resource Manager 来管理和配置资源组，您可能已经很熟悉它了，因为它是资源的管理层。借助 Azure Resource Manager，可以通过声明式模板而不是脚本来管理基础设施，并实现标签管理、部署模板、依赖关系映射、简化的基于角色的访问控制，以及更清晰的成本管理。
您可以组织资源组来保障安全、进行管理，并跟踪与工作流程和应用相关的成本。
Azure 资源组是 VM、存储空间、虚拟网络、应用程序、数据库和数据库服务器的逻辑集合。您可以使用它们对应用程序的相关资源进行分组，并将它们分成生产和非生产组，或者您喜欢的任何其他组织结构。
Azure 资源组管理模型提供了四个级别的管理“范围” ，用于组织您的资源：
- 管理组：这些组是用于管理多个订阅的访问、策略和合规性的容器。某个管理组中的所有订阅都会自动继承应用于该管理组的条件。它们通常用于按内部部门或地理区域对订阅进行分组。
- 订阅：订阅将用户帐户与这些用户帐户所创建的资源关联起来。每个订阅都对您能够创建和使用的资源数量设有限制或配额。组织可以使用订阅来管理成本，以及由用户、团队或项目创建的资源。通常，一个订阅就对应一个应用程序。
- 资源组：资源组是一个逻辑容器，用于部署和管理 Azure 资源，例如 Web 应用、数据库和存储帐户。
- 资源：资源是您创建的服务实例，例如虚拟机、存储空间或 SQL Database。
在管理这些范围时，有一个重要因素需要牢记，那就是 Azure 订阅与管理组之间是有区别的。管理组不能包含 Azure 资源。它只能包含其他管理组或订阅。Azure 管理组提供了比 Azure 订阅更高一级的组织层级，例如，如果一个订阅代表一个应用程序，那么一个 Azure 管理组可能包含该部门管理的所有应用程序。此外，Azure 中没有“嵌套式”资源组的结构，如果您想通过“嵌套”方式来管理权限，需要结合前面提到的各个层级来设置权限。还要注意区分 Azure 资源组与“Azure 可用性集”这两个概念。Azure 中的可用性集是一个虚拟机 (VM) 的逻辑分组，用来告知 Azure 您的应用程序是如何构建的，从而保护应用程序的可用性。
创建 Azure 资源组的方法有多种：
- Azure 门户
- Azure PowerShell 脚本
- Azure CLI
- ARM 模板
以下是使用 Azure 资源组的一些最佳实践：
- 同一资源组中的资源应具有相同的生命周期。例如，如果某个应用程序需要多个需要一起更新的资源（如 SQL Database、Web 应用或移动应用），那么将这些资源归入同一个资源组是合理的。然而，对于 DevTest、预生产或生产环境，由于这些环境中的资源生命周期不同，使用不同的资源组或创建新的资源组就显得非常重要。
- 资源可以被添加到或从 Azure 资源组中删除。然而，每个资源都必须属于某个 Azure 资源组，因此如果您想将资源从一个资源组移动到另一个资源组，必须先将它们从原始资源组中移除，然后再添加到新的资源组中。
- 并非所有资源都可以移动到不同的资源组。
- 包含在资源组中的资源可以位于不同的 Azure 区域，甚至可以与资源组本身所在的区域不同。然而，有时最佳实践是将资源组中的所有资源保持在同一地区，以减少延迟或跨区域数据传输。无论如何，资源组需要一个位置来指定元数据的存储位置，这对于某些合规策略是必要的。
- 通过资源组授予访问权限。您应该使用资源组来控制对资源的访问，稍后将详细介绍访问控制。
- 删除资源组时，组内所有资源都会被删除。
- 每个资源组最多可部署 800 个资源类型实例，但也有例外。
准备好自动优化 Azure 资源组了吗？
Azure 资源组是一种实施基于角色的访问控制 (RBAC) 的方法。通常，您会希望在资源组层级授予用户访问权限，使用组可以更容易管理权限，并提供更高的可见性。
我们向首席信息官 (CIO) 推荐的顶级云最佳实践之一是，为您的组织建立一个能够支持战略的结构。然后，组织 Azure 资源的方式应遵循组织结构，这样就可以轻松遵循最小权限原则，只授予所需的最低权限，而这些权限可以在资源组层级进行管理，而不必在管理组或订阅层级操作。例如，与加密密钥管理相关的策略可以应用于管理组层级，而定期暂停策略则可能应用于资源组层级。
有效使用标签可以让您出于技术、自动化、计费和安全等目的识别资源。标签的应用可以超越资源组，这使您能够使用标签将属于同一项目、应用程序或服务的组和资源关联起来。务必遵循标签的最佳实践，例如在部署资源之前要求应用一套标准标签，以确保在优化资源使用。
组织订阅和资源组有几种常见方式。第一种、也是不幸常见的一种，是“混乱”模型。如果这个词描述了您的环境，不要灰心。我们见过许多组织经历这些成长阵痛，最终将其环境整理得井井有条。
另一种方式是按应用程序组织。例如，一个薪资或计费应用程序会对应一个单独的 Azure 云订阅，每个环境（开发、测试、预生产等）都有相应的资源组，并归属于该订阅之下。
我们也经常看到按环境组织的结构。在这种情况下，生产环境有一个订阅，开发环境有一个订阅，测试环境有一个订阅，每个订阅下的资源组对应各个应用程序。最成熟的组织方式是按业务单元或服务单元组织，这种模型将资源的所有权分配给企业职能。例如，财务部门拥有一个订阅，市场部门拥有另一个订阅。在这些订阅之下，将有对应各个应用程序的资源组。
Azure 资源组及其他云供应商原生的结构能够帮助有效地组织和管理云资源。在创建好基础并使用 Azure 资源组来为您的业务和运行的应用程序提供所需的分段和对齐后，下一步是开始有效地将资源与应用程序需求匹配。通过这样做，您将能够在优化资源成本的同时，最大化应用程序的性能。
确保应用程序性能并优化您的云环境已经超出了人工可管理的范围，这也是为什么 IBM 将使命专注于管理任何应用程序在任何云上、任何规模下的性能、合规性和成本。
Turbonomic 软件可以让您更轻松地以可视方式查看订阅与资源组之间的父子关系。这一能力有助于直观地映射出组织已实施的框架，使您能够在已建立的应用程序上下文中查看基础设施。Turbonomic 软件会自动发现所有相关的 Azure 订阅、各订阅下的资源组及其内部的资源，包括 Azure 虚拟机 (VM)、Azure 托管磁盘、Azure SQL Server，以及任何保留实例 (RI)，无论是共享 RI 还是针对某个订阅或资源组的 RI。随后，Turbonomic 软件将分析每个资源的使用情况，并开始生成优化操作。此视图显示了单个 Azure 订阅及其下的若干 Azure 资源组的详细情况，每个资源组的待优化操作，以及这些操作可能带来的潜在节省。
此外，Turbonomic 软件还包含一个强大的优化建模引擎，旨在让客户在安全的沙盒模式下对云环境进行不同场景的建模。例如，可以模拟在对资源组中的工作负载进行适当规模调整后，Azure 保留虚拟机实例库存利用率的影响，并与未进行适当调整规模的情况进行对比。