SQL Server中的高可用性（1）----高可用性概覽

    自從SQL Server 2005以來，微軟已經提供了多種高可用性技術來減小宕機時間和增長對業務數據的保護，而隨着SQL Server 2008，SQL Server 2008 R2，SQL Server 2012的不斷髮布，SQL Server中已經存在了知足不一樣場景的多種高可用性技術。

    在文章開始以前，我首先簡單概述一下以什麼來決定使用哪種高可用性技術。

 

依靠什麼來決定使用哪種高可用性技術？

    不少企業都須要他們的所有或部分數據高可用，好比說在線購物網站，在線商品數據庫必7*24小時在線，不然在競爭激烈的市場環境下，宕機時間就意味着流失客戶和收入。再好比說，一個依賴於SQL Server的呼叫中心，若是數據庫宕機，則全部的呼叫員都只能坐在那裏回覆客戶「對不起，系統故障」，這也是很難接受的。

    固然，在一個理想的世界中，全部的關鍵數據都會時刻在線，但在現實世界中，會存在各類各樣的緣由致使數據庫不可用，因爲沒法預估災難出現的時間和形式，須要提早採起措施來預防各類突發狀況，所以SQL Server提供了多種高可用性技術，這些技術主要包括：集羣、複製、鏡像、日誌傳送、AlwaysOn可用性組以及其它諸如文件組備份還原、在線重建索引等單實例的高可用性技術。使用何種高可用性技術並非隨意挑一個熟悉技術直接使用，而是要基於業務和技術綜合考慮。由於沒有一項單獨的技術能夠實現全部的功能。如何根據具體的業務和預算採用這些技術，就是所謂的高可用性策略。

在設計高可用性策略時應該首先考慮下述因素：

• RTO（Recovery Time Objective）-也就是恢復時間目標，意味着容許多少宕機時間，一般用幾個9表示，好比說99.999%的可用性意味着每一年的宕機時間不超過5分鐘、99.99%的可用性意味着每一年的宕機時間不超過52.5分鐘、99.9%的可用性意味着每一年的宕機時間不超過8.75小時。值得注意的是，RTO的計算方法要考慮系統是24*365，仍是僅僅是上午6點到下午9點等。您還須要注意是否維護窗口的時間在算在宕機時間以內，若是容許在維護窗口時間進行數據庫維護和打補丁，則更容易實現更高的可用性。
• RPO（Recovery Point Objective）-也就是恢復點目標，意味着容許多少數據損失。一般只要作好備份，能夠比較容易的實現零數據損失。但當災難發生時，取決於數據庫損壞的程度，從備份恢復數據所須要的時間會致使數據庫不可用，這會影響RTO的實現。一個早期比較著名的例子是某歐美的銀行系統，只考慮的RPO，系統裏只存在了完整備份和日誌備份，每3個月一次完整備份，每15分鐘一第二天志備份，當災難發生時，只可以經過完整備份和日誌備份來恢復數據，所以雖然沒有數據丟失，但因爲恢復數據花了整整兩天時間，形成銀行系統2天時間不可用，所以流失了大量客戶。另一個相反的例子是國內某在線視頻網站，使用SQL Server做爲後端關係數據庫，前端使用了No-SQL，按期將No-SQL的數據導入關係數據庫做爲備份，當災難發生時最多容許丟失一天的數據，可是要保證高可用性。

    預算 –RTO和RPO統稱爲SLA（服務水平協議），設計高可用性策略時，要根據業務來衡量知足何種程度的SLA，這要取決於預算以及衡量不一樣SLA在故障時所形成的損失。SLA並非越高越好，而是要基於業務需求，一般來講，在有限的預算之下很難實現很高的SLA，而且即便經過複雜的架構實現較高的SLA，複雜的架構也意味着高運維成本，所以須要在預算範圍以內選擇合適的技術來知足SLA。

所以，綜合來講，能夠經過幾個接單的問題肯定高可用性的大框架：

• 股東可以接受的宕機時間是多少?
• 管理人員可以接受的宕機時間是多少?
• 爲高可用性方案提供的預算是多少?
• 宕機致使的損失是每小時是多少錢?

 

冷備份、暖備份和熱備份

    根據主機和備機之間同步數據的程度，備份能夠分爲三種狀況，分別爲冷備份、暖備份和熱備份。

• 冷備份：也就是所謂的備份，備用服務器被配置用於接受主服務器的數據，當出故障時，手動將數據還原到主數據庫，或是從新配置程序的鏈接字符串或權限來使得備份數據庫上線。
• 暖備份：主服務器數據會不停的將日誌傳送到備用服務器（間隔不定，能夠是15分鐘，30分鐘，1分鐘等等），在這方式下，主服務器到備份服務器一般是異步更新，因此不能保證主服務器和備份服務器數據一致。此外，該方案一般不會實現自動故障監測和故障轉移。
• 熱備份：主服務器的數據自動在備份服務器上進行同步，大多數狀況下都會包含自動的故障監測和故障轉移，而且可以保證主服務器和備份服務器的數據一致性。

    隨着冷備份到暖備份到熱備份，成本會直線上升。

 

SQL Server中所支持的高可用特性

    SQL Server中所支持的高可用性功能與版本息息相關，企業版支持全部的高可用性功能，這些功能包括：

• l 故障轉移集羣
• l 數據庫鏡像
• l 事務日誌傳送
• l 數據庫快照
• l 高可用性升級
• l 熱加載內存
• l 在線索引操做
• l 數據庫部分在線（只還原了主文件組或主文件組和額外的NDF文件）

    具體何種版本支持哪些高可用特性，請參閱：http://msdn.microsoft.com/zh-cn/library/cc645993.aspx，值得注意的是免費的Express版本能夠做爲數據庫鏡像的見證服務器，從而節省了成本。

故障轉移集羣

    故障轉移集羣爲整個SQL Server實例提供高可用性支持，這意味着在集羣上某個節點的SQL Server實例發生了硬件錯誤、操做系統錯誤等會故障轉移到該集羣上的其它節點。經過多個服務器（節點）共享一個或多個磁盤來實現高可用性，故障轉移集羣在網絡中出現的方式就像單臺計算機同樣，可是具備高可用特性。值得注意的是，因爲故障轉移集羣是基於共享磁盤，所以會存在磁盤單點故障，所以須要在磁盤層面部署SAN複製等額外的保護措施。最多見的故障轉移集羣是雙節點的故障轉移集羣，包括主主節點和主從節點。

 

事務日誌傳送

    事務日誌傳送提供了數據庫級別的高可用性保護。日誌傳送可用來維護相應生產數據庫（稱爲「主數據庫」）的一個或多個備用數據庫（稱爲「輔助數據庫」）。發生故障轉移以前，必須經過手動應用所有未還原的日誌備份來徹底更新輔助數據庫。日誌傳送具備支持多個備用數據庫的靈活性。若是須要多個備用數據庫，能夠單獨使用日誌傳送或將其做爲數據庫鏡像的補充。當這些解決方案一塊兒使用時，當前數據庫鏡像配置的主體數據庫同時也是當前日誌傳送配置的主數據庫。

    事務日誌傳送可用於作冷備份和暖備份的方式。

 

數據庫鏡像

    數據庫鏡像其實是個軟件解決方案，一樣提供了數據庫級別的保護，可提供幾乎是瞬時的故障轉移，以提升數據庫的可用性。數據庫鏡像能夠用來維護相應生產數據庫（稱爲「主體數據庫」）的單個備用數據庫（或「鏡像數據庫」）。
由於鏡像數據庫一直處於還原狀態，但並不會恢復數據庫，所以沒法直接訪問鏡像數據庫。可是，爲了用於報表等只讀的負載，可建立鏡像數據庫的數據庫快照來間接地使用鏡像數據庫。數據庫快照爲客戶端提供了快照建立時對數據庫中數據的只讀訪問。每一個數據庫鏡像配置都涉及包含主體數據庫的「主體服務器」，而且還涉及包含鏡像數據庫的鏡像服務器。鏡像服務器不斷地使鏡像數據庫隨主體數據庫一塊兒更新。
    數據庫鏡像在高安全性模式下以同步操做運行，或在高性能模式下以異步操做運行。在高性能模式下，事務不須要等待鏡像服務器將日誌寫入磁盤即可提交，這樣可最大程度地提升性能。在高安全性模式下，已提交的事務將由夥伴雙方提交，但會延長事務滯後時間。數據庫鏡像的最簡單配置僅涉及主體服務器和鏡像服務器。在該配置中，若是主體服務器丟失，則該鏡像服務器能夠用做備用服務器，但可能會形成數據丟失。高安全性模式支持具備自動故障轉移功能的備用配置高安全性模式。這種配置涉及到稱爲「見證服務器」的第三方服務器實例，它可以使鏡像服務器用做熱備份服務器。從主體數據庫至鏡像數據庫的故障轉移一般要用幾秒鐘的時間。

    數據庫鏡像可用於作暖備份和熱備份。

 

複製

    複製嚴格來講並不算是一個爲高可用性設計的功能，但的確能夠被應用於高可用性。複製提供了數據庫對象級別的保護。複製使用的是發佈-訂閱模式，即由主服務器（稱爲發佈服務器）向一個或多個輔助服務器或訂閱服務器發佈數據。複製可在這些服務器間提供實時的可用性和可伸縮性。它支持篩選，以便爲訂閱服務器提供數據子集，同時還支持分區更新。訂閱服務器處於聯機狀態，而且可用於報表或其餘功能，而無需進行查詢恢復。SQL Server 提供四種複製類型：快照複製、事務複製、對等複製以及合併複製。

 

AlwaysOn可用性組

    AlwaysOn可用性組是SQL Server 2012推出的新功能。一樣提供了數據庫級別的保護。它取數據庫鏡像和故障轉移集羣之長，使得業務上有關聯的數據庫做爲一個可用性組共同故障轉移，該功能還拓展了數據庫鏡像只能1對1的限制，使得1個主副本能夠對應最多4個輔助副本（在SQL Server 2014中，該限制被拓展到8個），其中2個輔助副本能夠被做爲熱備份和主副本實時同步，而另外兩個異步輔助副本能夠做爲暖備份。此外，輔助副本還能夠被配置爲只讀，並可用於承擔備份的負載。

    正由於如此，數據庫鏡像在SQL Server 2012中被標記爲「過期」。

 

高可用性策略設計

    在瞭解了高可用性基本的概念和SQL Server中提供的高可用性技術以後，咱們再來看一下高可用性策略的設計。高可用性策略的規劃能夠分爲四個階段：

收集需求

    決定高可用性策略的第一步無疑是收集業務需求來創建SLA。文中以前所述的RTO和RPO是最關鍵的部分，在此基礎之上爲可用性需求創建切實可行的指望，並基於該指望創建切實可行的高可用性策略。

評估限制

    評估限制不只僅指的評估是SQL Server中不一樣的高可用性技術中的限制，還包括那些非技術的限制。若是隻有幾萬元的預算，卻要作基於異地數據中心和SAN複製的高可用方案，那無疑是癡人說夢。另外一個非技術限制是運維人員的水平，一般來講，複雜的架構意味着須要更高技能的運維人員。其它一些非技術限制包括數據中心的可用磁盤空間、電源供給和空調是否能知足須要，以及實現該可用性策略所須要的時間。

    技術限制則包括不一樣高可用性的功能與限制，不一樣SQL Server版本所支持的功能以及CPU個數以及內存大小等。強烈建議在實施高可用性策略以前，首先參閱微軟MSDN網站上不一樣SQL Server版本和功能的限制。

選擇技術

    在收集完需求並評估限制以後，接下來就是選擇本文前面所述的技術或技術組合來知足SLA的需求。若是所選技術沒法知足SLA，則能夠很容易的報告出是因爲什麼限制沒法知足SLA，從而能夠申請缺乏的資源或在SLA上作出妥協。

測試、驗證並文檔化

    在高可用性策略一開始實施的時候就須要通過嚴格的測試和驗證，從而確保當前的可用性策略可以知足SLA。但當高可用性策略上線以後，也要按期進行測試和驗證來確保當前的策略在數據增加、業務或需求變動的狀況下依然能夠知足SLA。同時，要把可用性解決方案的配置、故障轉移的方法和災難恢復計劃同時文檔化，以便於出現故障或是將來調整高可用性策略時有跡可循。

 

小結

本篇文章闡述了高可用性的基本概念、SLA的概念、SQL Server中所支持的不一樣種類的高可用性功能以及設計一個高可用性策略所需的步驟。值得注意的是，雖然本文僅僅講述了數據庫層面的高可用性，但高可用性不只僅是DBA的事，還包括系統運維人員、網絡管理人員、開發人員、管理人員等不一樣角色的共同協做，纔可以更好的知足SLA。