了解高可用性和灾难恢复选项
要构思用于虚拟机 (VM) 的解决方案，必须先了解基于 IaaS 的部署的可用性选项。
基础结构即服务与平台即服务
就可用性而言，是选择 IaaS 还是 PaaS 很重要。 使用 IaaS 时，你有一个虚拟机，这意味着有一个安装了 SQL Server 的操作系统。 负责 SQL Server 的管理员或组可选择高可用性和灾难恢复 (HADR) 解决方案，并可更好地控制如何配置该解决方案。
使用基于 PaaS 的部署（如 Azure SQL 数据库）时，HADR 解决方案内置于功能中，通常只需要启用。 可以配置的选项很少。
由于存在这些差异，是选择 IaaS 还是 PaaS 可能会影响 HADR 解决方案的最终设计。
用于 Azure 虚拟机的 SQL Server HADR 功能
使用 IaaS 时，可以使用 SQL Server 提供的功能来提高可用性。 在某些情况下，可以将它们与 Azure 级别的功能结合起来，进一步提高可用性。
下表显示了 SQL Server 中提供的功能
| 功能名称 | 保护 |
|---|---|
| Always On 故障转移群集实例 (FCI) | 实例 |
| Always On 可用性组 (AG) | 数据库 |
| 日志传送 | 数据库 |
SQL Server 实例是指 SQL Server 的整个安装（二进制文件、实例中的所有对象，包括登录名、SQL Server 代理作业和数据库）。 实例级保护是指可用性功能中考虑了整个实例。
SQL Server 中的数据库包含最终用户和应用程序使用的数据。 这些数据包括 SQL Server 所依赖的系统数据库，以及为了供最终用户和应用程序使用而创建的数据库。 SQL Server 实例始终有其自己的系统数据库。 数据库级的保护是指可用性功能中考虑了数据库中或用户/应用程序数据库的事务日志中捕获的所有内容。 位于数据库外部或未在事务日志中捕获的所有内容（如 SQL Server 代理作业和链接服务器）都必须手动处理，以确保在发生计划内或计划外故障转移事件时，目标服务器可以像主服务器一样运行。
FCI 和 AG 都需要一个基础群集机制。 对于在 Windows Server 上运行的 SQL Server 部署，该机制是 Windows Server 故障转移群集 (WSFC)，而对于 Linux 则是 Pacemaker。
Always On 故障转移群集实例
安装 SQL Server 时，系统会配置 FCI。 SQL Server 的独立实例无法转换为 FCI。 系统会为 FCI 分配一个唯一的名称和 IP 地址（不同于加入群集的基础服务器或节点）。 名称和 IP 地址也必须与基础群集机制不同。 应用程序和最终用户将使用 FCI 的唯一名称来进行访问。 此抽象使应用程序不必知道实例运行的位置。 基于 Azure 的 FCI 与本地 FCI 之间的一个主要区别是：对于 Azure 来说，需要内部负载均衡器 (ILB)。 ILB 用于帮助确保应用程序和最终用户可以连接到 FCI 的唯一名称。
如果 FCI 故障转移到群集的另一个节点，则无论是手动启动故障转移还是由于出现问题而进行故障转移，整个实例都将在另一个节点上重启。 这意味着故障转移过程是完全停止然后启动 SQL Server。 在故障转移过程中，连接到 FCI 的任何应用程序或最终用户都将断开连接，只有可以处理此中断并从中断恢复的应用程序才能自动重新连接。
在其他节点上启动时，实例会经历恢复过程。 FCI 将与故障点保持一致，因此从技术上说，不会丢失任何数据，但是任何需要回滚的事务都将在恢复过程中进行回滚。 如上所述，因为这是实例级保护，所需的所有内容（登录名、SQL Server 代理作业等）都已存在，所以数据库准备就绪后，企业就可以像往常那样继续运作。
FCI 需要一个数据库副本，但这也是它的单一故障点。 为了确保其他节点可以访问数据库，FCI 需要某种形式的共享存储。 对于基于 Windows Server 的体系结构，可以通过 Azure 高级文件共享、iSCSI、Azure 共享磁盘、存储空间直通 (S2D) 或支持的第三方解决方案（如 SIOS DataKeeper）来实现此目的。 使用 SQL Server Standard Edition 的 FCI 最多可以有两个节点。 FCI 还要求使用 Active Directory 域服务 (AD DS) 和域名服务 (DNS)，因此，这意味着必须在 Azure 中的某个位置实现 AD DS 和 DNS，FCI 才能正常工作。
使用 Windows Server 2016 或更高版本时，FCI 可以使用存储副本为 FCI 创建本机灾难恢复解决方案，而无需使用其他功能（如日志传送或 AG）。
AlwaysOn 可用性组
SQL Server 2012 Enterprise Edition 中已经引入了 AG，从 SQL Server 2016 开始，Standard Edition 中也引入了 AG。 在 Standard Edition 中，AG 可以包含一个数据库，而在 Enterprise Edition 中，AG 可以包含多个数据库。 尽管 AG 与 FCI 有一些相似之处，但它们在许多方面都不同。
FCI 与 AG 之间最大的区别在于 AG 提供数据库级的保护。 主要副本是参与 AG 的实例，该 AG 中包含读/写数据库。 次要副本是主要副本通过日志传输发送事务以保持同步的位置。 主要副本之间的数据移动可以采用同步方式，也可采用异步方式。 所有次要副本上的数据库都处于正在加载的状态，这意味着它们可以接收事务，但在次要副本成为主要副本之前，它们不能成为完全可写的副本。 在 Standard Edition 中，AG 最多可以有两个副本（一个主要副本，一个次要副本），而 Enterprise Edition 支持多达 9 个副本（一个主要副本，八个次要副本）。 次要副本可通过数据库的备份初始化，自 SQL Server 2016 起，还可使用一种称为“自动种子设定”的功能对其进行初始化。 对于使用所配置终结点的可用性组，自动种子设定使用日志流传输将备份流式传输到其每个数据库的次要副本。
AG 使用侦听器提供抽象。 侦听器的工作方式与分配给 FCI 的唯一名称类似，并且有自己的名称和 IP 地址（不同于 WSFC、节点等任何其他对象）。 侦听器还需要 ILB，并经历停止和启动过程。 应用程序和最终用户可以使用侦听器进行连接，但与 FCI 不同的是，必要时，不一定要使用侦听器。 可以直接连接到实例。 对于 Enterprise Edition，Enterprise Edition 中的次要副本也可以配置为只读访问（如果需要），并且可用于其他功能（例如数据库一致性检查 (DBCC) 和备份）。
与 FCI 相比，AG 的故障转移时间更短，这也是其具有吸引力的一个原因。 尽管 AG 不需要共享存储，但每个副本都有数据的副本，这会增加数据库副本总数和总体存储成本。 存储对于每个副本而言都是本地的。 例如，如果数据库在主要副本上的数据占用量为 1 TB，那么在每个副本上的占用量均为 1 TB。 如果有五个副本，这意味着需要 5 TB 的空间。
请记住，位于数据库外部或未在数据库的事务日志中捕获的所有对象都必须手动创建，如果有任何其他 SQL Server 实例需要成为新的主要副本，还必须在该实例上考虑这些对象。 你将负责的对象示例包括 SQL Server 代理作业、实例级登录名和链接服务器。 如果可以使用 Windows 身份验证或 AG 中包含的数据库，则可简化访问过程。
许多组织可能会面临实现高可用性体系结构的挑战，也可能只需要 Azure 平台提供的高可用性，或使用 Azure SQL 托管实例这样的 PaaS 解决方案。 在了解 Azure 平台解决方案之前，还应该了解另一项 SQL Server 功能：日志传送。
日志传送
日志传送自 SQL Server 早期就已经存在。 此功能基于备份、复制和还原，是实现 SQL Server HADR 最简单的方法之一。 日志传送主要用于灾难恢复，但也可用于提高本地可用性。
日志传送和 AG 一样提供的是数据库级保护，这意味着你仍需要考虑 SQL Server 代理作业、链接服务器、实例级登录名等。日志传送本身不提供抽象，因此若要切换到另一个参与日志传送的服务器，必须能够容忍名称更改。 如果无法做到这一点，可以使用 DNS 别名等方法，可在网络层配置 DNS 别名，以尽量缓解名称更改问题。
日志传送机制很简单：首先，在主服务器上对源数据库进行完整备份，在另一个称为辅助服务器或热备用服务器的实例上将其还原为加载状态（STANDBY 或 NORECOVERY）。 这个新的数据库副本称为“辅助数据库”。 然后，SQL Server 中内置的自动过程将自动备份主数据库的事务日志，将备份复制到备用服务器上，最后将备份还原到备用服务器上。
SQL Server HADR 功能并不是提高 IaaS 可用性的唯一选项。 还应该考虑 Azure 中的一些功能。