标签：故障转移 clust ilo 基础 失败 win 故障排除 比较 dia
资源组是由一个或多个资源组成的组，WSFC的故障转移是以资源组为单位的，资源组中的资源是相互依赖的。一个资源所依赖的其他资源必须和该资源处于同一个资源组，跨资源组的依赖关系是不存在的。在任何时刻，每个资源组都仅属于集群中的一个结点，该结点就是资源组的活跃结点（Active Node），由活跃结点为应用程序提供服务。AlwaysOn建立在WSFC的健康检测和故障转移的特性之上，和故障转移集群有了不可分割的关系，因此，从底层的集群资源来理解可用性组，知其然知，其所以然，有助于更好地维护AlwaysOn。
一，AlwaysOn的可用性组是集群的资源组
AlwaysOn的可用性组（Availability Group）是集群的资源组，其资源类型是“SQL Server Availability Group”，由于，WSFC的故障转移是以资源组为单位的，因此，AlwaysOn的每次故障转移都会将整个可用性组里的数据库一起转移。
1，查看集群的资源组
打开故障转移集群管理器（Failover Cluster Manager），选中集群结点，点开Roles，集群的每个角色就是一个资源组，在右边的资源组监控器面板中，能够看到创建成功的可用性组 TestAG，角色类型（Type）是Other；
2，资源组的故障转移属性
右击角色的属性，在Failover Tab中，查看集群的故障转移属性的设置，默认设置如下图：
两者的区别是：
3，切换到General Tab
首选结点（Preferred Owners）选项的默认设置是勾选集群中的所有结点，优先顺序是从上到下，第一个勾选的结点是最优先结点（Most Preferred Owners）。
在发生故障转移之后，如果最优先结点恢复健康，那么故障恢复（Failback）将资源组移回到最优先选结点；
二，从集群资源的角度来看待SQL Server 可用性组
由于AlwaysOn 可用性组建立在故障转移集群之上，可用性组就是Windows 集群的资源组，在故障转移集群管理器中，通过配置集群资源的属性，控制AlwaysOn 可用性组的健康检测和故障转移特性的底层特性。
点击角色TestAG下方面板Resource选项卡，能够看到该资源组拥有两个资源：可用性组TestAG和侦听器TestListener。这两个资源在创建AlwaysOn时，由系统自动创建。每个资源，都有Status标识该资源的健康状态。
在Server Name 选项卡中，列出AlwaysOn可用性组中包含的Listener，该Listener 的集群资源类型是Network Name，这就是说，AlwaysOn不使用Windows集群的虚拟网络名和虚拟IP地址，而是使用Listener来作为访问可用性组的网络接口。无论Windows 集群的虚拟网络名，还是AlwaysOn的侦听器Listener，其资源类型都是相同的（Network Name），都有虚拟网络名（DNS Name）和虚拟IP地址，只是一个服务于Windows集群，一个服务于AlwaysOn，其行为是相同的：
1，集群资源（可用性组）的属性
TestAG资源的类型是SQL Server Availability Group，状态是Online
2，切换到Dependencies Tab，查看资源的依赖关系
资源组中的资源是相互依赖的，一个资源所依赖的其他资源必须和该资源处于同一个资源组，跨资源组的依赖关系是不存在的。资源TestAG 和 资源Server Name之间是“and”的关系，这就是说，只有这两个资源都处于Online状态之后，整个资源组才处于可用的Online状态。
3，切换到Policies Tab，查看资源出现故障时，集群监控器的响应策略
该选项卡的选项决定了资源发生故障转移时的行为，建议保留其默认设置，默认设置是当资源出现故障时，会在15分钟内尝试在当前结点重启（一般是立即尝试重启，不需要等待15分钟），第一次尝试重启失败，就会将整个资源组转移到其他的结点上，默认的关键选项：
选项“If resource fails, attempt restart on current node”：选择该选项，WSFC在检测到当前资源出现故障后，尝试在当前结点重启；
选项 “If restart is unsuccessufll, fail over all resources in this service or application” ：勾选该选项，WSFC在第一次重启失败后，将整个资源组转移到集群中的其他结点上；如果不勾选该选项，该资源出现故障，并不会导致整个资源组的故障转移。
4，切换到Advanced Policies Tab
配置持有资源的集群结点：在Possible Owners 选项卡中，罗列出当前资源能够转移到的结点，也就是指定哪些结点会是当前资源的拥有者；如果一个结点没有被勾选，就意味着当前资源不会在该结点上运行。
配置检测资源健康的时间间隔：WSFC为了检测每个资源是否工作正常，会使用不同的时间间隔来做两种不同程度的检查，对于SQL Server可用组资源类型：
第三章节会详细描述集群资源的检查检测。
5，切换到Properties Tab，查看和配置资源的私有属性
HealthCheckTimeout属性：健康检测的超时时间，默认设置是30000ms，这就是说，WSFC在认定SQL Server 可用性组资源出现故障之前，需要等待诊断存储过程（sp_server_diagnostics）返回诊断信息的最长时间间隔 ；
诊断存储过程对系统进行诊断的时间间隔的公式是diagnostics_internal=max(5s, HealthCheckTimeout/3)，这就是说，sp_server_diagnostics的查询时间间隔是HealthCheckTimeout/3，但不会少于5秒。WSFC会持续收到诊断存储过程返回的结果，如果诊断存储过程在diagnostics_internal时间范围内没有返回结果，就会产生超时错误，WSFC开始0到2次等待，如果在HealthCheckTimeout属性规定的时间范围内，诊断存储过程都没有返回结果，那么WSFC判定健康检查失败，该资源出现故障。也就是说，WSFC最多等待3次诊断存储过程（sp_server_diagnostics）超时未返回，才会判定资源出现故障。
FailureConditionLevel属性：设置资源出现故障的级别，从0到5共6个级别，默认值是3。对于级别1~5，每个级别除了当前级别的条件外，还包括之前级别的所有条件，这意味着级别越高，发生故障转移或重新启动的概率就越大。级别0表示无论发生任何故障，WSFC都不会自动转移或重新启动。
在默认的FailureConditionLevel=3设置下，WSFC连接到可用性主副本上的SQL Server实例，并执行存储过程 sp_server_diagnostics获得可用性组的诊断信息，藉此评估可用组的健康状况。WSFC将存储过程 sp_server_diagnostics的评估结果和FailureConditionLevel属性值相比较，如果满足条件，那么WSFC判定当前的主副本出现故障，并将可用性组切换到新的可用性副本上；
6，故障检测存储过程（sp_server_diagnostics）
系统存储过程 sys.sp_server_diagnostics 用于诊断系统的健康状态，发现潜在的故障，该SP返回的诊断信息对于WSFC判断系统是否执行故障转移是至关重要的，该存储过程只有一个参数：重复间隔的秒数，返回两个重要的字段：
sp_server_diagnostics [@repeat_interval =] ‘repeat_interval_in_seconds‘
诊断信息和FailureConditionLevel的关系是：
故障检测存储过程（sp_server_diagnostics）返回的组件和可能出现的状态之间的关系如下图:
可以看到，只有system，resource和query_processing这三个组件会出现“Error”的运行状态，用于和FailureConditionLevel属性值比较，用作故障转移的条件；而 io_subsystem 的状态只能是Clean或Warning，Events 的状态只能是Unknowns。用户可以手动执行该存储过程，查看服务器诊断的结果：
EXEC sys.sp_server_diagnostics
三，集群资源的健康检测
集群中的每个资源都有一个资源类型，WSFC根据不同类型的资源，使用不同的方式进行Isalive和Looksalive检查，一般会把SQL Server Availability Group资源类型配置成“If resource fails, attempt restart on current node” 和 “If restart is unsuccessufll, fail over all resources in this service or application”模式，即在资源的Policies 选项卡中勾选相应的选项：
Looksalive检查：WSFC检查活跃结点的SQL Server服务（Service Name 是 MSSQLServer）是否处于“启动状态”，根据SQL Server Availability Group资源的Advance Polices 选项卡中的设置，这个检查默认每5s做一次；
Isalive检查：WSFC连接活跃结点，并在活跃结点中执行TSQL查询语句（select @@ServerName），如果活跃结点返回查询的结果，那么Isalive检查成功；如果活跃结点的SQL Server实例连接不上，或没有返回查询结果，那么Isalive检查失败，根据SQL Server Availability Group资源的Advance Polices选项卡中的设置，这个检查默认每30s做一次。
每执行6次Looksalive检查，就会执行一次Isalive检查，WSFC之所以需要对SQL Server 可用性组执行Isalive检查，是因为即使SQL Server 服务处于正在运行（Running）状态，也不能说明SQL Server 可以响应应用程序的请求，有时，可能整个SQL Server实例已经挂起，但是SQL Server服务的状态还是Running，所以需要Isalive 检查深入检查SQL Server的状态。此外，一旦looksalive检查失败，WSFC就会立即执行Isalive检查。
如果Isalive检查失败，WSFC会根据设置，重试3~5次Isalive检查。如果这些检查都失败了，WSFC就根据Polices选项卡中的设置进行故障转移，由集群仲裁选举出新的主副本（Primary Replica），Listener将SQL Server实例名和IP地址指向集群中新的主副本，由其该结点为应用程序继续提供服务，切换的过程是透明的。根据故障转移模式的不同，分为自动故障转移，手动故障转移和强制故障转移，详细信息请阅读《部署AlwaysOn第二步：配置AlwaysOn，创建可用性组》。
四，资源组的故障转移
故障转移完成之后，故障转移的目标辅助副本转换成为主副本，其数据库转换成主数据库，新的主副本重做已经固化的事务日志，回滚尚未提交的事务，使主数据库恢复到原主副本发生故障时的事务一致性的状态；如果原先的主副本从故障中恢复而重新运行，它会发现集群中已经存在新的主副本，于是它就把自己转换为辅助副本，其数据库转为辅助数据。当心的辅助数据库连接上主数据库之后，辅助数据库就开始进行同步操作，执行日志的固化和重做。
1，自动故障转移
在主副本出现故障之后，AlwaysOn迅速将资源组转移到其他辅助副本，使数据库再次变为可用，要发生自动故障转移，必须满足：
2，手动故障转移
当主副本和辅助副本可用，并且辅助数据库处于SYNCHRONIZED状态时，可以执行手动故障转移，但是，在手动转移的过程中，如果主副本停止运行，那么辅助副本将进入“RESOLVING”角色，此时，该副本既不是辅助副本，也不是主副本，但可以执行强制故障转移把辅助副本升级为主副本，但是，可能会丢失数据。
通过故障转移集群管理器（Failover Cluster Manager），能够手动执行资源组的转移操作，但是，建议始终通过SSMS执行任意模式的故障转移操作，能够避免操作错误和数据丢失。
3，强制故障转移
一旦执行强制故障转移，主副本尚未发送到原来的辅助副本上的事务日志都会丢失，这意味着，新的主数据库可能会缺少一些最近提交的数据更新，在强制故障转移之后，剩余的辅助副本上的辅助数据库都将处于挂起状态，要重新恢复辅助副本的配置，必须以某个副本上的数据为基础，重新配置可用性组。
五，监控AlwaysOn的健康状态
AlwaysOn的健康状态可以从故障转移集群管理器（Failover Cluster Manager）和SSMS来监控，建议通过SSMS来手动故障转移和监控，配置故障转移集群控制器来对AlwaysOn的异常进行故障排除。
打开SSMS，连接到主副本（Primary Replica）上，点击“AlwaysOn High Availability”能够看到与该SQL Server 实例相关联的可用性组（Availability Group），右击可用性组，打开Dashboard，能够查看可用性组的详细信息，并对可用性组执行手动故障转移操作。
参考文档：
《SQL Server 2012 实施与管理实战指南》第二章
sp_server_diagnostics (Transact-SQL)
标签：故障转移 clust ilo 基础 失败 win 故障排除 比较 dia
原文地址：http://www.cnblogs.com/wangsicongde/p/7551044.html
