文章出處
文章列表
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群集
資源不是一個真正的資源，是不具有自動故障轉移功能的，因此微軟并不推薦這麼做。
更多信息，參考
Configuring Integration Services in a Cluster
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）。另外，兩個以上的節點同時發生故障轉移，需要同時切換到
共有節點的概率是比較低的，因此也在一定程度上解決了“活躍/活躍”結構的性能問題
無論什么樣的拓撲結構，有兩點是不會變的：
1、SQLSERVER集群無法提供數據庫端的負載均衡功能。作為“活躍/活躍”群集，其實是幾個
獨立的數據庫實例，他們彼此間沒有聯系。再次強調，群集技術只是一個提供“高可用性”的技術
，而不是提升性能的技術
2、無論群集有幾個節點，對于某個數據庫實例而言他只有一份數據。一旦數據本身出現問題，群集
對此便無能為力。所以，群集技術不是一個提供數據“災難恢復”的技術。對重要的數據庫，僅僅使用群集技術是不夠的
2.2.5 SQL2012對故障轉移群集的改進
SQLSERVER2012群集基本沿襲了SQLSERVER2008群集以來的一系列特點。不過他也帶來了一些新特性
使得群集具有了更加強大的功能以及更高的可用性。
新特性介紹
1、多子網群集的支持
2、RegisterAllProvidersIP
3、存放數據庫的物理位置
4、新的Resource DLL
5、Sp_server_diagnostics
文章列表
全站熱搜
留言列表
