介绍用于在 Azure 中部署 SQL Server 的 PaaS 选项

平台即服务（PaaS）在云中提供了完整的开发和部署环境，可用于简单的基于云的应用程序和高级企业应用程序。

Azure SQL 数据库和 Azure SQL 托管实例是适用于 Azure SQL 的 PaaS 产品/服务的一部分。

• Azure SQL 数据库 - 在云中基于 SQL Server 引擎构建的一系列产品的一部分。 它使开发人员在大规模构建新的应用程序服务和精细部署选项方面具有很大的灵活性。 SQL 数据库提供了一种低维护解决方案，是某些工作负载的不错选择。

• Azure SQL 托管实例 - 它最适合大多数迁移到云的方案，因为它提供完全托管服务和功能。

根据成本效益的程度，每个产品/服务都提供了对基础结构一定程度的管理。

部署模型

Azure SQL 数据库在两种不同的部署模型中可用：

• 单一数据库 - 按数据库级别计费和管理的单一数据库。 你可从规模和数据大小角度单独管理每个数据库。 此模型中部署的每个数据库都有自己的专用资源，即使都部署到同一逻辑服务器。

• 弹性池 - 一组共同管理并共享一组通用资源的数据库。 弹性池为软件即服务应用程序模型提供经济高效的解决方案，因为资源在所有数据库之间共享。 可以根据基于 DTU 的购买模型或基于 vCore 的购买模型配置资源。

购买模型

在 Azure 中，所有服务都支持物理硬件，你可以灵活地在两种不同的购买模型之间进行选择：

数据库事务单位 (DTU)

基于 DTU 的购买模型 基于组合计算、存储和 I/O 资源的公式计算。 对于想要简单、预配置的资源选项的客户来说，这是一个不错的选择。

DTU 购买模型采用多种不同的服务层级，例如基本、标准和高级。 每个层都有不同的功能，在选择此平台时提供各种选项。

就性能而言，基本层用于要求较低的工作负荷，而高级层则用于密集型工作负荷要求。

计算和存储资源依赖于 DTU 级别，并以固定存储限制、备份保留期和成本提供一系列性能功能。

有关 DTU 购买模型的详细信息，请参阅 基于 DTU 的购买模型概述。

vCore

基于 vCore 的购买模型允许根据给定工作负荷购买指定数量的 vCore。 vCore 是购买 Azure SQL 数据库资源时的默认购买模型。 vCore 数据库在核心数与提供给数据库的内存量和存储量之间存在特定关系。 Azure SQL 数据库和 Azure SQL 托管实例都支持 vCore 购买模型。

还可以在三个不同的服务层级中购买 vCore 数据库：

常规用途服务层级提供两种计算选项： 预配 和 无服务器。 预配的资源是预先分配的，并根据配置的 vCore 按小时计费，非常适合一致的工作负载。 无服务器资源根据需求自动缩放，并按秒计费，使其对可变工作负荷具有成本效益。

无服务器

术语“无服务器”可能会产生误导性，因为你仍将 Azure SQL 数据库部署到逻辑服务器进行连接。 无服务器 是一种计算层，可根据工作负荷需求自动纵向扩展或缩减资源。 当工作负荷不再需要计算资源时，数据库将暂停，并且仅在非活动期间对存储计费。 尝试连接后，数据库将恢复并变为可用。

控制暂停的设置称为自动暂停延迟，最小值为 60 分钟，最大值为 7 天。 如果数据库在该持续时间内保持空闲状态，则会暂停。

数据库在指定时间内处于非活动状态后，它会暂停，直到后续连接尝试。 配置计算自动缩放范围和自动暂停延迟会影响数据库性能和计算成本。

应将使用无服务器的应用程序配置为处理连接错误，并包括重试逻辑，因为连接到暂停的数据库会产生连接错误。

Azure SQL 数据库的无服务器模型与标准 vCore 模型之间的另一个区别是，使用无服务器，可以指定最小和最大 vCore 数。 内存和 I/O 限制与指定范围成正比。

该图像显示了 Azure 门户中无服务器数据库的配置屏幕。 你可以选择最少半个 vCore 和最多 16 个 vCore 的选项。

无服务器与 Azure SQL 数据库中的所有功能不完全兼容，因为其中一些功能需要后台进程不断运行，例如：

• 异地复制
• 长期备份保留
• 弹性作业中的作业数据库
• SQL 数据同步中的同步数据库（数据同步是一种在一组数据库之间复制数据的服务）

备份

平台即服务产品/服务最重要的功能之一是备份。 在这种情况下，系统会自动执行备份，而无需你进行任何干预。 Azure Blob 异地冗余存储存储这些备份，默认情况下，会根据数据库的服务层保留 7 到 35 天。 基本数据库和 vCore 数据库默认保留期为 7 天，管理员可以调整 vCore 数据库的此值。 可以通过配置长期保留（LTR）来延长保留时间，使你能够将备份保留长达 10 年。

为了提供冗余，还可以使用可读取访问的异地冗余 Blob 存储。 此存储会将数据库备份复制到首选的次要区域。 它还允许您在需要时从该次要区域进行读取。 不支持手动备份数据库，平台将拒绝任何执行此作的请求。

数据库备份按给定计划执行：

• 完整：每周一次
• 差异：每 12 小时一次
• 日志– 每 5-10 分钟，具体取决于事务日志活动

此备份计划应满足大多数恢复点/时间目标（RPO/RTO）的需求，但是，每个客户都应评估它们是否符合你的业务需求。

有多种选项可用于还原数据库。 由于平台即服务的性质，无法使用常规方法（如发出 T-SQL 命令 RESTORE DATABASE）手动还原数据库。

无论实现哪种还原方法，都无法通过现有数据库进行还原。 如果需要还原数据库，则必须在启动还原过程之前删除或重命名现有数据库。 此外，请记住，根据平台服务层级，还原时间不保证且可能会波动。 建议测试还原过程，以获取有关还原可能需要多长时间的基线指标。

• 使用 Azure 门户还原 - 使用 Azure 门户，可以选择将数据库还原到 Azure SQL 数据库的同一逻辑服务器，也可以使用还原在任何 Azure 区域中的新服务器上创建新数据库。

• 使用脚本语言还原 - 可以使用 PowerShell 和 Azure CLI 还原数据库。

有关自动备份的详细信息，请参阅 自动备份 - Azure SQL 数据库和 Azure SQL 托管实例。

主动地理复制

异地复制 是一项业务连续性功能，可将数据库异步复制到最多四个次要副本。 当事务提交到主副本（及其同一区域内的副本）时，事务将发送到次要副本进行重播。 由于此通信以异步方式完成，因此调用应用程序不必等待辅助副本在 SQL Server 将控制权返回到调用方之前提交事务。

辅助数据库是可读的，可以用于卸载只读工作负荷，从而释放主数据库上事务性工作负荷的资源，并且可以将数据放在更靠近最终用户的位置。 此外，辅助数据库可以位于主数据库所在的同一区域，也可以位于另一个 Azure 区域中

可以由用户手动或由应用程序以编程方式启动故障转移。 如果发生故障转移，可更新应用程序连接字符串以反映当前主数据库的新终结点。

故障转移组

故障转移组建立在异地复制中使用的技术之上，但为连接提供了一个终结点。 使用故障转移组的主要原因是，它们提供可用于将流量路由到相应副本的终结点。 然后，应用程序可以在故障转移后进行连接，而无需更改连接字符串。