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

高可用性和災害復原方案指南作者： , . ()。參與者： ()、 ()、 ()、 ()、 ()。矚慫润厲钐瘗睞枥庑赖賃軔。校稿者： ()、 ()、 ()、 ()、 ()、 . ()、 ()、 ()、 . ()、 ( )。聞創沟燴鐺險爱氇谴净祸測。發行日期： 年 月適用於： 摘要：這份技術白皮書討論如何使用 高可用性和災害復原方案，來縮短已規劃及未規劃的停機時間、盡可能地提高應用程式可用性，以及提供資料保護。残骛楼諍锩瀨濟溆塹籟婭骒。本文的主要目標是為了鋪陳共通的完整脈絡，促進企業專案關係人、技術決策者、系統架構設計師、基礎結構工程師與資料庫管理員彼此討論。酽锕极額閉镇桧猪訣锥顧荭。本內容分為兩個主要部分：高可用性和災害復原概念。簡要討論規劃、管理及衡量高度可用之資料庫環境商務目標的驅策因素和挑戰。本討論後將有 和 方案之高可用性和災害復原功能的簡要概觀。彈贸摄尔霁毙攬砖卤庑诒尔。 保護層級。深入討論 方案所提供之保護層級的主要功能、基本原理及相依性。說明基礎結構可用性、 執行個體層級保護、資料庫層級保護，以及資料層應用程式功能。謀荞抟箧飆鐸怼类蒋薔點鉍。著作權本文件是以原本的形式提供。本文件中所表達的資訊和觀點，包括 及其他網際網路網站參考資料，如有變更恕不另行通知。您應自行承擔使用本文件的風險。厦礴恳蹒骈時盡继價骚卺癩。此處描述的部分範例僅供說明使用，純屬虛構，並無意圖亦不應將其影射為任何實際關聯或連接。本文件不會為您提供任何 產品的任何智慧財產權的任何法律權限。您可以複製及使用本文件，但僅限組織內部參考用途。茕桢广鳓鯡选块网羈泪镀齐。 . 著作權所有，並保留一切權利。目錄高可用性和災害復原概念鹅娅尽損鹌惨歷茏鴛賴縈诘。高可用性說明籟丛妈羥为贍偾蛏练淨槠挞。規劃與未規劃的停機時間比較預頌圣鉉儐歲龈讶骅籴買闥。降低可用性渗釤呛俨匀谔鱉调硯錦鋇絨。量化停機時間铙誅卧泻噦圣骋贶頂廡缝勵。復原目標擁締凤袜备訊顎轮烂蔷報赢。調整 或機會成本贓熱俣阃歲匱阊邺镓騷鯛汉。監視可用性健全狀況坛摶乡囂忏蒌鍥铃氈淚跻馱。規劃災害復原蜡變黲癟報伥铉锚鈰赘籜葦。概觀： 的高可用性買鲷鴯譖昙膚遙闫撷凄届嬌。 綾镝鯛駕櫬鹕踪韦辚糴飙钪。大幅縮短規劃的停機時間驅踬髏彦浃绥譎饴憂锦諑琼。排除閒置硬體，並改善成本效益和效能猫虿驢绘燈鮒诛髅貺庑献鵬。容易部署及管理锹籁饗迳琐筆襖鸥娅薔嗚訝。 和 功能比較構氽頑黉碩饨荠龈话骛門戲。 保護層級輒峄陽檉簖疖網儂號泶蛴镧。基礎結構可用性尧侧閆繭絳闕绚勵蜆贅瀝纰。 作業系統识饒鎂錕缢灩筧嚌俨淒侬减。 容錯移轉叢集凍鈹鋨劳臘锴痫婦胫籴铍賄。 叢集驗證精靈恥諤銪灭萦欢煬鞏鹜錦聰櫻。 仲裁模式和投票組態鯊腎鑰诎褳鉀沩懼統庫摇饬。透過強制仲裁執行 災害復原硕癘鄴颃诌攆檸攜驤蔹鸶胶。 執行個體層級保護阌擻輳嬪諫迁择楨秘騖輛埙。可用性改進 執行個體氬嚕躑竄贸恳彈瀘颔澩纷釓。 容錯移轉叢集執行個體釷鹆資贏車贖孙滅獅赘慶獷。資料庫可用性怂阐譜鯪迳導嘯畫長凉馴鸨。 可用性群組谚辞調担鈧谄动禪泻類谨觋。可用性群組容錯移轉嘰觐詿缧铴嗫偽純铪锩癱恳。可用性群組接聽程式熒绐譏钲鏌觶鷹緇機库圆鍰。可用性改進 資料庫鶼渍螻偉阅劍鲰腎邏蘞阕簣。用戶端連接性建議纣忧蔣氳頑莶驅藥悯骛覲僨。結論颖刍莖蛺饽亿顿裊赔泷涨负。23 / 26高可用性和災害復原概念當所有專案關係人對於規劃、管理及評量 和 目標的相關商務驅策因素、挑戰及目標具有共識時，您將可以為高可用性和災害復原方案選擇最合適的資料庫技術。濫驂膽閉驟羥闈詔寢賻減栖。熟悉這些概念的讀者可前往本文的概觀： 的高可用性一節。銚銻縵哜鳗鸿锓謎諏涼鏗穎。高可用性說明對任何的軟體應用程式或服務來說，使用者的經驗和期待就是高可用性的最終評斷標準。停機時間會對企業造成有形與觀感方面的影響，影響可能包含資訊遺失、財物損失、生產力降低、機會成本、違約金或商譽受損等問題。挤貼綬电麥结鈺贖哓类芈罷。高可用性方案的主要目標就是要將停機時間的影響降到最低，或是讓損失降到最少。針對此目標構築的完善策略會在商務程序和服務等級協定 ()，以及技術功能和基礎結構成本之間取得理想的平衡。赔荊紳谘侖驟辽輩袜錈極嚕。一個平台是否稱得上高度可用，取決於客戶和專案關係人的協定和預期。系統可用性的計算方式如下：實際執行時間預期執行時間 100%這個公式產生的值通常會依照業界標準，以 的個數來表示此方案的品質，藉此傳達年度可能執行時間的分鐘數，或停機時間的分鐘數。塤礙籟馐决穩賽釙冊庫麩适。 的個數可用性百分比年度總停機時間 天 小時 小時 分 分 秒 分 秒規劃與未規劃的停機時間比較系統中斷可能是已預期及規劃中的結果，但也可能是未規劃的意外事件。停機時間若經過適當地管理，不一定會造成負面影響。可預知的停機時間有兩種主要類型：裊樣祕廬廂颤谚鍘羋蔺递灿。規劃的維護工作。規劃的維護工作會預先宣告及協調時間間隔，維護工作包括軟體修補、硬體升級、密碼更新、離線重新索引、資料載入或災害復原程序演習。經過謹慎及妥善管理的作業程序應該可將停機時間縮至最短，並防止任何資料遺失。事先規劃的維護活動可視為投資，因為這些活動可防止或緩和其他可能更嚴重的未規劃中斷情況。仓嫗盤紲嘱珑詁鍬齊驁絛鯛。未規劃的中斷。系統層級、基礎結構或程序失敗可能會在未規劃或不受控制的情況下發生，也可能會在可預知的情況下發生，通常是因為相關人員認為不太可能會發生或其影響尚可接受。穩固的高可用性方案會偵測這些失敗類型、從中斷狀態自動復原，然後重新建立容錯機制。绽萬璉轆娛閬蛏鬮绾瀧恒蟬。建立高可用性的 時，您應該將規劃的維護活動和未規劃的停機時間之關鍵效能指標 () 分開計算。透過此方法，您可清楚比較您投入維護活動的心力以及避免未規劃停機時間的好處。骁顾燁鶚巯瀆蕪領鲡赙骠弒。降低可用性我們不應該將高可用性視為全有或全無的價值主張。相對於完全中斷，使用者通常還是比較能接受仍可使用部分系統，或使用有限的功能或降低的效能。這些不同程度的可用性包括：瑣钋濺暧惲锟缟馭篩凉貿锕。唯讀和延遲作業。在維護期間或分段式災害復原期間，系統仍可讓使用者擷取資料，但可能暫時停止新工作流程和背景處理，或是將其排入佇列中。鎦诗涇艳损楼紲鯗餳類碍穑。資料延遲和應用程式回應。由於繁重的工作負載、待處理項目或部分平台失敗，有限的硬體資源可能會超載或過小。使用者經驗會因此變差，但仍可以較不具生產力的方式完成工作。栉缏歐锄棗鈕种鵑瑶锬奧伛。部分、暫時性或懸置性失敗。應用程式邏輯或硬體堆疊的健全性會在遇到錯誤時重試或自動修正。這類問題對使用者而言可能會造成資料延遲或應用程式回應不良。辔烨棟剛殓攬瑤丽阄应頁諳。部分端對端失敗。規劃或未規劃的中斷可能會在整套方案中縱向發生 (基礎結構、平台及應用程式)，或在不同的功能元件之間橫向發生。視受影響的功能或元件而定，使用者可能會經歷部分作業成功或效能降低。峴扬斕滾澗辐滠兴渙藺诈機。若將系統中斷導致可用性降低的程度放在頻譜上來看，一端是完全中斷，依程度輕重排列下來就是這些較不理想的情況，而這些可用性降低的情況也可做為分段式災害復原的中繼步驟。由此看來，使用者對於可用性降低時退而求其次的接受態度也就不足為奇了。詩叁撻訥烬忧毀厉鋨骜靈韬。量化停機時間實際發生停機時間時 (不論是規劃或未規劃的停機時間)，主要商務目標就是讓系統恢復上線，並將資料損失降至最低。停機時間的每一分鐘都有直接和間接成本。若發生未規劃的停機時間，您必須要平衡花費在判斷發生中斷的原因、目前的系統狀態，以及從失敗中復原所需步驟時的時間與工作量。则鯤愜韋瘓賈晖园栋泷华缙。在任何中斷的預定時間點，您應該制定或尋求商務決策，以停止調查中斷原因或執行維護工作、透過讓系統恢復上線從失敗中復原，然後視需要重新建立容錯機制。胀鏝彈奥秘孫戶孪钇賻锵咏。復原目標資料備援是高可用性資料庫方案的主要元件。主要 執行個體的交易活動都會以同步或非同步的方式套用至一個或多個次要執行個體。發生中斷時，進行中的交易可能會回復，或因為資料傳播延遲而在次要執行個體上遺失。鳃躋峽祷紉诵帮废掃減萵輳。您可以評量影響，然後判斷恢復交易所需時間及上次交易復原的延遲時間，據此來設定復原目標：復原時間目標 ()。這是中斷的持續時間。初始目標是至少讓系統恢復到唯讀功能，方便相關人員調查失敗原因。不過，主要目標還是將整個服務還原至可進行新交易的時間點。稟虛嬪赈维哜妝扩踴粜椤灣。復原點目標 ()。這通常稱為可接受的資料遺失量值。這是上次認可資料交易到失敗前，以及失敗後到最近復原資料的時間間隔或延遲。實際的資料遺失會隨系統在失敗時的工作負載、失敗類型及使用的高可用性方案類型而有所不同。陽簍埡鲑罷規呜旧岿錟麗鲍。您應該使用 和 值做為目標，指定企業容許的停機時間及可接受的資料遺失，並做為監視可用性健全狀況的標準。沩氣嘮戇苌鑿鑿槠谔應釵蔼。調整 或機會成本停機時間的商務成本可能是指財務，或是對客戶商譽形式上的影響。這些成本會隨時間累積，或者在中斷期間的特定時間點產生。除了預測特定復原時間和資料復原點失敗所產生的成本之外，您還可以計算為達到 和 目標及避免完全失敗所需的商務程序和基礎結構投資。這些投資主題應該包括：钡嵐縣緱虜荣产涛團蔺缔嵛。避免停機時間。如果一開始未發生中斷，則可以完全避免中斷復原成本。投資包括容錯和備援硬體或基礎結構、將工作負載分散到不同失敗點，以及預防性維護的規劃停機時間等成本。懨俠劑鈍触乐鹇烬觶騮揚銥。自動復原。如果發生系統失敗，您可以透過自動且透明的復原機制，大幅降低停機時間對客戶經驗的影響。資源使用情形。次要或待命基礎結構可處於閒置狀態，等到發生中斷情況時再擔綱上陣。同時這些設備也可以用於唯讀工作負載，或將工作負載分散到所有可用的硬體，藉此提升整體系統效能。謾饱兗争詣繚鮐癞别瀘鯽礎。在特定 和 目標下，您可以時間函數表示及調整所需的可用性和復原投資，以及停機時間的預計成本。在實際中斷期間，這可讓您根據經過的停機時間來制定成本相關決策。呙铉們欤谦鸪饺竞荡赚趱為。監視可用性健全狀況從營運觀點來看，在實際中斷期間，您不應該嘗試將所有相關變數列入考量，立刻在當下計算 或機會成本。相反地，您應該以 監視待命執行個體在預期 時的資料延遲。莹谐龌蕲賞组靄绉嚴减籩诹。發生中斷情況時，您也應該限制中斷時一開始花在調查根本原因的時間，改為著重於檢查復原環境的健全狀況，然後依據詳細的系統記錄和次要資料複本進行後續鑑識分析。麸肃鹏镟轿騍镣缚縟糶尔摊。規劃災害復原高可用性是指為防止系統中斷所執行的工作，而災害復原則是指失敗後重新建立高可用性所執行的工作。您應該在實際中斷之前，盡可能地規劃災害復原程序和職責。起始自動或手動容錯移轉和復原計畫的決策，會以主動式監視和警示為基礎，並應該繫結至預先建立的 和 臨界值。完善的災害復原計畫範圍應該包括：納畴鳗吶鄖禎銣腻鰲锬颤階。失敗和復原的規模。根據失敗位置和類型，您可以在資料中心、基礎結構、平台、應用程式或工作負載等不同層級採取更正措施。風撵鲔貓铁频钙蓟纠庙誑繃。研究性來源資料。適當團體應該能夠隨時存取所有基準和最近的監視記錄、系統警示、事件記錄及診斷查詢。相依性協調。在應用程式堆疊中，以及所有專案關係人之間，系統與商務的依存關係為何？決策樹。預先決定、可重複且經過驗證的決策樹，包含角色職責、錯誤分級、 和 目標的容錯移轉準則及規定的復原步驟。灭嗳骇諗鋅猎輛觏馊藹狰廚。驗證。採取步驟從中斷復原之後，必須執行哪些動作來確認系統回到正常作業？文件。將上述所有項目擷取到一組文件中，並提供足夠的詳細資料和清楚說明，方便第三方團體可在最少協助下執行復原計畫。這類文件通常稱為執行書或資源書。铹鸝饷飾镡閌赀诨癱骝吶转。復原演習。定期練習災害復原計畫以建立預期的 目標基準，並考慮定期輪流在主要站台和每個災害復原站台上，主控實際執行的主要站台。攙閿频嵘陣澇諗谴隴泸鐙浍。概觀： 的高可用性若想達成所需的 和 目標，您必須確保重要應用程式持續執行，並在未規劃及規劃的停機時間保護重要資料。 提供一組功能，可協助您達成這些目標，同時降低成本和複雜性。趕輾雏纨颗锊讨跃满賺蚬騍。對於新的 功能非常熟悉的讀者可前往本文 保護層級一節更深入的討論內容。夹覡闾辁駁档驀迁锬減汆藥。 是全新經過整合、具備彈性且符合成本效益的高可用性和災害復原方案。該方案可在資料中心及跨資料中心提供資料和硬體備援，並改善應用程式容錯移轉時間，以增加關鍵性應用程式的可用性。 提供彈性的組態，並可重複使用現有的硬體投資。视絀镘鸸鲚鐘脑钧欖粝佥爾。 方案可利用兩個主要的 功能，在資料庫和執行個體層級設定可用性：偽澀锟攢鴛擋緬铹鈞錠铃铋。 的新功能 可用性群組可大幅增強資料庫鏡像的功能，並協助確保應用程式資料庫的可用性；這些功能也允許透過資料保護的記錄式資料移動避免資料遺失，而不需要使用共用磁碟。緦徑铫膾龋轿级镗挢廟耬癣。可用性群組提供一組整合的選項，包括自動及手動容錯移轉一組邏輯資料庫、最多支援四個次要複本、快速應用程式容錯移轉，以及自動修復頁面。騅憑钶銘侥张礫阵轸蔼揽齊。 容錯移轉叢集執行個體 ()可增強 容錯移轉叢集功能，並支援跨子網路的多站台叢集，藉此實現 執行個體的跨資料中心容錯移轉。更快且更容易預測的執行個體容錯移轉，是能夠更快復原應用程式的另一個主要優點。疠骐錾农剎貯狱颢幗騮鸪詼。大幅縮短規劃的停機時間在任何組織中，造成應用程式停機時間的主要原因不外乎是作業系統修補、硬體維護等所造成的規劃停機時間。這個原因就佔了 環境幾乎 的停機時間。镞锊过润启婭澗骆讕瀘載撻。 透過降低修補需求及啟用更多線上維護作業，大幅縮短規劃的停機時間： 。 支援在 上部署，這是 和 的基本、簡化部署選項。此作業系統組態可降低多達 的作業系統修補需求，藉此縮短規劃的停機時間。榿贰轲誊壟该槛鲻垲赛纬闼。線上作業。線上作業的增強支援 (例如 重新索引及使用預設值加入資料行) 有助於縮短資料庫維護作業期間的停機時間。邁茑赚陉宾呗擷鹪讼凑幟结。輪流升級和修補。 功能可輪流升級及修補執行個體，因此有助於大幅縮短應用程式停機時間。 上的 。在 環境中主控 執行個體還有即時移轉的額外好處，讓您可以在主機間移轉虛擬機器，完全不需要停機。當管理員在主機上執行維護作業時，應用程式不會受到影響。嵝硖贪塒廩袞悯倉華糲饃励。排除閒置硬體，並改善成本效益和效能一般高可用性方案需要部署昂貴的備援被動伺服器。 可用性群組可讓您針對唯讀工作負載 (例如 報表查詢或備份作業)，在被動或閒置伺服器上使用次要資料庫複本。同時使用主要與次要資料庫複本的能力，有助於提升所有工作負載的效能，因為您可在不同的伺服器硬體投資之間取得更佳的資源平衡。该栎谖碼戆沖巋鳧薩锭谟贛。容易部署及管理組態精靈 等功能及對 命令列介面、儀表板、動態管理檢視 ()、原則式管理的支援，以及 整合，皆有助於簡化可用性群組的部署和管理。劇妆诨貰攖苹埘呂仑庙痙湯。 和 功能比較在針對高可用性和災害復原方案選取 技術時，復原點目標 () 和復原時間目標 () 的商務目標應該是您的主要驅策因素。下表提供不同方案可達成之結果類型的概略比較：臠龍讹驄桠业變墊罗蘄嚣驮。高可用性和災害復原 方案可能的資料遺失 ()可能的復原時間 ()自動容錯移轉可讀取的次要複本() 可用性群組同步認可零 ()數秒是() 可用性群組非同步認可數秒數分鐘否 容錯移轉叢集執行個體不適用()數秒到數分鐘是不適用資料庫鏡像()高安全性 (同步 見證)零 ()數秒是不適用資料庫鏡像()高效能 (非同步)數秒()數分鐘()否不適用記錄傳送數分鐘()數分鐘到數小時()否還原期間不適用備份、複製、還原()數小時()數小時到數天()否還原期間不適用() 不論何種類型， 可用性群組最多總共可以有四個次要複本。() 未來的 版本將移除這項功能。請改用 可用性群組。鰻順褛悦漚縫冁屜鸭骞阋苈。() 備份、複製、還原適用於災害復原，但不適用於高可用性。()不支援從容錯移轉叢集執行個體自動容錯移轉可用性群組，或將容錯移轉可用性群組自動容錯移轉至容錯移轉叢集執行個體。穑釓虚绺滟鳗絲懷紓泺視娇。() 本身不提供資料保護；資料遺失取決於儲存系統實作。()與工作負載、資料量及容錯移轉程序高度相關。 保護層級 方案可協助提供容錯和災害復原機制，範圍可橫跨基礎結構和應用程式元件的多個邏輯和實體層。在過去，常見的作法是區分各種參與對象和角色的職責，讓每個對象和角色只關注這些方案層級的一部分。隶誆荧鉴獫纲鴣攣駘賽涝鈧。本節在文中的編排方式，係針對每個層級進行更深入的逐步說明，並提供設計討論和實作決策的基本原理和指引。一個 方案要能成功，每個人對於各層級都需要了解，並跨層級地共同合作：浹繢腻叢着駕骠構砀湊農瑤。基礎結構層級。伺服器層級容錯和節點內網路通訊利用 容錯移轉叢集() 功能，監視健全狀況和協調容錯移轉作業。鈀燭罚櫝箋礱颼畢韫粝銨鹏。 執行個體層級。 容錯移轉叢集執行個體() 是跨 叢集中伺服器節點安裝的 執行個體，並可容錯移轉至 叢集中的伺服器節點。裝載 的節點會附加至健全的對稱式共用儲存體 ( 或 )。惬執缉蘿绅颀阳灣熗鍵舣讷。資料庫層級。可用性群組是一組可一起進行容錯移轉的使用者資料庫。可用性群組由一個主要複本和一到四個次要複本所組成。每個複本都是由一個位於 叢集之不同節點上的 ( 或非 ) 執行個體所裝載。贞廈给鏌綞牵鎮獵鎦龐朮戗。用戶端連接性。資料庫用戶端應用程式可直接連接至 執行個體網路名稱，也可以連接至與可用性群組接聽程式繫結的虛擬網路名稱()。 會摘要 叢集和可用性群組拓撲，以邏輯方式將連接要求重新導向至適當的 執行個體和資料庫複本。嚌鲭级厨胀鑲铟礦毁蕲鷯鑭。下圖說明具有代表性的 方案邏輯拓撲：基礎結構可用性 可用性群組和 容錯移轉叢集執行個體都利用 作業系統和 做為平台技術。因此，想成為一位成功的 資料庫管理員，必須比過去更加全面了解這些技術。薊镔竖牍熒浹醬籬铃騫违紗。 作業系統 依賴 平台提供網路、儲存體、安全性、修補及監視的基礎結構和服務。齡践砚语蜗铸转絹攤濼絡減。不同的 版本是根據類似 作業系統版本 (包括 作業系統、 作業系統及 作業系統) 不斷增加的功能和容量，慢慢打造而成。绅薮疮颧訝标販繯轅赛怃贿。如需詳細資訊，請參閱：安裝 的硬體和軟體需求()。饪箩狞屬诺釙诬苧径凛骗橥。 安裝選項在 眾多主要的高可用性功能中，其中一項就是支援在 或更新版本的 安裝選項上進行部署。 安裝選項為執行中的特定伺服器角色提供基本環境，該環境具有有限的功能及相當有限的 應用程式支援。預設只會啟用必要的服務和命令提示字元環境。烴毙潜籬賢擔視蠶贲粵貫飭。此作業模式可減少作業系統的攻擊面和系統負擔，並可大幅降低持續進行維護、維修及修補的需求。在 上部署 的主要考量是 和作業系統的所有部署、組態、管理及維護，都必須透過指令碼環境 (例如 ) 或透過命令列和遠端工具來完成。鋝岂涛軌跃轮莳講嫗键砺脈。為私人雲端最佳化 高可用性和災害復原案例在私人雲端環境中愈來愈重要。將 部署至私人雲端有助於確保有效使用電腦、網路及儲存體資源，並降低實體使用量以及資本和作業支出，也可協助您整合部署作業、有效率地擴充資源，並視需要在不影響控制權的情況下部署資源。撷伪氢鱧轍幂聹諛詼庞復堝。除了 主機和客體系統的 容錯移轉叢集支援之外， 還支援即時移轉功能，讓您在主機間移動虛擬機器，幾乎不需要停機。即時移轉也可搭配客體叢集使用。踪飯梦掺钓貞绫賁发蘄韃钆。如需詳細資訊，請參閱私人雲端運算 為私人雲端最佳化 ()。婭鑠机职銦夾簣軒蚀骞设犹。 容錯移轉叢集 容錯移轉叢集 () 提供基礎結構功能，支援 等託管伺服器應用程式的高可用性和災害復原案例。譽諶掺铒锭试监鄺儕泻濰鴇。如果 叢集節點或服務失敗，該節點上裝載的服務或資源可在稱為容錯移轉的程序中自動或手動轉移至另一個可用的節點。在 方案中，此程序適用於 和可用性群組。俦聹执償閏号燴鈿膽賾劳覡。 叢集中的節點會一起運作，共同提供這些類型的功能：分散式的中繼資料和通知。 服務和託管應用程式中繼資料是在叢集中的每個節點上進行維護。此中繼資料除了包含託管應用程式設定之外，還包含 組態和狀態。對某個節點的中繼資料或狀態所做的變更會自動傳播到叢集中的其他節點。缜電怅淺靓蠐浅錒鵬凜锩惡。資源管理。叢集中的個別節點可以提供實體資源，例如直接附加的儲存體 ()、網路介面及共用磁碟儲存體存取權。託管應用程式 (例如 ) 會自行註冊為叢集資源，並可設定對其他資源的啟動和健全狀況相依性。骥擯帜褸饜兗椏長绛粤藎锾。健全狀況監視。節點間和主要節點健全狀況偵測是透過活動訊號式網路通訊和資源監視的組合來完成。叢集的整體健全狀況是由叢集節點的仲裁投票所決定。癱噴导閽骋艳捣靨骢鍵桧篓。容錯移轉協調。每個資源都是設定為在主要節點上裝載，而且每個資源都可以自動或手動轉移至一個或多個次要節點。以健全狀況為主的容錯移轉原則會控制節點之間資源擁有權的自動轉移。在發生容錯移轉時，節點和託管應用程式會收到通知，以便它們可以適當反應。鑣鸽夺圆鯢齙慫餞離龐東偿。如需詳細資訊，請參閱 容錯移轉叢集和節點平衡()。榄阈团皱鹏緦寿驏頦蕴釙負。注意：了解 叢集和仲裁管理的內部工作，現在對資料庫管理員而言特別重要。 健全狀況監視、管理及失敗復原步驟基本上都會繫結至 組態。逊输吴贝义鲽國鳩犹騸缋樣。 儲存體組態 容錯移轉叢集依賴叢集中的每個節點來管理其連接的儲存裝置、磁碟區及檔案系統。 假設儲存體子系統十分穩固，因此如果附加至節點的儲存裝置無法使用，則會將叢集節點視為失敗節點。幘觇匮骇儺红卤齡镰瀉戲颖。對於寫入作業而言，系統會使用 持續保留，以邏輯方式逐一將磁碟區附加至各個叢集節點。視儲存體子系統功能和組態而定，如果節點失敗，磁碟區的邏輯擁有權可能會轉移至叢集中的其他節點。誦终决懷区馱倆侧澩赜鱺罢。 方案利用並受限於特定的 儲存體組態組合，包括：直接附加與遠端的比較。儲存裝置可實際直接附加至伺服器，也可以由遠端裝置透過網路或主機匯流排介面卡() 來提供。遠端儲存技術包含以存放區域網路() 為基礎的方案 (例如 或光纖通道)，以及以伺服器訊息區塊() 檔案共用為基礎的方案。医涤侣綃噲睞齒办銩凛赝嚣。對稱與非對稱的比較。如果將完全相同的邏輯磁碟區組態和檔案路徑提供給叢集中的每個節點，則可將儲存裝置視為對稱。基礎磁碟區的實體實作和容量可能會有所不同。舻当为遙头韪鳍哕晕糞窶適。專用與共用的比較。專用儲存體會保留並指派給叢集中的單一節點使用。共用儲存體則可供叢集中的多個節點存取。相容之共用儲存裝置的控制權和擁有權，可透過 通訊協定從一個節點轉移至另一個節點。 支援多個節點同時裝載叢集共用磁碟區以共用檔案。但是， 不支援多個節點同時存取共用磁碟區。鸪凑鸛齏嶇烛罵奖选锯宫煬。注意： 仍然需要對稱式共用儲存體，以供所有可能之執行個體的節點擁有者存取。不過，採用 可用性群組之後，您現在可以在 叢集中部署不同的非 執行個體，且每個執行個體都有各自唯一且專用的本機或遠端儲存體。筧驪鴨栌怀鏇颐嵘悅废颛鲷。 資源健全狀況偵測和容錯移轉 叢集節點中的每個資源可以定期或視需要報告其狀態和健全狀況。表示叢集資源失敗的情況有許多種，包括：停電、磁碟或記憶體錯誤、網路通訊錯誤、組態錯誤或無反應的服務。韋鋯鯖荣擬滄閡悬贖蘊詡蝉。您可以將 叢集資源 (例如網路、儲存體或服務) 設定為彼此相依。資源的累積健全狀況是透過其個別資源相依性的健全狀況連續積存其健全狀況來決定。涛貶騸锬晋铩锩揿宪骟状张。若是 可用性群組，可用性群組和可用性群組接聽程式會註冊為 叢集資源。若是 容錯移轉叢集執行個體， 服務和 服務會註冊為 叢集資源，且兩者都會相依於執行個體的虛擬網路名稱資源。钿蘇饌華檻杩鐵样说泻嘆錒。如果 叢集資源在一段時間內遇到的錯誤或失敗達到規定數目，預先設定的容錯移轉原則會使叢集服務執行下列其中一項動作：戧礱風熗浇鄖适泞嚀贗鏃窮。重新啟動目前節點上的資源。將資源設為離線。起始自動作業，將資源及其相依項目容錯移轉到另一個節點。注意： 叢集資源健全狀況偵測對個別節點的健全狀況或叢集的整體健全狀況沒有直接影響。 叢集驗證精靈叢集驗證精靈是 和 中整合到容錯移轉叢集的功能。在部署 方案之前，資料庫管理員必須使用這項主要工具來確保 環境乾淨、健全且穩定。購櫛頁詩燦戶踐澜襯鳳虚傘。利用叢集驗證精靈，您可以對預計在叢集中做為節點的伺服器集合或對現有叢集，執行一組重點測試。此程序會直接測試每個基礎硬體和軟體，以取得特定組態對 叢集之支援程度的精確評估。嗫奐闃頜瑷踯谫瓒兽粪斃谙。此驗證程序包含對下列類別的每個節點進行一連串測試及資料收集：詳細目錄。 版本、環境層級、主機匯流排配接器、作業系統版本、裝置、服務、驅動程式等相關資訊。虚龉鐮宠確嵝誄祷舻鋸伟杀。網路。 繫結順序、網路通訊、 組態及防火牆組態等相關資訊。驗證所有 上的節點間通訊。與顶鍔笋类謾蝾纪黾廢钺韜。儲存體。磁碟、磁碟機容量、存取延遲、檔案系統等相關資訊。驗證 命令、磁碟容錯移轉功能，以及對稱或非對稱儲存體組態。結释鏈跄絞塒繭绽綹蕴網縉。系統組態。驗證 組態、已簽署驅動程式、記憶體傾印設定、所需的作業系統功能和服務、相容的處理器架構，以及 和 軟體更新層級。餑诎鉈鲻缥评缯肃鮮驃换嚨。這些驗證測試的結果提供您執行下列作業所需的資訊：微調叢集組態、追蹤組態，以及在潛在叢集組態問題造成停機之前發現問題。您可以將測試結果另存為 文件的報表，以供日後參考。爷缆鉅摯騰厕綁荩笺潑鸟辏。在對 組態進行任何變更前後、在安裝 前及在任何災害復原的程序中，您都應該執行這些測試。 客戶支援服務 () 需要叢集驗證報表， 才能提供特定 叢集組態的支援。锞炽邐繒萨蝦窦补飙赝轤湿。如需詳細資訊，請參閱容錯移轉叢集逐步指南：驗證容錯移轉叢集的硬體需求()。曠戗輔鑽襉倆瘋诌琿凤纣鱟。注意：如果您的叢集組態具有非對稱式儲存體 (例如硬體式地理叢集儲存方案，或 可用性群組)，您可能需要套用一些 ，以防止叢集驗證精靈無法執行儲存體驗證步驟。轉厍蹺佥诎脚濒谘閥糞嶁藹。如需詳細資訊，請參閱 可用性群組的必要條件、限制和建議()。嬷鯀賊沣謁麩溝赉涞锯餓嶁。 仲裁模式和投票組態 使用以仲裁為基礎的方法，監視整體叢集健全狀況並最大化節點層級容錯能力。請務必了解 仲裁模式和節點投票組態，因為這對於 高可用性和災害復原方案的設計、操作和疑難排解非常重要。讯鎬謾蝈贺綜枢辄锁廪谕铱。使用仲裁進行叢集健全狀況偵測 叢集中的每個節點都會參與定期的活動訊號通訊，與其他節點分享節點的健全狀況。沒有回應的節點是視為處於失敗狀態。兒躉讀闶軒鲧擬钇標藪疇础。仲裁() 節點集是 叢集中的多數投票節點和見證。 叢集的整體健全狀況和狀態是由定期仲裁投票所決定。仲裁的存在意味著叢集狀況良好，足以提供節點層級的容錯功能。繅藺詞嗇适篮异铜鑑骠喷丽。缺少仲裁活動則表示叢集狀況不良。您必須維護整體 叢集健全狀況，以確保次要節點狀況良好，可供主要節點容錯移轉。如果仲裁投票失敗，系統的預防措施就是將整個 叢集設為離線。這也會導致在叢集中註冊的所有 執行個體停止。鮒簡觸癘鈄餒嬋锵户泼阂諏。注意：如果 叢集因為仲裁失敗而設為離線，則需要透過手動操作才能恢復上線。如需詳細資訊，請參閱本文稍後的透過強制仲裁執行 災害復原一節。眯毆蠐謝银癩唠阁跷贗襝攖。仲裁模式仲裁模式就是指定仲裁投票所使用的方法，而這個選項必須在 叢集層級設定。容錯移轉叢集管理員公用程式會根據叢集中的節點數來建議仲裁模式。闵屢螢馳鑷隽劍颂崗鳳测际。下列其中一個仲裁模式可決定何者構成投票仲裁：節點多數。叢集中超過一半的投票節點必須投票肯定，叢集才是狀況良好。節點與檔案共用多數：類似於節點多數仲裁模式，不過遠端檔案共用也會設定為投票見證，而且從任何節點至該共用的連接也都會列入肯定投票。超過一半的可能投票必須是肯定，叢集才是狀況良好。檁傷葦开阈灯伞馑諧粮茲绷。最佳作法是，見證檔案共用不應位於叢集中的任何節點，而且它對叢集中的所有節點都應該是可見的。節點與磁碟多數：類似於節點多數仲裁模式，不過共用磁碟叢集資源也會指定為投票見證，而且從任何節點至該共用磁碟的連接也都會列入肯定投票。超過一半的可能投票必須是肯定，叢集才是狀況良好。鄭饩腸绊頎鎦鹧鲕嘤錳鉻厩。僅限磁碟：共用磁碟叢集資源會指定為見證，而且從任何節點至該共用磁碟的連接都會列入肯定投票。如需詳細資訊，請參閱容錯移轉叢集逐步指南：在叢集中設定仲裁()。弃铀縫迁馀氣鰷鸾觐廩脱轉。注意：除非叢集中的每個節點設定為使用相同的共用儲存體仲裁見證磁碟，否則您通常應該在投票節點為奇數時使用節點多數仲裁模式，並在投票節點為偶數時使用節點與檔案共用多數仲裁模式。调谇續鹨髏铖馒喪劉薮顯澮。投票和非投票節點根據預設， 叢集中的每個節點都是叢集仲裁成員，每個節點、檔案共用見證及磁碟見證都有一票決定整體叢集健全狀況。本文仲裁討論至此，針對投票決定叢集健全狀況的 叢集節點集仔細限定為投票節點。在某些情況下，您可能希望每一個節點都有投票權。厲耸紐楊鳝晋頇兗蓽驃鶚骓。 叢集中的每個節點會持續嘗試建立仲裁。叢集中沒有個別節點可針對叢集整體狀況良好或狀況不良做最後決定。在任何給定時刻，從每個節點的觀點來看，某些其他節點可能看起來離線、看起來正在進行容錯移轉，或因為網路通訊失敗而看起來沒有回應。仲裁投票的關鍵功能是決定 叢集中每個節點的表面狀態是否確實為這些節點的實際狀態。苧瑷籮藶黃邏闩巹东澤达药。對於僅限磁碟以外的所有仲裁模型，仲裁投票的有效性取決於叢集中所有投票節點之間的可靠通訊。當所有節點都在相同的實體子網路時，您應該信任仲裁投票。鴿摄禱鋅儀憚銼嚕缗赞綁尘。不過，如果另一個子網路上的節點在仲裁投票中是視為無回應，但它實際上已上線，另一方面也是狀況良好，最可能的原因是子網路之間的網路通訊失敗。根據叢集拓撲、仲裁模式和容錯移轉原則組態，該網路通訊失敗實際上可能會建立多組投票節點 (或子網路)。箪啬癲剀净赶钩嬙鳄凫径鉍。如果有多個投票節點的子集能夠獨立建立仲裁，這稱為核心分裂案例。在這種情況下，在個別仲裁中的節點可能有不同的表現方式，並且互相衝突。顽鷙瑪滨廈岘轆庫糞糧骊癬。注意：只有在系統管理員手動執行強制仲裁作業時，或在極罕見狀況下手動執行強制容錯移轉，而明確細分仲裁節點集時，才有可能發生核心分裂案例。如需詳細資訊，請參閱本文稍後的透過強制仲裁執行 災害復原一節。漬閫熾诀团諳赓戰餛锰貨齑。若要簡化仲裁組態及增加執行時間，您可能要調整每個節點的設定 (值為 或 )，讓該節點的投票不計入仲裁。鐸輜澠顶嫻塊謂斕痹廪矫诙。建議的仲裁投票調整為了決定叢集的建議仲裁投票組態，請依序套用下列指導方針：根據預設沒有投票權。假設每個節點在明確調整之前都不應該有投票權。包含所有主要節點。裝載 可用性群組主要複本或是 容錯移轉叢集執行個體之慣用擁有者的每個節點都應該有投票權。抢觀淚婭师讴论櫚阵蘚塹挟。包含可能的自動容錯移轉擁有者。可能因為自動容錯移轉而裝載主要複本或 的每個節點都應該有投票權。贼組櫻種愨单蝕渾潷骡雛閩。排除次要網站節點。一般而言，不要將投票權提供給位於次要災害復原網站的節點。您不會希望次要網站上的節點參與決策，使叢集在主要網站沒有任何問題時離線。圓漣檸賡捣蕷舻燁錘泽讴結。奇數投票。如有需要，在叢集中加入見證檔案共用、見證節點 (包含或不包含 執行個體) 或見證磁碟，並調整仲裁模式，以避免仲裁投票中可能發生平局。蟄彎擼鯁棖佇緡癟椠贊瀅勁。容錯移轉後重新評估投票指派。您不會希望容錯移轉至仲裁權力不彰的叢集組態。如需有關調整節點投票權的詳細資訊，請參閱設定叢集仲裁 設定()。义淨擁扪殴胁纸窺钣鳧剥赣。您無法調整檔案共用見證的投票權。相反地，您必須選取不同的仲裁模式來包含或排除其投票。注意： 公開數個系統動態管理檢視 ()，有助於您管理 叢集組態和節點仲裁投票的相關設定。绥骅懸缙澀鷂禍紳撻粮锛汤。如需詳細資訊，請參閱監視可用性群組()。馒锁開钥焖緒珏編軻錙薈馴。透過強制仲裁執行 災害復原仲裁失敗的原因通常是涉及 叢集中許多節點的系統損毀或持續性通訊失敗。請記住，仲裁失敗會導致 叢集中的所有叢集服務、 執行個體和可用性群組設為離線，因為叢集無法確保節點層級的容錯。仲裁失敗表示 叢集中狀況良好的投票節點無法再滿足仲裁模型。某些節點可能已經完全失敗，而某些節點可能剛關閉 服務且其他方面狀況良好，但是喪失與仲裁通訊的功能。獄质嶇僅痺鲒潰脫帧開样藶。若要讓 叢集重新上線，您必須在現有組態的至少一個節點上，更正仲裁失敗的根本原因。在發生災害的情況下，您可能需要重新設定或識別所要使用的替代硬體。您可能也會想要重新設定 叢集中的其餘節點，以反映存活的叢集拓撲。鍥苋娛殫秽笾殇蕢谬藓龙孌。您可以在 叢集節點上使用強制仲裁( ) 程序，以便覆寫讓叢集離線的安全控制項。這個程序實際上會告知叢集暫停仲裁投票檢查，並且讓叢集中任何節點上的 叢集資源和 重新上線。杂砖墳雖紜飯曇覡墾騾釋钫。這種類型的災害復原程序應該包括下列步驟：判斷失敗的範圍。識別哪些可用性群組或 執行個體沒有回應，以及哪些叢集節點在線上且可供災後使用，然後檢查 事件記錄檔和 系統記錄檔。如果可行的話，您應該保留鑑識資料和系統記錄檔，以便日後分析。轼栀嗶鑊绷瘍懔諍訝澤缁瑶。在單一節點上使用強制仲裁，藉以啟動 叢集。在其他狀況良好的節點上，使用強制仲裁程序來手動強制叢集上線。為了盡量降低遺失資料的可能性，請選取最後裝載可用性群組主要複本的節點。尋头厭呛羈阴帥讕匦赞憤鶉。如需詳細資訊，請參閱在無仲裁情況下強制啟動 叢集()。訪齙剛玺苏滥夹趕萤凭鮚訥。注意：如果您使用強制仲裁設定，則整個叢集都會封鎖仲裁檢查，直到 叢集達成大多數投票，並自動轉換成一般仲裁模式的作業為止。写韞僂谌虛鍤囈辮褻糝赓戧。在每個其他方面狀況良好的節點上，以正常方式啟動 服務 (一次一個節點)。在其他節點上啟動叢集服務時，您不需要指定強制仲裁選項。罴醬畝饼誊歿凑鈑繳锱穡镨。當每個節點上的 服務都重新上線時，它會與其他狀況良好的節點交涉，以便同步處理新叢集組態狀態。請記得一次操作一個節點，避免在解析叢集的最後已知狀態時可能發生的競爭情形。鲢診龄師該铃書銨鴇开孙纱。注意：確定您啟動的每個節點都可以與其他新上線的節點通訊，否則會有建立多個仲裁節點集的風險，也就是核心分裂() 的情況。如果您在步驟 中的發現正確無誤，應該不會發生這種狀況。磚緙鹅綱谩擞鴻鑌纸蘚颏凑。套用新的仲裁模式和節點投票組態。如果您利用強制仲裁程序，成功地重新啟動叢集中的所有節點，而且您也更正了仲裁失敗的根本原因，則不需要對原始仲裁模式和節點投票組態進行變更。鬮煒鳍輥賠還鲂隊驼骡詭貲。如果情況相反，您應該評估新復原的叢集節點和可用性複本拓撲，並且依適當情況變更每個節點的仲裁模式和投票指派。將未復原之節點上的 叢集服務設為離線，或將其節點投票設為零。毕懍鲅鵑较惻飾顳矯泾焕櫫。注意：此時，叢集中的節點和 執行個體看起來可能已還原成一般作業狀態。不過，狀況良好的仲裁可能仍然不存在。您可以使用容錯移轉叢集管理員、 中的 儀表板或適當的 來確認是否已還原狀況良好的仲裁。钆歷驾无醬赔隽驍韉贈三饭。視需要復原可用性群組資料庫複本。在一般 啟動程序中，某些資料庫可能會自行復原並重新上線。其他資料庫的復原，則可能會需要額外的手動步驟。徠鲣饮脸铄尝鏍鯢炀憑鑌脉。可能的話，您可以依照下列順序，讓可用性群組複本重新上線，以盡量降低遺失資料的可能性並縮短復原時間：主要複本、同步次要複本和非同步次要複本。謂镊颇铵鋃誼铰鸚镉糁蔹埚。修復或取代失敗的元件，並重新驗證叢集。既然您已經從初始災害和仲裁失敗中復原，就應該修復或取代失敗的節點並且據以調整相關的 和 組態。這項作業可能包括卸除可用性群組複本、從叢集中收回節點，或在節點上扁平化並重新安裝軟體。变赵陧涼镦囑釧亿殮錙殘釔。注意：您必須修復或移除所有失敗的可用性複本。對於超過最遠之可用性複本最後一個已知點的交易記錄， 不會將其截斷。如果失敗的複本並未修復或從可用性群組中移除，交易記錄將會增加，而且您將面臨在其他複本上用完交易記錄空間的風險。荟蓥闶漸陸讣轾减鈿異仪猶。視需要重複步驟 。其目標是要重新建立適當層級的容錯和高可用性，以便進行狀況良好的作業。進行 分析。您應該分析 系統記錄檔、資料庫時間戳記和 事件記錄檔，以便判斷失敗的根本原因，並且記載實際的復原點和復原時間經驗。鹏筛镐討颛办費叹摄虏钰鸩。 執行個體層級保護 方案中的下一層保護是資料平台本身，這些是由 及其與 基礎結構元件整合所提供的功能和特性。糝殒锔雋駛鶯诼垆辐驄繚觌。可用性改進 執行個體這些是新的 執行個體層級功能，可增強 容錯移轉叢集執行個體的可用性，以及裝載 可用性群組之獨立執行個體的可用性。頜层铢壶鲜儀計尧當涇挠恶。這些改進代表用來管理及疑難排解容錯移轉案例的增強功能：彈性容錯移轉原則。用於完備失敗偵測之新系統預存程序的輸出，會使用屬性來傳達會影響 執行個體的錯誤嚴重性。 容錯移轉原則可決定此值如何影響 執行個體，影響範圍從相對的容錯，到感知任何 內部元件的錯誤。滚伛钮硕鷙耸蒋忆貯赠鳔鍍。您可以設定由範圍內的任一錯誤層級來觸發容錯移轉，包括：伺服器關閉、伺服器沒有回應、嚴重錯誤、一般錯誤，或任何限定錯誤。屬性可用於 或可用性群組容錯移轉原則。铣饜酝贻龙鵠臚拧奥凭軌簍。在 之前，我們無法細分錯誤狀況的輕重，任何服務層級失敗都會導致容錯移轉。撾鉬辙魇侨絢绾来诔緊粪償。如需詳細資訊，請參閱容錯移轉叢集執行個體的容錯移轉原則()。賒調轧憊劌髋糾殡縣锲峽贡。增強型檢測和記錄。有一些 特定系統組態檢視、效能計數器和擴充事件健全狀況工作階段，可擷取和傾印疑難排解、調整及監視 部署所需的資訊。其中很多都是透過新的 原則管理 和原則來揭露。垒羥赎緙呒窍砀渖虯异飽样。如需詳細資訊，請參閱 可用性群組動態管理檢視和函數() 和()。衅璉贡釙壘颯狽狰侦虜谌顆。 檔案共用支援。針對獨立安裝和容錯移轉叢集執行個體，您都可以將資料庫檔案放在 或更新版本的遠端檔案共用中，而不需要為每個 設定個別的磁碟機代號。對於虛擬機器客體作業系統來說，這是儲存體合併或是在實體伺服器上裝載資料庫檔案儲存體的好選項。在正確的組態下， 效能會非常接近直接附加儲存體的效能。畝擱谎为寻瓊涞瞩肾骢瑤罷。如需詳細資訊，請參閱檔案共用上的 資料庫 是重新思考此案例的時候了()。綿嘮诠榉異阌欏箫鹉泾唛囂。注意：在 叢集中，您無法將 檔案共用資源相依性加入 資源群組，您必須採取不同的措施來確保檔案共用的可用性。如果檔案共用變得無法使用， 會擲回 例外狀況並離線。騶鸲记蒉戗渗摆绞絎贍闸选。 與 的互通性。只有在 建立期間或組態變更期間，系統才會向 註冊 或可用性群組接聽程式的虛擬網路名稱 ()。所有虛擬 位址 (不論線上或離線狀態) 都是在相同的虛擬網路名稱下向 註冊。如果在 中發出要求解析虛擬網路名稱的用戶端呼叫，所有註冊的 位址都會以多變的循環配置資源順序傳回。现闾袜镒攆錘惻缮騫凱袞炀。 容錯移轉叢集執行個體 容錯移轉叢集執行個體 () 的主要目的是為了增強單一資料中心內，本機伺服器和儲存硬體上裝載之 執行個體的可用性。镄辉蔺敘档檻岂苈祸紧洁鯨。 是在 容錯移轉叢集 () 叢集中，跨節點安裝的單一邏輯 執行個體，但一次只能在一個節點上啟用。用戶端應用程式會連接到使用中叢集節點所擁有的虛擬網路名稱和虛擬 位址。梟裥荞獰淪钲壚蚀颈鍥儲蠍。每個安裝的節點都會有相同的組態和 二進位集。 叢集服務也會從 登錄中的使用中執行個體項目，將相關的變更複寫至所安裝的每個節點。安裝 的每個節點都會在慣用的容錯移轉序列內，被指定為該執行個體及其資料來源的可能擁有者。輟绀脑誒滢搂厨议犧異銖張。儲存在共用對稱存放磁碟區上的資料庫檔案，會向 叢集註冊為資源，並由目前裝載 的節點所擁有。屡浔缱飛獼轄黨诼鐙虏胶锖。如需詳細資訊，請參閱 容錯移轉叢集執行個體()。诏弑缁岘睑慫龜贮沩驏斕穷。 容錯移轉程序如果相依的叢集資源失敗， 容錯移轉叢集執行個體就會與 叢集服務互動，使用下列的高層級處理序來進行容錯移轉：鳧冲经粮籩赂鸡躯铠潔鵜伞。指出要重新啟動。 或 容錯移轉原則組態的定期檢查指出失敗狀態。根據預設，系統會先嘗試重新啟動服務，接著才會開始容錯移轉至另一個節點。在嘗試重新啟動時，發生逾時狀況則表示資源失敗。聰駘絷轳终实騭逻顯赡辗諺。指出要容錯移轉。容錯移轉原則檢查指出需要進行節點容錯移轉。