By Perry Whittle，2016/02/24（首次发布：2014/09/24）

关于系列

本文属于进阶系列：Stairway to AlwaysOn

AlwaysOn是一套复杂的技术，往往被误解。在这个阶梯中，您将学习AlwaysOn技术，它们如何适应高可用性堆栈，以及如何充分利用它们。

欢迎来到“SQL Server AlwaysOn的阶梯”系列的第一个级别。在这篇1级文章中，我们将发现“AlwaysOn”，“故障转移群集实例”（FCI）和“Windows Server故障转移群集”技术。我们将详细介绍每个细节并总结它们所在的高可用性堆栈的位置。这将为我们提供一个良好的基础，这对上升的楼梯水平是必不可少的。较高级别的楼梯将研究AlwaysOn可用性组和FCI使用的所需基础架构和不同的存储要求和选项。

在每个楼梯层次之后，您将进一步了解AlwaysOn结构如何构建。尽管作为DBA，您可能没有与AlwaysOn和FCI下面的核心基础设施项目进行任何直接交互，但是有助于全面了解所有技术如何集成。最后的楼梯将导致一个功能AlwaysOn配置。

我们首先要看基础知识，其中包括对已经提到的3种技术的简要描述。

AlwaysOn描述中使用了许多首字母缩写词和缩写词。本文结尾处包含了一个常用术语表。

不用多说，让我们深入了解每种技术。

Windows服务器故障转移群集

Windows Server故障转移群集（WSFC）是位于所有Microsoft高可用性应用程序下的核心高可用性（HA）产品。 WSFC是Windows Server操作系统软件套件的一部分。在创建SQL Server的故障转移群集实例，AlwaysOn高可用性组或甚至Microsoft Exchange邮件服务器群集之前，您需要部署和配置WSFC。

Windows Server故障转移群集提供了将多个计算机节点（物理和/或虚拟）组合起来为一组应用程序提供高可用性的能力。应用程序是服务器软件，如SQL Server或Exchange，我们希望能够在任何节点上运行。通过向客户端呈现包括唯一IP地址和唯一计算机名称或“虚拟网络名称”的虚拟接入点来使应用高度可用。此地址和虚拟名称成为应用程序组中的资源，并在参与节点（如令牌）之间传递。活动计算机节点的严重硬件故障将导致在该节点上运行的组服务的丢失。群集服务将根据故障类型（硬件或软件）自动尝试重新启动当前节点或伙伴节点上的组。

在较高级别上，客户端访问点详细信息与任何磁盘和服务资源一起传输到故障转移伙伴节点。群集实例的故障转移会导致客户端连接断开;一旦服务在另一个节点上可用，则客户端可以重新连接。常见的故障通常是其中之一，但是应用程序的任何故障都可能导致服务移动到另一个节点：

• 公用NIC或网络故障
• 电源故障
• 主板故障
• CPU故障

使用WSFC时，群集应用程序被安装到单独的组或“应用程序”中，其中包含一组资源，如磁盘，服务，IP地址等。组及其资源在任何时候都由单个节点拥有，而除非有计划的交换机或故障转移到该节点，否则不能从任何其他伙伴节点访问资源。

下面显示了Windows Server故障转移群集的典型视图。群集节点全部通过网络连接，域控制器和DNS服务与WSFC一起工作，以允许客户端连接到虚拟IP或虚拟网络名称，无论服务在哪个节点上运行。

为了部署FCI，计算机节点必须使用共享存储，这些存储通常从SAN出现给每个节点。为了部署一个典型的AlwaysOn组，节点利用自己的本地存储，而不是与其他集群伙伴共享。

尽管群集节点可能具有不同的硬件，但通常最好将节点间的硬件保持一致，以避免功能较弱的节点无法处理超出其功能的负载。但是，节点必须使用相同的操作系统补丁级别和网络配置;在部署Windows Server故障转移群集之前验证您的配置时，这将变得清晰。 Windows Server版本（Windows 2003中的8个节点，Windows 2008中的16个节点和Windows 2012中的64个节点）的最大群集节点数量不同。

部署强大的Windows Server故障转移群集需要仔细的设计，支持的硬件和相应版本的Windows Server操作系统。地理分散的集群（跨多个WAN的集群）进一步增加了所需的设计和规划的数量，并显着增加了成本。

知道WSFC仅提供故障转移伙伴功能很重要。应用程序在节点之间没有负载平衡或扩展。每个服务都运行在一个且只有一个节点上。

通常，在大型多节点群集中，您可以在Windows Server故障转移群集节点的子集上安装群集应用程序。在所有节点上安装应用程序的错误都可能导致一些不希望的故障转移，我们将在后面看到，也违反了AlwaysOn组限制策略，这可以确保所有AlwaysOn实例驻留在集群中的不同节点上。

WSFC需要某种形式的中介来控制群集资源所有权。此仲裁以Cluster Quorum的形式提供。自Windows 2003 SP1以来，此Quorum采用节点投票系统的形式，维持Quorum所需的多数选票。您还可以使用磁盘形式的其他仲裁资源进行本地化群集，也可以使用多站点群集的远程文件共享。从Windows Server 2012开始，法定人数使用动态节点权重配置在计划中断期间动态平衡群集投票，以防止不必要的故障转移。我们将在未来的层面更详细地讨论法定人数。

故障转移群集实例

SQL Server的故障转移群集实例一直是SQL Server产品中流行的高可用性技术。 SQL Server高度可用的实例是集群化的，以减轻任何节点硬件故障和任何潜在的软件故障。 这里唯一的薄弱环节是存储; 存储子系统成为单点故障。

故障转移群集实例是默认或命名的SQL Server实例，已作为群集应用程序安装到WSFC上。 群集应用程序通常具有以下资源：

• IP地址
• 网络名字
• 共享磁盘
• SQL Server服务
• SQL Server代理服务

独立实例共享相同的基本要求，不同之处在于，使用独立实例时，IP地址和网络名称将从计算机节点本身获取，而磁盘存储由计算机的本地磁盘资源提供。

参考上面的图，我们看到了具有单个FCI的2节点集群的典型视图。 SQL Server的群集实例将使用已呈现给WSFC节点的任何共享存储。通常这种存储将采取从SAN提供的LUN的形式。 SQL Server的FCI部署在一个两步的过程中，这个过程将在稍后的阶梯中介绍。现在，下面是部署SQL Server的故障转移群集实例的两步过程的基本概述：

1. 在将参与FCI的第一个计算机节点上启动“新建SQL Server故障转移群集安装”向导。一旦完成并成功完成，您就可以进入第二阶段了。
2. 在希望加入新的SQL Server FCI的WSFC中的任何计算机节点上启动“将节点添加到SQL Server故障转移群集”向导。

注意：尽管标准版将FCI限制为2个节点，但并不指定有多少节点具有Windows群集的成员资格（您可能有任何数字，直到操作系统的最大值）。该限制是在SQL Server安装程序级别执行的。

FCI有点像一个跑道接力队的传球过程;计算机节点拥有群集的SQL Server应用程序及其资源，然后为客户端提供对SQL Server服务（持有接力棒）的访问权限。当活动的计算机节点失败（下落接力棒）时，合作伙伴节点进入并获得集群应用程序及其资源的所有权（接上接力棒）。

AlwaysOn可用性组

多年来，故障转移群集一直是为SQL Server提供高可用性的主要方法。当一个节点失败时，另一个节点接管向客户端提供SQL Server服务。 AlwaysOn与Windows Server故障转移群集技术集成，提供更具弹性的高可用性平台。

尽管群集在实例级别上工作，但AlwaysOn在数据库级别配置。 AlwaysOn可用性组是SQL Server 2012中引入的新技术，用于将预定义的数据库组复制到AlwaysOn中已知的一组只读伙伴实例或副本。多个节点各自托管一个AlwaysOn数据库的同步副本，并且最好通过监听器的配置来提供访问（稍后会详细介绍）。

AlwaysOn可用性组需要一个或多个辅助副本来托管高可用性数据库的副本。这些辅助数据库可能是可读或不可读的。它们也可以以异步或同步的方式进行更新。异步副本仅支持手动强制故障转移，而同步副本支持自动或手动故障转移。

次要只读副本可以配置为响应只读查询，您也可以将目标的次要目标作为备份/维护操作以减轻主数据库的压力。这种主从关系也是可逆的，以确保真正的高可用性。任何经过适当配置的只读伙伴在系统发生故障时都可能承担主角色。

AlwaysOn依靠WSFC核心功能实现AO提供的高可用性，但不需要与FCI相关的以下任何共享资源。

• 共享磁盘
• 共享的IP地址
• 共享网络名称
• 共享的SQL Server和SQL Server代理资源

这个共享资源规则有一个例外。创建AlwaysOn组侦听器时，将创建将由AO组副本共享的IP地址和网络名称资源。

正如我们所发现的，故障转移群集实例链中的薄弱环节是共享存储。这里有很多方法可以实现冗余，但是通常成本很高，而且安装和维护通常很困难。当然，如前所述，故障转移群集实例只能缓解服务器硬件。它不提供单个或甚至多个辅助数据库。我们在SQL Server 2012之前的SQL Server版本中有数据库镜像，但这些仅为单个不可读的辅助数据库提供了范围。

AlwaysOn仍然使用熟悉的SQL Server端点作为实例通信。端点在使用可用性组部署向导时自动配置。向导驱动的部署提供了最简单的部署路径，而手动部署需要大量的手动交互。尽管如此，一个基本的AlwaysOn组配置仍然非常容易部署和配置，并提供以前不可用的HA级别，而无需采用复杂的功能集成级别。

您也可以创建一个高可用的侦听器服务，您将使用该服务来接受到可用性组的传入连接。监听器由一个唯一的IP地址和一个唯一的虚拟网络名称组成。这是使组内数据库高度可用的最重大变化之一。

在创建AlwaysOn可用性组期间，将在Windows Server故障转移群集内创建一个群集角色，并包含一个资源。此资源在AlwaysOn组故障转移期间在伙伴节点之间进行故障转移，并标识AlwaysOn组的主副本。

AlwaysOn听众

监听程序在配置时将作为资源创建，并驻留在AlwaysOn可用性组的故障转移群集应用程序角色中。资源是：

• 虚拟IP地址
• 虚拟网络名称

侦听器使用TCP端口来接受传入的连接，并默认连接到主副本。当只读路由已配置时，指向只读意向连接的监听程序的连接将被路由到辅助伙伴而不是主要副本。这是我们可以减轻主副本负载的另一种方式。

在AlwaysOn组的故障转移期间，群集中的节点之间的群集应用程序及其资源将发生故障转移。群集应用程序的节点位置跟​​踪主副本及其底层节点，并根据需要在群集中移动。在主副本是SQL Server的群集实例的情况下，侦听器由该FCI 副本的主动节点拥有。

结论

这就是阶梯1的结尾，它提供了3个核心技术的快速介绍，用来使我们的SQL Server实例及其对象高度可用。 在我们的高可用性堆栈中，我们将WSFC作为基本级别，这是安装FCI或AlwaysOn可用性组的主要要求。 接下来，我们有了位于WSFC顶部的FCI，它依靠群集来服务和保护SQL Server实例。 最后，我们有AlwaysOn组，坐在SQL Server的独立实例和SQL Server的“故障转移群集实例”之上。

在2级中，我们将查看SQL Server High Availability中可用的存储类型及其典型用法。 这将帮助您了解系列中未来的阶梯级别。

词汇表