出自《SQLSERVER2012實施與管理實戰指南》
SQLSERVER故障轉移 P41事實上，從sqlserver2000到sqlserver2008 R2，sqsrvres.dll中定義的looksalive和isalive方法都是類似的。具體來講：looksalive：通過服務器控制管理器（service control manager，SCM）來檢查SQLSERVER服務在活躍節點是否處于“啟動狀態”。根據SQLSERVER資源的Advanced Polices選項卡中的設置，這個檢查默認是每5秒做一次isalive：根據SQLSERVER資源的Advanced Polices選項卡中的設置，這個檢查默認是60秒做一次也就是說每12次Looksalive檢查就會伴隨一個Isalive檢查。SQLSERVER需要Isalive檢查是因為即使SQLSERVER服務是正在運行狀態也不能說明SQLSERVER就可以良好地響應應用程序的請求。有時候可能整個SQLSERVER已經掛起了，但是服務的狀態還是“啟動”，所以需要Isalive Check來進一步檢查SQLSERVER的狀態。此外，一旦lookalive檢查的結果失敗，Windows群集服務就會立刻觸發Isalive檢查在SQL2012之前，Isalive所做的事情很簡單，Windows群集服務會使用TCP/ip或者命名管道來連接SQLSERVER群集實例。連接上之后，運行一句命令：“select @@servername”。如果成功返回結果那么Isalive檢查就成功了。從第一次成功執行select @@servername開始，Isalive檢查就會根據設定的時間間隔，使用這個連接不斷地重復檢查工作如果連接不上SQLSERVER群集實例或者語句運行失敗，那么Isalive檢查失敗。此時Windows群集會再做3~5次（Windows的版本和設置不同）Isalive檢查。如果這些檢查都失敗，就要根據Policies選項卡中的設置開始進行故障轉移你可以把故障轉移簡單地想象成SQLSERVER服務的重啟，所不同的是故障轉移的時候，SQLSERVER服務是在當前節點停止的，然后在另一個節點上啟動起來。因此故障轉移所花費的時間和SQLSERVER服務重啟的時間是差不多的。當然共享磁盤和虛擬網絡名等資源在另一個節點上線也會額外花費一點時間，不過在大多數情況下這部分時間是比較短的。另外由于故障轉移一般是意外發生的，所以你要預期SQLSERVER切換到新節點以后，還需要一段時間來做數據庫的修復前面也提到過，除了SQLSERVER和SQLSERVER AGENT以外，SQLSERVER資源組里可能還會有Analysis Service資源。但是和SQLSERVER和SQLSERVER AGENT所不同的是，Analysis Service資源沒有自己的資源類型，也就是說他是一個GENERIC SERVICE（通用服務）。Analysis Service的isalive和lookalive檢查就使用的是clusres.dll中定義的通用服務檢查方法。SQLSERVER的諸多組件和服務中，SQLSERVER 、SQLSERVER AGNET、ANALYSIS SERVICE三個服務無論是有自己專屬的資源類型還是通用服務，都是被設計為可以通過resource dll形成群集資源。這種類型的服務被稱為cluster-aware。SQLSERVER還有很多其他資源，比如：SQL broswer、Reporting Service等，他們被設計為無法通過任何resource dll在Windows群集中形成資源，所以他們不是cluster-aware的。對于不是cluster-aware的服務，即使被安裝在了群集的節點上，Windows依舊把他當成是安裝在了一個單機環境中，他無法具有故障轉移的功能。需要提一下的是Integration Services是一個比較特別的服務。Integration Services本身不是cluster-aware的服務，但是用戶可以通過一些步驟手動把他配置成一個群集資源。但是這樣配置出來的Integration Services群集資源不是一個真正的資源，是不具有自動故障轉移功能的，因此微軟并不推薦這麼做。更多信息，參考http://msdn.microsoft.com/en-us/library/ms345193.aspxConfiguring Integration Services in a Clusterhttp://msdn.microsoft.com/kb/9421762.2.4 SQLSERVER群集的拓撲結構最簡單的SQLSERVER故障轉移群集拓撲結構就是“活躍/非活躍 ”群集，這種結構下群集有兩個節點，用戶在群集上安裝一個SQLSERVER群集實例，該實例的“可能的所有者（Possible Owners）”包含上述兩個節點。這樣任意時間只有一個節點上有SQLSERVER服務在運行，而另一個節點就是“非活躍”節點。這種配置優點就是結構簡單明了，無論SQLSERVER運行在哪個節點上都能獲得同樣的性能表現。缺點是總有一個節點處于空閑狀態，浪費了50%的硬件資源
另一種拓撲結構是活躍/活躍集群，還是以一個兩節點的群集為例，這個時候用戶在群集上安裝兩個SQLSERVER群集實例，每個實例的“可能的所有者”都包含群集兩個節點。在正常情況下，兩個實例分別運行在不同的節點上，這樣兩個節點就都是“活躍”節點這種結構的優勢是：兩個節點的硬件資源都能被充分利用（需要安裝兩個或多個SQLSERVER群集實例），并且節約成本。缺點是：一旦某個節點發生故障轉移，就會發生另一個節點上同時運行了兩個SQLSERVER實例的情況。此時，這兩個實例可能會爭用這個節點上的CPU、內存、I/O等資源，導致兩個實例的性能都受到影響。有時可能兩邊的用戶都不能接受。因此要盡快解決異常節點上的問題，盡早把發生故障轉移的實例切換回去
在此基礎上，我們來介紹所謂的N+1結構，即N個活躍節點加上一個非活躍節點，以3個節點的群集為例在上面安裝兩個SQLSERVER群集實例，每個實例的Possible Owner包含群集中的兩個節點，但是只有一個節點是兩個實例共有的。正常情況下，兩個SQLSERVER都運行在非共有的那個節點上，互不相干。一旦某個節點發生故障轉移，就會切換到那個共有的非活躍節點上
這個結構是一個介于“活躍/非活躍”和“活躍/活躍”之間的一種方案。相對于“活躍/非活躍”，他浪費的節點資源比較少（1/N+1）。另外，兩個以上的節點同時發生故障轉移，需要同時切換到共有節點的概率是比較低的，因此也在一定程度上解決了“活躍/活躍”結構的性能問題無論什么樣的拓撲結構，有兩點是不會變的：1、SQLSERVER集群無法提供數據庫端的負載均衡功能。作為“活躍/活躍”群集，其實是幾個獨立的數據庫實例，他們彼此間沒有聯系。再次強調，群集技術只是一個提供“高可用性”的技術，而不是提升性能的技術2、無論群集有幾個節點，對于某個數據庫實例而言他只有一份數據。一旦數據本身出現問題，群集對此便無能為力。所以，群集技術不是一個提供數據“災難恢復”的技術。對重要的數據庫，僅僅使用群集技術是不夠的2.2.5 SQL2012對故障轉移群集的改進SQLSERVER2012群集基本沿襲了SQLSERVER2008群集以來的一系列特點。不過他也帶來了一些新特性使得群集具有了更加強大的功能以及更高的可用性。新特性介紹1、多子網群集的支持2、RegisterAllPRovidersIP3、存放數據庫的物理位置4、新的Resource DLL5、Sp_server_diagnostics新聞熱點
疑難解答
