部署 IT 基础架构服务或业务应用程序对任何公司来说都是一项挑战。为了很好地执行它并避免任何不受欢迎的意外和计划外成本，您需要对其进行彻底的计划，以确保您尽可能做好准备。若要规划以任何规模部署已启用 Azure Arc 的服务器，它应涵盖成功完成任务所需的设计和部署条件。为了使部署顺利进行，我们的计划应清楚地了解：
- 角色和职责。
- 物理服务器或虚拟机的清单，以验证它们是否满足网络和系统要求。
- 实现成功部署和持续管理所需的技能和培训。
- 验收标准以及您如何跟踪其成功。
- 用于自动执行部署的工具或方法。
- 确定风险和缓解计划，以避免延误、中断等。
- 如何避免部署期间中断。
- 发生重大问题时的上报路径是什么？
本文的目的是确保你已准备好在环境中的多个生产物理服务器或虚拟机上成功部署已启用 Azure Arc 的服务器。
一、先决条件
规划部署时，请考虑以下基本要求：
- 您的计算机必须为连接的计算机代理运行受支持的操作系统。
- 计算机必须直接从本地网络或其他云环境直接或通过代理服务器连接到 Azure 中的资源。
- 若要安装和配置 Azure 连接的计算机代理，必须在计算机上具有提升的权限（即管理员或根用户）的帐户。
- 若要接入计算机，必须具有Azure Connected Machine 接入Azure 内置角色。
- 若要读取、修改和删除计算机，必须具有Azure Connected Machine 资源管理员 Azure 内置角色。
（一）支持的环境
已启用 Azure Arc 的服务器支持在托管在 Azure 外部的物理服务器和虚拟机上安装连接的计算机代理。这包括对在以下平台上运行的虚拟机的支持：
- VMware（包括Azure VMware Solution）
- Azure Stack HCI
- 其他云环境
不应在托管在 Azure、Azure Stack Hub 或 Azure Stack Edge 中的虚拟机上安装 Azure Arc，因为它们已经具有类似的功能。但是，只能出于测试目的使用 Azure VM 模拟本地环境。
在以下系统上使用 Azure Arc 时要格外小心：
- 克隆
- 作为服务器的第二个实例从备份还原
- 用于创建从中创建其他虚拟机的“母映像”
如果两个代理使用相同的配置，则当两个代理尝试充当一个 Azure 资源时，将遇到不一致的行为。对于这些情况，最佳做法是在克隆服务器、从备份还原服务器或从最佳配置映像创建服务器后，使用自动化工具或脚本将服务器接入 Azure Arc。
（二）支持的操作系统
Azure Arc 支持以下 Windows 和 Linux 操作系统。仅支持 x86-64（64 位）体系结构。Azure Arc 不在 x86（32 位）或基于 ARM 的体系结构上运行。
- Windows Server 2008 R2 SP1、2012 R2、2016、2019 和 2022
- 支持桌面和服务器核心体验
- Azure Stack HCI 支持 Azure Editions
- Windows 10、11
- Windows IOT企业版
- Azure Stack HCI
- Ubuntu 16.04、18.04、20.04 和 22.04 LTS
- Debian 10 和 11
- CentOS Linux 7 和 8
- Rocky Linux 8
- SUSE Linux Enterprise Server （SLES） 12 和 15
- Red Hat Enterprise Linux （RHEL） 7、8 和 9
- Amazon Linux 2
- Oracle Linux 7 和 8
（三）客户端操作系统指南
Azure Arc 服务和 Azure 连接的计算机代理仅在类似服务器的环境中使用这些计算机时，才在 Windows 10 和 11 客户端操作系统上受支持。也就是说，计算机应始终：
- 连接到互联网
- 已连接到电源
- 已通电
例如，运行 Windows 11 的计算机负责数字标牌、销售点解决方案和常规后台管理任务，非常适合 Azure Arc。最终用户生产环境计算机（如笔记本电脑）可能会长时间脱机，不应使用 Azure Arc，而应考虑使用 Microsoft Intune 或 Microsoft Configuration Manager。
（四）短期服务器和虚拟桌面基础架构
微软不建议在短期（临时）服务器或虚拟桌面基础结构 （VDI） VM 上运行 Azure Arc。 Azure Arc 专为服务器的长期管理而设计，未针对定期创建和删除服务器的情况进行优化。例如，Azure Arc 不知道代理是否由于计划内系统维护而脱机，或者 VM 是否已删除，因此它不会自动清理停止发送检测信号的服务器资源。因此，如果重新创建具有相同名称的 VM，并且存在具有相同名称的现有 Azure Arc 资源，则可能会遇到冲突。
Azure Stack HCI 上的 Azure 虚拟桌面不使用短期 VM，并支持在桌面 VM 中运行 Azure Arc。
（五）软件要求
Windows操作系统：
- NET Framework 4.6 或更高版本。
- Windows PowerShell 4.0 或更高版本（已包含在 Windows Server 2012 R2 及更高版本中）。对于 Windows Server 2008 R2 SP1，请下载并安装Windows Management Framework 5.1。
Linux 操作系统：
- systemd
- wget （下载安装脚本）
- openssl
- gnupg
（六）所需权限
对于管理连接的计算机的不同方面，将需要以下 Azure 内置角色：
- 若要接入计算机，必须具有要在其中管理服务器的资源组的 Azure 连接计算机载入或参与者角色。
- 若要读取、修改和删除计算机，必须具有资源组的 Azure Connected Machine资源管理员角色。
- 若要在使用“生成脚本”方法时从下拉列表中选择资源组，还需要该资源组的“读取者”角色（或包含“读取者”访问权限的其他角色）。
（七）Azure 订阅和服务限制
可以在任何单个资源组、订阅或租户中注册已启用 Azure Arc 的服务器数没有限制。每个已启用 Azure Arc 的服务器都与一个 Azure Active Directory 对象相关联，并计入目录配额。
（八）Azure 资源提供程序
若要使用已启用 Azure Arc 的服务器，必须在订阅中注册以下 Azure 资源提供程序：
- Microsoft.HybridCompute
- Microsoft.GuestConfiguration
- Microsoft.HybridConnectivity
- Microsoft.AzureArcData（如果您计划启用 Arc-enable SQL Server）
可以在 Azure 门户中注册资源提供程序
二、试点
在部署到所有生产环境之前，请先评估部署过程，然后再在您的环境中广泛采用它。对于试点，要确定对公司开展业务不重要的具有代表性的机器样本。需要确保留出足够的时间来运行试点并评估其影响：微软建议至少 30 天。
制定正式计划，描述试点的范围和细节。以下是计划应包含的内容的示例：
- 目标 - 描述导致决定需要试点的业务和技术驱动因素。
- 选择条件 - 指定用于选择将通过试点演示解决方案的哪些方面的条件。
- 范围 - 描述试点的范围，包括但不限于解决方案组件、预期计划、试点持续时间和目标计算机数。
- 成功标准和指标 - 定义试点的成功标准和用于确定成功级别的特定度量值。
- 培训计划 - 描述培训系统工程师、管理员等的计划。在试点期间不熟悉 Azure 和 IT 服务的人员。
- 过渡计划 - 描述用于指导从试点过渡到生产的策略和标准。
- 回滚 - 介绍将试点回滚到部署前状态的过程。
- 风险 - 列出执行试点以及与生产部署关联的所有已识别风险。
三、第一阶段：奠定基础
在此阶段，系统工程师或管理员在其组织的 Azure 订阅中启用核心功能以启动基础，然后再启用计算机由已启用 Azure Arc 的服务器和其他 Azure 服务进行管理。
任务 |
细节 |
估计持续时间 |
创建资源组 |
专用资源组，仅包含已启用 Azure Arc 的服务器，并集中管理和监视这些资源。 |
一小时 |
应用标记以帮助组织计算机。 |
评估并制定与 IT 一致的标记策略，该策略可帮助降低管理已启用 Azure Arc 的服务器的复杂性，并简化管理决策。 |
有一天 |
设计和部署 Azure 监视器日志 |
评估设计和部署注意事项，以确定组织是应使用现有 Log Analytics 工作区还是实现另一个 Log Analytics 工作区来存储从混合服务器和计算机收集的日志数据。 |
一天 |
制定 Azure 策略治理计划 |
确定如何使用 Azure 策略在订阅或资源组范围内实现混合服务器和计算机的治理。 |
一天 |
配置基于角色的访问控制 （RBAC） |
制定访问计划，以控制谁有权管理已启用 Azure Arc 的服务器，以及能够从其他 Azure 服务和解决方案查看其数据。 |
一天 |
识别已安装日志分析代理的计算机 |
在 Log Analytics 中运行以下日志查询，以支持将现有 Log Analytics 代理部署转换为扩展托管代理： 检测信号 |汇总arg_max（TimeGenerated ， OSType， ResourceId， ComputerEnvironment） by Computer |where ComputerEnvironment == “Non-Azure” and isempty（ResourceId） |project Computer，OSType |
一小时 |
注意：在评估 Log Analytics 工作区设计时，需要考虑与 Azure 自动化集成，以支持其更新管理、更改跟踪和清单功能，以及 Microsoft Defender for Cloud 和 Microsoft Sentinel。如果你的组织已有自动化帐户并启用了与 Log Analytics 工作区链接的管理功能，请评估是否可以集中和简化管理操作，并通过使用这些现有资源而不是创建重复的帐户、工作区等来最大限度地降低成本。
四、第二阶段：部署已启用 Azure Arc 的服务器
接下来，我们通过准备和部署 Azure 连接的计算机代理来添加阶段一中奠定的基础。
任务 |
细节 |
估计持续时间 |
下载预定义的安装脚本 |
查看并自定义预定义的安装脚本，以便大规模部署连接的计算机代理，以支持自动部署要求。 |
一天或多天，具体取决于要求、组织流程（例如，变更和发布管理）以及使用的自动化方法。 |
创建服务主体 |
创建服务主体，以使用 Azure PowerShell 或Azure从门户以非交互方式连接计算机。 |
一小时 |
将Connected Machine代理部署到目标服务器和计算机 |
使用自动化工具将脚本部署到服务器，并将其连接到 Azure。 |
一天或多天，具体取决于您的发布计划以及是否在分阶段推出之后。 |
五、第三阶段：管理和运营
第三阶段是管理员或系统工程师可以启用手动任务的自动化，以在连接的机器代理和计算机的生命周期中管理和操作计算机。
任务 |
细节 |
估计持续时间 |
创建资源运行状况警报 |
如果服务器停止向 Azure 发送检测信号的时间超过 15 分钟，则可能意味着它处于脱机状态、网络连接已被阻止或代理未运行。制定如何响应和调查这些事件的计划，并使用资源运行状况警报在事件开始时收到通知。 配置警报时指定以下内容： 资源类型 = 已启用 Azure Arc 的服务器 当前资源状态 = 不可用 以前的资源状态 = 可用 |
一小时 |
创建 Azure 顾问警报 |
为了获得最佳体验以及最新的安全和 bug 修复，我们建议使 Azure 连接的计算机代理保持最新。过期的代理将通过 Azure 顾问警报进行标识。 配置警报时指定以下内容： 建议类型 = 升级到最新版本的 Azure 连接的计算机代理 |
一小时 |
将 Azure 策略分配到订阅或资源组范围 |
将“为 VM 启用 Azure 监视器”策略（以及满足你需求的其他策略）分配到订阅或资源组范围。Azure Policy 允许分配策略定义，用于安装所需的代理，以便在整个环境中获得 VM 见解。 |
不同 |
为已启用 Azure Arc 的服务器启用更新管理 |
在 Azure 自动化中配置更新管理，以管理向已启用 Azure Arc 的服务器注册的 Windows 和 Linux 虚拟机的操作系统更新。 |
15 分钟 |
