SQL Server 2012 新一代的高可用技术AlwaysOn 之二 AlwaysOn的基本架构

要部署一套AlwaysOn的方案，必须首先要部署一套Windows2008或者Windows2008 R2的群集环境。在Windows群集的节点上，你可以在群集的节点上安装SQLServer单机实例，也可以使用群集中的多个节点安装SQLServer群集实例。无论是单机实例，还是群集实例，只要这些实例上都配置了同一个AlwaysOn可用性组，这些实例就被称为该可用性组的可用性副本（AvailabilityReplica）。AlwaysOn仅要求所有SQLServer实例都运行在同一个Windows群集上，但SQLServer实例本身不需要是群集模式的。如果没有特殊的理由，推荐所有的可用性副本都使用单机模式的SQLServer。

AlwaysOn可用性组里包含一个或多个用户数据库，这些数据库被称为可用性数据库（AvailabilityDatabase）。每个可用性副本上都有这些可用性数据库的副本，这些数据库副本彼此之间互相同步。如果可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。

AlwaysOn可用性组从Windows群集角度来看，其实就是一个群集资源，因此可用性组中包含的所有数据库是作为一个整体在群集的节点间进行故障转移的。这使得AlwaysOn非常适合那些需要用到多个数据库的应用程序，避免了像数据库镜像那样只能切换单个数据库的问题。但是，可用性组不能包含系统数据库，也就是说系统数据库不能通过AlwaysOn实现高可用性，这点和数据库镜像是类似的。

在多个可用性副本间，只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），而这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。

AlwaysOn可用性副本利用了Windows群集的特性来进行故障的侦测和转移，因此它也受到群集的一些限制：

·        一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。

·        一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。

·        如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。

·        一个数据库只能属于一个可用性组。

你可以通过图3-1来理解AlwaysOn的可用性副本，可用组和群集节点的关系。

图3-1AlwaysOn的可用性副本，可用组和群集节点的关系

假设一个Windows群集分布在两个子网(NetworkSubnet A和NetworkSubnet B)里。在子网A，有三个节点。子网B有两个节点。节点A1与节点A2上安装了一个群集的SQLServer实例Instance1。其他节点上分别安装了三个单机的SQLServer实例。这四个实例，就可以组成一个可用性组(AvailabilityGroup)。这些实例都是这个可用性组的可用性副本（AvailabilityReplica）。在图中(3-1)所显示的状态，SQL实例Instance1是主副本，其他实例都是辅助副本。这些实例上都存储有同样的一套用户数据库组（AvailabilityDatabase），但是只有Instance1上的数据库是可读写的。

如果NodeA1或NodeA2上安装有任何其他SQL实例，这些实例都不能被加入到这个可用性组里来。

接下来，让我们了解另一个重要的AlwasyOn组件: Listener（侦听器）。

假设我们建立了如下的这个AlwaysOn方案：可用性组(AvailabilityGroup)名叫testAG。它拥有三个可用性副本：Denali1、Denali2和Denali3。（图3-2）

Denali1现在是主副本，可用性组包含两个数据库：testdb1和testdb2。Denali1上还有一个不属于任何可用性组的数据库nonAGdb。在两个辅助副本Denali2和Denali3上，只有testdb1和testdb2这两个可用性数据库，没有其他数据库。

如果仅这样设置，在Windows故障转移群集管理器里就只能看到一个资源，即可用性组资源。但是SQL客户端不能使用这个资源的名字登陆SQLServer。它们必须知道当前主副本的实例名称，使用这个名字来连接SQLServer。一旦发生了AlwaysOn故障转移，就需要通过修改应用程序的连接字符串、添加别名等方式来把应用程序重新指向到新的主副本上去。在上面的例子里，用户开始时需要用Denali1这个名字来连接。如果AlwaysOn发生了故障转移，切换到了Denali2上，那所有的用户都要用Denali2这个名字来连接。这是非常不方便的。

为了可以让应用程序能够透明的连接到主副本而不会受到故障转移的影响，你需要创建一个Listener。一个Listener包含虚拟IP地址，虚拟网络名（DNS名）和端口号三个要素。创建了Listener之后，就会为可用性组资源添加虚拟IP地址和虚拟网络名资源。应用程序通过连接虚拟网络名而非主副本的实例名来访问到主副本实例和其上面运行的数据库，这点和故障转移群集很像。和故障转移群集不同的是，除了虚拟网络名可以使用之外，主副本本身的真实实例名依旧可以被用来连接到这个实例。

还是上面那个例子。我们可以创建一个名字（即虚拟网络名）是testAGvname的Listener。SQLServer Management Studio既可以用Denali1这个名字，也可以用testAGvname这个名字来连接SQLServer。用testAGvname连接上SQLServer之后，除了可用性组中的数据库，你也可以看到nonAGdb，证明你已经通过testAGvname连接到了Denali1这个副本上了。

 SQL Server 2012以前版本的SQL Server，只有在实例启动的时候才会尝试绑定IP地址和端口。但是SQLServer 2012却允许你在副本实例处于运行状态的时候，随时绑定新的IP地址，网络名和端口号。因此你可以随时为可用性组添加Listener，而且这个操作会立刻生效。当添加了Listener之后，你会在SQLServer的错误日志中看到类似这样的信息。

 你可以在创建可用性组的时候就为这个可用性组配置一个Listener。你也可以在可用性组创建完毕之后再动态的添加或删除listener。

要注意的是，SQLBrowser服务是不支持Listener的。这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser服务。

如果Listener使用的端口是默认端口1433的话，那么可用端程序可以很简单的直接使用虚拟网络名连接到主副本。但是如果Listener使用的端口是一个非默认端口的话，那么情况就有点复杂了：

（1）        如果主副本实例是侦听在默认端口上的话，那么客户端通过Listener的虚拟网络名依旧可以直接连接到主副本。其实客户端是使用了主副本侦听的1433端口，而非Listener所用的端口。

（2）        如果主副本实例是侦听在一个非默认端口上，那么客户端就必须在连接字符串中指定端口号才能连接到主副本实例。你可能会问，如果主副本上的SQL Browser服务在运行的话，客户端不能通过它找到主副本的端口从而连接上主副本吗？不行。即使你的主副本是个命名实例，客户端在使用AlwaysOn虚拟网络名时还是会把它当做一个默认实例，从而根本不会发UDP包到1434端口去访问SQL Brower服务。于是也就没法通过主副本的SQL Browser或的主副本侦听的端口。

如果各个可用性副本所使用的端口不相同，有的副本使用1433端口，而有的副本使用非默认端口，你就必须在连接字符串中指定端口号。如果客户端仅使用虚拟网络名来进行连接，当主副本是使用默认端口的实例时，连接可以建立；但一旦发生故障转移，应用程序的连接就会失败。这会影响数据库服务的高可用性。所以按照现有的设计，我们建议加入AlwaysOn的SQLServer实例，最好使用同样的固定端口。