对于任何一家公司而言，部署 IT 基础结构服务或业务应用程序都充满了挑战。 若要顺利执行此任务并避免任何意外变故和计划外成本，需要进行全面的规划，确保做好尽量充分的准备。 若要计划以任何规模部署已启用 Azure Arc 的服务器，它应涵盖需要满足的设计和部署条件，以便成功完成任务。
要使部署顺利进行，应在计划中明确以下方面的认知：
- 角色和职责。
- 清点物理服务器或虚拟机，以验证它们是否满足网络和系统要求。
- 实现成功部署和持续管理所需的技能集和培训。
- 验收条件以及如何跟踪其成功结果。
- 用于自动化部署的工具或方法。
- 已确定的风险和缓解计划列表，旨在避免延误、中断等问题。
- 有关在部署期间避免中断的计划。
- 出现重大问题时的事务升级路径。
本文可帮助你准备在环境中多个生产物理服务器或虚拟机上成功部署已启用 Azure Arc 的服务器。
若要详细了解我们的大规模部署建议，还可以参考此视频。
先决条件
在规划部署时，请考虑以下基本要求：
- 您的设备必须运行支持的操作系统，以使用Connected Machine Agent。
- 计算机必须直接或者通过代理服务器从本地网络或其他云环境连接到 Azure 中的资源。
- 若要安装并配置 Azure Connected Machine Agent，你必须有一个在计算机上拥有提升特权的帐户（即管理员或 root 帐户）。
- 若要加入计算机，必须具有“Azure Connected Machine 加入”Azure 内置角色。
- 若要读取、修改和删除计算机，你必须有“Azure Connected Machine 资源管理员”Azure 内置角色。
有关详细信息，请参阅安装 Connected Machine 代理的 先决条件 和 网络要求 。
Azure 订阅和服务限制
可以在任何一个资源组、订阅或租户中注册的已启用 Azure Arc 的服务器数量没有限制。
每个已启用 Azure Arc 的服务器都与一个 Microsoft Entra 对象相关联，并计入目录配额。 有关可以在 Microsoft Entra 目录中使用的最大对象数量的信息，请参阅 Microsoft Entra 服务限制和局限性。
试点
在部署到所有生产计算机之前，请先评估部署过程，然后再在环境中广泛采用这种部署。 要进行试点，请确定几台有代表性的、对公司业务运营不很关键的计算机。 确保有足够的时间来运行试点并评估其影响：建议至少 30 天。
制定正式的计划用于描述试点范围和细节。 你的计划通常应包含以下项：
- 目标 - 描述哪些业务和技术驱动因素导致你认定试点是有必要的。
- 选择标准 - 指定用于通过试点展示解决方案具体方面的标准。
- 范围 - 描述试点范围，包括但不限于解决方案组件、预计计划、试点持续时间和试点所针对的计算机数量。
- 成功条件和指标 - 定义试点的成功条件，以及用于确定成功程度的具体措施。
- 培训计划 - 描述在试点期间对 Azure 及其服务不太熟悉的系统工程师、管理员等人员的培训计划。
- 过渡计划 - 描述用于引导从试点环境过渡到生产环境的策略和条件。
- 回滚 - 描述从试点回滚到部署前状态的过程。
- 风险 - 列出所有已识别到的，与开展试点以及与生产部署相关的风险。
第 1 阶段：构建基础
在此阶段，系统工程师或管理员会在其组织的 Azure 订阅中启用核心功能，以奠定基础，然后再通过 Azure Arc 启用的服务器和其他 Azure 服务对计算机进行管理。
| 任务 | 详细信息 | 预计持续时间 |
|---|---|---|
| 创建资源组 | 专用的资源组，只包含已启用 Azure Arc 的服务器，并对这些资源进行集中式管理和监视。 | 一小时 |
| 规划 标记 以帮助组织计算机。 | 评估并制定符合 IT 部门要求的标记策略，以帮助降低管理已启用 Azure Arc 的服务器的复杂性，并简化管理决策。 | 一天 |
| 设计并部署 Azure Monitor 日志 | 评估设计和部署注意事项，确定组织应该使用现有的 Log Analytics 工作区还是实施另一个 Log Analytics 工作区来存储从混合服务器和计算机收集的日志数据。 | 一天 |
| 制定 Azure Policy 治理计划 | 确定如何使用 Azure Policy 在订阅或资源组范围内实现混合服务器和计算机的治理。 | 一天 |
| 配置基于角色的访问控制 (RBAC) | 制定访问计划，用于控制谁有权管理已启用 Azure Arc 的服务器并能够从其他 Azure 服务和解决方案查看这些服务器的数据。 | 一天 |
| 识别已安装 Azure Monitor 代理的计算机 | 在 Log Analytics 中运行以下日志查询，以支持将现有 Azure Monitor 代理部署转换为扩展托管代理： 心跳 | summarize arg_max(TimeGenerated, OSType, ResourceId, ComputerEnvironment) by Computer | where ComputerEnvironment == "Non-Azure" and isempty(ResourceId) | project Computer, OSType |
一小时 |
第 2 阶段：部署已启用 Azure Arc 的服务器
接下来，我们通过准备并部署 Azure Connected Machine Agent，在第 1 阶段打下的基础上补充内容。
| 任务 | 详细信息 | 预计持续时间 |
|---|---|---|
| 下载预定义安装脚本 | 查看并自定义用于大规模部署 Connected Machine Agent 来支持自动化部署要求的预定义安装脚本。 大规模加入资源的示例：
|
一天或多天，具体取决于要求、组织流程（例如，更改和发布管理）以及使用的自动化方法。 |
| 创建服务主体 | 创建一个服务主体，以使用 Azure PowerShell 或从门户以非交互方式连接计算机。 | 一小时 |
| 将 Connected Machine Agent 部署到目标服务器和计算机 | 使用自动化工具将脚本部署到服务器，然后将服务器连接到 Azure。 | 一天或多天，具体取决于发布计划，以及是否遵循分阶段实施方案。 |
第 3 阶段：管理和操作
第 3 阶段是指管理员或系统工程师能够使手动任务自动化，以便在 Connected Machine Agent 和计算机的整个生命周期内对其进行管理和操作。
| 任务 | 详细信息 | 预计持续时间 |
|---|---|---|
| 创建资源运行状况警报 | 如果服务器停止向 Azure 发送心跳信号超过 15 分钟，则可能意味着服务器脱机、网络连接被阻塞或代理未运行。 制定一个计划来规定如何应对和调查这些事件，并使用资源运行状况警报以便在这些事件开始发生时收到通知。 配置警报时请指定以下设置： 资源类型 = 已启用 Azure Arc 的服务器 当前资源状态 = 不可用 以前的资源状态 = 可用 |
一小时 |
| 创建 Azure 顾问警报 | 为获得最佳体验和最新的安全修复和 bug 修复，我们建议让 Azure Connected Machine 代理始终使用最新版本。 可以使用 Azure 顾问警报来识别已过时的代理。 配置警报时请指定以下设置： 建议类型 = 升级到最新版本的 Azure Connected Machine 代理 |
一小时 |
| 在订阅或资源组范围分配 Azure 策略 | 在订阅或资源组范围分配“启用用于 VM 的 Azure Monitor”策略（以及符合需求的其他策略）。 借助 Azure Policy，你可以分配策略定义，以便在整个环境中为 VM 见解安装所需的代理。 | 多种多样 |
| 为已启用 Azure Arc 的服务器启用 Azure 更新管理器。 | 在已启用 Arc 的服务器上配置 Azure 更新管理器，以管理 Windows 和 Linux 虚拟机的系统更新。 可以选择按需部署更新，或使用自定义计划应用更新。 | 5 分钟 |
后续步骤
- 通过面向混合云和多云的 Azure Arc 登陆区域加速器，了解最佳做法和设计模式。
- 了解如何重新配置、升级和删除 Connected Machine Agent。
- 查看代理连接问题排查指南中的故障排除信息。
- 了解如何使用其他 Azure 服务（例如 Azure 自动化 State Configuration 和其他受支持的 Azure VM 扩展）来简化部署。