你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Stack HCI 上的 Azure 良好架构框架视角
Azure Stack HCI 是一个超融合基础结构（HCI）平台，提供本地存储、网络资源和计算资源。 可以使用 Azure Stack HCI 创建和管理 Windows 和 Linux 虚拟机（VM）、用于容器化工作负荷的 Kubernetes 群集和其他已启用 Azure Arc 的服务。 该平台使用 Azure 简化的部署和管理，通过 Azure Arc 提供统一且一致的管理体验。可以使用 Azure Stack HCI 和 Azure Arc 功能在本地保留业务系统和应用程序数据，以解决数据主权、法规和合规性以及延迟要求。
本文假设你已了解混合系统并了解 Azure Stack HCI 的工作知识。 本文中的指南提供了映射到 Azure 良好架构框架支柱原则的体系结构建议。
重要
如何使用本指南
每个部分都有一个 设计清单，该清单 提供关注的体系结构区域以及本地化为技术范围的设计策略。
还包括有关有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于 Azure Stack HCI 及其依赖项的所有配置的详尽列表。 而是列出映射到设计透视的关键建议。 使用建议生成概念证明或优化现有环境。
演示关键建议的基础体系结构：
Azure Stack HCI 基线参考体系结构。
技术范围
此评审重点介绍以下 Azure 资源的相关决策：
- Azure Stack HCI（平台）、版本 23H2 及更高版本
- Azure Arc VM （工作负荷）
注意
本文介绍上述范围，并提供按平台体系结构和工作负荷体系结构组织的清单和建议。 平台问题由平台管理员负责。 工作负荷问题由工作负荷操作员和应用程序开发人员负责。 这些角色和职责是不同的，可以由单独的团队或个人拥有。 在应用指南时，请记住这一区别。
本指南不侧重于可在 Azure Stack HCI 上部署的特定资源类型，例如 Azure Arc VM、Azure Kubernetes 服务（AKS）和 Azure 虚拟桌面。 在 Azure Stack HCI 上部署这些资源类型时，请参阅相应的工作负荷指南，设计满足业务需求的解决方案。
可靠性
可靠性支柱的目的是通过 构建足够的复原能力和从故障中快速恢复的能力来提供持续的功能。
可靠性设计原则为各个组件、系统流和整个系统提供高级设计策略。
在混合云部署中，目标是减少一个组件故障的影响。 使用这些设计清单和配置建议来减轻在 Azure Stack HCI 上部署的工作负荷的组件故障的影响。
必须区分平台可靠性和工作负荷可靠性。 工作负荷可靠性依赖于平台。 应用程序所有者或开发人员必须设计可提供定义的可靠性目标的应用程序。
设计清单
根据 可靠性设计评审清单启动设计策略。 确定其与业务需求的相关性，同时记住 Azure Stack HCI 的性能。 扩展策略以根据需要包含更多方法。
（Azure Stack HCI 平台体系结构和工作负荷体系结构） 定义工作负荷可靠性目标。
设置服务级别目标（SLO），以便评估可用性目标。 将 SLA 计算为百分比，例如 99.9%、99.95% 或反映工作负荷运行时间的 99.995%。 请记住，此计算不仅基于 Azure Stack HCI 群集或工作负荷发出的平台指标。 若要获取全面的目标度量，请考虑量化的细微差别因素，例如发布期间的预期停机时间、例行操作、可支持性或其他特定于工作负荷或组织特定的因素。
Microsoft提供的服务级别协议（SLA）通常会影响 SLO 计算。 但是，Microsoft不会为 Azure Stack HCI 群集或已部署的工作负荷的运行时间和连接提供 SLA，因为Microsoft不会控制客户数据中心的可靠性（例如电源和冷却）或管理平台的人员和流程。
（Azure Stack HCI 平台体系结构） 考虑性能和操作如何影响可靠性。
群集 或其依赖项的性能下降会使 Azure Stack HCI 平台不可用。 例如：
如果没有适当的工作负荷容量规划，在设计阶段将 Azure Stack HCI 群集权限化具有挑战性，这是一项要求，使工作负荷能够达到所需的可靠性目标。 在群集设计过程中使用 Azure Stack HCI 大小器工具 。 如果需要高度可用的 VM，请考虑“节点数的 N+1 最低要求”。 对于业务关键型或任务关键型工作负荷，如果复原至关重要，请考虑对群集大小使用“N+2 个节点数”。
平台的可靠性取决于关键平台依赖项（如物理磁盘类型）的性能。 必须根据要求选择正确的磁盘类型。 对于需要低延迟和高吞吐量存储的工作负荷，我们建议使用全闪存（仅 NVMe/SSD）存储配置。 对于常规用途计算，混合存储（用于缓存的 NVMe 或 SSD 和容量 HDD）配置可能会提供更多的存储空间。 但权衡的是，如果工作负荷超过缓存工作集，旋转磁盘的性能会明显降低，并且 HDD 与 NVMe/SSD 相比，故障值之间的平均时间要低得多。
性能效率 更详细地描述了这些示例。
Azure Stack HCI 操作 不当可能会影响修补和升级、测试和部署一致性。 以下是一些示例：
如果 Azure Stack HCI 平台未 随最新的硬件原始设备制造商（OEM）固件、驱动程序和创新而发展，则平台可能无法利用最新的复原功能。 定期应用硬件 OEM 驱动程序和固件更新。 有关详细信息，请参阅 Azure Stack HCI 解决方案目录。
在部署之前，必须测试目标环境的连接、硬件和标识和访问管理。 否则，可以将 Azure Stack HCI 解决方案部署到不稳定的环境，这可能会造成可靠性问题。 即使在群集硬件可用之前，也可以在独立模式下使用环境检查器工具来检测问题。
有关操作指南，请参阅 卓越运营。
（Azure Stack HCI 平台体系结构） 为群集及其基础结构依赖项提供容错。
存储设计选择。 对于大多数部署，“自动创建工作负荷和基础结构卷”的默认选项就足够了。 如果选择高级选项：“仅创建所需的基础结构卷”，请根据工作负荷要求在存储空间直通中配置适当的卷容错。 这些决策会影响卷的性能、容量和复原能力。 例如，三向镜像提高了具有三个或更多节点的群集的可靠性和性能。 有关详细信息，请参阅存储效率和创建存储空间直通虚拟磁盘和卷的容错。
网络体系结构。 使用经过验证的网络拓扑部署 Azure Stack HCI。 具有四个或更多个物理节点的多节点群集需要“存储切换”设计。 具有两个或三个节点的群集可以选择使用“存储无交换机”设计。 无论群集大小如何，我们建议对管理和计算意向（南北上行）使用双顶机架（ToR）交换机来提供更高的容错能力。 在交换机服务（固件更新）操作期间，双 ToR 拓扑还提供复原能力。 有关详细信息，请参阅 已验证的网络拓扑。
（工作负荷体系结构） 生成冗余以提供复原能力。
请考虑将单个 Azure Stack HCI 群集上部署为本地冗余部署的工作负荷。 群集在平台级别提供高可用性，但必须记住，部署群集“在单个机架中”。 因此，对于业务关键型或任务关键型用例，我们建议跨两个或多个单独的 Azure Stack HCI 群集（理想情况下在单独的物理位置）部署工作负荷或服务的多个实例。
对工作负荷使用行业标准的高可用性模式，例如提供主动/被动同步或异步数据复制 （如 SQL Server Always On）的设计。 另一个示例是外部网络负载均衡（NLB）技术，可以跨部署在单独物理位置的 Azure Stack HCI 群集上运行的多个工作负荷实例路由用户请求。 请考虑使用合作伙伴外部 NLB 设备。 或评估支持混合和本地服务的流量路由的负载均衡选项，例如使用 Azure ExpressRoute 或 VPN 隧道连接到本地服务的Azure 应用程序网关实例。
有关详细信息，请参阅 跨多个 Azure Stack HCI 群集部署工作负荷实例。
（工作负荷体系结构） 根据工作负荷恢复点目标（RPO）和恢复时间目标（RTO）目标规划和测试可恢复性 。
有 一个记录良好的灾难恢复计划。 定期测试恢复步骤，以确保业务连续性计划和流程有效。 确定 Azure Site Recovery 是否是保护在 Azure Stack HCI 上运行的 VM 的可行选择。 有关详细信息，请参阅使用 Azure Stack HCI 上的 Azure Site Recovery 保护 VM 工作负荷（预览版）。
（工作负荷体系结构） 配置并定期测试工作负荷备份和还原过程。
数据恢复和保留的业务要求驱动工作负荷备份的策略。 全面的策略包括工作负荷操作系统（OS）和应用程序持久性数据的注意事项，能够还原单个（时间点）文件和文件夹级数据。 根据数据恢复和符合性要求配置备份保留策略，以确定可用数据恢复点的数量和期限。 浏览Azure 备份作为为 Azure Stack HCI 启用主机级或 VM 来宾级备份的选项。 查看与备份相关的软件供应商合作伙伴提供的数据保护解决方案。 有关详细信息，请参阅 Azure Stack HCI 的Azure 备份指南和最佳做法和Azure 备份。
建议
| 建议 | 好处 |
|---|---|
| 在存储空间直通存储池中保留一个容量磁盘，相当于每个节点的空间。 | 如果在部署 Azure Stack HCI 群集后选择创建工作负荷卷（高级选项：“仅创建所需的基础结构卷”），建议 将 5% 到 10% 的总池容量保留到未分配在存储池中的容量。 当物理磁盘发生故障时，这种保留和未使用或可用容量使存储空间直通可以修复“就地”，从而在发生物理磁盘故障时提高数据复原能力和性能。 |
| 确保所有物理节点都有权访问 Azure Stack HCI 和 Azure Arc 所需的出站 HTTPS 终结点列表。 | 若要可靠地管理、监视和操作 Azure Stack HCI 群集或工作负荷资源，所需的出站网络终结点必须直接或通过代理服务器进行访问。 临时中断不会影响工作负荷的运行状态，但可能会影响可管理性。 |
| 如果选择手动创建工作负荷卷（虚拟磁盘），请使用最合适的复原类型来最大程度地提高工作负荷复原能力和性能。 对于在部署群集后手动创建的任何用户卷， 请在 Azure 中创建卷的存储路径。 该卷可以通过存储路径存储工作负荷 VM 配置文件、VM 虚拟硬盘（VHD）和 VM 映像。 | 对于具有三个或多个节点的 Azure Stack HCI 群集，请考虑使用三向镜像来提供最高的复原能力和性能功能。 建议对业务关键型或任务关键型工作负荷使用镜像卷。 |
| 请考虑实施 工作负荷反关联规则 ，以确保托管同一服务多个实例的 VM 在单独的物理主机上运行。 此概念类似于 Azure 中的“可用性集”。 | 使所有组件都变得冗余。 对于业务关键型或任务关键型工作负荷，请使用多个 Azure Arc VM 或 Kubernetes 副本集或 Pod 来部署应用程序或服务的多个实例。 如果发生单个物理节点的计划外中断，此方法会增加复原能力。 |
安全性
安全支柱的目的是为工作负载提供机密性、完整性和可用性保证。
安全 设计原则 通过对 Azure Stack HCI 的技术设计应用方法，为实现这些目标提供了高级设计策略。
Azure Stack HCI 是一种默认安全产品，在云部署过程中启用了 300 多个安全设置。 默认安全设置提供一致的安全基线，以确保设备以已知良好状态启动。 可以使用偏移保护控制来提供大规模管理。
Azure Stack HCI 中的默认安全功能包括强化的 OS 安全设置、Windows Defender 应用程序控制、通过 BitLocker 进行卷加密、机密轮换、本地内置用户帐户和 Microsoft Defender for Cloud。 有关详细信息，请参阅 “查看安全功能”。
设计清单
根据 安全设计评审清单启动设计策略。 确定漏洞和控制以提高安全态势。 扩展策略以根据需要包含更多方法。
（Azure Stack HCI 平台体系结构） 查看安全基线。 Azure Stack HCI 和安全标准 提供基线指导，以加强平台和托管工作负载的安全态势。 如果你的工作负载需要遵守特定的法规合规性法规，请考虑法规安全标准，例如支付卡行业数据安全标准和联邦信息处理标准 140。
Azure Stack HCI 平台提供的默认设置 支持安全功能，包括标识控制、网络筛选和加密。 这些设置构成了新预配的 Azure Stack HCI 群集的良好安全基线。 可以根据组织安全要求自定义每个设置。
确保 检测并防范意外的安全配置偏移。
（Azure Stack HCI 平台体系结构） 检测、预防和响应威胁。 持续监视 Azure Stack HCI 环境，并防范现有和不断演变的威胁。
建议在 Azure Stack HCI 上启用 Defender for Cloud。 使用 Defender 云安全状况管理启用基本的 Defender for Cloud 计划（免费层），以监视和识别可以保护 Azure Stack HCI 平台以及其他 Azure 和 Azure Arc 资源所要采取的步骤。
若要从增强的安全功能中受益，包括单个服务器和 Azure Arc VM 的安全警报，请在 Azure Stack HCI 群集节点和 Azure Arc VM 上为服务器启用 Microsoft Defender for Servers。
使用 Defender for Cloud 衡量 Azure Stack HCI 节点和工作负载的安全状况。 Defender for Cloud 提供单一的玻璃体验，以帮助管理安全合规性。
使用 Defender for Servers 监视托管 VM 的威胁和配置错误。 还可以在 Azure Stack HCI 节点上启用终结点检测和响应功能。
考虑将所有源的安全和威胁情报数据聚合到集中式安全信息和事件管理（SIEM）解决方案，例如 Microsoft Sentinel。
（Azure Stack HCI 平台体系结构和工作负荷体系结构） 创建分段以包含爆炸半径。 有几种策略可以实现分段。
标识。 使平台和工作负载的角色和职责保持独立。 仅允许授权标识执行与其指定角色相符的特定操作。 Azure Stack HCI 平台管理员同时使用 Azure 和本地域凭据来执行平台职责。 工作负荷操作员和应用程序开发人员管理工作负荷安全性。 若要简化委派权限，请使用 Azure Stack HCI 内置基于角色的访问控制（RBAC） 角色，例如平台管理员的“Azure Stack HCI 管理员”和“Azure Stack HCI VM 参与者”或工作负荷操作员的“Azure Stack HCI VM 读取者”。 有关特定内置角色 操作的详细信息，请参阅 适用于混合角色和多云角色的 Azure RBAC 文档。
网络。 根据需要隔离网络。 例如，可以预配多个逻辑网络，这些逻辑网络使用单独的虚拟局域网（vLAN）和网络地址范围。 使用此方法时，请确保管理网络可以访问每个逻辑网络和 vLAN，以便 Azure Stack HCI 群集节点可以通过 ToR 交换机或网关与 vLAN 网络通信。 此配置是工作负荷的可用性管理所必需的，例如允许基础结构管理代理与工作负荷来宾 OS 通信。
查看 有关为其他信息构建分段策略 的建议。
（Azure Stack HCI 平台体系结构和工作负荷体系结构） 使用受信任的标识提供者来控制访问。 建议为所有身份验证和授权目的Microsoft Entra ID。 如果需要，可以将工作负荷加入本地 Windows Server Active Directory 域。 利用支持强密码、多重身份验证、RBAC 和机密管理控制的功能。
（Azure Stack HCI 平台体系结构和工作负荷体系结构） 隔离、筛选和阻止网络流量。 你可能有一个工作负荷用例，该用例需要通过网络安全组、网络服务质量策略或虚拟设备链接进行微分段，以便可以引入合作伙伴设备进行筛选。 如果有此类工作负荷，请参阅网络参考模式的软件定义网络注意事项，了解网络控制器提供的受支持特性和功能的列表。
（工作负荷体系结构） 加密数据以防止篡改。 加密传输中的数据、静态数据以及正在使用的数据。
在部署期间创建的数据卷上启用了静态数据加密。 这些数据卷包括基础结构卷和工作负荷卷。 有关详细信息，请参阅 管理 BitLocker 加密。
使用 Azure Arc VM 的受信任启动功能，通过使用新式操作系统（例如安全启动）的 OS 功能来提高第 2 代 VM 的安全性，这些操作系统可以使用虚拟受信任的平台模块。
操作机密管理。 根据组织要求，更改与 Azure Stack HCI 部署用户标识关联的凭据。 有关详细信息，请参阅 “管理机密轮换”。
（Azure Stack HCI 平台体系结构） 强制实施安全控制。 使用 Azure Policy 审核和强制实施内置策略，例如“应一致地强制实施应用程序控制策略”或“应实现加密卷”。 可以使用这些 Azure 策略来审核安全设置，并评估 Azure Stack HCI 的符合性状态。 有关可用策略的示例，请参阅 Azure 策略。
（工作负荷体系结构） 使用内置策略改进工作负荷安全态势。 若要评估在 Azure Stack HCI 上运行的 Azure Arc VM，可以通过安全基准、Azure 更新管理器或 Azure Policy 来宾配置扩展应用内置策略。 可以使用各种策略来检查以下条件：
- Log Analytics 代理安装
- 需要最新的安全修补程序的最新系统更新
- 漏洞评估和潜在缓解措施
- 使用安全通信协议
建议
| 建议 | 好处 |
|---|---|
| 使用安全基线和偏移控制设置在群集节点上应用和维护安全设置。 | 这些配置有助于防止不需要的更改和偏移，因为它们每隔 90 分钟自动刷新安全设置，以强制实施 Azure Stack HCI 的预期安全状况。 |
| 在 Azure Stack HCI 中使用 Windows Defender 应用程序控制 。 | Windows Defender 应用程序控制可减少 Azure Stack HCI 的攻击面。 使用Azure 门户或 PowerShell 查看策略设置和控制策略模式。 Windows Defender 应用程序控制策略有助于控制允许在系统上运行的驱动程序和应用。 |
| 通过 BitLocker 启用卷加密以实现静态数据加密。 | BitLocker 通过加密在 Azure Stack HCI 上创建的群集共享卷来保护 OS 和数据卷。 BitLocker 使用 XTS-AES 256 位加密。 建议在 Azure Stack HCI 云部署期间为所有数据卷保留启用卷加密默认设置。 |
| 导出 BitLocker 恢复密钥 ，将其存储在 Azure Stack HCI 群集外部的安全位置。 | 在特定故障排除或恢复操作期间，可能需要 BitLocker 密钥。 建议通过“Get-AsRecoveryKeyInfo”PowerShell cmdlet 从每个 Azure Stack HCI 群集导出、保存和备份 OS 和数据卷的加密密钥。 将密钥保存在安全的外部位置，例如 Azure 密钥库。 |
| 使用 SIEM 解决方案提高安全监视和警报功能。 为此，可以将 已启用 Azure Arc 的服务器（Azure Stack HCI 平台节点）载入到 sentinel Microsoft。 或者，如果使用其他 SIEM 解决方案，请配置 安全事件的 syslog 转发到所选解决方案。 | 通过使用 Microsoft Sentinel 或 syslog 转发来转发安全事件数据，通过与客户管理的 SIEM 解决方案集成提供警报和报告功能。 |
| 使用 服务器消息块（SMB）签名 增强传输中数据保护，该保护在“默认安全设置”中启用。 | 使用 SMB 签名，可以在 Azure Stack HCI 平台与平台（北部或南部）外部的系统之间对 SMB 流量进行数字签名。 为 Azure Stack HCI 平台和其他系统之间的外部 SMB 流量配置签名，以帮助防止中继攻击。 |
| 使用 SMB 加密设置增强传输中数据保护，该保护在“默认安全设置”中启用。 | 群集内流量设置的 SMB 加密控制存储网络上 Azure Stack HCI 群集（东部或西部）中物理节点之间的流量加密。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，并优化其他 领域以满足组织预算，同时满足业务需求。
成本优化设计原则为实现这些目标并提供高级设计策略，并在与 Azure Stack HCI 及其环境相关的技术设计中做出权衡。
设计清单
根据 投资成本优化 的设计评审清单启动设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
Azure Stack HCI 会产生硬件、软件许可、工作负载、来宾 VM（Windows Server 或 Linux）许可和其他集成云服务（例如 Azure Monitor 和 Defender for Cloud）的成本。
（Azure Stack HCI 平台体系结构和工作负荷体系结构） 估算实际成本，作为成本建模的一部分。 使用 Azure 定价计算器选择和配置 Azure Stack HCI、Azure Arc 和 Azure Stack HCI 上的 AKS 等服务。 试验各种配置和支付选项来建模成本。
（Azure Stack HCI 平台体系结构和工作负荷体系结构） 优化 Azure Stack HCI 硬件的成本。 选择符合业务和商业要求的硬件 OEM 合作伙伴。 若要浏览已验证的节点、集成系统和顶级解决方案的认证列表，请参阅 Azure Stack HCI 解决方案目录。 与硬件合作伙伴沟通工作负荷特征、大小、数量和性能，以便你可以为 Azure Stack HCI 节点和群集大小授权经济高效的硬件解决方案。
（Azure Stack HCI 平台体系结构） 优化许可成本。 Azure Stack HCI 软件根据“每个物理 CPU 核心”获得许可和计费。 使用具有Azure 混合权益的现有本地核心许可证来降低 Azure Stack HCI 工作负荷的许可成本，例如运行 Windows Server、SQL Server 或 AKS 的 Azure Arc VM 和已启用 Azure Arc 的 Azure SQL 托管实例。 有关详细信息，请参阅Azure 混合权益成本计算器。
（Azure Stack HCI 平台体系结构） 节省环境成本。 评估以下选项是否有助于优化资源使用情况。
利用Microsoft套餐的折扣计划。 请考虑使用 Azure 混合权益 来降低运行 Azure Stack HCI 和 Windows Server 工作负荷的成本。 有关详细信息，请参阅 Azure Stack HCI 的 Azure 混合权益。
浏览促销产品/服务。 在注册后利用 Azure Stack HCI 60 天免费试用版，以初步证明概念或验证。
（Azure Stack HCI 平台体系结构） 节省运营成本。
评估用于修补、更新和其他操作的技术选项。 Azure Stack HCI 群集免费更新管理器，这些群集已启用Azure 混合权益和 Azure Arc VM 管理。 有关详细信息，请参阅 更新管理器常见问题解答 和 更新管理器定价。
评估与可观测性相关的成本。 设置警报规则和数据收集规则（DCR），以满足监视和审核需求。 工作负荷引入、处理和保留的数据量直接影响成本。 使用智能保留策略进行优化、限制警报的数量和频率，以及选择用于存储日志的正确存储层。 有关详细信息，请参阅 Log Analytics 的成本优化指南。
（工作负荷体系结构） 评估隔离的密度。 使用 Azure Stack HCI 上的 AKS 来提高密度并简化工作负荷管理，使容器化应用程序能够跨多个数据中心或边缘位置进行缩放。 有关详细信息，请参阅 Azure Stack HCI 上的 AKS 定价。
建议
| 建议 | 好处 |
|---|---|
| 如果具有具有软件保障的 Windows Server Datacenter 许可证，请使用 Azure Stack HCI Azure 混合权益。 | 借助 Azure Stack HCI 的 Azure 混合权益，可以最大程度地发挥本地许可证的价值，并对 Azure Stack HCI 的现有基础结构进行现代化改造，而不会产生额外的成本。 |
| 选择 Windows Server 订阅加载项或自带许可证来许可并激活 Windows Server VM，并在 Azure Stack HCI 上使用它们。 有关详细信息，请参阅 Azure Stack HCI 上的 Windows Server VM 许可证。 | 虽然可以使用任何现有的 Windows Server 许可证和激活方法（可选）启用可用于 Azure Stack HCI 的“Windows Server 订阅加载项”，但只能通过 Azure 订阅 Windows Server 来宾许可证来订阅 Windows Server 来宾许可证，该许可证按 Azure Stack HCI 群集中物理核心总数收费。 |
| 对扩展到 Azure Stack HCI 的 VM 权益使用 Azure 验证，以便支持的 Azure 独占工作负载可以在云之外工作。 | Azure Stack HCI 版本 23H2 或更高版本默认启用此权益。 使用此权益，使 VM 可以在其他 Azure 环境中运行，并且工作负荷可以从仅在 Azure 中可用的产品/服务中受益，例如 Azure Arc 启用的扩展安全更新。 |
卓越运营
卓越运营主要侧重于开发 实践、可观测性和发布管理的过程。
卓越运营设计原则提供了一个高级设计策略，用于实现工作负荷操作要求的目标。
监视和诊断至关重要。 可以使用指标来度量性能统计信息并快速排查和修正问题。 有关如何排查问题的详细信息，请参阅 卓越运营设计原则 和 收集 Azure Stack HCI 的诊断日志。
设计清单
根据 卓越运营 的设计评审清单启动设计策略，以定义与 Azure Stack HCI 相关的可观测性、测试和部署过程。
（Azure Stack HCI 平台体系结构） 提高 Azure Stack HCI 的支持性。 部署时默认启用可观测性。 这些功能可增强平台的可支持性。 遥测和诊断信息是使用 AzureEdgeTelemetryAndDiagnostics 扩展安全地从平台共享的，该扩展默认安装在所有 Azure Stack HCI 群集节点上。 有关详细信息，请参阅 Azure Stack HCI 可观测性。
（Azure Stack HCI 平台体系结构） 使用 Azure 服务减少运营复杂性并提高管理规模。 Azure Stack HCI 与 Azure 集成，以启用更新管理器等服务，用于修补平台和用于监视和警报的 Azure Monitor。 可以使用 Azure Arc 和 Azure Policy 来管理安全配置和合规性审核。 实现 Defender for Cloud 以帮助管理网络威胁和漏洞。 将 Azure 用作这些操作过程和过程的控制平面，以帮助降低复杂性、提高规模效率并提高管理一致性。
（工作负荷体系结构） 提前规划工作负载的 IP 地址网络范围要求。 Azure Stack HCI 提供了一个平台，用于部署和管理虚拟化或容器化工作负荷。 另请考虑工作负荷使用的逻辑网络的 IP 地址要求。 查看以下资源：
在 Azure Stack HCI 上部署的工作负荷需要 逻辑网络。 有关特定示例，请参阅 AKS 群集的网络要求、 适用于 Azure Arc VM 的逻辑网络以及 使用 Azure Stack HCI 的虚拟桌面。
（工作负荷配置） 为在 Azure Stack HCI 上部署的工作负荷启用监视和警报。 可以使用 适用于虚拟机的 Azure Monitor 或 适用于 Arc VM 的 VM 见解，也可以使用 容器见解和托管 Prometheus AKS 群集。
评估是否应为工作负荷使用集中式 Log Analytics 工作区。 有关共享日志接收器（数据位置）的示例，请参阅 工作负荷管理和监视建议。
（Azure Stack HCI 平台体系结构） 使用适当的验证技术进行安全部署。 在部署 Azure Stack HCI 解决方案之前，在独立模式下使用环境检查器工具评估目标环境的就绪情况。 此工具验证所需的连接、硬件、Windows Server Active Directory、网络和 Azure Arc 集成先决条件的正确配置。
（Azure Stack HCI 平台体系结构） 获取最新状态并保持最新状态。 使用 Azure Stack HCI 解决方案目录随时了解 Azure Stack HCI 群集部署的最新硬件 OEM 创新。 请考虑使用高级解决方案从额外的集成、统包式部署功能和简化的更新体验中受益。
使用更新管理器更新平台并管理 OS、核心代理和服务，包括解决方案扩展。 保持最新状态，并考虑尽可能对扩展使用“启用自动升级”设置。
建议
| 建议 | 好处 |
|---|---|
| 启用 Azure Stack HCI 群集 上的 Monitor Insights，以使用本机 Azure 功能增强监视和警报。 见解可以使用 DCR 收集的群集性能计数器和事件日志通道来监视关键的 Azure Stack HCI 功能。 对于某些硬件基础结构（如 Dell APEX），可以实时可视化硬件事件。 有关详细信息，请参阅 功能工作簿。 |
Azure 管理见解，因此它始终是最新的，它可以跨多个群集进行缩放，并且高度可自定义。 见解提供对具有基本指标的默认工作簿的访问，以及为监视 Azure Stack HCI 的关键功能而创建的专用工作簿。 此功能提供准实时监视。 可以使用聚合和筛选器功能创建图形和自定义可视化效果。 还可以配置自定义警报规则。 见解的成本取决于引入的数据数量以及 Log Analytics 工作区的数据保留设置。 启用 Azure Stack HCI Insights 时，建议使用 Insights 创建体验创建的 DCR。 DCR 名称的前缀为 AzureStackHCI-. 它配置为仅收集所需的数据。 |
| 设置警报，并根据组织要求配置警报处理规则。 获取有关运行状况、指标、日志或其他可观测性数据的更改的通知。 - 运行状况警报 - 日志警报 - 指标警报 有关详细信息，请参阅 指标警报的建议规则。 |
将 Monitor 警报与 Azure Stack HCI 集成，无需额外付费即可获得多项关键优势。 获取准实时监视并自定义警报，以通知正确的团队或管理员进行修正。 可以在 Azure Stack HCI 中收集计算、存储和网络资源的综合指标列表。 对日志数据执行高级逻辑操作，并定期评估 Azure Stack HCI 系统的指标。 |
| 使用更新功能在一个位置集成和管理 Azure Stack HCI 解决方案的各个方面。 有关详细信息，请参阅 关于 Azure Stack HCI 中的更新。 | 更新业务流程协调程序是在初始 Azure Stack HCI 群集部署期间安装的。 此功能可自动执行更新和管理操作。 若要使 Azure Stack HCI 处于受支持的状态，请确保定期更新群集，以便在可用时移动到新的基线生成。 此方法为平台提供新功能和改进。 有关发布训练、更新节奏以及每个基线生成的支持窗口的详细信息，请参阅 Azure Stack HCI 版本 23H2 版本信息。 |
| 若要帮助掌握技能、实验室、培训事件、产品演示或概念证明项目，请考虑使用 Jumpstart HCIBox。 使用 Azure 上的 VM 部署解决方案，无需物理硬件即可快速部署 Azure Stack HCI。 | HCIBox 支持 Azure Stack HCI 版本 23H2，以便快速测试和评估 Azure Edge 产品的最新功能，例如本机 Azure Arc 和 AKS 集成在独立沙盒中。 可以使用支持嵌套虚拟化的 VM 将此沙盒部署到 Azure 订阅，以模拟 Azure VM 中的 Azure Stack HCI 群集。 以最少的手动工作量获取 Azure Stack HCI 功能，例如新的 云部署功能 。 有关详细信息，请参阅 Microsoft技术社区博客。 |
性能效率
性能效率与保持用户体验有关 ，即使通过管理容量增加负载 也是如此。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则提供了一种高级设计策略，用于针对预期使用情况实现这些容量目标。
设计清单
根据 性能效率的设计评审清单启动设计策略。 定义基于 Azure Stack HCI 的关键指示器的基线。
（Azure Stack HCI 平台体系结构） 使用 OEM 合作伙伴产品/服务中经 Azure Stack HCI 验证的硬件 或集成系统。 请考虑使用 Azure Stack HCI 目录中的高级解决方案生成器来优化 Azure Stack HCI 环境的性能。
（Azure Stack HCI 平台存储体系结构）根据工作负荷性能和容量要求，为 Azure Stack HCI 群集节点选择正确的物理磁盘类型。 对于需要低延迟和高吞吐量存储的高性能工作负荷，请考虑使用全闪存（仅 NVMe/SSD）存储配置。 对于常规用途计算或大型存储容量要求，请考虑使用混合存储（SSD 或 NVMe 用于缓存层，将 HDD 用于容量层），这可能会增加存储容量。
（Azure Stack HCI 平台体系结构） 在群集设计（部署前）阶段使用 Azure Stack HCI 大小器工具。 应使用工作负荷容量、性能和复原能力要求作为输入来适当调整 Azure Stack HCI 群集的大小。 大小确定可以同时脱机（群集仲裁）的最大物理节点数，例如任何计划内（维护）或计划外（电源或硬件故障）事件。 有关详细信息，请参阅 群集仲裁概述。
（Azure Stack HCI 平台体系结构） 对于具有高性能或低延迟要求的工作负荷，请使用基于全闪存（NVMe 或 SSD）的解决方案。 这些工作负载包括但不限于高度事务性数据库技术、生产 AKS 群集或任何任务关键型或业务关键型工作负荷，以及低延迟或高吞吐量存储要求。 使用全闪存部署最大程度地提高存储性能。 所有 NVMe 或全 SSD 配置（尤其是在非常小规模）可提高存储效率和最大化性能，因为没有驱动器用作缓存层。 有关详细信息，请参阅 基于全闪存的存储。
（Azure Stack HCI 平台体系结构） 在部署生产工作负荷之前，为 Azure Stack HCI 群集存储 建立性能基线。 使用 Insights 配置 Monitor Azure Stack HCI 功能，以同时监视单个 Azure Stack HCI 群集或多个群集的性能。
（Azure Stack HCI 平台体系结构） 为 Azure Stack HCI 群集启用 Insights 后，请考虑使用 Monitor for Resilient File System （ReFS） 重复数据删除和压缩功能 。 根据工作负荷存储使用情况和容量要求确定是否应使用此功能。 此功能提供对 ReFS 重复数据删除和压缩节省、性能影响和作业的监视。 有关详细信息，请参阅 监视 ReFS 重复数据删除和压缩。
作为最低要求，计划在整个群集中保留
1 x physical nodes (N+1)有价值的容量，以确保通过更新管理执行更新时可以清空群集节点。 考虑保留2 physical nodes (N+2)业务关键型或任务关键型用例容量的节点工作。
建议
| 建议 | 好处 |
|---|---|
| 如果在 Azure Stack HCI 群集部署期间选择“仅创建基础结构卷”的高级选项，我们建议在为性能密集型工作负荷创建工作负荷卷时使用镜像来创建虚拟磁盘。 | 此建议有利于具有严格延迟要求的工作负荷，或者需要高吞吐量的工作负荷，以及每秒随机读取和写入输入/输出操作（例如 SQL Server 数据库、Kubernetes 群集或其他性能敏感型 VM）的组合。 在使用镜像的卷上部署工作负荷 VHD，以最大程度地提高性能和复原能力。 镜像的速度比任何其他复原类型都快。 |
| 请考虑使用 DiskSpd 测试 Azure Stack HCI 群集的工作负荷存储性能 功能。 还可以使用 VMFleet 生成负载并测量存储子系统的性能。 评估是否应使用 VMFleet 来测量存储子系统性能。 |
在部署生产工作负荷之前，为 Azure Stack HCI 群集性能建立基线。 DiskSpd 允许管理员使用各种命令行参数测试群集的存储性能。 DiskSpd 的主要功能是发出读取和写入操作以及输出性能指标，例如延迟、吞吐量和 IOP。 |
权衡
有设计权衡与支柱清单中所述的方法。 下面是一些优点和缺点示例。
构建冗余会增加成本
在为 Azure Stack HCI 解决方案设计和采购硬件时，请提前了解工作负荷的要求，例如工作负荷 RTO 和 RPO 目标和存储性能要求（IOP 和吞吐量）。 若要部署高度可用的工作负荷，建议至少使用三节点群集，以便对工作负荷卷和数据进行三向镜像。 对于计算资源，请确保部署至少“N+1 个物理节点数”，这将 随时保留群集中“单节点空间”的容量。 对于业务关键型或任务关键型工作负荷，请考虑保留“N+2 节点的容量”，以提供更高的复原能力。 例如，如果群集中的两个节点处于脱机状态，则工作负荷可以保持联机状态。 此方法为方案提供了更高的复原能力，例如，如果在计划的更新过程中运行工作负荷的节点脱机（导致两个节点同时脱机）。
对于业务关键型或任务关键型工作负荷，我们建议部署两个或多个独立的 Azure Stack HCI 群集，并在单独的群集中部署工作负荷服务的多个实例。 使用利用数据复制和应用程序负载均衡技术的工作负荷设计模式。 例如， SQL Server Always-on 可用性组 使用同步或异步数据库复制跨不同数据中心的单独群集实现较低的 RTO 和 RTO 目标。
因此，工作负荷复原能力的增加和 RTO 和 RPO 目标的减少会增加成本，并且需要精心构建的应用程序和操作严谨性。
在没有有效工作负荷规划的情况下提供可伸缩性会增加成本
如果过度预配硬件，则不正确的群集大小可能导致容量不足或降低投资回报（ROI）。 这两种方案都会影响成本。
增加的容量等于更高的成本。 在 Azure Stack HCI 群集设计阶段，需要充分规划，以便 根据工作负荷容量要求对群集节点 的功能和数量进行适当规划。 因此，除了预计的增长外，还必须了解工作负荷要求（vCPU、内存、存储和 X 个 VM 数量），并允许增加一些 额外空间 。 使用“存储切换”设计时，可以执行添加节点手势。 但在部署后可能需要很长时间才能获取更多硬件。 添加笔记手势比在初始部署期间适当调整群集硬件大小和节点数（最大 16 个节点）要复杂得多。
如果过度预配节点硬件规范并选择不正确的节点数（群集大小），则存在缺点。 例如，如果工作负荷要求比群集的总体容量小得多，并且硬件在整个硬件保修期内未使用，则 ROI 值可能会降低。
Azure 策略
Azure 提供了一组与 Azure Stack HCI 及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下情况：
- 主机和 VM 网络应受到保护。
- 应实现加密卷。
- 应始终强制实施应用程序控制策略。
- 应满足安全核心要求。
查看 Azure Stack HCI 内置策略。 Defender for Cloud 提供了 显示内置策略符合性状态的新建议 。 有关详细信息，请参阅Azure 安全中心的内置策略。
如果工作负荷在部署在 Azure Stack HCI 上的 Azure Arc VM 上运行，请考虑使用内置策略，例如拒绝创建或修改扩展安全更新许可证。 有关详细信息，请参阅 已启用 Azure Arc 的工作负荷的内置策略定义。
请考虑创建自定义策略，为在 Azure Stack HCI 群集上部署的 Azure Stack HCI 资源和 Azure Arc VM 提供额外的治理。 例如：
- 使用 Azure 审核 Azure Stack HCI 主机注册
- 确保主机运行最新的 OS 版本
- 检查所需的硬件组件和网络配置
- 验证启用必要的 Azure 服务和安全设置
- 确认安装所需的扩展
- 评估 Kubernetes 群集和 AKS 集成的部署
Azure 顾问建议
Azure 顾问是个性化的云顾问程序，可帮助遵循最佳做法来优化 Azure 部署。 下面是一些建议，可帮助你提高 VM 的可靠性、安全性、成本效益、性能和卓越运营能力。
后续步骤
将 Azure 体系结构中心中的以下文章视为演示本文中突出显示的建议的资源。
- 演示主要建议的基础体系结构： Azure Stack HCI 基线参考体系结构。
- 如果你的组织需要混合方法，请仔细选择与混合网络体系结构相关的设计选择。 有关详细信息，请参阅 混合体系结构设计。
使用以下 Azure Stack HCI 产品文档构建实施专业知识：
查看云采用框架指南：
云采用框架就绪方法指导客户在为云采用做好准备时的环境。 该方法包括 Azure 登陆区域等技术加速器，它们是任何 Azure 云采用环境的构建基块。 请查看以下文章，详细了解如何为混合云准备环境。