基於磁盤的備份
首先來看的是最簡單的技術——備份。在SQL Server 2008的企業版中，備份有了一個新的特性，那就是備份壓縮。那麼備份壓縮對於高可用有什麼幫助呢？
那麼就要提到現在業界非常流行的一種備份解決方案——磁盤備份解決方案，有很多與該解決方案相近的名稱：在線備份、虛擬磁帶庫等等。這些方案其實都是基於一個思想，將數據備份到快速的在線磁盤設備上，這樣就可以利用磁盤的高速IO和高速檢索能力。不過磁盤的高昂代價往往是這種企業在這一解決方案面前駐足不前的主要原因，而現在SQL Server 2008企業版中的備份壓縮可以大幅度減少備份後的文件尺寸，因此基於磁盤的備份解決方案看起來也更加有競爭力了。
基於磁盤的備份帶來最大的好處就是利用磁盤高速IO的能力進行快速的還原。這就可以縮短數據庫服務離線的時間，同時也可以減少數據庫備份這一維護操作對應用的影響。
數據庫鏡像+故障轉移集群
上面我們介紹的故障轉移集群、日志傳送亦或基於磁盤的備份都是作為單一技術出現的，而在真實的大中型企業環境中為了確保數據應用的持續在線，我們通常有一些組合多種高可用技術的方案。通過混合不同可用性技術，我們將可以采長補短。
例如數據庫鏡像技術。
雖然數據庫鏡像可以解決故障轉移集共享存儲存在單點失效威脅、依賴於特殊硬件等一系列的問題，但是數據庫鏡像最大的問題就是故障轉移路徑過短。對於大中型企業來說，僅有兩個節點的故障轉移路徑有些不足。因此通過增加一個故障轉移集群作為數據庫鏡像的鏡像節點就可以解決了數據庫鏡像故障轉移路徑過短的問題。
上面這種解決方案當主體服務器失效後，數據庫鏡像會將啟動鏡像節點，而由於鏡像節點是由一個故障轉移集群承擔的，因此當鏡像節點中的一個節點失效後還有一個後備節點，因此還可以有一個後備節點承擔。
其實故障轉移集群和數據庫鏡像是各有利弊，因此這兩種技術融合在一起後的解決方案不僅僅是上面這一種，下面就給出另外一種解決方案的示意圖：
細心的讀者可能會發現，方案二種沒有了見證節點，這意味著從主集群切換到鏡像集群需要手動完成。那麼為什麼這種解決方案中沒有了見證節點呢？
因為數據庫鏡像和故障轉移集群都擁有自動故障轉移的特性，如果兩種技術的自動切換都生效的話，那麼在主體集群的活動節點失效後就會有兩個節點同時試圖生效——主體集群的後備節點和鏡像集群的活動節點，那麼結果就只有一個，數據庫鏡像會話失敗。
遠程故障轉移集群
對於某些跨地區甚至是跨洲的大型集團來說，站點失效這個困擾會逐漸進入IT主管和DBA的腦海中。
不過遠程故障轉移集群就不僅僅是SQL Server一個人就能完成的了，這個方案要依賴於SQL Server，Windows Server這些基礎軟件，還要依賴於存儲設備、交換機、服務器這些硬件。
因為在遠程故障轉移集群中，共享儲存不再存在於一個數據中心，而是可能相距數十公裡，甚至數千公裡，因此中長距的底層存儲同步往往是這一解決方案的關鍵。對於中長距的底層存儲同步，通常分為兩種，一種是在30公裡內的，通過單模光纖可以實現兩個數據中心存儲設備間的同步復制，而另外一種則是在30公裡之外了，而這種情況通常都是通過租用ICP的線路來實現兩地間的異步復制。
聽上去好像很復雜，不過不用擔心，EMC這樣的廠商有非常成熟的硬件設備以及相關軟件。這就是為什麼在SQL Server的Always On中會出現EMC這樣第三方廠商名字的原因。
遠程故障轉移集群的替代方案
哦，天哪！我們討論的解決方案似乎越來越貴。我可不希望這樣結束。
其實對於遠程故障轉移集群來說，主要解決的問題是站點失效的問題，因此單純使用SQL Server的功能也可以解決這個問題。盡管沒有基於硬件的那麼高效和穩定。
那麼怎麼構建一個相對廉價的遠程容災方案呢？我們的答案是故障轉移集群+日志傳送/復制。在不提到這兩項技術的話，他們兩個一定會有意見的。
日志傳送依賴於日志備份以及還原來實現數據同步的，而復制呢，除了日志外多了一個快照(注意：復制中使用日志的方式與日志傳送是不一樣的)。因此我們只要確保主服務器的日志能夠以一個合理的頻率傳送給遠端的後備服務器，我們就可以提供一定程度上遠程容災能力了。
可是在SQL Server 2005之前，復制和日志傳送都有一些小問題，日志傳送是依賴於日志備份作業、日志傳送作業和日志還原作業，因此日志傳送無法做到連續性，他的嘴短同步間隔是一分鐘，無法再短了。事務復制盡管能做連續，但是事務復制有主從之分，如果是多站點這項技術會嚴重限制後備服務器的自治能力。
不過從SQL Server 2005開始，事務復制有了一種新的模式，叫做對等事務復制。對等事務復制平等看待參與復制的所有節點，而取消了主從之分。這就給我們的多站點數據服務規劃指出了一條新的道路。
不過大家在這張有些誇張的圖裡面也許可以看出些端倪。通過對等事務復制，我們確實可以設計出一個非常復雜的數據復制拓撲，利用高速/低速線路，優質/常規線路，我們可以在分布於多個站點的服務器之間構建出一個復制拓撲。說上面這張圖是開玩笑，原因是通常復制拓撲不會這麼混亂，但是對等復制一定可以制成這張圖上出現的服務器數量，關鍵是要良好規劃和設計。
算了，給張清楚點的吧。這是一個比較真實地對等復制拓撲，我們有兩個站點。站點內擁有高速的鏈接，而站點間則是相對低速的租用鏈路。A、B、C分別是三個應用的數據庫，A和C是本地性應用，因此僅在單個站點內進行了復制，保證其容災能力，而B是一個集團性的應用，為了確保其數據的可用性，因此在站點內和站點間分別實現了復制冗余，同時站點A和站點B可以互不干擾對數據的使用(當然這要依賴於數據庫的設計和對等復制鏈路的配置)。
SQL Server 2008在對等復制方面也有一個小小的改進，那就是沖突檢測。在SQL Server 2005的對等事務復制中，沖突是一個非常頭疼的事情，因此才會要求非常嚴格的數據訪問隔離設計。SQL Server 2008會在發生沖突的時候暫停復制，既保證了兩個站點間的正常數據訪問，也保證了在數據沖突時不會錯誤覆蓋正確的數據版本。
結束語
其實SQL Server的可用性和數據應用的可用性完全是兩個層面的事情，SQL Server僅僅是數據應用中的一個組成部分，因此如何達到真正的系統可用性，還要考慮更多的問題，通訊(交換機、路由器之類)、網絡服務(DNS、 DHCP之類)、操作系統、應用服務(IIS、中間件服務器)，還有很多很多的問題。
美國人遭遇了911，我們遭遇了512，除了沉重的傷痛之外也留給我們許多需要思考的問題。盡管對於很多IT來說，911和512似乎很遙遠，不過我們也討論到了IT系統需要面對的不僅僅是這些巨大的災難，還有飓風、火災、硬件故障、軟件缺陷、人為破壞，甚至是例行維護。因此規劃和實施有效的可用性方案算是未雨綢缪，當遇到真正的突發事件時，才能避免花費成百數千倍的代價去彌補。
