MicrosoftSQLServerAlwaysOn高可用性和灾害复原方案指南

高可用性和災害復原方案指南作者： , . ()。

參與者： ()、 ()、 ()、 ()、 ()。

校稿者： ()、 ()、 ()、 ()、 ()、 . ()、 ()、 ()、 . ()、 ( )。

發行日期：年月適用於：摘要：這份技術白皮書討論如何使用高可用性和災害復原方案，來縮短已規劃及未規劃的停機時間、盡可能地提高應用程式可用性，以及提供資料保護。

本文的主要目標是為了鋪陳共通的完整脈絡，促進企業專案關係人、技術決策者、系統架構設計師、基礎結構工程師與資料庫管理員彼此討論。

本內容分為兩個主要部分：高可用性和災害復原概念。

簡要討論規劃、管理及衡量高度可用之資料庫環境商務目標的驅策因素和挑戰。

本討論後將有和方案之高可用性和災害復原功能的簡要概觀。

保護層級。

深入討論方案所提供之保護層級的主要功能、基本原理及相依性。

說明基礎結構可用性、執行個體層級保護、資料庫層級保護，以及資料層應用程式功能。

著作權本文件是以原本的形式提供。

本文件中所表達的資訊和觀點，包括及其他網際網路網站參考資料，如有變更恕不另行通知。

您應自行承擔使用本文件的風險。

此處描述的部分範例僅供說明使用，純屬虛構，並無意圖亦不應將其影射為任何實際關聯或連接。

本文件不會為您提供任何產品的任何智慧財產權的任何法律權限。

您可以複製及使用本文件，但僅限組織內部參考用途。

© . 著作權所有，並保留一切權利。

目錄高可用性和災害復原概念错误!未指定书签。

高可用性說明错误!未指定书签。

規劃與未規劃的停機時間比較错误!未指定书签。

降低可用性错误!未指定书签。

量化停機時間错误!未指定书签。

復原目標错误!未指定书签。

調整或機會成本错误!未指定书签。

監視可用性健全狀況错误!未指定书签。

規劃災害復原错误!未指定书签。

概觀：的高可用性错误!未指定书签。

错误!未指定书签。

大幅縮短規劃的停機時間错误!未指定书签。

排除閒置硬體，並改善成本效益和效能错误!未指定书签。

容易部署及管理错误!未指定书签。

和功能比較错误!未指定书签。

保護層級错误!未指定书签。

基礎結構可用性错误!未指定书签。

作業系統错误!未指定书签。

容錯移轉叢集错误!未指定书签。

叢集驗證精靈错误!未指定书签。

仲裁模式和投票組態错误!未指定书签。

透過強制仲裁執行災害復原错误!未指定书签。

執行個體層級保護错误!未指定书签。

可用性改進–執行個體错误!未指定书签。

容錯移轉叢集執行個體错误!未指定书签。

資料庫可用性错误!未指定书签。

可用性群組错误!未指定书签。

可用性群組容錯移轉错误!未指定书签。

可用性群組接聽程式错误!未指定书签。

可用性改進─ 資料庫错误!未指定书签。

用戶端連接性建議错误!未指定书签。

結論错误!未指定书签。

高可用性和災害復原概念當所有專案關係人對於規劃、管理及評量和目標的相關商務驅策因素、挑戰及目標具有共識時，您將可以為高可用性和災害復原方案選擇最合適的資料庫技術。

熟悉這些概念的讀者可前往本文的＜概觀：的高可用性＞一節。

高可用性說明對任何的軟體應用程式或服務來說，使用者的經驗和期待就是高可用性的最終評斷標準。

停機時間會對企業造成有形與觀感方面的影響，影響可能包含資訊遺失、財物損失、生產力降低、機會成本、違約金或商譽受損等問題。

「高可用性方案的主要目標就是要將停機時間的影響降到最低，或是讓損失降到最少。

」針對此目標構築的完善策略會在商務程序和服務等級協定 ()，以及技術功能和基礎結構成本之間取得理想的平衡。

一個平台是否稱得上高度可用，取決於客戶和專案關係人的協定和預期。

系統可用性的計算方式如下：這個公式產生的值通常會依照業界標準，以的個數來表示此方案的品質，藉此傳達年度可能執行時間的分鐘數，或停機時間的分鐘數。

的個數可用性百分比年度總停機時間天小時分秒分秒規劃與未規劃的停機時間比較系統中斷可能是已預期及規劃中的結果，但也可能是未規劃的意外事件。

停機時間若經過適當地管理，不一定會造成負面影響。

可預知的停機時間有兩種主要類型：規劃的維護工作。

規劃的維護工作會預先宣告及協調時間間隔，維護工作包括軟體修補、硬體升級、密碼更新、離線重新索引、資料載入或災害復原程序演習。

經過謹慎及妥善管理的作業程序應該可將停機時間縮至最短，並防止任何資料遺失。

事先規劃的維護活動可視為投資，因為這些活動可防止或緩和其他可能更嚴重的未規劃中斷情況。

未規劃的中斷。

系統層級、基礎結構或程序失敗可能會在未規劃或不受控制的情況下發生，也可能會在可預知的情況下發生，通常是因為相關人員認為不太可能會發生或其影響尚可接受。

穩固的高可用性方案會偵測這些失敗類型、從中斷狀態自動復原，然後重新建立容錯機制。

建立高可用性的時，您應該將規劃的維護活動和未規劃的停機時間之關鍵效能指標 () 分開計算。

透過此方法，您可清楚比較您投入維護活動的心力以及避免未規劃停機時間的好處。

降低可用性我們不應該將高可用性視為全有或全無的價值主張。

相對於完全中斷，使用者通常還是比較能接受仍可使用部分系統，或使用有限的功能或降低的效能。

這些不同程度的可用性包括：唯讀和延遲作業。

在維護期間或分段式災害復原期間，系統仍可讓使用者擷取資料，但可能暫時停止新工作流程和背景處理，或是將其排入佇列中。

資料延遲和應用程式回應。

由於繁重的工作負載、待處理項目或部分平台失敗，有限的硬體資源可能會超載或過小。

使用者經驗會因此變差，但仍可以較不具生產力的方式完成工作。

部分、暫時性或懸置性失敗。

應用程式邏輯或硬體堆疊的健全性會在遇到錯誤時重試或自動修正。

這類問題對使用者而言可能會造成資料延遲或應用程式回應不良。

部分端對端失敗。

規劃或未規劃的中斷可能會在整套方案中縱向發生 (基礎結構、平台及應用程式)，或在不同的功能元件之間橫向發生。

視受影響的功能或元件而定，使用者可能會經歷部分作業成功或效能降低。

若將系統中斷導致可用性降低的程度放在頻譜上來看，一端是完全中斷，依程度輕重排列下來就是這些較不理想的情況，而這些可用性降低的情況也可做為分段式災害復原的中繼步驟。

由此看來，使用者對於可用性降低時退而求其次的接受態度也就不足為奇了。

量化停機時間實際發生停機時間時 (不論是規劃或未規劃的停機時間)，主要商務目標就是讓系統恢復上線，並將資料損失降至最低。

停機時間的每一分鐘都有直接和間接成本。

若發生未規劃的停機時間，您必須要平衡花費在判斷發生中斷的原因、目前的系統狀態，以及從失敗中復原所需步驟時的時間與工作量。

在任何中斷的預定時間點，您應該制定或尋求商務決策，以停止調查中斷原因或執行維護工作、透過讓系統恢復上線從失敗中復原，然後視需要重新建立容錯機制。

復原目標資料備援是高可用性資料庫方案的主要元件。

主要執行個體的交易活動都會以同步或非同步的方式套用至一個或多個次要執行個體。

發生中斷時，進行中的交易可能會回復，或因為資料傳播延遲而在次要執行個體上遺失。

您可以評量影響，然後判斷恢復交易所需時間及上次交易復原的延遲時間，據此來設定復原目標：復原時間目標 ()。

這是中斷的持續時間。

初始目標是至少讓系統恢復到唯讀功能，方便相關人員調查失敗原因。

不過，主要目標還是將整個服務還原至可進行新交易的時間點。

復原點目標 ()。

這通常稱為可接受的資料遺失量值。

這是上次認可資料交易到失敗前，以及失敗後到最近復原資料的時間間隔或延遲。

實際的資料遺失會隨系統在失敗時的工作負載、失敗類型及使用的高可用性方案類型而有所不同。

您應該使用和值做為目標，指定企業容許的停機時間及可接受的資料遺失，並做為監視可用性健全狀況的標準。

調整或機會成本停機時間的商務成本可能是指財務，或是對客戶商譽形式上的影響。

這些成本會隨時間累積，或者在中斷期間的特定時間點產生。

除了預測特定復原時間和資料復原點失敗所產生的成本之外，您還可以計算為達到和目標及避免完全失敗所需的商務程序和基礎結構投資。

這些投資主題應該包括：避免停機時間。

如果一開始未發生中斷，則可以完全避免中斷復原成本。

投資包括容錯和備援硬體或基礎結構、將工作負載分散到不同失敗點，以及預防性維護的規劃停機時間等成本。

自動復原。

如果發生系統失敗，您可以透過自動且透明的復原機制，大幅降低停機時間對客戶經驗的影響。

資源使用情形。

次要或待命基礎結構可處於閒置狀態，等到發生中斷情況時再擔綱上陣。

同時這些設備也可以用於唯讀工作負載，或將工作負載分散到所有可用的硬體，藉此提升整體系統效能。

在特定和目標下，您可以時間函數表示及調整所需的可用性和復原投資，以及停機時間的預計成本。

在實際中斷期間，這可讓您根據經過的停機時間來制定成本相關決策。

監視可用性健全狀況從營運觀點來看，在實際中斷期間，您不應該嘗試將所有相關變數列入考量，立刻在當下計算或機會成本。

相反地，您應該以監視待命執行個體在預期時的資料延遲。

發生中斷情況時，您也應該限制中斷時一開始花在調查根本原因的時間，改為著重於檢查復原環境的健全狀況，然後依據詳細的系統記錄和次要資料複本進行後續鑑識分析。

規劃災害復原高可用性是指為防止系統中斷所執行的工作，而災害復原則是指失敗後重新建立高可用性所執行的工作。

您應該在實際中斷之前，盡可能地規劃災害復原程序和職責。

起始自動或手動容錯移轉和復原計畫的決策，會以主動式監視和警示為基礎，並應該繫結至預先建立的和臨界值。

完善的災害復原計畫範圍應該包括：失敗和復原的規模。

根據失敗位置和類型，您可以在資料中心、基礎結構、平台、應用程式或工作負載等不同層級採取更正措施。

研究性來源資料。

適當團體應該能夠隨時存取所有基準和最近的監視記錄、系統警示、事件記錄及診斷查詢。

相依性協調。

在應用程式堆疊中，以及所有專案關係人之間，系統與商務的依存關係為何？決策樹。

預先決定、可重複且經過驗證的決策樹，包含角色職責、錯誤分級、和目標的容錯移轉準則及規定的復原步驟。

驗證。

採取步驟從中斷復原之後，必須執行哪些動作來確認系統回到正常作業？文件。

將上述所有項目擷取到一組文件中，並提供足夠的詳細資料和清楚說明，方便第三方團體可在最少協助下執行復原計畫。

這類文件通常稱為「執行書」或「資源書」。

復原演習。

定期練習災害復原計畫以建立預期的目標基準，並考慮定期輪流在主要站台和每個災害復原站台上，主控實際執行的主要站台。

概觀：的高可用性若想達成所需的和目標，您必須確保重要應用程式持續執行，並在未規劃及規劃的停機時間保護重要資料。

提供一組功能，可協助您達成這些目標，同時降低成本和複雜性。

對於新的功能非常熟悉的讀者可前往本文＜保護層級＞一節更深入的討論內容。

是全新經過整合、具備彈性且符合成本效益的高可用性和災害復原方案。

該方案可在資料中心及跨資料中心提供資料和硬體備援，並改善應用程式容錯移轉時間，以增加關鍵性應用程式的可用性。

提供彈性的組態，並可重複使用現有的硬體投資。