Azure 本地体系结构最佳做法

（Azure 本地平台体系结构和工作负荷体系结构） 定义工作负荷可靠性目标。

• 设置 服务级别目标（SLO），以便评估可用性目标。 以百分比（例如 99.9%、99.95%或 99.995%）计算 SLO，以反映工作负荷正常运行时间。 请记住，此计算不仅仅基于 Azure 本地实例或工作负荷发出的平台指标。 若要获取全面的目标度量，请考虑量化的细微差别因素，例如发布期间的预期停机时间、例行操作、支持性或其他特定于工作负荷或组织的因素。

• Microsoft提供的服务级别协议（SLA）通常会影响 SLO 计算。 但是，Microsoft不会为 Azure 本地实例或已部署的工作负荷的运行时间和连接提供 SLA，因为Microsoft不会控制客户数据中心的可靠性（例如电源和冷却）或管理平台的人员和流程。

（Azure 本地平台体系结构） 考虑性能和作如何影响可靠性。

实例或其依赖项的性能下降会使 Azure 本地平台不可用。 例如：

• 如果没有适当的工作负荷容量规划，在设计阶段 对 Azure 本地实例进行权限化 具有挑战性，这是一项要求，使工作负荷能够达到所需的可靠性目标。 在实例设计过程中使用 Azure 本地尺寸调整工具。 如果需要高度可用的 VM，请考虑“计算机数的 N+1 最低要求”。 对于业务关键型或任务关键型工作负载，如果复原能力至关重要，请考虑将实例大小设置为“N+2 台机器”。

• 平台的可靠性取决于关键平台依赖项（如物理磁盘类型）的性能。 必须根据要求选择正确的磁盘类型。 对于需要低延迟和高吞吐量存储的工作负荷，我们建议使用全闪存（仅 NVMe/SSD）存储配置。 对于常规用途计算，混合存储（用于缓存的 NVMe 或 SSD 和容量 HDD）配置可能会提供更多的存储空间。 但权衡的是，如果工作负荷超过 缓存工作集，旋转磁盘的性能会明显降低，并且 HDD 与 NVMe/SSD 相比，故障值之间的平均时间 要低得多。

  性能效率 更详细地描述了这些示例。

不当的 Azure 本地操作 可能会影响修补和升级、测试和部署的一致性。 下面是一些示例：

• 如果 Azure 本地平台未 随最新的硬件原始设备制造商（OEM）固件、驱动程序和创新而发展，则平台可能无法利用最新的复原功能。 定期应用硬件 OEM 驱动程序和固件更新。 有关详细信息，请参阅 Azure 本地解决方案目录。

• 在部署之前，必须测试目标环境的连接、硬件和标识和访问管理。 否则，可以将 Azure 本地解决方案部署到不稳定的环境，这可能会造成可靠性问题。 即使在实例硬件可用之前，也可以在 独立模式下使用环境检查器工具 来检测问题。

  有关操作指南，请参阅 卓越运营。

（Azure 本地平台体系结构） 为实例及其基础结构依赖项提供容错。

• 存储设计选择。 对于大多数部署来说，默认选项“自动创建工作负载和基础设施卷”就足够了。 如果选择高级选项：“仅创建所需的基础结构卷”，请根据工作负荷要求在存储空间直通中配置适当的卷容错能力。 这些决策会影响卷的性能、容量和复原能力。 例如，三向镜像提高了具有三台或更多台计算机的实例的可靠性和性能。 有关更多信息，请参阅存储效率的容错和创建存储空间直通虚拟磁盘和卷。

• 网络体系结构。 使用 经过验证的网络拓扑 部署 Azure 本地。 具有四台或更多物理计算机的多台计算机实例需要“存储切换”设计。 具有两台或三台计算机的实例可以选择使用“无存储开关”设计。 无论实例大小如何，我们都建议使用双架顶 (ToR) 交换机进行管理和计算意图（南北上行链路），以提供更高的容错能力。 双 ToR 拓扑在交换机维护（固件更新）期间也提供冗余能力。 有关详细信息，请参阅 已验证的网络拓扑。

（工作负荷体系结构） 生成冗余以提供复原能力。

• 请考虑在单个 Azure 本地实例上部署的工作负荷，作为 本地冗余部署。 该实例在平台级别提供高可用性，但必须记住将实例部署在“单个机架中”。 因此，对于业务关键型或任务关键型用例，我们建议跨两个或多个独立的 Azure 本地实例（理想情况下在单独的物理位置）部署工作负荷或服务的多个实例。

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

  有关详细信息，请参阅 跨多个 Azure 本地实例部署工作负荷实例。

（工作负荷体系结构）根据工作负荷恢复点目标（RPO）和恢复时间目标（RTO）目标 规划和测试可恢复性 。

有 一个记录良好的灾难恢复计划。 定期测试恢复步骤，以确保业务连续性计划和流程有效。 确定 Azure Site Recovery 是否是保护 Azure 本地上运行的 VM 的可行选择。 有关详细信息，请参阅 在 Azure Local（预览版）上使用 Azure Site Recovery 保护 VM 工作负载。

（工作负荷体系结构） 配置并定期测试工作负荷备份和还原过程。

数据恢复和保留的业务要求驱动工作负荷备份的策略。 全面的策略需要考虑工作负荷操作系统（OS）和应用程序持久性数据的因素，并具有恢复单个（时间点）文件级和文件夹级数据的能力。 根据数据恢复和符合性要求配置备份保留策略，以确定可用数据恢复点的数量和期限。 探索 Azure Backup 作为为 Azure Local 启用主机级或 VM 来宾级备份的选项。 在相关的情况下审查来自备份独立软件供应商合作伙伴的数据保护解决方案。 有关详细信息，请参阅 Azure 备份指南和最佳做法 以及 适用于 Azure 本地的 Azure 备份。

（Azure 本地平台体系结构） 查看安全基线。 Azure 本地和安全标准 提供基线指导，以加强平台和托管工作负载的安全态势。 如果你的工作负载需要遵守特定的法规合规性法规，请考虑法规安全标准，例如支付卡行业数据安全标准和联邦信息处理标准 140。

Azure 本地平台提供的默认设置 支持安全功能，包括标识控制、网络筛选和加密。 这些设置构成了新预配的 Azure 本地实例的良好安全基线。 可以根据组织安全要求自定义每个设置。

确保 检测并防范意外的安全配置偏移。

（Azure 本地平台体系结构） 检测、预防和响应威胁。 持续监视 Azure 本地环境，并防范现有和不断演变的威胁。

建议在本地 Azure 上启用 Defender for Cloud。 使用 Defender Cloud 安全状况管理监视和识别保护 Azure 本地平台以及其他 Azure 和 Azure Arc 资源所要采取的步骤，启用基本的 Defender for Cloud 计划（免费层）。

为了受益于增强的安全功能，包括单个服务器和 Azure Arc VM 的安全警报，请在 Azure 本地实例计算机和 Azure Arc VM 上启用 Microsoft Defender for Servers。

• 使用 Defender for Cloud 衡量 Azure 本地计算机和工作负荷的安全状况。 Defender for Cloud 提供单一平台体验来帮助管理安全合规性。

• 使用 Defender for Servers 监视托管 VM 的威胁和配置错误。 还可以在 Azure 本地计算机上启用终结点检测和响应功能。

• 请考虑将所有源的安全和威胁情报数据聚合到集中式安全信息和事件管理（SIEM）解决方案，例如 Microsoft Sentinel。

（Azure 本地平台体系结构和工作负荷体系结构） 创建分段以包含爆炸半径。 有几种策略可以实现分段。

• 标识。 使平台和工作负载的角色和职责保持独立。 仅允许授权身份执行与其指定角色相符的特定操作。 Azure 本地平台管理员同时使用 Azure 和本地域凭据来执行平台职责。 工作负载运营人员和应用程序开发人员管理工作负载的安全性。 若要简化委派权限，请使用 Azure 本地内置基于角色的访问控制（RBAC） 角色，例如平台管理员的“Azure 本地管理员”和工作负荷作员的“Azure 本地 VM 参与者”或“Azure 本地 VM 读取者”。 有关特定内置角色 作的详细信息，请参阅 适用于混合角色和多云角色的 Azure RBAC 文档。

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

• 查看 构建分段策略的建议 以获取更多信息。

（Azure 本地平台体系结构和工作负荷体系结构） 使用受信任的标识提供者来控制访问。 我们建议使用 Microsoft Entra ID 进行所有身份验证和授权。 如果需要，可以将工作负荷加入本地 Windows Server Active Directory 域。 利用支持强密码、多重身份验证、RBAC 和机密管理控制的功能。

（Azure 本地平台体系结构和工作负荷体系结构） 隔离、筛选和阻止网络流量。 你可能有一个工作负荷用例，该用例需要通过网络安全组、网络服务质量策略或虚拟设备链接进行微分段，以便可以引入合作伙伴设备进行筛选。 如果有此类工作负荷，请参阅 网络参考模式的软件定义网络注意事项 ，了解 网络控制器 提供的受支持特性和功能的列表。

（工作负荷体系结构） 加密数据以防止篡改。 加密传输中的数据、静态数据以及正在使用的数据。

• 在部署期间创建的数据卷上启用了静态数据加密。 这些数据卷包括基础结构卷和工作负荷卷。 有关详细信息，请参阅 管理 BitLocker 加密。

• 使用 Azure Arc VM 的受信任启动 功能，通过使用新式作系统（例如安全启动）的 OS 功能来提高第 2 代 VM 的安全性，这些作系统可以使用虚拟受信任的平台模块。

实施机密管理。 根据组织要求，更改与 Azure 本地部署用户标识关联的凭据。 有关详细信息，请参阅 “管理机密轮换”。

（Azure 本地平台体系结构） 强制实施安全控制。 使用 Azure Policy 审核和强制实施内置策略，例如“应一致地强制实施应用程序控制策略”或“应实现加密卷”。 可以使用这些 Azure 策略来审核安全设置，并评估 Azure 本地的符合性状态。 有关可用策略的示例，请参阅 Azure 策略。

（工作负荷体系结构） 使用内置策略改进工作负荷安全态势。 若要评估在 Azure 本地上运行的 Azure Arc VM，可以通过安全基准、Azure 更新管理器或 Azure Policy 来宾配置扩展应用内置策略。 可以使用各种策略来检查以下条件：

• Log Analytics 代理安装
• 过时的系统更新需要更新为最新的安全补丁
• 漏洞评估和潜在缓解措施
• 使用安全通信协议

（Azure 本地平台体系结构和工作负荷体系结构） 估算实际成本，作为成本建模的一部分。 使用 Azure 定价计算器 选择和配置 Azure 本地、Azure Arc 和 AKS 等服务。 试验各种配置和支付选项来建模成本。

（Azure 本地平台体系结构和工作负荷体系结构） 优化 Azure 本地硬件的成本。 选择符合业务和商业要求的硬件 OEM 合作伙伴。 若要浏览已验证的计算机、集成系统和顶级解决方案的认证列表，请参阅 Azure 本地解决方案目录。 与硬件合作伙伴沟通你的工作负载特征、大小、数量和性能，以便可以为 Azure 本地环境和实例大小优化经济高效的硬件解决方案。

（Azure 本地平台体系结构） 优化许可成本。 Azure 本地软件根据“每个物理 CPU 核心”进行许可和计费。 将现有的本地核心许可证与 Azure 混合权益 配合使用，以降低 Azure 本地工作负荷的许可成本，例如运行 Windows Server、SQL Server 或 AKS 和已启用 Azure Arc 的 Azure SQL 托管实例的 Azure Arc VM。 有关详细信息，请参阅 Azure 混合权益成本计算器。

（Azure 本地平台体系结构） 节省环境成本。 评估以下选项是否有助于优化资源使用情况。

• 利用微软提供的折扣计划。 请考虑使用 Azure 混合权益来降低运行 Azure 本地和 Windows Server 工作负荷的成本。 有关详细信息，请参阅 Azure 本地的 Azure 混合权益。

• 浏览促销产品/服务。 在注册后利用 Azure 本地 60 天免费试用版，以初步证明概念或验证。

（Azure 本地平台体系结构） 节省运营成本。

• 评估用于修补、更新和其他作的技术选项。 对于已启用 Azure 混合权益和 Azure Arc VM 管理的 Azure 本地实例，更新管理器是免费的。 有关详细信息，请参阅 更新管理器常见问题解答 和 更新管理器定价。

• 评估与可观测性相关的成本。 设置警报规则和数据收集规则（DCR），以满足监视和审核需求。 工作负荷引入、处理和保留的数据量直接影响成本。 使用智能保留策略进行优化、限制警报的数量和频率，以及选择用于存储日志的正确存储层。 有关详细信息，请参阅 Log Analytics 的成本优化指南。

（工作负荷体系结构） 优先评估密度而非隔离。 使用 Azure 本地上的 AKS 来提高密度并简化工作负荷管理，使容器化应用程序能够跨多个数据中心或边缘位置进行缩放。 有关详细信息，请参阅 Azure 本地定价上的 AKS。

（Azure 本地平台体系结构） 提高 Azure 本地的支持性。 部署时默认启用可观测性。 这些功能可增强平台的可支持性。 使用默认安装在所有 Azure 本地计算机上的 AzureEdgeTelemetryAndDiagnostics 扩展，从平台安全地共享遥测和诊断信息。 有关详细信息，请参阅 Azure 本地可观测性。

（Azure 本地平台体系结构） 使用 Azure 服务减少运营复杂性并提高管理规模。 Azure Local 与 Azure 集成，用于启用更新管理器等服务来修补平台，Azure Monitor 用于监视和警报。 可以使用 Azure Arc 和 Azure Policy 来管理安全配置和合规性审核。 实现 Defender for Cloud 以帮助管理网络威胁和漏洞。 将 Azure 用作这些作过程和过程的控制平面，以帮助降低复杂性、提高规模效率并提高管理一致性。

（工作负荷体系结构） 提前规划工作负载的 IP 地址网络范围要求。 Azure Local 提供了一个平台，用于部署和管理虚拟化或容器化工作负荷。 另请考虑工作负荷使用的逻辑网络的 IP 地址要求。 查看以下资源：

• Azure 本地（平台）网络参考体系结构和 IP 要求

• 部署在 Azure 本地上的工作负荷需要 逻辑网络。 有关特定示例，请参阅 AKS 群集的网络要求、 适用于 Azure Arc VM 的逻辑网络以及 具有 Azure 本地的虚拟桌面。

（工作负荷配置） 为 Azure 本地部署的工作负荷启用监视和警报。 可以使用 适用于虚拟机的 Azure Monitor 或 适用于 Arc VM 的 VM 见解，也可以使用 容器见解和托管 Prometheus AKS 群集。

评估是否应该使用集中式 Log Analytics 工作区来处理工作负荷。 有关共享日志接收器（数据位置）的示例，请参阅 工作负荷管理和监视建议。

（Azure 本地平台体系结构） 使用适当的验证技术进行安全部署。 在部署 Azure 本地解决方案之前，在 独立模式下使用环境检查器工具 评估目标环境的就绪情况。 此工具验证所需的连接、硬件、Windows Server Active Directory、网络和 Azure Arc 集成先决条件的正确配置。

（Azure 本地平台体系结构） 获取最新状态并保持最新状态。 使用 Azure 本地解决方案目录 随时了解 Azure 本地实例部署的最新硬件 OEM 创新。 请考虑使用高级解决方案从额外的集成、统包式部署功能和简化的更新体验中受益。

使用更新管理器更新平台并管理 OS、核心代理和服务，包括解决方案扩展。 保持最新状态，并考虑尽可能对扩展使用“启用自动升级”设置。

（Azure 本地平台体系结构）使用 OEM 合作伙伴产品/服务中的 Azure 本地验证硬件 或集成系统。 请考虑使用 Azure 本地目录中 的高级解决方案生成器来优化 Azure 本地环境的性能。

（Azure 本地平台存储体系结构）根据工作负荷性能和容量要求 ，为 Azure 本地计算机选择正确的物理磁盘类型 。 对于需要低延迟和高吞吐量存储的高性能工作负荷，请考虑使用全闪存（仅 NVMe/SSD）存储配置。 对于常规用途计算或大型存储容量要求，请考虑使用混合存储（SSD 或 NVMe 用于缓存层，将 HDD 用于容量层），这可能会增加存储容量。

（Azure 本地平台体系结构）在实例设计阶段（部署前）使用 Azure 本地尺寸工具。 应使用工作负荷容量、性能和复原要求作为输入来适当调整 Azure 本地实例的大小。 该大小决定了可以同时离线的物理机的最大数量（群集仲裁），例如任何计划内（维护）或计划外（电源或硬件故障）事件。 有关详细信息，请参阅群集 Quorum 概述。

（Azure 本地平台体系结构） 对于具有高性能或低延迟要求的工作负荷，请使用基于全闪存（NVMe 或 SSD）的解决方案。 这些工作负载包括但不限于高度事务性数据库技术、生产 AKS 群集或任何任务关键型或业务关键型工作负荷，以及低延迟或高吞吐量存储要求。 使用全闪存部署最大程度地提高存储性能。 All-NVMe 或全 SSD 配置（尤其是在非常小规模）可提高存储效率和最大化性能，因为没有驱动器用作缓存层。 有关详细信息，请参阅 基于全闪存的存储。

（Azure 本地平台体系结构）在部署生产工作负荷之前 ，为 Azure 本地实例存储建立性能基线 。 使用 Insights 配置 Monitor Azure 本地功能，以同时监视单个 Azure 本地实例或多个实例的性能。

（Azure 本地平台体系结构）为 Azure 本地实例启用 Insights 后， 请考虑使用 Monitor for Resilient File System （ReFS） 重复数据删除和压缩功能 。 根据工作负荷存储使用情况和容量要求确定是否应使用此功能。 此功能提供对 ReFS 重复数据删除、压缩的节省效果、性能影响和作业的监视。 有关详细信息，请参阅监控 ReFS 重复数据删除和压缩。

作为最低要求，计划在实例中保留 1 x physical machines (N+1) 的容量，以确保实例机器在通过更新管理执行更新时可以被耗尽。 考虑为业务关键型或任务关键型用例保留 2 physical machines (N+2) 台机器的工作容量。