业务关键层 - Azure SQL 数据库Business Critical tier - Azure SQL Database

Note

业务关键层在 DTU 购买模型中称为“高级”。Business Critical tier is called Premium in DTU purchasing model. 有关基于 vCore 购买模型与基于 DTU 购买模型的比较,请参阅 Azure SQL 数据库购买模型和资源For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see Azure SQL Database purchasing models and resources.

Azure SQL 数据库基于 SQL Server 数据库引擎体系结构,该体系结构已根据云环境做出调整,以确保即使在发生基础结构故障时,也仍能提供 99.99% 的可用性。Azure SQL Database is based on SQL Server Database Engine architecture that is adjusted for the cloud environment in order to ensure 99.99% availability even in the cases of infrastructure failures. Azure SQL 数据库中使用了三种体系结构模型:There are three architectural models that are used in Azure SQL Database:

  • 常规用途/标准General Purpose/Standard
  • 业务关键/高级Business Critical/Premium
  • 超大规模Hyperscale

“高级”/“业务关键”服务层级模型基于数据库引擎进程群集。Premium/Business Critical service tier model is based on a cluster of database engine processes. 此体系结构模型依赖于以下事实:即使在执行维护活动期间,也始终存在可用数据库引擎节点的仲裁,并且能尽量减少对工作负荷性能的影响。This architectural model relies on a fact that there is always a quorum of available database engine nodes and has minimal performance impact on your workload even during maintenance activities.

Azure 以透明方式升级和修补底层操作系统、驱动程序和 SQL Server 数据库引擎,同时尽量减少最终用户的停机时间。Azure upgrades and patches underlying operating system, drivers, and SQL Server Database Engine transparently with the minimal down-time for end users.

Azure SQL 数据库的“高级”或“业务关键”服务层级中已启用高级可用性,此功能面向密集型工作负荷,此类工作负荷无法承受由于持续维护操作而造成的任何性能影响。Premium availability is enabled in Premium and Business Critical service tiers of Azure SQL Database and it is designed for intensive workloads that cannot tolerate any performance impact due to the ongoing maintenance operations.

在高级模型中,Azure SQL 数据库在单个节点上集成了计算和存储层。In the premium model, Azure SQL database integrates compute and storage on the single node. 此体系结构模型中的高可用性是通过使用类似于 SQL Server AlwaysOn 可用性组的技术复制部署在四节点集群中的计算(SQL Server 数据库引擎进程)和存储(本地连接的 SSD)来实现的。High availability in this architectural model is achieved by replication of compute (SQL Server Database Engine process) and storage (locally attached SSD) deployed in four node cluster, using technology similar to SQL Server Always On Availability Groups.

数据库引擎节点群集

SQL 数据库引擎进程和底层 mdf/ldf 文件都放置在同一个节点上,该节点在本地附加了 SSD 存储,使工作负荷保持较低的延迟。Both the SQL database engine process and underlying mdf/ldf files are placed on the same node with locally attached SSD storage providing low latency to your workload. 高可用性是使用类似于 SQL Server Always On 可用性组的技术来实现的。High availability is implemented using technology similar to SQL Server Always On Availability Groups. 每个数据库是由数据库节点组成的群集,该群集中的一个主数据库可由客户工作负荷访问,还有三个辅助进程包含数据副本。Every database is a cluster of database nodes with one primary database that is accessible for customer workload, and a three secondary processes containing copies of data. 主节点不断地将更改推送到辅助节点,以确保在主节点出于任何原因崩溃时,可在次要副本上提供数据。The primary node constantly pushes the changes to secondary nodes in order to ensure that the data is available on secondary replicas if the primary node crashes for any reason. 故障转移由 SQL Server 数据库引擎处理 - 一个次要副本成为主节点,并创建新的次要副本来确保群集中有足够的节点。Failover is handled by the SQL Server Database Engine - one secondary replica becomes the primary node and a new secondary replica is created to ensure enough nodes in the cluster. 工作负荷自动重定向到新的主节点。The workload is automatically redirected to the new primary node.

此外,业务关键群集具有内置的读取扩展功能,该功能提供免费的内置只读节点,用于运行不会影响主要工作负荷性能的只读查询(例如报告)。In addition, Business Critical cluster has built-in Read Scale-Out capability that provides free-of charge built-in read-only node that can be used to run read-only queries (for example reports) that should not affect performance of your primary workload.

何时选择此服务层级?When to choose this service tier?

“业务关键”服务层级为具有以下特点的应用程序而设计:需要来自基础 SSD 存储的低延迟响应(平均 1-2 毫秒)、在底层基础设施发生故障时需要快速恢复或是需要将报表、分析和只读查询分流到主数据库的免费可读次要副本。Business Critical service tier is designed for the applications that require low-latency responses from the underlying SSD storage (1-2 ms in average), fast recovery if the underlying infrastructure fails, or need to off-load reports, analytics, and read-only queries to the free of charge readable secondary replica of the primary database.

选择“业务关键”服务层级而不是“常规用途”层级的主要原因包括:The key reasons why you should choose Business Critical service tier instead of General Purpose tier are:

  • 低 IO 延迟要求 - 需要存储层快速做出响应(平均 1-2 毫秒)的工作负荷应使用“业务关键”层级。Low IO latency requirements - workload that needs the fast response from the storage layer (1-2 milliseconds in average) should use Business Critical tier.
  • 应用程序与数据库之间频繁通信。Frequent communication between application and database. 无法利用应用层缓存或请求批处理,并需要发送大量必须得到快速处理的 SQL 查询的应用程序非常适合使用“业务关键”层级。Application that cannot leverage application-layer caching or request batching and need to send many SQL queries that must be quickly processed are good candidates for Business Critical tier.
  • 大量的更新 - 插入、更新和删除操作修改内存中的数据页(脏页),而这些数据必须通过 CHECKPOINT 操作保存到数据文件中。Large number of updates - insert, update, and delete operations modify the data pages in memory (dirty page) that must be saved to data files with CHECKPOINT operation. 潜在的数据库引擎进程崩溃或故障转移包含大量脏页的数据库可能会增大“常规用途”层级中的恢复时间。Potential database engine process crash or a failover of the database with a large number of dirty pages might increase recovery time in General Purpose tier. 如果工作负荷会导致大量的内存中更改,请使用“业务关键”层级。Use Business Critical tier if you have a workload that causes many in-memory changes.
  • 存在修改数据的长时间运行的事务。Long running transactions that modify data. 长时间打开的事务会阻止截断日志文件,这可能会增加日志大小和虚拟日志文件 (VLF) 的数量。Transactions that are opened for a longer time prevent truncation of log file that might increase log size and number of Virtual log files (VLF). 如果存在大量的 VLF,可能会在故障转移后减慢数据库的恢复速度。High number of VLF can slow down recovery of database after failover.
  • 工作负荷包含可重定向到免费辅助只读副本的报告和分析查询。Workload with reporting and analytic queries that can be redirected to the free-of-charge secondary read-only replica.
  • 提高复原能力,并在故障后更快地恢复。Higher resiliency and faster recovery from the failures. 发生系统故障时,主实例上的数据库将被禁用,某个次要副本将立即成为新的读写主数据库,该数据库随时可以处理查询。In a case of system failure, the database on primary instance will be disabled and one of the secondary replicas will be immediately became new read-write primary database that is ready to process the queries. 数据库引擎不需要分析和重做日志文件中的事务,也不需要加载内存缓冲区中的所有数据。Database engine doesn't need to analyze and redo transactions from the log file and load all data in the memory buffer.
  • 高级数据损坏防护 - “业务关键”层级在幕后利用数据库副本来实现业务连续性,因此服务还可以利用自动页面修复,这与 SQL Server 数据库镜像和可用性组使用的技术相同。Advanced data corruption protection - Business Critical tier leverages database replicas behind-the-scenes for business continuity purposes, and so the service also then leverages automatic page repair, which is the same technology used for SQL Server database mirroring and availability groups. 如果副本由于数据完整性问题而无法读取某个页面,将从另一个副本检索该页面的全新副本,并替换不可读的页面,而不会造成数据丢失或客户停机。In the event that a replica cannot read a page due to a data integrity issue, a fresh copy of the page will be retrieved from another replica, replacing the unreadable page without data loss or customer downtime. 如果数据库具有异地次要副本,则此功能在“常规用途”层级中适用。This functionality is applicable in General Purpose tier if the database has geo-secondary replica.
  • 更高的可用性 - 采用多 AZ 配置的“业务关键”层级保证 99.995% 的可用性,相比之下,“常规用途”层级保证 99.99% 的可用性。Higher availability - Business Critical tier in Multi-AZ configuration guarantees 99.995% availability, compared to 99.99% of General Purpose tier.
  • 快速异地恢复 - 在部署后的所有时间,采用异地复制配置的“业务关键”层级保证 5 秒恢复点目标 (RPO) 和 30 秒恢复时间目标 (RTO)。Fast geo-recovery - Business Critical tier configured with geo-replication has a guaranteed Recovery point objective (RPO) of 5 sec and Recovery time objective (RTO) of 30 sec for 100% of deployed hours.

后续步骤Next steps