用于高可用性和災難恢復的MicrosoftSQLServerAlwaysOn

1、用于高可用性和災難恢復的 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 高可用性和災難恢復解決方案減少計劃內和計劃外的停機時間、最大程度地提高應用程序可

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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