Azure 本地基线参考体系结构

此基线参考体系结构提供与工作负荷无关的指南和建议，用于配置 Azure Local 2311 和更高版本的基础结构，为高度可用的虚拟化和容器化工作负荷提供可靠的平台。 此体系结构介绍提供本地计算、存储和网络功能的物理计算机的资源组件和群集设计选择。 它还介绍了如何使用 Azure 服务简化 Azure 本地服务的日常管理，以便进行大规模操作。

有关优化为在 Azure 本地上运行的工作负荷体系结构模式的详细信息，请参阅 Azure 本地工作负荷 导航菜单中的内容。

此体系结构是如何使用存储交换机网络设计部署多节点 Azure 本地实例的起点。 应在 Azure 本地实例上部署的工作负荷应用程序架构良好。 必须使用多个实例或高可用性（HA）部署设计良好的工作负载应用程序，并确保对任何关键工作负载服务采取适当的业务连续性和灾难恢复（BCDR）控制措施。 这些 BCDR 控制包括常规备份和 DR 故障转移功能。 为了专注于超融合基础结构（HCI）基础结构平台，本文有意将这些工作负载设计方面排除在外。

有关 Azure Well-Architected 框架五大支柱的指南和建议的详细信息，请参阅Azure 本地 Well-Architected 框架服务指南。

文章布局

Architecture	设计决策	Well-Architected Framework 方法
▪ 建筑 ▪ 组件 ▪ 平台资源 ▪ 平台支持资源 ▪ 方案详细信息 ▪ 将 Azure Arc 与 Azure Local 配合使用 ▪ 利用 Azure 本地默认安全配置 ▪ 潜在用例 ▪ 部署此方案	▪ 群集设计选项 ▪ 物理磁盘驱动器 ▪ 网络设计 ▪ 监测 ▪ 更新管理	▪ 可靠性 ▪ 安全 ▪ 成本优化 ▪ 卓越运营 ▪ 性能效率

Architecture

有关详细信息，请参阅 相关资源。

Components

此体系结构由物理服务器硬件组成，可用于在本地或边缘位置部署 Azure 本地实例。 为了增强平台功能，Azure Local 与 Azure Arc 和其他提供支持资源的 Azure 服务集成。 Azure Local 提供了一个可复原的平台，用于部署、管理和操作用户应用程序或业务系统。 以下各节介绍了平台资源和服务。

平台资源

• Azure 本地 部署在本地或边缘位置并使用物理服务器硬件和网络基础结构的 HCI 解决方案。 Azure Local 提供了一个平台，用于部署和管理虚拟化工作负载，例如虚拟机（VM）、Kubernetes 群集以及 Azure Arc 启用的其他服务。 Azure 本地实例可以使用原始设备制造商（OEM）合作伙伴提供的经验证、集成或高级硬件类别，从单台计算机部署扩展到最多 16 台物理计算机。 在此体系结构中，Azure Local 提供用于在本地或边缘托管和管理虚拟化和容器化工作负荷的核心平台。

• Azure Arc 是一种基于云的服务，可将基于 Resource Manager 的管理模型扩展到 Azure 本地和其他非 Azure 位置。 Azure Arc 使用 Azure 作为控制和管理平面来管理各种资源，例如 VM、Kubernetes 群集以及容器化数据和机器学习服务。 在此体系结构中，Azure Arc 支持通过 Azure 控制平面集中管理和治理 Azure 本地部署的资源。

• Azure Key Vault 是一种云服务，可用于安全地存储和访问机密。 机密是你想要严格限制访问的任何内容，例如 API 密钥、密码、证书、加密密钥、本地管理员凭据和 BitLocker 恢复密钥。 在此体系结构中，Key Vault 保护 Azure 本地上的工作负载和基础结构组件使用的敏感信息和凭据。

• 云见证 是一种使用 Azure 存储作为故障转移群集仲裁机制的功能。 Azure Local 部署（仅限两个计算机实例）使用云见证作为投票的仲裁机制，确保群集的高可用性 (HA)。 存储帐户和见证配置是在 Azure 本地云部署过程中创建的。 在此架构中，云见证为双节点群集提供多数仲裁，以维持高可用性。

• Azure 更新管理器 是一项统一服务，旨在管理和管理 Azure 本地更新。 可以使用更新管理器来管理部署在 Azure 本地环境中的工作负载，包括可以通过 Azure Policy 启用的 Windows 和 Linux 虚拟机的来宾操作系统更新合规性。 此统一方法通过单个仪表板在 Azure、本地环境和其他云平台上集中管理补丁。 在此体系结构中，更新管理器为基础结构和工作负载提供集中式更新和修补程序管理。

平台支持资源

• Azure Monitor 是一种基于云的服务，用于从云和本地工作负荷收集、分析和处理诊断日志和遥测数据。 可以使用 Azure Monitor 通过监视解决方案最大程度地提高应用程序和服务的可用性和性能。 部署 Azure Local Insights，以简化 Azure Monitor 数据收集规则（DCR）的创建并启用对 Azure Local 实例的监控。 在此体系结构中，Azure Monitor 为 Azure 本地群集和工作负荷提供监视和遥测。

• Azure Policy 是评估 Azure 和本地资源的服务。 Azure Policy 通过与 Azure Arc 的集成使用资源的属性来评估资源，并根据称为 策略定义 的业务规则，确定可用于通过策略设置应用 VM 来宾配置的合规性或能力。 在此体系结构中，Azure Policy 为 Azure 本地计算机的作系统安全配置提供审核和符合性功能。 这些设置通过使用 偏移控件持续应用。

• Defender for Cloud 是基础结构安全管理系统。 它增强了数据中心的安全态势，并为混合工作负荷提供高级威胁防护，无论它们驻留在 Azure 还是其他地方，以及跨本地环境。 在此体系结构中，Defender for Cloud 为 Azure 本地运行的工作负荷提供安全监视和威胁防护。

• Azure 备份 是一种基于云的服务，提供一种安全且经济高效的解决方案，用于备份数据并从 Microsoft 云中恢复数据。 Azure 备份服务器用于备份部署在 Azure 本地上的 VM 并将其存储在备份服务中。 在此体系结构中，Azure 备份保护数据，并为 Azure 本地托管的虚拟机启用恢复。

• Azure Site Recovery 是一种 DR 服务，它通过使业务应用和工作负载能够在发生灾难或中断时进行故障转移，从而提供 BCDR 功能。 Site Recovery 管理在其主站点（本地）和辅助位置（Azure）之间物理服务器和 VM 上运行的工作负荷的复制和故障转移。 在此体系结构中，Site Recovery 为在 Azure 本地实例上运行的负载启用灾难恢复 (DR) 和故障转移。

方案详细信息

以下部分提供了有关此参考体系结构的方案和潜在用例的详细信息。 这些部分包括可在 Azure 本地部署的业务优势和示例工作负荷资源类型的列表。

将 Azure Arc 与 Azure Local 配合使用

Azure Local 使用 Azure Arc 直接与 Azure 集成，以降低总拥有成本（TCO）和运营开销。 Azure Local 通过 Azure 进行部署和管理，通过部署 Azure Arc 资源网桥 组件，提供 Azure Arc 的内置集成。 此组件部署为 Azure 本地实例云部署过程的一部分。 将 Azure 本地计算机注册到 Azure Arc for servers ，作为启动 Azure 本地实例云部署的先决条件。 在部署期间，强制扩展安装在每台计算机上，例如生命周期管理器、Microsoft Edge 设备管理以及遥测和诊断扩展。 可以在部署后，通过使用 Azure Monitor 和 Log Analytics，并为 Azure Local 启用 Insights 来监控解决方案。 Azure 本地功能更新 每六个月发布一次，以增强客户体验。 使用 更新管理器控制和管理 Azure 本地更新。

可以通过选择 Azure 本地实例自定义位置作为工作负荷部署的目标来部署工作负荷资源，例如 Azure Arc VM、已启用 Azure Arc 的 AKS 和 Azure 虚拟桌面会话主机。 这些组件提供集中式管理、管理和支持。 如果现有 Windows Server Datacenter 核心许可证上具有有效的软件保障，可以通过将 Azure 混合权益应用到 Azure 本地、Windows Server VM 和 AKS 群集来进一步降低成本。 此优化有助于有效地管理这些服务的成本。

Azure 和 Azure Arc 集成扩展了 Azure 本地虚拟化和容器化工作负载的功能，包括以下解决方案：

• 用于在 Azure 本地 VM 上运行的传统应用程序或服务的 Azure 本地 VM。

• Azure 本地 上的 AKS，这些应用程序或服务受益于使用 Kubernetes 作为其业务流程平台。

• 虚拟桌面 用于在 Azure 本地（本地部署）上为虚拟桌面工作负载部署会话主机。 可以使用 Azure 中的控制和管理平面启动主机池创建和配置。

• 适用于容器化 Azure SQL 托管实例的 Azure Arc 启用的数据服务。

• 已启用 Azure Arc 的 Azure 容器应用 运行基于容器的应用程序和微服务。 可以使用适用于 Kubernetes 的容器应用扩展来部署它，以便预配连接的容器应用环境。 在 AKS 群集上启用后，可以运行 Azure Functions 等服务。 若要支持事件驱动的缩放，可以选择安装 Kubernetes Event-Driven 自动缩放（KEDA） 扩展。

• 适用于 Kubernetes 的已启用 Azure Arc 的 Azure 事件网格扩展，用于部署 事件网格中转站和事件网格运算符 组件。 此部署支持事件网格主题和订阅等功能来处理事件。

• 已启用 Azure Arc 的机器学习，其中 AKS 群集部署在 Azure 本地作为计算目标以运行 Azure 机器学习。 可以使用此方法在边缘训练或部署机器学习模型。

Azure Arc 连接的工作负载为 Azure 本地部署提供了增强的一致性和自动化功能，例如通过 Azure 本地 VM 扩展 来自动配置来宾操作系统，或使用 Azure Policy 评估是否符合行业法规或公司标准。 可以通过 Azure 门户或基础设施即代码（IaC）自动化来激活 Azure Policy。

利用 Azure 本地默认安全配置

Azure 本地默认安全配置提供深度防御策略，以简化安全性和合规性成本。 零售、制造和远程办公室方案的 IT 服务的部署和管理提出了独特的安全性和合规性挑战。 在 IT 支持有限或缺乏或专用数据中心的环境中，保护工作负载免受内部和外部威胁的影响至关重要。 Azure Local 具有默认的安全强化和与 Azure 服务的深度集成，可帮助解决这些难题。

Azure 本地认证的硬件可确保内置的安全启动、统一可扩展固件接口（UEFI）和受信任的平台模块（TPM）支持。 将这些技术与 基于虚拟化的安全性（VBS） 结合使用，以帮助保护安全敏感型工作负荷。 可以使用 BitLocker 驱动器加密来加密启动磁盘卷和存储空间直通卷。 服务器消息块（SMB）加密提供群集（存储网络上）物理计算机之间的流量的自动加密，以及群集物理计算机和其他系统之间的 SMB 流量签名。 SMB 加密还有助于防止中继攻击，并有助于遵守法规标准。

可以在 Defender for Cloud 中载入 Azure 本地 VM，以激活基于云的行为分析、威胁检测和修正、警报和报告。 在 Azure Arc 中管理 Azure 本地 VM，以便可以使用 Azure Policy 评估其符合行业法规和公司标准。

潜在的用例

Azure 本地的典型用例包括在本地或边缘位置运行 HA 工作负荷。 Azure Local 提供了一个平台来满足以下功能等要求：

• 提供本地部署的云连接解决方案，以解决数据主权、法规和合规性或延迟要求。

• 部署和管理在单个或多个边缘位置部署的 HA 虚拟化或基于容器的工作负荷。 此功能使业务关键型应用程序和服务能够以可复原、经济高效且可缩放的方式运行。

• 通过部署由 Microsoft 及其硬件 OEM 合作伙伴认证的解决方案来减少 TCO。 此解决方案使用新式基于云的部署过程，并提供 Azure 一致的集中式管理和监视体验。

• 使用 Azure 和 Azure Arc 提供集中式预配功能。此功能支持在多个位置一致且安全地部署工作负荷。 Azure 门户、Azure CLI 或 IaC 模板（ARM 模板、Bicep 和 Terraform）等工具可提高自动化和可重复性。 此方法为容器化工作负荷启用 Azure Kubernetes 服务（AKS）群集的快速部署和管理，并为传统的虚拟化工作负荷启用本地 Azure VM 的快速部署和管理。

• 遵循严格的安全性、合规性和审核要求。 Azure 本地部署时，默认配置了强化的安全态势，称为“默认安全”。 Azure Local 包含经过认证的硬件、安全启动、TPM、VBS、Credential Guard 和强制实施的应用程序控制策略。 Azure Local 能够与新式基于云的安全和威胁管理服务（如 Microsoft Defender for Cloud 和 Microsoft Sentinel）集成。 此集成提供扩展检测和响应（XDR）和安全信息事件管理（SIEM）功能。

群集设计选项

了解工作负荷性能和可靠性要求。 若要获得复原能力，请了解平台和工作负载在硬件或节点故障期间继续运行的预期。 此外，定义恢复策略的恢复时间目标（RTO）和恢复点目标（RPO）。 考虑 Azure 本地实例上部署的所有工作负荷的计算、内存和存储要求。 工作负荷的几个特征会影响决策过程：

• 中央处理单元（CPU）体系结构功能，包括硬件安全技术功能、CPU 数量、千兆赫（GHz）频率（速度）以及每个 CPU 套接字的核心数。

• 工作负载的图形处理单元（GPU）要求，例如 AI 或机器学习、推理或图形呈现。

• 每台计算机的内存，或运行工作负荷所需的物理内存数量。

• 实例中规模为 1 到 16 台计算机的物理计算机数。 使用 存储无交换机网络体系结构时，物理计算机的最大数目为 4。

  • 若要保持计算复原能力，需要在实例中至少保留 N+1 物理计算机容量。 此策略允许节点耗尽，以便从突然中断（如停电或硬件故障）进行更新或恢复。

  • 对于业务关键型或任务关键型工作负荷，请考虑保留 N+2 物理机，以提高复原能力。 例如，如果实例中的两台物理计算机处于脱机状态，则工作负荷可以保持联机状态。 此方法为在计划更新过程中运行工作负荷的计算机在计划内更新过程中脱机并导致两台实例物理计算机同时脱机的情况提供复原能力。

• 存储复原能力、容量和性能要求：

  • 冗余： 我们建议部署三台或更多物理计算机，以实现基础结构和用户数据卷的三向镜像，从而提供三份数据副本。 三向镜像提高了存储的性能和可靠性。

  • 容量： 在考虑容错或副本后所需的可用存储总量。 使用三向镜像时，此数字大约是容量层磁盘的原始存储空间的 33%。

  • 性能： 平台的每秒输入/输出操作数（IOPS），用于确定工作负载的存储吞吐量能力（通过与应用程序的块大小相乘来实现）。

若要设计和规划 Azure 本地部署，建议使用 Azure 本地大小调整工具 并创建用于调整 Azure 本地实例大小 的新项目 。 使用容量规划工具需要你掌握工作负荷要求。 在您的实例上运行的工作负载 VM 的数量和大小时，务必考虑到 VM 的 vCPU 数量、内存要求和必要存储容量等因素。

大小调整工具 首选项 部分将指导你完成与系统类型相关的问题，包括顶级解决方案、集成系统或已验证的节点和 CPU 系列选项。 它还有助于为实例选择复原要求。 若要设置复原级别，请遵循以下建议：

• 在实例中，保留至少相当于 N+1 个物理机器容量的空间，或者保留一个节点。 此方法可确保通过一次清空和重启每个节点来应用解决方案更新，而不会造成工作负荷停机。

• 为整个实例预留 N+2 台物理机的容量，以实现更高的复原能力。 此选项使系统能够在更新或其他同时影响两台计算机的意外事件期间承受计算机故障。 它还可确保实例中有足够的容量让工作负荷在剩余的联机计算机上运行。

此方案需要对用户卷使用三向镜像，这是具有三台或更多物理计算机的实例的默认值。

Azure 本地大小调整工具的输出是建议的硬件解决方案 SKU 列表，可以根据 Sizer 项目中的输入值提供所需的工作负荷容量和平台复原要求。 有关可用的 OEM 硬件合作伙伴解决方案的详细信息，请参阅 Azure 本地解决方案目录。 若要帮助正确调整解决方案 SKU 的大小以满足你的要求，请联系首选的硬件解决方案提供商或系统集成（SI）合作伙伴。

物理磁盘驱动器

存储空间直通 支持多种物理磁盘驱动器类型，这些磁盘驱动器在性能和容量上有所不同。 设计 Azure 本地实例时，请与所选的硬件 OEM 合作伙伴协作，确定最适合的物理磁盘驱动器类型，以满足工作负荷的容量和性能要求。 示例包括旋转硬盘驱动器（HDD）或固态硬盘（SSD）和非易失性内存快速（NVMe）驱动器。 这些驱动器通常称为闪存驱动器或永久性内存（PMem）存储，称为存储类内存（SCM）。

平台的可靠性取决于关键平台依赖项（如物理磁盘类型）的性能。 请务必根据要求选择正确的磁盘类型。 对于具有高性能或低延迟要求的工作负荷，请使用全闪存存储解决方案，例如 NVMe 驱动器或 SSD。 这些工作负载包括但不限于高度事务性数据库技术、生产 AKS 群集或任何任务关键型或业务关键型工作负荷，这些工作负荷具有低延迟或高吞吐量存储要求。 使用全闪存部署最大程度地提高存储性能。 All-NVMe 驱动器或全 SSD 配置（尤其是在小规模），可提高存储效率和最大化性能，因为没有驱动器用作缓存层。 有关详细信息，请参阅 基于全闪存的存储。

物理磁盘驱动器类型会影响群集存储的性能。 驱动器的类型因每种驱动器类型和所选缓存机制的性能特征而异。 物理磁盘驱动器类型是任何存储空间直通设计和配置的组成部分。 根据 Azure 本地工作负荷要求和预算限制，可以选择 最大化性能、 最大化容量或实现 平衡性能和容量的混合驱动器类型配置。

对于需要大容量永久性存储的常规用途工作负荷， 混合存储配置 可以提供最可用存储，例如将 NVMe 驱动器或 SSD 用于缓存层，将 HDD 用于容量。 缺点是，硬盘的性能和吞吐能力相比闪存驱动器较低。 如果工作负荷超出 缓存工作集，这些限制可能会影响存储性能。 此外，HDD 在与 NVMe 驱动器和 SSD 相比，故障值之间的平均时间较低。

存储空间直通提供支持读写作的 内置持久服务器端缓存 。 此缓存可最大程度地提高存储性能。 确定缓存的大小并进行配置，以适应应用程序和工作负荷的工作集。 存储空间直连虚拟磁盘或卷与群集共享卷（CSV）内存读取缓存结合使用，以提高Hyper-V的性能。 这种组合对于对工作负荷虚拟硬盘（VHD）或虚拟硬盘 v2（VHDX）文件的无缓冲区输入访问特别有效。

网络设计

网络设计是网络物理基础结构和逻辑配置中组件的总体排列方式。 可以将相同的物理网络接口卡 （NIC） 端口用于管理、计算和存储网络意向的所有组合。 对所有与意向相关的目的使用相同的 NIC 端口称为 完全聚合的网络配置。

支持完全融合的网络配置，但为了获得最佳的性能和可靠性，存储用途应使用专用的网络适配器端口。 因此，此基线架构提供了示例指南，说明如何使用存储交换网络架构部署多节点 Azure 本地实例，其中包括两个融合用于管理和计算目的的网络适配器端口，以及两个专用于存储目的的网络适配器端口。 有关详细信息，请参阅 Azure 本地云部署 网络注意事项。

此体系结构需要两台或更多台物理计算机，最多可以缩放 16 台计算机。 每台计算机都需要四个连接到两个机架顶部（ToR）交换机的网络适配器端口。 这两个 ToR 交换机应通过多机箱链路聚合组（MLAG）链接进行互连。 用于存储意向流量的两个网络适配器端口必须支持 远程直接内存访问（RDMA）。 这些端口需要每秒 10 千兆位（Gbps）的最低链路速度，但我们建议速度为 25 Gbps 或更高版本。 用于管理和计算用途的两个网络适配器端口通过 Switch Embedded Teaming（SET）技术进行聚合。 SET 技术提供链接冗余和负载均衡功能。 这些端口要求最小链路速度为 1 Gbps，但我们建议速度为 10 Gbps 或更高版本。

物理网络拓扑

以下物理网络拓扑显示了 Azure 本地计算机与网络组件之间的物理网络连接。

设计使用此基线体系结构的多节点存储切换的 Azure 本地部署时，需要以下组件。

• 双 ToR 开关：

  • 为保证网络复原能力，并在不产生停机的情况下能够为交换机提供服务或应用固件更新，需要使用双 ToR 网络交换机。 此策略可防止单一故障点（SPoF）。

  • 双 ToR 交换机用于存储或东西部流量。 这些交换机使用两个专用以太网端口，这些端口具有特定的存储虚拟局域网（VLAN）和优先级流控制（PFC）流量类，这些端口定义为提供无损失 RDMA 通信。

  • 这些交换机通过以太网电缆连接到物理计算机。

• 两台或多台物理计算机，最多 16 台物理计算机：

  • 每台计算机都是运行 Azure Stack HCI作系统的物理服务器。

  • 每台计算机总共需要四个网络适配器端口：两个支持 RDMA 的存储端口，两个网络适配器端口用于管理和计算流量。

  • 存储使用两个支持 RDMA 的网络适配器端口，这些端口连接到两个 ToR 交换机中的每个路径。 此方法为 SMB 直接存储流量提供链接路径冗余和专用优先带宽。

  • 管理和计算使用两个网络适配器端口，为两个 ToR 交换机中的每个端口提供一个路径，以便实现链接路径冗余。

• 外部连接：

  • 双 ToR 交换机连接到外部网络，例如内部企业局域网（LAN），以便使用边缘边界网络设备提供对所需出站 URL 的访问。 此设备可以是防火墙或路由器。 这些交换机路由进出 Azure 本地实例或南北流量的流量。

  • 外部南北流量连接支持群集管理意向和计算意向。 此网络配置通过使用两个交换机端口和两个网络适配器端口来实现，每个计算机通过 SET 和 Hyper-V 中的虚拟交换机聚合，以确保复原能力。 这些组件为使用 Azure 门户、Azure CLI 或 IaC 模板在 Resource Manager 中创建的逻辑网络中部署的 Azure 本地 VM 和其他工作负荷资源提供外部连接。

逻辑网络拓扑

逻辑网络拓扑概述设备之间的网络数据如何流动，而不考虑其物理连接。

以下示例演示了 Azure Local 的此多节点存储切换基线体系结构的逻辑设置摘要。

• 双 ToR 开关：

  • 在部署群集之前，需要为两个 ToR 网络交换机配置所需的 VLAN ID、最大传输单元设置，以及管理、计算和存储端口的数据中心桥接配置。 有关详细信息，请参阅 Azure 本地物理网络要求，或请求交换机硬件供应商或 SI 合作伙伴寻求帮助。

• 网络 ATC：

  • Azure Local 使用 网络 ATC 方法 应用网络自动化和基于意向的网络配置。

  • Azure Local 使用 网络 ATC 方法 应用网络自动化和基于意向的网络配置。

  • 网络 ATC 旨在通过使用网络流量 意图来确保最佳的网络配置和流量流动。 网络 ATC 定义用于不同网络流量意向（或类型）的物理网络适配器端口，例如群集 管理、工作负荷 计算和群集 存储 意向。

  • 基于意向的策略通过基于 Azure 本地云部署过程的一部分指定的参数输入自动执行计算机网络配置来简化网络配置要求。

• 外部通信：

  • 当物理计算机或工作负荷需要通过访问公司 LAN、Internet 或其他服务以外部方式通信时，它们 通过双 ToR 交换机进行路由。

  • 当两个 ToR 交换机充当第 3 层设备时，它们将处理路由，并提供群集以外的边缘边界设备（例如防火墙或路由器）的连接。

  • 管理网络意向使用聚合的 SET 团队虚拟接口，使群集管理 IP 地址和控制平面资源能够外部通信。

  • 对于计算网络意向，可以在 Azure 中创建一个或多个逻辑网络，其中包含环境的特定 VLAN ID。 工作负荷资源（如 VM）使用这些 ID 授予对物理网络的访问权限。 逻辑网络使用通过 SET 团队（Switch Embedded Teaming）聚合的两个物理网络适配器端口，实现计算和管理目标。

• 存储流量：

  • 物理计算机使用连接到 ToR 交换机的两个专用网络适配器端口相互通信，为存储流量提供高带宽和复原能力。

  • SMB1 和 SMB2 存储端口连接到两个独立的不可路由（或第 2 层）网络。 每个网络都配置了一个特定的 VLAN ID，该 ID 必须与 ToR 交换机的交换机端口配置匹配，默认存储 VLAN ID：711 和 712。

  • Azure Stack HCI操作系统中的两个存储用途网络适配器端口未配置默认网关。

  • 每个群集节点都可以访问群集的存储空间直通功能，例如在存储池、虚拟磁盘和卷中使用的远程物理驱动器。 通过 SMB-Direct RDMA 协议通过每台计算机中提供的两个专用存储网络适配器端口来访问这些功能。 SMB 多通道用于复原。

  • 此配置为存储相关操作提供了足够的数据传输速度，例如为镜像卷维护一致的数据副本。

网络交换机要求

以太网交换机必须满足 Azure Local 所需的不同规范，并由电气和电子工程师标准协会（IEEE SA）设置。 例如，对于多节点存储切换部署，存储网络用于 通过 RoCE v2 或 iWARP 进行 RDMA。 此过程要求 IEEE 802.1Qbb PFC 确保 存储流量类的无丢失通信。 ToR 交换机必须支持 IEEE 802.1Q for VLAN，以及链路层发现协议的 IEEE 802.1AB。

如果计划对 Azure 本地部署使用现有网络交换机，请查看 网络交换机和配置必须提供的强制 IEEE 标准和规范 列表。 购买新的网络交换机时，请查看 支持 Azure 本地网络要求的硬件供应商认证的交换机模型列表。

IP 地址要求

在多节点存储切换部署中，每个物理计算机增加所需的 IP 地址数将增加，单个群集中最多有 16 台物理计算机。 例如，若要部署 Azure Local 的双节点存储切换配置，群集基础结构至少需要分配 11 x 个 IP 地址。 如果使用微分段或软件定义的网络，则需要更多 IP 地址。 有关详细信息，请参阅 查看 Azure 本地的双节点存储参考模式 IP 地址要求。

在设计和规划 Azure 本地 IP 地址需求时，不仅要满足 Azure 本地实例和基础设施组件的 IP 地址需求，还需考虑为您的工作负载预留额外的 IP 地址或网络范围。 如果计划在本地部署 AKS，请参阅 azure Arc 网络要求启用的 AKS。

出站网络连接

在部署解决方案之前，请务必了解 Azure 本地的出站网络连接要求，并将这些要求纳入设计和实施计划。 若要使 Azure Local 能够与 Azure 和 Azure Arc 通信，以便管理和控制平面作，则需要出站网络连接。 例如，出站连接是预配已启用 Azure Arc 的资源（例如 Azure 本地 VM 或 AKS 群集）以及使用 Azure 管理服务（如更新管理器和 Azure Monitor）所必需的。

将 Azure 本地集成到现有的本地数据中心网络时，提前规划和尽职尽责地实现与所需公共终结点的网络通信至关重要。 如果在代理或防火墙设备上配置了严格的出口规则，则此要求尤其重要。 此外，如果网络安全控制包括安全套接字层（SSL）检查技术，请注意 Azure 本地网络通信不支持 SSL 检查。

出站网络连接为何重要

您的 Azure 本地实例需要出站网络连接。 此要求包括物理机器、Azure Arc 资源桥设备、AKS 群集和 Azure 本地 VM（如果您使用 Azure Arc 管理 VM 来宾操作系统）。 这些设备具有本地代理或服务，使用出站网络访问进行实时通信，以连接到公共终结点，从而能够连接到在 Azure 中运行的管理和控制平面资源提供程序。 例如，操作员需要进行出站连接，以便使用 Azure 门户、Azure CLI 或 IaC 工具（如 ARM、Bicep 或 Terraform 模板）来预配资源、管理资源或同时执行这两个操作。 Azure 和 Azure Arc 资源网桥可与 Azure 本地实例的 自定义位置 资源结合使用。 通过此组合，可以将资源的 CRUD（创建、读取、更新或删除）操作定位到已启用 Azure Arc 的工作负载资源的特定 Azure 本地实例。

若要启用连接，请配置防火墙、代理或 Internet 出口技术或这些组件的组合，以允许出站访问所需的公共终结点。 请考虑以下 Azure 本地出站网络要求的关键注意事项：

• Azure 本地不支持通过从 Azure 本地实例到公共终结点的任何网络路径执行 SSL/TLS 数据包检查。 此外，与所需公共终结点的连接不支持专用链接和 Azure ExpressRoute。 有关详细信息，请参阅 Azure 本地防火墙要求。

• 请考虑使用 Azure Arc 网关 来简化连接要求。 此方法大大减少了需要为防火墙或代理规则添加的用于部署和管理 Azure 本地服务的终结点数量。

• 在使用代理服务器控制和管理 Internet 出口访问来部署 Azure Local 时，请查看 代理要求。

Monitoring

Azure Local 见解基于 Azure Monitor 和 Log Analytics 构建，确保始终提供最新的、可扩展且高度自定义的解决方案。 见解提供对具有基本指标的默认工作簿的访问权限，以及为监视 Azure Local 的主要功能而创建的专用工作簿。 这些组件提供近乎实时的监视解决方案，并允许创建图形、通过聚合和筛选自定义可视化效果以及配置自定义资源运行状况警报规则。

若要增强监视和警报，请在本地启用 Azure Monitor Insights。 借助与 Azure 一致的体验，Insights 可以扩展以监控和管理多个本地实例。 见解使用群集性能计数器和事件日志通道来监视关键的 Azure 本地功能。 通过 Azure Monitor 和 Log Analytics 配置的 DCR 会收集日志。

更新管理

需要定期更新和修补 Azure 本地实例和已部署的工作负荷资源，例如 Azure 本地 VM。 通过定期应用更新，可确保组织保持强大的安全态势。 还可以提高资产的整体可靠性和可支持性。 我们建议，您使用自动和定期手动的评估，以便尽早发现并应用安全修补程序和操作系统更新。

基础结构更新

Azure 本地版会不断更新，以增强客户体验并引入新功能。 功能更新每六个月通过发布列车交付一次，新版本于 4 月 （YY04） 和 10 月 （YY10） 发布。 除了常规功能更新，Azure Local 还接收每月累积更新，其中包括作系统安全性和可靠性改进，以及扩展和代理的更新。

更新管理器是一项 Azure 服务，可用于应用、查看和管理 Azure 本地更新。 此服务提供一种机制，用于查看整个基础结构和边缘位置的所有 Azure 本地实例，这些实例使用 Azure 门户提供集中式管理体验。 有关详细信息，请参阅以下资源：

• Azure 本地版本信息
• Azure 本地生命周期节律
• 查看 Azure 本地 的更新阶段
• 使用更新管理器更新 Azure 本地

请务必定期检查新的驱动程序和固件更新，例如每三到六个月检查一次。 如果将顶级解决方案类别版本用于 Azure 本地硬件， 则解决方案生成器扩展 （SBE） 包更新 与更新管理器集成以提供简化的更新体验。 如果使用已验证的节点或集成系统类别，则可能需要下载并运行 OEM 特定的更新包，其中包含硬件的固件和驱动程序更新。 若要确定如何为硬件提供更新，请联系硬件 OEM 或 SI 合作伙伴。

负载的虚拟机操作系统修补

可以使用用于更新 Azure 本地实例物理计算机的相同机制来注册部署在 Azure 本地 管理器 中的 Azure 本地 VM，以提供统一的修补程序管理体验。 可以使用更新管理器创建 来宾维护配置。 这些配置控制设置，例如 重启设置（如有必要）、计划（日期、时间和重复选项），以及范围的 Azure 本地 VM 的动态（订阅）或静态列表。 这些设置控制在工作负载 VM 的客户操作系统中安装操作系统安全补丁的配置。

Considerations

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

Reliability

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性的设计评审清单。

确定潜在的故障点

每个体系结构都容易受到故障的影响。 可以使用故障模式分析（FMA）来预测故障并准备好缓解措施。 下表描述了此体系结构中潜在故障点的四个示例。

Component	Risk	Likelihood	影响和缓解	Outage
Azure 本地实例中断	电源、网络、硬件或软件故障	Medium	为防止 Azure 本地实例故障导致的长时间的应用程序中断（适用于业务关键或任务关键型用例），应使用 HA 和 DR 原则来构建工作负荷。 例如，可以使用行业标准工作负荷数据复制技术来维护使用多个 Azure 本地 VM 或 AKS 实例部署的持久性状态数据的多个副本，这些副本部署在单独的 Azure 本地实例和单独的物理位置。	潜在中断
Azure 本地单一物理计算机中断	电源、硬件或软件故障	Medium	为防止单个 Azure 本地计算机发生故障而导致的应用程序长时间中断，Azure 本地实例应具有多个物理计算机。 群集设计阶段的工作负荷容量要求决定了物理计算机的数量。 我们建议你拥有三台或更多台物理计算机。 我们还建议使用三向镜像，这是具有三台或更多物理计算机的群集的默认存储复原模式。 为了防止单点故障 (SPoF) 并增强工作负载的弹性，请在多个 AKS 工作节点上运行多个 Azure 本地虚拟机或容器 Pod，以部署工作负载的多个实例。 如果单个计算机发生故障，群集中剩余的联机物理计算机上会重启 Azure 本地 VM 和工作负荷或应用程序服务。	潜在中断
Azure 本地 VM 或 AKS 辅助角色节点（工作负荷）	Misconfiguration	Medium	应用程序用户无法登录或访问应用程序。 在部署期间识别配置错误。 如果在配置更新期间发生这些错误，开发运维团队必须回滚更改。 如有必要，可以重新部署 VM。 重新部署需要不到 10 分钟才能部署，但根据部署类型可能需要更长的时间。	潜在中断
与 Azure 的连接	网络中断	Medium	Azure Local 要求与 Azure 建立网络连接，以便控制平面作可用。 例如，若要预配新的 Azure 本地 VM 或 AKS 群集，请使用更新管理器安装解决方案更新，或使用 Azure Monitor 监视实例的运行状况。 如果与 Azure 的连接不可用，则实例处于降级状态，其中这些功能不可用。 但是，已在 Azure 本地上运行的现有工作负荷将继续运行。 如果在 30 天内未还原到 Azure 的网络连接，则实例将输入“策略外”状态，这会限制功能。 Azure 资源网桥设备无法脱机 45 天，因为这种不活动可能会影响用于身份验证的安全密钥的有效性。	管理操作不可用

有关详细信息，请参阅 有关执行 FMA 的建议。

可靠性目标

本部分介绍一个示例方案。 称为 Contoso Manufacturing 的虚构客户使用此参考体系结构部署 Azure 本地。 他们希望满足其要求，并在本地部署和管理工作负荷。 Contoso Manufacturing 有内部服务级别目标 （SLO） 目标 99.8% 业务和应用程序利益干系人就其服务达成一致。

• 对于通过 Azure Local 上运行的 Azure Local VMs 部署的应用程序，其 SLO 可用性为 99.8%，将导致以下时间段的允许停机或不可用：

  • 每周：20 分 10 秒

  • 每月：1 小时 26 分 56 秒

  • 季度：4 小时 20 分 49 秒

  • 每年：17 小时 23 分 16 秒

• 为了帮助满足 SLO 目标，Contoso Manufacturing 实施最低特权原则（PoLP），将 Azure 本地实例管理员的数量限制为一小组受信任和合格的个人。 此方法有助于防止因无意或意外操作生产资源导致的停机。 此外，监视本地 Active Directory 域服务（AD DS）域控制器的安全事件日志，以检测和报告使用 SIEM 解决方案的 Azure 本地实例管理员组的任何用户帐户组成员身份更改，称为“添加和删除作”。 监视可提高可靠性和提高解决方案的安全性。

  有关详细信息，请参阅 标识和访问管理的建议。

• Contoso Manufacturing 的生产系统 严格的变更控制过程已到位。 此过程要求在生产中实现之前，在具有代表性的测试环境中测试并验证所有更改。 提交到每周更改顾问流程的所有更改都必须包括详细的实施计划（或源代码链接）、风险级别分数、全面回滚计划、发布后测试和验证，以及明确要审查或批准的更改的成功标准。

  有关详细信息，请参阅 有关安全部署做法的建议。

• 每月安全修补程序和季度基线更新 仅在预生产环境验证后才会应用于生产 Azure 本地实例。 更新管理器和群集感知更新功能自动执行使用 VM 实时迁移 过程，以最大程度地减少每月服务操作期间业务关键型工作负荷的停机时间。 Contoso 制造标准操作过程要求在发布日期四周内对所有生产系统应用安全、可靠性或基线生成更新。 如果没有此策略，生产系统始终无法与每月操作系统和安全更新保持最新状态。 过时的系统会对平台可靠性和安全性产生负面影响。

  有关详细信息，请参阅 有关建立安全基线的建议。

• Contoso Manufacturing 实施每日、每周和每月备份 ，以保留过去 6 天的每日备份（星期一到星期六）、最近 3 周（每个星期日）和最近 3 个月的备份，每个 每月第 4 个星期日 被保留为第 1 个月、第 2 个月和第 3 个月的备份，使用记录和可审核的滚动日历计划。 此方法满足 Contoso 制造要求，要求在可用的数据恢复点数量与降低异地或云备份存储服务的成本之间进行充分平衡。

  有关详细信息，请参阅 有关设计 DR 策略的建议。

• 数据备份和恢复过程每六个月针对每个业务系统测试一次。 此策略可确保 BCDR 流程有效，并在发生数据中心灾难或网络事件时保护业务。

  有关详细信息，请参阅 有关设计可靠性测试策略的建议。

• 本文前面所述的操作过程和 过程，以及 Azure 本地的 Well-Architected Framework 服务指南中的建议，使 Contoso Manufacturing 能够满足其 99.8% SLO 目标，并有效地缩放和管理分布在全球多个制造站点的 Azure 本地和工作负荷部署。

  有关详细信息，请参阅 有关定义可靠性目标的建议。

Redundancy

请考虑在单个 Azure 本地实例上部署的工作负荷，作为 本地冗余部署。 群集在平台级别提供 HA，但必须在单个机架中部署群集。 对于业务关键型或任务关键型用例，建议在两个或多个独立的 Azure 本地实例之间部署工作负荷或服务的多个实例，理想情况下在单独的物理位置。

对提供主动/被动复制、同步复制或异步复制（例如 SQL Server Always On）的工作负荷使用行业标准 HA 模式。 还可以使用外部网络负载均衡（NLB）技术，在部署在单独的物理位置的 Azure 本地实例上运行的多个工作负荷实例上路由用户请求。 请考虑使用合作伙伴外部 NLB 设备。 或者，可以评估支持混合和本地服务的流量路由的 负载均衡选项 ，例如使用 ExpressRoute 或 VPN 隧道连接到本地服务的 Azure 应用程序网关实例。

有关详细信息，请参阅 针对冗余进行设计的建议。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全的设计评审清单。

• Azure 本地平台的安全基础：Azure 本地 是一种安全默认产品，它使用 TPM、UEFI 和安全启动验证的硬件组件，为 Azure 本地平台和工作负荷安全性构建安全基础。 使用默认安全设置进行部署时，Azure 本地已启用应用程序控制、凭据防护和 BitLocker。 若要使用 PoLP 简化委派权限，请使用 Azure 本地内置基于角色的访问控制（RBAC）角色， 例如平台管理员的 Azure 本地管理员，以及工作负荷操作员的 Azure 本地 VM 参与者或 Azure 本地 VM 读取者。

• 默认安全设置： Azure Local 在部署期间为 Azure 本地实例应用 默认安全设置 ， 并使偏移控制 能够使物理计算机保持已知良好状态。 可以使用安全默认设置来管理群集上的群集安全性、偏移控制和受保护的核心服务器设置。

• 安全事件日志：Azure 本地 syslog 转发 与安全监视解决方案集成，方法是检索相关的安全事件日志，以聚合和存储事件，以便在自己的 SIEM 平台中保留。

• 防范威胁和漏洞：Defender for Cloud 可保护 Azure 本地实例免受各种威胁和漏洞的影响。 此服务有助于改善 Azure 本地环境的安全状况，并可以防范现有和不断演变的威胁。

• 威胁检测和修正：Microsoft高级威胁分析 检测和修正威胁，例如面向 AD DS 的威胁，这些威胁向 Azure 本地实例计算机及其 Windows Server VM 工作负荷提供身份验证服务。

• 网络隔离： 根据需要隔离网络。 例如，可以预配使用单独的 VLAN 和网络地址范围的多个逻辑网络。 使用此方法时，请确保管理网络可以访问每个逻辑网络和 VLAN，以便 Azure 本地实例物理计算机可以通过 ToR 交换机或网关与 VLAN 网络通信。 此配置是管理工作负载所必需的，例如允许基础结构管理代理与工作负载来宾操作系统进行通信。

  有关详细信息，请参阅 有关构建分段策略的建议。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

• 许可的云样式计费模型： Azure 本地定价遵循 每月订阅计费模型 ，并在 Azure 本地实例中为每个物理处理器核心提供统一费率。 如果使用其他 Azure 服务，则收取额外的使用费。 如果拥有具有活动软件保障的 Windows Server Datacenter 版本的本地核心许可证，可以选择交换这些许可证以激活 Azure 本地实例和 Windows Server VM 订阅费用。

• Azure 本地虚拟机的自动 VM 客户修补： 此功能有助于减少手动修补的开销和相关维护成本。 此操作不仅有助于使系统更安全，而且还能优化资源分配，并有助于提高整体成本效益。

• 成本监视合并： 若要整合监视成本，请使用 Azure Local Insights 并使用 Azure 本地更新管理器进行修补。 Azure Local Insights 使用 Azure Monitor 提供丰富的指标和警报功能。 Azure Local 的生命周期管理组件与更新管理器集成，通过将各种组件的更新工作流整合为一个统一的体验，来简化保持群集的最新状态的任务。 使用 Azure Monitor 和更新管理器优化资源分配，并有助于总体成本效益。

  有关详细信息，请参阅 有关优化人员时间的建议。

• 初始工作负荷容量和增长： 规划 Azure 本地部署时，请考虑初始工作负荷容量、复原要求和未来的增长注意事项。 请考虑使用两个、三个或四节点的无交换机体系结构可以降低成本，例如，无需采购存储类网络交换机。 购买额外的存储类网络交换机可能是新 Azure 本地实例部署的昂贵组件。 相反，可以将现有交换机用于管理和计算网络，从而简化基础结构。 如果工作负荷容量和复原能力需求不能扩展到四节点配置之外，请考虑对管理和计算网络使用现有交换机，并使用 无存储交换机体系结构 部署 Azure 本地。

  有关详细信息，请参阅 优化组件成本的建议。

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。

• 与 Azure 集成的简化预配和管理体验：Azure 中的基于云的部署提供向导驱动的界面，演示如何创建 Azure 本地实例。 同样，Azure 简化了 管理 Azure 本地实例 和 Azure 本地 VM 的过程。 可以使用 此 ARM 模板自动执行基于门户的 Azure 本地实例部署。 使用模板可大规模部署 Azure Local，特别是在需要 Azure 本地实例运行业务关键型工作负荷的零售商店或制造站点等边缘方案中。

• Azure 虚拟机的自动化功能： Azure Local 提供了各种自动化功能来管理工作负荷，例如 Azure 本地 VM。 这些功能包括使用 Azure CLI、ARM 模板或 Bicep 模板自动部署 Azure 本地 VM。 虚拟机操作系统更新通过 Azure Arc 扩展提供，并通过更新管理器将更新应用于每个 Azure 本地实例。 Azure Local 还支持通过使用 Azure CLI 管理 Azure Local VM，并通过使用 Windows PowerShell 管理 非 Azure Local VM。 可以从其中一台 Azure 本地计算机本地运行 Azure CLI 命令，也可以从管理计算机远程运行。 与 Azure 自动化和 Azure Arc 集成有助于通过 Azure Arc 扩展为 VM 工作负荷 提供广泛的额外自动化方案。

  有关详细信息，请参阅有关使用 IaC的 建议。

• AKS 上的容器的自动化功能： Azure Local 提供了各种自动化功能，用于管理 AKS 上的工作负载，例如容器。 可以使用 Azure CLI 自动部署 AKS 群集。 使用适用于 Kubernetes 的 Azure Arc 扩展更新更新 AKS 工作负荷群集。 还可以使用 Azure CLI 管理 已启用 Azure Arc 的 AKS 。 可以从其中一台 Azure 本地计算机本地运行 Azure CLI 命令，也可以从管理计算机远程运行。 通过 Azure Arc 扩展与 Azure Arc 集成，实现适用于 容器化工作负荷 的各种额外自动化方案。

  有关详细信息，请参阅以下资源：

  • 启用自动化的建议
  • 比较 Azure 本地 VM 的管理功能

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅 性能效率的设计评审清单。

• 工作负荷存储性能： 请考虑使用 DiskSpd 工具测试 Azure 本地实例的工作负荷存储性能功能。 可以使用 VMFleet 工具生成负载并测量存储子系统的性能。 确定是否应使用 VMFleet 来度量存储子系统性能。

  建议在部署生产工作负荷之前，为 Azure 本地实例性能建立基线。 DiskSpd 使用各种命令行参数，使管理员能够测试群集的存储性能。 DiskSpd 的主要功能是发出读取和写入操作以及输出性能指标，例如延迟、吞吐量和 IOP。

  有关详细信息，请参阅 性能测试的建议。

• 工作负荷存储复原能力： 考虑 存储复原能力、使用情况（或容量）效率和性能的优点。 规划 Azure 本地卷包括确定复原能力、使用效率和性能之间的最佳平衡。 你可能会发现很难优化这种平衡，因为最大化其中一个特征通常对一个或多个其他特征产生负面影响。 提高复原能力可降低可用容量。 因此，性能可能会有所不同，具体取决于所选的复原类型。 当复原和性能是优先级，并且使用三台或更多物理计算机时，默认存储配置对基础结构和用户卷采用三向镜像。

  有关详细信息，请参阅 容量规划建议。

• 网络性能优化： 考虑网络性能优化。 在设计过程中，在确定最佳网络硬件配置时，请务必包括预计的网络流量带宽分配。

  若要优化 Azure 本地中的计算性能，可以使用 GPU 加速。 GPU 加速适用于 涉及数据见解或推理的高性能 AI 或机器学习工作负载。 由于数据重力或安全要求等注意事项，这些工作负载需要在边缘位置部署。 在混合部署或本地部署中，请务必考虑工作负荷性能要求，包括 GPU。 此方法有助于在设计和采购 Azure 本地实例时选择正确的服务。

  有关详细信息，请参阅 有关选择正确服务的建议。

部署此方案

以下部分提供了用于部署 Azure 本地的高级任务或典型工作流的示例列表，包括先决条件任务和注意事项。 此工作流列表仅用于示例指南。 这不是所有必需操作的详尽列表，这些操作可能会因组织、地理或项目特定的要求而异。

在此方案中，项目或用例要求在本地或边缘位置部署混合云解决方案，以便提供用于数据处理的本地计算。 还需要维护 Azure 一致的管理和计费体验。 本文 的“潜在用例 ”部分介绍了更多详细信息。 其余步骤假定 Azure Local 是项目的所选基础结构平台解决方案。

1. 收集相关利益干系人提供的工作负载和用例要求。 此策略使项目能够确认 Azure Local 的特性和功能满足工作负荷规模、性能和功能要求。 此评审过程应包括了解工作负荷规模或大小，以及所需的功能，例如 Azure 本地 VM、AKS、虚拟桌面或已启用 Azure Arc 的数据服务或已启用 Azure Arc 的机器学习服务。 工作负荷 RTO 和 RPO（可靠性）值和其他非功能要求（性能和负载可伸缩性）应记录为此步骤的一部分。

2. 查看建议的硬件合作伙伴解决方案的 Azure 本地大小器输出。 此输出包括建议的物理服务器硬件制造和型号、物理计算机数量以及每个物理节点要部署和运行工作负荷的 CPU、内存和存储配置的规范的详细信息。

3. 使用 Azure 本地大小调整工具 创建一个新项目，用于为工作负荷类型和缩放建模。 此项目包括 VM 的大小和数量及其存储要求。 这些详细信息连同系统类型、首选的CPU系列以及以满足您的高可用性和存储容错需求的韧性要求的选项一起录入，如 集群设计选项 部分中所述。

4. 查看建议的硬件合作伙伴解决方案的 Azure 本地大小器输出。 此解决方案包括建议的物理服务器硬件（制造和型号）、物理计算机数量以及每个物理节点要部署和运行工作负荷的 CPU、内存和存储配置规范的详细信息。

5. 请联系硬件 OEM 或 SI 合作伙伴，进一步限定建议的硬件版本与工作负载要求的适用性。 如果可用，请使用特定于 OEM 的大小调整工具来确定针对预期工作负荷的特定于 OEM 的硬件大小调整要求。 此步骤通常包括与硬件 OEM 或 SI 合作伙伴讨论解决方案的商业方面。 这些方面包括报价、硬件可用性、潜在顾客时间和合作伙伴提供的任何专业或增值服务，以帮助加速项目或业务成果。

6. 部署两个 ToR 交换机进行网络集成。 对于 HA 解决方案，Azure 本地实例需要部署两个 ToR 交换机。 每个物理计算机都需要四个 NIC，其中两个 NIC 必须支持 RDMA，后者提供两个从每台计算机到两个 ToR 交换机的链接。 两个 NIC（一个连接到每个交换机）聚合，用于计算和管理网络的出站南北连接。 另外两个支持 RDMA 的 NIC 专用于存储东西方流量。 如果计划使用现有的网络交换机，请确保交换机的制造和模型位于 Azure 本地支持的 批准的网络交换机列表上。

7. 与硬件 OEM 或 SI 合作伙伴合作，安排硬件交付。 然后，需要 SI 合作伙伴或员工将硬件集成到本地数据中心或边缘位置，例如机架和堆叠物理计算机的硬件、物理网络和电源单元布线。

8. 执行 Azure 本地实例部署。 根据所选的解决方案版本（顶级解决方案、集成系统或已验证的节点），硬件合作伙伴、SI 合作伙伴或员工都可以 部署 Azure 本地软件。 此步骤首先将物理计算机 Azure Stack HCI作系统加入已启用 Azure Arc 的服务器，然后启动 Azure 本地云部署过程。 客户和合作伙伴可以直接在 Azure 门户中 通过Microsoft提出支持请求，方法是选择 “支持 + 故障排除 ”图标，或者联系其硬件 OEM 或 SI 合作伙伴，具体取决于请求的性质和硬件解决方案类别。

   Tip

   Azure Stack HCI 操作系统版本 23H2 系统参考实现演示如何使用 ARM 模板和参数文件部署 Azure Local 的交换式多节点部署。 或者，Bicep 示例 演示如何使用 Bicep 模板部署 Azure 本地实例，包括其先决条件资源。

9. 使用 Azure 门户、CLI 或 ARM + Azure Arc 模板在 Azure 本地部署高度可用的工作负荷，以便实现自动化。 部署工作负载资源（例如 Azure 本地 VM、AKS、虚拟桌面会话主机或其他已启用 Azure Arc 的服务）时，请使用新 Azure 本地实例的自定义位置资源作为目标区域，这些服务可以通过 Azure 本地上的 AKS 扩展和容器化启用。

10. 安装每月更新以提高平台的安全性和可靠性。 若要使 Azure 本地实例保持最新状态，请务必安装Microsoft软件更新和硬件 OEM 驱动程序和固件更新。 这些更新可提高平台的安全性和可靠性。 更新管理器 应用更新，并提供集中且可缩放的解决方案，用于跨单个群集或多个群集安装更新。 请与硬件 OEM 合作伙伴联系，确定安装硬件驱动程序和固件更新的过程，因为此过程可能因所选硬件解决方案类别类型（顶级解决方案、集成系统或已验证的节点）而异。 有关详细信息，请参阅 基础结构更新。

相关资源

• 混合体系结构设计
• Azure 混合选项
• 使用 Azure Arc 优化对本地和多云环境中的 SQL Server 实例的管理

后续步骤

Microsoft Learn 产品文档：

• Azure 本地版本信息
• 在 Azure 本地 上 AKS
• Azure 本地虚拟桌面
• 什么是 Azure 本地监视？
• 使用 Azure 本地上的 Site Recovery 保护 VM 工作负荷
• Azure Monitor 概述
• 更改跟踪和库存概述
• 更新管理器概述
• 什么是已启用 Azure Arc 的数据服务？
• 什么是已启用 Azure Arc 的服务器？
• 什么是备份服务？
• Azure 自动化概述
• Azure 自动化状态配置
• 机器学习 中的 Kubernetes 计算目标简介

Azure 产品文档：

• Azure 本地
• 蔚蓝弧
• 密钥保管库
• Azure Blob 存储
• Azure Monitor
• Azure Policy
• Azure 容器注册表
• 云端保护者 (Defender for Cloud)
• Site Recovery
• Backup

Microsoft学习培训：

• 配置 Azure Monitor
• 设计用于备份和 DR 的解决方案
• Azure Arc 简介
• AKS 的 简介
• 使 VM 保持更新
• 使用备份 保护 VM

其他资源：

• 在任意位置使用机器学习 缩放模型部署 - 技术社区博客
• 使用已启用 AKS 和已启用 Azure Arc 的机器学习实现机器学习 - 技术社区博客
• 使用 Azure Arc 启用的机器学习，在 AKS Hybrid 和 Azure Local 上进行机器学习 - 技术社区博客