SQLSERVER羣集故障轉移筆記

SQLSERVER羣集故障轉移筆記

出自《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.aspx

Configuring Integration Services in a Cluster

http://msdn.microsoft.com/kb/942176

 

 

2.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）。另外，兩個以上的節點同時發生故障轉移，須要同時切換到

共有節點的機率是比較低的，所以也在必定程度上解決了「活躍/活躍」結構的性能問題

 

不管什麼樣的拓撲結構，有兩點是不會變的：

一、SQLSERVER集羣 沒法提供數據庫端的負載均衡功能。 做爲「活躍/活躍」羣集，實際上是幾個

獨立的數據庫實例，他們彼此間沒有聯繫。再次強調，羣集技術只是一個提供「高可用性」的技術

，而不是提高性能的技術

 

 

二、不管羣集有幾個節點， 對於某個數據庫實例而言他只有一份數據。 一旦數據自己出現問題，羣集

對此便無能爲力。因此，羣集技術不是一個提供數據「災難恢復」的技術。對重要的數據庫，僅僅使用羣集技術是不夠的

 

2.2.5 SQL2012對故障轉移羣集的改進

SQLSERVER2012羣集基本沿襲了SQLSERVER2008羣集以來的一系列特色。不過他也帶來了一些新特性

使得羣集具備了更增強大的功能以及更高的可用性。

新特性介紹

一、多子網羣集的支持

二、RegisterAllProvidersIP

三、存放數據庫的物理位置

四、新的Resource DLL

五、Sp_server_diagnostics