《用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn》由会员分享，可在线阅读，更多相关《用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn（28页珍藏版）》请在金锄头文库上搜索。
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 阈值紧密关联。合理的灾难恢复计划应包括： 故障和恢复的粒度。根据故障的位置和类型，您可以在不同级别执行更正操作：数据中心、基础结构、平台、应用程序或工作负荷。 可供调查的原始资料。应准备好基线和最新的监视历史记录、系统警报、事件日志和诊断查询数据，以便有关方面的人士随时查阅。 协调依赖关系。在应用程序堆栈内以及各个利益相关方之间，系统和业务具有怎样的依赖关系？ 决策树。一个预
