和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南.docx

《和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南.docx》由会员分享，可在线阅读，更多相关《和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南.docx（28页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南i用于高可用性和灾难恢复的 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)、Al

2、lan Hirt (SQLHA)、Ayad Shammout (Caregroup)、 Benjamin Wright-Jones (Microsoft)、Charles Matthews (Microsoft)、David P. Smith (ServiceU)、 Juergen Thomas (Microsoft)、Kevin Farlee (Microsoft)、Shahryar G. Hashemi (Motricity)、 Wolfgang Kutschera (Bwin Party)发布时间：发布时间：2012 年 1 月适用范围：适用范围：SQL Server 2012摘要：摘要

3、： 本白皮书讨论如何使用 SQL Server 2012 AlwaysOn 高可用性和灾难恢复解决方案减少计划 内和计划外的停机时间、最大程度地提高应用程序可用性，并且提供数据保护。本文旨在为商业利益相关者、技术决策者、系统架构设计师、基础结构工程师和数据库管理员提 供一般性的背景信息。本文内容分为两大部分：高可用性和灾难恢复的概念。高可用性和灾难恢复的概念。简要讨论规划、管理和测量高可用数据库环境的业务目标的驱动因 素以及面临的挑战。之后，我们将简要概括 SQL Server 2012 AlwaysOn 和 Windows Server 解决方案 的高可用性和灾难恢复功能。SQL Serve

4、r AlwaysOn 保护层。保护层。我们将深入讨论 SQL Server AlwaysOn 解决方案提供的保护层的功能、 基本原理和依赖条件，介绍基础结构可用性、SQL Server 实例级保护、数据库级保护和数据层应 用程序功能。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南ii用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南iii版权信息本文档按“原样”提供。本文档中的信息和表达的观点（包括 URL 和其他 Internet 网站引用）如 有更改，恕不另行通知。您应承担使用本文档所带来的

5、风险。本文档中提及的某些示例只是为了便于说明，纯属虚构。不应据此联想或妄加推断。本文档不向您提供对任何 Microsoft 产品中的任何知识产权的任何法律权利。您可以出于内部参考 目的复制和使用本文档。 2012 Microsoft。保留所有权利。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南iv目录目录高可用性和灾难恢复的概念高可用性和灾难恢复的概念.1高可用性简介.1计划内停机时间与计划外停机时间 .1降级的可用性.2停机时间的量化.2恢复目标.2确定合理的 ROI 或机会成本.3监视可用性状况.3规划灾难恢复.4概述：使用 Micros

6、oft SQL Server 2012 实现高可用性.4SQL Server AlwaysOn.4显著减少计划的停机时间.5消除闲置的硬件并提高成本效益和性能 .5轻松部署和管理.5比较 RPO 和 RTO 能力.6SQL Server AlwaysOn 保护层保护层 .7基础结构可用性.8Windows 操作系统.8Windows Server 故障转移群集.9WSFC 群集验证向导.11通过强制仲裁进行 WSFC 灾难恢复.14SQL Server 实例级保护.15可用性改进 SQL Server 实例.15AlwaysOn 故障转移群集实例.16数据库可用性.18AlwaysOn 可用性

7、组.18可用性组故障转移.20可用性组侦听器.21可用性改进 数据库 .22客户端连接建议.23结论结论 .24用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南1高可用性和灾难恢复的概念高可用性和灾难恢复的概念当所有利益相关者对规划、管理和测量 RTO 和 RPO 目标的相关业务驱动因素、面临的挑战和要实 现的目标达成共识后，您就可以为高可用性和灾难恢复解决方案选择最合适的数据库技术。熟悉这些概念的读者可以直接阅读本文的概述：使用 Microsoft SQL Server 2012 实现高可用性 一节。高可用性简介高可用性简介对于一个软件应用程

8、序或服务来说，高可用性归根到底是要根据最终用户的体验和期望来判断。 我们感受得到的停机时间对业务的影响可能包括：信息丢失、资产受损、生产效率下降、机会丢 失、合同无法履行或信誉受损。高可用性解决方案的主要目标是尽量减小停机时间的负面影响。合理的策略应实现业务流程、 服务级别协议 (SLA) 与技术能力、基础结构成本之间的最佳平衡。根据协议以及客户和利益相关者的期望，平台应该是高度可用的。系统的可用性可按以下公式 计算：实际的运行时间期望的运行时间 100%所得的值在业界通常用解决方案能够提供的 9 的个数来表示：这个值代表了每年解决方案运行的 实际分钟数，或相反，代表了解决方案停机的分钟数。9

9、 的个数的个数可用性百分比可用性百分比每年总停机时间每年总停机时间 299%3 天 15 小时 399.9%8 小时 45 分钟 499.99%52 分钟 34 秒 599.999%5 分钟 15 秒计划内停机时间与计划外停机时间计划内停机时间与计划外停机时间 系统停机可能是计划或意料之中的行为，也可能是意外故障导致的。如果正确管理停机时间， 它将不会带来负面影响。有两类主要的可预见的停机时间：计划的维护。计划的维护。在执行计划的维护任务（如软件修补、硬件升级、密码更新、脱机重建索引、 数据加载或灾难恢复过程演习）之前，应该预先公布和协调相应的时间范围。详尽、管理良 好的操作过程可以最大程度减

10、少停机时间和防止数据丢失。计划的维护活动可以看作一项必 要的投资，以预防或减轻更严重的计划外潜在停机故障。计划外停机。计划外停机。这种情况通常可能是发生了系统级、基础结构或流程故障，而这种故障不在计 划之内或不可控制，或者是虽然可以预见但是发生的可能性很小，或认为故障的影响在可接 受的范围之内。可靠的高可用性解决方案可以检测这类故障，自动从停机中恢复，然后重建 容错功能。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南2在确定高可用性的 SLA 时，您应针对计划的维护活动和计划外停机时间分别计算关键性能指标 (KPI)。此方法使您可以将计划的维

11、护活动方面的投资金额同这些活动避免计划外停机时间所减小 的损失进行比较。降级的可用性降级的可用性 高可用性不应该是一种非黑即白的硬性指标。在出现故障的时候，最终用户通常可以接受系统是 部分可用的，或具有有限的功能或降级的性能，而不是完全彻底的停机。这些不同的可用性级别 包括：只读和延迟的操作。只读和延迟的操作。在进行维护期间或在分阶段的灾难恢复期间，仍可以检索数据，但新的 工作流和后台处理可能暂时停止或排队。数据滞后和应用程序响应能力下降。数据滞后和应用程序响应能力下降。由于工作负荷繁重、处理工作积压或部分平台故障， 有限的硬件资源可能被过度使用或容量变小。用户体验可能变差，但是工作仍然可以完

12、成， 只是效率降低了。部分、暂时性或紧急故障。部分、暂时性或紧急故障。取决于遇到错误时重试或自我更正的应用程序逻辑或硬件堆栈的 可靠性。这类错误可能以数据滞后或应用程序响应能力下降的形式显示给最终用户。部分端到端故障。部分端到端故障。计划内或计划外停机可能以温和的方式发生在解决方案堆栈的垂直层（基 础结构、平台和应用程序）内，也可能以水平方式发生在不同功能组件之间。根据受影响的 功能或组件，用户可能会遇到任务部分成功或性能降级的情况。应该在解决方案中考虑接受这些退而求其次的方案，将它们视为一种代替完全停机的次级可用性 方案，也可以作为分阶段的灾难恢复过程的中间环节。停机时间的量化停机时间的量化

13、一旦发生停机事件，无论是计划内还是计划外，主要业务目标都是尽快使系统重新联机并尽量减 少数据丢失。每一分钟的停机时间都会产生直接和间接成本。对于计划外的停机时间，您需要花 时间和精力去确定停机发生的原因、当前的系统状态以及还原所需的步骤，但是必须精确把握这 些工作所需的时间和工作量。一旦某个停机事件达到某个预定的临界点，您应该做出或者寻求相应的业务决策，以便停止调查 停机事件或者执行维护任务，使系统恢复联机状态，并且在需要时重建容错功能。恢复目标恢复目标 数据冗余是高可用性数据库解决方案的重要组成部分。主 SQL Server 实例上的事务活动以同步或 异步方式应用到一个或多个辅助实例。发生停

14、机时，正在进行中的事务可能回滚，或由于数据传 播的延迟而在辅助实例上丢失。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南3您可以测量这种影响并设置相关的恢复目标：业务恢复需要多长的时间，以及恢复的最后一个事 务有多长时间的滞后。恢复时间目标恢复时间目标 (RTO)。这是指停机的持续时间。初始目标是使系统重新联机，至少提供一个只 读容量以便于调查故障。但是，最终的目标是将整个服务还原到可以执行新事务的点。恢复点目标恢复点目标 (RPO)。这通常指可接受的数据丢失的度量值。它是故障前最后提交的数据事务与 故障后恢复的最新数据之间的时间间隔或滞后值

15、。实际的数据丢失可能会有所不同，具体取 决于发生故障时系统的工作负荷、故障类型和所使用的高可用性解决方案类型。您应使用 RTO 和 RPO 值作为目标来指示业务容忍的停机时长和可接受的数据丢失量，并将它作为 监视可用性状况的度量值。确定合理的确定合理的 ROI 或机会成本或机会成本 停机时间的业务成本可能是金钱损失，也可能是企业信誉的损失。这些成本可能随时间而累积， 也可能在停机期间的某个点发生。除了使用指定的恢复时间和数据恢复点来预测停机导致的成本 之外，您还可以计算实现您的 RTO 和 RPO 目标或避免停机所需的业务流程和基础结构的投资总额。 这些投资的目的应包括：避免停机时间。避免停机

16、时间。如果从一开始没有发生停机，则可以完全避免停机恢复成本。投资中包含容 错和冗余硬件或基础结构的成本、将工作负荷分布到多个隔离的故障点的成本以及出于预防 性维护目的而发生的计划停机的成本。自动恢复。自动恢复。如果发生系统故障，您可以通过自动透明的恢复机制大大减小停机时间对客户体 验的影响。资源利用。资源利用。辅助或备用基础结构可以闲置，直到发生停机。它也可以用于处理只读工作负荷， 或通过将工作负荷分布到所有可用硬件来提高总体系统性能。对于指定的 RTO 和 RPO 目标，所需的可用性和恢复投资，以及预测的停机时间成本，可以表示为 时间的函数。在实际停机期间，这允许您根据停机时间长短来进行基于

17、成本的决策。监视可用性状况监视可用性状况 从运行角度，在实际停机期间，您不应尝试实时考虑所有相关的变量和计算 ROI 或机会成本。 您应监视备用实例上的数据滞后时间，将其作为预期的 RPO 度量值。发生停机时，您还应限制在停机期间调查停机原因所花的初始时间，而且应侧重验证恢复环境的 运行状况，然后依赖详细的系统日志和数据的辅助副本以进行后续的法医式分析。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南4规划灾难恢复规划灾难恢复 高可用性工作是采取一些措施来防止停机发生，而灾难恢复工作则是在停机后采取一些措施来重 建高可用性。应该尽可能在实际发生

18、停机前，制定完善的灾难恢复过程，并且明确各自的责任。根据活动的监 视和警报，是否要启动自动或手动故障转移和恢复计划的决策应该与预先确定的 RTO 和 RPO 阈值 紧密关联。合理的灾难恢复计划应包括：故障和恢复的粒度。故障和恢复的粒度。根据故障的位置和类型，您可以在不同级别执行更正操作：数据中心、 基础结构、平台、应用程序或工作负荷。可供调查的原始资料。可供调查的原始资料。应准备好基线和最新的监视历史记录、系统警报、事件日志和诊断查 询数据，以便有关方面的人士随时查阅。协调依赖关系。协调依赖关系。在应用程序堆栈内以及各个利益相关方之间，系统和业务具有怎样的依赖 关系？决策树。决策树。一个预先确

19、定的、可重复操作并且经过验证的决策树应该包括角色责任、故障分类、 以 RPO 和 RTO 目标表示的故障转移标准以及指定的恢复步骤。验证。验证。在执行从停机中恢复的步骤之后，必须执行什么操作来验证系统已恢复到正常运行 状态？文档。文档。用一系列文档记录上述信息，要足够详细并且条理清晰，以便第三方团队可以在尽量 不借助外部帮助的情况下执行恢复计划。此类文档通常称为“运行手册”或“操作指南”。恢复演习。恢复演习。定期演习灾难恢复计划以确定 RTO 目标的基准值，并考虑使主站点和每个灾难恢 复站点定期轮流充当主生产站点。概述：使用概述：使用 Microsoft SQL Server 2012 实现高

20、可用性实现高可用性实现所需的 RPO 和 RTO 目标涉及确保关键应用程序的连续运行，以及保护关键数据不受计划内和 计划外停机的影响。SQL Server 提供了一系列功能可以帮助您实现这些目标，而且所需的成本和 复杂性也不高。非常熟悉新的 AlwaysOn 功能的读者可以直接阅读本文的 SQL Server AlwaysOn 保护层 一节，以便 更加深入地了解相关的功能。SQL Server AlwaysOn AlwaysOn 是一种全新的集成式高可用性和灾难恢复解决方案，具有灵活性高、成本经济的特点。 它可以在数据中心内和数据中心间提供数据和硬件冗余，能够缩短应用程序故障转移的时间，从 而

21、提高关键任务应用程序的可用性。AlwaysOn 在配置方面极具灵活性，能够重复利用现有的硬件 资产。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南5AlwaysOn 解决方案可以利用两个主要的 SQL Server 2012 功能在数据库级别和实例级别配置可用性：AlwaysOn 可用性组可用性组：这是 SQL Server 2012 中引入的新功能，它大大增强了数据库镜像的功能， 帮助确保应用程序数据库的可用性；它采用基于日志的数据移动来提供数据保护，无需共享 磁盘，可以实现零数据丢失。可用性组提供一组集成的选项，包括逻辑数据库组的自动和手

22、动故障转移，支持多达四个辅 助副本，可以快速进行应用程序故障转移和自动页修复。AlwaysOn 故障转移群集实例故障转移群集实例 (FCI)：此功能增强了 SQL Server 故障转移群集功能并支持跨子网 的多站点群集，可以跨数据中心对 SQL Server 实例进行故障转移。同时，实例故障转移更快更 可预测，从而加快了应用程序恢复。显著减少计划的停机时间显著减少计划的停机时间 在任何组织中，应用程序停机的主要原因是操作系统修补、硬件维护等活动导致的计划停机。 这几乎占 IT 环境中总停机时间的 80%。SQL Server 2012 通过减少修补要求和支持更多联机维护操作，可以帮助显著减少

23、计划停机时间。Windows Server Core。SQL Server 2012 支持在 Windows Server Core（Windows Server 2008 和 Windows Server 2008 R2 的最小简化部署选项）上进行部署。此操作系统配置可以最大限度地 减少操作系统修补要求（可减少 60%），从而减少计划停机时间。联机操作。联机操作。SQL Server 2012 增强了对联机操作（如 LOB 重建索引和添加具有默认值的列）的 支持，这可以帮助减少数据库维护操作的停机时间。滚动升级和修补。滚动升级和修补。AlwaysOn 功能为实例的滚动升级和修补提供了便利，这

24、对减少应用程序停 机时间有很大帮助。Hyper-V 上的上的 SQL Server。在 Hyper-V 环境中托管的 SQL Server 实例还具有实时迁移的好处， 它允许您不用停机即可在主机间迁移虚拟机。管理员可以在主机上执行维护操作而不会影响 应用程序。消除闲置的硬件并提高成本效益和性能消除闲置的硬件并提高成本效益和性能 典型的高可用性解决方案通常需要部署昂贵、冗余的被动服务器。AlwaysOn 可用性组使您可以将 被动或空闲服务器上的辅助数据库副本用于只读工作负荷，如 SQL Server Reporting Services 报表 查询或备份操作。同时利用主数据库副本和辅助数据库副本

25、可以帮助提高所有工作负荷的性能， 因为在您的服务器硬件资产中更均衡地分配了资源。轻松部署和管理轻松部署和管理 诸如配置向导、Windows PowerShell 命令行界面支持、面板、动态管理视图 (DMV)、基于策略的 管理和 System Center 集成等功能，可以帮助简化可用性组的部署和管理。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南6比较比较 RPO 和和 RTO 能力能力 恢复点目标 (RPO) 和恢复时间目标 (RTO) 的业务目标应是为您的高可用性和灾难恢复解决方案选 择 SQL Server 技术的重要推动因素。 下表

26、粗略比较了这些不同解决方案可能得到的结果类型：高可用性和灾难恢复高可用性和灾难恢复 SQL Server 解决方案解决方案可能的数据可能的数据 丢失丢失 (RPO)可能的恢复可能的恢复 时间时间 (RTO)自动故障自动故障 转移转移可读辅助可读辅助 副本副本(1)AlwaysOn 可用性组可用性组 同步提交零几秒是(4)0 - 2AlwaysOn 可用性组可用性组 异步提交几秒几分钟否0 - 4AlwaysOn 故障转移群集实例故障转移群集实例不适用(5)几秒 到几分钟是不适用数据库镜像数据库镜像(2) 高安全性（同步 + 见证服务器）零几秒是不适用数据库镜像数据库镜像(2) 高性能（异步）几

27、秒(6)几分钟(6)否不适用日志传送日志传送几分钟(6)几分钟 到几小时(6)否在还原期间 不可用 备份、复制、还原备份、复制、还原(3)几小时(6)几小时 到几天(6)否在还原期间 不可用(1) AlwaysOn 可用性组最多可以有四个辅助副本，无论它们是何种类型。(2) 后续版本的 Microsoft SQL Server 将删除该功能。请改用 AlwaysOn 可用性组。(3) 备份、复制、还原适用于灾难恢复，但是不能提供高可用性。(4) 不支持从可用性组到故障转移群集实例或反向的自动故障转移。(5) FCI 本身并不提供数据保护；数据丢失取决于存储系统的实现形式。(6) 高度依赖于工作

28、负荷、数据量和故障转移过程。用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南7SQL Server AlwaysOn 保护层保护层SQL Server AlwaysOn 解决方案有助于在基础结构和应用程序组件的几个逻辑和物理层上提供容错 和灾难恢复功能。从过去经验来看，涉及的各个人员和角色具有不同的职责已成为共识，这样每 个责任人只关注这些解决方案层的一部分。本节的内容将对其中的每个层进行更深入的描述，并为设计方案讨论和实现形式决策提供基本的 原理和指南。成功的 SQL Server AlwaysOn 解决方案要求了解这些层并协调这些层的活动：

29、基础结构级别。基础结构级别。服务器级的容错和节点内部的网络通信都是利用 Windows Server 故障转移群 集 (WSFC) 功能来监视运行状况和协调故障转移。SQL Server 实例级别。实例级别。SQL Server AlwaysOn 故障转移群集实例 (FCI) 是在 WSFC 群集中的几个服 务器节点上安装并可以在其中进行故障转移的 SQL Server 实例。承载 FCI 的节点都连接到可靠 的对称共享存储设备（SAN 或 SMB）。数据库级别。数据库级别。可用性组 是一组共同实现故障转移的用户数据库。可用性组由一个主副本和一 至四个辅助副本组成。每个副本均由 WSFC 群集

30、不同节点上的 SQL Server（FCI 或非 FCI）实例 托管。客户端连接。客户端连接。数据库客户端应用程序可以直接连接到 SQL Server 实例网络名称，也可以连接到 与可用性组侦听器 绑定的虚拟网络名称 (VNN)。VNN 会提取 WSFC 群集和可用性组拓扑，以逻 辑方式将连接请求重定向到相应的 SQL Server 实例和数据库副本。下图中显示了一个典型的 AlwaysOn 解决方案的逻辑拓扑：用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南8基础结构可用性基础结构可用性AlwaysOn 可用性组和 AlwaysOn 故障转移

31、群集实例都是利用 Windows Server 操作系统和 WSFC 作 为平台技术。想要成为一名成功的 Microsoft SQL Server 数据库管理员，您需要比以往更加透彻地 了解这些技术。Windows 操作系统操作系统 SQL Server 依赖 Windows 平台提供用于网络、存储、安全性、修补和监视活动的底层基础结构和 服务。SQL Server 2012 的各个版本之间以递增的方式逐渐增加功能和容量，这一点类似于 Windows Server 2008 R2 操作系统的 Windows Server 2008 R2 Standard 版本、Windows Server 2

32、008 R2 Enterprise 版本和 Windows Server 2008 R2 Datacenter 版本。有关详细信息，请参阅：安装 SQL Server 2012 的硬件和软件要求 (http:/ zh-cn/library/ms143506(SQL.110).aspx)。Windows Server Core 安装选项安装选项 作为一项重要的高可用性功能，SQL Server 2012 支持在 Windows Server 2008 或更高版本的 Server Core 安装选项上进行部署。Server Core 安装选项是服务器系统的最小环境，可以运行具有有限功 能的服务器角

33、色，并且只支持非常有限的 GUI 应用程序。默认情况下，只启用必要的服务和命令 提示符环境。此操作模式减小了操作系统的受攻击面和系统开销，并且可以显著降低维护、服务和修补的要求。在 Windows Server Core 上部署 SQL Server 2012 的一个重要注意事项是：SQL Server 和操作系统的 所有部署、配置、管理和维护都必须使用脚本环境（如 Windows PowerShell）或通过使用命令行 或远程工具来完成。针对私有云优化针对私有云优化 SQL Server 高可用性和灾难恢复方案在私有云环境中日显重要。将 SQL Server 部署到私有云可以帮助确保高 效使

34、用您的计算机、网络和存储资源，减小物理占用空间、投资金额和运行开支。它将帮助您高 效地合并部署、扩展资源，并在不影响控制的情况下按需部署资源。除了对 Hyper-V 主机和客户操作系统的 Windows Server 故障转移群集支持之外，SQL Server 还支持 实时迁移，即可以在主机之间移动虚拟机而感觉不到系统停机。实时迁移还可以与客户群集一起 使用。有关详细信息，请参阅私有云计算 - 针对私有云优化 SQL Server (http:/ Microsoft SQL Server AlwaysOn 解决方案指南9Windows Server 故障转移群集故障转移群集 Windows S

35、erver 故障转移群集 (WSFC) 提供了各种基础结构功能来支持所承载的服务器应用程序 （如 Microsoft SQL Server）的高可用性和灾难恢复方案。如果一个 WSFC 群集节点或服务失败，则该节点上承载的服务或资源可在一个称为“故障转移” 的过程中自动或手动转移到另一个可用节点。使用 AlwaysOn 解决方案，此过程可同时应用到 FCI 和可用性组。WSFC 群集中的节点协同工作，共同提供这些类型的功能：分布式元数据和通知。分布式元数据和通知。群集中的每个节点上维护着 WSFC 服务和承载的应用程序元数据。除了 承载的应用程序设置之外，此元数据还包括 WSFC 配置和状态。

36、对一个节点上的元数据或状态 的更改会自动传播到群集中的其他节点。资源管理。资源管理。群集中的各节点可能提供物理资源，如直接连接的存储 (DAS)、网络接口和对共享 磁盘存储的访问。承载的应用程序（如 SQL Server）将其本身注册为群集资源，并且可配置启 动和运行状况对于其他资源的依赖关系。运行状况监视。运行状况监视。节点间和主节点运行状况检测是通过结合使用信号样式的网络通信和资源监 视来实现的。群集的总体运行状况是由群集中节点仲裁的投票决定。故障转移协调。故障转移协调。每个资源都配置为由主节点承载，并且每个资源均可自动或手动转移到一个 或多个辅助节点。基于运行状况的故障转移策略控制节点之间资源所有权的自动转移。在发 生故障转移时，节点和承载的应用程序会收到通知，以便其做出适当的响应。有关详细信息，请参阅 Windows Server | 故障转移群集和节点平衡 (http:/ WSFC 群集和仲裁管理的内部工作机制现在变得极为重要。AlwaysOn 运 行状况监视、管理和故障恢复步骤在本质上都与您的 WSFC 配置有关。WSFC 存储配置存储配置 Windows Server 故障转移群集依赖于群集中的每个节点来管理与其连接的存储设备、磁盘卷和文 件系统。WSFC 假定存储子系统非常可靠，因此如果连接到某一节点的存储设备不可用，则认为 该群集节点