AlwaysOn技术的简要说明：
SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。
AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。
WSFC的简要说明：
下面先介绍下Windows 故障转移群集（WSFC） ，WSFC 群集中的每个节点都参与周期性信号通信，以便与其他节点共享该节点的运行状况。未响应的节点被认为是处于故障状态。
“仲裁”节点集是 WSFC 群集中的大多数投票节点和见证服务器。WSFC 群集的总体运行状况和状态是由定期“仲裁投票”确定的。仲裁的存在意味着群集运行状况正常，且能提供节点级别的容错能力。
没有仲裁并不指示群集未在正常状况下运行。必须维护整体 WSFC 群集运行状况，以便确保运行状况辅助节点可用于要故障转移到的主节点。如果仲裁投票失败，作为一项预防措施，WSFC 群集将被设为脱机。这也将导致停止所有向群集注册的 SQL Server 实例。
注：如果 WSFC 群集因为仲裁失败而被设为脱机，则需要手动干预以便将其重新联机。
仲裁模式”是在 WSFC 群集级别配置的，指示用于仲裁投票的方法。故障转移群集管理器实用工具将会基于群集中的节点数来建议仲裁模式。
以下仲裁模式可用于确定构成投票仲裁的元素（仲裁机制）：
节点的大多数： 群集中超过一半的投票节点必须投票赞成群集处于正常状态。
节点和文件共享的大多数： 与节点的大多数仲裁模式相似，只有远程文件共享也配置为投票见证除外，并且从任何节点到该共享的连接也作为赞成投票计数。超过一半的可能投票必须赞成群集处于正常状态。
作为最佳实践，见证文件共享不应驻留在该群集中的任何节点上，必须它应该对于该群集中的所有节点都是可见的。
节点和磁盘的大多数： 与节点的大多数仲裁模式相似，只有共享磁盘群集资源也指定为投票见证除外，并且从任何节点到该共享磁盘的连接也作为赞成投票计数。超过一半的可能投票必须赞成群集处于正常状态。
仅限磁盘： 共享磁盘群集资源指定为见证，并且从任何节点到该共享磁盘的连接也作为赞成投票计数。
AlwaysOn的特性：
下面，先看一下AlwaysOn的关键特性：
1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。
2.一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。
3.辅助服务器可以独立执行备份和DBCC维护命令。通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。
4.主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。
5..支持自动、手动和强制三种故障转移方式。
6.有仪表盘用于监控AlwaysOn的运行状态。
7.可以实现多站点的部署，即主站点和辅助站点可以跨物理网络
AlwaysOn的基本架构说明：
在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。
因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：
一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。
一个数据库只能属于一个可用性组。
AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。
AlwaysOn在各副本间数据同步原理：
AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn通过三个步骤来完成：
步骤1：主副本记录发生变化的数据；
步骤2：将记录传输到各个辅助副本；
步骤3:把数据变化操作在辅助副本上执行一遍。
具体实现如下：
在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Server服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各辅助副本。
辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所带来的操作对数据库性能的影响。