为了实现企业核心业务系统的连续运行，保护关键数据免受计划内以及计划外停机的影响，在SQL Server 早期版本中就已经提供了一系列的高可用性解决技术，比如大家耳熟能详的故障转移群集、数据库镜像、日志传递、复制，此四种可高用性技术也有各自的优缺点。正因为现有高可用性技术的不足，SQL Server 2012中提出一种新的高可用性技术AlwaysOn，它集现有高可用性技术的优点于一身，在介绍此技术之前，先对现有高可用性技术简单介绍。
SQL Server 高可用技术简述
故障转移群集
故障转移群集又称为Failover Cluster。此技术使用的共享存储技术，不涉及到底层数据的同步问题，因此可以认为群集的最大好处就是性能较高。正因为如此，存储将成为整个群集技术中的单点故障。在短短的半年内，笔者遇到因为存储单点故障而进行的群集故障操作已有四个，平均一个多月就要处理一个。群集技术的另一个弊端就是某一个时间点只有一个节点处于活动状态，其他节点处于闲置不可用状态，造成了硬件资源的浪费。
数据库镜像
数据库镜像又称为Database Mirror。此技术可提供几乎是瞬时的故障转移，以提高数据库的可用性。镜像基于单个数据库实现，数据库镜像会及时将主数据库的数据同步到镜像数据库。此技术的最大弊端在于镜像数据库处于不可读状态，无形中也造成了硬件资料的浪费。
日志传送
日志传送又称为Log Shipping。同数据库镜像技术一样，日志传送是数据库级操作。可以使用日志传送来维护单个生产数据库(称为“主数据库”)的一个或多个热备用数据库(称为“辅助数据库”)。此技术支持对辅助数据库在还原作业之间的间隔时间内的只读访问权限，可用做报表查询，以提高资源的利用率。此技术一般用于远程的异步容灾，存在部分数据丢失的可能性。
复制
复制又称为Replication。此技术基于数据库对象级别，灵活性较高，可以很方便地将数据和数据库对象从一个数据库复制和分发到另一个数据库，然后在数据库之间进行同步以保持一致性。 使用复制，可以在局域网和广域网、拨号连接、无线连接和 Internet 上将数据分发到不同位置以及分发给远程或移动用户。此技术的弊端在于，它不支持DDL命令。如在源服务器中新建一个表对象，此对象是无法自动复制到目标服务器的。
AlwaysOn高可用性技术
AlwaysOn是SQL Server 2012中提供的一种全新的高可用性技术，其集中了上述高可用性技术的优点，以确保企业无需增加成本和提高复杂度，即可实现最高级别的可用性和数据保护。可在数据中心内部以及跨数据中心实现数据冗余，快速地实现应用程序故障转移，保护现有硬件资源。同时简化了其配置过程。AlwaysOn可以实现服务器实例级和数据库级配置高可用性，所对应的技术就是AlwaysOn故障转移群集实例和AlwaysOn可用性组。
AlwaysOn故障转移群集实例
一般来说，在单服务器情况下，当服务器上出现硬件或软件故障时，连接到该服务器的应用程序或客户端将会停机。在AlwaysOn故障转移群集实例环境中，SQL Server 实例的高可用性受到冗余节点的保护。 在群集环境中，一次只能有一个节点拥有群集的资源组。 在出现故障(硬件故障、操作系统故障、应用程序或服务故障)或进行计划的升级时，该资源组的所有权就会转移至另一个群集节点。 此过程对于连接到 SQL Server 的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。因此AlwaysOn故障转移群集实例必须由一组物理服务器节点构成，这些服务器节点推荐使用类似的硬件配置以及相同的软件配置，如操作系统的版本、SQL Server 版本、修补程序级别、组件以及实例名称。 相同的配置是确保群集在节点间进行故障转移时能够正常运行的前提条件。
SQL Server 2012在原有SQL Server故障转移群集的基础上功能得到了进一步的增强，支持跨越子网实现多站点群集，此技术一般用于两个或两个以上的数据中心，以同时提供本地高可用性和远程的灾难恢复。其中，每个故障转移群集节点都连接到其他子网或其他子网组。这些子网可以处于同一位置中，也可以位于地理上分散的站点。 跨地理上分散的站点进行群集有时又被称为扩展群集。 因为没有供所有节点都可以访问的共享存储，所以在多个子网上的数据存储之间应该复制数据。因此，多子网故障转移群集除了具备高可用性之外，还提供了灾难恢复解决方案。下面以图例说明：
在此需要使用到存储级别的复制技术，将本地数据中心数据库中的数据文件及日志文件复制到远程数据中心，当本地数据中心发生故障时，Windows 群集检测到故障，远程数据中心存储软件可以检测到复制失效，会将存储转换为读写状态，接下来Windows群集会将远程站点可读写的存储设备挂接到远程的Cluster节点上，此时存储复制的方向就从远程数据中心向本地数据中心复制。也就是说，故障转移群集实例成功启动后，Windows群集服务将监视基础群集的运行状况和 SQL Server 实例的运行状况。SQL Server 2012中允许群集服务使用专用连接来轮询活动 SQL Server 实例，以便通过系统存储过程获取详细的组件诊断信息。好处是，利用与 SQL Server 实例的专用连接，能够对组件诊断信息进行可靠轮询，即使在故障转移群集实例负荷较重时也是如此。利用详细的组件诊断信息，可以配置更灵活的故障转移策略，由此用户能选择哪些故障条件将触发故障转移以及哪些故障条件将不触发故障转移。用户利用产生的诊断信息，还可以通过追溯方式更好地对自动故障转移进行故障排除。此诊断信息将存储到与 SQL Server 错误日志并置的日志文件中。 可以将这些日志文件加载到日志文件查看器中以检查导致出现故障转移的组件状态，从而确定导致该故障转移的原因。
AlwaysOn可用性组
AlwaysOn可用性组
AlwaysOn可用性组是SQL Server 2012中提供的全新功能，确保了应用程序数据的可用性，实现零数据丢失。AlwaysOn可用性组技术融合了数据库群集和数据库镜像的优点，此技术的一大好处是提供非共享存储，可以避免因为存储的单点故障而造成的整个可用性方案失效。
AlwaysOn可用性组基于数据库(组)级别，是将一组用户数据库(可以是一个或多个)划到一个组中。每组可用性数据库都由一个可用性副本承载。可用性副本包括一个主副本和一到四个辅助副本。 主副本用于承载主数据库，辅助副本则承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本使主数据库可用于客户端的读写连接，实现对数据库的更改操作。 同时在数据库级别进行同步。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 每个辅助副本缓存事务日志记录，然后将它们还原到相应的辅助数据库。 主数据库与每个连接的辅助数据库进行数据同步。 因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
此外，用户可以借助辅助数据库来实现近实时的报表查询，将查询的负载分担到只读副本。相对于数据库群集及镜像来说，可以更好的利用硬件资源，从而提高IT效率并降低成本。
下面看一下AlwaysOn可用性组架构，如下图所示：
用户可以通过创建一个可用性组侦听器来提供到给定可用性组的主副本的客户端连接。 “可用性组侦听器”采用DNS名称的方式连接给定可用性组的资源，以便将客户端连接定向到相应的可用性副本。
对于每个可用性副本，AlwaysOn所支持的事务提交模式分为同步提交模式或异步提交模式。在异步提交模式下，主副本无需等待确认异步提交辅助副本已强制写入日志，便可提交事务。 异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丢失。此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况;所谓同步提交模式是指在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成强制写入日志。 同步提交模式可确保在给定的辅助数据库与主数据库同步时，充分保护已提交的事务。 这种保护的代价是延长事务滞后时间。此可用性模式相对于性能而言更强调高可用性和数据保护，当主副本和辅助副本距离较近时可以使用此方法，解决时时同步的问题。
正因为AlwaysOn可用性组集现有高可用性技术的优点于一身，不得不说，它是SQL Server 2012新特性中最为璀璨的一个。下面我们就结合实例看一下AlwaysOn可用性组的配置。
实例操作：AlwaysOn可用性组配置
实例：北京某知名医院的医院信息化平台解决方案系统，因查询压力较大，现需要搭建近实时的报表服务器，但因早期规划不周，经常需要执行类似于create table、drop table之类的DDL命令。
分析：基于此要求采用早期的高可用解决方案都不可行，故障转移群集和数据库镜像的辅助节点或者辅助数据库不可用，日志传送技术支持对辅助数据库在还原作业之间的间隔时间内的只读访问权限一般用于远程的异步容灾，存在部分数据丢失的可能性。复制的实时性较强，但针对的是数据库中对象，针对DDL命令为力。综合分析下来，AlwaysOn可用性组最为合适。
拓扑图：
步骤一：启用AlwaysOn 可用性组
启用 AlwaysOn 可用性组是服务器实例使用可用性组的先决条件。 在创建和配置任何可用性组之前，必须在每个 SQL Server 实例上启用 AlwaysOn 可用性组功能。 操作方法是：打开SQL Server配置管理器，右键单击该SQL Server实例名称，选择“属性”，然后打开“SQL Server属性”对话框，点击“AlwaysOn高可用性”选项卡，勾选“启用AlwaysOn可用性组”，如下图所示：
步骤二：创建可用性组
A.相应数据库做完全备份
在此需要将准备添加到可用性组中的数据库进行完全备份，只有进行完全备份之后，数据库才会进行日志备份。如下图所示：
B.创建可用性组
当准备工作完成后，就可以创建可用性组了，用户可以使用向导、T-SQL命令、PowerShell命令来创建可用性组，在此使用向导，在Server1上点击可用组向导，弹出创建新的可用性组的简介信息，直接下一步，出现如下图所示的界面：
然后选择我们刚进行过完整备份的DB1、DB2数据库。生产环境中，用户根据需要选择满足条件的数据库。
在此界面中可以选择自动故障转移，同步提交的意思是说辅助节点收到主节点传给它的日志后，主节点才进行事务的提交，从而保证数据的一致性。可读辅助副本选择是，辅助副本是允许只读的。
在此我们选择一个存放数据库备份文件的共享文件夹，以使得辅助节点可以从此处进行数据库的还原操作。
在此进行网络、磁盘空间、数据库文件以及兼容性的验证。在此侦听器配置显示的警告信息，是因为我们没有为可用性组配置侦听器，我们将在完成后再进行配置，在此直接下一步。然后系统会自动完成在辅助节点上还原数据库的操作。
步骤三：创建侦听器
在创建可用性组向导中默认是不创建侦听器的，所以我们在此需要创建侦听嘎嘎。每个可用性组侦听器都需要一个 DNS 主机名，该名称在域和 NetBIOS 中是唯一的。
指定侦听器的名称该侦听器所使用的端口号、IP地址(在此也可以使用DHCP服务器分配)。一旦创建成功，会注册到DNS中。用户就可以使用此名称来连接到可用性组中。
通过以上的介绍和实例配置，可以明显感觉到AlwaysOn可用性组的配置相当简洁，简单几步即可完成，丝毫不像日志传送、数据库镜像那么繁琐。就其功能而言，如用户需要实现基于共享存储服务器实例级别的高可用和故障恢复可以使用AlwaysOn多站点故障转移群集技术;如果用户需要实现非共享存储基于数据库级别的高可用和故障恢复则可以使用AlwaysOn可用性组技术;甚至还可以AlwaysOn故障转移群集和可用性组的组合使用实现实例级别的高可用和数据库级别的故障恢复。功能如此之强，让人叹服!下载本文
