Azure 本地基线参考体系结构

此基线参考体系结构提供与工作负荷无关的指南和建议，用于配置 Azure 本地版本 23H2、版本 2311 及更高版本的基础结构，以确保一个可靠的平台，可以部署和管理高度可用的虚拟化和容器化工作负载。 此体系结构介绍提供本地计算、存储和网络功能的物理节点的资源组件和群集设计选择。 它还介绍如何使用 Azure 服务来简化和简化 Azure 本地的日常管理。

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

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

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

文章布局

建筑

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

潜在的用例

Azure Local 的典型用例包括能够在本地或边缘位置运行高可用性（HA）工作负荷，从而提供解决工作负荷要求的解决方案。 您可以：

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

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

• 通过使用通过Microsoft、基于云的部署、集中管理和监视和警报认证的解决方案来降低总拥有成本（TCO）。

• 使用 Azure 和 Azure Arc 在多个位置一致且安全地部署工作负荷，从而提供集中预配功能。 Azure 门户、Azure CLI 或基础结构即代码（IaC）模板等工具使用 Kubernetes 进行容器化或传统工作负荷虚拟化，以推动自动化和可重复性。

• 遵循严格的安全性、合规性和审核要求。 Azure 本地部署时，默认配置了强化的安全状况，或默认 安全。 Azure 本地包含经过认证的硬件、安全启动、受信任的平台模块（TPM）、基于虚拟化的安全性（VBS）、Credential Guard 和强制实施的 Windows Defender 应用程序控制策略。 它还与新式基于云的安全和威胁管理服务（如 Microsoft Defender for Cloud 和 Microsoft Sentinel）集成。

方案详细信息

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

将 Azure Arc 与 Azure Local 配合使用

Azure Local 使用 Azure Arc 直接与 Azure 集成，以降低 TCO 和操作开销。 Azure Local 通过 Azure 进行部署和管理，通过部署 Azure Arc 资源网桥 组件，提供 Azure Arc 的内置集成。 此组件是在 HCI 群集部署过程中安装的。 Azure 本地群集节点注册到 Azure Arc 的服务器 作为启动群集基于云的部署的先决条件。 在部署期间，强制扩展安装在每个群集节点上，例如生命周期管理器、Microsoft Edge 设备管理以及遥测和诊断。 可以通过为 Azure 本地启用 Insights，使用 Azure Monitor 和 Log Analytics 在部署后监视 HCI 群集。 Azure 本地 功能更新会定期发布，以增强客户体验。 通过 azure 更新管理器控制和管理更新。

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

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

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

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

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

• 已启用 Azure Arc 的数据服务 用于容器化 Azure SQL 托管实例或使用 Azure 本地托管的已启用 Azure Arc 的 AKS 的 Azure Database for PostgreSQL 服务器。

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

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

Azure Arc 连接的工作负载为 Azure 本地部署提供了增强的 Azure 一致性和自动化，例如，使用 Azure Arc VM 扩展自动执行来宾 OS 配置， 或通过 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 本地实例。 为了增强平台功能，Azure Local 与 Azure Arc 和其他提供支持资源的 Azure 服务集成。 Azure Local 提供了一个可复原的平台，用于部署、管理和操作用户应用程序或业务系统。 以下各节介绍了平台资源和服务。

平台资源

体系结构需要以下必需的资源和组件：

• Azure 本地 是一种超融合基础结构（HCI）解决方案，它通过使用物理服务器硬件和网络基础结构在本地或边缘位置部署。 Azure Local 提供了一个平台，用于部署和管理虚拟化工作负载，例如 VM、Kubernetes 群集和其他由 Azure Arc 启用的服务。Azure 本地实例可以使用原始设备制造商（OEM）合作伙伴提供的已验证、集成或高级硬件类别，从单节点部署扩展到最多 16 个节点。

• Azure Arc 是一种基于云的服务，它基于 Azure 资源管理器将管理模型扩展到 Azure 本地和其他非 Azure 位置。 Azure Arc 使用 Azure 作为控制和管理平面来管理各种资源，例如 VM、Kubernetes 群集以及容器化数据和机器学习服务。

• Azure Key Vault 是一种云服务，可用于安全地存储和访问机密。 机密是想要严格限制访问的任何内容，例如 API 密钥、密码、证书、加密密钥、本地管理员凭据和 BitLocker 恢复密钥。

• 云见证 是 Azure 存储的一项功能，充当故障转移群集仲裁。 Azure 本地群集节点使用此仲裁进行投票，这可确保群集的高可用性。 存储帐户和见证配置是在 Azure 本地云部署过程中创建的。

• 更新管理器 是一项统一的服务，旨在管理和管理 Azure 本地更新。 可以使用更新管理器来管理 Azure 本地部署的工作负载，包括 Windows 和 Linux VM 的来宾 OS 更新符合性。 这种统一的方法通过单个仪表板简化了 Azure、本地环境和其他云平台的修补程序管理。

平台支持资源

该体系结构包括以下可选支持服务，以增强平台的功能：

• Monitor 是一项基于云的服务，用于从云和本地工作负荷收集、分析和处理诊断日志和遥测数据。 可以使用 Monitor 通过全面的监视解决方案最大程度地提高应用程序和服务的可用性和性能。 部署用于 Azure 本地的见解，以简化监视数据收集规则（DCR）的创建，并快速启用对 Azure 本地实例的监视。

• Azure Policy 是评估 Azure 和本地资源的服务。 Azure Policy 通过使用这些资源的属性将这些资源的属性用于业务规则（称为 策略定义）来评估资源，以确定可以使用策略设置应用 VM 来宾配置的符合性或功能。

• Defender for Cloud 是一个全面的基础结构安全管理系统。 它增强了数据中心的安全态势，并为混合工作负荷提供高级威胁防护，无论它们位于 Azure 还是其他地方，以及跨本地环境。

• Azure 备份 是一种基于云的服务，它提供一种简单、安全且经济高效的解决方案，用于备份数据并从 Microsoft 云中恢复数据。 Azure 备份服务器用于备份部署在 Azure 本地上的 VM 并将其存储在备份服务中。

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

群集设计选项

设计 Azure 本地实例时，请务必了解工作负荷性能和复原要求。 这些要求包括恢复时间目标（RTO）和恢复点目标（RPO）时间、计算（CPU）、内存和存储要求，这些工作负荷部署在 Azure 本地实例上。 工作负荷的几个特征会影响决策过程，包括：

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

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

• 每个节点的内存，或运行工作负荷所需的物理内存数量。

• 群集中规模为 1 到 16 个节点的物理节点数。 使用 存储无交换机网络体系结构时，最大节点数为 3。

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

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

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

  • 复原：建议部署三个或更多个节点，以便为基础结构和用户卷提供三个数据副本的三向镜像。 三向镜像提高了存储的性能和可靠性。

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

  • 性能：平台的每秒输入/输出操作数（IOPS），当与应用程序的块大小相乘时，确定工作负荷的存储吞吐量功能。

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

大小调整工具 首选项 部分将指导你完成与系统类型（Premier、Integrated System 或 Validated Node）和 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 驱动器配置（尤其是在小规模），提高存储效率和最大化性能，因为没有驱动器用作缓存层。有关详细信息，请参阅 基于全闪存的存储。

对于常规用途工作负荷，混合存储配置（例如用于缓存的 NVMe 驱动器或 SSD）和用于容量的 HDD，可能会提供更多存储空间。 缺点是，如果工作负荷超过 缓存工作集，并且 HDD 与 NVMe 和 SSD 驱动器相比，故障值之间的平均时间较低，则旋转磁盘的性能较低。

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

存储空间直通提供 内置、持久、实时、读取、写入、服务器端缓存，以最大限度地提高存储性能。 缓存的大小和配置以适应 应用程序和工作负载的工作集。 存储空间直通虚拟磁盘（或 卷）与群集共享卷（CSV）内存中读取缓存结合使用，以 提高 Hyper-V 性能，特别是对于对工作负荷虚拟硬盘（VHD）或虚拟硬盘 v2（VHDX）文件的无缓冲输入访问。

网络设计

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

尽管支持完全聚合的网络配置，但性能和可靠性的最佳配置是存储意向使用专用网络适配器端口。 因此，此基线体系结构提供了有关如何使用存储交换机网络体系结构部署多节点 Azure 本地实例的示例指南，以及两个用于管理和计算意向的网络适配器端口，以及存储意向的两个专用网络适配器端口。 有关详细信息，请参阅 Azure 本地云部署 网络注意事项。

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

物理网络拓扑

以下物理网络拓扑显示了节点与网络组件之间的实际物理连接。

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

• 双 ToR 开关：

  • 网络复原需要双重 ToR 网络交换机，并且能够对交换机提供服务或应用固件更新，而不会造成停机。 此策略可防止单一故障点（SPoF）。

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

  • 这些交换机通过以太网电缆连接到节点。

• 两个或更多个物理节点，最多 16 个节点：

  • 每个节点都是运行 Azure Stack HCI OS 的物理服务器。

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

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

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

• 外部连接：

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

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

逻辑网络拓扑

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

Azure Local 的此多节点存储切换基线体系结构的逻辑设置摘要如下：

• 双 ToR 开关：

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

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

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

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

• 外部通信：

  • 当节点或工作负荷需要通过访问公司 LAN、Internet 或其他服务以外部方式进行通信时，它们使用双 ToR 交换机进行路由。 上一 物理网络拓扑 部分概述了此过程。

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

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

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

• 存储流量：

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

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

  • Azure Stack HCI OS 中的两个存储意向网络适配器端口上没有 配置默认网关。

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

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

网络交换机要求

以太网交换机必须满足 Azure Local 所需的不同规范，并由电气和电子工程师标准协会（IEEE SA）设置。 例如，对于多节点存储交换机部署，存储网络用于通过 RoCE v2 或 iWARPRDMA。 此过程要求 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 地址要求时，请记住考虑到工作负荷所需的其他 IP 地址或网络范围，这些 IP 地址或网络范围超出了 Azure 本地实例和基础结构组件所需的范围。 如果计划在本地部署 AKS，请参阅 azure Arc 网络要求启用的 AKS。

监测

若要增强监视和警报，请启用 azure 本地上的 Monitor Insights。 见解可以使用 Azure 一致的体验来缩放以监视和管理多个本地群集。 见解使用群集性能计数器和事件日志通道来监视关键的 Azure 本地功能。 日志由通过 Monitor 和 Log Analytics 配置的 DCR 收集。

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

更新管理

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

基础结构更新

Azure 本地版会持续更新，以提高客户体验并添加新特性和功能。 此过程通过发布列车进行管理，这些列车按季度交付新的基线版本。 基线生成应用于 Azure 本地实例，使其保持最新状态。 除了常规基线生成更新之外，Azure Local 还使用每月 OS 安全性和可靠性更新进行更新。

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

• 关于 Azure 本地版本信息

• Azure 本地生命周期节奏

• 查看 Azure 本地 的更新阶段

• 使用 Azure 更新管理器更新 Azure 本地

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

工作负荷来宾 OS 修补

可以使用 Azure 更新管理器（AUM） 注册部署在 Azure 本地上的 Azure Arc VM，以使用用于更新 Azure 本地群集物理节点的相同机制提供统一的修补程序管理体验。 可以使用 AUM 创建 来宾维护配置。 这些配置控制设置，例如，如果需要、计划（日期、时间和重复选项），以及作用域的 Azure Arc VM 的动态（订阅）或静态列表，这些配置 重新启动。 这些设置控制在工作负荷 VM 来宾 OS 中安装 OS 安全修补程序的时间的配置。

考虑

这些注意事项实现 Azure Well-Architected 框架的支柱，这是一组指导原则，可用于提高工作负荷的质量。 有关详细信息，请参阅 azure Well-Architected FrameworkMicrosoft。

可靠性

可靠性可确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性支柱概述。

确定潜在的故障点

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

有关详细信息，请参阅 有关执行故障模式分析的建议。

可靠性目标

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

• 对于使用 Azure 本地运行的 Azure Arc VM 部署的应用程序，SLO 的运行时间或可用性为 99.8% 运行时间或可用性，会导致以下允许停机或不可用的时间段：

  • 每周：20 分 10 秒

  • 每月：1 小时 26 分 56 秒

  • 季度：4 小时 20 分 49 秒

  • 每年：17 小时 23 分 16 秒

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

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

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

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

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

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

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

  有关详细信息，请参阅 有关设计灾难恢复策略的建议。

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

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

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

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

冗余

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

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

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

安全

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全支柱概述。

安全注意事项包括：

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

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

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

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

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

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

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

成本优化

成本优化是研究减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化支柱概述。

成本优化注意事项包括：

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

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

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

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

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

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

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营支柱概述。

卓越运营注意事项包括：

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

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

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

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

  有关详细信息，请参阅 有关启用自动化的建议。

性能效率

性能效率是工作负荷的缩放能力，以满足用户以高效方式满足它的需求。 有关详细信息，请参阅 性能效率支柱概述。

性能效率注意事项包括：

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

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

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

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

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

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

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

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

部署此方案

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

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

1. 收集相关利益干系人的工作负载和用例要求。 此策略使项目能够确认 Azure Local 的特性和功能满足工作负荷规模、性能和功能要求。 此评审过程应包括了解工作负荷规模或大小，以及所需的功能，例如 Azure Arc VM、AKS、Azure 虚拟桌面或已启用 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 交换机进行网络集成。 对于高可用性解决方案，HCI 群集需要部署两个 ToR 交换机。 每个物理节点需要四个 NIC，其中两个 NIC 必须支持 RDMA，后者提供两个从每个节点到两个 ToR 交换机的链接。 两个 NIC（一个连接到每个交换机）聚合，用于计算和管理网络的出站南北连接。 另外两个支持 RDMA 的 NIC 专用于存储东西方流量。 如果计划使用现有的网络交换机，请确保交换机的制造和模型位于 Azure 本地支持的 批准的网络交换机列表上。

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

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

   提示

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

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

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

相关资源

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

后续步骤

产品文档：

• Azure Stack HCI OS 版本 23H2 版本信息
• 在 Azure 本地 上 AKS
• 适用于 Azure 本地 的 Azure 虚拟桌面
• 什么是 Azure 本地监视？
• 使用 Azure 本地 上的 Site Recovery 保护 VM 工作负荷
• 监视器概述
• 更改跟踪和库存概述
• 更新管理器概述
• 什么是已启用 Azure Arc 的数据服务？
• 什么是已启用 Azure Arc 的服务器？
• 什么是备份服务？

有关特定 Azure 服务的详细信息的产品文档：

• Azure 本地
• Azure Arc
• Key Vault
• Azure Blob 存储
• 监视器
• Azure Policy
• Azure 容器注册表
• Defender for Cloud
• Site Recovery
• 备份

Microsoft Learn 模块：

• 配置监视器
• 在 Azure 中设计站点恢复解决方案
• 已启用 Azure Arc 的服务器 简介
• 已启用 Azure Arc 的数据服务 简介
• AKS 的 简介
• 在任意位置使用机器学习 缩放模型部署 - 技术社区博客
• 使用已启用 AKS 和已启用 Azure Arc 的机器学习实现机器学习 - 技术社区博客
• 使用已启用 Azure Arc 的机器学习在 AKS 混合和 Stack HCI 上 机器学习 - 技术社区博客
• 机器学习 中的 Kubernetes 计算目标简介
• 使 VM 保持更新
• 使用自动化状态配置保护 VM 设置
• 使用备份 保护 VM