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。

分類: SQL Server 高可用性

本文轉自CareySon部落格園部落格，原文連結：http://www.cnblogs.com/CareySon/p/3249667.html如需轉載請自行聯系原作者