你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure Stack HCI 基线参考体系结构

Azure Stack HCI
Azure Arc
Azure Key Vault
Azure Blob 存储
Azure Monitor
Microsoft Defender for Cloud

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

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

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

有关 Azure 架构良好的框架的五大支柱的指南和建议的详细信息,请参阅 Azure Stack HCI 架构良好的框架服务指南

文章布局

体系结构 设计决策 Well-Architected Framework 方法
体系结构
可能的用例
方案详细信息
平台资源
平台支持资源
部署此方案
群集设计选项
物理磁盘驱动器
网络设计
监视
更新管理
可靠性
安全性
成本优化
卓越运营
性能效率

提示

GitHub 徽标Azure Stack HCI 23H2 群集参考实现演示如何使用 Azure 资源管理模板(ARM 模板)和参数文件部署 Azure Stack HCI 的交换机多服务器部署。 另外,Bicep 示例 演示如何使用 Bicep 模板部署 Azure Stack HCI 群集及其先决条件资源。

体系结构

显示多节点 Azure Stack HCI 群集参考体系结构的示意图,该体系结构具有用于外部南北连接的双架顶 (ToR) 交换机。

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

可能的用例

Azure Stack HCI 的典型用例包括在本地或边缘位置运行高可用性 (HA) 工作负载的能力,这提供了一种解决方案来满足工作负载需求。 您可以:

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

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

  • 通过使用经过 Microsoft 认证的解决方案、基于云的部署、集中管理以及监视和警报,降低总体拥有成本 (TCO)。

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

  • 遵守严格的安全性、合规性和审计要求。 Azure Stack HCI 部署时默认配置了强化安全态势,或默认配置为 secure-by-default。 Azure Stack HCI 整合了经过认证的硬件、安全启动、受信任的平台模块 (TPM)、虚拟化的安全性 (VBS)、Credential Guard 和强制的 Windows Defender 应用程序控制策略。 它还与新式基于云的安全和威胁管理服务(如 Microsoft Defender for Cloud 和 Microsoft Sentinel)集成。

方案详细信息

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

将 Azure Arc 与 Azure Stack HCI 配合使用

Azure Stack HCI 使用 Azure Arc 直接与 Azure 集成,以降低 TCO 和运营开销。 Azure Stack HCI 通过 Azure 进行部署和管理,Azure 通过部署 Azure Arc 资源网桥组件提供 Azure Arc 的内置集成。 此组件在 HCI 群集部署过程中安装。 Azure Stack HCI 群集节点已向 Azure Arc for servers 注册,这是启动群集基于云的部署的先决条件。 在部署过程中,每个群集节点上都安装了强制扩展,如生命周期管理器、Microsoft Edge 设备管理以及遥测和诊断。 通过启用 Azure Stack HCI Insights,可以在部署后使用 Azure Monitor 和 Log Analytics 来监视 HCI 群集。 我们将定期发布 Azure Stack HCI 的功能更新以改善客户体验。 通过 Azure 更新管理器控制和管理更新。

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

Azure 和 Azure Arc 集成扩展了 Azure Stack HCI 虚拟化和容器化工作负载的功能,包括:

Azure Arc 连接的工作负载为 Azure Stack HCI 部署提供增强的 Azure 一致性和自动化,例如使用 Azure Arc VM 扩展自动执行来宾 OS 配置,或者通过 Azure Policy 评估对行业法规或公司标准的合规性。 可以通过 Azure 门户或 IaC 自动化激活 Azure Policy。

充分利用 Azure Stack HCI 默认安全配置

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

Azure Stack HCI 认证的硬件可确保内置安全启动、统一可扩展固件接口 (UEFI) 和 TPM 支持。 将这些技术与 VBS 结合使用,有助于保护对安全敏感的工作负载。 可以使用 BitLocker 驱动器加密对启动磁盘卷和存储空间直通卷进行加密。 服务器消息块 (SMB) 加密对群集(存储网络)内服务器之间的流量进行自动加密,对群集节点与其他系统之间的 SMB 流量进行签名。 SMB 加密还有助于防止中继攻击,并有助于遵守法规标准。

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

组件

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

平台资源

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

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

  • Azure Arc 是一种基于云的服务,可将基于 Azure 资源管理器的管理模型扩展到 Azure Stack HCI 和其他非 Azure 位置。 Azure Arc 使用 Azure 作为控制和管理平面,以实现对各种资源的管理,如 VM、Kubernetes 群集、容器化数据和机器学习服务。

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

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

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

平台支持资源

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

  • Monitor 是一项基于云的服务,用于收集、分析和处理来自云和本地工作负载的诊断日志和遥测数据。 可使用 Monitor 通过全面的监视解决方案来帮助最大程度地提高应用程序和服务的可用性和性能。 部署 Azure Stack HCI Insights 以简化 Monitor 数据收集规则 (DCR) 的创建,并快速启用对 Azure Stack HCI 群集的监视。

  • Azure Policy 是一项评估 Azure 和本地资源的服务。 Azure Policy 通过与 Azure Arc 集成来评估资源,方法是将这些资源的属性用于业务规则(称为策略定义),以确定可用于使用策略设置应用 VM 来宾配置的合规性或功能。

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

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

  • Site Recovery 是一项灾难恢复服务,通过在发生灾难或停机时使商业应用程序和工作负载能够进行故障转移来提供 BCDR 功能。 Site Recovery 可管理在物理计算机和 VM 上运行的工作负载在其主站点(本地)和次要位置 (Azure) 之间的复制和故障转移。

群集设计选项

设计 Azure Stack HCI 群集时,请务必了解工作负载性能和复原要求。 这些要求包括部署在 Azure Stack HCI 群集上的所有工作负载的恢复时间目标 (RTO) 和恢复点目标 (RPO) 时间、计算 (CPU)、内存和存储要求。 工作负载的几个特征会影响决策过程,包括:

  • 中心处理单元 (CPU) 体系结构功能,包括硬件安全技术功能、CPU 数量、GHz 频率(速度)和每个 CPU 插槽的核心数。

  • 工作负载的图形处理单元 (GPU) 要求,例如用于 AI 或机器学习、推理或图形呈现。

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

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

    • 若要保持计算复原能力,需要在群集中保留至少 N+1 个节点的容量。 这种策略使节点能够从突然中断(如停电或硬件故障)中进行更新或恢复。

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

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

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

    • 容量:在容错之后,或者拷贝之后,需要的总可用存储空间将考虑在内。 使用三向镜像时,此数字大约是容量层磁盘的原始存储空间的 33%。

    • 性能:平台的每秒输入/输出操作数 (IOPS),它决定了工作负载的存储吞吐量能力乘以应用程序的块大小。

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

调整大小工具首选项部分将指导你完成与系统类型(顶级、集成系统或已验证的节点)和 CPU 系列选项相关的问题。 它还有助于选择群集的复原能力需求。 请确保:

  • 在整个群集中保留至少 N+1 个节点的容量,或一个节点。

  • 在整个群集中保留 N+2 个节点的容量,以获得额外的复原能力。 此选项使系统能够在更新期间承受节点故障或同时影响两个节点的其他意外事件。 它还可确保群集中有足够的容量让工作负载在剩余的联机节点上运行。

此场景要求对用户卷使用三向镜像,这是具有三个或更多物理节点的群集的默认设置。

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

物理磁盘驱动器

存储空间直通支持性能和容量各不相同的多种物理磁盘驱动器类型。 设计 Azure Stack HCI 群集时,请与所选的硬件 OEM 合作伙伴协作,确定最适合的物理磁盘驱动器类型,以满足工作负载的容量和性能要求。 示例包括旋转硬盘驱动器 (HDD) 或固态硬盘 (SSD) 和 NVMe 驱动器。 这些驱动器通常称为闪存驱动器,或持久内存 (PMem) 存储,也称为存储类内存 (SCM)

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

对于常规用途工作负载,混合存储配置(如用于缓存的 NVMe 驱动器或 SSD)和用于容量的 HDD 可能会提供更多存储空间。 代价是,如果工作负载超过缓存工作集,旋转磁盘的性能较低;与 NVMe 和 SSD 驱动器相比,HDD 的平均故障间隔时间值也会降低。

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

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

提示

对于高性能或延迟敏感的工作负载,建议使用全闪存存储(全 NVMe 或全 SSD)配置和三个或更多物理节点的群集大小。 使用默认存储配置设置部署此设计,为基础结构和用户卷使用三向镜像。 此部署策略提供最高的性能和复原能力。 使用全 NVMe 或全 SSD 配置时,你将从每个闪存驱动器的全部可用存储容量受益。 与混合或混搭 NVMe + SSD 设置不同,没有为缓存保留容量。 这确保了存储资源的最佳利用率。 有关如何平衡性能和容量以满足工作负载要求的详细信息,请参阅规划卷 - 当性能最重要时

网络设计

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

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

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

物理网络拓扑

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

设计使用此基线体系结构的多节点存储交换的 Azure Stack HCI 部署时,需要以下组件:

此图显示了多节点 Azure Stack HCI 群集的物理网络拓扑,该群集使用具有双 ToR 交换机的存储交换机体系结构。

  • 双 ToR 交换机:

    • 需要双 ToR 网络交换机来实现网络复原,并能够为交换机提供服务或应用固件更新,而不会导致停机。 此策略可防止单一故障点 (SPOF)。

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

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

  • 两个或更多个物理节点,最多 16 个节点:

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

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

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

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

  • 外部连接:

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

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

逻辑网络拓扑

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

Azure Stack HCI 的多节点存储交换基线体系结构的逻辑设置摘要如下:

显示使用具有双 ToR 交换机的存储交换体系结构的多节点 Azure Stack HCI 群集的逻辑网络拓扑的示意图。

  • 双 ToR 交换机:

    • 在部署群集之前,需要为两个 ToR 网络交换机配置所需的 VLAN ID、最大传输单元设置,以及管理计算存储端口的数据中心桥接配置。 有关详细信息,请参阅 Azure Stack HCI 的物理网络要求,或向你的交换机硬件供应商或 SI 合作伙伴寻求帮助。
  • Azure Stack HCI 使用网络 ATC 方法应用网络自动化和基于意图的网络配置。

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

    • 基于意向的策略通过根据作为 Azure Stack HCI 云部署过程的一部分指定的参数输入自动化节点网络配置,简化了网络配置需求。

  • 外部通信:

    • 当节点或工作负载需要通过访问公司 LAN、Internet 或其他服务进行外部通信时,它们会使用双 ToR 交换机进行路由。 此过程在前面的物理网络拓扑一节中进行了概述。

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

    • 管理网络意图使用聚合 SET 组合虚拟接口,使群集管理 IP 地址和控制平面资源能够与外部通信。

    • 对于计算网络意向,可以在 Azure 中创建一个或多个逻辑网络,并为环境使用特定的 VLAN ID。 工作负载资源(如 VM)使用这些 ID 授予对物理网络的访问权限。 逻辑网络使用两个物理网络适配器端口,这些端口通过 SET 组合用于计算和管理目的。

  • 存储流量:

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

    • SMB1SMB2 存储端口连接到两个独立的不可路由(或第 2 层)网络。 每个网络都配置了一个特定的 VLAN ID,该 ID 必须与 ToR 交换机的默认存储 VLAN ID:711 和 712 上的交换机端口配置相匹配。

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

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

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

网络交换机要求

以太网交换机必须符合 Azure Stack HCI 要求的不同规范,并由电气和电子工程师协会 (IEEE) 设置。 例如,对于多节点存储交换部署,存储网络通过 RoCE v2 或 iWARP 用于 RDMA。 此过程要求 IEEE 802.1Qbb PFC 确保存储流量类的无损通信。 ToR 交换机必须支持用于 VLAN 的 IEEE 802.1Q 和用于链路层发现协议的 IEEE 802.1AB。

如果计划对 Azure Stack HCI 部署使用现有网络交换机,请查看网络交换机和配置必须提供的强制性 IEEE 标准和规范列表。 购买新的网络交换机时,请联系交换机供应商,以确保设备符合 Azure Stack HCI IEEE 规范要求,或查看支持 Azure Stack HCI 网络要求的硬件供应商认证的交换机型号列表

IP 地址要求

在多节点存储交换部署中,所需的 IP 地址数量随着每个物理节点的增加而增加,单个群集内最多可达 16 个节点。 例如,若要部署 Azure Stack HCI 的双节点存储交换配置,群集基础结构至少需要分配 11 x 个 IP 地址。 如果使用微分段或软件定义的网络,则需要更多 IP 地址。 有关详细信息,请参阅查看 Azure Stack HCI 的双节点存储参考模式 IP 地址要求

设计和规划 Azure Stack HCI 的 IP 地址要求时,请记住考虑到 Azure Stack HCI 群集和基础结构组件所需的 IP 地址或网络范围之外的工作负载所需的其他 IP 地址或网络范围。 如果打算在 Azure Stack HCI 上部署 AKS,请参阅 Azure Arc 启用的 AKS 网络要求

监视

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

Azure Stack HCI Insights 是使用 Monitor 和 Log Analytics 构建的,确保了一个始终最新、可扩展且高度可定制的解决方案。 Insights 提供对具有基本指标的默认工作簿的访问权限,以及为监视 Azure Stack HCI 的关键功能而创建的专用工作簿。 这些组件提供了一种近乎实时的监控解决方案,并支持创建图形、通过聚合和筛选自定义可视化以及配置自定义资源运行状况警报规则。

更新管理

Azure Stack HCI 群集和部署的工作负载资源(例如 Azure Arc VM)需要定期更新和修补。 通过定期应用更新,可确保组织保持强大的安全态势,并提高资产的整体可靠性和可支持性。 建议使用自动和定期手动评估,以便及早发现和应用安全修补程序和操作系统更新。

基础结构更新

Azure Stack HCI 不断更新,以改善客户体验并添加新的特性和功能。 此过程通过发布序列进行管理,每季度发布一次新的基线版本。 基线生成应用于 Azure Stack HCI 群集,以保持其最新状态。 除了定期的基线版本更新之外,Azure Stack HCI 还会每月更新操作系统安全性和可靠性。

更新管理器是一项 Azure 服务,可用于应用、查看和管理 Azure Stack HCI 的更新。 此服务提供了一种机制,通过使用 Azure 门户提供集中管理体验,可以查看整个基础结构和边缘位置的所有 Azure Stack HCI 群集。 有关更多信息,请参阅以下资源:

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

工作负载来宾 OS 修补

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

注意事项

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

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性支柱概述

确定潜在的故障点

每个体系结构都容易出现故障。 可以预测故障,并通过故障模式分析准备好缓解措施。 下表介绍了此体系结构中潜在故障点的四个示例:

组件 风险 可能性 影响/缓解措施/备注 中断
Azure Stack HCI 群集中断 电源、网络、硬件或软件故障 为防止 Azure Stack HCI 群集在业务或任务关键型用例中发生故障而导致长时间的应用程序中断,工作负载应该使用 HA 和 DR 原则进行架构设计。 例如,可以使用行业标准工作负载数据复制技术来维护使用部署在单独的 Azure Stack HCI 群集和单独的物理位置上的多个 Azure Arc VM 或 AKS 实例部署的持久状态数据的多个副本。 潜在中断
Azure Stack HCI 单物理节点中断 电源、硬件或软件故障 为了防止单个 Azure Stack HCI 节点发生故障而导致的应用程序长时间中断,Azure Stack HCI 群集应具有多个物理节点。 群集设计阶段的工作负载容量要求决定了节点的数量。 建议有三个或更多个节点。 还建议使用三向镜像,这是具有三个或更多节点的群集的默认存储复原模式。 若要防止 SPoF 并提高工作负载复原能力,请使用在多个 AKS 工作器节点中运行的两个或多个 Azure Arc VM 或容器 Pod 部署工作负载的多个实例。 如果单个节点发生故障,Azure Arc VM 和工作负载/应用程序服务将在群集中剩余的联机物理节点上重新启动。 潜在中断
Azure Arc VM 或 AKS 工作器节点(工作负载) 配置错误 应用程序用户无法登录或访问应用程序。 在部署过程中发现配置错误。 如果这些错误发生在配置更新过程中,DevOps 团队必须回滚更改。 如有必要,可以重新部署 VM。 重新部署的部署时间不到 10 分钟,但根据部署类型,可能需要更长的时间。 潜在中断
连接到 Azure 网络中断 群集需要定期访问 Azure 控制平面,以实现计费、管理和监视功能。 如果群集断开与 Azure 的连接,则将以降级状态运行。 例如,如果群集断开与 Azure 的连接,则无法部署新的 Azure Arc VM 或 AKS 群集。 在 HCI 群集上运行的现有工作负载将继续运行,但应在 48 到 72 小时内还原连接,以确保不间断操作。

有关详细信息,请参阅执行失败模式分析的建议

可靠性目标

本节介绍一个示例方案。 名为 Contoso Manufacturing 的虚构客户使用此参考体系结构来部署 Azure Stack HCI。 他们希望满足自己的需求,并在本地部署和管理工作负载。 Contoso Manufacturing 的内部服务级别目标 (SLO) 目标为 99.8%,业务和应用程序利益干系人就其服务达成一致。

  • 对于使用 Azure Stack HCI 上运行的 Azure Arc VM 部署的应用程序,99.8% 正常运行时间或可用性的 SLO 会导致以下允许的停机时间或不可用时间:

    • 每周:20 分 10 秒

    • 每月:1 小时 26 分 56 秒

    • 每季度:4 小时 20 分 49 秒

    • 每年:17 小时 23 分 16 秒

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

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

  • Contoso Manufacturing 的生产系统实行严格的变更控制过程。 此过程要求在生产中实现之前,在具有代表性的测试环境中对所有更改进行测试和验证。 提交给每周变更咨询委员会流程的所有变更必须包括详细的实施计划(或源代码链接)、风险等级分数、全面的回滚计划、发布后测试和验证,以及待审查或批准变更的明确成功标准。

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

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

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

  • Contoso Manufacturing 实施每日、每周和每月备份,以保留过去 6 天的每日备份(星期一到星期六)、过去 3 x 的每周备份(每个星期日)和 3 x 的每月备份,并使用基于滚动日历的计划将每个星期日(第 4 周)保留为第 1 个月、第 2 个月和第 3 个月的备份,该计划是有记录和可审计的。 此方法满足 Contoso Manufacturing 的要求,即在可用数据恢复点的数量和降低异地或云备份存储服务的成本之间取得足够的平衡。

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

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

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

  • 本文前面所述的操作流程和程序以及 Azure Stack HCI 架构良好的框架服务指南中的建议,使 Contoso Manufacturing 能够实现其 99.8% 的 SLO 目标,并有效地缩放和管理全球多个制造站点的 Azure Stack HCI 和工作负载部署。

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

冗余

将部署在单个 Azure Stack HCI 群集上的工作负载视为本地冗余部署。 群集在平台级别提供高可用性,但必须将群集部署在单个机架中。 对于业务关键型或任务关键型用例,建议在两个或多个独立的 Azure Stack HCI 群集上部署工作负载或服务的多个实例,最好在单独的物理位置。

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

有关详细信息,请参阅有关设计冗余的建议

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息,请参阅安全性支柱概述

安全性注意事项包括:

  • Azure Stack HCI 平台的安全基础Azure Stack HCI 是一种默认安全产品,它使用经过验证的硬件组件和 TPM、UEFI 和安全启动,为 Azure Stack HCI 平台和工作负载安全性构建安全基础。 使用默认安全设置部署时,Azure Stack HCI 已启用 Windows Defender 应用程序控制、Credential Guard 和 BitLocker。 若要使用 PoLP 简化委派权限,请使用 Azure Stack HCI 内置基于角色的访问控制 (RBAC) 角色,例如面向平台管理员的 Azure Stack HCI 管理员和 Azure Stack HCI VM 参与者或面向工作负载操作员的 Azure Stack HCI VM 读取者。

  • 默认安全设置Azure Stack HCI 安全默认设置在部署期间为 Azure Stack HCI 群集应用默认安全设置,并启用偏移控制使节点保持已知良好状态。 可以使用安全默认设置来管理群集上的群集安全性、偏移控制和受保护的核心服务器设置。

  • 安全事件日志Azure Stack HCI syslog 转发通过检索相关的安全事件日志来聚合和存储事件,以便在自己的 SIEM 平台中保留,从而与安全监视解决方案集成。

  • 防范威胁和漏洞Defender for Cloud 可保护 Azure Stack HCI 群集免受各种威胁和漏洞的影响。 此服务有助于改善 Azure Stack HCI 环境的安全状况,并可以抵御现有和不断发展的威胁。

  • 威胁检测和修正Microsoft高级威胁分析可检测并修正威胁,例如针对 AD DS 的威胁,这些威胁向 Azure Stack HCI 群集节点及其 Windows Server VM 工作负载提供身份验证服务。

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

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

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息,请参阅成本优化支柱概述

成本优化注意事项包括:

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

  • Azure Arc VM 的自动 VM 来宾修补:此功能有助于减少手动修补的开销和相关的维护成本。 这一操作不仅有助于使系统更加安全,而且还优化了资源分配,从而可提高整体成本效益。

  • 成本监视整合:若要整合监视成本,请使用 Azure Stack HCI Insights,并使用 Azure Stack HCI 更新管理器进行修补。 Insights 使用 Monitor 提供丰富的指标和警报功能。 Azure Stack HCI 的生命周期管理器组件与更新管理器集成,通过将各种组件的更新工作流整合到到单一体验中,简化了保持群集最新的任务。 使用 Monitor 和更新管理器优化资源分配,提高整体成本效益。

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

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

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

提示

如果你拥有具有有效软件保障的 Windows Server Datacenter 许可证,则可以使用 Azure 混合权益节省成本。 有关详细信息,请参阅 Azure Stack HCI 的 Azure 混合权益

卓越运营

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

卓越运营注意事项包括:

  • 简化与 Azure 集成的预配和管理体验Azure 中的基于云的部署提供向导驱动的界面,演示如何创建 Azure Stack HCI 群集。 同样,Azure 简化了管理 Azure Stack HCI 群集Azure Arc VM 的过程。 可以使用 ARM 模板自动执行基于门户的 Azure Stack HCI 群集部署。 此模板提供大规模部署 Azure Stack HCI 的一致性和自动化,特别是在需要 Azure Stack HCI 群集运行业务关键型工作负载的边缘方案中。

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

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

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

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

性能效率

性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息,请参阅性能效率要素概述

性能效率注意事项包括:

  • 工作负载存储性能:请考虑使用 DiskSpd 工具测试 Azure Stack HCI 群集的工作负载存储性能功能。 可以使用 VMFleet 工具生成负载并测量存储子系统的性能。 评估是否应使用 VMFleet 来测量存储子系统性能。

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

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

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

    有关详细信息,请参阅容量规划的建议

  • 网络性能优化:考虑网络性能优化。 作为设计的一部分,在确定最佳网络硬件配置时,请务必包括预计的网络流量带宽分配

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

      有关详细信息,请参阅有关选择适当服务的建议

部署此方案

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

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

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

  2. 查看建议的硬件合作伙伴解决方案的 Azure Stack HCI Sizer 输出。 此输出包括建议的物理服务器硬件制造和模型、物理节点数以及部署和运行工作负载所需的每个物理节点的 CPU、内存和存储配置的详细信息。

  3. 使用 Azure Stack HCI 调整大小工具创建一个对工作负载类型和规模进行建模的新项目。 此项目包括 VM 的大小和数量及其存储要求。 这些详细信息连同系统类型、首选 CPU 系列以及高可用性和存储容错的复原要求的选项一起输入,如前面的群集设计选项部分所述。

  4. 查看建议的硬件合作伙伴解决方案的 Azure Stack HCI Sizer 输出。 此解决方案包括建议的物理服务器硬件(制造和模型)、物理节点数以及部署和运行工作负载所需的每个物理节点的 CPU、内存和存储配置的规范。

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

  6. 部署两个 ToR 交换机进行网络集成。 对于高可用性解决方案,HCI 群集需要部署两个 ToR 交换机。 每个物理节点需要四个 NIC,其中两个 NIC 必须支持 RDMA,后者提供两个从每个节点到两个 ToR 交换机的链接。 两个 NIC(一个连接到每个交换机)聚合,用于计算和管理网络的出站南北连接。 另外两个支持 RDMA 的 NIC 专用于存储东西流量。 如果计划使用现有的网络交换机,请确保交换机的品牌和型号位于 Azure Stack HCI 支持的已批准的网络交换机列表中。

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

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

    提示

    GitHub 徽标 Azure Stack HCI 23H2 群集参考实现演示如何使用 ARM 模板和参数文件部署 Azure Stack HCI 的交换机多服务器部署。 另外,Bicep 示例 演示如何使用 Bicep 模板部署 Azure Stack HCI 群集,包括其先决条件资源。

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

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

后续步骤

产品文档:

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

Microsoft Learn 模块: