一、alwayson概念
“可用性组” 针对一组离散的用户数据库（称为“可用性数据库” ，它们共同实现故障转移）支持故障转移环境。 一个可用性组支持一组主数据库以及一至八组对应的辅助数据库(包括一个主副本和两个同步提交辅助副本)。 辅助数据库不是备份，应继续定期备份您的数据库及其事务日志。
每组可用性数据库都由一个“可用性副本” 承载。 有两种类型的可用性副本：一个“主副本” 和一到四个“辅助副本”。 它承载主数据库和一至八个“辅助副本” ，其中每个副本承载一组辅助数据库，并用作可用性组的潜在故障转移目标。 可用性组在可用性副本级别进行故障转移。 可用性副本仅在数据库级别提供冗余 － 针对一个可用性组中的该组数据库。 故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。
主副本使主数据库可用于客户端的读写连接。 此外，它在称为“数据同步” 的过程中使用，在数据库级别进行同步。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 每个次要副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。 主数据库与每个连接的辅助数据库独立进行数据同步。 因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
或者，您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。
部署 Always On 可用性组 需要一个 Windows Server 故障转移群集 (WSFC) 群集。 给定可用性组的每个可用性副本必须位于相同 WSFC 群集的不同节点上。 唯一的例外是在迁移到另一个 WSFC 群集时，此时一个可用性组可能会暂时跨两个群集。
为您创建的每个可用性组创建一个 WSFC 资源组。 WSFC 群集将监视此资源组，以便评估主副本的运行状况。 针对 Always On 可用性组 的仲裁基于 WSFC 群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。 与数据库镜像相反，在 Always On 可用性组中没有见证服务器角色。
二、可用性模式
可用性模式是每个可用性副本的一个属性；可用性模式确定主副本是否需要等待辅助副本将事务日志写入到磁盘。
1.异步提交模式
异步提交模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。 如果每个辅助副本都在异步提交模式下运行，则主副本不会等待任何辅助副本强制写入日志， 而会在将日志记录写入本地日志文件后，立即将事务确认发送到客户端。 主副本使用与针对异步提交模式配置的辅助副本相关的最小事务滞后运行。
在“异步提交模式”下，辅助副本永远不会与主副本同步。 虽然给定的辅助数据库可能会赶上对应的主数据库，但任何辅助数据库在任何时点都可能会落后。 对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本的灾难恢复方案的情况，或性能比同步数据保护更重要的情况，异步提交模式将会很有用。 而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本。
异步提交辅助副本会尝试与接收自主副本的日志记录保持一致。 但异步提交辅助数据库往往会保持未同步状态，并且可能稍微滞后于相应的主数据库。通常，异步提交辅助数据库和相应的主数据库之间的这个时间差会很小。但是，如果承载辅助副本的服务器的工作负荷过高或网络速度很慢，则这个时间差会变得较大。
异步提交模式所支持的唯一故障转移形式为强制故障转移（可能造成数据丢失）。 强制故障转移是一种最后手段，仅可用于当前主要副本长时间保持不可用状态并且主数据库的即时可用性比可能丢失数据的风险更为重要的情况。故障转移目标必须是其角色处于 SECONDARY 或 RESOLVING 状态的副本。 故障转移目标将转换为主角色，并且其数据库副本将成为主数据库。 任何剩余的辅助数据库以及变得可用后的以前的主数据库都将被挂起，直到您手动单独恢复它们。 在异步提交模式下，原始主副本尚未发送到以前的辅助副本的任何事务日志都将丢失。 这意味着，某些或全部新的主数据库可能会缺少最近提交的事务
2.同步提交模式
同步提交模式相对于性能而言更强调高可用性，为此付出的代价是事务滞后时间增加。 在同步提交模式下，事务将一直等到辅助副本已将日志强制写入到磁盘中才会向客户端发送事务确认。
在同步提交可用性模式下，副本联接到某个可用性组后，辅助数据库就会与对应的主数据库求得一致并进入 SYNCHRONIZED（已同步）状态。 只要一直在进行数据同步，辅助数据库就会保持 SYNCHRONIZED 状态。 这可确保对主数据库提交的每个事务也应用到对应的辅助数据库。在同步辅助副本上的每个辅助数据库之后，辅助副本的同步运行状态总体上将为 HEALTHY。
注意：
1. 如果为当前主副本配置了异步提交可用性模式，那么对所有的辅助副本都采集异步方式提交事务，不管这些副本各自的可用性模式，所以要保证同步提交模式那么主副本和辅助副本都需要配置同步提交模式。
2.如果主副本与某一同步辅助会话超时，暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。
三、故障转移模式
可用性副本的主角色和辅助角色在称为“故障转移” 的过程中通常是可互换的。 存在三种故障转移形式：自动故障转移（无数据丢失）、计划的手动故障转移（无数据丢失）和强制手动故障转移（可能丢失数据）。最后一种形式通常称为“强制故障转移”
1.自动故障转移所需条件
仅在以下条件下才发生自动故障转移：
- 存在自动故障转移集。 此自动故障转移集由主要副本和次要副本（自动故障转移目标）构成，主要副本和次要副本都配置为同步提交模式并且设置为自动故障转移。如果主要副本设置为手动故障转移，即使次要副本设置为自动故障转移，也无法发生自动故障转移
- 自动故障转移目标具有正常运行的同步状态（这指示故障转移目标上的每个辅助数据库都与其相应的主数据库同步）。
- Windows Server 故障转移群集 (WSFC) 群集具有仲裁。
- 主副本已变得不可用，并且由灵活的故障转移策略定义的故障转移条件级别已得到满足。
注意：
1.在数据库级别，诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏之类的数据库问题不会导致可用性组进行故障转移
2. AlwaysOn 可用性组监视自动故障转移集中两个副本的运行状况。 如果任一副本失败，则该可用性组的运行状况状态将设置为“严重”。 如果辅助副本失败，则自动故障转移将不可行，因为自动故障转移目标不可用。 如果主副本失败，则可用性组将故障转移到辅助副本。 在之前的主副本进入联机状态之前，将不存在任何自动故障转移目标。 在任一情况下，为了在连续出现失败这种近乎不可能发生的情况下确保可用性，我们建议您将其他辅助副本配置为自动故障转移目标。
3.要设置故障转移模式为“自动”的前提是可用性模式是“同步提交”。
4.如果主要副本设置为手动故障转移，即使次要副本设置为自动故障转移，也无法发生自动故障转移。
5.只能设置一个自动故障转移辅助副本
四、可读辅助副本
1.辅助角色支持的连接访问类型
1.无连接
不允许任何用户连接。 辅助数据库不可用于读访问。 这是辅助角色中的默认行为。
2.仅读意向连接
辅助数据库仅适用于其 Application Intent 连接属性设置为 ReadOnly 的连接（读意向连接）。
3.允许任何只读连接
辅助数据库全部可用于读访问连接。 此选项允许较低版本的客户端进行连接。
2.主角色支持的连接访问类型
1.允许所有连接
主数据库同时允许读写连接和只读连接。 这是主角色的默认行为。
2.仅允许读/写连接
当 Application Intent 连接属性设置为 ReadWrite 或未设置时，允许此连接。 不允许其 Application Intent 连接字符串关键字设置为 ReadOnly的连接。 仅允许读写连接可帮助防止您的客户错误地将读意向工作负荷连接到主副本。
注意：所有的限制只针对配置了可用性数据库，非可用性数据库不受这些连接的限制，配置读写分离至少得保证有两个可读副本，如果只有一个可读副本当可读副本变成了主副本之后会导致只读意向无副本可连接。
五、alwayson同步原理
1.任何一个SQL Server里都有个叫Log Writer的线程，当任何一个SQL用户提交一个数据修改事务时，它会负责把记录本次修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）,所以对于任何一个数据库，日志文件里都会有所有数据变化的记录。
2.对于配置为AlwaysOn主副本的数据库，SQL Server会为它建立一个叫Log Scanner的工作线程,这个线程专门负责将日志记录从日志缓冲区或者日志文件里中读出，打包成日志块，发送给各个辅助副本。由于它的不间断工作，才使主副本上的数据变化，可以不断地向辅助副本上传播。
3.在辅助副本上，同样会有两个线程，完成相应的数据更新动作，它们是固化（Harden）和重做（Redo）。固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本的磁盘上的日志文件里（这个过程被称为"固化"）。
而重做线程，则负责从磁盘上读取日志块，将日志记录翻译成数据修改操作，在辅助副本的数据库上完成。当重做线程完成其工作以后，辅助副本上的数据库就会跟主副本一致了。AlwaysOn就是通过这种机制，保持副本之间的同步。重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。
这些线程在工作上各自独立，以达到更高的效率。Log Scanner负责传送日志块，而无须等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据已经传递完毕，而无须等待重做完成。其设计目标，是尽可能地减少AlwaysOn所带来的额外操作对正常数据库操作的性能影响。
同步操作按下列方式维护：
- 从客户端收到事务后，主副本会将事务的日志写入事务日志，同时将该日志记录发送到辅助副本。
- 日志记录写入主数据库的事务日志后，事务将不能撤消，除非在此时故障转移到尚未收到该日志的辅助副本。主副本将等待来自同步提交辅助副本的确认。
- 辅助副本将强制写入日志（固化），并将确认消息返回给主副本。
- 收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。
六、会话超时机制
由于软错误不能由服务器实例直接检测到，因此，软错误可能导致一个可用性副本无限期等待会话中另一个可用性副本的响应。 为了防止发生这种情况， Always On 可用性组实施了会话超时机制，此机制基于以下条件：所连接的可用性副本会在每个打开的连接上按固定间隔发送 ping。 在超时期限内收到 ping 指示连接仍是开放的且服务器实例正在通过此连接进行通信。 收到 ping后副本将重置此连接上的超时计数器。主副本和辅助副本相互 ping 以指示它们仍处于活动状态， 会话超时限制是用户可配置的副本属性，默认值为 10 秒。
如果在会话超时期限内没有收到来自另一个副本的ping，该连接将超时、连接将关闭；超时的副本进入 DISCONNECTED 状态。 即使为同步提交模式的副本，事务也将不等待该副本重新连接暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。
总结
理解掌握这些概念对部署维护AlwaysOn集群非常的有帮助，可以结合测试对概念更深入的理解。
注意： 域服务器宕机了也不影响使用SQLServer身份验证连接副本或者监听器，Windows身份验证会受影响。所以只要不故障切换AD宕机了也不影响AlwaysOn群集的连接。这个功能减少了AlwaysON对AD的依赖，同时也减少建双域控的成本。
针对AlwaysON可用性组的先决条件和限制：https://msdn.microsoft.com/zh-cn/library/ff878487(v=sql.120).aspx
搭建和加入域参考：http://www.cnblogs.com/chenmh/p/4444168.html
搭建故障转移群集参考：http://www.cnblogs.com/chenmh/p/4479304.html
Alwayson搭建参考：http://www.cnblogs.com/chenmh/p/4484176.html
Alwayson配置两个节点加共享文件夹仲裁见证：http://www.cnblogs.com/chenmh/p/7156719.html
Alwayson读写分离参考：http://www.cnblogs.com/chenmh/p/7000236.html
----------------------------------
故障转移群集是一组相互独立的计算机，通过协同工作改善群集角色（以前也叫做群集的应用程序与服务）的可用性与扩展性。群集的服务器（叫做节点）通过物理线缆及软件连接在一起。如果一个或多个群集结点故障，其他节点可继续提供服务（这一过程叫做故障转移）。此外群集角色可通过主动监控以验证节点是否正常工作。如果没能正常工作，则会重启动或转移到其他节点。故障转移群集还提供了群集共享卷（CSV）功能，能为群集角色提供一致的分布式名称空间，供群集节点访问所有节点的共享存储。通过使用故障转移群集功能，用户感受到的服务中断可以降到最低。故障转移群集有多种典型实用场景：
1) 为应用程序，例如 Microsoft SQL Server 及 Hyper-V 虚拟机提供高可用或持续可用的文件共享存储。
2) 运行在物理服务器或 Hyper-V 服务器中所运行虚拟机内的高可用群集角色，例如群集DHCP服务器。
Windows Server 2012 R2故障转移群集特点：
1. 创建最多包含64个节点的群集，对管理员的环境进行扩展，而老版本只能包含16个节点。
2. 通过对基础架构进行扩展，每个群集最多可运行8,000个虚拟机，每个节点最多可运行1,024个虚拟机。
3. 具有控制虚拟机群集管理和其他群集角色的功能。
4. 相比Windows Server 2008 R2，增加了对于扩展文件服务器的支持。
5. 支持群集感知更新 (CAU)，群集感知更新 (CAU)是一个自动化的功能，允许更新自动应用于群集服务器中的主机操作系统，并且更新过程中的可用性损失极小或为零
6. 在运行 Windows Server 2012 R2的群集中，管理员可以配置对同时运行Windows Server 2012 R2的群集虚拟机上的服务进行监视。
从虚拟化的角度来看，故障转移群集提供了具备高可用性的虚拟机。如果物理宿主机故障，运行在该宿主机中的虚拟机也会中断。这会造成破坏性关闭，并导致虚拟机停机。然而由于物理节点是群集的一部分，因此剩余群集节点可通过协调将停机的虚拟机重新恢复，通过群集中的其他节点再次将其快速启动。这一过程是自动化的，无需 IT 管理员干预，因此可确保群集中运行的负载比独立物理服务器中运行的负载具备更高级别的可用性。
在 Windows Server 2008 R2 及老版本中，在群集中运行虚拟机要求虚拟机必须使用共享的存储。这个场景中的共享存储意味着 iSCSI 或光纤通道连接的 SAN。在 Windows Server 2012 及后续的 Windows Server 2012 R2 中，故障转移群集可支持将虚拟机放置在文件共享中，使用 SMB 3.0 协议通过网络访问。这样管理员在部署基础结构时可获得更大程度的灵活性，并能简化部署与管理体验。
对于依然希望利用 SAN 存储作为共享存储解决方案的客户，强烈建议将 SAN 的 LUN 直接呈现给群集的每个节点，并将这些 LUN 作为群集共享卷使用。
一、 群集共享卷：
Windows Server 2012 R2 故障转移群集的群集共享卷（CSV）功能使得群集的多个节点可以同时读写访问同一个 LUN（磁盘）中供应的 NTFS 卷。通过使用 CSV，群集角色可从一个节点快速故障转移至其他节点，同时无需更改驱动器的所有权，也无需断开并重新加载卷。CSV 还有助于简化故障转移群集中大量 LUN 的管理工作。对于群集中的每个节点，CSV 都呈现为一致的文件命名空间，例如 C:\ClusterStorage\Volume1。CSV 以 NTFS 为基础提供了针对一般用途的群集文件系统，并且并非只能用于指定的群集负载。（在 Windows Server 2008 R2 中，CSV 只支持 Hyper-V 负载）。CSV 的应用包括：
1) 群集的虚拟磁盘（VHD）文件，将其用于群集的 Hyper-V 虚拟机。
2) 用横向扩展文件共享存储应用程序数据，供横向扩展文件服务器角色使用。这类应用程序数的例子包括 Hyper-V 虚拟机文件及 Microsoft SQL Server 数据。
1. 优化的 CSV 放置策略：
在故障转移群集中，有一个节点被看做该 CSV 的所有者或“协调节点”。协调节点拥有关联了逻辑单元号（LUN）的物理磁盘资源。所有针对文件系统的 I/O 操作都需要通过协调节点进行。分布式的 CSV 所有权可改善磁盘性能，因为有助于对磁盘 I/O 进行负载平衡。
因为 CSV 所有权可以跨越所有群集节点进行平衡，节点所拥有的 CSV 数量将不再不对称，因此如果一个节点故障，CSV 所有权的过渡将变得更高效。对于使用存储空间的横向扩展文件服务器群集，该功能非常重要，因为可确保存储空间所有权的分散。
此外在 Windows Server 2012 R2 中，针对某些情况，例如 CSV 故障转移、节点重新加入群集、为群集添加新节点、重启动群集节点，或在关闭后重新启动故障转移群集，所有权可自动重新进行平衡。
2. 增强 CSV 的适应性：Windows Server 2012 R2 包含下列有关 CSV 适应性的改进：
1) 每个故障转移群集节点多个服务器服务实例。默认实例负责处理来自服务器消息块（SMB）客户端的传入通讯并访问文件共享，辅助 CSV 实例处理节点间的 CSV 通讯。这种节点间通讯包括元数据访问及 I/O 通讯重定向。
2) 服务器服务的 CSV 健康度监控。
CSV 使用 SMB 作为群集节点间 I/O 转发的传输方式，并用于实现元数据更新。如果服务器服务变得不够健康，就会影响 I/O 性能以及访问存储的能力。因为现在群集节点可以包含多个服务器服务实例，因此如果默认实例遇到问题，CSV 将获得更大程度的适应性。此外这一变化也改善了 CSV 节点间 SMB 通讯的扩展性。
如果服务器服务变得不够健康，可能会影响到 CSV 协调节点接受其他节点 I/O 请求的能力，以及执行元数据更新的操作。在 Windows Server 2012 R2 中，如果一个节点的服务器服务变得不够健康，CSV 所有权会自动转移到其他节点，以保障适应性。
在 Windows Server 2012 中，每个节点的服务器服务只有一个实例，同时服务器服务也不受监控。
二、 Active Directory 分离的群集
在 Windows Server 2012 R2 中，可在不依赖 Active Directory 域服务（AD DS）作为网络名的情况下部署故障转移群集。这种群集也叫 Active Directory 分离的群集。在使用这种方式部署群集时，群集网络名称（也叫做管理访问点）及客户端访问点所用的任何群集节点的网络名称都需要在域名系统（DNS）中注册。不过在 AD DS 中无需为这样的群集创建计算机对象，包括群集本身的计算机对象（也叫做群集名称对象，即 CNO），及在 AD DS 中为任何客户端访问点访问群集角色时创建的对象（也叫做虚拟计算机对象，即 VCO）。（群集节点依然需要加入 Active Directory 域。）
通过这种部署方式，即可在原本不具备创建计算机对象所需权限的 AD DS，或无需求助 Active Directory 管理员在 AD DS中更新计算机对象的情况下直接创建故障转移群集。此外也无需为这样的群集管理并维护群集计算机对象。例如，可以避免遇到 Active Directory 管理员无意中删除群集计算机对象造成的问题，这种问题会对群集负载的可用性产生极大影响。
用于创建 Active Directory 分离群集的选项并未包含在 Windows Server 2012 中。在 Windows Server 2012 中，只能在 DNS 及 AD DS 中都存在群集网络名的情况下部署故障转移群集。
Active Directory 分离的群集使用 Kerberos 对群集内通讯进行身份验证。然而如果需要针对群集网络名进行身份验证，此时群集将使用 NTLM 协议。
Windows Server 2012 与 Windows Server 2012 R2 群集还能不依赖 AD DS 启动，因此对于在群集中运行虚拟化域控制器的数据中心，可提供更高程度的灵活性。
三、 群集仲裁及动态见证
群集的仲裁是由投票元素的数量决定的，该机制确保了群集能够正常启动并持续运行。一般来说，群集中的每个节点都有一个仲裁投票，此外仲裁见证（在配置后）可以有额外的一张仲裁投票。在 Windows Server 2012 中，可以为每个群集配置一个仲裁见证。仲裁见证可以是指定的磁盘资源或文件共享资源。每个元素可通过投出自己的一“票”确定群集是否可运行。群集能否正常工作的仲裁结果是由活跃群集关系中大多数投票元素决定的。
为改善群集以及群集中所托管角色的可用性，群集仲裁配置的设置一定要慎重。
群集仲裁配置将直接影响整个群集的高可用性，原因在于：
1) 有助于确保在活跃成员关系产生变化后，故障转移群集依然能正常启动并持续运行。成员关系的变化可能是由于节点计划内或计划外关机，或节点与群集存储之间连接的中断导致的。
2) 当节点的子集无法与节点的其他子集（分裂式群集）通讯时，群集仲裁配置有助于确保群集中只有一个子集可以持续运行。缺乏足够仲裁投票的子集将停止作为群集继续运行。具备大多数仲裁投票的子集可继续承担群集角色。这样即可避免群集产生分区，并确保同一个应用程序不会同时由多个分区承载。
群集环境下，使用群集完整功能的运行还取决于下列因素：
1）群集结点间的网络连接。
2）承载群集资源的每个节点所放置的容量。
3）群集角色的优先级设置。
1. 见证配置：
作为一项常规规则，在配置仲裁时，群集中的投票元素必须是奇数。因此如果群集包含偶数个投票节点，就必须配置磁盘见证或文件共享见证。群集可承受额外一个节点的故障。此外添加见证投票使得群集能够在半数节点同时故障或断开的情况下继续正常工作。
如果所有节点都能访问磁盘，则通常建议使用磁盘见证；如果需要通过复制存储实现多站点灾难恢复，则建议使用文件共享见证。只有存储供应商支持从所有站点读写访问复制存储时，才可以对包含复制存储的环境配置磁盘见证。
2. 节点投票的分配“
在 Windows Server 2012 中，作为一种高级仲裁配置选项，管理员可以选择针对每个节点分配或取消仲裁投票。默认情况下，所有节点都可投票，无论投票如何分配，所有节点都能在群集中正常工作，获得群集数据库的更新，并可承载应用程序。
在某些灾难恢复配置下，管理员可能希望取消某些节点的投票。例如在多站点群集中，可以取消备份站点内节点的投票权，让这些节点不影响仲裁的计算结果。但只建议对跨站点手工故障转移的环境使用这种方式。
要查看节点配置的投票选项，可使用 Get-ClusterNode Windows PowerShell cmdlet 查看群集节点的通用属性 NodeWeight。如果值为“0”，意味着该节点无法参与仲裁投票；如果值为“1”则意味着该节点将参与仲裁投票，并且受到群集的管理。所有群集节点的投票分配情况可使用 Validate Cluster Quorum 验证测试加以验证。
3. 动态仲裁管理：
在 Windows Server 2012 中，作为一个高级仲裁配置选项，管理员可以选择启用群集的动态仲裁管理。在启用该选项后，群集可根据每个节点的状态动态管理节点的投票分配情况。离开活跃群集关系的节点投票会被自动取消，重新加入群集的节点可重新获得投票。默认情况下动态仲裁管理已被启用。注意 – 通过动态仲裁管理，群集仲裁的大多数将由任意时刻位于群集活跃成员关系内的节点决定。这一点与 Windows Server 2008 R2 的群集仲裁有很大不同，以前的仲裁大多数是固定的，取决于初始群集配置。通过动态仲裁管理，群集还可以通过最后一个残存的群集节点正常运行。通过动态调整仲裁大多数需求，群集可持续承受节点的关机，直到剩下最后一个节点。
群集为节点分配的动态投票可通过使用 Get-ClusterNode Windows PowerShell cmdlet 查看群集节点的通用属性 DynamicWeight 加以验证。如果值为“0”，意味着节点没有仲裁投票；值为“1”意味着节点有仲裁投票。
4. 动态见证：
在 Windows Server 2012 R2 中，如果群集被配置为使用动态仲裁（默认设置），见证投票也将根据当前群集关系中投票节点的数量进行动态调整。如果有奇数个投票，仲裁见证将不参与投票；如果有偶数个投票，仲裁见证将参与投票。
正如在上图中看到的，对于这个包含 64 的节点的群集，我们使用了“节点及磁盘大多数”仲裁配置，并且这也是默认的推荐设置，但这一共就有了 64 张投票 – 偶数个。我们需要奇数个投票，因此使用见证磁盘作为第 65 个投票。然而如果即将失去一个节点，最后又剩下 63 个运行中的节点：
在本例中，负载已经故障转移到其他节点，已关机节点的投票被取消。这样我们就剩下 63 个节点，每个节点都有一票，再加上见证磁盘也有一票。这样总共就有 64 张投票 – 又是偶数个。上文已经提过，我们需要确保投票数量为奇数，而在 Windows Server 2012 R2 中，我们可以自动将见证磁盘的票数调整为 0。群集仲裁也会自动调整，这一次将变为“节点大多数”。
仲裁见证投票也能根据见证资源的健康程度动态进行调整。如果见证资源脱机或故障，群集会将见证投票设置为“0”。
动态见证功能极大降低了由于见证资源故障导致群集停机的风险。群集可根据目前可用的节点投票数量决定是否使用见证投票。
这一改动也极大简化了群集见证的配置。管理员不再需要决定是否配置仲裁见证，因为 Windows Server 2012 R2 的推荐配置始终包含仲裁见证。群集可以自动决定何时使用见证。
四、 关闭时清空虚拟机
在 Windows Server 2012 中，如果关闭群集结点前没有清空节点，虚拟机会被切换至保存状态，随后转移到其他节点上恢复。这意味着虚拟机的可用性将产生中断。如果保存虚拟机状态所需时间太长，则可将虚拟机关闭，然后在其他节点上重启动。不过在 Windows Server 2012 R2 中，群集可自动在关闭前将运行中的虚拟机实时迁移到其他节点。
这一变化提供了一种更安全的机制，可确保服务器关闭（或任何需要关闭群集服务的情况）不会造成虚拟机的计划外停机。这样的设计可提高来宾操作系统内所运行应用程序的可用性。
微软官方建议管理员在关闭群集节点前先将其置于维护模式，或将所有虚拟机移动到其他节点。这是清空运行中群集角色最安全的方式。
要启用或禁用该功能，需要配置 DrainOnShutdown 群集通用属性。默认情况下该属性已启用（值为“1”）。
五、 虚拟机网络健康度检测
在 Windows Server 2012 中，如果发生虚拟机层面的网络中断，此时虽然该虚拟机对用户不可用，但实际上依然在计算机上正常运行。
在 Windows Server 2012 R2 中，虚拟机的设置界面新增了一个保护网络选项。如果受保护的虚拟网络断开，群集会将受影响的虚拟机实时迁移到外部虚拟网络可用的其他宿主机。为此群集节点间须有多个网络路径。
该设置位于网络适配器的高级功能下。默认情况下此设置已被启用。管理员可以针对每个虚拟机的每个网络修改该设置，因此如果有低优先级网络，例如用于测试或备份的网络，可以选择在这样的网络断开后不对虚拟机进行实时迁移。
如果没有可连接到群集其他节点的可用网络，群集会将此节点从群集成员关系中删除，转移虚拟机文件的所有权，然后在其他节点上重启动这些虚拟机。
这一变化提高了虚拟机遇到网络问题的可用性。如果进行实时迁移，由于实时迁移可维持虚拟机的会话状态，因此不会产生停机。
六、 增强的群集仪表板
在 Windows Server 2012 中，需要点击每个故障转移群集的名称才能查看状态信息。在 Windows Server 2012 R2 中，故障转移群集管理器新增的群集仪表板可供管理员快速查看所有被管理故障转移群集的健康度状态。管理员可以看到故障转移群集的名称，并通过图标了解群集的运行状态，群集角色的数量与状态，以及节点状态和事件状态。
如果要管理多个故障转移群集，该仪表板可让管理员更方便地快速查看故障转移群集的健康度。
七、 虚拟机监控
在运行 Windows Server 2012 与 Windows Server 2012 R2 的群集中，管理员可监控同样运行 Windows Server 2012 或 Windows Server 2012 R2 的群集虚拟机内的服务。管理员可以监控虚拟机内的任何 Windows 服务（例如 SQL 或 IIS），或虚拟机发生的任何 ETW 事件。当管理员监控的条件被触发后，群集服务会在宿主机的错误日志中加以记录，并执行恢复操作。这些操作可能是重启动服务，或在其他节点上重启动或移动群集虚拟机（取决于服务重启动设置集群及故障转移设置）。
只能在列表中看到使用自己的进程所运行的服务，例如 SQL、Exchange，但 IIS 与 Print Spooler 服务不受此规则限制。不过可以通过使用 Windows PowerShell Add-ClusterVMMonitoredItem cmdlet 设置监控任何 NT 服务 – 该命令无任何限制：
Add-ClusterVMMonitoredItem –VirtualMachine BJ-VM-03 -Service spooler
当被监控的服务遇到非预期故障，后续的恢复操作将由该服务的恢复操作决定。这些恢复操作可在来宾系统内部使用 Service Control Manager 查看并配置。在下图所示的例子中，在服务首次和第二次故障后，Service Control Manager 将重启动这些服务，如果再次故障，Service Control Manager 将不执行任何操作，并将恢复操作交由宿主机所运行的群集服务负责处理。
群集服务通过定期健康度检查监控群集虚拟机的状态。当群集服务确定某个虚拟机处于“关键”状态，例如虚拟机内部的应用程序或服务处于不健康状态，群集服务将执行下列恢复操作：
1) 宿主机记录 ID 1250 事件 – 随后可通过集中化的监控解决方案加以监控，例如 System Center Operations Manager。
2) 故障转移群集管理器内的虚拟机状态将显示该虚拟机处于“应用程序关键”状态。
3) 针对“应用程序关键”状态的虚拟机执行恢复操作。首先在同一个节点上重启动该虚拟机。请注意 – 虚拟机的重启动是强制不允许取消的。如果第二次故障，虚拟机将重启动并故障转移到群集的其他节点。请注意 – 故障转移，或在同节点上重启动，这个决定是可配置的，并可由虚拟机的故障转移属性决定。
八、 故障转移优先级，相关性及反相关性
1. 优先级
在 Windows Server 2012 及后续的 Windows Server 2012 R2 中，故障转移提供的新功能使得管理员能够定义群集中虚拟机的启动顺序，这样一旦遇到故障，有大量虚拟机需要尽快重启动，取决于选项设置，部分虚拟机可被优先进行重启动处理。
该功能可以帮助管理员确保如果故障转移导致资源占用率过高，最重要的虚拟机始终可以优先获得所需的全部资源，随后才开始处理重要性次高的虚拟机。
另外在节点故障后，如果高优先级虚拟机无法获得所需的足够内存和其他资源以完成启动操作，群集服务会暂时让低优先级的虚拟机脱机。随后释放出来的资源可分配给高优先级虚拟机。在必要时，可抢占启动最低优先级的虚拟机，随后继续启动高优先级虚拟机。抢占启动的虚拟机会按照优先级顺序重启动。
2. 相关性
在 Windows Server 2012 与 Windows Server 2012 R2 故障转移群集中，管理员可以配置首选和可能所有者。
对于特定虚拟机（从技术上说，可以是任何群集组），可对故障转移时所用节点的顺序进行配置。假设该虚拟机通常在节点 A 上运行，管理员希望在可行的情况下尽量将其转移到节点 C，那么就可通过首选所有者选项定义最先转移到的节点，随后转移到的节点，以及后续转移到的节点。这是一种优先级列表，群集将通过该列表确定虚拟机的放置位置。因此管理员可以明确控制虚拟机的位置。
另一方面，可能的所有者则是指，对于特定虚拟机（从技术上说，可以是任何群集资源），可以配置虚拟机在故障转移时可能放置到的节点。默认情况下这是指所有节点，但如果不希望将任何虚拟机故障转移到某个特定节点，则可将其从可能的所有者列表中删除，防止转移到该节点。
3. 反相关性
可能的所有者是一种尽量确保相关虚拟机相关虚拟机分散在不同节点上的做法，每个虚拟机都有相对独立的可能的所有者，不过还有另一种方式实现这一点。
AntiAffinityClassNames 是另一个群集组属性，Windows 故障转移群集使用该属性确定不应位于同一个节点的群集组。在使用群集的 Hyper-V 环境时，群机组与虚拟机之间存在 1:1 的关系，因此可以使用 AntiAffinityClassNames 属性为虚拟机配置反相关性。
一旦配置完毕，故障转移群集会尽可能试图确保属于同一个组的虚拟机分散到群集不同节点上。与故障转移优先级与首选的和可能的所有者功能配合使用后，即可更细化地控制重要虚拟化负载的放置。
九、 群集感知更新
在老版本 Windows Server 中，服务器更新工具（例如 WSUS）无法考虑一组服务器可能是高可用群集成员这种情况。由于高可用群集的目的是为群集中托管的服务提供高可用性，因此绝不能同时对群集的所有节点安装补丁。故障转移群集的补丁安装工作通常需要分批手工进行，或使用专门的脚本/工具，同时需要管理员加以密切关注，在每月一次短暂的维护窗口内为所有节点成功安装补丁。
群集感知更新（CAU）是 Windows Server 2012 R2 内建的一个重要功能，解决了这个问题。CAU 可供管理员对群集服务器进行更新，而更新过程几乎不会影响可用性，或者只产生最少量的影响。在进行更新的过程中，CAU 会用透明的方式将群集每个节点设置为节点维护模式，将“群集角色”临时故障转移到其他节点，为节点安装更新和其他必要内容，需要时执行重启动操作，让节点退出维护模式，将最初的群集角色重新转移到这个节点上，并对下一个节点执行更新。CAU 的工作与具体负载无关，非常适合 Hyper-V 及各种文件服务器负载。
尤其是从 Hyper-V 的角度来看，CAU 能与故障转移群集功能配合使用，将运行中的虚拟机迁移到不同物理节点，这样即可确保虚拟机中运行的重要应用程序和负载不会停机，同时宿主机设施也能安装必要的更新，随时保持最新状态。
管理员触发 CAU 扫描后，CAU 会配合节点本身令其针对更新源执行更新检查工作，例如更新源可能是 Microsoft Update、Windows Update，或 WSUS。
CAU 可帮助企业促进 IT 进程的一致性。针对不同类型的故障转移群集可创建更新运行配置文件，并能通过文件共享集中管理，以确保整个 IT 机构内所部署的 CAU 能用一致的方式应用更新，就算群集是由其他业务线或管理员负责管理的也不受影响。
更新的运行可安排计划，每天、每周，或每月进行，这样即可确保群集的更新与其他 IT 管理流程保持一致，而 CAU 提供了一种可扩展架构，能用可感知群集的方式对群集软件清单进行更新。这样开发商即可对并非通过 Windows Update 或 Microsoft Update 发布的软件更新，或并非来自微软的更新安装情况进行协调，例如非微软设备的驱动更新。
CAU 的自行更新模式促成了一种“一体式群集”装置（一套运行 Windows Server 2012 与 Windows Server 2012 R2，通常安装到一个机箱内的群集环境）自行更新操作。一般来说，这类装置都部署在分支办公室，缺乏管理群集的本地 IT 人员。自行更新模式能为这类环境提供巨大的价值。
CAU 有两种模式：下文第一张图所示的自行更新模式，以及第二张图所示的远程更新模式。
在自行更新模式中，需要在一个节点上运行 CAU 角色，并充当更新工作的协调者。更新协调者这个节点确保了整个群集都能顺利安装更新。CAU 角色也是可以感知群集的，因此 CAU 更新协调者角色可由多个节点承担 – 但同一时间只能有一个节点是更新协调者。
另一方面，远程更新模式使得运行 Windows Server 2012、Windows Server 2012 R2、Windows 8 或 Windows 8.1 的远程计算机可以充当 CAU 更新协调者。这种方法最适合使用 CAU 对 Windows Server 2012/R2 服务器核心操作系统安装更新，并且需要实时看到更新进度的情况。
要部署故障转移群集，并充分利用故障转移群集的其他功能，需满足下列条件：
1. 带 Hyper-V 的 Windows Server 2012 R2 或 Hyper-V Server 2012 R2。
2. 对于群集共享卷，需要共享存储，并通过 iSCSI 或光纤通道连接。
3. 对于虚拟机监控，需要创建相应的防火墙例外，并提供所需的域配置。
4. 对于群集感知更新，需要 WSUS 基础结构，或从一个群集节点连接到互联网以访问 Microsoft/Windows Update。
十、 来宾群集
在 Windows Server 2012 Hyper-V 中，微软为虚拟机本身的虚拟化工作提供了完整的支持，从群集到来宾操作系统全都包含在内。例如群集的 SQL AlwaysOn 配置，其本身就需要多个节点，所有节点都为虚拟机，并且还需要访问共享存储。该配置看起来类似下图所示：
在上述例子中有一个简单的三节点 Hyper-V 物理群集，在该群集基础上使用两个虚拟机创建了两节点来宾群集，这些节点都能直接访问共享存储。使用共享存储的来宾群集在微软平台中可充分利用多种不同存储选项所提供的优势。举例来说，如果使用 SMB 存储作为 Hyper-V 群集的主要存储方式，则该 SMB 存储还可通过网络供应给虚拟机使用。通过这种方式，虚拟机即可借助虚拟网络适配器访问 iSCSI 存储。然而这些场景都需要通过虚拟网络适配器将底层存储设施直接提供给虚拟机，而非使用共享存储上保存的 VHD 或 VHDX 文件。
Windows Server 2012 中首次引入了虚拟光纤通道。正如上文介绍的，通过该技术可将虚拟光线存储直接供应给虚拟机，并能通过访问共享存储直接构建来宾群集。
上文曾提过，来宾群集配置可得到微软的完整支持，并可配合其他功能，例如实时迁移与动态内存等功能使用，这意味着客户能够将群集负载虚拟化，并且不会影响密度和敏捷度等重要特性。此外来宾群集能通过故障转移优先级、相关性，及反相关性等上文介绍的功能获益，可确保来宾群集节点能以在相互之间，以及与底层物理宿主机之间最优化方式放置。
来宾群集的优势是可提供额外的一层适应性。如果物理宿主机故障，只会导致来宾群集的一个节点子集遇到故障，来宾群集所提供的应用程序级别的适应性依然能够快速恢复负载。
当物理节点故障了，之前在该节点运行的虚拟机也停止运行，但物理 Hyper-V 群集可确保虚拟机在其他节点所运行的来宾群集虚拟机中快速重启动。应用程序级别的适应性确保了从整体来看，应用程序或负载只会经历一个短时间的停机。
然而挑战之处在于，在这些配置中，底层存储（FC、iSCSI、SMB）需要直接供应给虚拟机。在私有或公共云环境中，通常需要为用户或租户管理员隐藏底层设施细节。
PS：文章在写作的同时参考有微软TechNet。
转载于:https://blog.51cto.com/ericxuting/1597930
----
SQL Server AlwaysOn搭建
2015-05-07 11:48 pursuer.chen 阅读(6149) 评论(4) 编辑 收藏
标签：SQL SERVER/MSSQL SERVER/数据库/DBA/高性能解决方案
概述
环境：
域服务器:windows server 2008 R2 SP1,192.168.2.10
DNS:192.168.2.10
CLU11, windows server 2008 R2 SP1 ,192.168.2.11,SQL Server 2012 Enterprise (64-bit)
CLU12, windows server 2008 R2 SP1 ,192.168.2.12,SQL Server 2012 Enterprise (64-bit)
CLU13, windows server 2008 R2 SP1 ,192.168.2.13,SQL Server 2012 Enterprise (64-bit)
搭建前提：
1.将域用户（需要域管理权限）配置为SQLServer服务和代理的启动用户，同时将域用户加入到SQLServer登入用户并赋予sysadmin服务器角色。
2.将域用户加入到在每台SQLServer服务器的本地用户administrator组中
3.先安装好SQLServer实例再搭建故障转移群集，否则如果在安装的过程中有群集节点故障可能导致安装失败。同时安装SQLServer必须使用administrator本地管理员用户进行安装，其它用户可能导致某些功能安装失败！！！
4.将1433、5022端口加入到防火墙
5.由于alwayson对于故障转移群集依赖非常的高，如果有节点由于网络原因节点连接不上会导致alwayson添加数据库失败，保证数据库服务器和域服务器之间的网络顺畅
6.使用windows身份验证的域用户搭建alwayson
目录
启动AlwaysOn高可用性
1.将cmh\administrator加入三台服务器的登入名中，服务器角色选择sysadmin
2.打开SQL Server配置管理器，配置域用户为启动服务器账户
3.启用AlwaysOn可用性组
配置AlwaysOn高可用性
1.打开AlwaysOn可用性组-新建可用性组向导
2.下一步
3.输入可用性组名称
4.选择可用性组的数据库，数据库必须要是完整恢复模式并且要先进行一次完整备份
5.添加副本
6.由于5022号端口已经在使用，这里就配置5023号端口
7.选择默认配置-首选辅助副本
8.配置监听器，暂时不配置最后来配置。
9.配置备份共享路径；在CLU12服务器本地文件夹上新建Alwayson并且共享该文件夹，权限配置为读写。
为了保证共享存储不会因为单一节点故障应该配置可靠性共享存储。
10.验证配置结果
11.完成
12.关闭
13.添加副本
14.可读副本选择“是”，同时配置端点为5023，默认是5022
15.配置共享存储路径
16.
17.
18.添加侦听器
19.端口选择1433，网络模式选择静态IP,输入侦听IP地址
20.在域控制器中查看计算机
21.在域控制器中查看DNS
22.查看配置的AlwaysOn
23.查看群集
24.查看监听显示面板
删除整个AlwaysOn和故障转移集群
如果要将整个集群全部删除需要注意删除的顺序。
一、删除AlwaysOn
1.删除AlwaysOn所有辅助副本
2.删除AlwaysOn可用性组
二、删除故障转移集群
1.从故障转移集群中删除所有非主节点
2.当最后只剩下主节点时右键集群-更多操作-破坏集群
3.删除域服务器中的计算机用户和DNS中对应故障转移集群和AlwaysOn监听
4.在SQLServer启动服务中将alwaysOn启用功能勾选去掉。
总结
在防火墙中需要将1433,5022号端口添加例外。
alwayson有一定的负载均衡能力，通过配置只读路由辅助副本可以分担一定的读取，而数据库镜像作为镜像的数据库是无法访问，这也是alwayson相对于数据库镜像的优势。
搭建和加入域参考：http://www.cnblogs.com/chenmh/p/4444168.html
搭建故障转移群集参考：http://www.cnblogs.com/chenmh/p/4479304.html
Alwayson读写分离参考：http://www.cnblogs.com/chenmh/p/7000236.html
Alwayson概念总结参考：http://www.cnblogs.com/chenmh/p/6972007.html