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

通过本地和区域冗余的可用性 - Azure SQL 托管实例

适用于： Azure SQL 托管实例

• Azure SQL 数据库
• Azure SQL 托管实例

本文介绍通过本地冗余实现可用性的 Azure SQL 托管实例体系结构，以及通过区域冗余实现的高可用性。

重要

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

概述

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

默认情况下，Azure SQL 托管实例通过本地冗余实现可用性，使实例在以下情况下可用：

• 导致短暂停机的客户启动的管理操作
• 服务维护操作
• 与以下对象相关的问题与数据中心中断：
  • 为服务提供支持的计算机运行所在的机架
  • 托管运行 SQL 数据库引擎的 VM 的物理计算机
  • 运行 SQL 数据库引擎的虚拟机
• SQL 数据库引擎的其他问题
• 其他潜在的计划外本地中断

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

但是，若要在发生整个区域中断时尽量减少对数据的影响，可以通过启用区域冗余来实现高可用性。 如果没有区域冗余，故障转移将发生在同一本地数据中心内，这可能会导致实例在中断解决得到之前不可用 - 恢复的唯一方法是通过灾难恢复解决方案（例如通过故障转移组）或异地冗余备份的异地还原。 要了解详细信息，请查看业务连续性概述。

高可用性通过保护你免受对以下情况的影响来提高服务的可靠性：

• 形成数据中心的可用性区域

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

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

有关不同服务层的特定 SLA 的详细信息，请查看 Azure SQL 托管实例的 SLA。

通过本地冗余实现可用性

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

“常规用途”服务层级

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

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

• 无状态计算层：运行数据库引擎进程，仅包含暂时性的缓存数据，例如在附加的 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 托管实例会将不同副本放置到同一区域的不同可用性区域中。 若要消除单一故障点，还要跨多个区域复制控制环。 然后，控制平面流量将路由到跨可用性区域部署的负载均衡器。 从控制平面流向负载均衡器的流量由 Azure 流量管理器 (ATM) 控制。

通过使用区域冗余配置，“业务关键”或“常规用途”实例能够应对范围要广得多的故障（包括灾难性的数据中心服务中断），且不会对应用程序逻辑进行任何更改。 可将任何现有“业务关键”或“常规用途”实例转换为区域冗余配置。

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

若要开始使用 SQL 托管实例的区域冗余，请查看“配置区域冗余”。

“常规用途”服务层级

在“常规用途”服务层级中，通过将无状态计算节点放置在不同的可用性区域中来实现区域冗余，然后区域冗余依赖于附加到当前包含活动 SQL 数据库引擎进程的节点的有状态区域冗余存储 (ZRS)。 发生中断时，SQL 数据库引擎进程在一个无状态节点上处于活动状态，然后访问有状态存储中的数据。

下图演示了“常规用途”服务层级的区域冗余体系结构：

注意

区域冗余当前位于“常规用途”服务层级预览版中。

“业务关键”服务层级

在业务关键服务层级中，通过将计算和存储副本放置在不同的可用性区域中，然后使用基础 Always On 可用性组技术将数据更改从主实例复制到其他可用性区域中的备用副本来实现区域冗余。 发生中断时，会自动故障转移，将其中一个备用副本无缝转换为主副本。

下图演示了业务关键服务层的区域冗余体系结构：

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

可用性是 SQL 托管实例平台的基本功能，其运作对数据库应用程序透明。 不过，我们认识到，你可能需要先测试在计划内或计划外事件期间启动的自动故障转移操作对应用程序的具体影响，然后才会将其部署到生产环境。 可以通过调用特殊的 API 来重启托管实例，从而手动触发故障转移。 由于重启操作会干扰系统，其数量过多可能会对平台造成压力，因此每个托管实例每 15 分钟只允许进行一次故障转移调用。

在真正的故障转移期间，与实例的连接会失败，而 SQL 服务在不同的节点上成为主服务。 若要模拟故障转移，请调用重启 SQL 进程的命令以模拟启动服务的过程，就好像发生了故障转移一样。 但是，与模拟故障转移相比，连接在真正的故障转移期间可能会失败更长的时间，因为在真正的故障转移期间，SQL 进程将成为群集中另一个虚拟机上的主进程（可在本地进行，如果启用了区域冗余则在另一个区域中进行），在模拟故障转移期间，SQL 进程将在现有虚拟机上重启。

本部分中的手动故障转移命令在本地冗余和区域冗余配置中的行为方式相同 - 它仅在本地重启 SQL 进程，并且不会启动到另一个节点的故障转移。 此本地故障转移与针对故障转移组发生的故障转移不同。

可以使用 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。

后续步骤

• 为 Azure SQL 托管实例启用区域冗余。
• 了解 Azure 可用性区域
• 了解 Service Fabric
• 了解 Azure 流量管理器
• 了解如何在 SQL 托管实例上发起手动故障转移
• 有关高可用性和灾难恢复的更多选项，请参阅业务连续性