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

Azure SQL 托管实例的高可用性

  • 项目

适用于：Azure SQL 托管实例

本文介绍 Azure SQL 托管实例中的高可用性。

重要

“常规用途”服务层级的区域冗余配置在公共预览版提供，而“业务关键”服务层级的区域冗余配置通常都是可用的。

概述

Azure SQL 托管实例中高可用性体系结构的目标是最大程度地减少客户发起的管理操作（这些操作会导致短暂停机、服务维护操作和计划外中断）对客户工作负载的影响。 有关不同服务层的特定 SLA 的详细信息，请查看 Azure SQL 托管实例。

高可用性可保护你免受以下情况的影响：

  • 构成数据中心的可用性区域（存在多区域地区的情况下）
  • 为服务提供支持之节点所运行的机架
  • 节点本身
  • 应用层

为了最大程度地减少区域范围或更大范围的中断所造成的影响，可使用业务连续性概述中所述的可用技术。

SQL 托管实例在 Windows 操作系统上稳定的最新版 SQL Server 数据库引擎上运行，其中包含所有适用的修补程序。 SQL 托管实例会自动处理关键的维护任务（例如修补、备份、Windows 和 SQL 引擎升级），以及底层硬件故障、软件故障或网络故障等计划外事件。 实例得到修补或进行故障转移时，如果在应用中使用重试逻辑，则停机通常不会产生影响。 即使出现最严重的问题，SQL 托管实例也能快速恢复，确保数据始终可用。 大多数用户不会注意到升级是持续执行的。

高可用性解决方案旨在确保提交的数据永远不会由于故障而丢失，维护操作不会影响工作负荷，且实例不会成为软件体系结构中的单一故障点。

有两种不同的基于服务层级的高可用性体系结构模型：

  • “远程存储模型”基于常规用途和下一代常规用途服务层级中的计算和存储隔离，该模型依赖于远程存储的高可用性和可靠性以及由 Azure Service Fabric 管理的计算群集的高可用性。 此高可用性模型面向可以容忍在维护活动期间出现一定程度的性能下降的预算导向型业务应用程序。
  • 基于数据库引擎进程群集的本地存储模型，该模型依赖于“业务关键”服务层级中具有本地存储的可用数据库引擎节点的仲裁。 此本地存储模型面向具有较高事务处理率且需要较高 IO 性能的任务关键型应用程序。 此高可用性体系结构保证维护活动期间尽量减小对工作负载性能造成的影响。

本地冗余可用性

本地冗余可用性基于将计算节点和数据存储在主要区域的单个数据中心内，并在发生本地故障（例如小规模网络或电源故障）时保护数据。 如果区域内发生火灾或洪水等大规模灾难，则存储帐户的所有副本或计算节点上的数据可能会丢失或无法恢复。 因此，为了在使用本地冗余可用性选项时进一步保护数据，请考虑为数据库备份使用更具弹性的存储选项。

“常规用途”服务层级

常规用途服务层级使用远程存储可用性体系结构。 下图显示了具有隔离的计算和存储层的四个不同节点。

显示计算和存储分离的示意图。

远程存储可用性模型包括两个层：

  • 无状态计算层：运行数据库引擎进程，仅包含暂时性的缓存数据，例如在附加的 SSD 上的 tempdb 和 model 数据库，内存中的计划缓存、缓冲池和列存储池。 此无状态节点由 Azure Service Fabric 运行。后者会初始化数据库引擎、控制节点运行状况，并根据需要执行到另一节点的故障转移。
  • 有状态数据层，包含存储在 Azure Blob 存储中的数据库文件（.mdf 和 .ldf）。 Azure Blob 存储具有内置的数据可用性和冗余功能。 本地冗余可用性基于将数据存储在本地冗余存储 (LRS) 中，该存储在主要区域的单个数据中心内复制数据三次。 它可以保证即使数据库引擎进程崩溃，日志文件中的每条记录或者数据文件中的页面也仍会得到保留。

每当升级数据库引擎或操作系统，或者检测到故障时，Azure Service Fabric 会将无状态数据库引擎进程移到具有足够可用容量的另一个无状态计算节点。 Azure Blob 存储中的数据不受移动操作的影响，数据/日志文件将附加到新初始化的数据库引擎进程。 此过程保证高可用性，但在过渡期间，繁重工作负载的性能可能会有一定程度的下降，因为新的数据库引擎进程是使用冷缓存启动的。

下一代常规用途服务层级

注意

下一代常规用途服务层级升级目前为预览版。

下一代常规用途是现有常规用途服务层级的体系结构升级，其使用经升级的远程存储层来将实例数据和日志文件存储到托管磁盘，而非页 Blob 上。

“业务关键”服务层级

业务关键型服务层级利用本地存储可用性模型，该模型与单个节点上的计算资源（数据库引擎进程）和存储（本地附加的 SSD）相集成。 实现高可用性的方式是将计算和存储资源复制到其他节点。

数据库引擎节点群集的示意图。

底层数据库文件 (.mdf/.ldf) 放在附加的 SSD 存储中，以便为工作负荷提供延迟极低的 IO。 高可用性是使用类似于 SQL Server Always On 可用性组的技术来实现的。 群集包含可供读/写客户工作负载访问的单个主要副本，最多包含三个次要副本（计算和存储），这些副本包含数据的副本。 主要副本不断地将更改按顺序推送到次要副本，在提交每个事务之前，它可确保数据保留到足够数量的次要副本上。 此过程可以保证，当主要副本或可读次要副本因任何原因不可用时，始终可以故障转移到某个完全同步的副本。 故障转移由 Azure Service Fabric 启动。 次要副本成为新的主要副本后，将创建另一个次要副本，以确保群集具有足够数量的副本来维护仲裁。 故障转移完成后，Azure SQL 连接会根据连接字符串自动重定向到新的主要副本（或可读次要副本）。

作为一项额外的优势，本地存储可用性模型提供用于将只读 Azure SQL 连接重定向到某个次要副本的功能。 此功能称为读取扩展。它通过主要副本免费提供 100% 的额外计算容量，以减轻分析工作负荷等只读操作的负担。

区域冗余可用性

区域冗余可用性是基于在主要区域中将数据节点和存储副本放置在三个 Azure 可用性区域上。 每个可用性区域都是一个独立的物理位置，具有独立的电源、冷却系统和网络。

默认情况下，将在同一数据中心创建本地存储可用性模型的节点群集。 引入 Azure 可用性区域后，SQL 托管实例可以将业务关键实例的不同副本放置到同一区域的不同可用性区域中。 同样，将“常规用途”服务层级的无状态计算节点放置在不同的可用性区域中，而有状态存储则使用区域冗余存储 (ZRS) 配置。

若要消除单一故障点，还要将控件环跨区域地复制为三个网关环 (GW)。 到特定网关环的路由受 Azure 流量管理器 (ATM) 控制。 通过选择区域冗余配置，“业务关键”或“常规用途”实例能够应对范围要广得多的故障（包括灾难性的数据中心服务中断），且不会对应用程序逻辑进行任何更改。 此外，还可将任何现有“业务关键”或“常规用途”实例转换为区域冗余配置。

由于区域冗余实例的副本位于不同的数据中心，且相互之间有一定的距离，因此增加的网络延迟可能会延长事务提交时间，从而影响某些 OLTP 工作负载的性能。 始终可以通过禁用区域冗余设置返回到单个区域配置。 此过程是一种联机操作，类似于常规的服务层级目标升级。 在此进程结束时，该实例将从区域冗余环迁移到单个区域环，反之亦然。

下图演示了高可用性体系结构的区域冗余版本：

区域冗余高可用性体系结构示意图。

使用区域冗余时，请注意以下几点：

  • 区域冗余不适用于下一代常规用途服务层级。
  • 有关支持区域冗余配置的区域的最新信息，请参阅按区域提供的服务支持。
  • 对于区域冗余可用性，选择维护时段，而不是目前在选择区域中提供的默认设置。

“业务关键”实例支持的区域

以下区域支持“业务关键”SQL 托管实例的区域冗余：

美洲 欧洲 中东 非洲 亚太区
巴西南部 法国中部 卡塔尔中部 南非北部 澳大利亚东部
加拿大中部 意大利北部 以色列中部 印度中部
美国中部 德国中西部 日本东部
美国东部 挪威东部 韩国中部
美国东部 2 北欧 东南亚
美国中南部 英国南部 东亚
美国西部 2 瑞典中部
美国西部 3 瑞士北部
波兰中部

“常规用途”实例支持的区域

注意

“常规用途”服务层的区域冗余配置在预览版种提供。

美洲 欧洲 中东 非洲 亚太区
巴西南部 法国中部 卡塔尔中部 南非北部 澳大利亚东部
美国东部 意大利北部 以色列中部 印度中部
美国东部 2 德国中西部 日本东部
美国中南部 挪威东部 韩国中部
美国西部 2 北欧 东南亚
美国西部 3 英国南部 东亚
瑞典中部
瑞士北部
波兰中部

测试应用程序的故障复原能力

高可用性是 SQL 托管实例平台的基本功能，其运作对数据库应用程序透明。 不过，我们认识到，你可能需要先测试在计划内或计划外事件期间启动的自动故障转移操作对应用程序的具体影响，然后才会将其部署到生产环境。 可以通过调用特殊的 API 来重启托管实例，从而手动触发故障转移。 在使用区域冗余实例的情况下，API 调用会导致将客户端连接重定向到与旧主节点的可用性区域不同的可用性区域中的新主节点。 因此，除了测试故障转移对现有数据库会话的影响外，还可以验证它是否会由于网络延迟的变化而改变了端到端性能。 由于重启操作会干扰系统，其数量过多可能会对平台造成压力，因此每个托管实例每 15 分钟只允许进行一次故障转移调用。

可以使用 PowerShell、REST API 或 Azure CLI 启动故障转移：

PowerShell REST API Azure CLI
Invoke-AzSqlInstanceFailover SQL 托管实例 - 故障转移 az sql mi failover 可用于从 Azure CLI 调用 REST API 调用

结论

Azure SQL 托管实例提供与 Azure 平台深度集成的内置高可用性解决方案。 该服务依赖于使用 Service Fabric 来执行故障检测和恢复，依赖于 Azure Blob 存储来实现数据保护，并依赖于可用性区域来提高容错能力。 对于“业务关键”服务层级，SQL 托管实例使用 SQL Server 的 Always On 可用性组技术来执行数据库复制和故障转移。 将这些技术相结合，应用程序可完全实现混合存储模型的优势并支持最严格的 SLA。

后续步骤