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

可靠性建议

Azure 顾问可帮助确保并提高业务关键应用程序的连续性。 可以在顾问仪表板的“可靠性”选项卡上获取可靠性建议。

  1. 登录到 Azure 门户

  2. 在任意页面中搜索并选择顾问

  3. 顾问仪表板中,选择“可靠性”选项卡。

AgFood 平台

升级到最新的 ADMA DotNet SDK 版本

我们发现了对已计划弃用的 ADMA DotNet SDK 版本的调用。 为确保不间断地访问 ADMA、最新功能并改进性能,建议切换到最新的 SDK 版本。

潜在优势:确保对 ADMA 的访问不间断

有关详细信息,请参阅什么是 Azure Data Manager for Agriculture?

升级到最新的 ADMA Java SDK 版本

我们发现了对已计划弃用的 ADMA Java Sdk 版本的调用。 我们建议切换到最新的 Sdk 版本,以确保不间断地访问 ADMA、最新功能和性能改进。

潜在优势:确保对 ADMA 的访问不间断

有关详细信息,请参阅什么是 Azure Data Manager for Agriculture?

升级到最新的 ADMA Python SDK 版本

我们发现了对已计划弃用的 ADMA Python SDK 版本的调用。 为确保不间断地访问 ADMA、最新功能并改进性能,建议切换到最新的 SDK 版本。

潜在优势:确保对 ADMA 的访问不间断

有关详细信息,请参阅什么是 Azure Data Manager for Agriculture?

升级到最新的 ADMA JavaScript SDK 版本

我们发现了对已计划弃用的 ADMA JavaScript SDK 版本的调用。 为确保不间断地访问 ADMA、最新功能并改进性能,建议切换到最新的 SDK 版本

潜在优势:确保对 ADMA 的访问不间断

有关详细信息,请参阅什么是 Azure Data Manager for Agriculture?

API 管理

将API 管理服务迁移到 stv2 平台

对托管在 stv1 平台上的 API 管理实例的支持将于2024 年 8 月 31 日停用。 先迁移到基于 stv2 的平台,以避免服务中断。

潜在优势:提高服务稳定性并利用新的平台功能

有关详细信息,请参阅 API 管理 stv1 平台停用 - 全球 Azure 云(2024 年 8 月)

主机名证书轮换失败

API 管理服务无法从 Key Vault 刷新主机名证书,这可能会导致使用过时证书的服务和运行时 API 流量遭到阻止。 确保 Key Vault 中存在证书且 API 管理服务标识具有机密读取访问权限。

潜在优势:确保服务可用性

有关详细信息,请参阅为 Azure API 管理实例配置自定义域名

旧门户已在 3 年前被弃用,于 2023 年 10 月停用。 但我们看到该门户的使用非常活跃,当我们禁用它后,可能会导致服务中断。

强烈建议你尽快迁移到新的开发人员门户,以继续享受我们的服务,并利用新功能和改进。

潜在优势:确保业务连续性

有关详细信息,请参阅迁移到新的开发人员门户

依赖项网络状态检查失败

Azure API 管理服务依赖项不可用。 请检查虚拟网络配置。

潜在优势:提高服务稳定性

有关详细信息,请参阅将 Azure API 管理实例部署到虚拟网络 - 外部模式

SSL/TLS 重新协商受阻

SSL/TLS 重新协商尝试被阻止;安全通信可能失败。 若要支持客户端证书身份验证方案,请对列出的主机名启用“协商客户端证书”。 对于基于浏览器的客户端,此选项可能会导致向客户端显示证书提示。

潜在优势:确保服务可用性

有关详细信息,请参阅如何在 API 管理中使用客户端证书身份验证确保 API 安全

将 Azure API Management 实例部署到多个 Azure 区域以享更高的服务可用性

Azure API Management 支持多区域部署,这样,API 发布者能够将区域 API 网关添加到一个现有的 API Management 实例。 跨区域部署有助于减少分布在不同地理区域的 API 使用者所感知到的请求延迟,并且还能改善服务可用性。

潜在优势:提高对区域故障的复原能力

有关详细信息,请参阅将 Azure API 管理实例部署到多个 Azure 区域

在生产工作负载上为 API 管理实例启用和配置自动缩放。

生产服务层级中的 API Management 实例可以通过添加和删除单元来扩展。 自动缩放功能可以动态调整 API Management 实例的单元来适应负载的变化,而无需手动干预。

潜在优势:提高可伸缩性和优化成本。

有关详细信息,请参阅自动缩放 Azure API 管理实例

应用程序服务

横向扩展应用程序服务计划以避免 CPU 耗尽

CPU 利用率高可能导致应用程序出现运行时问题。 应用程序在过去几天超过了 90 的 CPU。 为了减少 CPU 使用率并避免运行时问题,请横向扩展应用程序。

潜在优势:使应用保持正常运行

有关详细信息,请参阅 Azure 应用服务最佳做法

检查应用的服务运行状况问题

我们有一个与应用的服务运行状况相关的建议。 打开 Azure 门户,转到应用,单击“诊断并解决”以查看更多详细信息。

潜在优势:使应用保持正常运行

有关详细信息,请参阅 Azure 应用服务最佳做法

修复应用服务资源的备份数据库设置

当应用程序的数据库配置无效时,其备份将失败。 有关详细信息,请参阅应用管理页上的应用程序备份历史记录。

潜在优势:确保业务连续性

有关详细信息,请参阅 Azure 应用服务最佳做法

修复应用服务资源的备份存储设置

当应用程序的存储设置无效时,其备份将失败。 有关详细信息,请参阅应用管理页上的应用程序备份历史记录。

潜在优势:确保业务连续性

有关详细信息,请参阅 Azure 应用服务最佳做法

纵向扩展应用服务计划 SKU 以避免内存问题

包含你的应用程序的应用程序服务计划已超过 85% 内存分配。 内存消耗过高可能导致应用程序出现运行时问题。 找到有问题的应用程序,并将其纵向扩展到具有更多内存资源的更高计划。

潜在优势:使应用保持正常运行

有关详细信息,请参阅 Azure 应用服务最佳做法

横向扩展应用服务计划

请考虑将应用服务计划横向扩展到至少两个实例,以在日常维护期间避免冷启动延迟和服务中断。

潜在优势:优化用户体验和可用性

有关详细信息,请参阅 https://aka.ms/appsvcnuminstances

修复应用程序代码,一个工作进程因未处理的异常而发生故障

应用程序中的工作进程因未处理的异常而发生故障。 若要确定根本原因,请在发生故障时收集内存转储和调用堆栈信息。

潜在优势:使应用保持正常运行且高度可用

有关详细信息,请参阅 https://aka.ms/appsvcproactivecrashmonitoring

将应用服务升级到标准计划以避免请求拒绝

当某应用程序是共享的应用程序服务计划的一部分并多次达到其配额时,可能会拒绝传入请求。 Web 应用程序在达到配额后无法接受传入请求。 若要去除配额,请升级到标准计划。

潜在优势:使应用保持正常运行

有关详细信息,请参阅 Azure 应用服务计划概述

将应用服务资源移到标准或更高层级并使用部署槽

当一周内多次部署应用程序时,可能会出现问题。 你上周多次部署了应用程序。 为了帮助减少对生产 Web 应用程序的部署影响,请将应用服务资源移动到标准(或更高)计划,并使用部署槽位。

潜在优势:在更新时使应用保持正常运行

有关详细信息,请参阅在 Azure 应用服务中设置暂存环境

请考虑将此订阅中的 Static Web App(s) 托管计划升级到标准 SKU。

此订阅中所有免费 SKU Static Web Apps 使用的组合带宽超出了每月 100GB 的限制。 请考虑将这些应用程序升级到标准 SKU 以避免限制。

潜在优势:通过避免限制提高应用的可用性。

有关详细信息,请参阅定价 - Static Web Apps

对应用服务资源使用部署槽

当一周内多次部署应用程序时,可能会出现问题。 你在过去一周内多次部署了应用程序。 为了帮助管理更改并帮助减少对生产 Web 应用程序的部署影响,请使用部署槽位。

潜在优势:在更新时使应用保持正常运行

有关详细信息,请参阅在 Azure 应用服务中设置暂存环境

考虑将应用程序体系结构更改为 64 位

应用程序服务配置为 32 位,其内存消耗量接近 2 GB 的限制。 如果应用程序支持,请考虑重新编译应用程序并将应用服务配置改为 64 位。

潜在优势:提高应用程序的可靠性

有关详细信息,请参阅 Azure 中 Web 应用的应用程序性能常见问题解答

CX Observer 个性化建议

CX Observer 个性化建议

潜在优势:NA

应用服务证书

颁发应用程序服务证书需要域验证

你的应用程序服务证书目前处于待签发状态,需要域验证。 未能验证域名所有权将导致证书签发失败。 应用程序服务证书的域名验证不是自动进行的,需要进行操作。 如果最近验证了域所有权并已颁发证书,则可以忽略此消息。

潜在优势:确保成功颁发应用服务证书。

有关详细信息,请参阅在 Azure 应用服务中添加和管理 TLS/SSL 证书

应用程序网关

升级 SKU 或添加更多实例

部署两个或更多中型或大型实例将在计划内或计划外维护导致服务中断时确保业务连续性(容错)。

潜在优势:通过应用程序网关复原确保业务连续性

有关详细信息,请参阅多区域负载均衡 - Azure 参考体系结构

避免替代主机名以确保站点的完整性

在配置应用程序网关时,避免替代主机名。 如果在应用程序网关前端使用的域不同于访问后端所使用的域,则可能会导致 Cookie 或重定向 URL 损坏。 确保后端能够应对域差异或更新应用程序网关配置,以便不需要在后端替代主机名。 在配合应用服务一起使用时,请将自定义域名附加到 Web 应用,并避免在后端使用 *.azurewebsites.net 主机名。 请注意,在所有情况下,不同的前端域不是问题,某些类别的后端(如 REST API)通常不太敏感。

潜在优势:通过可复原的应用程序网关配置,确保站点完整性并避免 cookie 或重定向 URL 被破坏。

有关详细信息,请参阅排查应用程序网关中的应用服务问题

在网络性能监视器上实施 ExpressRoute 监视器

当 ExpressRoute 线路未由 ExpressRoute 监视器监视网络性能时,你会错过本地到 Azure 资源以及 Azure 到本地资源的丢失、延迟和性能通知。 对于端到端监视,请对网络性能实施 ExpressRoute 监视。

潜在优势:改善网络中的检测时间和缓解时间问题,并通过 ExpressRoute 提供有关网络路径的见解

有关详细信息,请参阅为 ExpressRoute 配置网络性能监视器(已弃用)

在虚拟网络中实现多个 ExpressRoute 线路以确保跨界复原能力

如果 ExpressRoute 网关只关联了一条 ExpressRoute 线路,则可能会出现复原能力问题。 要确保对等互连位置冗余和复原能力,请将一条或以上的额外线路连接到网关。

潜在优势:改进复原能力,以免 ExpressRoute 对等互连位置故障

有关详细信息,请参阅使用 ExpressRoute 设计高可用性

向配置文件再添加至少一个终结点(首选在另一 Azure 区域进行)

如果有一个终结点出现故障,则配置文件需要多个终结点以确保可用性。 我们还建议将终结点置于不同的区域。

潜在优势:通过允许故障转移提高复原能力

有关详细信息,请参阅流量管理器终结点

将配置的终结点添加到“所有(全球)”

对于地理路线规划,流量将路由到定义区域中的终结点。 如果某个区域出现故障,则不会进行预定义的故障转移。 如果某个终结点将区域分组配置为地理配置文件的“所有(世界)”,则可以避免流量黑洞,保证服务可用性。

潜在优势:通过避免流量黑洞提高复原能力

有关详细信息,请参阅添加、禁用、启用、删除或移动终结点

将一个终结点添加或移动到另一个 Azure 区域

与此邻近配置文件关联的所有终结点都位于同一区域。 尝试连接时,其他区域的用户可能会遇到长时间的延迟。 如果一个区域中的所有终结点都出现故障,则将一个终结点添加或移动到另一个区域会提高邻近路由的整体性能并提供更好的可用性。

潜在优势:通过允许故障转移到另一个区域提高复原能力

有关详细信息,请参阅配置性能流量路由方法

从基本网关移到生产网关 SKU

基本 VPN SKU 用于开发或测试场景。 如果将 VPN 网关用于生产环境,请改为使用生产 SKU,后者具有更多数量的隧道、边界网关协议 (BGP)、双活配置、自定义 IPsec/IKE 策略,以及更高的稳定性和可用性。

潜在优势:更多可用功能和更高的稳定性及可用性

有关详细信息,请参阅关于 VPN 网关配置设置

启用主动-主动网关以确保冗余

在双活配置中,两个 VPN 网关实例都会建立到本地 VPN 设备的站点到站点 (S2S) VPN 隧道。 当一个网关实例上发生计划内维护事件或计划外事件时,流量会自动切换到另一个活动 IPsec 隧道。

潜在优势:通过连接复原确保业务连续性

有关详细信息,请参阅为跨界连接和 VNet 到 VNet 连接设计高可用网关连接

当源组中只有一个源时禁用运行状况探测

如果只有单个源,则 Front Door 始终将流量路由到该源,即使其运行状况探测报告状态不正常。 运行状况探测的状态不会执行任何操作来更改 Front Door 的行为。 在这种情况下,运行状况探测不会带来任何好处。

潜在优势:通过减少不必要的运行状况探测流量来确保服务可用性

有关详细信息,请参阅 Front Door 最佳做法

使用托管 TLS 证书

Front Door 管理 TLS 证书时,可降低运营成本,并帮助避免因忘记续订证书而导致的代价高昂的中断。 Front Door 会自动颁发并轮换托管 TLS 证书。

潜在优势:通过让 Front Door 管理和轮换证书来确保服务可用性

有关详细信息,请参阅 Front Door 最佳做法

使用用于出站连接的 NAT 网关

通过将 NAT 网关用于虚拟网络的出站流量,可防止因源网络地址转换 (SNAT) 端口耗尽导致的连接失败问题。 NAT 网关会动态缩放,为发往 Internet 的流量提供安全连接。

潜在优势:使用 NAT 网关防止出站连接失败

有关详细信息,请参阅用于出站连接的源网络地址转换 (SNAT)

跨可用性区域部署应用程序网关

通过跨可用区部署应用程序网关来实现区域冗余。 区域冗余通过使应用程序网关能够在各种中断中持续运行,从而提高复原能力,即使一个区域受到影响,也可确保连续性,并增强整体可靠性。

潜在优势:使用可用性区域时,应用程序网关的复原能力大大增加。

有关详细信息,请参阅缩放应用程序网关 v2 和 WAF v2

更新应用程序网关用户的 VNet 权限

若要提高安全性并在 Azure 中提供更一致的体验,所有用户都必须通过权限检查才能在虚拟网络中创建或更新应用程序网关。 用户或服务主体所需的最低权限是 Microsoft.Network/virtualNetworks/subnets/join/action。

潜在优势:避免应用程序网关资源的管理中断

有关详细信息,请参阅应用程序网关基础结构配置

在 Front Door 和源上使用同一域名

重写主机头时,请求 Cookie 和 URL 重定向可能会中断。 使用诸如 Azure 应用程序服务等平台时,会话亲和性以及身份验证和授权等功能可能无法正常工作。 请确保验证应用程序是否能正常工作。

潜在优势:通过保留原始主机名来确保应用程序的完整性

有关详细信息,请参阅 Front Door 最佳做法

为 ExpressRoute 实现网站复原能力

为确保最大复原能力,Microsoft 建议在两个对等互连位置连接到两条 ExpressRoute 线路。 最大复原能力旨在增强可用性,并确保关键工作负载具有最高级别的复原能力。

潜在优势:ExpressRoute 中的最大复原能力旨在消除 Microsoft 网络路径中的任何单一故障点。 这是通过跨两个不同的位置提供双 (2) 线路来实现的,以实现 ExpressRoute 中的站点多样性。 最大复原能力旨在增强可用性,并确保关键工作负载具有最高级别的复原能力。

有关详细信息,请参阅设计和构建 Azure ExpressRoute 以实现复原能力

实现区域冗余 ExpressRoute 网关

实现 Azure 可用性区域中的区域冗余虚拟网络网关。 这会提高虚拟网络网关的复原能力、可伸缩性和可用性。

潜在优势:为 ExpressRoute 提供区域性复原和冗余

有关详细信息,请参阅在可用性区域中创建区域冗余虚拟网络网关

确保自动缩放用于提高性能和复原能力

配置应用程序网关时,建议预配自动缩放,进行横向缩减和扩展以响应需求的变化。 这有助于尽可能减少单个组件失败的影响。

潜在优势:提高性能和复原能力。

有关详细信息,请参阅缩放应用程序网关 v2 和 WAF v2

ExpressRoute IP 路由接近指定的限制

ExpressRoute 线路即将达到其 IP 路由限制。 超过这些限制将中断连接。 一旦路由在限制范围内,连接就会还原:定期监视路由计数。 浏览虚拟 WAN RouteMap 以减少播发的 IP 路由。

潜在优势:监视 IP 路由计数可防止连接问题并确保稳定性。

有关详细信息,请参阅虚拟 WAN 常见问题解答

避免将流量管理器放在 Front Door 后面

对于 Front Door,不建议将流量管理器用作来源之一,因为这可能会导致路由问题。 如果你在高可用性体系结构中同时需要这两种服务,请始终将流量管理器放在 Azure Front Door 前面。

潜在优势:提高工作负载复原能力。

有关详细信息,请参阅 Front Door 最佳做法

考虑至少有两个来源

多个来源通过在应用程序的多个实例之间分配流量来支持冗余。 如果一个实例不可用,则其他后端来源仍可接收流量。

潜在优势:提高工作负载复原能力。

有关详细信息,请参阅 Azure Front Door 上的 Azure 架构良好的框架透视

更改名为 GatewaySubnet 的 V1 网关子网,因为它已预留给 VPN/Express Route

由于内部升级失败,2024 年 10 月之后应用程序网关面临删除的风险。 这是因为名为 Gatewaysubnet 的子网,该子网预留给 VPN/ExpressRoute。 要解决此问题,请更改子网或迁移到 V2。 解决问题后等待一天,以使此消息消失

潜在优势:避免应用程序网关 V1 资源的管理中断

有关详细信息,请参阅有关应用程序网关的常见问题解答

更改 V1 网关的子网,因为当前子网包含 NAT 网关

由于内部升级失败,2024 年 10 月之后应用程序网关可能会被删除。 这是因为它缺少专用子网,并且包含 NAT 网关。 要解决此问题,请更改子网、删除 NAT 网关或迁移到 V2。 解决问题后等待一天,以使此消息消失

潜在优势:避免应用程序网关 V1 资源的管理中断

有关详细信息,请参阅有关应用程序网关的常见问题解答

重新激活订阅以取消阻止 V1 网关的内部升级

由于内部升级失败,2024 年 10 月之后应用程序网关面临删除的风险。 这是因为订阅处于非活动状态。 要解决此问题,请激活订阅。 解决问题之后,此消息将在一天后消失。

潜在优势:避免应用程序网关 V1 资源的管理中断

有关详细信息,请参阅重新激活已禁用的 Azure 订阅

适用于容器的应用程序网关

迁移到支持的 AGC 版本

容器应用程序网关的版本是使用预览版预配的,不支持用于生产。 务必使用最新 API 版本来预配新网关。

潜在优势:确保生产工作负载的可支持性和复原能力

有关详细信息,请参阅什么是适用于容器的应用程序网关?

创建标准搜索服务 (2GB)

超过存储配额时,索引操作将停止工作。 即将接近 2 GB 的存储配额。 如果需要更多存储,请创建标准搜索服务或添加额外的分区。

潜在优势:处理更多数据的能力

有关详细信息,请参阅 https://aka.ms/azs/search-limits-quotas-capacity

创建标准搜索服务 (50MB)

超过存储配额时,索引操作将停止工作。 即将超过 50 MB 的存储配额。 若要维护操作,请创建基本或标准搜索服务。

潜在优势:处理更多数据的能力

有关详细信息,请参阅 https://aka.ms/azs/search-limits-quotas-capacity

通过添加更多分区,来避免超出可用存储配额

超过存储配额后,仍可以进行查询,但索引操作将停止工作。 即将超过可用存储配额。 如果需要更多存储,请添加额外的分区。

潜在优势:可以为其他数据编制索引

有关详细信息,请参阅 https://aka.ms/azs/search-limits-quotas-capacity

已启用 Azure Arc 的 Kubernetes

升级到已启用 Azure Arc 的 Kubernetes 最新代理版本

为了获取已启用 Azure Arc 的 Kubernetes 的最佳体验、更卓越的稳定性和新功能,请升级到最新代理版本。

潜在优势:已启用 Arc 的 K8s 最新代理版本

有关详细信息,请参阅升级已启用 Azure Arc 的 Kubernetes 代理

已启用 Azure Arc 的 Kubernetes 配置

将 Microsoft Flux 扩展升级到最新主版本

Microsoft Flux 扩展发布了主版本。 规划在 6 个月内为所有已启用 Azure Arc 的 Kubernetes 和 Azure Kubernetes 服务 (AKS) 群集手动升级到 Microsoft Flux 的最新主要版本,以获取持续支持和新功能。

潜在优势:持续支持和新功能

有关详细信息,请参阅已启用 Azure Arc 的 Kubernetes 群集的可用扩展

即将推出的 Microsoft Flux 扩展的重大变更

Microsoft Flux 扩展经常会接收到安全更新和稳定性更新。 即将推出的更新与 OSS Flux 项目保持一致,将通过删除已弃用的字段来修改 HelmRelease 和 HelmChart API。 为了避免工作负载中断,需要采取必要的操作。

潜在优势:更高的稳定性、安全性和新功能

有关详细信息,请参阅已启用 Azure Arc 的 Kubernetes 群集的可用扩展

将 Microsoft Flux 扩展升级到支持的版本

一个或多个已启用 Azure Arc 的群集和 Azure Kubernetes 群集上的 Microsoft Flux 当前版本不受支持。 要获取安全修补程序、缺陷修复和 Microsoft 支持,请升级到受支持的版本。

潜在优势:获取安全修补程序、bug 修复和 Microsoft 支持

有关详细信息,请参阅已启用 Azure Arc 的 Kubernetes 群集的可用扩展

已启用 Azure Arc 的服务器

升级到最新版的 Azure Connected Machine Agent

Azure Connected Machine Agent 会定期更新 bug 修补程序、稳定性增强功能和新功能。 将代理升级到最新版本,以获得最佳的 Azure Arc 体验。

潜在优势:更高的稳定性和新功能

有关详细信息,请参阅管理和维护 Connected Machine 代理

用于 Redis 的 Azure 缓存

增加碎片内存预留

碎片和内存压力可能会导致可用性事件。 为了帮助减少在高内存压力下运行的缓存故障,请通过“高级设置”选项中提供的 maxfragmentationmemory-reserved 设置,增加针对碎片的内存预留。

潜在优势:在缓存具有高内存碎片时,避免发生可用性事件

有关详细信息,请参阅如何配置 Azure Cache for Redis

为 Cache for Redis 实例配置异地复制以提高应用程序的持久性

异地复制支持缓存数据的灾难恢复,即使发生罕见的广泛区域故障时也能提供有效的防护。 这对于任务关键型应用程序至关重要。 建议为高级 Azure Cache for Redis 实例配置被动异地复制。

潜在优势:异地复制为缓存的数据启用灾难恢复。

有关详细信息,请参阅为高级 Azure Cache for Redis 实例配置被动异地复制

Azure Container Apps

重新创建容器应用环境以避免 DNS 问题

容器应用环境可能存在网络问题,进而导致 DNS 问题。 我们建议你创建新的容器应用环境,在新的环境中重新创建容器应用,并删除旧的容器应用环境。

潜在优势:避免容器应用环境中出现 DNS 故障。

有关详细信息,请参阅快速入门:使用 Azure 门户部署你的第一个应用程序

续订自定义域证书

你上传的自定义域证书即将过期。 为了防止可能出现的服务中断,请续订证书并为容器应用上传新证书。

潜在优势:服务不会因证书过期而失败。

有关详细信息,请参阅 Azure 容器应用中的自定义域名和自带证书

检测到阻止续订托管证书的问题。

我们已检测到容器应用使用的托管证书无法自动续订。 按照文档链接确保自定义域的 DNS 设置正确。

潜在优势:避免由于证书过期而停机。

有关详细信息,请参阅 Azure 容器应用中的自定义域名和免费托管证书

增加容器化应用的最小副本计数

为 Azure 容器应用容器化应用程序设置的最小副本计数可能太低,这可能导致复原、可伸缩性和负载均衡方面的问题。 请考虑增加该最小副本计数,以提高可用性。

潜在优势:提高容器应用的可用性。

有关详细信息,请参阅在 Azure 容器应用中设置缩放规则

Azure Cosmos DB

为 Azure Cosmos DB 容器配置分区键

当 Azure Cosmos DB 非分区集合达到其预配的存储配额时,将无法添加数据。 Cosmos DB 的非分区集合正在接近其预配的存储配额。 将这些集合迁移到具有分区键定义的新集合,使服务能够自动横向扩展它们。

潜在优势:可随存储或请求率的增加而无缝缩放容器,不会遇到任何限制

有关详细信息,请参阅 Azure Cosmos DB 中的分区和水平缩放

在代码中使用静态 Cosmos DB 客户端实例并缓存数据库和集合的名称

帐户上的大量元数据操作可能会导致速率限制。 元数据操作具有系统保留的请求单位 (RU) 限制。 通过在代码中使用静态 Cosmos DB 客户端实例并缓存数据库和集合的名称,可避免元数据操作的速率限制。

潜在优势:优化 RU 使用情况并避免速率限制

有关详细信息,请参阅 Azure Cosmos DB 和 .NET SDK v2 的性能提示

检查托管加密密钥的链接 Azure Key Vault

当 Azure Cosmos DB 帐户无法访问其链接的托管加密密钥的 Azure Key Vault 时,可能会发生数据访问和安全问题。 Azure Key Vault 的配置阻止 Cosmos DB 帐户连接到密钥保管库来访问托管加密密钥。 如果你最近执行了密钥轮换,请确保以前的密钥或密钥版本保持启用状态并且可用,直到 Cosmos DB 完成轮换。 可以在 24 小时后禁用以前的密钥或密钥版本,也可以在 Azure Key Vault 审核日志不显示该密钥或密钥版本 Azure Cosmos DB 中的任何活动之后禁用。

潜在优势:更新你的配置以继续使用客户管理的密钥并访问你的数据

有关详细信息,请参阅通过 Azure Key Vault 为 Azure Cosmos DB 帐户配置客户管理的密钥

在 Azure Cosmos DB 容器上配置“一致”索引模式

配置了 Lazy 索引模式的 Azure Cosmos 容器会以异步方式更新,从而提高写入性能,但可能会影响查询新鲜度。 容器配置了 Lazy 索引模式。 如果查询新鲜度很重要,请使用一致索引模式进行即时索引更新。

潜在优势:提高查询结果一致性和可靠性

有关详细信息,请参阅管理 Azure Cosmos DB 中的索引策略

修补程序 - 升级到 2.6.14 版 Async Java SDK v2 或 Java SDK v4

Azure Cosmos DB Async Java SDK v2 版本 2.6.13(及更低版本)中存在一个严重 bug,当全局逻辑序列号 (LSN) 大于“最大整数”值时会导致错误。 在 Azure Cosmos DB 容器的生存期内出现大量事务后,你会看到服务出现此错误。 注意:这是 Async Java SDK v2 的关键修补程序,但我们仍强烈建议你迁移到 Java SDK v4

潜在优势:如果未采取措施,则所有创建、读取、更新和删除操作可能会开始失败,并出现 NumberFormatException

有关详细信息,请参阅 Azure Cosmos DB Async Java SDK for API for NoSQL(旧版):发行说明和资源

Azure Cosmos DB Java SDK v4 版本 4.15 及更低版本中存在一个严重 bug,当全局逻辑序列号 (LSN) 大于“最大整数”值时会导致错误。 在 Azure Cosmos DB 容器的生存期内出现大量事务后,你会看到服务出现这种情况。 通过升级到 Java SDK v4 的当前建议版本来避免此问题

潜在优势:如果未采取措施,则所有创建、读取、更新和删除操作可能会开始失败,并出现 NumberFormatException

有关详细信息,请参阅 Azure Cosmos DB Java SDK v4 for API for NoSQL:发行说明和资源

使用新的 3.6+ 终结点连接到已升级的 Azure Cosmos DB API for MongoDB 帐户

一些应用程序在使用旧的 3.2 终结点(即 [accountname].documents.azure.com)连接到已升级的 Azure Cosmos DB API for MongoDB 帐户。 请使用新终结点 [accountname].mongo.cosmos.azure.com(或主权云、政府云或受限云中的等效终结点)。

潜在优势:利用 Azure Cosmos DB API for MongoDB 版本 3.6+ 中的最新功能

有关详细信息,请参阅 Azure Cosmos DB for MongoDB(4.0 服务器版本):支持的功能和语法

将 Azure Cosmos DB API for MongoDB 帐户升级到 v4.2 以节省查询/存储成本并利用新功能

你的 Azure Cosmos DB API for MongoDB 帐户符合升级到版本 4.2 的条件。 升级到 v4.2 后可利用新存储格式,从而将存储成本最多降低 55%,将查询成本最多降低 45%。 v4.2 还包括许多其他功能,例如多文档事务。

潜在优势:改进了可靠性、查询/存储效率、性能和新功能

有关详细信息,请参阅升级 Azure Cosmos DB for MongoDB 帐户的 API 版本

在 Azure Cosmos DB API for MongoDB 帐户上启用服务器端重试 (SSR)

当帐户引发 TooManyRequests 错误并显示 16500 错误代码时,启用服务器端重试 (SSR) 可以帮助缓解此问题。

潜在优势:阻止限制并提高查询的可靠性和性能

向 Azure Cosmos DB 上的生产工作负载再添加一个区域

Azure Cosmos DB 上的生产工作复制在单个区域中运行可能会具有可用性问题,你的一些 Cosmos DB 帐户似乎就是这种情况。 将它们配置到至少两个 Azure 区域中,提高它们的可用性。 注意:额外的区域将产生额外的成本。

潜在优势:提高生产工作负载的可用性

有关详细信息,请参阅 Azure Cosmos DB for NoSQL 中的高可用性(可靠性)

将旧版 Azure Cosmos DB SDK 升级到最新版本

使用旧版 SDK 的 Azure Cosmos DB 帐户缺少最新修补程序和改进。 Azure Cosmos DB 帐户使用的是旧版本的 SDK。 要获取最新修补程序、性能改进和新功能,请升级到最新版本。

潜在优势:提高可靠性、性能,并提供新功能

有关详细信息,请参阅 Azure Cosmos DB 文档

将过时的 Azure Cosmos DB SDK 升级到最新版本

使用旧版 SDK 的 Azure Cosmos DB 帐户缺少最新修补程序和改进。 Azure Cosmos DB 帐户使用的是过时的 SDK 版本。 建议升级到最新版本,以获取最新修补程序、性能改进和新功能。

潜在优势:提高可靠性、性能,并提供新功能

有关详细信息,请参阅 Azure Cosmos DB 文档

为 Cosmos DB 帐户启用服务托管故障转移

为 Cosmos DB 帐户启用服务托管故障转移,从而确保帐户的高可用性。 出现主要区域中断时,服务托管故障转移会自动将写入区域切换到次要区域。 此举可确保应用程序继续正常运行,而不会出现停机。

潜在优势:Azure 的服务托管故障转移功能通过自动化故障转移过程、减少停机时间和提高复原能力来提高系统可用性。

有关详细信息,请参阅 Azure Cosmos DB for NoSQL 中的高可用性(可靠性)

为生产工作负载启用 HA

许多具有一致工作负载的群集都未启用高可用性 (HA)。 建议从 Azure 门户中的“缩放”页激活 HA,以防在出现意外的节点故障时数据库停机,并符合 SLA 保证的条件。

潜在优势:激活 HA 以避免发生意外节点故障时数据库停机

有关详细信息,请参阅缩放和配置 Azure Cosmos DB for MongoDB vCore 群集

为多区域 Cosmos DB 帐户启用区域冗余

该建议建议为多区域 Cosmos DB 帐户启用区域冗余,以改进高可用性,并在发生区域性服务中断时降低数据丢失的风险。

潜在优势:提高高可用性并降低数据丢失风险

有关详细信息,请参阅 Azure Cosmos DB for NoSQL 中的高可用性(可靠性)

在其他 Azure 区域中至少添加一个数据中心

Azure Managed Instance for Apache Cassandra 群集被指定为生产群集,但目前部署在单个 Azure 区域中。 对于生产群集,建议在其他 Azure 区域中至少添加一个数据中心,以便为灾难恢复场景提供防范。

潜在优势:确保应用程序在灾难恢复时具有另一个区域

有关详细信息,请参阅高可用性和灾难恢复的最佳做法

避免控制平面操作被限速

系统通过资源提供程序发现帐户中存在大量控制平面操作。 如果请求在连续 5 分钟时间内在持续级别超过记录的限制,则可能在 Azure Cosmos DB 资源上遇到请求受限以及失败或不完整的操作。

潜在优势:优化控制平面操作,避免由于速度限制而导致操作失败

有关详细信息,请参阅 Azure Cosmos DB 服务配额

Azure 数据资源管理器

解决虚拟网络问题

由于虚拟网络 (VNet) 问题,服务无法安装或继续。 若要解决此问题,请执行故障排除指南中的步骤。

潜在优势:改进了可靠性、可用性、性能并提供新功能

有关详细信息,请参阅排查虚拟网络中 Azure 数据资源管理器群集的访问、引入和操作问题

为“Microsoft.Kusto/clusters”添加子网委派

如果子网没有被委派,关联的 Azure 服务将无法在其中运行。 子网没有所需的委派。 为“Microsoft.Kusto/clusters”委派子网。

潜在优势:改进了可靠性、可用性、性能并提供新功能

有关详细信息,请参阅什么是子网委派?

Azure Database for MySQL

高可用性 - 向当前没有主键的表添加一个主键。

我们的内部监视系统已发现高可用性备用服务器上存在明显的复制滞后。 此滞后主要是由备用服务器在缺少主键的表上重播中继日志引起的。 若要解决此问题并遵循最佳做法,建议向所有表添加主键。 完成此操作后,继续禁用,然后重新启用高可用性以缓解问题。

潜在优势:通过实施此方法,备用服务器将免受由于任何表上缺少主键而导致的复制严重滞后的不利影响。 此方法有助于减少故障转移时间,最终支持保持业务连续性的目标。

有关详细信息,请参阅排查 Azure Database for MySQL - 灵活服务器中的复制延迟问题

复制 - 向当前没有主键的表添加一个主键

我们的内部监视观测到副本服务器上的复制延迟很大,因为副本服务器正在重播缺少主键的表上的中继日志。 为确保副本服务器能够有效地与主服务器同步并实时更新更改,请将主键添加到主服务器中的表,然后重新创建副本服务器。

潜在优势:通过采用此方法,副本服务器将达到与主服务器紧密同步的状态。

有关详细信息,请参阅排查 Azure Database for MySQL - 灵活服务器中的复制延迟问题

Azure Database for PostgreSQL

删除非活动逻辑复制槽(重要)

由于预写日志 (WAL) 文件保留和快照文件的生成,非活动的逻辑复制槽可能会导致服务器性能下降和服务不可用。 Azure Database for PostgreSQL 灵活服务器可能具有非活动性逻辑复制槽。 这需要立即注意。 删除非活动复制槽,或开始从这些槽中使用更改,以便槽的日志序列号 (LSN) 前进并接近服务器的当前 LSN。

潜在优势:通过删除非活动逻辑复制槽来提高 PostgreSQL 可用性

有关详细信息,请参阅 Azure Database for PostgreSQL - 灵活服务器中的逻辑复制和逻辑解码

删除非活动逻辑复制槽

当 Orcas PostgreSQL 灵活服务器具有非活动的逻辑复制槽时,由于预写日志 (WAL) 文件保留和快照文件的生成,可能导致服务器性能下降和服务不可用。 这需要立即注意。 删除非活动复制槽,或开始从这些槽中使用更改,以便槽的日志序列号 (LSN) 前进并接近服务器的当前 LSN。

潜在优势:通过删除非活动逻辑复制槽来提高 PostgreSQL 可用性

有关详细信息,请参阅逻辑解码

配置地区冗余备份存储

配置 GRS,确保即使遇到故障或灾难,数据库也能达到其可用性和持续性目标。

潜在优势:确保从区域故障或灾难中恢复。

有关详细信息,请参阅 Azure Database for PostgreSQL–灵活服务器中的备份和还原

定义在低峰时段发生的自定义维护窗口

为维护计划指定首选项时,可以选择一周中的某一天,然后选择一个时间范围。 如果未指定,系统将选择服务器区域时间中的晚上 11 点到早上 7 点之间的时间。 选择使用率较低的某天和时间。

潜在优势:配置维护时段可避免在系统高峰期进行维护。

有关详细信息,请参阅 Azure Database for PostgreSQL - 灵活服务器中的计划性维护

Azure IoT 中心

将 Microsoft Edge 设备运行时升级到受支持的 IoT 中心版本

当 Edge 设备使用过时的版本时,可能出现性能下降。 我们建议你升级到 Azure IoT Edge 运行时的最新受支持版本。

潜在优势:使用受支持的 Edge 设备最新版本以确保业务连续性

有关详细信息,请参阅更新 IoT Edge

将设备客户端 SDK 升级到 Iot 中心的受支持版本

当设备使用过时版本的 SDK 时,可能出现性能下降。 部分或所有设备正在使用过时的 SDK。 我们建议你升级到受支持的 SDK 版本。

潜在优势:使用受支持的设备 SDK 来确保业务连续性

有关详细信息,请参阅 Azure IoT 中心 SDK

检测到 IoT 中心潜在设备风暴

当至少两个设备尝试使用相同的设备 ID 凭据连接到 IoT 中心时,就可能发生这种情况。 当第二个设备 (B) 进行连接时,会导致第一个设备 (A) 断开连接。 然后 (A) 尝试再次重新连接,这会导致 (B) 断开连接。

潜在优势:改进设备的连接性

有关详细信息,请参阅了解并解决 Azure IoT 中心错误

将 Device Update for IoT Hub SDK 升级到受支持的版本

当 Device Update for IoT Hub 实例使用过时版本的 SDK 时,它不会获得最新的升级。 要获取最新修补程序、性能改进和新功能,请升级到最新版本的 Device Update for IoT Hub SDK。

潜在优势:使用受支持的 SDK 来确保业务连续性

有关详细信息,请参阅什么是 Device Update for IoT Hub?

添加 IoT Hub 单位或提高 SKU 级别

当 IoT 中心超过每日消息配额时,可能出现操作和成本问题。 若要确保将来的顺利运行,请添加单位或增加 SKU 级别。

潜在优势:IoT 中心可以再次接收消息。

有关详细信息,请参阅了解并解决 Azure IoT 中心错误

Azure Kubernetes 服务 (AKS)

为系统节点池启用自动缩放

为确保即使在高负载期间也能调度系统 Pod,请在系统节点池上启用自动缩放。

潜在优势:为系统节点池启用自动缩放程序可确保已计划系统 Pod 并且群集可以正常工作。

有关详细信息,请参阅在 Azure Kubernetes 服务 (AKS) 中使用群集自动缩放程序

系统节点池中至少有 2 个节点

确保系统节点池至少有 2 个节点,从而确保系统 Pod 的可靠性。 对于单个节点,如果节点或硬件失败,群集可能会出现故障。

潜在优势:拥有 2 个节点可确保针对节点故障的复原能力。

有关详细信息,请参阅在 Azure Kubernetes 服务 (AKS) 中管理系统节点池

创建专用系统节点池

没有专用系统节点池的群集可靠性较低。 建议将系统节点池专用于为关键系统 Pod 提供服务,防止在系统 Pod 与竞争性的用户 Pod 之间造成资源饥饿现象。 在池中使用 CriticalAddonsOnly=true:NoSchedule 污点强制强制实施此行为。

潜在优势:通过防止核心系统 Pod 的资源短缺来确保群集可靠性

有关详细信息,请参阅在 Azure Kubernetes 服务 (AKS) 中管理系统节点池

确保生产环境中不使用 B 系列虚拟机 (VM)

当群集中具有一个或多个使用不推荐的可突发 VM SKU 的节点池时,不保证可 100% 使用全部 vCPU 功能。 确保 B 系列 VM 不在生产环境中使用。

潜在优势:实现一致性能的最佳做法

有关详细信息,请参阅 Bv1 大小系列

Azure NetApp 文件

为 Azure Netapp 文件 AD 连接器配置 AD DS 站点

如果 Azure NetApp 文件无法访问分配的 AD DS 站点域控制器,则域控制器发现流程将查询所有域控制器。 可能使用了无法访问的域控制器,从而导致卷创建、客户端查询、身份验证和 AD 连接修改问题。

潜在优势:使用 Azure Netapp 文件优化 DNS 连接

有关详细信息,请参阅了解适用于 Azure NetApp 文件的 Active Directory 域服务站点设计和规划指南

确保分配给 Microsoft.NetApp 委派子网的角色具有子网读取权限

管理 Azure NetApp 文件资源所需的角色必须在委托给 Microsoft.NetApp 的子网上具有“Microsoft.network/virtualNetworks/subnets/read”权限,如果角色(无论是自定义角色还是内置角色)没有此权限,卷创建将失败

潜在优势:确保子网/读取权限以防止卷创建失败

查看 SAP 配置,了解与 Azure NetApp 文件搭配使用的超时值

在与 Azure NetApp 文件一起使用时,SAP 的高可用性依靠设置适当的超时值来防止应用程序中断。 请查看“了解详情”链接,确保配置符合文档中所述的超时值。

潜在优势:提高 SAP 应用程序在 ANF 上的复原能力

有关详细信息,请参阅使用 Azure 托管和运行 SAP 工作负载方案

实现面向 Azure NetApp 文件资源的灾难恢复策略

要避免发生区域性灾难时数据或功能丢失,请为 Azure NetApp 文件卷实施常见的灾难恢复技术,例如跨区域或跨可用区复制。

潜在优势:使用 Azure NetApp 文件复制功能轻松管理灾难恢复

有关详细信息,请参阅了解 Azure NetApp 文件中的数据保护和灾难恢复选项

Azure Netapp 文件 - 为 SMB 卷启用连续可用性

对于持续可用性,我们建议为 Azure Netapp 文件启用服务器消息块 (SMB) 卷。

潜在优势:通过为 SMB 卷启用持续可用性来防止应用程序中断

有关详细信息,请参阅在现有 SMB 卷上启用连续可用性

Azure Site Recovery

为恢复服务保管库启用软删除

通过软删除,可在删除后将备份数据再保留在恢复服务保管库中一段时间,让你有机会在永久删除之前检索这些数据。

潜在优势:帮助在意外删除时恢复备份数据

有关详细信息,请参阅 Azure 备份的软删除

为恢复服务保管库启用跨区域还原

使用跨区域还原 (CRR),可以还原位于次要区域(Azure 配对区域)的 Azure VM,帮助进行灾难恢复。

潜在优势:作为还原选项之一,跨区域还原 (CRR) 允许你在某个次要区域(Azure 配对区域)中还原 Azure VM。

有关详细信息,请参阅如何在 Azure 门户中还原 Azure VM 数据

Azure Spring Apps

将应用程序配置服务升级到第 2 代

我们注意到,你仍在使用第 1 代应用程序配置服务,后者将于 2024 年 4 月终止支持。 与第 1 代服务相比,第 2 代应用程序配置服务提供更好的性能,从第 1 代服务升级到第 2 代服务无需停机,因此我们建议你尽快升级。

潜在优势:更高的稳定性和可用性。

有关详细信息,请参阅使用 Tanzu 的应用程序配置服务

Azure SQL 数据库

为 SQL 数据库启用跨区域灾难恢复

为 SQL 数据库启用跨区域灾难恢复,以防发生区域中断时确保业务连续性。

潜在优势:启用灾难恢复将为主数据库创建连续同步的可读辅助数据库。

有关详细信息,请参阅使用 Azure SQL 数据库确保业务连续性的概览

为 Azure SQL 数据库启用区域冗余以实现高可用性和复原能力。

若要实现高可用性和弹性,请为 SQL 数据库或弹性池启用区域冗余以使用可用区,并确保数据库或弹性池能够抵御区域故障。

潜在优势:启用区域冗余可确保 Azure SQL 数据库能够从区域性硬件和软件故障中复原,并且恢复对应用程序是透明的。

有关详细信息,请参阅通过冗余实现可用性 - Azure SQL 数据库

Azure Stack HCI

升级到 Arc 启用的 AKS 最新版本

升级到由 Azure Arc 启用的 AKS 的 API/SDK 最新版本,以获得新功能并提高稳定性。

潜在优势:Azure Arc 启用的最新版本的 AKS,包含最新功能和更高的稳定性。

有关详细信息,请参阅 https://azure.github.io/azure-sdk/releases/latest/index.html

升级到 Arc 启用的 AKS 最新版本

升级到由 Azure Arc 启用的 AKS 的 API/SDK 最新版本,以获得新功能并提高稳定性。

潜在优势:Azure Arc 启用的最新版本的 AKS,包含最新功能和更高的稳定性。

有关详细信息,请参阅 https://azure.github.io/azure-sdk/releases/latest/index.html

经典部署模型存储

需要执行的操作:在 2024/8/30 前迁移经典存储帐户。

将经典存储帐户迁移到 Azure 资源管理器以确保业务连续性。 Azure Resource Manager 将提供所有相同的功能以及一致的管理层、资源分组以及对新功能和更新的访问权限。

潜在优势:确保通过迁移经典存储帐户来管理数据的能力

经典部署模型虚拟机

2024 年 8 月 31 日前迁移云服务(经典版)

云服务(经典)即将停用。 为避免数据丢失或业务连续性受损,请在 2024 年 8 月 31 日之前迁移。

潜在优势:服务的连续性

有关详细信息,请参阅将 Azure 云服务(经典)迁移到 Azure 云服务(外延支持)

认知服务

升级应用程序以使用 Azure OpenAI 中的最新 API 版本

具有较旧 API 版本的 Azure OpenAI 资源缺少最新退出的特性和功能。 建议使用最新的 REST API 版本。

潜在优势:我们的新 API 版本包含最新的强大特性和功能。

有关详细信息,请参阅 Azure OpenAI 服务 REST API 参考

此资源已超出配额,请等待或升级以取消阻止

如果资源超出配额,就将受到阻止。 可以等待配额自动快速补充,或者将其升级到付费 SKU,即可马上再次使用资源。

潜在优势:如果升级到付费 SKU,则可以立即再次使用资源。

有关详细信息,请参阅计划和管理 Azure AI Studio 的成本

容器注册表

为关键性的生产工作负载使用高级层

高级注册表附带的存储、并发操作和网络带宽最多,可支持大容量应用场景。 高级层还增加了异地复制、可用性区域支持、内容信任、客户管理的密钥和专用终结点等功能。

潜在优势:高层级提供最高的性能、缩放和复原选项

有关详细信息,请参阅 Azure 容器注册表服务层级

确保启用异地复制以支持复原能力要求

借助异地复制功能,可以让工作负载跨区域使用单个映像、标记和注册表名称,从而提供网络闭环注册表访问能力,减少数据传输成本,并在发生区域性中断时实现区域注册表复原。 此功能仅在高级服务层级中提供。

潜在优势:提高复原能力和拉取性能、简化注册表管理和降低数据传输成本

有关详细信息,请参阅 Azure 容器注册表中的异地复制

内容分发网络

Edgio 的 Azure CDN - 托管证书续订不成功。 需要其他验证。

Edgio 的 Azure CDN 使用 CNAME 委托向 DigiCert 续订证书,以进行托管证书续订。 自定义域必须解析为 azureedge.net 终结点,以便使用 DigiCert 的自动续订过程可以成功。 确保正确配置自定义域的 CNAME 和 CAA 记录。 如果需要进一步帮助,请向 Azure 提交支持案例,以重新尝试续订请求。

潜在优势:确保服务可用性。

续订已到期的 Azure Front Door 客户证书以避免服务中断

当 Azure Front Door 标准版和高级版配置文件的客户证书过期时,可能会出现服务中断。 请在证书过期前续订,以避免服务中断。

潜在优势:确保服务可用性。

有关详细信息,请参阅使用 Azure 门户在 Azure Front Door 自定义域上配置 HTTPS

重新验证 Azure Front Door 托管证书续订的域所有权

Azure Front Door (AFD) 无法自动续订托管证书,因为域不是映射到 AFD 终结点的 CNAME。 对于要自动续订的托管证书,重新验证域所有权。

潜在优势:未定义

有关详细信息,请参阅使用 Azure 门户在 Azure Front Door 上配置自定义域

将 Azure Front Door 客户证书的机密版本切换为“最新”

将 Azure Front Door (AFD) 客户证书机密配置为“最新”,以便 AFD 引用 Azure 密钥保管库中的最新机密版本,从而可以自动轮换机密。

潜在优势:最新版本可以自动轮换。

有关详细信息,请参阅使用 Azure 门户在 Azure Front Door 自定义域上配置 HTTPS

通过将 DNS TXT 记录添加到 DNS 提供程序来验证域所有权

通过将 DNS TXT 记录添加到 DNS 提供程序来验证域所有权。 通过 TXT 记录验证域所有权可以增强安全性,并确保对域进行适当的控制。

潜在优势:确保服务可用性。

有关详细信息,请参阅使用 Azure 门户在 Azure Front Door 上配置自定义域

数据工厂

在 Azure 数据工厂 中实施 BCDR 策略获得跨区域冗余

实施 BCDR 策略可提高数据的高可用性,降低数据丢失风险

潜在优势:提高高可用性并降低数据丢失风险

有关详细信息,请参阅适用于 Azure 数据工厂和 Azure Synapse Analytics 管道的 BCDR - Azure 体系结构中心

在 SHIR 上启用自动升级

自承载集成运行时自动升级已被禁用。 知道你未在获取自承载集成运行时的最新更改和 bug 修复。 检查这些设置以启用 SHIR 自动升级

潜在优势:获取自承载集成运行时的最新更改和 bug 修复

有关详细信息,请参阅自承载集成运行时自动更新和过期通知

Fluid Relay

应升级 Azure Fluid Relay 客户端库

如果使用旧客户端库调用了 Azure Fluid Relay 服务,则可能会导致应用程序问题。 为了确保应用程序保持运行,请将 Azure Fluid Relay 客户端库升级到最新版本。 升级提供了最新功能,并且增强了性能和稳定性。

潜在优势:可靠性提高

有关详细信息,请参阅与 Fluid Framework 发布的版本兼容性

HDInsight

通过删除和重新创建 HDInsight 群集(证书轮换第 2 轮)来应用关键更新

HDInsight 服务已尝试在所有正在运行的群集上应用关键证书更新。 但是,由于某些自定义配置更改,我们无法在你的某些群集上应用更新。 为了防止群集运行不正常和无法使用,请删除并重新创建群集。

潜在优势:确保群集正常运行并保持稳定

有关详细信息,请参阅使用 Apache Hadoop、Apache Spark、Apache Kafka 等在 HDInsight 中设置群集

非 ESP ABFS 群集 [可读 Word 的群集权限]

计划在非 ESP ABFS 群集中引入更改,以限制非 Hadoop 组用户执行 Hadoop 命令以运行存储操作。 此更改可改善群集安全状况。 客户需要在 2023 年 9 月 30 日之前规划更新。

潜在优势:此更改旨在改善群集的安全状况

有关详细信息,请参阅 Azure HDInsight 发行说明

在 Kafka 群集磁盘上重启代理

当 HDInsight 群集中的 Kafka 中转站使用的数据磁盘几乎已满时,Apache Kafka 中转站进程将无法启动并失败。 若要解决此问题,请查找每个主题的保留时间,备份旧文件并重启代理。

潜在优势:避免 Kafka 中转站问题

有关详细信息,请参阅场景:由于磁盘空间已满,代理运行不正常或无法重启

群集名称长度更新

群集名称的最大长度将从 59 个字符更改为 45 个字符,以改善群集的安全状况。 此更改将于 2023 年 9 月 30 日实施。

潜在优势:HDInsight 的安全状况已改进

有关详细信息,请参阅 Azure HDInsight 发行说明

将群集升级到最新的 HDInsight 映像

一年前创建的群集没有最新的映像升级。 群集是在一年前创建的。 作为最佳做法的一部分,我们建议使用最新的 HDInsight 映像,以获取最好的开放源代码更新、Azure 更新和安全修补程序。 在六个月内(建议的最长间隔时间)升级群集。

潜在优势:获取最新的修补程序和功能

有关详细信息,请参阅在开始创建群集之前考虑以下几点。

升级 HDInsight 群集

未使用最新映像的群集没有最新的升级。 你的群集未使用最新映像。 我们建议你使用最新版本的 HDInsight 映像,以获取最好的开放源代码更新、Azure 更新和安全修补程序。 新的 HDInsight 版本每 30 到 60 天发布一次。

潜在优势:获取最新的修补程序和功能

有关详细信息,请参阅 Azure HDInsight 发行说明

无法访问网关或虚拟机

我们检测到网络探测失败,它表示网关或虚拟机无法访问。 验证所有群集主机的可用性。 重启虚拟机以恢复。 如果需要进一步的帮助,请随时联系 Azure 支持以获取帮助。

潜在优势:可靠性提高

VM 代理为 9.9.9.9。 升级群集。

我们的记录表明,你的一个或多个群集正在使用日期为 2022 年 2 月或更早的映像(映像版本 2202xxxxxx 或更早)。 使用 2022 年 2 月或更早版本映像的 HDInsight 群集存在潜在的可靠性问题。请考虑使用最新映像重建群集。

潜在优势:提高了缩放和网络连接的可靠性

媒体服务

增加媒体服务配额或限制

当媒体帐户达到其配额限制时,可能出现服务中断。 若要避免服务中断,请查看资产当前使用情况、内容密钥策略和流策略,并增加接近达到限制的实体的配额限制。 可以通过开具票证并添加相关详细信息来请求提高配额限制。 提示:请不要创建更多的 Azure 媒体帐户来提高配额上限。

潜在优势:避免因客户超出配额限制而导致服务中断。

有关详细信息,请参阅 Azure 媒体服务配额和限制

服务总线

使用服务总线高级层提高复原能力

运行关键应用程序时,服务总线高级层在 CPU 和内存级别提供更好的资源隔离,进而增强可用性。 它还支持异地灾难恢复功能,因此无需更改应用程序配置,即可更轻松地从区域灾难中恢复。

潜在优势:服务总线高层级通过 CPU 和内存资源隔离以及异地灾难恢复提供更好的复原能力

有关详细信息,请参阅服务总线高级消息传送层

使用高级层中的服务总线自动缩放功能来提高复原能力

在运行关键应用程序时,启用自动缩放功能可以让你拥有足够的容量来处理应用程序的负载。 运行适量的资源可以减少限制并提供更好的用户体验。

潜在优势:启用自动缩放可防止用户受到容量限制

有关详细信息,请参阅自动更新 Azure 服务总线命名空间的消息传送单元

Azure 虚拟机中的 SQL Server

为虚拟机上的 SQL 启用 Azure 备份

要实现 SQL AG 集成的零基础结构备份、时间点还原和集中管理等优势,请使用 Azure 备份为虚拟机上的 SQL 数据库启用备份。

潜在优势:SQL 感知的备份、无基础结构备份、集中式管理、AG 集成和时间点还原

有关详细信息,请参阅关于 Azure VM 中的 SQL Server 备份

存储

对达到容量限制的存储帐户使用托管磁盘

当存储帐户中的高级 SSD 非托管磁盘即将达到其高级存储容量限制时,可能会发生故障。 为了避免达到此限制后出现的故障,可迁移到没有帐户容量限制的托管磁盘。 可以在不到 5 分钟的时间内通过门户完成此迁移。

潜在优势:避免帐户达到容量限制后出现缩放问题

有关详细信息,请参阅标准存储帐户的可伸缩性和性能目标

配置 Blob 备份

Azure Blob 备份有助于保护数据免遭意外或恶意删除。 我们建议配置 Blob 备份。

潜在优势:防止意外或恶意删除数据

有关详细信息,请参阅 Azure Blob 备份概览

订阅

启用 Azure 备份,为数据提供简单、可靠且经济高效的保护

通过 Azure 上强大的一键式备份,确保你的信息和应用程序安全。 激活 Azure 备份,为各种工作负荷(包括 VM、SQL 数据库、应用程序和文件共享)提供经济高效的保护。

潜在优势:确保业务关键型应用程序始终受到保护

有关详细信息,请参阅 Azure 备份文档 - Azure 备份

创建 Azure 服务运行状况警报

Azure 服务运行状况警报可让你了解四个方面的问题和公告(服务问题、计划内维护、安全和运行状况公告)。 这些警报经过个性化设置,可通知你中断情况及其对所选 Azure 区域和服务的潜在影响。

潜在优势:随时了解以下四个方面的问题和建议:服务问题、计划内维护、安全建议和运行状况建议

有关详细信息,请参阅使用 Azure 门户创建有关服务通知的活动日志警报

虚拟机

通过使用托管磁盘提高数据可靠性

具有共享存储帐户或存储缩放单元的磁盘的可用性集中的虚拟机在中断期间不可对单个存储规模单元故障进行复原。 迁移到 Azure 托管磁盘以确保可用性集中的不同 VM 的磁盘彼此完全独立,以避免单点故障。

潜在优势:通过连接复原确保业务连续性

有关详细信息,请参阅 https://aka.ms/aa_avset_manageddisk_learnmore

启用虚拟机复制,使应用程序免受区域性服务中断的影响

启用复制到另一个区域后,虚拟机可灵活应对区域性服务中断。 为了减少 Azure 区域中断对业务的不利影响,我们建议为所有业务关键型虚拟机启用复制。

潜在优势:在 Azure 区域中断时确保业务连续性

若要了解详细信息,请参阅快速入门:为 Azure VM 设置到 Azure 次要区域的灾难恢复

将出站连接协议更新为 Azure Site Recovery 的服务标记

通过基于 IP 地址的允许列表来控制防火墙出站连接的方法较为脆弱,一个较好的替代方法是使用服务标记。 我们强烈建议使用服务标记,以允许连接到计算机的 Azure Site Recovery 服务。

潜在优势:确保实现比硬编码 IP 地址更高的安全性、稳定性和复原能力

有关详细信息,请参阅关于 Azure VM 灾难恢复中的网络

将附加到支持高级磁盘的 VM 的标准磁盘升级为高级磁盘

将标准 SSD 磁盘与高级虚拟机配合使用可能会导致性能不佳和延迟问题。 建议考虑将标准磁盘升级为高级磁盘。 对于所有操作系统磁盘和数据磁盘都使用高级存储的单一实例虚拟机,我们保证虚拟机连接率至少达到 99.9%。 选择升级时,需要考虑两个因素。 第一个因素是,升级需要重启虚拟机,此过程需要 3-5 分钟才能完成。 第二个因素是,如果列表中的 VM 是关键的生产 VM,则请对照高级磁盘的成本来评估改善的可用性。

潜在优势:只有在所有磁盘都是高级磁盘的情况下,才会提高可用性 (单一 VM SLA 可用)

有关详细信息,请参阅 Azure 托管磁盘类型

将 VM 从高级非托管磁盘升级到托管磁盘,无需额外付费

Azure 托管磁盘提供更高的复原能力、简化的服务管理、更高的缩放目标,以及更多可选的磁盘类型。 你的虚拟机在使用高级非托管磁盘,这种磁盘可以通过门户在 5 分钟内迁移到托管磁盘,无需额外付费。

潜在优势:利用托管磁盘的更高复原能力和其他优势

有关详细信息,请参阅 Azure 托管磁盘简介

将已弃用的虚拟机映像升级到较新的映像

订阅中的虚拟机 (VM) 在已计划弃用的映像上运行。 弃用映像后,无法从已弃用的映像创建新的 VM。 要防止工作负载中断,请升级到映像的较新版本。 (VMRunningDeprecatedImage)

潜在优势:最大限度地减少对 VM 工作负载的任何潜在中断

有关详细信息,请参阅已弃用的 Azure 市场映像 - Azure 虚拟机

升级到较新的虚拟机映像产品/服务

订阅中的虚拟机 (VM) 在已计划弃用的映像上运行。 弃用映像后,无法从已弃用的映像创建新的 VM。 要防止工作负载中断,请升级到映像的较新版本。 (VMRunningDeprecatedOfferLevelImage)

潜在优势:最大限度地减少对 VM 工作负载的任何潜在中断

有关详细信息,请参阅已弃用的 Azure 市场映像 - Azure 虚拟机

升级到较新的虚拟机映像 SKU

订阅中的虚拟机 (VM) 在已计划弃用的映像上运行。 弃用映像后,无法从已弃用的映像创建新的 VM。 要防止工作负载中断,请升级到映像的较新版本。

潜在优势:最大限度地减少对 VM 工作负载的任何潜在中断

有关详细信息,请参阅已弃用的 Azure 市场映像 - Azure 虚拟机

将虚拟机规模集升级到备用映像版本

订阅中的 VMSS 在已计划弃用的映像上运行。 映像弃用后,虚拟机规模集工作负载将不再横向扩展。升级到映像的较新版本,以防止工作负载中断。

潜在优势:最大限度地减少对虚拟机规模集工作负载的任何潜在中断

有关详细信息,请参阅已弃用的 Azure 市场映像 - Azure 虚拟机

将虚拟机规模集升级到备用映像套餐

订阅中的 VMSS 在已计划弃用的映像上运行。 映像弃用后,虚拟机规模集工作负载将不再横向扩展。为了防止工作负载中断,请升级到映像的较新套餐。

潜在优势:最大限度地减少对虚拟机规模集工作负载的任何潜在中断

有关详细信息,请参阅已弃用的 Azure 市场映像 - Azure 虚拟机

将虚拟机规模集升级到备用映像 SKU

订阅中的 VMSS 在已计划弃用的映像上运行。 映像弃用后,虚拟机规模集工作负载将不再横向扩展。为了防止工作负载中断,请升级到映像的较新 SKU。

潜在优势:最大限度地减少对虚拟机规模集工作负载的任何潜在中断

有关详细信息,请参阅已弃用的 Azure 市场映像 - Azure 虚拟机

向 Azure 虚拟桌面环境提供缺少的必需 URL 访问权限

要正确部署会话主机并将其注册到 Windows 虚拟桌面 (WVD),需要将一组 URL 添加到“允许列表”,以防虚拟机在受限环境中运行。 对于允许列表中缺少的特定 URL,请在应用程序事件日志中搜索事件 3702。

潜在优势:使用 Windows 虚拟桌面服务时,请确保成功部署和运行会话主机功能

有关详细信息,请参阅 Azure 虚拟桌面所需的 FQDN 和终结点

对齐资源和资源组的位置

为了减少区域服务中断的影响,建议将资源并置于资源组所在的同一区域中。 这样,Azure Resource Manager 就可以存储与一个区域中组内所有资源相关的元数据。 通过并置,可以减少受区域不可用影响的可能性。

潜在优势:减少因区域中断而导致的写入失败

有关详细信息,请参阅什么是 Azure 资源管理器?

使用可用性区域提高复原能力和可用性

数据中心发生故障时,Azure 中的可用性区域 (AZ) 可帮助保护应用程序和数据。 每个 AZ 由一个或多个数据中心组成,这些数据中心配置了独立电源、散热设备和网络。 通过设计使用区域性 VM 的解决方案,可以将 VM 与任何其他区域中的故障隔离开来。

潜在优势:使用区域性 VM 可保护应用免受任何其他区域中的区域性中断。

有关详细信息,请参阅将 Azure 单实例 VM 从地区移到区域目标可用性区域

启用 Azure 虚拟机规模集 (VMSS) 应用程序运行状况监视

使用应用程序运行状况扩展或负载均衡器运行状况探测配置虚拟机规模集应用程序运行状况监视后,Azure 平台可以通过响应应用程序运行状况的变化来提高应用程序的复原能力。

潜在优势:通过向 Azure 公开应用程序运行状况来提高复原能力

有关详细信息,请参阅将应用程序运行状况扩展与虚拟机规模集配合使用

在虚拟机上启用备份

为虚拟机启用备份以保护数据。

潜在优势:保护虚拟机

有关详细信息,请参阅什么是 Azure 备份服务?

在 Azure 虚拟机规模集 (VMSS) 上启用自动修复策略

启用自动实例修复有助于通过维护一组正常运行的实例来实现高可用性。 如果应用程序运行状况扩展或负载均衡器运行状况探测发现运行不正常的实例,则自动实例修复会尝试通过触发修复操作来恢复实例。

潜在优势:通过自动修复失败的实例来提高复原能力

有关详细信息,请参阅 Azure 虚拟机规模集的自动实例修复

按指标配置虚拟机规模集自动缩放

使用基于指标的自定义自动缩放优化资源利用率、降低成本并提高应用程序性能。 根据实时指标(例如 CPU、内存和磁盘操作)自动添加虚拟机实例。 确保高可用性,同时保持成本效益。

潜在优势:确保高可用性,同时保持成本效益

有关详细信息,请参阅 Azure 虚拟机规模集的自动缩放概览

将 Azure 磁盘与区域冗余存储 (ZRS) 配合使用,以提高复原能力和可用性

具有 ZRS 的 Azure 磁盘在一个区域中的三个可用性区域中提供数据同步复制,使磁盘能够容忍区域性故障,而不会对应用程序造成中断。 为了获得更高复原能力和可用性,请将磁盘从 LRS 迁移到 ZRS。

潜在优势:通过设计应用程序以使用 ZRS 磁盘,将跨 3 个可用性区域复制数据,使磁盘能够从区域性服务中断中复原

有关详细信息,请参阅将磁盘从 LRS 转换为 ZRS

工作负荷

为多用途 SQL 服务器 (MPSQL) 配置 Always On 可用性组

具有 Always On 可用性组的 MPSQL 服务器具有更好的可用性。 你的 MPSQL 服务器未配置为 Epic 系统中共享基础结构中 AlwaysOn 可用性组的一部分。 Always On 可用性组可提高数据库的可用性并改进资源使用情况。

潜在优势:改进了数据库可用性和资源使用

有关详细信息,请参阅什么是 AlwaysOn 可用性组?

在 Citrix VDI 服务器上配置本地主机缓存以确保无缝连接代理操作

我们观察到,你的 Citrix VDI 服务器未配置本地主机缓存。 本地主机缓存 (LHC) 是 Citrix 虚拟应用和桌面中的一项功能,允许连接代理操作在发生中断时继续。当站点数据库在 90 秒内无法访问时,LHC 就会参与。

潜在优势:无缝连接代理操作

将 Hyperspace Web 服务器部署为为 3 个区域配置的虚拟机规模集 Flex 的一部分

我们发现,你在虚拟机规模集 Flex 设置中的 Hyperspace Web 服务器没有分布在所选 Azure 区域中的 3 个区域。 对于需要高可用性和大规模的服务,如 Epic 系统中的 Hyperspace Web,建议将服务器部署为虚拟机规模集 Flex 的一部分,并分布在 3 个区域。 借助灵活业务流程,Azure 可在整个 Azure VM 生态系统中提供统一的体验

潜在优势:适用于 Epic DB 中的 Hyperspace Web 服务器的高可用性和按需大规模缩放

有关详细信息,请参阅创建使用可用性区域的虚拟机规模集

将 Azure 负载均衡器中的空闲超时设置为 30 分钟,以在 SAP 工作负载中设置 ASCS HA

若要防止负载均衡器超时,请确保所有 Azure 负载均衡规则中的“空闲超时(分钟)”设置为最大值 30 分钟。 打开负载均衡器,选择“负载均衡规则”并添加或编辑规则以启用设置。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 Azure 负载均衡器中启用浮动 IP,以便在 SAP 工作负载中设置 ASCS HA

为进行端口重复使用和实现更好的可用性,在 Azure 负载均衡器的负载均衡规则中启用浮动 IP,以便在 SAP 工作负载中进行 ASCS 实例的 HA 设置。 打开负载均衡器,选择“负载均衡规则”并添加或编辑规则以启用。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 Azure 负载均衡器中启用 HA 端口,以便在 SAP 工作负载中设置 ASCS HA

为进行端口重复使用和实现更好的可用性,在负载均衡规则中启用 HA 端口,以便在 SAP 工作负载中进行 ASCS 实例的 HA 设置。 打开负载均衡器,选择“负载均衡规则”并添加或编辑规则以启用。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在放置于 Azure 负载均衡器之后的 VM 上禁用 TCP 时间戳,以在 SAP 工作负载中设置 ASCS HA

在放置于 Azure 负载均衡器之后的 VM 上禁用 TCP 时间戳 启用 TCP 时间戳会导致运行状况探测因 VM 来宾 OS TCP 堆栈删除 TCP 数据包而失败,从而导致负载均衡器将终结点标记为停止

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 https://launchpad.support.sap.com/#/notes/2382421

将 Azure 负载均衡器中的空闲超时设置为 30 分钟,以在 SAP 工作负载中设置 HANA DB HA

若要防止负载均衡器超时,请确保所有 Azure 负载均衡规则中的“空闲超时(分钟)”参数设置为最大值 30 分钟。 打开负载均衡器,选择“负载均衡规则”并添加或编辑规则以启用建议的设置。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 Azure 负载均衡器中启用浮动 IP,以便在 SAP 工作负载中设置 HANA DB HA

为进行更灵活的路由,在 Azure 负载均衡器的负载均衡规则中启用浮动 IP,以便在 SAP 工作负载中进行 HANA DB 实例的 HA 设置。 打开负载均衡器,选择“负载均衡规则”并添加或编辑规则以启用建议的设置。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 Azure 负载均衡器中启用 HA 端口,以便在 SAP 工作负载中设置 HANA DB HA

为提高可伸缩性,在负载均衡规则中启用 HA 端口,以便在 SAP 工作负载中进行 HANA DB 实例的 HA 设置。 打开负载均衡器,选择“负载均衡规则”并添加或编辑规则以启用建议的设置。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在放置于 Azure 负载均衡器之后的 VM 上禁用 TCP 时间戳,以在 SAP 工作负载中设置 HANA DB HA

在放置于 Azure 负载均衡器之后的 VM 上禁用 TCP 时间戳。 启用 TCP 时间戳会导致运行状况探测因 VM 来宾 OS TCP 堆栈删除 TCP 数据包而失败,从而导致负载均衡器将终结点标记为停止。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Azure 负载均衡器运行状况探测

确保在 SAP 工作负载的 ASCS HA 设置中为 Pacemaker 配置启用 stonith

在 Pacemaker 群集中,使用 STONITH(“爆头”)资源实现节点级别隔离。 为帮助管理失败的节点,确保在 HA 群集配置中将“stonith-enable”设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

将 Pacemaker 群集中的 corosync 令牌设置为 30000,以便在 SAP 工作负载中设置 ASCS HA (RHEL)

corosync 令牌设置确定在 HA 群集中直接使用或作为实际令牌超时计算基础的超时时间。 要允许进行内存保留维护,为 Azure 上的 SAP 将 corosync 令牌设置为 30000。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载的 ASCS HA 设置中,将 Pacemaker 配置中的“预期投票”参数设置为“2”(RHEL)

对于双节点 HA 群集,请按 Azure 上的 SAP 建议将仲裁“expected-votes”参数设置为“2”,以确保适当的仲裁、复原能力和数据一致性。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载 (ConcurrentFencingHAASCSRH) 的 ASCS HA 设置中启用 Pacemaker 配置中的“concurrent-fencing”参数

并发隔离使隔离操作能够并行执行,从而增强高可用性 (HA)、防止脑裂应用场景,并帮助进行可靠的 SAP 部署。 在 ASCS HA 设置的 Pacemaker 群集配置中,将此参数设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

确保在 SAP 工作负载的 ASCS HA 设置中为群集配置启用 stonith

在 Pacemaker 群集中,使用 STONITH(“爆头”)资源实现节点级别隔离。 为帮助管理失败的节点,确保在 HA 群集配置中将“stonith-enable”设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载的 ASCS HA 设置中,将群集配置的 stonith 超时设置为 144

“stonith-timeout”指定群集等待 STONITH 操作完成的时间。 将该时间设置为“144”秒可以有更多的时间来完成隔离操作。 建议为 Azure 上的 SAP 的 HA 群集进行此设置。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

将 Pacemaker 群集中的 corosync 令牌设置为 30000,以便在 SAP 工作负载中设置 ASCS HA (SUSE)

corosync 令牌设置确定在 HA 群集中直接使用或作为实际令牌超时计算基础的超时时间。 要允许进行内存保留维护,为 Azure 上的 SAP 将 corosync 令牌设置为“30000”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载的 ASCS HA 设置中,将 Pacemaker 群集中的“token_retransmits_before_loss_const”设置为 10

corosync token_retransmits_before_loss_const 确定在 HA 群集中的超时之前尝试重新传输的令牌数。 为了获得稳定性和可靠性,请将 ASCS HA 设置的“totem.token_retransmits_before_loss_const”设置为“10”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

“corosync join”超时指定等待成员身份协议中的加入消息的时间,以便在新节点加入群集时,有时间将其状态与现有节点同步。 对于 ASCS HA 设置,在 Pacemaker 群集配置中将其设置为“60”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

将 Pacemaker 群集中的“corosync consensus”设置为“36000”,以便在 SAP 工作负载中设置 ASCS HA

corosync“consensus”参数指定在启动群集配置中的一轮成员身份之前等待达成共识的时间(以毫秒为单位)。 将 ASCS HA 设置的 Pacemaker 群集配置中的“consensus”设置为可靠故障转移行为的 corosync 令牌的 1.2 倍。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

将 Pacemaker 群集中的“corosync max_messages”设置为“20”,以便在 SAP 工作负载中设置 ASCS HA

corosync“max_messages”常量指定一个处理器在接收令牌时可以发送的最大消息数。 将其设置为 Pacemaker 群集配置中的 corosync 令牌参数的 20 倍,以允许高效通信,而不使网络不堪重负。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载的 ASCS HA 设置中的群集配置中将“预期投票数”设置为“2”(SUSE)

对于双节点 HA 群集,请按 Azure 上的 SAP 建议将仲裁“expected_votes”参数设置为 2,以确保适当的仲裁、复原能力和数据一致性。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载的 ASCS HA 设置中,将群集配置中的“two_node”参数设置为 1

对于双节点 HA 群集,请根据 Azure 上的 SAP 建议将仲裁参数“two_node”设置为 1。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 SAP 工作负载中的 Pacemaker ASCS HA 设置中启用“并发隔离”(ConcurrentFencingHAASCSSLE)

并发隔离使隔离操作能够并行执行,从而增强 HA、防止脑裂应用场景,并帮助进行可靠的 SAP 部署。 在 ASCS HA 设置的 Pacemaker 群集配置中,将此参数设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

确保在已启用 HA 的 SAP 工作负载的 Pacemaker 中,“fence_azure_arm”实例数为 1

如果使用 Azure 隔离代理通过托管标识或服务主体进行隔离,请确保 ASCS HA 设置的 Pacemaker 配置中有一个 fence_azure_arm(适用于 Azure Resource Manager 的 I/O 隔离代理)实例,以实现高可用性。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

对于 ASCS HA 设置的 Azure 隔离代理,在 Pacemaker 配置将 stonth-timeout 设置为 900

为了使 ASCS HA 设置的 Pacemaker 功能可靠,请将“stonith-timeout”设置为 900。 此设置适用于通过托管标识或服务主体使用 Azure 隔离代理进行隔离的情况。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 Pacemaker 配置中为 SAP 工作负载中的 ASCS HA 设置创建 softdog 配置文件

softdog 计时器将作为内核模块加载到 linux OS 中。 如果此计时器检测到系统已挂起,则会触发系统重置。 确保在 Pacemaker 群集中为 ASCS HA 设置创建了 softdog 配置文件

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

确保在 SAP 工作负荷中为 ASCS HA 设置中的 Pacemaler 加载 softdog 模块

softdog 计时器将作为内核模块加载到 linux OS 中。 如果此计时器检测到系统已挂起,则会触发系统重置。 首先确保已创建 softdog 配置文件,然后在 AsCS HA 设置的 Pacemaker 配置中加载 softdog 模块

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 HANA DB HA 设置的 Pacemaker 配置中将 PREFER_SITE_TAKEOVER 参数设置为“true”

SAP HANA 中的 PREFER_SITE_TAKEOVER 参数定义了 HANA 系统复制 (SR) 资源代理是否会优先接管辅助实例,而不是在本地重启失败的主实例。 为了使 HANA DB 高可用性 (HA) 设置的功能可靠,请将 PREFER_SITE_TAKEOVER 设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载(用于具有 Redhat OS 的 VM)的群集配置中启用 stonith

在 Pacemaker 群集中,使用 STONITH(“爆头”)资源实现节点级别隔离。 为帮助管理失败的节点,确保在 SAP 工作负载的 HA 群集配置中将“stonith-enable”设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

对于已启用 HA 的 HANA DB(用于具有 RHEL OS 的 VM),将 Pacemaker 群集中的 corosync 令牌设置为 30000

corosync 令牌设置确定在 HA 群集中直接使用或作为实际令牌超时计算基础的超时时间。 若要允许进行内存保留维护,请将 Azure 上具有 Redhat OS 的 SAP 的 corosync 令牌设置为 30000。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载 (RHEL) 中,将预期投票参数设置为“2”

对于双节点 HA 群集,请按 Azure 上的 SAP 建议将仲裁投票设置为“2”,以确保适当的仲裁、复原能力和数据一致性。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

在 Pacemaker 配置中为 HANA DB HA 设置启用“concurrent-fencing”参数

并发隔离使隔离操作能够并行执行,从而增强高可用性 (HA)、防止脑裂应用场景,并帮助进行可靠的 SAP 部署。 在 HANA DB HA 设置的 Pacemaker 群集配置中,将此参数设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 Red Hat Enterprise Linux 上的 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负荷的群集配置中,将参数 PREFER_SITE_TAKEOVER 设置为“true”

SAP HANA 拓扑中的 PREFER_SITE_TAKEOVER 参数定义了 HANA SR 资源代理是否会优先接管辅助实例,而不是在本地重启失败的主实例。 为了确保 HANA DB HA 设置的功能可靠,将其设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载(用于具有 SUSE OS 的 VM)的群集配置中启用 stonith

在 Pacemaker 群集中,使用 STONITH(“爆头”)资源实现节点级别隔离。 为帮助管理失败的节点,确保在 HA 群集配置中将“stonith-enable”设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载中,将群集配置的 stonith 超时设置为 144

“stonith-timeout”指定群集等待 STONITH 操作完成的时间。 将该时间设置为“144”秒可以有更多的时间来完成隔离操作。 建议为 Azure 上的 SAP 的 HA 群集进行此设置。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

对于已启用 HA 的 HANA DB(用于具有 SUSE OS 的 VM),将 Pacemaker 群集中的 corosync 令牌设置为 30000

corosync 令牌设置确定在 HA 群集中直接使用或作为实际令牌超时计算基础的超时时间。 若要允许内存保留维护,对于已启用 HA 的 HANA DB(用于具有 Redhat OS 的 VM),请将 corosync 令牌设置为 30000。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载的 Pacemaker 群集中将“token_retransmits_before_loss_const”设置为 10

corosync token_retransmits_before_loss_const 确定在 HA 群集中的超时之前尝试重新传输的令牌数。 根据 HANA DB HA 设置的建议,将 totem.token_retransmits_before_loss_const 设置为 10。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

对于 SAP 工作负载中已启用 HA 的 HANA DB,将 Pacemaker 群集中的“corosync join”设置为 60

“corosync join”超时指定等待成员身份协议中的加入消息的时间,以便在新节点加入群集时,有时间将其状态与现有节点同步。 对于 HANA DB HA 设置,在 Pacemaker 群集配置中将其设置为“60”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

对于 SAP 工作负荷中已启用 HA 的 HANA DB,请将 Pacemaker 群集中的“corosync consensus”设置为 36000

corosync“consensus”参数指定在启动群集中新一轮成员身份之前等待达成共识的时间(以毫秒为单位)。 要执行可靠的故障转移行为,将 HANA DB HA 设置的 Pacemaker 群集配置中的“consensus”设置为 corosync 令牌的 1.2 倍。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

对于 SAP 工作负载中已启用 HA 的 HANA DB,将 Pacemaker 群集中的“corosync max_messages”设置为 20

corosync“max_messages”常量指定一个处理器在接收令牌时可以发送的最大消息数。 要允许高效通信,而不使网络不堪重负,将其设置为 Pacemaker 群集配置中的 corosync 令牌参数的 20 倍。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载 (SUSE) 中,将预期投票参数设置为 2

在启用了 HA 的 SAP 工作负载的群集配置中,将预期投票参数设置为“2”,以确保适当的仲裁、复原能力和数据一致性。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载的群集配置中,将 two_node 参数设置为 1

对于双节点 HA 群集,请根据 Azure 上的 SAP 建议将仲裁参数“two_node”设置为 1。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在已启用 HA 的 SAP 工作负载的群集配置中启用“concurrent-fencing”参数

并发隔离使隔离操作能够并行执行,从而增强 HA、防止脑裂应用场景,并帮助进行可靠的 SAP 部署。 在启用了 HA 的 SAP 工作负载中,将此参数设置为“true”。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

确保在 HANA DB HA 设置的 Pacemaker 配置中有一个 fence_azure_arm 实例

如果使用 Azure 隔离代理通过托管标识或服务主体进行隔离,请确保 HANA DB HA 设置的 Pacemaker 配置中有一个 fence_azure_arm(适用于 Azure Resource Manager 的 I/O 隔离代理)实例,以实现高可用性。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

在 Pacemaker 配置中使用 Azure 隔离代理将 stonth -timeout 设置为 900,以便进行 HANA DB HA 设置

如果使用 Azure 隔离代理通过托管标识或服务主体进行隔离,请通过将“stonith-timeout”设置为 900,确保 HANA DB HA 设置的 Pacemaker 功能可靠。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

确保 softdog 配置文件在 SAP 工作负载的 HANA DB 的 Pacemaker 配置中

softdog 计时器将作为内核模块加载到 Linux OS 中。 如果此计时器检测到系统已挂起,则会触发系统重置。 确保在 Pacemaker 群集中为 HANA DB HA 设置创建了 softdog 配置文件。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

确保在 SAP 工作负载的 ASCS HA 设置的 Pacemaler 中加载 softdog 模块

softdog 计时器将作为内核模块加载到 Linux OS 中。 如果此计时器检测到系统已挂起,则会触发系统重置。 首先确保已创建 softdog 配置文件,然后在 HANA DB HA 设置的 Pacemaker 配置中加载 softdog 模块。

潜在优势:SAP 工作负载中 HA 设置的可靠性

有关详细信息,请参阅 SUSE Linux Enterprise Server 上 Azure VM 中 SAP HANA 的高可用性

后续步骤

详细了解可靠性 - Microsoft Azure 构架良好的框架