用于高可用性和災(zāi)難恢復(fù)的MicrosoftSQLServerAlwaysOn

1、用于高可用性和災(zāi)難恢復(fù)的 Microsoft SQL Server AlwaysOn 解決方案指南作者：LeRoy Tuttle, Jr. (Microsoft)供稿人：Cephas Lin (Microsoft)、Justin Erickson (Microsoft)、Lindsey Allen (Microsoft)、Min He (Microsoft)、Sanjay Mishra (Microsoft)審校：Alexei Khalyako (Microsoft)、Allan Hirt (SQLHA)、Ayad Shammout (Caregroup)、Benjamin Wright-Jo

2、nes (Microsoft)、Charles Matthews (Microsoft)、David P. Smith (ServiceU)、Juergen Thomas (Microsoft)、Kevin Farlee (Microsoft)、Shahryar G. Hashemi (Motricity)、Wolfgang Kutschera (Bwin Party)發(fā)布時間：2012 年 1 月適用范圍：SQL Server 2012摘要：本白皮書討論如何使用 SQL Server 2012 AlwaysOn 高可用性和災(zāi)難恢復(fù)解決方案減少計劃內(nèi)和計劃外的停機(jī)時間、最大程度地提高應(yīng)用程序可

3、用性，并且提供數(shù)據(jù)保護(hù)。本文旨在為商業(yè)利益相關(guān)者、技術(shù)決策者、系統(tǒng)架構(gòu)設(shè)計師、基礎(chǔ)結(jié)構(gòu)工程師和數(shù)據(jù)庫管理員提供一般性的背景信息。本文內(nèi)容分為兩大部分：高可用性和災(zāi)難恢復(fù)的概念。簡要討論規(guī)劃、管理和測量高可用數(shù)據(jù)庫環(huán)境的業(yè)務(wù)目標(biāo)的驅(qū)動因素以及面臨的挑戰(zhàn)。之后，我們將簡要概括 SQL Server 2012 AlwaysOn 和 Windows Server 解決方案的高可用性和災(zāi)難恢復(fù)功能。SQL Server AlwaysOn 保護(hù)層。我們將深入討論 SQL Server AlwaysOn 解決方案提供的保護(hù)層的功能、基本原理和依賴條件，介紹基礎(chǔ)結(jié)構(gòu)可用性、SQL Server 實例級保護(hù)、數(shù)

4、據(jù)庫級保護(hù)和數(shù)據(jù)層應(yīng)用程序功能。版權(quán)信息本文檔按“原樣”提供。本文檔中的信息和表達(dá)的觀點（包括 URL 和其他 Internet 網(wǎng)站引用）如有更改，恕不另行通知。您應(yīng)承擔(dān)使用本文檔所帶來的風(fēng)險。本文檔中提及的某些示例只是為了便于說明，純屬虛構(gòu)。不應(yīng)據(jù)此聯(lián)想或妄加推斷。本文檔不向您提供對任何 Microsoft 產(chǎn)品中的任何知識產(chǎn)權(quán)的任何法律權(quán)利。您可以出于內(nèi)部參考目的復(fù)制和使用本文檔。© 2012 Microsoft。保留所有權(quán)利。目錄高可用性和災(zāi)難恢復(fù)的概念1高可用性簡介1計劃內(nèi)停機(jī)時間與計劃外停機(jī)時間1降級的可用性2停機(jī)時間的量化2恢復(fù)目標(biāo)2確定合理的 ROI 或機(jī)會成本3監(jiān)視

5、可用性狀況3規(guī)劃災(zāi)難恢復(fù)4概述：使用 Microsoft SQL Server 2012 實現(xiàn)高可用性4SQL Server AlwaysOn4顯著減少計劃的停機(jī)時間5消除閑置的硬件并提高成本效益和性能5輕松部署和管理5比較 RPO 和 RTO 能力6SQL Server AlwaysOn 保護(hù)層7基礎(chǔ)結(jié)構(gòu)可用性8Windows 操作系統(tǒng)8Windows Server 故障轉(zhuǎn)移群集9WSFC 群集驗證向?qū)?1通過強(qiáng)制仲裁進(jìn)行 WSFC 災(zāi)難恢復(fù)14SQL Server 實例級保護(hù)15可用性改進(jìn) SQL Server 實例15AlwaysOn 故障轉(zhuǎn)移群集實例16數(shù)據(jù)庫可用性18AlwaysOn

6、 可用性組18可用性組故障轉(zhuǎn)移20可用性組偵聽器21可用性改進(jìn) 數(shù)據(jù)庫22客戶端連接建議23結(jié)論24用于高可用性和災(zāi)難恢復(fù)的 Microsoft SQL Server AlwaysOn 解決方案指南iv高可用性和災(zāi)難恢復(fù)的概念當(dāng)所有利益相關(guān)者對規(guī)劃、管理和測量 RTO 和 RPO 目標(biāo)的相關(guān)業(yè)務(wù)驅(qū)動因素、面臨的挑戰(zhàn)和要實現(xiàn)的目標(biāo)達(dá)成共識后，您就可以為高可用性和災(zāi)難恢復(fù)解決方案選擇最合適的數(shù)據(jù)庫技術(shù)。熟悉這些概念的讀者可以直接閱讀本文的概述：使用 Microsoft SQL Server 2012 實現(xiàn)高可用性 一節(jié)。高可用性簡介對于一個軟件應(yīng)用程序或服務(wù)來說，高可用性歸根到底是要根據(jù)最終用戶的

7、體驗和期望來判斷。我們感受得到的停機(jī)時間對業(yè)務(wù)的影響可能包括：信息丟失、資產(chǎn)受損、生產(chǎn)效率下降、機(jī)會丟失、合同無法履行或信譽(yù)受損。高可用性解決方案的主要目標(biāo)是盡量減小停機(jī)時間的負(fù)面影響。合理的策略應(yīng)實現(xiàn)業(yè)務(wù)流程、服務(wù)級別協(xié)議 (SLA) 與技術(shù)能力、基礎(chǔ)結(jié)構(gòu)成本之間的最佳平衡。根據(jù)協(xié)議以及客戶和利益相關(guān)者的期望，平臺應(yīng)該是高度可用的。系統(tǒng)的可用性可按以下公式計算：實際的運(yùn)行時間期望的運(yùn)行時間 ×100%所得的值在業(yè)界通常用解決方案能夠提供的 9 的個數(shù)來表示：這個值代表了每年解決方案運(yùn)行的實際分鐘數(shù)，或相反，代表了解決方案停機(jī)的分鐘數(shù)。9 的個數(shù)可用性百分比每年總停機(jī)時間299%3

8、天 15 小時399.9%8 小時 45 分鐘499.99%52 分鐘 34 秒599.999%5 分鐘 15 秒計劃內(nèi)停機(jī)時間與計劃外停機(jī)時間系統(tǒng)停機(jī)可能是計劃或意料之中的行為，也可能是意外故障導(dǎo)致的。如果正確管理停機(jī)時間，它將不會帶來負(fù)面影響。有兩類主要的可預(yù)見的停機(jī)時間：· 計劃的維護(hù)。在執(zhí)行計劃的維護(hù)任務(wù)（如軟件修補(bǔ)、硬件升級、密碼更新、脫機(jī)重建索引、數(shù)據(jù)加載或災(zāi)難恢復(fù)過程演習(xí)）之前，應(yīng)該預(yù)先公布和協(xié)調(diào)相應(yīng)的時間范圍。詳盡、管理良好的操作過程可以最大程度減少停機(jī)時間和防止數(shù)據(jù)丟失。計劃的維護(hù)活動可以看作一項必要的投資，以預(yù)防或減輕更嚴(yán)重的計劃外潛在停機(jī)故障。· 計劃

9、外停機(jī)。這種情況通常可能是發(fā)生了系統(tǒng)級、基礎(chǔ)結(jié)構(gòu)或流程故障，而這種故障不在計劃之內(nèi)或不可控制，或者是雖然可以預(yù)見但是發(fā)生的可能性很小，或認(rèn)為故障的影響在可接受的范圍之內(nèi)?？煽康母呖捎眯越鉀Q方案可以檢測這類故障，自動從停機(jī)中恢復(fù)，然后重建容錯功能。在確定高可用性的 SLA 時，您應(yīng)針對計劃的維護(hù)活動和計劃外停機(jī)時間分別計算關(guān)鍵性能指標(biāo) (KPI)。此方法使您可以將計劃的維護(hù)活動方面的投資金額同這些活動避免計劃外停機(jī)時間所減小的損失進(jìn)行比較。降級的可用性高可用性不應(yīng)該是一種非黑即白的硬性指標(biāo)。在出現(xiàn)故障的時候，最終用戶通常可以接受系統(tǒng)是部分可用的，或具有有限的功能或降級的性能，而不是完全徹底的停機(jī)

10、。這些不同的可用性級別包括：· 只讀和延遲的操作。在進(jìn)行維護(hù)期間或在分階段的災(zāi)難恢復(fù)期間，仍可以檢索數(shù)據(jù)，但新的工作流和后臺處理可能暫時停止或排隊。· 數(shù)據(jù)滯后和應(yīng)用程序響應(yīng)能力下降。由于工作負(fù)荷繁重、處理工作積壓或部分平臺故障，有限的硬件資源可能被過度使用或容量變小。用戶體驗可能變差，但是工作仍然可以完成，只是效率降低了。· 部分、暫時性或緊急故障。取決于遇到錯誤時重試或自我更正的應(yīng)用程序邏輯或硬件堆棧的可靠性。這類錯誤可能以數(shù)據(jù)滯后或應(yīng)用程序響應(yīng)能力下降的形式顯示給最終用戶。· 部分端到端故障。計劃內(nèi)或計劃外停機(jī)可能以溫和的方式發(fā)生在解決方案堆棧的垂

11、直層（基礎(chǔ)結(jié)構(gòu)、平臺和應(yīng)用程序）內(nèi)，也可能以水平方式發(fā)生在不同功能組件之間。根據(jù)受影響的功能或組件，用戶可能會遇到任務(wù)部分成功或性能降級的情況。應(yīng)該在解決方案中考慮接受這些退而求其次的方案，將它們視為一種代替完全停機(jī)的次級可用性方案，也可以作為分階段的災(zāi)難恢復(fù)過程的中間環(huán)節(jié)。停機(jī)時間的量化一旦發(fā)生停機(jī)事件，無論是計劃內(nèi)還是計劃外，主要業(yè)務(wù)目標(biāo)都是盡快使系統(tǒng)重新聯(lián)機(jī)并盡量減少數(shù)據(jù)丟失。每一分鐘的停機(jī)時間都會產(chǎn)生直接和間接成本。對于計劃外的停機(jī)時間，您需要花時間和精力去確定停機(jī)發(fā)生的原因、當(dāng)前的系統(tǒng)狀態(tài)以及還原所需的步驟，但是必須精確把握這些工作所需的時間和工作量。一旦某個停機(jī)事件達(dá)到某個預(yù)定的臨

12、界點，您應(yīng)該做出或者尋求相應(yīng)的業(yè)務(wù)決策，以便停止調(diào)查停機(jī)事件或者執(zhí)行維護(hù)任務(wù)，使系統(tǒng)恢復(fù)聯(lián)機(jī)狀態(tài)，并且在需要時重建容錯功能?；謴?fù)目標(biāo)數(shù)據(jù)冗余是高可用性數(shù)據(jù)庫解決方案的重要組成部分。主 SQL Server 實例上的事務(wù)活動以同步或異步方式應(yīng)用到一個或多個輔助實例。發(fā)生停機(jī)時，正在進(jìn)行中的事務(wù)可能回滾，或由于數(shù)據(jù)傳播的延遲而在輔助實例上丟失。您可以測量這種影響并設(shè)置相關(guān)的恢復(fù)目標(biāo)：業(yè)務(wù)恢復(fù)需要多長的時間，以及恢復(fù)的最后一個事務(wù)有多長時間的滯后。· 恢復(fù)時間目標(biāo) (RTO)。這是指停機(jī)的持續(xù)時間。初始目標(biāo)是使系統(tǒng)重新聯(lián)機(jī)，至少提供一個只讀容量以便于調(diào)查故障。但是，最終的目標(biāo)是將整個服務(wù)還

13、原到可以執(zhí)行新事務(wù)的點。· 恢復(fù)點目標(biāo) (RPO)。這通常指可接受的數(shù)據(jù)丟失的度量值。它是故障前最后提交的數(shù)據(jù)事務(wù)與故障后恢復(fù)的最新數(shù)據(jù)之間的時間間隔或滯后值。實際的數(shù)據(jù)丟失可能會有所不同，具體取決于發(fā)生故障時系統(tǒng)的工作負(fù)荷、故障類型和所使用的高可用性解決方案類型。您應(yīng)使用 RTO 和 RPO 值作為目標(biāo)來指示業(yè)務(wù)容忍的停機(jī)時長和可接受的數(shù)據(jù)丟失量，并將它作為監(jiān)視可用性狀況的度量值。確定合理的 ROI 或機(jī)會成本停機(jī)時間的業(yè)務(wù)成本可能是金錢損失，也可能是企業(yè)信譽(yù)的損失。這些成本可能隨時間而累積，也可能在停機(jī)期間的某個點發(fā)生。除了使用指定的恢復(fù)時間和數(shù)據(jù)恢復(fù)點來預(yù)測停機(jī)導(dǎo)致的成本之外，

14、您還可以計算實現(xiàn)您的 RTO 和 RPO 目標(biāo)或避免停機(jī)所需的業(yè)務(wù)流程和基礎(chǔ)結(jié)構(gòu)的投資總額。這些投資的目的應(yīng)包括：· 避免停機(jī)時間。如果從一開始沒有發(fā)生停機(jī)，則可以完全避免停機(jī)恢復(fù)成本。投資中包含容錯和冗余硬件或基礎(chǔ)結(jié)構(gòu)的成本、將工作負(fù)荷分布到多個隔離的故障點的成本以及出于預(yù)防性維護(hù)目的而發(fā)生的計劃停機(jī)的成本。· 自動恢復(fù)。如果發(fā)生系統(tǒng)故障，您可以通過自動透明的恢復(fù)機(jī)制大大減小停機(jī)時間對客戶體驗的影響。· 資源利用。輔助或備用基礎(chǔ)結(jié)構(gòu)可以閑置，直到發(fā)生停機(jī)。它也可以用于處理只讀工作負(fù)荷，或通過將工作負(fù)荷分布到所有可用硬件來提高總體系統(tǒng)性能。對于指定的 RTO 和

15、RPO 目標(biāo)，所需的可用性和恢復(fù)投資，以及預(yù)測的停機(jī)時間成本，可以表示為時間的函數(shù)。在實際停機(jī)期間，這允許您根據(jù)停機(jī)時間長短來進(jìn)行基于成本的決策。監(jiān)視可用性狀況從運(yùn)行角度，在實際停機(jī)期間，您不應(yīng)嘗試實時考慮所有相關(guān)的變量和計算 ROI 或機(jī)會成本。您應(yīng)監(jiān)視備用實例上的數(shù)據(jù)滯后時間，將其作為預(yù)期的 RPO 度量值。發(fā)生停機(jī)時，您還應(yīng)限制在停機(jī)期間調(diào)查停機(jī)原因所花的初始時間，而且應(yīng)側(cè)重驗證恢復(fù)環(huán)境的運(yùn)行狀況，然后依賴詳細(xì)的系統(tǒng)日志和數(shù)據(jù)的輔助副本以進(jìn)行后續(xù)的法醫(yī)式分析。規(guī)劃災(zāi)難恢復(fù)高可用性工作是采取一些措施來防止停機(jī)發(fā)生，而災(zāi)難恢復(fù)工作則是在停機(jī)后采取一些措施來重建高可用性。應(yīng)該盡可能在實際發(fā)生停

16、機(jī)前，制定完善的災(zāi)難恢復(fù)過程，并且明確各自的責(zé)任。根據(jù)活動的監(jiān)視和警報，是否要啟動自動或手動故障轉(zhuǎn)移和恢復(fù)計劃的決策應(yīng)該與預(yù)先確定的 RTO 和 RPO 閾值緊密關(guān)聯(lián)。合理的災(zāi)難恢復(fù)計劃應(yīng)包括：· 故障和恢復(fù)的粒度。根據(jù)故障的位置和類型，您可以在不同級別執(zhí)行更正操作：數(shù)據(jù)中心、基礎(chǔ)結(jié)構(gòu)、平臺、應(yīng)用程序或工作負(fù)荷。· 可供調(diào)查的原始資料。應(yīng)準(zhǔn)備好基線和最新的監(jiān)視歷史記錄、系統(tǒng)警報、事件日志和診斷查詢數(shù)據(jù)，以便有關(guān)方面的人士隨時查閱。· 協(xié)調(diào)依賴關(guān)系。在應(yīng)用程序堆棧內(nèi)以及各個利益相關(guān)方之間，系統(tǒng)和業(yè)務(wù)具有怎樣的依賴關(guān)系？· 決策樹。一個預(yù)先確定的、可重復(fù)操作

17、并且經(jīng)過驗證的決策樹應(yīng)該包括角色責(zé)任、故障分類、以 RPO 和 RTO 目標(biāo)表示的故障轉(zhuǎn)移標(biāo)準(zhǔn)以及指定的恢復(fù)步驟。· 驗證。在執(zhí)行從停機(jī)中恢復(fù)的步驟之后，必須執(zhí)行什么操作來驗證系統(tǒng)已恢復(fù)到正常運(yùn)行狀態(tài)？· 文檔。用一系列文檔記錄上述信息，要足夠詳細(xì)并且條理清晰，以便第三方團(tuán)隊可以在盡量不借助外部幫助的情況下執(zhí)行恢復(fù)計劃。此類文檔通常稱為“運(yùn)行手冊”或“操作指南”。· 恢復(fù)演習(xí)。定期演習(xí)災(zāi)難恢復(fù)計劃以確定 RTO 目標(biāo)的基準(zhǔn)值，并考慮使主站點和每個災(zāi)難恢復(fù)站點定期輪流充當(dāng)主生產(chǎn)站點。概述：使用 Microsoft SQL Server 2012 實現(xiàn)高可用性實現(xiàn)所需

18、的 RPO 和 RTO 目標(biāo)涉及確保關(guān)鍵應(yīng)用程序的連續(xù)運(yùn)行，以及保護(hù)關(guān)鍵數(shù)據(jù)不受計劃內(nèi)和計劃外停機(jī)的影響。SQL Server 提供了一系列功能可以幫助您實現(xiàn)這些目標(biāo)，而且所需的成本和復(fù)雜性也不高。非常熟悉新的 AlwaysOn 功能的讀者可以直接閱讀本文的 SQL Server AlwaysOn 保護(hù)層 一節(jié)，以便更加深入地了解相關(guān)的功能。SQL Server AlwaysOnAlwaysOn 是一種全新的集成式高可用性和災(zāi)難恢復(fù)解決方案，具有靈活性高、成本經(jīng)濟(jì)的特點。它可以在數(shù)據(jù)中心內(nèi)和數(shù)據(jù)中心間提供數(shù)據(jù)和硬件冗余，能夠縮短應(yīng)用程序故障轉(zhuǎn)移的時間，從而提高關(guān)鍵任務(wù)應(yīng)用程序的可用性。Alwa

19、ysOn 在配置方面極具靈活性，能夠重復(fù)利用現(xiàn)有的硬件資產(chǎn)。AlwaysOn 解決方案可以利用兩個主要的 SQL Server 2012 功能在數(shù)據(jù)庫級別和實例級別配置可用性：· AlwaysOn 可用性組：這是 SQL Server 2012 中引入的新功能，它大大增強(qiáng)了數(shù)據(jù)庫鏡像的功能，幫助確保應(yīng)用程序數(shù)據(jù)庫的可用性；它采用基于日志的數(shù)據(jù)移動來提供數(shù)據(jù)保護(hù)，無需共享磁盤，可以實現(xiàn)零數(shù)據(jù)丟失。可用性組提供一組集成的選項，包括邏輯數(shù)據(jù)庫組的自動和手動故障轉(zhuǎn)移，支持多達(dá)四個輔助副本，可以快速進(jìn)行應(yīng)用程序故障轉(zhuǎn)移和自動頁修復(fù)。· AlwaysOn 故障轉(zhuǎn)移群集實例 (FCI)：

20、此功能增強(qiáng)了 SQL Server 故障轉(zhuǎn)移群集功能并支持跨子網(wǎng)的多站點群集，可以跨數(shù)據(jù)中心對 SQL Server 實例進(jìn)行故障轉(zhuǎn)移。同時，實例故障轉(zhuǎn)移更快更可預(yù)測，從而加快了應(yīng)用程序恢復(fù)。顯著減少計劃的停機(jī)時間在任何組織中，應(yīng)用程序停機(jī)的主要原因是操作系統(tǒng)修補(bǔ)、硬件維護(hù)等活動導(dǎo)致的計劃停機(jī)。這幾乎占 IT 環(huán)境中總停機(jī)時間的 80%。SQL Server 2012 通過減少修補(bǔ)要求和支持更多聯(lián)機(jī)維護(hù)操作，可以幫助顯著減少計劃停機(jī)時間。· Windows Server Core。SQL Server 2012 支持在 Windows Server Core（Windows Serv

21、er 2008 和 Windows Server 2008 R2 的最小簡化部署選項）上進(jìn)行部署。此操作系統(tǒng)配置可以最大限度地減少操作系統(tǒng)修補(bǔ)要求（可減少 60%），從而減少計劃停機(jī)時間。· 聯(lián)機(jī)操作。SQL Server 2012 增強(qiáng)了對聯(lián)機(jī)操作（如 LOB 重建索引和添加具有默認(rèn)值的列）的支持，這可以幫助減少數(shù)據(jù)庫維護(hù)操作的停機(jī)時間。· 滾動升級和修補(bǔ)。AlwaysOn 功能為實例的滾動升級和修補(bǔ)提供了便利，這對減少應(yīng)用程序停機(jī)時間有很大幫助。· Hyper-V 上的 SQL Server。在 Hyper-V 環(huán)境中托管的 SQL Server 實例還具有實

22、時遷移的好處，它允許您不用停機(jī)即可在主機(jī)間遷移虛擬機(jī)。管理員可以在主機(jī)上執(zhí)行維護(hù)操作而不會影響應(yīng)用程序。消除閑置的硬件并提高成本效益和性能典型的高可用性解決方案通常需要部署昂貴、冗余的被動服務(wù)器。AlwaysOn 可用性組使您可以將被動或空閑服務(wù)器上的輔助數(shù)據(jù)庫副本用于只讀工作負(fù)荷，如 SQL Server Reporting Services 報表查詢或備份操作。同時利用主數(shù)據(jù)庫副本和輔助數(shù)據(jù)庫副本可以幫助提高所有工作負(fù)荷的性能，因為在您的服務(wù)器硬件資產(chǎn)中更均衡地分配了資源。輕松部署和管理諸如配置向?qū)?、Windows PowerShell 命令行界面支持、面板、動態(tài)管理視圖 (DMV)、基于

23、策略的管理和 System Center 集成等功能，可以幫助簡化可用性組的部署和管理。比較 RPO 和 RTO 能力恢復(fù)點目標(biāo) (RPO) 和恢復(fù)時間目標(biāo) (RTO) 的業(yè)務(wù)目標(biāo)應(yīng)是為您的高可用性和災(zāi)難恢復(fù)解決方案選擇 SQL Server 技術(shù)的重要推動因素。下表粗略比較了這些不同解決方案可能得到的結(jié)果類型：高可用性和災(zāi)難恢復(fù)SQL Server 解決方案可能的數(shù)據(jù)丟失 (RPO)可能的恢復(fù)時間 (RTO)自動故障轉(zhuǎn)移可讀輔助副本(1)AlwaysOn 可用性組 同步提交零幾秒是(4)0 - 2AlwaysOn 可用性組 異步提交幾秒幾分鐘否0 - 4AlwaysOn 故障轉(zhuǎn)移群集實例不適

24、用(5)幾秒到幾分鐘是不適用數(shù)據(jù)庫鏡像(2) 高安全性（同步 + 見證服務(wù)器）零幾秒是不適用數(shù)據(jù)庫鏡像(2) 高性能（異步）幾秒(6)幾分鐘(6)否不適用日志傳送幾分鐘(6)幾分鐘到幾小時(6)否在還原期間不可用備份、復(fù)制、還原(3)幾小時(6)幾小時到幾天(6)否在還原期間不可用(1) AlwaysOn 可用性組最多可以有四個輔助副本，無論它們是何種類型。(2) 后續(xù)版本的 Microsoft SQL Server 將刪除該功能。請改用 AlwaysOn 可用性組。(3) 備份、復(fù)制、還原適用于災(zāi)難恢復(fù)，但是不能提供高可用性。(4) 不支持從可用性組到故障轉(zhuǎn)移群集實例或反向的自動故障轉(zhuǎn)移。(

25、5) FCI 本身并不提供數(shù)據(jù)保護(hù)；數(shù)據(jù)丟失取決于存儲系統(tǒng)的實現(xiàn)形式。(6) 高度依賴于工作負(fù)荷、數(shù)據(jù)量和故障轉(zhuǎn)移過程。SQL Server AlwaysOn 保護(hù)層SQL Server AlwaysOn 解決方案有助于在基礎(chǔ)結(jié)構(gòu)和應(yīng)用程序組件的幾個邏輯和物理層上提供容錯和災(zāi)難恢復(fù)功能。從過去經(jīng)驗來看，涉及的各個人員和角色具有不同的職責(zé)已成為共識，這樣每個責(zé)任人只關(guān)注這些解決方案層的一部分。本節(jié)的內(nèi)容將對其中的每個層進(jìn)行更深入的描述，并為設(shè)計方案討論和實現(xiàn)形式?jīng)Q策提供基本的原理和指南。成功的 SQL Server AlwaysOn 解決方案要求了解這些層并協(xié)調(diào)這些層的活動：· 基礎(chǔ)結(jié)

26、構(gòu)級別。服務(wù)器級的容錯和節(jié)點內(nèi)部的網(wǎng)絡(luò)通信都是利用 Windows Server 故障轉(zhuǎn)移群集 (WSFC) 功能來監(jiān)視運(yùn)行狀況和協(xié)調(diào)故障轉(zhuǎn)移。· SQL Server 實例級別。SQL Server AlwaysOn 故障轉(zhuǎn)移群集實例 (FCI) 是在 WSFC 群集中的幾個服務(wù)器節(jié)點上安裝并可以在其中進(jìn)行故障轉(zhuǎn)移的 SQL Server 實例。承載 FCI 的節(jié)點都連接到可靠的對稱共享存儲設(shè)備（SAN 或 SMB）。· 數(shù)據(jù)庫級別?？捎眯越M 是一組共同實現(xiàn)故障轉(zhuǎn)移的用戶數(shù)據(jù)庫?？捎眯越M由一個主副本和一至四個輔助副本組成。每個副本均由 WSFC 群集不同節(jié)點上的 SQL

27、Server（FCI 或非 FCI）實例托管。· 客戶端連接。數(shù)據(jù)庫客戶端應(yīng)用程序可以直接連接到 SQL Server 實例網(wǎng)絡(luò)名稱，也可以連接到與可用性組偵聽器 綁定的虛擬網(wǎng)絡(luò)名稱 (VNN)。VNN 會提取 WSFC 群集和可用性組拓?fù)?，以邏輯方式將連接請求重定向到相應(yīng)的 SQL Server 實例和數(shù)據(jù)庫副本。下圖中顯示了一個典型的 AlwaysOn 解決方案的邏輯拓?fù)洌?基礎(chǔ)結(jié)構(gòu)可用性AlwaysOn 可用性組和 AlwaysOn 故障轉(zhuǎn)移群集實例都是利用 Windows Server 操作系統(tǒng)和 WSFC 作為平臺技術(shù)。想要成為一名成功的 Microsoft SQL Ser

28、ver 數(shù)據(jù)庫管理員，您需要比以往更加透徹地了解這些技術(shù)。Windows 操作系統(tǒng)SQL Server 依賴 Windows 平臺提供用于網(wǎng)絡(luò)、存儲、安全性、修補(bǔ)和監(jiān)視活動的底層基礎(chǔ)結(jié)構(gòu)和服務(wù)。SQL Server 2012 的各個版本之間以遞增的方式逐漸增加功能和容量，這一點類似于 Windows Server 2008 R2 操作系統(tǒng)的 Windows Server 2008 R2 Standard 版本、Windows Server 2008 R2 Enterprise 版本和 Windows Server 2008 R2 Datacenter 版本。有關(guān)詳細(xì)信息，請參閱：安裝 SQL

29、Server 2012 的硬件和軟件要求 (zh-cn/library/ms143506(SQL.110).aspx)。Windows Server Core 安裝選項作為一項重要的高可用性功能，SQL Server 2012 支持在 Windows Server 2008 或更高版本的 Server Core 安裝選項上進(jìn)行部署。Server Core 安裝選項是服務(wù)器系統(tǒng)的最小環(huán)境，可以運(yùn)行具有有限功能的服務(wù)器角色，并且只支持非常有限的 GUI 應(yīng)用程序。默認(rèn)情況下，只啟用必要的服務(wù)和命令提示符環(huán)境。此操作模式減小了操作系統(tǒng)的受攻擊面和系統(tǒng)開銷，并且可以顯著降低維護(hù)、服務(wù)和修補(bǔ)的要求。在

30、Windows Server Core 上部署 SQL Server 2012 的一個重要注意事項是：SQL Server 和操作系統(tǒng)的所有部署、配置、管理和維護(hù)都必須使用腳本環(huán)境（如 Windows PowerShell）或通過使用命令行或遠(yuǎn)程工具來完成。針對私有云優(yōu)化 SQL Server高可用性和災(zāi)難恢復(fù)方案在私有云環(huán)境中日顯重要。將 SQL Server 部署到私有云可以幫助確保高效使用您的計算機(jī)、網(wǎng)絡(luò)和存儲資源，減小物理占用空間、投資金額和運(yùn)行開支。它將幫助您高效地合并部署、擴(kuò)展資源，并在不影響控制的情況下按需部署資源。除了對 Hyper-V 主機(jī)和客戶操作系統(tǒng)的 Windows S

31、erver 故障轉(zhuǎn)移群集支持之外，SQL Server 還支持實時遷移，即可以在主機(jī)之間移動虛擬機(jī)而感覺不到系統(tǒng)停機(jī)。實時遷移還可以與客戶群集一起使用。有關(guān)詳細(xì)信息，請參閱私有云計算 - 針對私有云優(yōu)化 SQL Server (Windows Server 故障轉(zhuǎn)移群集Windows Server 故障轉(zhuǎn)移群集 (WSFC) 提供了各種基礎(chǔ)結(jié)構(gòu)功能來支持所承載的服務(wù)器應(yīng)用程序（如 Microsoft SQL Server）的高可用性和災(zāi)難恢復(fù)方案。如果一個 WSFC 群集節(jié)點或服務(wù)失敗，則該節(jié)點上承載的服務(wù)或資源可在一個稱為“故障轉(zhuǎn)移”的過程中自動或手動轉(zhuǎn)移到另一個可用節(jié)點。使用 Always

32、On 解決方案，此過程可同時應(yīng)用到 FCI 和可用性組。WSFC 群集中的節(jié)點協(xié)同工作，共同提供這些類型的功能：· 分布式元數(shù)據(jù)和通知。群集中的每個節(jié)點上維護(hù)著 WSFC 服務(wù)和承載的應(yīng)用程序元數(shù)據(jù)。除了承載的應(yīng)用程序設(shè)置之外，此元數(shù)據(jù)還包括 WSFC 配置和狀態(tài)。對一個節(jié)點上的元數(shù)據(jù)或狀態(tài)的更改會自動傳播到群集中的其他節(jié)點。· 資源管理。群集中的各節(jié)點可能提供物理資源，如直接連接的存儲 (DAS)、網(wǎng)絡(luò)接口和對共享磁盤存儲的訪問。承載的應(yīng)用程序（如 SQL Server）將其本身注冊為群集資源，并且可配置啟動和運(yùn)行狀況對于其他資源的依賴關(guān)系。· 運(yùn)行狀況監(jiān)視。節(jié)

33、點間和主節(jié)點運(yùn)行狀況檢測是通過結(jié)合使用信號樣式的網(wǎng)絡(luò)通信和資源監(jiān)視來實現(xiàn)的。群集的總體運(yùn)行狀況是由群集中節(jié)點仲裁的投票決定。· 故障轉(zhuǎn)移協(xié)調(diào)。每個資源都配置為由主節(jié)點承載，并且每個資源均可自動或手動轉(zhuǎn)移到一個或多個輔助節(jié)點?；谶\(yùn)行狀況的故障轉(zhuǎn)移策略控制節(jié)點之間資源所有權(quán)的自動轉(zhuǎn)移。在發(fā)生故障轉(zhuǎn)移時，節(jié)點和承載的應(yīng)用程序會收到通知，以便其做出適當(dāng)?shù)捻憫?yīng)。有關(guān)詳細(xì)信息，請參閱 Windows Server | 故障轉(zhuǎn)移群集和節(jié)點平衡 (注意：數(shù)據(jù)庫管理員了解 WSFC 群集和仲裁管理的內(nèi)部工作機(jī)制現(xiàn)在變得極為重要。AlwaysOn 運(yùn)行狀況監(jiān)視、管理和故障恢復(fù)步驟在本質(zhì)上都與您的 WS

34、FC 配置有關(guān)。WSFC 存儲配置Windows Server 故障轉(zhuǎn)移群集依賴于群集中的每個節(jié)點來管理與其連接的存儲設(shè)備、磁盤卷和文件系統(tǒng)。WSFC 假定存儲子系統(tǒng)非常可靠，因此如果連接到某一節(jié)點的存儲設(shè)備不可用，則認(rèn)為該群集節(jié)點出現(xiàn)故障。對于基于寫的操作，磁盤卷每次使用 SCSI-3 永久性預(yù)留邏輯連接到一個群集節(jié)點。根據(jù)存儲子系統(tǒng)的功能和配置，如果一個節(jié)點失敗，可以將磁盤卷的邏輯所有權(quán)轉(zhuǎn)移到群集中的其他節(jié)點。對于下面的對比方案，SQL Server AlwaysOn 解決方案都可以使用，但是限于某些特定的 WSFC 存儲配置組合，其中包括：· 直接連接與遠(yuǎn)程。存儲設(shè)備直接物理連

35、接到服務(wù)器，或者通過網(wǎng)絡(luò)或主機(jī)總線適配器 (HBA) 由遠(yuǎn)程設(shè)備提供。遠(yuǎn)程存儲技術(shù)包括基于存儲區(qū)域網(wǎng)絡(luò) (SAN) 的解決方案（如 iSCSI 或光纖通道）以及基于服務(wù)器消息塊 (SMB) 文件共享的解決方案。· 對稱與非對稱。如果為群集中的每個節(jié)點提供完全相同的邏輯磁盤卷配置和文件路徑，則認(rèn)為存儲設(shè)備是對稱的?；A(chǔ)磁盤卷的物理實現(xiàn)形式和容量可能有所不同。· 專用與共享。專用存儲設(shè)備是為特定使用目的預(yù)留并分配給群集中的一個節(jié)點。共享存儲設(shè)備則可供群集中的多個節(jié)點訪問?？梢允褂?SCSI-3 協(xié)議將兼容的共享存儲設(shè)備的控制權(quán)和所有權(quán)從一個節(jié)點轉(zhuǎn)移到另一個節(jié)點。WSFC 支持“

36、群集共享卷”的并發(fā)多節(jié)點承載，以便進(jìn)行文件共享。但是，SQL Server 不支持對共享卷的并發(fā)多節(jié)點訪問。注意：SQL Server FCI 仍要求對稱共享存儲設(shè)備能夠被實例的所有可能的節(jié)點所有者訪問。但是，引入 AlwaysOn 可用性組后，您現(xiàn)在可以在 WSFC 群集中部署不屬于 FCI 的其他 SQL Server 實例，每個實例具有自己的唯一、專用本地或遠(yuǎn)程存儲設(shè)備。WSFC 資源運(yùn)行狀況檢測和故障轉(zhuǎn)移WSFC 群集節(jié)點中的每個資源都可以定期或按需報告其狀態(tài)和運(yùn)行狀況。很多情況可能指示群集資源故障，其中包括：電源故障、磁盤或內(nèi)存錯誤、網(wǎng)絡(luò)通信錯誤、配置錯誤或服務(wù)不響應(yīng)。您可使 WSF

37、C 群集資源（如網(wǎng)絡(luò)、存儲或服務(wù)）彼此依賴。資源的累計運(yùn)行狀況由該資源及其每個資源依賴項的持續(xù)累積運(yùn)行狀況來確定。對于 AlwaysOn 可用性組，可用性組和可用性組偵聽器注冊為 WSFC 群集資源。對于 AlwaysOn 故障轉(zhuǎn)移群集實例，SQL Server 服務(wù)和 SQL Server 代理服務(wù)均注冊為 WSFC 群集資源，且都依賴于實例的虛擬網(wǎng)絡(luò)名稱資源。如果某個 WSFC 群集資源在一段時間內(nèi)遇到指定次數(shù)的錯誤或故障，則配置的“故障轉(zhuǎn)移策略”將導(dǎo)致群集服務(wù)執(zhí)行以下操作之一：· 重新啟動當(dāng)前節(jié)點上的資源。· 將資源設(shè)為脫機(jī)。· 開始將資源和它的依賴項自動故

38、障轉(zhuǎn)移到另一個節(jié)點。注意：WSFC 群集資源運(yùn)行狀況檢測對于單個節(jié)點的運(yùn)行狀況或群集的總體運(yùn)行狀況沒有直接影響。WSFC 群集驗證向?qū)杭炞C向?qū)且粋€已集成到 Windows Server 2008 和 Windows Server 2008 R2 故障轉(zhuǎn)移群集的功能。它是數(shù)據(jù)庫管理員的重要工具，可以幫助他們在部署 SQL Server AlwaysOn 解決方案前確保具有正常運(yùn)行、穩(wěn)定純凈的 WSFC 環(huán)境。使用群集驗證向?qū)?，您可以針對要用作群集?jié)點的服務(wù)器集合或現(xiàn)有群集運(yùn)行一組有針對性的測試。此過程將直接測試各個基礎(chǔ)硬件和軟件，以準(zhǔn)確評估指定配置對 WSFC 群集的支持程度。此驗證過程包

39、含一系列的測試，并會在每個節(jié)點上收集以下類別的數(shù)據(jù)：· 資產(chǎn)清單。有關(guān) BIOS 版本、環(huán)境級別、主機(jī)總線適配器、RAM、操作系統(tǒng)版本、設(shè)備、服務(wù)、驅(qū)動程序等的信息。· 網(wǎng)絡(luò)。有關(guān) NIC 綁定順序、網(wǎng)絡(luò)通信、IP 配置和防火墻配置的信息。驗證所有 NIC 的節(jié)點間通信情況。· 存儲。有關(guān)磁盤、驅(qū)動器容量、訪問延遲時間、文件系統(tǒng)等的信息。驗證 SCSI 命令、磁盤故障轉(zhuǎn)移功能、對稱或非對稱存儲配置。· 系統(tǒng)配置。驗證 Active Directory 配置、驅(qū)動程序已簽名、內(nèi)存轉(zhuǎn)儲設(shè)置、所需的操作系統(tǒng)功能和服務(wù)、兼容的處理器體系結(jié)構(gòu)，以及 Service

40、 Pack 和 Windows 軟件更新級別。這些驗證測試的結(jié)果為您提供所需的信息，以便優(yōu)化群集配置、跟蹤配置和識別潛在的群集配置問題以免它們導(dǎo)致停機(jī)。您可以將測試結(jié)果報告保存為 HTML 文檔，供以后參考。您應(yīng)在對 WSFC 配置進(jìn)行任何更改之前和之后、在安裝 SQL Server 前以及在執(zhí)行任何災(zāi)難恢復(fù)過程時運(yùn)行這些測試。Microsoft 客戶支持服務(wù)部門 (CSS) 要求提供群集驗證報告作為 Microsoft 支持指定 WSFC 群集配置的前提條件。有關(guān)詳細(xì)信息，請參閱故障轉(zhuǎn)移群集分步指南：驗證故障轉(zhuǎn)移群集的硬件 (注意：如果您的群集配置具有非對稱存儲設(shè)備，并且與基于硬件的地理群集

41、存儲解決方案或是與 AlwaysOn 可用性組同時使用，您可能需要應(yīng)用很多修補(bǔ)程序來防止群集驗證向?qū)У拇鎯︱炞C步驟失敗。有關(guān)詳細(xì)信息，請參閱針對 AlwaysOn 可用性組的先決條件、限制和建議 (WSFC 仲裁模式和投票配置WSFC 使用一種基于仲裁的方法來監(jiān)視群集的整體運(yùn)行狀況，并且最大限度地提高節(jié)點級別的容錯能力。理解 WSFC 仲裁模式和節(jié)點投票配置對于 AlwaysOn 高可用性和災(zāi)難恢復(fù)解決方案的設(shè)計、操作和故障排除十分重要。通過仲裁執(zhí)行群集運(yùn)行狀況檢測WSFC 群集中的每個節(jié)點都參與周期性信號通信，以便與其他節(jié)點共享該節(jié)點的運(yùn)行狀況。未響應(yīng)的節(jié)點被認(rèn)為是處于故障狀態(tài)?！爸俨谩惫?jié)點

42、集是 WSFC 群集中的大多數(shù)投票節(jié)點和見證服務(wù)器。WSFC 群集的總體運(yùn)行狀況和狀態(tài)是由定期“仲裁投票”確定的。仲裁的存在意味著群集運(yùn)行狀況正常，且能提供節(jié)點級別的容錯能力。沒有仲裁并不指示群集未在正常狀況下運(yùn)行。必須維護(hù)整體 WSFC 群集運(yùn)行狀況，以便確保運(yùn)行狀況良好的輔助節(jié)點可用于充當(dāng)要故障轉(zhuǎn)移到的主節(jié)點。如果仲裁投票失敗，作為一項預(yù)防措施，整個 WSFC 群集將被設(shè)為脫機(jī)。這也將導(dǎo)致所有向群集注冊的 SQL Server 實例都停止。注意：如果 WSFC 群集因為仲裁失敗而被設(shè)為脫機(jī)，則需要手動干預(yù)以便將其重新聯(lián)機(jī)。有關(guān)詳細(xì)信息，請參閱本文后面的通過強(qiáng)制仲裁進(jìn)行 WSFC 災(zāi)難恢復(fù)一

43、節(jié)。仲裁模式“仲裁模式”是在 WSFC 群集級別配置的，以指定用于仲裁投票的方法。故障轉(zhuǎn)移群集管理器實用工具將基于群集中的節(jié)點數(shù)來建議仲裁模式。以下仲裁模式之一用于確定構(gòu)成投票仲裁的元素：· 節(jié)點多數(shù)：群集中超過一半的投票節(jié)點必須投票贊成群集處于正常狀態(tài)。· 節(jié)點和文件共享多數(shù)：此模式與“節(jié)點多數(shù)”仲裁模式相似，只不過還另外配置了一個遠(yuǎn)程文件共享充當(dāng)投票見證服務(wù)器，并且從任何節(jié)點到該共享的連接也計為有效贊成投票。贊成投票數(shù)超過總投票數(shù)的一半即表示群集處于正常狀態(tài)。作為最佳實踐，見證文件共享不應(yīng)駐留在該群集中的任何節(jié)點上，它應(yīng)該對于該群集中的所有節(jié)點都是可見的。·

44、節(jié)點和磁盤多數(shù)：此模式與“節(jié)點多數(shù)”仲裁模式相似，只不過還另外指定了一個共享磁盤群集資源充當(dāng)投票見證服務(wù)器，并且從任何節(jié)點到該共享磁盤的連接也計為有效贊成投票。贊成投票數(shù)超過總投票數(shù)的一半即表示群集處于正常狀態(tài)。· 僅磁盤：共享磁盤群集資源指定為見證服務(wù)器，并且從任何節(jié)點到該共享磁盤的連接也計為有效贊成投票。有關(guān)詳細(xì)信息，請參閱故障轉(zhuǎn)移群集分步指南：在群集中配置仲裁 (注意：除非將群集中的每個節(jié)點配置為使用相同的共享存儲仲裁見證磁盤，否則，如果您具有奇數(shù)數(shù)目的投票節(jié)點，則通常應(yīng)該使用“節(jié)點多數(shù)”仲裁模式；如果您具有偶數(shù)數(shù)目的投票節(jié)點，則通常應(yīng)該使用“節(jié)點和文件共享多數(shù)”仲裁模式。投票

45、和非投票節(jié)點默認(rèn)情況下，WSFC 群集中的每個節(jié)點都是群集仲裁的成員；每個節(jié)點、文件共享見證服務(wù)器和磁盤見證服務(wù)器都具有能夠確定群集整體運(yùn)行狀況的單個投票。為了便于討論仲裁，本文現(xiàn)在將 WSFC 群集節(jié)點中有權(quán)投票的節(jié)點稱為“投票節(jié)點”。在某些情況下，您可能不希望每個節(jié)點都具有投票權(quán)。WSFC 群集中的每個節(jié)點不斷嘗試建立仲裁。群集中沒有任何一個單獨節(jié)點可以明確確定該群集的整體運(yùn)行狀況是正常還是非正常。在任意給定時刻，從各節(jié)點的角度來說，其他一些節(jié)點可能好像脫機(jī)，或者好像處于故障轉(zhuǎn)移中，或者好像由于網(wǎng)絡(luò)通信失敗而無法響應(yīng)。仲裁投票的一個關(guān)鍵功能是確定 WSFC 群集中每個節(jié)點的明顯表現(xiàn)出來的狀

46、態(tài)是否真的就是這些節(jié)點的實際狀態(tài)。除了“僅磁盤”之外，對于其他所有仲裁模式，仲裁投票的效力取決于群集中所有投票節(jié)點之間的可靠通信。當(dāng)所有節(jié)點位于同一物理子網(wǎng)時，您應(yīng)信任仲裁投票。但是，如果其他子網(wǎng)上的節(jié)點在仲裁投票中被視為無響應(yīng)，但它實際上處于聯(lián)機(jī)狀態(tài)并且正常運(yùn)行，則很可能是因為子網(wǎng)之間網(wǎng)絡(luò)通信失敗。根據(jù)群集拓?fù)?、仲裁模式和故障轉(zhuǎn)移策略配置，網(wǎng)絡(luò)通信失敗最終可能會創(chuàng)建不止一組（或一個子組）的投票節(jié)點。如果多個子組的投票節(jié)點能夠建立自己的仲裁，這稱作“裂腦情形”。在這種情況下，每個仲裁中的節(jié)點可能具有不同的行為方式，并互相沖突。注意：裂腦情形僅在系統(tǒng)管理員手動執(zhí)行強(qiáng)制仲裁操作時或者在非常罕見的情

47、況下（如強(qiáng)制手動故障轉(zhuǎn)移）才可能出現(xiàn)；并且會顯式將仲裁節(jié)點組進(jìn)一步劃分為多個組/子組。有關(guān)詳細(xì)信息，請參閱本文后面的通過強(qiáng)制仲裁進(jìn)行 WSFC 災(zāi)難恢復(fù) 一節(jié)。為了簡化您的仲裁配置和增加運(yùn)行時間，您可能要調(diào)整每個節(jié)點的 NodeWeight 設(shè)置（值為 0 或 1），以便不將該節(jié)點的投票計為有效仲裁投票。建議的仲裁投票調(diào)整要為群集確定建議的仲裁投票配置，請按順序應(yīng)用以下準(zhǔn)則：1. 默認(rèn)情況下不投票。在沒有明確的判斷時，假定每個節(jié)點不應(yīng)投票。2. 包括所有的主節(jié)點。承載 AlwaysOn 可用性組主副本或是 AlwaysOn 故障轉(zhuǎn)移群集實例的首選所有者的每個節(jié)點都應(yīng)具有一票。3. 包括可能的自

48、動故障轉(zhuǎn)移所有者。在自動故障轉(zhuǎn)移之后可能承載主副本或 FCI 的每個節(jié)點都應(yīng)具有一票。4. 不包括輔助站點節(jié)點。通常，不要向駐留在輔助災(zāi)難恢復(fù)站點的節(jié)點分配投票。在主站點不存在任何問題時，您不會希望輔助站點中的節(jié)點參與到令群集脫機(jī)的決策中來。5. 奇數(shù)數(shù)目的投票。如果需要，可以將見證文件共享、見證節(jié)點（具有或不具有 SQL Server 實例）或見證磁盤添加到群集，并且調(diào)整仲裁模式，以防止群集投票中可能出現(xiàn)票數(shù)正好一半的情況。6. 故障轉(zhuǎn)移后重新評估投票分配。您不希望故障轉(zhuǎn)移到不支持運(yùn)行狀況仲裁的群集配置。有關(guān)調(diào)整節(jié)點投票的詳細(xì)信息，請參閱配置群集仲裁 NodeWeight 設(shè)置 (您無法調(diào)整

49、文件共享見證服務(wù)器的投票。相反，您必須選擇不同的仲裁模式來包含或排除其投票。注意：SQL Server 公開了若干系統(tǒng)動態(tài)管理視圖 (DMV)，可幫助您管理與 WSFC 群集配置和節(jié)點仲裁投票相關(guān)的設(shè)置。有關(guān)詳細(xì)信息，請參閱監(jiān)視可用性組 (通過強(qiáng)制仲裁進(jìn)行 WSFC 災(zāi)難恢復(fù)仲裁故障通常由系統(tǒng)性災(zāi)難或涉及 WSFC 群集中多個節(jié)點的持久性通信故障引起。請注意，仲裁故障將會使 WSFC 群集中的所有群集服務(wù)、SQL Server 實例和可用性組設(shè)為脫機(jī)，這是因為該群集無法確保節(jié)點級容錯。仲裁故障意味著 WSFC 群集中運(yùn)行狀況良好的投票節(jié)點不再滿足仲裁模式的要求。一些節(jié)點可能已完全失敗，而另一些

50、節(jié)點可能只是關(guān)閉了 WSFC 服務(wù)從而失去仲裁通信的能力，但是其他方面運(yùn)行狀況良好。要使 WSFC 群集重新聯(lián)機(jī)，您必須在現(xiàn)有配置下的至少一個節(jié)點上消除仲裁故障的根源。在災(zāi)難方案中，您可能需要重新配置或確定要使用的替代硬件。您可能還要重新配置 WSFC 群集中的其余節(jié)點以反映幸存的群集拓?fù)洹Ｄ梢栽?WSFC 群集節(jié)點上使用“強(qiáng)制仲裁”過程來覆蓋使該群集脫機(jī)的安全控制。這樣做可有效地通知 WSFC 群集掛起仲裁投票檢查，并使您能夠在該群集中的任意節(jié)點上將 WSFC 群集資源和 SQL Server 重新聯(lián)機(jī)。此類型的災(zāi)難恢復(fù)過程應(yīng)包含以下步驟：1) 確定故障的范圍。確定哪些可用性組或 SQL

51、Server 實例是不響應(yīng)的，哪些群集節(jié)點處于聯(lián)機(jī)狀態(tài)且可在災(zāi)后使用，然后檢查 Windows 事件日志和 SQL Server 系統(tǒng)日志。在可行的情況下，您應(yīng)保留取證數(shù)據(jù)和系統(tǒng)日志以供未來分析使用。2) 在單一節(jié)點上使用強(qiáng)制仲裁來啟動 WSFC 群集。在其他正常運(yùn)行的節(jié)點上，使用強(qiáng)制仲裁過程來手動強(qiáng)制群集聯(lián)機(jī)。為了最大程度地減少可能丟失的數(shù)據(jù)，應(yīng)選擇一個最后承載可用性組主副本的節(jié)點。有關(guān)詳細(xì)信息，請參閱在無仲裁情況下強(qiáng)制啟動 WSFC 群集 (注意：如果您使用強(qiáng)制仲裁設(shè)置，在群集范圍內(nèi)將阻止仲裁檢查，直到 WSFC 群集獲得了投票多數(shù)并自動轉(zhuǎn)換到正常仲裁狀態(tài)。3) 逐一在每個其他方面運(yùn)行正常

52、的節(jié)點上正常啟動 WSFC 服務(wù)。當(dāng)您在其他節(jié)點上啟動該群集服務(wù)時，您無需指定強(qiáng)制仲裁選項。隨著每個節(jié)點上的 WSFC 服務(wù)重新聯(lián)機(jī)，該服務(wù)會與其他運(yùn)行狀態(tài)正常的節(jié)點進(jìn)行協(xié)商以同步新的群集配置狀態(tài)。請務(wù)必記住，一次只能在一個節(jié)點上執(zhí)行此操作，以避免在解析群集的上一個已知狀態(tài)時出現(xiàn)潛在的爭用情況。注意：確保您啟動的每個節(jié)點可以與其他剛聯(lián)機(jī)的節(jié)點通信，否則，您將會面臨創(chuàng)建多個仲裁節(jié)點集（即裂腦情形）的風(fēng)險。如果您在步驟 1 中的調(diào)查結(jié)果很準(zhǔn)確，則應(yīng)該不會發(fā)生這種情況。4) 應(yīng)用新的仲裁模式和節(jié)點投票配置。如果您使用強(qiáng)制仲裁過程成功地重新啟動了群集中的所有節(jié)點并且消除了仲裁故障的根源，則不需要更改原

53、始仲裁模式和節(jié)點投票配置。否則，您應(yīng)評估新恢復(fù)的群集節(jié)點和可用性副本拓?fù)?，并相?yīng)地更改每個節(jié)點的仲裁模式和投票分配。將未恢復(fù)的節(jié)點上的 WSFC 群集服務(wù)設(shè)置為脫機(jī)，或?qū)⑵涔?jié)點投票設(shè)置為零。注意：此時，群集中的節(jié)點和 SQL Server 實例可能看起來已恢復(fù)到正常操作狀態(tài)。但是，可能仍然不存在運(yùn)行狀況正常的仲裁。使用故障轉(zhuǎn)移群集管理器或 SQL Server Management Studio 中的 AlwaysOn 面板或適當(dāng)?shù)?DMV 來驗證仲裁已恢復(fù)正常。5) 根據(jù)需要恢復(fù)可用性組數(shù)據(jù)庫副本。某些數(shù)據(jù)庫可能作為常規(guī) SQL Server 啟動過程的一部分自行恢復(fù)和聯(lián)機(jī)。其他數(shù)據(jù)庫的恢復(fù)

54、可能要求執(zhí)行額外的手動步驟。通過按照以下順序?qū)⒖捎眯越M副本重新聯(lián)機(jī)（如果可能）可以最大程度地減少丟失數(shù)據(jù)的可能性并縮短恢復(fù)時間：主副本、同步輔助副本、異步輔助副本。6) 修復(fù)或替換失敗的組件并重新驗證群集。從最初的災(zāi)難和仲裁故障中恢復(fù)之后，您應(yīng)修復(fù)或替換失敗的節(jié)點并對相關(guān)的 WSFC 和 AlwaysOn 配置進(jìn)行相應(yīng)地調(diào)整。這可能包括：刪除可用性組副本、將節(jié)點從群集中逐出或者在節(jié)點上平展并重新安裝軟件。注意：您必須修復(fù)或刪除所有失敗的可用性副本。SQL Server 2012 不會截斷超過最后一個可用性副本的上一個已知點的事務(wù)日志。如果沒有在可用性組中修復(fù)或刪除某個失敗的副本，則事務(wù)日志將會

55、增長，因而您將面臨其他副本的事務(wù)日志空間不足的風(fēng)險。7) 根據(jù)需要，重復(fù)步驟 4。目標(biāo)是重新建立適當(dāng)級別的容錯和高可用性以實現(xiàn)正常的操作。8) 進(jìn)行 RPO/RTO 分析。您應(yīng)分析 SQL Server 系統(tǒng)日志、數(shù)據(jù)庫時間戳和 Windows 事件日志，以確定故障的根源，并記錄實際的恢復(fù)點和恢復(fù)時間經(jīng)驗。SQL Server 實例級保護(hù)AlwaysOn 解決方案中的下一個保護(hù)層是數(shù)據(jù)平臺本身；它們是 Microsoft SQL Server 2012 和與其集成的 Windows Server 基礎(chǔ)結(jié)構(gòu)組件提供的功能。可用性改進(jìn) SQL Server 實例這些是新的 SQL Server 2012 實例級功能，它們增強(qiáng)了 AlwaysOn 故障轉(zhuǎn)移群集實例和承載 AlwaysOn 可用性組的獨立實例的可用性。這些改進(jìn)使管理故障轉(zhuǎn)移方案和故障排除的能力得到增強(qiáng)：· 靈活的故障轉(zhuǎn)移策略。用于可靠故障檢測的新系統(tǒng)存儲過程 sp_server_diagnostics 的輸出使用 FailureConditionLevel 屬性來表示影響 SQL Server 實例的故障的嚴(yán)重性。WSFC 故障轉(zhuǎn)移策略控制此值如何影響 SQL Server