Azure-Arc-Kubernetes-和服务器教程-一-Azure Arc Kubernetes 和服务器教程（一）

Azure Arc Kubernetes 和服务器教程（一）

原文：Azure Arc-Enabled Kubernetes and Servers

协议：CC BY-NC-SA 4.0

一、作为 Azure 控制平面的扩展的 Azure Arc

欢迎阅读本 Azure Arc 支持的 Kubernetes 和服务器书的第一章。总的来说，这本书将带你进入支持 Azure Arc 的 Kubernetes 和支持 Azure Arc 的服务器的世界。Azure Arc 有许多产品，我们希望在本书中重点介绍 Azure Arc 的 Kubernetes 和服务器产品，以便在两个重点主题上为您提供最大的价值。

在我们深入 Azure Arc 产品本身之前，理解 Azure Arc 如何适合作为 Azure 控制平面的扩展是很重要的。这就是我们在本章要探讨的内容。这将有助于建立本书剩余章节的基础知识。

混合、多云和边缘

混合云、多云和边缘云计算都是快速增长的领域。让我们简要地定义一下它们是什么:

混合云

混合云将内部数据中心(私有云)与公共云相结合，为组织创建单一的云环境。混合云为您提供公共云和内部部署(也称为私有云)之间的工作负载可移植性。混合云允许企业根据需要为每个工作负载选择最佳计算位置。

多层

多云是指企业结合使用来自不同云提供商的两个或更多公共云。多云不是由单个云提供商提供的。多云通常是几个或更多主要云提供商的组合:亚马逊网络服务(Amazon Web Services)、谷歌云平台(Google Cloud Platform)、微软(Microsoft)、阿里巴巴(Alibaba)和 IBM。

边缘云计算

边缘云计算是将云服务、计算和数据存储扩展到数据源或其附近。边缘云计算节省带宽，非常适合有延迟问题的工作负载。物联网和数据密集型工作负载是边缘云计算的常见用例。

查看这些领域的一些统计数据以了解增长情况非常重要。每年发布的一个重要资源是《Flexera 云状态报告》。这份报告对所有与云相关的内容进行了细分，并给出了一些关于企业在云领域所发生的事情的硬性统计数据。让我们来看看 Flexera 2021 年云状态报告中的一些统计数据。

企业正在采用混合云

87%对 Flexera 2021 云状态报告做出回应的企业报告采用了混合云战略。
企业正在拥抱多云

93%对《Flexera 2021 年云状态报告》做出回应的企业表示拥有多云战略。他们还报告说，在他们的战略中结合了公共云和私有云。
企业正在拥抱边缘云计算

49%对 Flexera 2021 云状态报告做出回应的企业正在试验或计划使用边缘服务。

综上所述，大多数企业都采用混合云作为他们的云模型，其中包括多云。下图来自 Flexera 2021 年云状态报告，显示了这一点。

img/506033_1_En_1_Fig1_HTML.png

图 1-1

Flexera 2021 年云状态报告中使用的云类型图表

这证明了云计算的增长是在混合、多云和边缘云计算领域。

Azure Arc 概述

正如我们在上一节中看到的，在当今的技术世界中，对混合云、多云和边缘云计算的需求日益增长。随着工作负载在混合云、多云和边缘云计算环境中运行，管理它们的复杂性也在增加。

2019 年，在微软的大型技术大会上，微软 Ignite 公布了 Azure Arc。Azure Arc 将 Azure 功能扩展到 Azure 之外的环境，如内部数据中心和其他私有云和公共云。Azure Arc 通过将 Azure Resource Manager (ARM)及其管理工具带到各种环境中来简化复杂的分布式环境，而不管它们在什么云上。Azure Arc 为技术团队提供了部署工作负载和管理资源的能力，无论它们位于何处。

Arc 是对企业内部和多云管理需求日益增加的复杂性的回应。Azure Arc 使您能够在上创建和管理资源以及工作负载

内部
非 Azure 云(即 GCP、AWS、阿里巴巴等。)
私有云
微软混合(Azure Stack Hub、Azure Stack HCI、Azure Stack Edge)

Arc all up 由多种产品组成，有助于满足组织的各种多环境需求。以下是 Azure Arc 提供价值的三个关键领域:

一致性

Arc 为您提供一致的资源和工作负载治理、库存和管理。

零接触合规性和配置

借助 Arc，您可以获得跨资源和工作负载(如服务器、Kubernetes 等)的零接触合规性和配置。

统一体验

Azure Arc 为您提供了跨环境和资源/工作负载的单一面板和单一控制平面的统一体验。通过 Azure 门户、Azure CLI、Azure PowerShell 或 Azure REST API 的管理，无论工作负载和资源在哪里运行，都使用相同的工具。

现在，Azure Arc 将 Azure 服务扩展到运行在 Azure 之外的资源和工作负载。基于 Azure Arc 产品，扩展的服务会有所不同。这里列出了许多可以通过 Azure Arc 扩展的 Azure 服务:

管理组
捐款
资源组
基于角色的访问控制
磨尖
安全中心/Azure Defender
蔚蓝哨兵报
Azure 密钥库
Azure 策略/Azure 策略来宾配置
Azure 备份
更新管理、变更跟踪和清单
Azure 监视器
Azure 自动化
在 Azure 门户中查看和访问
Azure SDK
ARM 模板
更多

目前，在管理支持 Azure Arc 的服务器和支持 Azure Arc 的 Kubernetes 时，Azure Arc 是免费提供的。Azure Arc 控制面板功能免费提供。被视为 Azure Arc 控制平面一部分的服务有

将服务器和 Kubernetes 集群附加到 Azure
通过 Azure 管理组和标记进行资源组织
通过资源图进行搜索和索引
通过 Azure RBAC 和 Azure 订阅的访问和安全性
通过修补程序管理进行补丁管理
通过 ARM 模板和 Azure 扩展的环境和自动化

Azure Arc 产品

当 Azure Arc 推出时，它提供了一些产品，第一个是支持 Azure Arc 的服务器。自发布以来，微软一直在快速向 Arc 添加额外的产品，并扩展当前产品的功能。Azure Arc 产品分为两类。基础设施是您运行工作负载的基础设施。服务是通过 Arc 从 Azure 扩展出来的 Azure 服务。第一类是基础设施，第二类是服务。Azure Arc 产品及其能够管理的资源类型包括:

基础设施

**服务器:**支持 Linux 和 Windows，支持裸机服务器、本地服务器、AWS EC2 虚拟机、GCP 计算机引擎虚拟机、VMWare 虚拟机和 Hyper-V 虚拟机
支持 Azure Arc 的 SQL Server: 从 Azure 管理 SQL Server 的实例，将 Azure 服务扩展到 Azure 外部托管的 SQL Server 实例
Kubernetes: 内部 Kubernetes 集群、Rancher K3s、AWS EKS 集群、GCP GKE 集群
**Azure Arc 物联网:**通过支持 Azure Arc 的 Kubernetes，在边缘集中管理和部署物联网工作负载

服务

img/506033_1_En_1_Fig2_HTML.png

图 1-2

Azure Arc 产品

**数据服务:**在 Azure 之外运行 Azure 数据服务，包括 SQL 托管实例和 PostgreSQL。
**Azure Arc with light house:**Azure Arc 和 Azure Lighthouse 的组合，用于将灯塔管理功能扩展到非 Azure 环境。
带有 Azure Arc 的 Azure 应用服务: Azure 应用 PaaS 服务(App service，Functions，Logic Apps，Event Grid，API Management)和其他 PaaS 服务可以通过 Arc 在任何 Kubernetes 集群上运行。

我为什么要为我的组织使用 Azure Arc？

多云架构通常更加复杂，管理起来也更加困难。根据 Flexera 2021 年云状态报告，68%的受访企业目前没有使用多云管理工具。只有 32%的企业在利用多云管理工具。该报告还涵盖了多云治理、安全性和成本管理工具统计数据。这些其他领域的比例也很低。这意味着多云管理工具有巨大的增长机会。微软开始用 Azure Arc 来填补这一空白。

用例

以下是一些对使用 Azure Arc 有意义的用例:

法定管辖权

法律要求某些工作负载在特定地区、国家等地处理和保留数据。，需要跨多个数据中心和云提供商的基础架构。

等待时间

一些工作负载具有延迟要求，必须通过将工作负载定位在特定地理位置来满足这些要求。

传统基础设施

一些传统基础设施陈旧且具有挑战性，有时无法迁移到云中。Arc 可以将云扩展到本地传统基础设施。

可用性

能够跨多个云提供商甚至内部运行相同的服务，以便在云提供商或内部停机时实现更高的可用性。

开发者选项

能够让开发人员选择在最适合他们需求的环境中运行工作负载。

边缘计算需求(本地)

随着组织不断扩大其优势和本地工作负载运行范围，如商店、仓库、工厂、现场等。，扩展云和集中化管理可以降低跨边缘位置管理的复杂性。

混合云场景

当提到利用 Azure Arc 时，组织有许多场景。让我们来看一下其中的一个场景。在本例中，该组织正在运行一个基于容器的 web 应用，该应用的组件分布在 Azure 云和他们的内部数据中心。

在这个特定场景中，组织需要为将从内部使用 web 应用的用户提供低延迟，并且他们希望公共流量进入 web 应用；作为云运行在 Azure 上可以更好地处理外部流量负载。

该组织利用 Azure Arc 来管理内部 Kubernetes 集群和基于云的 Azure Kubernetes 服务(AKS)集群。他们还利用 GitOps 来确保内部 Kubernetes 集群和基于云的 AKS 集群配置和应用部署始终匹配。此外，他们还利用 Azure Container Instance (ACI)在 AKS 集群上按需提供非常快速的突发容量。下图显示了这个基于混合的应用的架构。

img/506033_1_En_1_Fig3_HTML.png

图 1-3

在混合云模式下运行的基于容器的 web 应用

摘要

这使我们结束了第一章。在本章中，我们花时间了解了混合、多云和边缘区域，以及管理它们所带来的挑战。我们对 Azure Arc 进行了概述。我们深入 Azure Arc 的产品，让大家了解 Azure Arc 是由什么组成的。我们最后探究了为什么您的组织可能会采用 Azure Arc。这一切都是为了给你一个 Azure Arc 知识的坚实基础，以帮助你进一步开始本书的剩余章节，更深入地进入混合、多云、edge 和 Azure Arc 的世界。

二、Azure 资源管理器洞察

介绍

在这一部分，我们将研究微软 Azure 中的 Azure 资源管理器或“ARM”平台管理层。我们将讨论它是什么，它是如何工作的，你可以用它做什么，以及如何在你的 Azure ARC 部署和 Azure 中的其他实现项目中有效使用它的技巧和诀窍。

什么是 Azure 资源管理器？

ARM 的核心是 Azure 的部署和管理服务。它允许创建、配置和管理资源，如虚拟机或虚拟网络，以及平台即服务或“PaaS”，如 Azure App Service、ARC 和 Azure SQL 等产品。

在 Azure 的初期，一个被称为 Azure 服务管理器或“ASM”的管理和结构系统被实现来管理平台。这个不成熟的系统很快暴露了它在治理、安全控制、资源组织、结构和环境管理方面的局限性。

ASM 最终被称为 Azure 资源管理器或“ARM”的更灵活、更强大的管理层所取代。然而，ASM 仍然存在于 Azure 环境中，基于 ASM 的资源被称为“经典”

ARM 管理层本质上执行一些任务，如创建资源并使用身份和访问控制(IAM)来管理它们，使用标记进行组织和分组，或者添加锁来防止未经授权的更改。

把 ARM 想象成你和 Azure 之间的解释器。你告诉它你想做什么，它就知道怎么做。

ARM 使你能够在 Azure 平台内部执行许多任务。它允许通过声明方式而不是静态脚本或其他动作来管理基础设施。这意味着您可以作为一个组来部署、管理、配置和监控资源，而不是试图单独管理它们。例如，您可以将定义的访问控制设计应用于一组资源，而不必单独配置每个资源，从而节省时间并减少潜在的人为错误。

这种方法不仅允许对资源范围进行更简单的管理，还允许您轻松地将同一组资源重新部署为另一个单独部署的一部分。当您需要使用生命周期方法为解决方案部署资源时，这非常方便，在生命周期方法中，您可能首先从开发环境开始，然后在最终进入生产环境之前转移到测试或 QA 环境。

在决定你的 Azure 部署策略时，你需要考虑很多不同的因素。

首先，一旦你开始走上一条路，有时很难改变方向。例如，如果您决定使用 PowerShell 脚本部署资源，但后来又决定改用其他部署方法，如 Terraform，那么这种改变可能会非常困难，并且可能需要付出大量的努力。花些时间回顾这些选择，并决定最适合你的道路。

考虑技术投资。走这条路你需要买什么？您需要构建和托管服务器吗？您需要购买软件许可吗？您是否需要第三方服务？你需要培训你的团队吗？成本是什么，价值是什么？

此外，组织未来的云采用计划是什么？Azure 的计划是什么？你有路线图可循吗？有哪些外部环境可能会推动 Azure 的采用或消费？公司是否需要在近期规划一个数据中心出口或关闭一个关键位置？

你的员工也是你项目成功的关键。您的团队中谁拥有使用工具、服务或应用所需的知识？是否存在技能差距？你将如何关闭它？将来，您将如何管理知识文档并将其转移给新的或初级的资源？

请记住，您在这里的选择不仅会影响使用 ARM 部署基础架构资源的团队，还会潜在地影响您的应用开发或数据和分析团队在将解决方案部署到 Azure 环境时的工作方式。一定要让每个人都尽早参与进来，这样每个观点都会得到考虑，并做出最佳选择。

这些都是关键领域，在规划你的路线之前，需要整个组织的思考、讨论和集体决策。

其次，预先计划好你真正想用 Azure 做什么是成功的关键。在你至少定义了基本需求、资源列表和路线图之前，你不应该在 Azure 中构建任何东西。

你会把 Azure 只用于网络应用，还是只用于数据分析？你会将数据中心扩展到环境中，并使用 Azure 来操作和管理整个组织的核心基础设施吗？

每一个不同的场景都会让你走上一条不同的道路，并且需要非常不同的资源来完成。

理解手臂

ARM 采用标准层次结构，具有五个级别的作用域，每一级都继承上一级的设置。

img/506033_1_En_2_Fig1_HTML.png

图 2-1

Azure 管理范围

层次结构的顶端是 Azure 租户。这通常也称为“注册”或“目录”从我们组织讨论的角度来看，名字其实并不重要。它只是层次结构的最高级别。

通常用于结构、管理、策略或其他更广泛的管理的第一个范围级别是管理组。该层级通常包含订阅，但在不同地理政治区域(如北美与欧洲或亚太地区)可能有不同策略的情况下，也可以有多层管理组。

设置可以应用于层次结构中的任何级别，但是用于治理和/或安全性的访问控制、权限和策略通常会在管理组中创建，以便它们由订阅和结构中低于它们的所有内容继承。

img/506033_1_En_2_Fig2_HTML.png

图 2-2

Azure 层次结构

这种具有继承性的分层方法支持在多个级别上配置和管理 Azure 环境，持续的限制性策略从全局或公司范围的配置向下移动到应用于非常特定的资源集的高度特定的策略集。

Key Definitions

租户/目录/注册:这是 Azure 的顶层组织。它将组织作为一个整体来表示，所有其他结构(如管理组和订阅)都属于租户。

管理组:位于结构顶部的组织对象，包含订阅和层次结构中低于订阅的所有内容。

订阅:Azure 中的一个逻辑构造，包含资源组，代表许多不同方面或管理和组织的边界。

Policy:Azure 中的一个构造，它允许创建需求规范，这些规范可以审计正确的配置，防止错误配置，或者改变资源的配置。

Geography :代表不同的地理区域，可能有不同的主权要求/政策，例如欧洲。

在设计组织结构时，需要考虑管理团队的一些限制。

表 2-1

管理组限制

资源

限制

| | --- | --- | | 每个租户的管理组 | Ten thousand | | 每毫克订阅量 | 无限的 | | 等级制度的层次 | 根+6 级 | | 直接母公司管理组 | 一个 | | 每个地点的 MG 级部署 | eight hundred | | MG 级部署的位置 | Ten |

关于管理组限制，要考虑的重要事项是层级限制和最大部署位置。

如果您正在为一家在多个国家运营的国际组织开始大规模 Azure 云转型之旅，则应该考虑这些限制，并将其纳入您的管理团队设计中:

你将需要十个以上 Azure 区域的资源。
您需要根据地理政治区域、业务单位和责任划分等因素来隔离不同的订阅。
您需要减少延迟的区域部署来满足业务需求。

在管理组级别下面，您会发现 Azure 订阅。

订阅级别包含资源组，通常是职责开始分离和收缩的范围。

虽然通常会对管理组实施广泛的 RBAC 控制，但经常需要允许对一个订阅和另一个订阅进行不同级别的访问。例如，如果您的组织使用生产和非生产订阅模式。生产中的权限可能需要比非生产中的权限更加严格。

Key Definitions

订阅:Azure 中的一个逻辑构造，包含资源组，代表许多不同方面或管理和组织的边界。

资源组:保存资源的容器对象。通常，这些资源作为应用或解决方案的一部分彼此相关，或者是类似的资源，如路由表或虚拟网络，它们可以组合在一起，通过基于角色的访问控制或 RBAC 进行管理。

RBAC :指基于角色的访问控制，这是 ARM 的一个特性，允许向用户或用户组分配预定义或自定义的角色。

Location : Azure Locations 代表 Azure geography 中部署资源的整体区域，例如“EastUS2”、“SouthCentralUS”和“WestUS”。

标签:标签用于将 Azure 资源组织成一个逻辑分类。标签由一个键/值对组成，这意味着有一个“键”和一个“值”。例如，您可能有一个标签，其键名为“Environment”，值名为“Prod”。

订阅经常被用作一个管理边界，在这里用户可以被授权访问订阅中的每个资源。在较小的程度上，它被用作规模的逻辑单位，通过它可以在每个 Azure 区域的基础上限制特定类型的 Azure 资源的数量。

以下是使用订阅级别管理边界的两个示例:

向高级管理员授予订阅的所有者级别权限，以便此人可以管理访问控制。
将“网络贡献者”角色授予组织中的网络管理员，以便他们可以访问各种网络资源和工具来测试性能和排除故障。

与管理组和订阅一样，在设计订阅策略时，需要考虑一些与 ARM 框架相关的限制。

表 2-2

订阅限制

资源

限制

| | --- | --- | | 每个租户的订阅量 | 无限的 | | 每个订阅的联合管理员 | 无限的 | | 每个订阅的资源组 | Nine hundred and eighty | | ARM API 请求大小 | 4，194，304 字节 | | 每个订阅的标签 | Fifty | | 每个订阅的唯一标签计算 | Eighty thousand | | 每个位置的订购级部署 | eight hundred | | 订阅级别部署的位置 | Ten |

这里要考虑的最重要的事项是每个订阅的资源组数量和每个订阅的位置。如果您的资源组策略将需要大量的 rg，请考虑将它们跨多个订阅，如果您正在计划多区域部署，请计划每个订阅 10 个位置的限制。在某些情况下，使用嵌套模板跨多个位置进行部署可能会超出位置限制。

资源组或“RG”级别用于进一步细化权限，并开始组织内的职责分离。例如，如果您将所有网络资源放在一个“网络”资源组中，您可以将订阅的读者访问权限授予您的网络团队，但将贡献者访问权限授予该网络 RG。

在设计和实现资源组结构时，有许多事情需要记住。这项任务初看起来可能很简单，但是随着环境复杂性的增加，它将变得越来越令人望而生畏。

资源组中的资源应该共享生命周期，并且应该一起部署、更新和最终删除。例如，创建包含虚拟网络、虚拟网络网关、VPN 连接和路由表的“网络资源组”。这些资源在逻辑上被组合在一起，可能具有相同的 RBAC 结构，并且应该在组织内保持相同的生命周期。

资源只能存在于单个资源组中，不能属于多个组，因此 RBAC 结构应该考虑资源组的内容以及相应设计的配置。

大多数资源可以随时移动到不同的 RG。随着环境复杂性的增加，当有必要重新组织层次结构时，这通常是有帮助的。

更改资源组时，每个资源有不同的限制。在尝试移动之前，请确保阅读了有关更改资源上的资源组的文档。

资源可以位于不同 Azure 区域的资源组中，但建议将资源与 RG 保持在同一区域，因为如果 RG 位于故障区域，一个区域中的任何控制平面问题都可能影响另一个区域中的资源。这限制了单个区域故障的潜在影响。

此外，资源组为其中包含的资源提供必要的元数据。如果元数据变得不可用，资源可能会失败。

资源组是一种逻辑结构，用于对用户进行组织和访问控制，而不是限制对其他资源的访问。

资源组不充当资源之间的屏障！一个资源组中的资源可以自由地与另一个资源组中的资源交互。

标签可以应用于资源组，但是资源不会自动继承标签；然而，Azure Policy 或 PowerShell 可以在这方面提供帮助。

可以应用开箱即用或“OOB”策略，该策略可以将缺失的标签从资源组复制到该组中的资源。这极大地简化了确保所需标签出现在资源上的过程。

删除资源组将删除该组中的所有资源。删除 RG 时要小心！三重检查每个资源都可以被删除而没有影响。

关于资源组和层次结构中的其他级别，需要记住一些其他限制。

表 2-3

资源组限制

项目

限制

| | --- | --- | | 每个 RG 的资源 | 资源受资源组内资源类型的限制 | | 每类资源 | 每个 RG 有 800 个资源类型实例 | | 历史上每个 RG 的部署 | eight hundred | | 每次部署的资源 | eight hundred | | 每个作用域的管理锁 | Twenty | | 每个资源或 RG 的标签数量 | Fifty | | 标签密钥长度 | Five hundred and twelve | | 标签值长度 | Two hundred and fifty-six |

对于资源组限制，设计中要考虑的主要问题是历史上每个资源组中相似资源的数量和每个 RG 的部署。如果您正在部署资源的多个迭代，如订阅中的存储帐户，或者它是一个特别动态的环境，您预计将超过 800 个部署历史限制，您需要考虑减轻这些限制的方法。

可以通过多种方式创建资源组，包括 Azure 门户、Azure CLI、PowerShell 和 ARM 或其他部署模板。

除了 ARM 中的层次限制之外，在您的环境的整体实施策略中，还应该考虑一些部署模板的限制。

表 2-4

ARM 模板限制

价值

限制

| | --- | --- | | 因素 | Two hundred and fifty-six | | 变量 | Two hundred and fifty-six | | 资源(包括副本数量) | eight hundred | | 输出 | Sixty-four | | 模板表达式 | 24，576 个字符 | | 导出模板中的资源 | Two hundred | | 模板尺寸 | 4 MB | | 参数文件大小 | 4 MB |

Key Definitions

Azure Resource Manager (ARM)模板:通常被称为“ARM 模板”，这是一种 JavaScript 对象符号，或 JSON 格式的文件，用于通过 ARM 部署资源。这个文件是以声明性语法结构编写的，这意味着您是在声明您想要创建的对象，而不是必须编写大量的代码序列来创建对象。

当通过 ARM 或任何其他方式部署资源时，在 ARM 执行请求之前，总是需要两条信息。您必须为资源提供一个资源组和一个将部署资源的 Azure 位置。

我们已经深入讨论了资源组，所以让我们从地理角度来谈谈 ARM 的组织。

从地理角度来说，Azure 中的资源有两种交付方式。它们要么是“非区域性服务”，这意味着它们不位于特定的数据中心，服务基本上来自任何地方，要么它们是从特定的 Azure 区域交付的，要使用该服务，您必须使用该服务可用的区域。

Azure 区域是一组位置非常接近的 Azure 数据中心。Azure 区域内的资源通常会有 1-2 毫秒的跨区域延迟。每个区域都连接到 Azure edge 网络，区域之间至少有 5 毫秒的延迟，但这取决于源和目的地。如果你在美国东部和悉尼之间移动数据，这个数字会高得多。

img/506033_1_En_2_Fig3_HTML.png

图 2-3

蓝色区域资源

Key Definitions

Azure Region :部署在延迟定义的地理区域内的数据中心集合，通过高带宽、低延迟的网络连接进行连接。

在每个 Azure 区域中，有两个或更多的数据中心或“可用性区域”

这些可用性区域代表一个区域内完全独立的 Azure 数据中心，拥有自己的电力、冷却和互联网连接。

如果某个地区的任何一个数据中心出现故障，该数据中心的工作负载将转移到其他两个数据中心，前提是您的地区战略设计中已经考虑到了这一点。

Azure 平台提供多种类别的服务。

**基础服务:**一个核心的 Azure 服务，在所有 Azure 区域都可用。这将是虚拟网络、虚拟机和存储帐户等基本服务。

主流服务:Azure 服务，在推荐地区可用，但在其他地区可能不支持。

专业服务:非常具体的服务，由需求驱动，通常需要专业的硬件来交付。Azure 上的 SAP HANA 大型实例是专业化服务的一个很好的例子，因为它需要 Azure 数据中心中的专用服务器，这些服务器可以支持所需的特殊操作系统以及 HANA 数据库。

当考虑您的区域策略时，验证您想要在 Azure 中使用的所有服务在您选择的区域中都可用是非常重要的。

虽然某一特定类型的资源可能在某一特定地区可用，但这并不意味着它在所有地区都可用。根据您期望使用的资源来规划您的区域！

您可以在网站上按地区查看 Azure 产品的可用性

https://azure.microsoft.com/en-us/global-infrastructure/services/

除了选择主要区域之外，还应该为灾难恢复和跨区域操作确定一个辅助区域。微软将特定的 Azure 区域与通常相距超过 300 英里的类似服务配对，并在它们之间不断复制。

这可以保护工作负载免受自然灾害、停电或连接问题的潜在影响，这些问题可能会导致某个区域离线。

利用配对区域使您能够更快地克服主区域内的灾难或环境内的灾难。

虽然您必须从一个地区到另一个地区复制计算工作负载，但地理冗余存储或“GRS”和具有地理复制功能的 Azure SQL 会在配对的地区之间自动复制，管理服务如 ARM 资源元数据、IAM 和活动日志也会自动复制。

此外，平台更新在成对的区域中按顺序安排，以防止两个区域都受到更新窗口或更新问题的影响。

img/506033_1_En_2_Fig4_HTML.png

图 2-4

蓝色成对区域

微软使用“爆炸半径”方法为应用弹性的设计建议提供信息。

这实际上意味着，您需要根据爆炸半径和对运营的潜在影响来设计您的应用的弹性。

Key Definitions

爆炸半径:这代表一个事件对你周围环境的影响。这可以在许多层面上表现出来:

**失去资源:**由于硬件故障而离线的服务器。
**资源收集丢失:**这可能表示数据中心中的一个机架由于配电故障而离线。
**数据中心区域丢失:**这表示 Azure 数据中心区域丢失，导致存储、网络或计算实例等服务出现重大故障。
**区域丢失:**这表示某个地理区域发生了灾难性故障，迫使 Azure 区域中的所有数据中心离线。这可能是飓风或地震等自然灾害、电网灾难性故障或其他重大事件。

Azure Region:Azure 数据中心的集合，这些数据中心非常接近，具有低延迟连接以及独立的电源、冷却和互联网连接。

可用性区域:标识 Azure 区域的特定子集，该子集允许资源的分布，并且能够防止单个 Azure 数据中心的丢失。

弹性:应用根据服务级别协议(SLA)适应或调整故障并继续运行和交付服务的能力

在考虑如何以及在哪里使用 ARM 部署资源时，您需要考虑如何为您的部署规划弹性。

对于任何工作负载，您应该问的第一个问题是，“我需要此部署的弹性吗？”通常，非生产工作负载不需要高可用性或灾难恢复，但对生产系统会有不同的要求。

如果您确实需要工作负载的弹性，那么您的下一个问题是，“需要多少？”这通常由您的应用的服务级别协议来回答。如果您有一个业务关键型应用，它可能具有非常高的 SLA，例如 99.99%的正常运行时间，每次事件的停机时间不超过 2 小时，数据丢失时间不超过 1 小时。

img/506033_1_En_2_Fig5_HTML.png

图 2-5

天蓝色爆炸半径

一旦确定了需求，就可以基于爆炸半径方法构建应用。一旦确定了方法，就可以使用 ARM 将工作负载部署到 Azure。

武器发展和管理

在我们深入使用 ARM 之前，让我们快速讨论一下微软是如何持续维护和更新 Azure 的。

Azure 是一个不断经历转型的平台(有时每周一次)，因此，由于 Azure 基础设施在整个地区或平台上的更新，每个 Azure 资源的特性或行为每天都可能不同或功能不同，因此经常会非常混乱。

这种看似混乱的服务模式初看起来可能如此，但在幕后，服务更改、更新和功能扩展都经过了多个客户的严格审查和测试，这些客户愿意投入时间来测试和审查这些更改/更新，并与微软合作完善它们以实现全面可用性(GA)。

Azure 服务和功能在正式发布之前，会在一个包含来自 MSTeam、客户和合作伙伴的反馈和改进的周期中发布。

img/506033_1_En_2_Fig6_HTML.png

图 2-6

Azure 开发生命周期阶段

在开发阶段，只有 Microsoft 资源参与开发特定服务的特性和功能。一旦微软确定他们已经为下一阶段做好准备，他们将邀请表示有兴趣或请求访问该服务的客户来开发围绕该产品的解决方案。这被称为“私人预览”

一旦服务已经过测试和更新，并且已经达到可以在正常使用下开始运行的状态，这个阶段就变成了“公共预览”在此阶段，任何选择实施该服务的客户都可以使用该服务，但是该服务存在一些限制，例如降低或取消服务级别协议和“尽力而为”支持，并且某些功能可能不可用或不可配置。

一旦产品管理团队认为该服务已经过全面审查并准备好投入运营，它将被视为“普遍可用”或简单的“正式发布”

强烈建议您不要使用未正式发布的服务来部署生产工作负载。功能、特性、功能和部署模型在预览版和正式发布版之间都会发生变化。在部署利用某项服务的生产工作负载之前，请始终等待该服务在您所在的地区普遍可用。

一旦产品普遍可用，所有 Azure SLAs 和支持保证都适用，服务可以在生产中实现。

您可以通过访问 Azure Products by Region 网站来查看任何地区的任何 Azure 服务的状态和可用性:

https://status.azure.com/en-us/status

img/506033_1_En_2_Fig7_HTML.png

图 2-7

Azure 状态网站

使用 Azure 资源管理器

让我们来看看您可以与 ARM 交互的一些机制，它们是如何工作的，以及在通过 ARM 部署工作负载时应该遵循哪些建议和最佳实践。

ARM 比以前的 ASM 系统灵活得多，有多种方式可以与之交互。您可以简单地登录 Azure web 门户并使用基于 web 的图形界面，可以使用 PowerShell 或 Azure CLI 等命令行工具，甚至可以通过 REST 或第三方系统(如 HashiCorp 的 Terraform)或其他部署工具(如 Chef 或 Octopus)通过 Azure API 直接连接。

Azure 门户和 Azure API 直接与 ARM 接口，而 PowerShell 和 Azure CLI 与 Azure SDK 交互，后者管理翻译并移交给 ARM 进行请求处理。

一旦请求直接或通过 SDK 提交给 ARM，ARM 将验证发出请求的用户或服务主体的身份，并通过 RBAC 验证权限，如果流程获得授权，则执行该流程。

img/506033_1_En_2_Fig8_HTML.png

图 2-8

Azure 资源管理器操作

这个过程将“创建虚拟机”这样简单的事情变成了构建 Azure 数据中心所需的所有复杂命令和子命令，如分配存储、创建网络接口、锁定处理器/RAM 资源、将它们连接在一起，以及配置它们以基于您的请求返回功能虚拟机。

ARM via Azure 门户

与 ARM 最常见也是最不成熟的交互是通过 Azure 门户。使用 Azure portal 可能会出现大量人为错误，以及由于人为错误和配置选项验证有限或没有验证而导致的应用或解决方案的架构故障。

Azure 门户由四个主要区域组成，它们将始终用于与 ARM 平台进行交互，以创建、修改或管理资源。

img/506033_1_En_2_Fig9_HTML.png

图 2-9

蔚蓝门户

**主导航:**这个区域包含最常用的 Azure 资源和对象的快速链接。菜单是可定制的，可以添加、删除或重新组织项目以满足用户的需求。
**搜索框:**搜索框是一个非常有用的工具，可以快速找到特定的资源类型或资源。
**实用程序菜单:**实用程序菜单包含常用门户实用程序的快捷方式，例如用于通过门户执行 Azure CLI 命令的 Azure Cloud Shell，以及用于更改门户主题或布局的设置选项。
**交互面板:**这是门户的主要交互区域。这是可以在门户中查看或修改资源的地方。

Azure 门户中与资源的大部分交互将发生在交互窗格中。一旦选择了资源类型，基于任何适当的筛选器的所有资源都将显示在窗格中。

img/506033_1_En_2_Fig10_HTML.png

图 2-10

门户交互窗格 1

从这个视图中，您可以创建一个当前类型的新资源；您可以通过添加、删除或重新排序列来修改视图。还可以对视图应用多种不同类型的筛选器，并且可以将视图导出为逗号分隔值文件，以便在应用(如 Microsoft Excel)中查看和操作。

此外，您可以创建 Microsoft Graph 查询来获取基于图形查询结构的附加信息，并且可以创建标记并将其分配给资源。

如果您选择了单个资源，视图将会发生变化以显示该资源的特定详细信息。在这里，您可以管理资源并执行大多数配置任务。

您可以为资源分配 RBAC 角色，查看活动或诊断日志，或者修改资源的配置选项。

img/506033_1_En_2_Fig11_HTML.png

图 2-11

门户交互窗格 2

通过命令行启动

Azure Cloud Shell 是一个基于浏览器的交互式命令行工具，用于管理资源。Cloud Shell 可以使用 PowerShell 风格的 CLI 呈现，也可以使用 BASH 来处理命令。

可以通过两种方式访问云外壳:

直接链接:打开浏览器，导航至 https://shell.azure.com
Azure portal: Select the Cloud Shell icon in the Azure portal Utility Menu.

图 2-12

天蓝色的云壳

Azure 云壳可以处理多种语言来执行命令。

PowerShell 经常在云 Shell 中用来执行特定的命令或脚本。在清单 2-1 中，执行了一个 PowerShell 命令来显示特定资源组中的所有网络安全组。

代码片段 1。Get-AzResource

Get-AzResource -ResourceType "Microsoft.Network/NetworkSecurityGroups" -ResourceGroupName "nsg-rg-msdn-ent"

这将返回以下信息。

Name              : app-nsg-msdn-ent
ResourceGroupName : nsg-rg-msdn-ent
ResourceType      : Microsoft.Network/networkSecurityGroups
Location          : eastus2
ResourceId        : /subscriptions/c7abfg3-c4c1-436f-b9a7-d5230a145a6b/resourceGroups/nsg-rg-msdn-ent/providers/Microsoft.Network/networkSecurityGroups/app-nsg-msdn-ent
Tags              :

Listing 2-1PowerShell Command in Cloud Shell

除了 PowerShell，在云壳中也可以使用 Azure CLI。在清单 2-2 的示例中，已经执行了一个 Azure CLI 命令来显示特定资源组中的所有网络安全组。

代码片段 2。Az 资源列表

az resource list -g nsg-rg-msdn-ent --resource-type "Microsoft.Network/NetworkSecurityGroups"

在 AzCLI 中运行本质上相同的命令会以不同的格式返回不同的信息。

  {
    "changedTime": "2021-08-01T22:37:30.018120+00:00",
    "createdTime": "2021-08-01T22:27:12.392913+00:00",
    "extendedLocation": null,
    "id": "/subscriptions/c7adec53-c4c1-436f-b9a7-d5230a145a6b/resourceGroups/nsg-rg-msdn-ent/providers/Microsoft.Network/networkSecurityGroups/app-nsg-msdn-ent",
    "identity": null,
    "kind": null,
    "location": "eastus2",
    "managedBy": null,
    "name": "app-nsg-msdn-ent",
    "plan": null,
    "properties": null,
    "provisioningState": "Succeeded",
    "resourceGroup": "nsg-rg-msdn-ent",
    "sku": null,
    "tags": {},
    "type": "Microsoft.Network/networkSecurityGroups"
  }

Listing 2-2Azure CLI Command in Cloud Shell

Azure PowerShell 和 AzCLI 也可以从 Windows 命令提示符、PowerShell 提示符或 PowerShell ISE 实例中使用。

当运行命令或脚本时，使用 PoweShell ISE 通常是一个好主意，这样您可以更容易地检查代码、执行代码片段和解决问题。

通常，您可以使用 ARM 模板部署资源。ARM 模板使用基于 JSON 的声明性结构来标识要部署到 Azure 的一组资源的资源、属性和配置。

ARM 模板使用三个组件来构成部署的定义。

**参数:**提供部署过程中使用的值。参数文件可以重用，因为它们通常用于标识标准数据，并且在订阅、资源组和 Azure 环境中保持一致。

**变量:**特定于模板的参数，通常不会被重用。

Resources: 标识在部署期间要创建的资源。资源的配置信息通常从参数或变量中获取，并在资源创建期间应用。

当您部署 ARM 模板时，ARM 会将模板中的声明性代码转换为 REST API 操作，并按顺序执行它们。

让我们看看基本 ARM 模板中的结构组件。

| 声明此部分用于资源创建标识资源提供程序正在部署的资源的类型声明要使用的 Azure API 版本标识资源名称设置将部署资源的位置为资源选择 SKU 如果需要，标识子 SKU 指定资源的任何特定属性 | `"resources": [``{``"type": "Microsoft.Storage/storageAccounts",``"apiVersion": "2019-04-01",``"name": "storageaccount1",``"location": "centralus",``"sku": {``"name": "Standard_LRS"``},``"kind": "StorageV2",``"properties": {}``}``]` |

一旦你部署了你的 ARM 模板，它就被转换成一个 PUT API 操作并针对 Azure API 执行，你的资源就基于你的请求被创建。

PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/mystorageaccount?api-version=2019-04-01
REQUEST BODY
{
  "location": " centralus ",
  "sku": {
    "name": "Standard_LRS"
  },
  "kind": "StorageV2",
  "properties": {}
}

ARM via DevOps

通过 ARM 在 Azure 中部署的典型代码创建>存储>执行过程相对简单。

代码通常是使用支持 ARM、Terraform、Chef 和大量编码语言和插件的工具(如 VS Code)开发的。

两种最常见的代码格式是 ARM 模板和 Terraform 模板。两者都可以用 VS 代码开发，部署到 Azure。Terraform 的好处在于，它在 Azure 中维护一个状态文件，在执行代码管道时会引用它，只修改需要的内容。

ARM 模板不跟踪当前的 Azure 环境，在部署和维护 Azure IaC 环境时灵活性稍差。

img/506033_1_En_2_Fig13_HTML.png

图 2-13

Azure 开发周期(简单)

一旦模板被创建，它们就被存储在某种代码库中。目前最常用的回购协议是 GIT，但代码也可以存储在 Azure 回购协议或许多其他第三方回购协议中。

一旦您创建了代码并准备好进行部署，您可以通过 PowerShell 命令或者更好的 Azure DevOps 管道进行部署。一旦你执行你的命令，或者运行管道，ARM 将接收你的请求，翻译它，并把它传递给 Azure API 进行服务。

摘要

在本章中，我们讨论了 Azure Resource Manager，它是什么，如何使用它，以及在规划 ARM 部署时需要考虑的事项。

虽然 Azure 资源管理器一开始看起来有点让人不知所措，但是如果你把它分成几部分，一次只关注一件事，就不难理解了。

通过本章，您应该对 ARM 有了基本的了解，对使用它规划部署有了深入的了解，并找到了如何将它融入您的云之旅的一些想法。

三、Azure 管理洞察

在 IT 界，管理被定义为监督所有与运营和资源相关的事务的过程。Azure Arc 存在的理由是通过将 Azure 云中的监控和控制服务扩展到 Azure 外部的计算机和服务来执行管理，例如在内部网络或其他云中。Azure Arc 本身并没有提供多少管理价值。相反，它是基于 Azure 的管理功能的丰富混合集，扩展到 Azure Arc 连接的计算机和服务，商业价值由此产生。

虽然本书中的许多章节都集中在 Azure Arc 的规划和部署方面，但本章的目的是让你具备想象什么是可能的知识。通过学习 Azure Arc 提供的监控和控制功能，您将发现您可以使用 Azure Arc 做什么。您将使用这些有价值的构建模块，有时称为微服务，来交付我们将在第六章“混合服务器监控解决方案”和第七章“Azure Arc 服务器的监管和安全合规性”中涉及的解决方案

Azure 策略

Azure 策略支撑着 Azure Arc 的所有功能。换句话说，你需要分配一个或多个策略给 Azure Arc 对象来完成工作。将 Azure Arc 视为一个 Azure 策略分发和执行框架并不是不准确的。

图 3-1 展示了 Azure Arc 服务器和 Azure Arc Kubernetes 实例(在底部)如何被分配 Azure 策略(左下和右下)以强制执行 Microsoft Defender for Cloud 和 Azure Monitor 配置。这些设置反过来支持微软 Sentinel、Azure 日志分析和 Azure 自动化解决方案。

img/506033_1_En_3_Fig1_HTML.png

图 3-1

Azure Arc 对象的 Azure 策略分配支持对 Azure 管理服务的访问

真理的单一来源

Azure Policy 强制执行组织标准并大规模评估合规性。对于各种规模的组织来说，使用基于法规遵从性的模型来实现安全敏感型治理、资源一致性和法规遵从性是最佳实践。本质上，你管理的是政策的例外。如果您实现了 100%的策略遵从性，并且您持续地监控该遵从性，那么您已经做了最好的工作。有什么比在任何地方用同样的工具执行同样的政策更好的方法来获得这种信心呢？

拥有安全合规性的“单一事实来源”对于确保安全态势的完整性至关重要。图 3-2 展示了 Azure Policy 和 Azure Arc 协同工作的威力。在右上角，可以看到 Azure Policy 正在将 Azure Monitor 和 Microsoft Defender for Cloud 的计划一致地推广到位于 Azure 和内部或任何云中的 Windows 和 Linux 计算机。其他云当然包括 AWS 和私有云服务提供商。

img/506033_1_En_3_Fig2_HTML.png

图 3-2

Azure 策略为云计划分配 Azure Monitor 和 Azure Defender

与活动目录的比较

熟悉 Microsoft Windows Active Directory(AD)的人可以将 Azure 策略等同于 Active Directory 组策略。如果您不熟悉 AD，可以考虑一个用户名和计算机名的目录服务，它为网络上发生的所有事情分配和实施统一的策略。

正如 AD 中的组策略对象(GPO)应用于指定的范围，如 OU(组织单位)或安全组，Azure 策略被分配给范围，如 Azure 订阅或资源组。在这两种情况下，许多位置的大量计算机共享一个策略的单个实例，从而提高了效率和一致性。表 3-1 通过将 Azure 策略概念与熟悉的 Active Directory 组策略组件进行比较，帮助理解它们。

表 3-1

比较 Azure 策略和 Active Directory 组策略

Azure 策略

Active Directory 组策略

| | --- | --- | | Azure 策略在分配范围内的计算机上强制实施设置。多个策略可以捆绑在一个计划中。计算机可以应用多个方案。 | GPO 可以包含许多不同设置的设置。计算机可以应用多个 GPO。 | | 策略分配的范围在 Azure 订阅和资源组级别。例外可以应用于范围内的特定计算机。 | GPO 通常应用于域和 OU 级别。它们也可以应用于安全组，并且支持特定的豁免。 | | 以下是导致策略被评估的时间或事件:在具有策略分配的范围内创建、更新或删除资源。一个策略或计划被新分配给一个范围。更新已经分配给某个范围的策略或计划。在每 24 小时一次的标准合规性评估周期中。 | 计算机运行时，GPO 在启动时和每 90 分钟应用和处理一次。 | | Azure 策略示例:"审核最短密码期限不超过 1 天的 Windows 计算机" | GPO 设置示例:默认域策略➤计算机配置➤策略➤ Windows 设置➤安全设置➤帐户策略➤密码策略➤“最短密码期限”策略设置“1 天” |

Tip

Azure 策略也可以分配给 Azure 管理组，这些逻辑容器允许 Azure 管理员一次管理多个 Azure 订阅的访问、策略和合规性。

图 3-3 是 Azure 门户中策略刀片的概览窗格。已经分配给资源的五个计划的名称可以在左栏中看到。第四列和第五列显示分配的计划中不符合的资源数量和不符合的策略数量。通过逐一修正相关的不符合策略，可以减少不符合资源的数量。

img/506033_1_En_3_Fig3_HTML.png

图 3-3

Azure 策略定义对 Azure 内部和内部资产统一实施规则

总之，Azure 策略在 Azure Arc 中用于向 Azure Arc 服务器交付策略分配。在此模型中，Azure 策略的常见用途是启用对 Azure Monitor 和 Microsoft Sentinel 的监控，并实施相关合规性计划中包含的安全策略。

微软云卫士

Microsoft Defender for Cloud 是一项可选服务，可在您的 Azure 订阅中启用。作为最佳实践，打开 Microsoft Defender for Cloud 以增强您的云安全状况。Microsoft Defender for Cloud 的独特功能包括安全评分，用于衡量您的订阅的安全状况，以及法规遵从性，这是一个强大的治理和基准测试解决方案。

使用 Microsoft Defender for Cloud 保护您的混合云工作负载。当 Microsoft Defender for Cloud(以前的 Azure Security Center)最初发布时，唯一支持的计算机是 Azure 虚拟机(VM)。现在有了 Azure Arc，Microsoft Defender for Cloud 支持扩展到任何云中的本地计算机或虚拟机。面向 Azure Arc 场景的 Microsoft Defender for Cloud 的主要优势包括:

建立一个数据驱动的指标，使用 Azure Secure Score 评估您在 Azure、内部部署和其他云中的资源的安全状态。
简化企业合规性，并对照法规要求查看您的合规性。
Microsoft Defender for Server 针对易受攻击的工作负载(如服务器、SQL 数据库和 Kubernetes)提供深度安全检查。

这些关键优势映射到图 3-4 中所示的 Microsoft Defender for Cloud 中的顶级仪表盘图块。通过 Azure Arc，Windows 和 Linux 服务器以及 Azure 之外的 Kubernetes 完全参与了 Microsoft Defender for Cloud coverage，就像它们在 Azure 中的同行一样。

img/506033_1_En_3_Fig4_HTML.png

图 3-4

Microsoft Defender for Cloud(以前的 Azure Defender)是 Azure Arc 机器和 Kubernetes 安全的关键

Microsoft Defender for Cloud 的每个 Azure Arc 服务器的月成本为 15 美元，机器上的 SQL server 的月成本为 15 美元。Azure Arc Kubernetes 的成本是 2 美元/虚拟机核心/月，容器注册表是 0.29 美元/映像。具体价格因地区而异；点击此链接获取最新价格:

https://azure.microsoft.com/en-us/pricing/details/azure-defender

关注安全性的仪表板

为了在每个技术孤岛中监控企业的所有安全敏感方面，需要监视许多控制台和门户。你真的可以说，你宁愿看你的反恶意软件应用门户，而不是看你的防火墙健康门户？当然，你需要关注这两个门户网站以及其他许多网站。虽然 Azure 中的安全设置几乎无处不在，但 Microsoft Defender for Cloud 通过其安全评分方法获得了一个战略制高点，您可以从这个制高点评估您的企业安全状况。

正当运行 Microsoft Sentinel 的客户可以将 Microsoft Sentinel 视为他们的顶级安全操作控制台。然而，与 Microsoft Sentinel 中的实时事件处理和调查不同，Microsoft Defender for Cloud 提供了相关的控制面板视图，以及对“最普遍的建议(按资源)”和“潜在增长最高的控制”的洞察

在没有 Microsoft Sentinel 集成的情况下，Microsoft Defender for Cloud 具有内置的警报和通知工作流功能，可以在配置时向您发出信号。像微软 Sentinel 一样，工作流自动化采用 Azure Logic 应用的形式。例如，您可以编写一个逻辑应用，该应用获取 Microsoft Defender for Cloud alerts 的输出，并发送一封 O365 电子邮件，其中包含详细信息。

Tip

您可以为 Microsoft Defender for Cloud 发出的安全警报启用粒度抑制规则。在 Microsoft Defender 中查找云➤常规➤安全警报➤抑制规则的设置。基于 IP、DNS、主机和 Azure 资源实体创建覆盖

Microsoft Defender for Cloud for server

对于许多客户来说，这可能是激活 Microsoft Defender for Cloud 的首要原因。Microsoft Defender for Cloud for servers 包括 Microsoft Defender for Endpoint，无需额外费用。它们共同提供全面的终端检测和响应(EDR)功能。使用 Microsoft Defender for Cloud 的 Windows 服务器会自动启用 Microsoft Defender for Endpoint 传感器。

Azure 虚拟机和 Azure Arc 服务器之间有许多功能相似之处，其中之一是如何使用来自 Microsoft Defender for Cloud 的数据填充安全刀片。图 3-5 与您看到的启用了 Microsoft Defender for Cloud coverage 的 Azure 虚拟机几乎相同，但这个 Azure Arc 服务器是一个运行在内部私有云上的虚拟机。提供了安全建议的优先列表以及计算机的安全事件和警报的历史列表。

img/506033_1_En_3_Fig5_HTML.jpg

图 3-5

Microsoft Defender for Cloud 的覆盖范围通过 Azure Arc 扩展到了本地服务器

符合监管要求

对于一些组织，如必须遵守 PCI DSS 的金融机构或必须遵守 HIPAA 的医疗保健组织，合规性是部署 Azure Arc 和 Microsoft Defender for Cloud 的关键原因。符合性分配的安全分数基于范围内的资源符合所需安全策略的程度。拥有一个定义良好的、行业认可的安全模型可以让您的团队朝着一个有意义的目标努力。

各种行业和地区监管标准可通过策略分配给范围。这些监管标准已预先部署(开箱即用)到每个 Microsoft Defender for Cloud 实例中:

PCI DSS 3.2.1(支付卡行业数据安全标准，适用于处理主要卡组织品牌信用卡的组织)
ISO 27001(关于如何管理信息安全的国际标准)
SOC TSP(关于服务组织提供的服务的内部控制报告)

在 Microsoft Defender for Cloud 门户网站中轻松添加其他法规遵从性标准:

NIST SP 800-53 R4(联邦信息系统和组织的安全和隐私控制)
NIST SP 800 171 R2(保护非联邦系统和组织中的受控非机密信息)
英国官方和英国国民健康保险制度
加拿大联邦 PBMM
Azure CIS 1.1.0(新)(Microsoft Azure Foundations 基准法规遵从性)
Azure 安全基准
HIPAA HITRUST(医疗保健组织健康保险可携带性和责任法案)
SWIFT CSP CSCF v2020(客户安全控制框架包括针对 SWIFT 用户的强制性和咨询性安全控制)

天蓝色监视器

Azure Monitor 是一项 Azure 服务，它收集、分析和处理来自 Azure 和内部环境的遥测数据。将“Azure Monitor”视为一个包含各种解决方案的品牌，就像“Microsoft Office”一样，它包括 Word、Excel、Outlook 和一系列帮助各个应用和组件协同工作的公共基础。

Azure Monitor 有很多优点；参考图 3-7 了解使用了哪些工具和微服务。如果你在 Azure 中有任何资源或者你正在使用 Azure Arc，你已经在使用 Azure Monitor 了。每个 Azure 和 Azure Arc 资源都生成日志，许多资源还提供关于利用率和性能的指标。

img/506033_1_En_3_Fig7_HTML.png

图 3-7

Azure Monitor 收集、分析和处理遥测数据

Tip

了解 Azure Monitor 产品名称

Azure Monitor、日志分析和应用洞察是提供监控的单一服务。日志分析和应用洞察中的一些功能已经更名为 Azure Monitor，但其功能没有改变。日志分析的日志数据引擎和查询语言被称为 Azure Monitor Logs 。

Azure Monitor 数据源和解决方案

在图 3-7 的左边是输入到 Azure Monitor 的数据源，比如 Windows 计算机操作系统、类似 Key Vault 的 Azure 服务，或者来自 Azure 订阅的活动。中间度量和日志的数据库图标代表遥测数据流动和存储的数据存储库。数据的消费者和用户(“解决方案”)位于右侧，包括 Azure 仪表盘和工作簿，用于可视化和日志分析，以运行在可用性、性能、配置或安全问题发生时发出警报的预定查询。

Azure Monitor 将来自多个来源的数据存储在一起，以便可以使用一组通用工具关联和分析数据。您完全从数据存储库中抽象出来(您可以把它想象成一个无限容量的数据湖)。存储库中的数据是只读的，受您的工作区的保留策略的约束。微软通过正常的 Azure 基于角色的访问控制来处理安全访问，并在数据保留期结束时自动清除数据，默认情况下保留期为 30 天，但可延长至 2 年。

Azure Monitor 的不同数据源将写入日志分析工作区(Logs)或 Azure Monitor 指标数据库(metrics)或两者。数据存储在表中，每个工作空间或数据库都有不同的表，这取决于向它们写入了什么数据源。

Azure Monitor 范围定位

Azure Monitor 在您创建新的 Azure 订阅时启用，活动日志和平台指标会自动收集。当涉及到日志查询时，生成日志的资源被视为“作用域”。

图 3-8 展示了 Azure Monitor 日志需要一个范围来执行查询的概念。通过将 Azure Monitor 日志限定到任何生成日志的特定 Azure 资源，您可以针对该资源的日志数据运行集中查询。或者，通过将范围设置为日志分析工作区，您可以从向该工作区报告日志的所有数据源的数据库表中进行搜索。

img/506033_1_En_3_Fig8_HTML.png

图 3-8

Azure Monitor 日志需要选择一个范围来定位查询

例如，图 3-9 显示了 Azure Arc 服务器的日志刀片。由于该服务器运行的是 Windows Defender 反恶意软件防御，并且部署了安全和审计或安全无中心解决方案，因此保护状态表出现在日志视图中，您可以直接查询该表。

img/506033_1_En_3_Fig9_HTML.png

图 3-9

使用 Azure Monitor 日志检查 Azure Arc 服务器上 Windows Defender 的状态和上次扫描日期

不用说，一个相同的 ProtectionStatus 表也存在于运行 Windows Defender 的 Azure VM 的日志视图中。考虑一下，您可以对所有计算机的 ProtectionStatus 表运行相同的查询，包括 in-Azure 和非 Azure，以了解是否有任何计算机检测到威胁或扫描过期。这是一个有力的例子，说明了 Azure Arc 如何将本地计算机提升到与 in-Azure 虚拟机相同的管理范式，从而使您在混合管理任务方面的生活更加轻松。

Tip

当查询范围设置为特定资源时，查询浏览器、保存和新警报规则按钮在 Azure Monitor 日志视图中不可用。要创建警报、保存或加载查询，日志分析的范围必须是工作区。

日志分析和微软哨兵

部署这些 Azure 服务中的一个或两个来支持基础设施监控(日志分析)和/或安全监控(Microsoft Sentinel)是 Azure Arc 的一个优秀和常见的场景。通过这样做，您将实现“单一控制台”,将您的 in-Azure 和非 Azure 资源集中在相同的警报基础架构和门户视图中。两种解决方案使用相同的代理，并具有相同的推广计划。

如果您的企业有任何数量的服务器在 Azure 之外运行，并且您计划从 Azure 监控它们，您希望

使用天蓝色弧线来…
分配 Azure 策略…
安装 Microsoft 监控代理(MMA)和依赖项

对于 Azure Log Analytics 和 Microsoft Sentinel 场景，这就是全部内容。本章描述的所有其他监控解决方案只需要安装 MMA(和依赖项)。

日志分析工作区

像用于 AKS 部署的 VM Insights (包括 Azure Arc 服务器)和 Container Insights 这样的监控解决方案安装到日志分析工作区中。 Microsoft Sentinel 作为超集解决方案( Security Insights )安装到现有的日志分析工作区中。(Azure Log Analytics 工作区和 Microsoft Sentinel 实例之间存在 1:1 的关系。)无论您的最终目标是使用日志分析监控服务器，还是使用 Microsoft Sentinel 管理服务器的安全性(或者两者兼有)，您都需要在 Windows 和 Linux 服务器上安装 MMA。

以下是您将在日志分析工作区中执行的三项常见操作:

部署监控和管理特定服务的解决方案。
运行计划查询规则以发出警报。
创建可视化效果，如工作簿和仪表板。

接下来，我们将逐一了解这些内容。

Tip

避免工作空间蔓延。考虑在新的生产 Azure 订阅中创建一个日志分析工作区，作为您创建的第一个资源。这样做可以使您创建的其他日志生成资源(如虚拟机和密钥库)有一个共同的目标。

–启用应用洞察、容器洞察和虚拟机洞察并安装 Azure Sentinel 时，选择预先存在的工作空间。
–在 Azure Security Center 的定价和设置➤订阅➤设置➤自动配置中配置您的中央日志分析工作区的自动分配。

日志分析解决方案

日志分析中的监控解决方案提供了对特定 Azure 应用或服务操作的分析。部署日志分析工作区后，将自动添加适合您环境的监控解决方案，以提供特定功能。例如，当您启用 Microsoft Defender for Cloud 时，安全解决方案会安装在您选择的日志分析工作区中。

使用 Azure Monitor 日志的基本功能不需要安装解决方案；然而，几乎所有生产日志分析工作区都会安装几个解决方案。

对 Azure Arc 服务器特别有用的解决方案包括由 Azure Automation 安装的变更跟踪和更新，以及微软 Sentinel 的解决方案名称安全观察。图 3-10 显示了安装在日志分析工作空间中的这些解决方案。如果您需要从工作区中删除一个解决方案，您可以在这里完成。

img/506033_1_En_3_Fig10_HTML.png

图 3-10

日志分析工作区的解决方案刀片列出了工作区中安装的解决方案

日志分析成本

Azure Monitor 的日志接收成本以每天千兆字节(GB/天)为单位。这是使用日志分析的主要成本。监控服务器每月贡献 1 到 3 GB 的日志和度量数据；运行 DNS 服务器的域控制器每月将高达 10 GB。根据经验，每个 Azure Arc 服务器每月预算 5 美元用于日志分析处理。(此处未估算 Microsoft Sentinel 摄取成本，该成本也以 GB/天为单位进行测量，并计入日志分析费用。)

为 Azure Logic App 和 Azure Functions executions 之类的东西运行预定查询规则和微成本会产生较小的成本。最贵的监视器每 5 分钟运行一次，每月大约 1.5 美元。每小时或每天运行一次的监视器成本要低得多，低至每天 0.05 美元。一般组织每月在这些小额费用上的花费远低于 50 美元。

要获得 Azure Monitor 度量查询和警报费用的精确估计，请在以下链接的 Azure 定价计算器中输入您的规模数据:

azure。微软。com/ en-us/ pricing/ calculator/？服务=监视器

微收费的贡献者包括指标查询(每 1000 个 API 调用 0.01 美元，前 100 万个免费)、ITSM 连接(每创建 1000 个票证 5.00 美元，前 1000 个免费)和电子邮件通知(每 100，000 个电子邮件 2.00 美元，前 1000 个免费)。

日志警报规则

日志警报允许您使用日志分析查询来定期评估日志，并根据结果发出警报。规则可以使用操作组触发一个或多个操作。操作组可以包括通知任务，如发送电子邮件或创建 ITSM 票证，以及自动化任务，如启动 Azure Automation Runbook 或 Logic 应用。

传统的基于状态的监控与基于分析的监控

这是真正的监控工作发生的地方。传统的网络监控工具，如微软系统中心操作管理器(SCOM)或网络安全管理软件产品公司的 Orion ，由一个代表被监控服务器健康状态的数据库组成。代理或探测器使用专有工作流来检查特定的属性或指标，并将其写入数据库。例如，监视器可能“ping”一个服务器，并将 ping 应答状态记录到数据库中。当您想知道服务器是否在线时，您可以检查数据库中的 state 值，以了解最后一次成功的 ping 是什么时候。

一种更现代、更可扩展的方法是使用基于日志的分析。这种方法的流行实现包括来自 Splunk 、 Sumo Logic 和 ELK (Elasticsearch、Logstash 和 Kibana) 的产品。企业通常选择 Splunk 的功能和特性集，云原生 Sumo 逻辑的简单性，或 ELK 的开源设计。

在该模型中，轻量级代理进程将日志数据从服务器传输到存储库。想法是，如果我们记录服务器正在做的一切，我们可以通过搜索日志的副本来了解我们想要的任何东西。有关服务器状态的问题通过两步过程来回答:(1)首先运行一个搜索存储库的查询，然后(2)查找搜索查询条件的匹配(或不匹配)。

基于查询的警报规则如何工作

例如，考虑一个您希望发出警报的常见场景；这是与受监控服务器失去联系。对失去联系发出警报的查询包括从计算机中搜索最近的“心跳”日志条目。运行查询时没有找到最近的心跳日志条目构成了失去联系。每 5 分钟运行一次该查询(一个预定警报规则)可以在与服务器失去联系时产生近乎实时的警报。

参见图 3-11 中 Azure 日志分析工作区的规则刀片。第一列显示警报生成规则的名称，第二列显示对感兴趣的条件进行检查的实际查询语言。

img/506033_1_En_3_Fig11_HTML.png

图 3-11

预设规则检查您想要发出警报的条件

许多适用于 Azure 虚拟机的查询也适用于 Azure Arc 服务器。例如，考虑这个简单的查询，它返回一个受监控计算机的列表，以及它们最近的心跳:

Heartbeat
| summarize arg_max(TimeGenerated, *) by Computer

由于 Azure VMs 和 Azure Arc 服务器每分钟都产生心跳消息，并且这两种服务器都属于 Azure 对象的“计算机”类，因此实现了同构列表。

如果将来迁移到 Azure VMs，您在为 Azure Arc 服务器构建有用的监控规则库方面所做的投资将在很少或没有修改的情况下继续工作。基于预定查询的规则在 Microsoft Sentinel 中的工作方式相同，它们被称为分析活动规则。

工作簿和仪表板

当不利或异常事件发生时，一旦您收到警报，请考虑有效监控的另一面是可视化。特别是，要评估计算机性能指标的状态，一个警报列表(甚至是没有警报)是不够的。在许多情况下，您需要某种基于图表或图形的可视化显示来执行管理。

Azure Monitor(以及 Azure Log Analytics 和 Microsoft Sentinel)使用与警报生成规则相同的核心功能解决了可视化需求:查询。Azure Monitor 中使用的查询语言 Kusto Query Language 或 KQL 的一个特性是，查询可以以图形和列表格式返回数据。请这样想:虽然预定的警报规则包含要运行的查询和要根据查询结果执行的操作，但 Azure Monitor 可视化如工作簿和仪表板包含多个查询。当您打开工作簿或仪表板时，每个查询都会立即执行并实时呈现图形输出供您查看。

Azure 工作簿

图 3-12 中的工作簿展示了混合环境中跨平台查询分析的强大功能。带有条形图和彩色阴影的分类图表评估服务器性能。该视图显示了 Windows 和 Linux 服务器的 CPU 利用率，这些服务器既是 Azure 中的虚拟机，也是本地物理和虚拟计算机。借助 Azure Arc 和 Microsoft Monitoring Agent (MMA ),您可以使用 Azure 管理工具实现服务器性能的“单一平台”,这些工具可扩展到您的整个资产。

img/506033_1_En_3_Fig12_HTML.png

图 3-12

查询在 Azure 工作簿中以图表形式返回数据

工作簿保存在您的 Azure 订阅中，可以通过各种方式与团队成员共享。Microsoft Sentinel 环境只有共享工作簿，而 Azure Monitor 和日志分析环境只有私有工作簿。在所有环境中，通过向接收者发送唯一的 URL，私有工作簿是可共享的。

工作簿支持启用参数的交互式报告——也就是说，选择表格中的一个元素将动态更新相关的图表和可视化效果(参见图 3-12 中的下拉选择框，如计数器和表格趋势)。这使您可以旋转和聚焦可视化，以便在数据中“飞来飞去”。

Azure 仪表盘

Azure Monitor 中的另一个可视化产品是 Dashboard。就像 Azure 工作簿一样，Azure 仪表板是 KQL 查询的集合，配置为以图表和图形格式返回数据。仪表板可以是您的用户帐户专用的，也可以与队友共享。

图 3-13 是一个仪表板，基础设施洞察显示所有受监控服务器的网络流量指标，包括内部 Azure 虚拟机和内部 Azure Arc 服务器。这种可视化有助于您快速识别您的资产中的“主要参与者”—,无论他们在哪里，也无论他们运行什么操作系统。

img/506033_1_En_3_Fig13_HTML.jpg

图 3-13

Azure 仪表盘具有自动刷新和全屏模式

使用仪表板的主要原因包括，像工作簿一样，仪表板有一个自动刷新设置，可以从每 5 分钟到每天一次进行自定义。仪表板也有一个有用的“全屏”模式。通过组合这些功能，您可以创建无限数量的实时 kiosk 风格的仪表板，这些仪表板可以在任何装有 web 浏览器的计算机上运行。

Azure 自动化解决方案

Azure Automation 帐户链接到给定的 Azure 日志分析工作区，以支持各种解决方案。在 Azure Automation 中，您可以为您的 Azure Arc 服务器和 Azure 内虚拟机启用更新管理、更改跟踪和清单功能。这些功能依赖于日志分析工作区，因此需要将工作区与自动化帐户相链接。

最佳实践是在创建 Azure Log Analytics 工作空间后立即创建一个自动化帐户，然后继续执行链接它们的过程。但是，仅支持某些区域将它们链接在一起。表 3-2 列出了成功启用和使用这些功能的支持映射。确保了解此表，并为您的 Azure Log Analytics 工作区选择区域。

表 3-2

支持的映射 Azure 日志分析 Azure 自动化

日志分析工作区区域

Azure 自动化区域

| | --- | --- | | 澳大利亚东南部 | 澳大利亚东南部 | | 加拿大中央 | 加拿大中央 | | 印度中部 | 印度中部 | | 中国东方 2 号 | 中国东方 2 号 | | 艾西乌斯 | 伊斯特斯 2 号 | | 伊斯特斯 2 号 | 艾西乌斯 | | 法国腹侧 | 法国腹侧 | | 日本料理 | 日本料理 | | 北欧 | 北欧 | | 中南半岛 | 中南半岛 | | 东南亚 | 东南亚 | | 瑞士北部 | 瑞士北部 | | 英国南部 | 英国南部 | | 美国亚利桑那州 | 美国亚利桑那州 | | 美国弗吉尼亚州 | 美国弗吉尼亚州 | | 威斯特中心 | 威斯特中心 | | 西欧国家 | 西欧国家 | | 威斯乌斯 2 号 | 威斯乌斯 2 号 |

您会很高兴创建了一个自动化帐户，这不仅是为了我们将在本章中描述的更新和配置管理功能，也是为了您将获得的通用流程自动化:

Runbooks :可以自动启动的 PowerShell 或 Python 脚本
混合工人小组:在本地执行从基于云的 Azure 流程启动的操作手册的自动化工具
观察者任务:启动观察事件的成对操作手册，然后在事件发生时执行选定的自动操作

有了自动化框架，您可以将 runbooks 指定为对 Azure Monitor 警报的自动响应。此外，您可以准备基于 PowerShell 和 Python 脚本的 runbooks，以响应由 Microsoft Sentinel 行动手册(Azure Logic Apps)激活的 webhooks。

Tip

要将 Azure Automation 帐户与 Azure Log Analytics 工作区链接，请导航到其中一个配置管理解决方案或自动化帐户中的更新管理解决方案。在右侧的详细信息窗格中，您将能够选择配对的日志分析工作区，并按下启用按钮。

Azure 自动化成本

Azure Automation 在 Azure Arc 场景中有两个优秀的特性:更新管理和配置管理。一个是处处自由；另一个成本在 Azure 之外:

**更新管理:**免费(所有 Azure 虚拟机和 Azure Arc 服务器)
**配置管理:**Azure 虚拟机免费，Azure Arc 服务器每月 6 美元的“非 Azure 节点配置管理”

除了这些功能之外，Azure Automation 还具有流程自动化功能，例如微收费的作业运行时间(0.002 美元/分钟，每月 500 美元)和观察器节点(002 美元/小时，每月 744 美元)。

要获得流程自动化和配置管理的 Azure Automation 费用估算，请在 Azure Automation 定价页面选择您的地区和货币:

https://azure.microsoft.com/en-us/pricing/details/automation/

更新管理

Azure automation 的更新管理功能是一个巨大的价值，因为对 Azure 虚拟机或 Azure Arc 服务器使用该解决方案没有许可成本。除了日志分析数据处理的微收费，这是一个完全免费的解决方案，用于监控和管理 Windows 和 Linux 操作系统(OS)更新。行业内真的没有类似的。

如果您正在购买第三方服务器更新解决方案，或使用 Microsoft Endpoint Manager(以前的 System Center Configuration Manager)进行操作系统更新，或使用 WSUS(Windows Server Updating Server)，请考虑迁移到这款免费的全功能解决方案来处理您的服务器操作系统更新。它简单而优雅，并与 Azure Arc 和 Microsoft Defender for Cloud 完全集成。

在您启用更新管理解决方案后，您的每个 Azure Arc 服务器都将在 Azure 门户中的 Azure Arc 服务器刀片内拥有一个实时更新仪表板，如图 3-14 所示。您不仅可以准确地实时查看所选计算机的更新状态，还可以针对本地服务器轻松创建和启动基于云的更新任务。

img/506033_1_En_3_Fig14_HTML.png

图 3-14

Azure Arc 服务器的更新管理刀片

除了添加到每个 Azure Arc 服务器的更新管理视图，还有一个视图管理 Azure Automation account blade 中的多台机器上的更新，如图 3-15 所示。从该页面，您可以在 Azure VM 和 Azure Arc 服务器设置中针对多台 Windows 和 Linux 计算机启动即时或计划更新作业。

img/506033_1_En_3_Fig15_HTML.png

图 3-15

Azure Automation 帐户的更新管理刀片

结构管理

Azure automation 的配置管理功能对 Azure 虚拟机是免费的，Azure Arc 服务器每月有 6 美元的 Azure 消费成本(被称为“非 Azure 节点的配置管理”)。该特性捆绑了三个微服务:状态配置(DSC)、清单和变更跟踪。

状态配置(DSC)

Azure Automation State Configuration 是一个 Azure 配置管理服务，允许您为任何云或内部数据中心中的节点编写、管理和编译 PowerShell 所需的状态配置(DSC)配置。

如果您还没有准备好从云中管理机器配置，您可以使用 Azure Automation State Configuration 作为仅报告端点。此功能允许您通过 DSC 设置(推送)配置，并在 Azure Automation 中查看报告详细信息。

如果您的环境已经在 Azure 之外使用 DSC，请考虑 Azure 自动化状态配置提供了几个优势。该服务能够从一个安全的中心位置快速轻松地跨数千台机器进行扩展。

Azure Automation State Configuration service 之于 DSC，就像 Azure Automation runbooks 之于 PowerShell 脚本一样。换句话说，就像 Azure Automation 帮助你管理 PowerShell 脚本一样，它也帮助你管理 DSC 配置。

库存

Azure 自动化清单功能会发现您的环境中安装了什么软件。您可以收集和查看计算机上的软件、文件、Linux 守护程序、Windows 服务和 Windows 注册表项的清单。跟踪计算机的配置可以帮助您查明环境中的操作问题，并更好地了解计算机的状态。

清单解决方案提供了类似传统 CMDB(配置管理数据库)的功能，可以跟踪所有受监控的 Windows 和 Linux 服务器上安装的软件和运行的服务，包括 Azure 虚拟机和本地 Azure Arc 服务器。实时和历史库存状态同样被跟踪。

39 台服务器(主要是 Azure Arc Windows 服务器和一些 Linux)的清单视图如图 3-16 所示。在之前的 24 小时内，Azure Automation 跟踪了超过 12，000 项软件更改、近 800 项 Windows 服务和 200 项 Linux 守护程序状态更改。

img/506033_1_En_3_Fig16_HTML.png

图 3-16

Azure Automation Inventory:安装在您环境中的软件的实时配置管理数据库

更改跟踪

Azure Automation 中的更改跟踪可监控 Azure、内部和其他云环境中托管的虚拟机的更改，以帮助您查明操作和环境问题。例如，如果 Azure Arc 服务器开始出现问题，您可以咨询计算机的服务器-Azure Arc 更改跟踪刀片，查看在过去几个小时或几天内是否发生了任何意外的软件或注册表更改。更改跟踪所跟踪的项目包括

Windows 软件
Linux 软件(软件包)
Windows 和 Linux 文件
Windows 注册表项
微软服务
linux 守护进程

变更跟踪建立在 Azure Automation 的库存特性之上。捕获受监控清单发生的更改，以便在调查过程中重现这些更改，并提供环境中名义更改率的指标。图 3-17 是 Azure Automation 帐户设置为 30 天视图的变更跟踪刀片。

img/506033_1_En_3_Fig17_HTML.jpg

图 3-17

Azure 自动化变更跟踪:检测跨平台和应用的变更

聚焦和过滤变更跟踪摘要，以深入到图中反映的单个变更，这是很简单的。变更跟踪在某种程度上是 Azure 自动化配置管理解决方案的“皇冠上的宝石”,因为它在取证和安全角色中的价值。

当您的环境中出现无法解释的问题时，一个早期且有效的问题是，什么发生了变化？有了 Azure Automation 变更跟踪，你就有了一个有价值的工具来回答这个问题。当检查变更事件的变更细节时，变更的“之前和之后”值被保存并显示，如图 3-18 所示。

img/506033_1_En_3_Fig18_HTML.png

图 3-18

在 Linux 计算机上检测到的软件版本更改的详细视图

虽然更改跟踪对于重建单个计算机上发生的更改非常有用，但它的另一个作用是监视和评估在整个资产的正常情况下更改的总体速度和范围。然后，当异常数量的更改发生时，Azure Automation 的聚合监控功能可以检测到它们。

在单个计算机中检测到的更改被写入 Azure Log Analytics 中的 ConfigurationChange 表。如果查询检测到与正常更改量有较大差异，则表明环境中发生了值得调查的事情。

事实上，异常变化检测是一种非常有价值的安全监控技术。图 3-19 是这种情况下可能出现的 Microsoft Sentinel 概览页面的一个片段。如果你看到了这个，你就会知道在过去的 24 小时内经历了两次异常巨大的变化。调查意外的变化可能是不需要的过程正在发生并需要补救的第一个提示。

img/506033_1_En_3_Fig19_HTML.png

图 3-19

来自 Azure Sentinel overview blade 的数据源异常检测

摘要

在这一章中，你学习了 Azure Arc 的所有功能。您已经熟悉了 Azure Arc 中的监视和控制特性，并对它们的功能有了基本的了解。既然你受到了启发，让我们进入下一章，我们将深入如何规划、部署和支持 Azure Arc 服务器。

四、Azure Arc 服务器：入门

Azure Arc 代表了一个全新的概念，它有机地从云中出现。这一秘密成分标志着 Azure Arc 对云本质特征的自然倾向，如广泛的网络接入和快速的弹性。“云”系统自然会战胜不能持续适应的遗留和传统系统。考虑一下 Azure Arc 给你的组织带来的超大规模资源池的好处——将你的非 Azure 资源投射到 Azure Resource Manager (ARM)控制平面，在那里它们加入数十亿个管理良好的对象。

创建这个被投影的对象，一个 Azure Arc 服务器，并从中获取价值是本章的内容。本章介绍并深入探究 Azure Arc 服务器对象在 Azure 中的样子，以及它在 Windows 和 Linux 计算机上的代理足迹。在这一章中，我们集中在一次安装一个 Azure Arc 代理来进行测试和评估，在第 5“Azure Arc 服务器:大规模使用”一章中，将会有关于在生产中部署 Azure Arc 代理的细节。

管理平台即服务

Azure Arc 是服务器管理功能的目标架构，因为它将管理任务移动到了一个成熟的超大规模云中。这些任务是什么——服务器可用性、配置、性能和安全性——自早期联网以来就没有改变过。发生变化的是管理任务的最佳交付位置。

在有云之前，有内部，大多数人把它叫做 LAN 和/或 WAN(局域网/广域网)。还有一个 VPN(虚拟专用网络)，这些以网络为中心的结构定义了管理和监控发生的画布。要监控的每个对象都在 LAN/WAN/VPN 边界内，因此管理工具也在那里。

快进到现代混合时代，物理位置通常与服务交付或消费无关。服务器管理任务的出现是很自然的，也是意料之中的，这些任务可以从云服务中“剥离”并交付，比留在内部更有效。可以将灾难恢复即服务(DRaaS)产品想象为受异地公共云保护的本地服务器。灾难恢复传统上需要大量昂贵的基础设施来构建热点站点，因此将灾难恢复剥离到云是经济驱动的早期行业趋势。

图 4-1 图片服务器管理功能如同冰山，大部分服务器管理负担转移到 Azure。庞大的全球 Azure 资源管理器是您使用 Azure Arc 的后端服务提供商。Azure Arc 代表了云经济学产生的新范式:无成本管理即服务(MaaS)。换句话说，Azure Arc 是微软作为免费平台服务提供的一个无限可扩展的管理工具框架。

img/506033_1_En_4_Fig1_HTML.jpg

图 4-1

Azure Arc 将许多服务器管理功能移至 Azure 资源管理器

云服务管理可以从业务支持、供应和配置的角度以及可移植性和互操作性的角度进行描述。Azure Arc 允许您的服务器体验这些规模经济，通常只保留给云服务，即使它们不存在于云中！扪心自问:为什么不为您的服务器“植入”一套行之有效的管理、监控和安全最佳实践呢？当您可以减轻成本和维护负担时，为什么还要购买和维护任何遗留管理工具呢？

这是对投资 Azure Arc 进行服务器管理是否明智的最后一次“检验”:作为一种基于云的管理技术，Azure Arc 通过了托管服务的“相互协调”测试。该产品最根本的基础是消费者和服务提供商的“双赢”。微软赢了，因为通过使用 Azure Arc，你更有可能消费收费的微软服务，你赢了，因为 Azure Arc 降低了你的服务器的总拥有成本(TCO)。

什么是 Azure Arc 服务器？

在前端，Azure Arc 服务器是一台由 Azure 管理但在 Azure 外部运行的计算机。在后端，Azure Arc 服务器是 Azure 资源管理器(ARM)资源“类型”Microsoft.HybridCompute/machines的一个机器实例。

Azure 资源管理器(ARM)资源类型

Azure Arc 服务器的混合本质是由独立的物理和逻辑实体组成的:

**物理位置:**运行在除 Azure cloud 之外的世界任何地方的物理或虚拟计算机
虚拟位置:“类型”的 Azure 资源Microsoft.HybridCompute/machines存在于特定的 Azure 订阅、资源组和位置中

相比之下，完全存在于 Azure 中的 Azure VM 具有以下分类:

Azure VM: 【类型】微软的 Azure 资源。特定 Azure 订阅、资源组和位置中存在的计算/虚拟机器

像 Azure 中的其他所有对象一样，Azure 虚拟机和 Azure Arc 服务器都是由资源类型、订阅、资源组和位置定义的 Azure 资源。分配给 Azure 虚拟机和 Azure Arc 计算机的标签在治理和计费方面的工作方式相同。

图 4-2 是正在运行的 Azure Arc 服务器(左边)和 Azure VM(右边)的 Azure 资源管理器(ARM)定义的并列 JSON 视图。这些常见的基础软件结构解释了为什么使用基于 Azure 的工具管理本地服务器是合理且高效的。

img/506033_1_En_4_Fig2_HTML.png

图 4-2

Visual Studio 代码中的并排 JSON 视图突出了 Azure Arc 服务器和 Azure VMs 的 ARM 通用性

Tip

使用 Azure PowerShell 通过 ARM 资源类型名称查询 Azure Arc 服务器或 Azure VMs 的列表:

get-AzResource -ResourceType Microsoft.HybridCompute/machines

get-AzResource -ResourceType Microsoft.Compute/virtualMachines

Azure 门户中的 Azure Arc 服务器

Azure 门户( https://portal.azure.com )是 JSON 模板元素的图形化视图，这些模板元素定义了 Azure 订阅中的资源组。如图 4-3 所示，你可以在你的 Azure 资源组中的导出模板刀片检查你的 Azure 门户中资源组的内容。您的 Azure Arc 服务器将与所有其他 Azure 资源类型一起包含在您的资源组中。

img/506033_1_En_4_Fig3_HTML.png

图 4-3

将整个资源组导出到 JSON 文档

当然，Azure 门户有一整套专用的 Azure Arc 视图，这些视图显示了 Azure Arc 基础设施资源，如服务器、Kubernetes 集群、SQL 服务器和 Azure Stack HCI 部署。图 4-4 显示了 Azure Arc 服务器页面，在这里可以找到您有权访问的所有订阅中的所有 Azure Arc 服务器。

img/506033_1_En_4_Fig4_HTML.png

图 4-4

Azure 门户中的 Azure Arc 服务器

如图 4-4 中视图的列所示，您可以根据状态(连接或离线)、位置(创建 Azure Arc 服务器资源的 Azure 区域)、操作系统(Linux 或 Windows)以及您可能在创建时或之后选择性分配的标签等参数进行排序和过滤。

此时你应该明白的是，Azure Arc 服务器是 Azure 控制平面中的一个逻辑构造。部署 Azure Arc 服务器的实际技术过程是创建一个“类型”Microsoft.HybridCompute/machines的 Azure 资源记录。要使用交互方法装载 Azure Arc 服务器，您需要以下这些东西:

有权创建 Azure Arc 资源的 Azure 订阅的登录凭据
适合您的组织的 Azure 订阅中的资源组，用于包含 Azure Arc 服务器资源
承载 Azure Arc 服务器对象的 Azure 区域(位置),该区域不必与资源组位于同一区域

Azure Arc 服务器位置选择

在大多数情况下，当您装载 Azure Arc 服务器时，您选择的位置应该是地理上离您的机器位置最近的 Azure 区域。以下是选择要使用的区域时的一些注意事项:

静态数据存储在包含您指定的区域的 Azure geography 中，如果您有数据驻留需求，这也可能会影响您对区域的选择。
如果您的计算机连接的 Azure 区域受到中断的影响，连接的计算机不会受到影响，但是使用 Azure 的管理操作可能无法完成。

在发生区域性中断的情况下，如果您有多个支持地理冗余服务的位置，最好将每个位置的 Azure Arc 服务器连接到不同的 Azure 区域。

Tip

Azure Arc 支持的服务器在一个资源组中支持多达 5，000 个机器实例。对于非常大的部署，规划多个资源组。

注册 Azure 资源提供者

启用 Azure Arc 的服务器依赖于订阅中的以下 Azure 资源提供者来使用服务:

微软。混合计算
微软。猜测配置

如果它们尚未注册，您可以使用以下命令注册它们:

Azure PowerShell

Login-AzAccount
Set-AzContext -SubscriptionId [subscription you want to onboard]
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration

蓝色 CLI

az account set --subscription "{Your Subscription Name}"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'

您也可以在 Azure 门户中注册资源提供者，方法是按照 Azure 资源提供者和类型链接上的注册资源提供者 Azure 门户部分中的步骤:

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types#azure-portal

在你注册了两个指定的提供者之后，你的 Azure 订阅的资源提供者刀片应该如图 4-5 所示。

img/506033_1_En_4_Fig5_HTML.png

图 4-5

要在您的 Azure 订阅中注册的资源提供者，以创建支持 Azure Arc 的服务器

将 Azure Arc 连接到 Windows 和 Linux 服务器

安装 Azure Arc 代理可能是您需要安装的最后一个代理，因为通过 Azure Policy 和 Azure Arc，您可以管理您的混合计算机可能需要的所有当前和未来的管理和安全代理。“天蓝弧代理”被称为天蓝连机 代理。

在安装时，Azure Connected Machine Agent 需要使用 Azure AD 进行身份验证，以验证新的 Azure Arc 服务器已被授权与您的 Azure 订阅相关联。有两种方法可以做到这一点:

使用交互式脚本手动添加服务器。这适用于小型部署和测试。每次安装时，您都可以使用您的个人用户凭据登录 Azure。本章逐步介绍这种方法。
大规模添加服务器。此方法使用您在 Azure AD 中创建的 Azure 应用注册的身份和客户端密码(应用密码)。通过您喜欢的任何脚本或管理工具运行带开关的代理安装。在第 5 章“Azure Arc 服务器:大规模使用”中介绍

先决条件:使用交互式脚本添加 Azure Arc 服务器(Windows 和 Linux 计算机)

在尝试装载 Azure Arc 服务器之前，请注意以下参数:

需要服务器的本地管理员或 root 权限。
搭载 Azure Arc 服务器所需的最低内置 Azure 订阅安全角色是Azure Connected Machine on boarding。
请确保您已经对所有涉及的 Azure 订阅执行了本章“注册 Azure 资源提供者”一节中涵盖的过程。
确认要加入的服务器可以通过 TCP 443 端口访问互联网的以下 URL:
- management.azure.com
- login.windows.net
- login.microsoftonline.com
- dc.services.visualstudio.com
- agentserviceapi.azure-automation.net
- *-agent service-prod-1 . azure-automation . net
- *.guestconfiguration.azure.com
- *.his.arc.azure.com
- *.blob.core.windows.net
- azgn*.servicebus.windows.net
- pas.windows.net

逐步:使用交互式脚本添加 Azure Arc Windows 服务器

img/506033_1_En_4_Fig6_HTML.png

图 4-6

将内部和其他云中的服务器连接到 Azure 有两种主要方式

在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
在图 4-6 中的选择方法页，点击生成脚本。

img/506033_1_En_4_Fig7_HTML.png

图 4-7

Azure 门户将自动生成一个自定义脚本，将计算机装载到 Azure Arc 上

输入适合您环境的资源详细信息和标签，然后点击下载并运行脚本以到达如图 4-7 所示的刀片。

img/506033_1_En_4_Fig8_HTML.png

图 4-8

使用 onboarding 脚本手动安装 Azure Arc 代理的三个步骤

下载脚本(OnboardingScript.ps1)并将其复制到要添加到 Azure Arc 的服务器。
1. 在提升的 PowerShell 会话中运行脚本。注意脚本输出的代码。
2. 打开网页浏览器进入 https://microsoft.com/devicelogin 。
3. 在您的租户中使用 Azure AD 凭据登录，并输入如图 4-8 所示的代码。

请注意图 4-8 中的脚本会将AzureConnectedMachineAgentWindows Installer 包下载到您执行脚本的文件夹中。日志文件 installationlog 也在同一位置创建。(在给定代码过期之前，您有有限的时间使用该代码完成登录。)

img/506033_1_En_4_Fig9_HTML.png

图 4-9

Azure Connected Machine Agent 文件夹和服务的拆卸

安装代理后，您会发现Azure Connected Machine Agent列在添加/删除程序中，如图 4-9 所示。
1. 代理文件位于 C:\ Program Files \ AzureConnectedMachineAgent。
2. 创建了两个 Windows 服务:
  1. 客户配置 Arc 服务 (GCArcService):该服务监控机器的期望状态。
  2. 客户配置扩展服务 (ExtensionService):该服务安装请求的扩展。
安装 Azure Arc 代理后，您可以打开您的 Azure 门户来查看新的混合计算机对象:

https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.HybridCompute%2Fmachines

图 4-10 显示了添加 Azure Arc 服务器后你可能很快会看到什么。如果您在创建时为 Azure Arc 服务器指定了标签，您会在 Overview blade 上看到它们。您也可以通过点击更改链接手动添加标签，或者在 Azure Arc 服务器生命周期中的任何时候以编程方式添加标签。我们将在第六章的“混合服务器监控解决方案”中讨论标签的高级使用

img/506033_1_En_4_Fig10_HTML.png

图 4-10

Windows Azure Arc 服务器的概述

逐步:使用交互式脚本添加 Azure Arc Linux 服务器

使用手动方法连接 Linux 服务器的过程与连接 Windows 服务器的过程非常相似。您必须遵守本章前面的“先决条件:使用交互式脚本添加 Azure Arc 服务器(Windows 和 Linux 计算机)”一节。

img/506033_1_En_4_Fig11_HTML.png

图 4-11

自动生成的定制 Bash 脚本将 Linux 计算机装载到 Azure Arc 上

在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
在选择方法页(之前参见图 4-6 ，点击生成脚本。
输入适合您环境的资源详细信息和标签，然后点击下载并运行脚本以到达如图 4-11 所示的刀片。

img/506033_1_En_4_Fig12_HTML.png

图 4-12

手动将 Linux 计算机加入 Azure Arc

下载脚本(OnboardingScript.sh)并将其复制到要添加到 Azure Arc 的 Linux 计算机上。(使用 WinSCP 等任何方便的工具；在 https://winscp.net 下载。)
```
sudo chmod 700 OnboardingScript.sh
```
```
sudo ./OnboardingScript.sh
```
1. 通过运行以下命令启用要执行的脚本:
2. 使用提升的权限运行脚本，如下所示:
3. 在脚本运行接近完成时，注意脚本打印出一个设备登录代码，如图 4-12 所示。

img/506033_1_En_4_Fig13_HTML.png

图 4-13

Azure Connected Machine 代理的设备登录

打开网页浏览器进入 https://microsoft.com/devicelogin 。web 浏览器会话可以发生在任何计算机上；它不需要从板载的 Linux 计算机上运行。
在您的租户中使用 Azure AD 凭据登录，如图 4-13 的上部所示。

将出现一个类似图 4-8 中 Windows 代理启动时看到的输入代码页。输入密码后，您会收到一条确认信息，如图 4-13 的下部所示。当您看到这个消息时，脚本将会提示您查看您的板载服务器；导航到

https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.HybridCompute%2Fmachines

img/506033_1_En_4_Fig14_HTML.png

图 4-14

确认所有 Azure Arc 守护程序正在运行

安装代理后，将应用以下配置更改:
1. 代理文件位于
  1. /var/opt/azcmagent(支持文件)
  2. /var/lib/GuestConfig。(来自 Azure 的应用策略)
  3. /opt/azcmagent(hima dsd . service files)
  4. /opt/GC_Ext，(来宾配置代理文件和下载的扩展文件)
  5. /opt/DSC(常见的 DSC 工件)
2. 创建了三个 Linux 守护进程:
  1. Azure Connected Machine Agent 服务 (himdsd.service):该服务实现了 Azure 实例元数据服务(IMDS)来管理与 Azure 的连接以及连接机器的 Azure Arc 身份。
  2. GC Arc 服务 (gcad.service):监控机器的期望状态配置。
  3. 扩展服务 (extd.service):针对机器安装所需的扩展。
您可以使用该命令检查服务守护程序是否正在运行，如图 4-14 :
```
systemctl -list-units | grep <service name>
```
所示

img/506033_1_En_4_Fig15_HTML.png

图 4-15

刚加入后的 Linux Azure Arc 服务器概述

安装 Azure Arc 代理后，您可以在 Azure 门户中查看新的混合计算机对象，如图 4-15 所示。

管理和使用 Azure VM 扩展

Azure 虚拟机(VM)扩展是在 Azure VMs 上提供部署后配置和自动化任务的小型应用。例如，如果虚拟机需要安装软件或在其中运行脚本，可以使用 VM 扩展来代替传统的配置管理工具。

扩展本质上是一个“带外”(OOB)管理通信通道，使用期望状态配置(DSC)技术创建，可与 Azure 虚拟机和 Azure Arc 服务器同等工作。一个诞生于超大规模 Azure 云中的通信通道，现在通过 Azure Arc 扩展到 Azure 之外的服务器。

在您的计算机管理任务中尽可能使用扩展是一种力量倍增器。传统上，在云和内部环境中跨 Linux 和 Windows 服务器部署和审核软件需要多种管理工具。现在，有了支持 Azure Arc 的服务器和 Azure 虚拟机，混合机器生命周期的管理得到了简化。

每当在 Azure VM 或 Azure Arc 服务器中安装一个扩展时，就会在 Azure 资源组中创建一个隐藏资源类型—，它是计算机对象—的子对象，如下所示:

Azure Arc 服务器扩展资源类型:

Microsoft.HybridCompute/machines/extensions

Azure VM 扩展资源类型:

微软。计算/虚拟机器/扩展

扩展对象表示该计算机上该扩展的所需状态配置。在选择了 Show hidden types 选项的情况下查看资源组中的所有资源将会显示您已经部署的扩展。扩展补充和扩展了 Azure 资源管理器框架，基础设施运行在该框架上，这实际上是服务管理功能向平台服务的教科书式迁移。

在图 4-16 中，您可以看到微软的新方法——即跨平台配置扩展—如何实现跨您的资产的同质管理。

img/506033_1_En_4_Fig16_HTML.png

图 4-16

扩展是资源组中隐藏的资源类型

就业务价值而言，该模型意味着您可以通过一致的控制点和可重复的流程来加速计算机管理中固有的添加/删除/更改流程。有几种方法可以自动地大规模利用扩展；我们将在接下来讨论这些。

Azure VM 扩展的用例

以下是一些可用的 Azure VM 扩展的具体用例，它们为支持 Azure Arc 的服务器提供了关键优势:

**DSC VM 扩展:**使用 Azure Automation 状态配置集中存储配置，维护 Azure Arc 服务器的期望状态。例如，在计算机上实施标准功能部署，如 IIS 或 DNS 服务。
**日志分析代理 VM 扩展:**使用 Azure Monitor 和 Microsoft Sentinel 中的日志收集日志数据进行分析。这有助于对不同来源的数据进行复杂的分析。
Azure Monitor for VMs: 分析您的 Windows 和 Linux 虚拟机的性能，并监控它们的进程以及对其他资源和外部进程的依赖。这是通过启用日志分析代理和依赖关系代理虚拟机扩展来实现的。
**自定义脚本扩展:**在混合连接的机器上下载并执行脚本。该扩展对于部署后配置、软件安装或任何其他配置或管理任务非常有用。考虑在所有服务器创建后立即安装反恶意软件或其他安全代理。

您可以通过以下链接了解每个扩展的详细信息，并找到当前可用扩展的完整列表:

发现 Windows 虚拟机扩展
发现 Linux 的虚拟机扩展

https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-windows

https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-linux

管理 Azure VM 扩展的方法

即使它们影响许多地方的机器，扩展只存在于 Azure 控制平面中，所以它们很容易使用，并且可以在任何可以访问 Azure 的地方执行。有五种方法可用于部署和管理 Azure VM 扩展，所有方法都适用于所有 Azure VM 和 Azure Arc 服务器，包括 Windows 和 Linux。这些方法是 Azure 门户、Azure PowerShell、Azure CLI、ARM 模板和 Azure 策略。

方法 Azure 门户中的扩展

在单个 Azure Arc 服务器上使用扩展的一个简单快捷的方法是在 Azure 门户中 Azure Arc 服务器页面的扩展刀片上。图 4-17 显示了一个使用 VM 扩展连接到 Azure Log Analytics 的典型 Azure Arc 服务器。

img/506033_1_En_4_Fig17_HTML.png

图 4-17

添加到 Azure Arc 服务器的 Azure VM 扩展

为了帮助你理解 Azure Arc 和 Azure VM 扩展在 Azure Arc 服务器上的净效果，请看图 4-18 ，图 4-17 中 Azure Arc 服务器“Luther”内部的控制面板➤程序和功能小程序。

img/506033_1_En_4_Fig18_HTML.png

图 4-18

扩展是资源组中隐藏的资源类型

图 4-18 展示了 Azure VM 扩展(添加在 Azure 资源管理器控制平面中)如何影响存在于 Azure 之外的 Azure Arc 服务器。这台服务器的所有者需要安装的唯一软件是 Azure Arc 代理( Azure Connected Machine 代理)。随后，微软管理代理(MMA)及其依赖代理的扩展也安装了这些软件——安装工作由 Azure 资源管理器支持的 Azure Arc 自动完成。

导航到 Azure Arc 服务器的扩展页面的原因包括仔细检查特定的扩展是否按预期安装，或者手动安装或卸载扩展。如果点击计算机扩展页面上的添加按钮(如图 4-17 ，会提供一个可供手动安装的扩展列表，如图 4-19 。

img/506033_1_En_4_Fig19_HTML.png

图 4-19

从 Azure 门户在 Azure Arc 服务器上手动安装新的 Azure VM 扩展

Tip

Azure 门户只公开了可用 Azure VM 扩展的子集，这些扩展也可以与 Azure Arc 服务器一起工作。其他还有 *Azure Key Vault VM 扩展、基于扩展的用户混合 Runbook Worker、*和 Azure Defender 集成扫描器可以通过 ARM 模板安装。

或者，点击一个已安装扩展的名称(同样在图 4-17 中)将打开该扩展的详细信息页面，带有一个卸载按钮，如图 4-20 所示。如果您在正确安装特定扩展时遇到问题，您可以从这里卸载失败的扩展，并让 Azure Arc 再次尝试添加该扩展。

img/506033_1_En_4_Fig20_HTML.png

图 4-20

每个已安装的 Azure VM 扩展在其详细信息页面上都有一个卸载按钮

方法 2:使用 Azure PowerShell 的扩展

Azure PowerShell 命令可以从任何安装了 Azure PowerShell 的计算机上运行，也可以从 Azure 门户中的 Azure Cloud Shell 上运行。无论哪种情况，都需要添加 Az。使用以下 cmdlet 将 Machine 模块连接到 PowerShell 实例:

Install-Module -Name Az.ConnectedMachine

将该模块一次性安装到 PowerShell 或 Cloud Shell 实例后，您可以运行以下 PowerShell 命令来列出、添加和删除扩展:

Get-AzConnectedMachineExtension -ResourceGroupName <rgname> -MachineName <machineName>

New-AzConnectedMachineExtension -Name <extensionName> -ResourceGroupName <rgname> -MachineName <machineName> -Location <location> -Publisher <publisher> -ExtensionType <extensionType> -Settings <settings>

Remove-AzConnectedMachineExtension -MachineName <machineName> -ResourceGroupName <rgname> -Name <extensionName>

图 4-21 演示了在 Azure 云 Shell 中使用 PowerShell 来列出 Azure Arc 服务器上已安装的 Azure VM 扩展。请注意，这与图 4-17 中 Azure 门户中看到的数据相同。

img/506033_1_En_4_Fig21_HTML.png

图 4-21

列出安装在带有 Azure PowerShell 的 Windows Azure Arc 服务器中的 Azure VM 扩展

方法 3:使用 Azure CLI 的扩展

Azure CLI 可安装在 Windows、macOS 和 Linux 环境中。也可以在 Docker 容器和 Azure 云壳中运行。在所有场景中，就像 PowerShell 的情况一样，在 Azure Arc 服务器上使用 Azure CLI 之前，需要安装一个模块。命令是

az extension add --name connectedmachine

将该模块一次性安装到您的 Azure CLI 或云外壳实例后，您可以运行如下命令来列出、添加和删除扩展:

az connectedmachine extension list --machine-name "myMachineName" --resource-group "myResourceGroup"

az connectedmachine extension create --machine-name "myMachineName" --name "OmsAgentForLinux or MicrosoftMonitoringAgent" --location "eastus" --settings '{\"workspaceId\":\"myWorkspaceId\"}' --protected-settings '{\"workspaceKey\":\"myWorkspaceKey\"}' --resource-group "myResourceGroup" --type-handler-version "1.13" --type "OmsAgentForLinux or MicrosoftMonitoringAgent" --publisher "Microsoft.EnterpriseCloud.Monitoring"

az connectedmachine extension delete --machine-name "myMachineName" --name "OmsAgentForLinux" --resource-group "myResourceGroup"

如果你没有 Azure CLI 的本地安装，在 Azure Cloud Shell Bash 环境中运行这些命令的快捷方式如图 4-22 所示。

img/506033_1_En_4_Fig22_HTML.png

图 4-22

使用 Azure CLI 列出安装在 Linux Azure Arc 服务器上的 Azure VM 扩展

方法 4:作为 ARM 模板的扩展

当您为新的 Azure Arc 服务器使用基于模板的部署和供应工具时，这是一个值得考虑的好方法。Microsoft 已在此链接中发布了模板文件和参数文件，并提供了扩展的示例值，如下所示:

https://docs.microsoft.com/en-us/azure/azure-arc/servers/manage-vm-extensions

适用于 Windows 和 Linux Azure Arc 计算机的 ARM 模板可用于以下扩展:

日志分析虚拟机扩展
自定义脚本扩展
PowerShell DSC 扩展
依赖代理扩展
Azure Key Vault 虚拟机扩展
Microsoft Defender for Cloud 集成漏洞扫描器
Azure Automation 混合 Runbook Worker 扩展

方法 5:使用 Azure 策略部署扩展

虽然列在最后，但这是管理扩展的最佳方法，因为使用 Azure Policy 可以在一个管理操作中实现部署、合规性和云规模。Azure 策略适用于新的和现有的计算机。尽管之前使用扩展的任何方法都有其用例，但 Azure Policy 是最有可能将 Azure VM 扩展部署到 Azure Arc 服务器的方法。

得益于 Azure Arc，Azure 策略和捆绑策略集的计划可以应用于全球范围的异构计算机。Azure Policy 的内置合规性和补救功能是实现任何给定扩展的技术目标的路线图和工具集。

例如，使用这种方法，您可以将内置的 Azure PolicyDeploy Log Analytics agent 分配给 Linux 或 Windows Azure Arc machines (见图 4-23 )来审计启用 Arc 的服务器是否安装了日志分析代理。如果代理未安装，该策略可以创建预定义的补救任务，以通过 Azure 资源部署作业自动安装代理。

img/506033_1_En_4_Fig23_HTML.png

图 4-23

将日志分析代理部署到 Windows Azure Arc 计算机的内置 Azure 策略

值得注意的是，Azure Policy 通过查看适当的 Azure VM 扩展是否成功安装在 Azure Arc 服务器对象上来间接进行检查，而不是通过与计算机本身进行交互。考虑在 Azure Arc 的架构中，所需配置的成功状态的证明被委托给一个较低且高度分布式的级别——混合计算机本身上的 DSC 代理。这有效地让 Azure Resource Manager 在评估策略合规性时只承担检查状态值的轻量级任务。

Microsoft 建议使用 Azure 策略安装用于 Windows 或 Linux 的日志分析代理。我们将在第六章“混合服务器监控解决方案”中详细介绍这种方法

摘要

在这一章中，你深入地学习了什么是 Azure Arc 服务器，并了解了手动部署和扩展管理的概念。您还了解了 Azure Arc 服务器如何通过 Azure Resource Manager 与 Azure 控制平面进行交互。现在你已经理解了使用 Azure Arc 服务器的基础，在下一章，你将学习如何大规模部署和管理 Azure Arc 服务器。我们还将介绍更高级的 Azure Arc 特性，如标签和仪表板，以及在所有场景中对 Azure Arc 服务器进行故障排除。

五、Azure Arc 服务器：大规模使用

当您使用 Azure Arc 来管理可能不存在于云中的本地服务器时，您可以有效地将云服务管理的基本特征扩展到非云资源。这意味着，从业务支持、供应/配置和可移植性/互操作性的角度来看，您的所有服务器都可以分享云消费者享受的规模经济优势。本章将帮助你在生产中使用 Azure Arc，从这些角度实现最大的好处。

第四章“Azure Arc 服务器:入门”介绍了一次安装一个 Azure Arc 代理，以便用交互方法进行测试和评估，而本章继续使用服务主体大规模部署 Azure Arc 服务器。第四章还包括了 Azure VM 扩展如何与 Azure Arc 服务器协同工作来执行部署后配置和自动化任务的细节，所有这些都同样适用于大规模使用 Azure Arc 服务器的扩展。

本章通过讲述如何在 Azure Arc 服务器上使用标签以及如何创作 Azure Monitor 工作簿来增加你的 Azure Arc 技能，这些工作簿可以作为你的混合资产中所有服务器的仪表板。最后，我们总结了在 Windows 和 Linux 服务器上使用 Azure Arc 的一般故障排除技巧。

为入职创建服务主体

要将非 Azure 计算机作为启用 Azure Arc 的服务器连接到 Azure，您可以使用 Azure Active Directory 服务主体，而不是使用特权用户身份来交互连接计算机，就像我们在第四章“Azure Arc 服务器:入门”中所做的那样使用这种方法，具有提升权限的管理员或用户需要登录(或使用 PowerShell remoting)每台要管理的计算机，并以交互方式连接到服务器。

回想一下，安装 Azure Arc 代理需要安装程序对 Azure 订阅具有写访问权限，以便创建特定 Azure 订阅、资源组和位置中存在的“类型”Microsoft.HybridCompute/machines的 Azure 资源管理器(ARM)资源。安装程序可以是人，也可以是安全主体而不是人。在大规模应用中，您需要一个不需要人工参与的流程，您需要一个可以通过自动化或脚本化轻松无限重复的流程。

一个服务主体是一个特殊的有限管理身份(一个“Azure 服务帐户”)，它被授予使用 azcmagent 命令将机器连接到 Azure 所需的最低权限。这比使用像全局管理员这样的特权更高的帐户更安全，并且符合微软访问控制安全最佳实践。服务主体在入职和离职期间使用；它不用于任何其他目的。Azure Connected Machine on boarding是一个预定义的 Azure 访问角色，足以搭载 Azure Arc 服务器。

安装和配置 Connected Machine (Azure Arc)代理的安装方法确实要求您使用的自动化方法(如通过编写脚本)在要注册的目标计算机上具有提升的权限。在 Linux 上，使用 root 帐户；在 Windows 上，作为本地管理员组的成员。

使用 PowerShell 创建服务主体

使用 Azure PowerShell 创建您的服务主体非常简单；以下是要输入的命令:

$sp = New-AzADServicePrincipal -DisplayName "Arc-for-servers" -Role "Azure Connected Machine Onboarding"
$sp
$credential = New-Object pscredential -ArgumentList "temp", $sp.Secret
$credential.GetNetworkCredential().password

图 5-1 展示了它在 Azure Cloud Shell 中运行的样子。您正在使用这些命令执行三个操作:

img/506033_1_En_5_Fig1_HTML.png

图 5-1

使用 PowerShell 创建 Azure Arc onboarding 服务主体

创建名为 Arc-for-servers 的企业应用
在你的 Azure 订阅中为应用分配 Azure Connecting Machine on boarding 角色
创建仅可见一次的秘密密码

运行完这些命令后，将结果复制并粘贴到要保存的文件中，这一点非常重要。稍后您将需要应用 Id 和密码来编辑用于大规模入职的脚本。

使用 Azure 门户创建服务主体

如果您愿意，可以使用 Azure 门户创建您的服务主体；在此链接的向 Azure AD 注册应用并创建服务主体和向应用分配角色部分中有详细步骤:

https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal

使用与 PowerShell 演示相同的设置，将应用命名为“Arc-for-servers”，创建一个新的客户端密码，并在您的 Azure 订阅中为应用分配角色Azure Connected Machine on boarding。记下如图 5-2 所示的应用(客户端)ID，并保留为我们接下来将创建的入职脚本创建的密码。

img/506033_1_En_5_Fig2_HTML.png

图 5-2

使用 Azure 门户创建 Azure Arc onboarding 服务主体

将 Azure Arc 大规模连接到 Windows 服务器

创建了 Azure AD 服务主体，分配了 Azure 订阅权限，并且有了服务主体密码，您就可以使用脚本向 Azure 添加多个服务器了。当然，第 4“Azure Arc 服务器:入门”一章中关于交互式入职的先决条件的所有内容也适用于大规模入职。特别要确保微软。HybridCompute 和微软。GuestConfiguration Azure 资源提供商已在您的 Azure 订阅中注册。

循序渐进:大规模添加 Azure Arc Windows 服务器

img/506033_1_En_5_Fig3_HTML.png

图 5-3

开始体验大规模板载服务器

在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
在图 5-3 中的选择方法页，在添加多个服务器下，点击生成脚本。

img/506033_1_En_5_Fig4_HTML.png

图 5-4

具有 Azure Connected Machine on boarding 角色的应用注册已列出，以供选择进行身份验证

阅读先决条件页面，然后单击下一步:资源详细信息。
输入适合您的环境的资源详细信息，然后单击 Next: Authentication 。
如图 5-4 所示，您之前创建的服务主体可供选择；然后点击下一步:标签。

如图 5-5 所示，资源标签可以选择性地与该脚本上的 Azure Arc 服务器相关联。

img/506033_1_En_5_Fig5_HTML.png

图 5-5

可选地为 Azure Arc 服务器分配标签。以后可以随时添加或更改标签

img/506033_1_En_5_Fig6_HTML.png

图 5-6

大规模入职脚本可供下载、编辑以添加密码，并在测试服务器上运行

输入需要的标签后，点击下一步:下载并运行脚本，进入如图 5-6 所示的下载脚本页面。

您也可以选择使用以下脚本格式手动创作入职脚本:

# OnboardingScript.ps1
# --------------------

# Download the package
function download() {$ProgressPreference="SilentlyContinue"; Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent -OutFile AzureConnectedMachineAgent.msi}
download

# Install the package
msiexec /i AzureConnectedMachineAgent.msi /l*v installationlog.txt /qn | Out-String

# Run connect command

& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
  --service-principal-id "{serviceprincipalAppID}" `
  --service-principal-secret "{serviceprincipalPassword}" `
  --resource-group "{ResourceGroupName}" `
  --tenant-id "{tenantID}" `
  --location "{resourceLocation}" `
  --subscription-id "{subscriptionID}"

Tips on running OnboardingScript.ps1: (applies to Windows and Linux)

该脚本可以装载在多台服务器上。Azure Arc 服务器将被分配到相同的订阅、资源组和 Azure 区域。
从门户下载的脚本将不包含$servicePrincipalSecret值；在运行下载的脚本之前，您需要手动添加服务主体密码。
该脚本必须以本地管理员(或 root)权限运行。
您可以使用模式--tags "tag1name=tagvalue,'tag 2 name'='tag value'"修改标签来制作脚本的多个版本

img/506033_1_En_5_Fig7_HTML.png

图 5-7

在服务器上手动运行大规模入职脚本进行验证

虽然脚本可能在数百台服务器上运行，但谨慎的做法是至少在一台计算机上手动验证脚本。将脚本(OnboardingScript.ps1)复制到预期的 Azure Arc 服务器，并在提升的 PowerShell 会话中运行该脚本。图 5-7 显示了手动运行时规模入职脚本的输出。

安装 Azure Arc 代理后，您可以打开您的 Azure 门户来查看新的混合计算机对象:

https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.HybridCompute%2Fmachines

大规模运行 Azure Arc Windows Onboarding 脚本

当然，制作大规模入职脚本的主要原因是允许在大量计算机上远程自动运行脚本，而无需进一步的人工干预。网络管理员工具包中任何使用提升权限运行 PowerShell 脚本的方法都可以使用。考虑这些选项:

使用Invoke-Command cmdlet 进行一对多远程处理的 PowerShell 远程处理。
使用 Microsoft Endpoint Manager (MEM)，以前的 System Center Configuration Manager(SCCM)，将 PowerShell 脚本部署为应用或程序。
使用 Active Directory 组策略对象(GPO)将 PowerShell 脚本作为即时计划任务运行。

建议使用第三个选项，因为 GPO 计划任务方法允许您以管理员权限立即运行该脚本，并且该脚本只运行一次，因为每次组策略刷新时，它都会删除该任务。按照以下步骤将 Azure Arc Windows onboarding 脚本部署到您的 Active Directory (AD)域中的许多或所有服务器。

img/506033_1_En_5_Fig8_HTML.png

图 5-8

使用组策略创建立即计划任务

将 OnboardingScipt.ps1 文件复制到网络共享位置；在我们的例子中，我们将使用域“sysvol”脚本文件夹:%LOGONSERVER%\sysvol\%USERDNSDOMAIN%\scripts\OnboardingScript.ps1
打开组策略管理控制台(GPMC)并导航到 AD 林中包含要加载到 Azure Arc server 的系统的位置。右键单击并选择“在此域中创建一个 GPO，并在此链接它。”出现提示时，指定名称 Install Azure Arc Agent 。
右键单击新 GPO 并选择编辑。导航到计算机配置➤首选项➤控制面板设置➤计划任务，然后右键单击并选择新➤即时任务(至少 Windows 7)，如图 5-8 所示。

img/506033_1_En_5_Fig9_HTML.png

图 5-9

配置新任务的常规选项卡

在新任务的“常规”选项卡上，将操作设置为“创建”,输入名称“立即任务”以安装 Azure Arc 代理，将用户帐户更改为“系统”,选择“无论用户是否登录都运行”,以最高权限运行，并配置为 Windows 7、Windows Server 2008 R2，如图 5-9 所示。
转到新任务的“操作”选项卡，输入以下信息:
- Action = "启动程序"
- 程序/脚本=
  
  C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
- 添加参数(可选)=
  
  -ExecutionPolicy Bypass -command "& \\SERVER\SHARE\OnboardingScript.ps1"
  
  (用您在环境中使用的名称替换 SERVER 和 SHARE)
最后，转到通用选项卡，选择应用一次，不要再次应用选项。
保存新任务，Azure Arc 代理将在下一个组策略刷新间隔(每 90 分钟一次，随机偏移量最长为 30 分钟)安装在 GPO 应用的计算机上。

将 Azure Arc 大规模连接到 Linux 服务器

为了大规模部署 Linux 服务器，您将使用为大规模部署 Windows 服务器而开发的相同 Azure 广告服务主体和加密密码。大规模连接 Linux 服务器的过程与大规模连接 Windows 服务器的过程非常相似。

循序渐进:大规模添加 Azure Arc Linux 服务器

您必须遵守第 4“Azure Arc 服务器:入门”一章中的“先决条件:使用交互式脚本添加 Azure Arc 服务器(Windows 和 Linux 计算机)”一节

img/506033_1_En_5_Fig10_HTML.png

图 5-10

自动生成的定制 bash 脚本使用服务主体将 Linux 计算机装载到 Azure Arc

在你的 Azure 门户中，点击新建并选择 Azure Arc for servers ，然后点击创建。
在前面图 5-3 中看到的选择一种方法刀片，在添加多个服务器下，点击生成脚本。
阅读先决条件页面，然后单击下一步:资源详细信息。
输入适合您的环境的资源详细信息，将操作系统设置为 Linux ，然后单击下一步:认证。
如前图 5-4 所示，您之前创建的服务主体可供选择；然后点击下一步:标签。
输入需要的标签后，点击下一步:下载并运行脚本，进入如图 5-10 所示的下载脚本页面。

以下是手动创作 Linux 大规模入职脚本的格式:

此时，您的 bash 脚本已经准备好在一台试验计算机上进行测试，然后使用各种 Linux 软件管理技术进行大规模部署。

# OnboardingScript.sh
# --------------------

# Download the installation package
wget https://aka.ms/azcmagent -O ~/install_linux_azcmagent.sh

# Install the hybrid agent
bash ~/install_linux_azcmagent.sh

# Run connect command
azcmagent connect \
  --service-principal-id "{serviceprincipalAppID}" \
  --service-principal-secret "{serviceprincipalPassword}" \
  --resource-group "{ResourceGroupName}" \
  --tenant-id "{tenantID}" \
  --location "{resourceLocation}" \
  --subscription-id "{subscriptionID}"

大规模运行 Azure Arc Linux Onboarding 脚本

流行的开源配置管理软件可能正在您的 Linux 环境中使用，如 Chef 或 Puppet ，这些工具非常适合部署您的 Azure Arc at-scale onboarding 脚本。作为远程部署 onboarding 脚本的简化演练，考虑使用 Linux 内置 ssh 命令的这些步骤:

img/506033_1_En_5_Fig11_HTML.jpg

图 5-11

生成用于远程运行脚本的 ssh 密钥对

将 onboarding 脚本复制到您的 Linux 管理计算机上，并通过运行以下命令来执行该脚本:
```
sudo chmod 700 OnboardingScript.sh
```
使用 ssh-keygen 实用程序生成一个公钥-私钥对(参见图 5-11 作为示例)。每次出现提示时，按回车键即可。
```
ssh-keygen -t rsa
```
接下来，将公钥添加到您想要在 Azure Arc 中注册的远程主机上的~/.ssh/authorized_keys文件:
```
ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<host>
```
现在，您可以从管理计算机上执行远程主机上的 SSH 命令，而无需输入密码。以下单个命令行将(1)将脚本从管理计算机复制到目标计算机，(2)运行 onboarding 脚本，以及(3)删除脚本的远程副本。
```
scp OnboardingScript.sh <host>:/tmp/ && ssh -t <user>@<host> "sudo -s bash /tmp/OnboardingScript.sh" && ssh -t <user>@<host> "rm /tmp/OnboardingScript.sh"
```

在脚本运行完成时，注意脚本打印出一个信息通知，表明入职已完成，如图 5-12 所示。

img/506033_1_En_5_Fig12_HTML.png

图 5-12

将 Linux 计算机远程部署到 Azure Arc

从 Windows 管理中心将计算机连接到 Azure Arc

微软提供了一种使用 Windows 管理中心装载 Azure Arc 服务器的方法。Windows 管理中心是一款本地部署的基于浏览器的应用，用于管理 Windows 服务器、集群、超融合基础设施以及 Windows 10 电脑。这是一款自 2019 年起正式上市(GA)的免费产品，已经被许多组织用于生产。您可以在环境中的计算机上安装该产品，然后登录该计算机上的 web 门户，与 Windows 管理中心进行交互。门户为服务器管理的几乎每个方面提供控制。对于使用 PowerShell 和/或单独的基于 GUI 的管理工具进行服务器管理来说，这是一种可行的、甚至是聪明的替代方法。表 5-1 列出了 Windows 管理中心整合的 27 个具体管理工具。

表 5-1

Windows 管理中心中包含的服务器管理功能

Azure 混合服务

防火墙

角色和功能

| | --- | --- | --- | | Azure 备份 | 安装的应用 | 计划任务 | | Azure 文件同步 | 本地用户和组 | 服务 | | 天蓝色监视器 | 网络 | 仓库 | | Azure 安全中心 | 性能监控器 | 存储迁移服务 | | 证书 | 管理员 | 存储副本 | | 设备 | 处理 | 系统洞察 | | 事件 | 登记处 | 设置:环境变量 | | 文件和文件共享 | 远程桌面 | 设置:电源配置 |

微软继续投资 Windows 管理中心，并指导 Windows Server 2022 的客户将 Windows 管理中心视为服务器管理的主要方法。如果您已经在使用 Windows 管理中心，或者正在等待在您的环境中部署它的用例，请考虑您可以将其用于 Azure Arc server onboarding。在某些方面，Windows 管理中心是大规模加入 Azure Arc server 的简化方法。以下是这种方法的“利弊”考虑因素的简短列表:

Azure Arc 优点:Windows 管理中心

它不需要也不使用服务主体。
它不需要使用脚本来进行入职培训。
Windows 管理中心本身易于安装和使用。

Azure Arc 缺点:Windows 管理中心

一次装载一台服务器。
被授权将服务器装载到您的 Azure 订阅的用户必须登录。
您不能在创建服务器时将标签分配给 Azure Arc 服务器。

该解决方案以与第四章“Azure Arc 服务器:入门”中详述的交互式脚本方法相同的方式使用已登录用户的 Azure 凭据不同之处在于，用户不需要复制设备代码并单独登录来验证他们的 Azure 用户身份(在交互式脚本方法中会发生这种情况)。

使用 Windows 管理中心将服务器装载到 Azure Arc 的其他注意事项包括:

搭载 Azure Arc 服务器所需的最低内置 Azure 订阅安全角色是Azure Connected Machine on boarding。登录到 Windows 管理中心控制台的用户必须在您的 Azure 订阅中拥有此权限。(要删除机器，用户需要Azure Connected Machine Resource Administrator角色。)
虽然将 Windows 管理中心实例连接到 Azure 订阅确实会创建 Azure AD 应用注册(服务主体)，通常命名为*Windows Admin Center-https://，*该服务主体不会用于 Azure Arc onboarding 操作。
您不能选择使用预先创建的 Azure Arc 服务主体来启动服务器，如本章的“为启动创建服务主体”一节中所述。
确保微软。HybridCompute 和微软。GuestConfiguration 在尝试使用 Windows 管理中心加载 Azure Arc 服务器之前，Azure 资源提供程序已在您的 Azure 订阅中注册。

逐步:使用 Windows 管理中心添加 Azure Arc 服务器

此过程假设您已经在环境中的服务器上安装了 Windows 管理中心，并且至少连接了一个您希望加载到 Azure Arc 的服务器。

img/506033_1_En_5_Fig13_HTML.png

图 5-13

Windows 管理中心连接的服务器的设置页面

登录 Windows 管理中心。
在概览页面的所有连接列表中，在已连接的 Windows 服务器列表中，从列表中选择一台服务器进行连接。
从左侧窗格中，选择设置。
在设置页面中，选择Azure Arc for servers；点击开始。
在 Windows 管理中心 blade 的 Azure 入门中，点击复制按钮，如图 5-13 所示。

img/506033_1_En_5_Fig14_HTML.png

图 5-14

在 Windows 管理中心控制台中部署 Azure Arc 服务器之前的最后一步

点击输入代码链接，在打开的网页中粘贴代码。
出现提示时，选择有权限将 Azure Arc 服务器添加到您的订阅的 Azure 登录身份。
关闭登录 Azure 页面，您会发现连接到 Azure Active Directory 步骤填充了一个或多个 Azure Active Directory 租户 id。从下拉列表中选择您的租户，选中 Create new 单选按钮，点击 Connect 。
点击按钮中的标志。当请求权限对话框出现时，点击接受按钮。
返回到服务器刀片的 Azure Arc，再次点击开始按钮。
在Connect server to Azureblade，选择想要创建 Azure Arc 服务器的 Azure 订阅、资源组和 Azure 区域，点击设置按钮，如图 5-14 所示。
您将看到一个 Windows 管理中心任务“为服务器设置 Azure Arc ”,该任务将运行几分钟。
When Azure Arc for server is set up for a connected server in Windows Admin Center, you will see a view like Figure 5-14 with shortcuts to these items:

图 5-15

Azure Arc 用于与 Windows 管理中心集成的服务器
- 在 Azure 中查看此服务器在 Azure 门户中为连接的服务器打开 Azure Arc 服务器页面。
- 此服务器连接到链接打开 Azure 门户中的资源组页面，Azure Arc 服务器是该页面的成员。
- 从 Azure 订阅中删除 Azure Arc 服务器对象的 Disconnect 服务器按钮。
- 到 Azure Policy 和 Azure Monitor 搜索日志的链接。

要板载后续服务器，不需要重复步骤 1 到 9；事实上，你可以从步骤 10 开始:从一个连接的服务器的设置刀片，打开 Azure Arc for servers 项，点击开始按钮。对所有要装载到 Azure Arc 的服务器重复步骤 10 和 11。

在 Azure Arc 服务器上使用标签

当混合机器连接到 Azure 时，它就变成了一台连接的机器，并受益于标准的 Azure 构造，如 Azure 策略和应用标签。使用 Azure 作为管理引擎来轻松组织和管理服务器库存的能力大大降低了管理复杂性，并为混合和多云环境提供了一致的策略。在 Azure Arc 服务器上应用和使用标签是你的组织的力量倍增器。图 5-16 提示了标签如何出现在任何给定 Azure Arc 服务器的 Azure portal 概览页面中。

img/506033_1_En_5_Fig16_HTML.png

图 5-16

应用于 Azure Arc 服务器的 Azure 资源标签

用标签增加商业价值

最好的标记方案包括与业务一致的焦点，例如会计、业务所有权和业务关键程度，它们反映了业务利益并随着时间的推移保持这些标准。投资于标记系统可为整体业务提供更好的 IT 资产成本和价值核算。资产的业务价值与其运营成本之间的这种关联，是在更广泛的组织内改变成本中心对 IT 的看法的一项关键活动。

组织基于云的资源对 IT 来说是一项至关重要的任务，除非您只有简单的部署。这里有一些标签标准，可以考虑用来组织你的资源，有标签对的例子，因为它们可能应用于 Azure Arc 服务器的管理:

资源管理:City/Bellevue, Datacenter/West-Campus
成本管理和优化:Department/Marketing, Promotion/Spring2020
运营管理:Vendor/Dell, Network/HQ-LAN-A
安全性:Owner/Jill.Smith@company.com, JIT enabled/Yes
治理和法规遵从性:HIPAA HITRUST/Yes, ISO 27001/Yes
自动化:Backup Policy/DailyFull-LRS-Retain365days, Patching Group/Wave2-West
工作负载优化:Shutdown allowed/Weekend-Holiday, Shutdown allowed/Weeknight-Weekend-Holiday

图 5-17 提供了开始使用标签的建议，这是你的 Azure 门户中可用的标签页面。请注意，左栏列出了在 Azure 订阅的资源上找到的所有标记名称/值对。点击左边的任何标签对，就会在右边调出具有相同标签名/值对的所有 Azure 资源的详细视图。

img/506033_1_En_5_Fig17_HTML.png

图 5-17

使用 Azure 门户中的标签窗格来探索标签关联

关于 Azure 资源标签的一切

标签是一种半随机的管理元数据，由人类和流程使用，以发出信号并相互交互。您或流程会留下一个标签，供其他人或流程读取，以帮助做出未来决策或选择自动操作。把它们想象成旗帜或标记。
Azure 资源标签有两个元素:标签名和标签值，就像City/Bellevue。
每个 Azure Arc 服务器的每个名称都可以有一个标记(如“City”)，因此您只能将标记类型的一个值(如“Bellevue”)与每个服务器关联。换句话说，一台服务器上不能有两个城市标签，每个标签只能有一个值字段(比如城市名)。
Azure 记住了标签名称和标签值的范围。您可以预先创建标记名和值，以供用户在创建新资源时选择。Azure 还会记住订阅中已经存在的所有标签和值。为了避免标签泛滥，在头脑中有一个标签名称和值对计划，并帮助用户坚持它。
您可以构建管理产品和解决方案，如警报、查询、策略、报告和仪表板，这些产品和解决方案可以对标签进行排序和输入。首先，您为资源分配标签和值；然后，您制作寻找您已经部署的标签的管理工件。想想这个简单的例子:您的服务器管理员或配置过程向服务器添加了一个关于特定备份策略的标记。备份自动化扫描带有该标签的计算机，并自动应用正确的备份策略—备份刚刚开始。只需添加一个标签。
使用 Azure 策略，你可以让 Azure 资源自动从它们的资源组继承标签。同样使用 Azure 策略，您可以强制特定标签的存在来执行操作任务。大型 Azure 地产通过政策和标签得到了良好的管理。Azure Arc 是您在整个资产中利用这种高级管理模式的机会，无论是在 Azure 中还是在非 Azure 中。

对启用 Azure Arc 的服务器应用清单标记

以下步骤将创建一个有用的服务器库存管理功能，演示如何在 Azure Arc 服务器上使用标签。请注意，我们正在创建有意义的标记值，这些值与我们的环境相匹配，并且我们打算用于我们的管理目的。(只创建将被使用的标签值，而不仅仅是“有就好。”)用您环境中存在的值替换供应商名称和虚拟化类型。

在您的 Azure 门户中打开 Azure CLI，并运行以下命令来创建基本分类，该分类允许您查询和报告您的 Azure Arc 服务器与哪种硬件或虚拟化平台相关联:
现在，您需要将标记名称/值对添加到订阅中的 Azure Arc 服务器。此 Azure PowerShell 为本地物理计算机增加了“服务器平台/戴尔主机”的价值:

az tag create --name "Server Platform"
az tag add-value --name "Server Platform" --value "HP Host"
az tag add-value --name "Server Platform" --value "Dell Host"
az tag add-value --name "Server Platform" --value "HV Guest"
az tag add-value --name "Server Platform" --value "ESX Guest"

$tag = @{"Server Platform"="Dell Host"}
$VM = Get-AzResource -ResourceGroupName RG-DEV-EUS -Name Venus
Set-AzResource -ResourceId $vm.Id -Tag $tag -Force

为每个 Azure Arc 服务器重新运行这组 PowerShell，适当地更改服务器平台标记。

在您将服务器平台标签应用到所有 Azure Arc 服务器之后，使用资源图浏览器来查询它们并深入了解您的云计算环境。在“查询”窗口中，输入以下查询:

Resources
| where type =~ 'Microsoft.HybridCompute/machines'
| where isnotempty(tags['Server Platform'])
| project name, location, resourceGroup, tags

Azure 资源图浏览器是 Azure 门户的一部分，支持直接在 Azure 门户中运行资源图查询。

img/506033_1_En_5_Fig18_HTML.png

图 5-18

Azure 资源图浏览器显示格式化的结果

点击运行查询，然后选择格式的结果切换。如图 5-18 所示，列出了所有支持 Azure Arc 的服务器及其分配的服务器平台标签值。您可以轻松地查询和报告服务器资源是如何托管的。例如，您可以将结果固定为一个图表，为您的门户工作流提供 Azure Arc 服务器的实时动态信息。

使用 Azure Monitor 工作簿的仪表板混合服务器数据

图表和图形等可视化工具可以帮助您分析监控数据，从而深入了解问题并识别模式。Azure Monitor 工作簿和仪表板允许您利用来自 Azure 的多个数据源，并将它们组合成单一控制台体验。

在 Azure Arc 服务器的情况下，我们可以利用这种能力来创建所有云中所有服务器的融合显示。按照以下步骤创建 Azure Monitor 工作簿，该工作簿具有真正的“所有服务器”视图:

从你的 Azure Log Analytics 工作区的工作簿刀片中，点击新建按钮。
点击新工作簿文本项下的编辑，可以选择更改标题和文本，例如“Azure Arc workbook”，然后点击完成编辑。
在编辑查询项:query -2 部分，将查询数据源更改为 Azure Resource Graph ，将可视化和大小更改为“Grid”和“Full”，粘贴该查询，如图 5-19 所示。点击 Run Query，观察 Azure 虚拟机和 Azure Arc 服务器都在网格中列出。

img/506033_1_En_5_Fig19_HTML.png

图 5-19

在 Azure Monitor 工作簿中嵌入 Azure 资源图表网格

resources
| where type == "microsoft.hybridcompute/machines" or type == "microsoft.compute/virtualmachines"
| mvexpand prop=properties.provisioningState
| project ComputerName = id,  Status = properties.status, State=prop, location, resourceGroup, type, tags

img/506033_1_En_5_Fig20_HTML.png

图 5-20

混合资产可视化:Azure 虚拟机和 Azure Arc 服务器在一个列表中

单击高级设置选项卡，输入“所有服务器”作为图表标题，然后单击完成编辑。
单击工作簿顶部的完成编辑，然后单击保存图标。为工作簿命名，如“Azure Arc ”,然后单击保存按钮。
图 5-20 显示了到目前为止的工作簿，清晰地列出了 Azure 和其他云中的所有 Windows 和 Linux 服务器，包括它们的标签。单击“图钉”图标会将此工作簿保存到您所选的仪表板，在该仪表板上，您所有服务器资产的准确实时数据将始终可用。
让我们再增加一个可视化来演示 Azure 资源图和 Azure Monitor 工作簿的映射功能。单击工作簿最底部的添加查询按钮
在编辑查询项部分，将查询数据源更改为 Azure Resource Graph，将可视化和大小更改为“Map”和“Medium”，然后粘贴该查询。

img/506033_1_En_5_Fig21_HTML.jpg

图 5-21

混合资产映射:Azure 虚拟机和 Azure Arc 服务器的组合位置

点击运行查询并观察显示位于每个 Azure 区域的 Azure 虚拟机和 Azure Arc 服务器数量的世界地图(图 5-21 )。使用默认的“热图”拓扑，具有较高计数的站点具有较大的圆圈和较暖的颜色。

resources
| where type == "microsoft.hybridcompute/machines" or type == "microsoft.compute/virtualmachines"
| extend location
| summarize VMCount=count() by location
| order by VMCount desc

点击高级设置选项卡，输入“按地区服务器数”作为图表标题，然后点击完成编辑两次，然后点击保存图标。

Azure Arc 服务器状态疑难解答

Azure Arc 代理安装问题

Azure Arc 代理的维护成本非常低，安装和卸载都非常快速简单。代理安装问题可能涉及 Azure 订阅端和/或 Azure Arc 服务器端。如果运行 azcmagent 工具的 Azure Arc 安装脚本可以到达微软，但在安装过程中失败，请查看 Azure 订阅中的活动日志以了解云端失败的线索。

例如，图 5-22 显示 Azure Arc machine onboarding 失败的原因是微软。HybridCompute 资源提供者未注册 Azure 订阅。在搜索过滤器中键入“Azure Arc machines”以仅显示涉及 Azure Arc 服务器的 Azure 活动日志条目。

img/506033_1_En_5_Fig22_HTML.png

图 5-22

Azure 活动日志是排除代理入职故障的关键

如果您的安装过程被 Azure communications 或本地访问问题阻塞，那么设置为“详细”操作的 azcmagent 工具的日志将是最相关的。要收集详细日志，请尝试使用 azcmagent.exe 工具和开关“--verbose”安装 Azure Connected Machine Agent，然后查看这些位置的日志，寻找代理端故障的线索:

代理日志位置

Windows Azure Arc 代理安装日志位置
Linux Azure Arc 代理安装日志位置

%ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log

/var/opt/azcmagent/log/azcmagent.log

代理安装命令行

以下是在使用服务主体执行大规模安装时，使用 Windows 和 Linux 的已连接计算机代理启用详细日志记录的命令示例:

Windows Azure Arc 代理安装
Linux Azure Arc 代理安装

& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect --resource-group "resourceGroupName" --tenant-id "tenantID" --location "regionName" --subscription-id "subscriptionID" –verbose

azcmagent connect --resource-group "resourceGroupName" --tenant-id "tenantID" --location "regionName" --subscription-id "subscriptionID" --verbose

代理卸载过程

从控制面板卸载 Windows 代理➤程序和功能➤ Azure Connected Machine 代理➤通过双击azureconnectedmachineagent . MSI安装程序包卸载或运行代理安装向导。
根据您的 Linux 操作系统，使用以下命令之一卸载 Linux 代理:
- Ubuntu:
  
  sudo apt purge azcmagent
- RHEL、CentOS、Amazon Linux:
  
  sudo yum remove azcmagent
- SLES:
  
  sudo zypper remove azcmagent

Azure Arc 代理操作问题

在操作中，代理通信很简单:大约每 5 分钟就有一次到 Azure Arc 服务器所在区域的微软云中的 HTTPS 端点的出站心跳通信。图 5-23 显示了发送心跳消息的 Windows 和 Linux 代理的正常状态。(HTTP 状态代码 204 表示“成功，没有要发送的附加内容。”)

img/506033_1_En_5_Fig23_HTML.png

图 5-23

Windows 和 Linux Azure Arc 代理发送心跳消息

如果出站通信中断，在客户端，您会在 Azure Arc 服务器的 himds.log 文件中看到错误消息。也就是说，在“通过 HTTP 向服务发送心跳”消息之后，将不会有 HTTP 状态代码 204；可能会有其他的东西帮助你理解问题所在。

识别断开连接的 Azure Arc 服务器

在 Azure cloud 端，代理心跳丢失将导致 Azure Arc 服务器状态在 15 分钟内从连接更改为断开连接。以下 Azure 资源图查询将仅在一个或多个 Azure Arc 服务器未处于连接状态时返回数据:

resources
| where type == "microsoft.hybridcompute/machines"
| project ComputerName = id,  Status = properties.status, location, resourceGroup, type, tags
| where Status != "Connected"

考虑将前面的 Azure 资源图查询保存到我们在本章前面创作的 Azure Arc 工作簿(将其命名为“Azure Arc 代理未连接”)。如果任何 Azure Arc 服务器名称出现在网格中，您需要调查相关服务器的 Azure Connected Machine Agent 状态。图 5-24 显示了几个处于断开状态的 Azure Arc 服务器。

img/506033_1_En_5_Fig24_HTML.jpg

图 5-24

Azure 资源图查询生成断开连接的 Azure Arc 服务器列表

Windows 和 Linux 计算机上的 Azure Arc 服务

Azure Arc 服务器处于断开状态的一个常见原因是计算机上的一个或多个 Azure Arc 服务(或守护程序)被停止。这里有一些关于识别和重启 Azure Arc 使用的服务和守护进程的提示。

视窗服务

Azure 混合实例元数据服务(himds)
来宾配置 Arc 服务(GCArcService)
来宾配置扩展服务(Extension service)

在 Windows 计算机上重新启动所有 Azure Arc 服务的命令(需要在提升的 PowerShell 会话中运行):

Restart-Service -Name himds
Restart-Service -Name GCArcService
Restart-Service -Name ExtensionService

Linux 守护进程

Azure 连接的计算机代理服务(himdsd.service)
GC Arc 服务(gcad.service)
扩展服务(extd.service)

在 Linux 计算机上重启所有 Azure Arc 守护进程的命令:

sudo systemctl restart himdsd.service
sudo systemctl restart gcad.service
sudo systemctl restart extd.service

Tip

如果您已经将 Azure Automation 更改跟踪解决方案部署到您的 Azure Arc 服务器，您可以运行以下计划查询警报规则，以确定 Azure Arc 相关服务何时在 Windows 和 Linux 计算机上停止:

ConfigurationChange | where ConfigChangeType contains "WindowsServices" or ConfigChangeType contains "Daemons"

| where SvcState contains "Stopped" | where SvcPreviousState contains "Running"

| where SvcName in ("himds", "GCArcService", "ExtensionService", "himdsd.service", "gcad.service", "extd.service")

摘要

在本章中，你学习了如何大规模部署和管理 Azure Arc 服务器，包括创建和使用 Azure 广告服务主体。我们还讨论了更高级的 Azure Arc 特性，如标签和仪表板，以及在所有场景中对 Azure Arc 服务器进行故障排除。您现在已经掌握了专业部署和支持 Azure Arc 连接机器的所有知识。在接下来的两章中，我们将使用 Azure Arc 构建两个企业解决方案。第六章“混合服务器监控解决方案”部署了一个监控和警报解决方案，第七章“Azure Arc 服务器的法规和安全合规性”部署了一个安全解决方案。

Azure-Arc-Kubernetes-和服务器教程-一-