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)发布时间：2012 年 1 月适用范围：SQL Server 2012摘要：本白皮书讨论如何使用 SQL Server 2012 AlwaysOn 高可用性和灾难恢复解决方案减少计划内和计划外的停机时间、最大程度地提高应用程序可
3、用性，并且提供数据保护。本文旨在为商业利益相关者、技术决策者、系统架构设计师、基础结构工程师和数据库管理员提供一般性的背景信息。本文内容分为两大部分：高可用性和灾难恢复的概念。简要讨论规划、管理和测量高可用数据库环境的业务目标的驱动因素以及面临的挑战。之后，我们将简要概括 SQL Server 2012 AlwaysOn 和 Windows Server 解决方案的高可用性和灾难恢复功能。SQL Server AlwaysOn 保护层。我们将深入讨论 SQL Server AlwaysOn 解决方案提供的保护层的功能、基本原理和依赖条件，介绍基础结构可用性、SQL Server 实例级保护、数
4、据库级保护和数据层应用程序功能。版权信息本文档按“原样”提供。本文档中的信息和表达的观点（包括 URL 和其他 Internet 网站引用）如有更改，恕不另行通知。您应承担使用本文档所带来的风险。本文档中提及的某些示例只是为了便于说明，纯属虚构。不应据此联想或妄加推断。本文档不向您提供对任何 Microsoft 产品中的任何知识产权的任何法律权利。您可以出于内部参考目的复制和使用本文档。 2012 Microsoft。保留所有权利。目录高可用性和灾难恢复的概念1高可用性简介1计划内停机时间与计划外停机时间1降级的可用性2停机时间的量化2恢复目标2确定合理的 ROI 或机会成本3监视可用性状况3
5、规划灾难恢复4概述：使用 Microsoft SQL Server 2012 实现高可用性4SQL Server AlwaysOn4显著减少计划的停机时间5消除闲置的硬件并提高成本效益和性能5轻松部署和管理5比较 RPO 和 RTO 能力6SQL Server AlwaysOn 保护层7基础结构可用性8Windows 操作系统8Windows Server 故障转移群集9WSFC 群集验证向导11通过强制仲裁进行 WSFC 灾难恢复14SQL Server 实例级保护15可用性改进 SQL Server 实例15AlwaysOn 故障转移群集实例16数据库可用性18AlwaysOn 可用性组1
6、8可用性组故障转移20可用性组侦听器21可用性改进 数据库22客户端连接建议23结论24用于高可用性和灾难恢复的 Microsoft SQL Server AlwaysOn 解决方案指南iv高可用性和灾难恢复的概念当所有利益相关者对规划、管理和测量 RTO 和 RPO 目标的相关业务驱动因素、面临的挑战和要实现的目标达成共识后，您就可以为高可用性和灾难恢复解决方案选择最合适的数据库技术。熟悉这些概念的读者可以直接阅读本文的概述：使用 Microsoft SQL Server 2012 实现高可用性 一节。高可用性简介对于一个软件应用程序或服务来说，高可用性归根到底是要根据最终用户的体验和期望来
7、判断。我们感受得到的停机时间对业务的影响可能包括：信息丢失、资产受损、生产效率下降、机会丢失、合同无法履行或信誉受损。高可用性解决方案的主要目标是尽量减小停机时间的负面影响。合理的策略应实现业务流程、服务级别协议 (SLA) 与技术能力、基础结构成本之间的最佳平衡。根据协议以及客户和利益相关者的期望，平台应该是高度可用的。系统的可用性可按以下公式计算：实际的运行时间期望的运行时间 100%所得的值在业界通常用解决方案能够提供的 9 的个数来表示：这个值代表了每年解决方案运行的实际分钟数，或相反，代表了解决方案停机的分钟数。9 的个数可用性百分比每年总停机时间299%3 天 15 小时399.9
8、%8 小时 45 分钟499.99%52 分钟 34 秒599.999%5 分钟 15 秒计划内停机时间与计划外停机时间系统停机可能是计划或意料之中的行为，也可能是意外故障导致的。如果正确管理停机时间，它将不会带来负面影响。有两类主要的可预见的停机时间： 计划的维护。在执行计划的维护任务（如软件修补、硬件升级、密码更新、脱机重建索引、数据加载或灾难恢复过程演习）之前，应该预先公布和协调相应的时间范围。详尽、管理良好的操作过程可以最大程度减少停机时间和防止数据丢失。计划的维护活动可以看作一项必要的投资，以预防或减轻更严重的计划外潜在停机故障。 计划外停机。这种情况通常可能是发生了系统级、基础结构
9、或流程故障，而这种故障不在计划之内或不可控制，或者是虽然可以预见但是发生的可能性很小，或认为故障的影响在可接受的范围之内。可靠的高可用性解决方案可以检测这类故障，自动从停机中恢复，然后重建容错功能。在确定高可用性的 SLA 时，您应针对计划的维护活动和计划外停机时间分别计算关键性能指标 (KPI)。此方法使您可以将计划的维护活动方面的投资金额同这些活动避免计划外停机时间所减小的损失进行比较。降级的可用性高可用性不应该是一种非黑即白的硬性指标。在出现故障的时候，最终用户通常可以接受系统是部分可用的，或具有有限的功能或降级的性能，而不是完全彻底的停机。这些不同的可用性级别包括： 只读和延迟的操作。
10、在进行维护期间或在分阶段的灾难恢复期间，仍可以检索数据，但新的工作流和后台处理可能暂时停止或排队。 数据滞后和应用程序响应能力下降。由于工作负荷繁重、处理工作积压或部分平台故障，有限的硬件资源可能被过度使用或容量变小。用户体验可能变差，但是工作仍然可以完成，只是效率降低了。 部分、暂时性或紧急故障。取决于遇到错误时重试或自我更正的应用程序逻辑或硬件堆栈的可靠性。这类错误可能以数据滞后或应用程序响应能力下降的形式显示给最终用户。 部分端到端故障。计划内或计划外停机可能以温和的方式发生在解决方案堆栈的垂直层（基础结构、平台和应用程序）内，也可能以水平方式发生在不同功能组件之间。根据受影响的功能或组
11、件，用户可能会遇到任务部分成功或性能降级的情况。应该在解决方案中考虑接受这些退而求其次的方案，将它们视为一种代替完全停机的次级可用性方案，也可以作为分阶段的灾难恢复过程的中间环节。停机时间的量化一旦发生停机事件，无论是计划内还是计划外，主要业务目标都是尽快使系统重新联机并尽量减少数据丢失。每一分钟的停机时间都会产生直接和间接成本。对于计划外的停机时间，您需要花时间和精力去确定停机发生的原因、当前的系统状态以及还原所需的步骤，但是必须精确把握这些工作所需的时间和工作量。一旦某个停机事件达到某个预定的临界点，您应该做出或者寻求相应的业务决策，以便停止调查停机事件或者执行维护任务，使系统恢复联机状态
12、，并且在需要时重建容错功能。恢复目标数据冗余是高可用性数据库解决方案的重要组成部分。主 SQL Server 实例上的事务活动以同步或异步方式应用到一个或多个辅助实例。发生停机时，正在进行中的事务可能回滚，或由于数据传播的延迟而在辅助实例上丢失。您可以测量这种影响并设置相关的恢复目标：业务恢复需要多长的时间，以及恢复的最后一个事务有多长时间的滞后。 恢复时间目标 (RTO)。这是指停机的持续时间。初始目标是使系统重新联机，至少提供一个只读容量以便于调查故障。但是，最终的目标是将整个服务还原到可以执行新事务的点。 恢复点目标 (RPO)。这通常指可接受的数据丢失的度量值。它是故障前最后提交的数据
13、事务与故障后恢复的最新数据之间的时间间隔或滞后值。实际的数据丢失可能会有所不同，具体取决于发生故障时系统的工作负荷、故障类型和所使用的高可用性解决方案类型。您应使用 RTO 和 RPO 值作为目标来指示业务容忍的停机时长和可接受的数据丢失量，并将它作为监视可用性状况的度量值。确定合理的 ROI 或机会成本停机时间的业务成本可能是金钱损失，也可能是企业信誉的损失。这些成本可能随时间而累积，也可能在停机期间的某个点发生。除了使用指定的恢复时间和数据恢复点来预测停机导致的成本之外，您还可以计算实现您的 RTO 和 RPO 目标或避免停机所需的业务流程和基础结构的投资总额。这些投资的目的应包括： 避免
14、停机时间。如果从一开始没有发生停机，则可以完全避免停机恢复成本。投资中包含容错和冗余硬件或基础结构的成本、将工作负荷分布到多个隔离的故障点的成本以及出于预防性维护目的而发生的计划停机的成本。 自动恢复。如果发生系统故障，您可以通过自动透明的恢复机制大大减小停机时间对客户体验的影响。 资源利用。辅助或备用基础结构可以闲置，直到发生停机。它也可以用于处理只读工作负荷，或通过将工作负荷分布到所有可用硬件来提高总体系统性能。对于指定的 RTO 和 RPO 目标，所需的可用性和恢复投资，以及预测的停机时间成本，可以表示为时间的函数。在实际停机期间，这允许您根据停机时间长短来进行基于成本的决策。监视可用性
15、状况从运行角度，在实际停机期间，您不应尝试实时考虑所有相关的变量和计算 ROI 或机会成本。您应监视备用实例上的数据滞后时间，将其作为预期的 RPO 度量值。发生停机时，您还应限制在停机期间调查停机原因所花的初始时间，而且应侧重验证恢复环境的运行状况，然后依赖详细的系统日志和数据的辅助副本以进行后续的法医式分析。规划灾难恢复高可用性工作是采取一些措施来防止停机发生，而灾难恢复工作则是在停机后采取一些措施来重建高可用性。应该尽可能在实际发生停机前，制定完善的灾难恢复过程，并且明确各自的责任。根据活动的监视和警报，是否要启动自动或手动故障转移和恢复计划的决策应该与预先确定的 RTO 和 RPO 阈
16、值紧密关联。合理的灾难恢复计划应包括： 故障和恢复的粒度。根据故障的位置和类型，您可以在不同级别执行更正操作：数据中心、基础结构、平台、应用程序或工作负荷。 可供调查的原始资料。应准备好基线和最新的监视历史记录、系统警报、事件日志和诊断查询数据，以便有关方面的人士随时查阅。 协调依赖关系。在应用程序堆栈内以及各个利益相关方之间，系统和业务具有怎样的依赖关系？ 决策树。一个预先确定的、可重复操作并且经过验证的决策树应该包括角色责任、故障分类、以 RPO 和 RTO 目标表示的故障转移标准以及指定的恢复步骤。 验证。在执行从停机中恢复的步骤之后，必须执行什么操作来验证系统已恢复到正常运行状态？ 文
17、档。用一系列文档记录上述信息，要足够详细并且条理清晰，以便第三方团队可以在尽量不借助外部帮助的情况下执行恢复计划。此类文档通常称为“运行手册”或“操作指南”。 恢复演习。定期演习灾难恢复计划以确定 RTO 目标的基准值，并考虑使主站点和每个灾难恢复站点定期轮流充当主生产站点。概述：使用 Microsoft SQL Server 2012 实现高可用性实现所需的 RPO 和 RTO 目标涉及确保关键应用程序的连续运行，以及保护关键数据不受计划内和计划外停机的影响。SQL Server 提供了一系列功能可以帮助您实现这些目标，而且所需的成本和复杂性也不高。非常熟悉新的 AlwaysOn 功能的读者
18、可以直接阅读本文的 SQL Server AlwaysOn 保护层 一节，以便更加深入地了解相关的功能。SQL Server AlwaysOnAlwaysOn 是一种全新的集成式高可用性和灾难恢复解决方案，具有灵活性高、成本经济的特点。它可以在数据中心内和数据中心间提供数据和硬件冗余，能够缩短应用程序故障转移的时间，从而提高关键任务应用程序的可用性。AlwaysOn 在配置方面极具灵活性，能够重复利用现有的硬件资产。AlwaysOn 解决方案可以利用两个主要的 SQL Server 2012 功能在数据库级别和实例级别配置可用性： AlwaysOn 可用性组：这是 SQL Server 201
19、2 中引入的新功能，它大大增强了数据库镜像的功能，帮助确保应用程序数据库的可用性；它采用基于日志的数据移动来提供数据保护，无需共享磁盘，可以实现零数据丢失。可用性组提供一组集成的选项，包括逻辑数据库组的自动和手动故障转移，支持多达四个辅助副本，可以快速进行应用程序故障转移和自动页修复。 AlwaysOn 故障转移群集实例 (FCI)：此功能增强了 SQL Server 故障转移群集功能并支持跨子网的多站点群集，可以跨数据中心对 SQL Server 实例进行故障转移。同时，实例故障转移更快更可预测，从而加快了应用程序恢复。显著减少计划的停机时间在任何组织中，应用程序停机的主要原因是操作系统修补
20、、硬件维护等活动导致的计划停机。这几乎占 IT 环境中总停机时间的 80%。SQL Server 2012 通过减少修补要求和支持更多联机维护操作，可以帮助显著减少计划停机时间。 Windows Server Core。SQL Server 2012 支持在 Windows Server Core（Windows Server 2008 和 Windows Server 2008 R2 的最小简化部署选项）上进行部署。此操作系统配置可以最大限度地减少操作系统修补要求（可减少 60%），从而减少计划停机时间。 联机操作。SQL Server 2012 增强了对联机操作（如 LOB 重建索引和添加
21、具有默认值的列）的支持，这可以帮助减少数据库维护操作的停机时间。 滚动升级和修补。AlwaysOn 功能为实例的滚动升级和修补提供了便利，这对减少应用程序停机时间有很大帮助。 Hyper-V 上的 SQL Server。在 Hyper-V 环境中托管的 SQL Server 实例还具有实时迁移的好处，它允许您不用停机即可在主机间迁移虚拟机。管理员可以在主机上执行维护操作而不会影响应用程序。消除闲置的硬件并提高成本效益和性能典型的高可用性解决方案通常需要部署昂贵、冗余的被动服务器。AlwaysOn 可用性组使您可以将被动或空闲服务器上的辅助数据库副本用于只读工作负荷，如 SQL Server R
22、eporting Services 报表查询或备份操作。同时利用主数据库副本和辅助数据库副本可以帮助提高所有工作负荷的性能，因为在您的服务器硬件资产中更均衡地分配了资源。轻松部署和管理诸如配置向导、Windows PowerShell 命令行界面支持、面板、动态管理视图 (DMV)、基于策略的管理和 System Center 集成等功能，可以帮助简化可用性组的部署和管理。比较 RPO 和 RTO 能力恢复点目标 (RPO) 和恢复时间目标 (RTO) 的业务目标应是为您的高可用性和灾难恢复解决方案选择 SQL Server 技术的重要推动因素。下表粗略比较了这些不同解决方案可能得到的结果类型
23、：高可用性和灾难恢复SQL Server 解决方案可能的数据丢失 (RPO)可能的恢复时间 (RTO)自动故障转移可读辅助副本(1)AlwaysOn 可用性组 同步提交零几秒是(4)0 - 2AlwaysOn 可用性组 异步提交几秒几分钟否0 - 4AlwaysOn 故障转移群集实例不适用(5)几秒到几分钟是不适用数据库镜像(2) 高安全性（同步 + 见证服务器）零几秒是不适用数据库镜像(2) 高性能（异步）几秒(6)几分钟(6)否不适用日志传送几分钟(6)几分钟到几小时(6)否在还原期间不可用备份、复制、还原(3)几小时(6)几小时到几天(6)否在还原期间不可用(1) AlwaysOn 可用
24、性组最多可以有四个辅助副本，无论它们是何种类型。(2) 后续版本的 Microsoft SQL Server 将删除该功能。请改用 AlwaysOn 可用性组。(3) 备份、复制、还原适用于灾难恢复，但是不能提供高可用性。(4) 不支持从可用性组到故障转移群集实例或反向的自动故障转移。(5) FCI 本身并不提供数据保护；数据丢失取决于存储系统的实现形式。(6) 高度依赖于工作负荷、数据量和故障转移过程。SQL Server AlwaysOn 保护层SQL Server AlwaysOn 解决方案有助于在基础结构和应用程序组件的几个逻辑和物理层上提供容错和灾难恢复功能。从过去经验来看，涉及的各
25、个人员和角色具有不同的职责已成为共识，这样每个责任人只关注这些解决方案层的一部分。本节的内容将对其中的每个层进行更深入的描述，并为设计方案讨论和实现形式决策提供基本的原理和指南。成功的 SQL Server AlwaysOn 解决方案要求了解这些层并协调这些层的活动： 基础结构级别。服务器级的容错和节点内部的网络通信都是利用 Windows Server 故障转移群集 (WSFC) 功能来监视运行状况和协调故障转移。 SQL Server 实例级别。SQL Server AlwaysOn 故障转移群集实例 (FCI) 是在 WSFC 群集中的几个服务器节点上安装并可以在其中进行故障转移的 SQ
26、L Server 实例。承载 FCI 的节点都连接到可靠的对称共享存储设备（SAN 或 SMB）。 数据库级别。可用性组 是一组共同实现故障转移的用户数据库。可用性组由一个主副本和一至四个辅助副本组成。每个副本均由 WSFC 群集不同节点上的 SQL Server（FCI 或非 FCI）实例托管。 客户端连接。数据库客户端应用程序可以直接连接到 SQL Server 实例网络名称，也可以连接到与可用性组侦听器 绑定的虚拟网络名称 (VNN)。VNN 会提取 WSFC 群集和可用性组拓扑，以逻辑方式将连接请求重定向到相应的 SQL Server 实例和数据库副本。下图中显示了一个典型的 Alwa
27、ysOn 解决方案的逻辑拓扑： 基础结构可用性AlwaysOn 可用性组和 AlwaysOn 故障转移群集实例都是利用 Windows Server 操作系统和 WSFC 作为平台技术。想要成为一名成功的 Microsoft SQL Server 数据库管理员，您需要比以往更加透彻地了解这些技术。Windows 操作系统SQL Server 依赖 Windows 平台提供用于网络、存储、安全性、修补和监视活动的底层基础结构和服务。SQL Server 2012 的各个版本之间以递增的方式逐渐增加功能和容量，这一点类似于 Windows Server 2008 R2 操作系统的 Windows
28、Server 2008 R2 Standard 版本、Windows Server 2008 R2 Enterprise 版本和 Windows Server 2008 R2 Datacenter 版本。有关详细信息，请参阅：安装 SQL Server 2012 的硬件和软件要求 (http:/ Server Core 安装选项作为一项重要的高可用性功能，SQL Server 2012 支持在 Windows Server 2008 或更高版本的 Server Core 安装选项上进行部署。Server Core 安装选项是服务器系统的最小环境，可以运行具有有限功能的服务器角色，并且只支持非常
29、有限的 GUI 应用程序。默认情况下，只启用必要的服务和命令提示符环境。此操作模式减小了操作系统的受攻击面和系统开销，并且可以显著降低维护、服务和修补的要求。在 Windows Server Core 上部署 SQL Server 2012 的一个重要注意事项是：SQL Server 和操作系统的所有部署、配置、管理和维护都必须使用脚本环境（如 Windows PowerShell）或通过使用命令行或远程工具来完成。针对私有云优化 SQL Server高可用性和灾难恢复方案在私有云环境中日显重要。将 SQL Server 部署到私有云可以帮助确保高效使用您的计算机、网络和存储资源，减小物理占用
30、空间、投资金额和运行开支。它将帮助您高效地合并部署、扩展资源，并在不影响控制的情况下按需部署资源。除了对 Hyper-V 主机和客户操作系统的 Windows Server 故障转移群集支持之外，SQL Server 还支持实时迁移，即可以在主机之间移动虚拟机而感觉不到系统停机。实时迁移还可以与客户群集一起使用。有关详细信息，请参阅私有云计算 - 针对私有云优化 SQL Server (http:/ Server 故障转移群集Windows Server 故障转移群集 (WSFC) 提供了各种基础结构功能来支持所承载的服务器应用程序（如 Microsoft SQL Server）的高可用性和灾
31、难恢复方案。如果一个 WSFC 群集节点或服务失败，则该节点上承载的服务或资源可在一个称为“故障转移”的过程中自动或手动转移到另一个可用节点。使用 AlwaysOn 解决方案，此过程可同时应用到 FCI 和可用性组。WSFC 群集中的节点协同工作，共同提供这些类型的功能： 分布式元数据和通知。群集中的每个节点上维护着 WSFC 服务和承载的应用程序元数据。除了承载的应用程序设置之外，此元数据还包括 WSFC 配置和状态。对一个节点上的元数据或状态的更改会自动传播到群集中的其他节点。 资源管理。群集中的各节点可能提供物理资源，如直接连接的存储 (DAS)、网络接口和对共享磁盘存储的访问。承载的应
32、用程序（如 SQL Server）将其本身注册为群集资源，并且可配置启动和运行状况对于其他资源的依赖关系。 运行状况监视。节点间和主节点运行状况检测是通过结合使用信号样式的网络通信和资源监视来实现的。群集的总体运行状况是由群集中节点仲裁的投票决定。 故障转移协调。每个资源都配置为由主节点承载，并且每个资源均可自动或手动转移到一个或多个辅助节点。基于运行状况的故障转移策略控制节点之间资源所有权的自动转移。在发生故障转移时，节点和承载的应用程序会收到通知，以便其做出适当的响应。有关详细信息，请参阅 Windows Server | 故障转移群集和节点平衡 (http:/ WSFC 群集和仲裁管理的
33、内部工作机制现在变得极为重要。AlwaysOn 运行状况监视、管理和故障恢复步骤在本质上都与您的 WSFC 配置有关。WSFC 存储配置Windows Server 故障转移群集依赖于群集中的每个节点来管理与其连接的存储设备、磁盘卷和文件系统。WSFC 假定存储子系统非常可靠，因此如果连接到某一节点的存储设备不可用，则认为该群集节点出现故障。对于基于写的操作，磁盘卷每次使用 SCSI-3 永久性预留逻辑连接到一个群集节点。根据存储子系统的功能和配置，如果一个节点失败，可以将磁盘卷的逻辑所有权转移到群集中的其他节点。对于下面的对比方案，SQL Server AlwaysOn 解决方案都可以使用，
34、但是限于某些特定的 WSFC 存储配置组合，其中包括： 直接连接与远程。存储设备直接物理连接到服务器，或者通过网络或主机总线适配器 (HBA) 由远程设备提供。远程存储技术包括基于存储区域网络 (SAN) 的解决方案（如 iSCSI 或光纤通道）以及基于服务器消息块 (SMB) 文件共享的解决方案。 对称与非对称。如果为群集中的每个节点提供完全相同的逻辑磁盘卷配置和文件路径，则认为存储设备是对称的。基础磁盘卷的物理实现形式和容量可能有所不同。 专用与共享。专用存储设备是为特定使用目的预留并分配给群集中的一个节点。共享存储设备则可供群集中的多个节点访问。可以使用 SCSI-3 协议将兼容的共享存
35、储设备的控制权和所有权从一个节点转移到另一个节点。WSFC 支持“群集共享卷”的并发多节点承载，以便进行文件共享。但是，SQL Server 不支持对共享卷的并发多节点访问。注意：SQL Server FCI 仍要求对称共享存储设备能够被实例的所有可能的节点所有者访问。但是，引入 AlwaysOn 可用性组后，您现在可以在 WSFC 群集中部署不属于 FCI 的其他 SQL Server 实例，每个实例具有自己的唯一、专用本地或远程存储设备。WSFC 资源运行状况检测和故障转移WSFC 群集节点中的每个资源都可以定期或按需报告其状态和运行状况。很多情况可能指示群集资源故障，其中包括：电源故障、
36、磁盘或内存错误、网络通信错误、配置错误或服务不响应。您可使 WSFC 群集资源（如网络、存储或服务）彼此依赖。资源的累计运行状况由该资源及其每个资源依赖项的持续累积运行状况来确定。对于 AlwaysOn 可用性组，可用性组和可用性组侦听器注册为 WSFC 群集资源。对于 AlwaysOn 故障转移群集实例，SQL Server 服务和 SQL Server 代理服务均注册为 WSFC 群集资源，且都依赖于实例的虚拟网络名称资源。如果某个 WSFC 群集资源在一段时间内遇到指定次数的错误或故障，则配置的“故障转移策略”将导致群集服务执行以下操作之一： 重新启动当前节点上的资源。 将资源设为脱机。
37、 开始将资源和它的依赖项自动故障转移到另一个节点。注意：WSFC 群集资源运行状况检测对于单个节点的运行状况或群集的总体运行状况没有直接影响。WSFC 群集验证向导群集验证向导是一个已集成到 Windows Server 2008 和 Windows Server 2008 R2 故障转移群集的功能。它是数据库管理员的重要工具，可以帮助他们在部署 SQL Server AlwaysOn 解决方案前确保具有正常运行、稳定纯净的 WSFC 环境。使用群集验证向导，您可以针对要用作群集节点的服务器集合或现有群集运行一组有针对性的测试。此过程将直接测试各个基础硬件和软件，以准确评估指定配置对 WSFC
38、 群集的支持程度。此验证过程包含一系列的测试，并会在每个节点上收集以下类别的数据： 资产清单。有关 BIOS 版本、环境级别、主机总线适配器、RAM、操作系统版本、设备、服务、驱动程序等的信息。 网络。有关 NIC 绑定顺序、网络通信、IP 配置和防火墙配置的信息。验证所有 NIC 的节点间通信情况。 存储。有关磁盘、驱动器容量、访问延迟时间、文件系统等的信息。验证 SCSI 命令、磁盘故障转移功能、对称或非对称存储配置。 系统配置。验证 Active Directory 配置、驱动程序已签名、内存转储设置、所需的操作系统功能和服务、兼容的处理器体系结构，以及 Service Pack 和 W
39、indows 软件更新级别。这些验证测试的结果为您提供所需的信息，以便优化群集配置、跟踪配置和识别潜在的群集配置问题以免它们导致停机。您可以将测试结果报告保存为 HTML 文档，供以后参考。您应在对 WSFC 配置进行任何更改之前和之后、在安装 SQL Server 前以及在执行任何灾难恢复过程时运行这些测试。Microsoft 客户支持服务部门 (CSS) 要求提供群集验证报告作为 Microsoft 支持指定 WSFC 群集配置的前提条件。有关详细信息，请参阅故障转移群集分步指南：验证故障转移群集的硬件 (http:/ AlwaysOn 可用性组同时使用，您可能需要应用很多修补程序来防止群
40、集验证向导的存储验证步骤失败。有关详细信息，请参阅针对 AlwaysOn 可用性组的先决条件、限制和建议 (http:/ 仲裁模式和投票配置WSFC 使用一种基于仲裁的方法来监视群集的整体运行状况，并且最大限度地提高节点级别的容错能力。理解 WSFC 仲裁模式和节点投票配置对于 AlwaysOn 高可用性和灾难恢复解决方案的设计、操作和故障排除十分重要。通过仲裁执行群集运行状况检测WSFC 群集中的每个节点都参与周期性信号通信，以便与其他节点共享该节点的运行状况。未响应的节点被认为是处于故障状态。“仲裁”节点集是 WSFC 群集中的大多数投票节点和见证服务器。WSFC 群集的总体运行状况和状态
41、是由定期“仲裁投票”确定的。仲裁的存在意味着群集运行状况正常，且能提供节点级别的容错能力。没有仲裁并不指示群集未在正常状况下运行。必须维护整体 WSFC 群集运行状况，以便确保运行状况良好的辅助节点可用于充当要故障转移到的主节点。如果仲裁投票失败，作为一项预防措施，整个 WSFC 群集将被设为脱机。这也将导致所有向群集注册的 SQL Server 实例都停止。注意：如果 WSFC 群集因为仲裁失败而被设为脱机，则需要手动干预以便将其重新联机。有关详细信息，请参阅本文后面的通过强制仲裁进行 WSFC 灾难恢复一节。仲裁模式“仲裁模式”是在 WSFC 群集级别配置的，以指定用于仲裁投票的方法。故障
42、转移群集管理器实用工具将基于群集中的节点数来建议仲裁模式。以下仲裁模式之一用于确定构成投票仲裁的元素： 节点多数：群集中超过一半的投票节点必须投票赞成群集处于正常状态。 节点和文件共享多数：此模式与“节点多数”仲裁模式相似，只不过还另外配置了一个远程文件共享充当投票见证服务器，并且从任何节点到该共享的连接也计为有效赞成投票。赞成投票数超过总投票数的一半即表示群集处于正常状态。作为最佳实践，见证文件共享不应驻留在该群集中的任何节点上，它应该对于该群集中的所有节点都是可见的。 节点和磁盘多数：此模式与“节点多数”仲裁模式相似，只不过还另外指定了一个共享磁盘群集资源充当投票见证服务器，并且从任何节点
43、到该共享磁盘的连接也计为有效赞成投票。赞成投票数超过总投票数的一半即表示群集处于正常状态。 仅磁盘：共享磁盘群集资源指定为见证服务器，并且从任何节点到该共享磁盘的连接也计为有效赞成投票。有关详细信息，请参阅故障转移群集分步指南：在群集中配置仲裁 (http:/ 群集中的每个节点都是群集仲裁的成员；每个节点、文件共享见证服务器和磁盘见证服务器都具有能够确定群集整体运行状况的单个投票。为了便于讨论仲裁，本文现在将 WSFC 群集节点中有权投票的节点称为“投票节点”。在某些情况下，您可能不希望每个节点都具有投票权。WSFC 群集中的每个节点不断尝试建立仲裁。群集中没有任何一个单独节点可以明确确定该群
44、集的整体运行状况是正常还是非正常。在任意给定时刻，从各节点的角度来说，其他一些节点可能好像脱机，或者好像处于故障转移中，或者好像由于网络通信失败而无法响应。仲裁投票的一个关键功能是确定 WSFC 群集中每个节点的明显表现出来的状态是否真的就是这些节点的实际状态。除了“仅磁盘”之外，对于其他所有仲裁模式，仲裁投票的效力取决于群集中所有投票节点之间的可靠通信。当所有节点位于同一物理子网时，您应信任仲裁投票。但是，如果其他子网上的节点在仲裁投票中被视为无响应，但它实际上处于联机状态并且正常运行，则很可能是因为子网之间网络通信失败。根据群集拓扑、仲裁模式和故障转移策略配置，网络通信失败最终可能会创建不
45、止一组（或一个子组）的投票节点。如果多个子组的投票节点能够建立自己的仲裁，这称作“裂脑情形”。在这种情况下，每个仲裁中的节点可能具有不同的行为方式，并互相冲突。注意：裂脑情形仅在系统管理员手动执行强制仲裁操作时或者在非常罕见的情况下（如强制手动故障转移）才可能出现；并且会显式将仲裁节点组进一步划分为多个组/子组。有关详细信息，请参阅本文后面的通过强制仲裁进行 WSFC 灾难恢复 一节。为了简化您的仲裁配置和增加运行时间，您可能要调整每个节点的 NodeWeight 设置（值为 0 或 1），以便不将该节点的投票计为有效仲裁投票。建议的仲裁投票调整要为群集确定建议的仲裁投票配置，请按顺序应用以下准则：1. 默认情况下不投票。在没有明确的判断时，假定每个节点不应投票。2. 包括所有的主节点。承载 AlwaysOn 可用性组主副本或是 AlwaysOn 故障转移群集实例的首选所有者的每个节点都应具有一票。3. 包括可能的自动故障转移所有者。在自动故障转移之后可能承载主副本或 FCI 的每个节点都应具有一票。4. 不包括辅助站点节点。通常，不要向驻留在辅助灾难恢复站点的节点分配投票。在主站点不存在任何问题时，您不会希望辅助站点
