部署AlwaysOn第三步：集群資源組的健康檢測和故障轉移
資源組是由一個或多個資源組成的組，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中，查看集群的故障轉移屬性的設置，默認設置如下圖：
- 故障轉移（Failover）屬性：設置集群在指定的時間區間內執行故障轉移的次數；
- 故障恢復（Failback）屬性：設置集群在發生故障轉移之後，把資源組移回到最優先節點；
兩者的區別是：
- 故障轉移（Failover）是指：出現故障後轉移，集群把故障結點擁有的資源組轉移到另一個可用的結點上；
- 故障恢復（Failback）是指：出現故障後恢復，在發生故障轉移之後，如果最優先結點恢復正常，把資源組移回到最優先節點；
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，其行為是相同的：
- 使用Windows集群的虛擬網絡名，用戶看不到集群背後的一堆Windows Server，當資源發生故障時，WSFC自動將資源轉移到健康的結點上；
- 使用Listener，用戶看不到AlwaysOn集群背後的一堆可用性副本，當一個副本發生故障時，AlwaysOn自動轉移到健康的副本上；
- 根本差異在於：集群使用共享資源，沒有數據的冗余，而AlwaysOn的各個可用性副本（Availability Replica）上都存儲數據的一個副本；
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可用組資源類型：
- “Basic resource health check interval” 稱作“Looksalive check”，默認的時間間隔是5s；
- “Thorough resource health check interval”稱作“Isalive check”，默認的時間間隔是30s；
第三章節會詳細描述集群資源的檢查檢測。
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判斷系統是否執行故障轉移是至關重要的，該存儲過程只有一個參數：重復間隔的秒數，返回兩個重要的字段：
- 字段State：表示組件的健康狀態，可能值是：0（Unknown），1（clean），2（warning），3（error）；
- 字段component_name：表示組件的類型，可能類型是system，resource，query_processing，io_subsystem，events,availability group;
sp_server_diagnostics [@repeat_interval =] ‘repeat_interval_in_seconds‘
診斷信息和FailureConditionLevel的關系是：
- 當FailureConditionLevel屬性值為3，如果診斷結果返回“系統錯誤”，表示需要進行故障轉移或重新啟動；
- 當FailureConditionLevel屬性值為4，如果診斷結果返回“資源錯誤”或“系統錯誤”，表示需要進行故障轉移或重新啟動；
- 當FailureConditionLevel屬性值為5，如果診斷結果返回“query_processing錯誤”，“資源錯誤”或“系統錯誤”，表示需要進行故障轉移或重新啟動；
故障檢測存儲過程（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迅速將資源組轉移到其他輔助副本，使數據庫再次變為可用，要發生自動故障轉移，必須滿足：
- 當前主副本和一個輔助副本都設置為同步提交模式和自動故障轉移模式；
- 輔助副本必須和主副本同步，即輔助副本處於SYNCHRONIZED狀態；
- 主副本變得不可用，此時將發生自動故障轉移；
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)
部署AlwaysOn第三步：集群資源組的健康檢測和故障轉移