用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn.docx
《用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn.docx》由会员分享，可在线阅读，更多相关《用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn.docx（26页珍藏版）》请在冰豆网上搜索。
用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn
用于高可用性和灾难恢复的MicrosoftSQLServerAlwaysOn解决方案指南
作者：
LeRoyTuttle,Jr.（Microsoft）
供稿人：
CephasLin（Microsoft）、JustinErickson（Microsoft）、LindseyAllen（Microsoft）、
MinHe（Microsoft）、SanjayMishra（Microsoft）
审校：
AlexeiKhalyako（Microsoft）、AllanHirt（SQLHA）、AyadShammout（Caregroup）、BenjaminWright-Jones（Microsoft）、CharlesMatthews（Microsoft）、DavidP.Smith（ServiceU）、JuergenThomas（Microsoft）、KevinFarlee（Microsoft）、ShahryarG.Hashemi（Motricity）、WolfgangKutschera（BwinParty）
发布时间：
2012年1月
适用范围：
SQLServer2012
摘要：
本白皮书讨论如何使用SQLServer2012AlwaysOn高可用性和灾难恢复解决方案减少计划内和计划外的停机时间、最大程度地提高应用程序可用性，并且提供数据保护。
本文旨在为商业利益相关者、技术决策者、系统架构设计师、基础结构工程师和数据库管理员提供一般性的背景信息。
本文内容分为两大部分：
高可用性和灾难恢复的概念。
简要讨论规划、管理和测量高可用数据库环境的业务目标的驱动因素以及面临的挑战。
之后，我们将简要概括SQLServer2012AlwaysOn和WindowsServer解决方案的高可用性和灾难恢复功能。
SQLServerAlwaysOn保护层。
我们将深入讨论SQLServerAlwaysOn解决方案提供的保护层的功能、基本原理和依赖条件，介绍基础结构可用性、SQLServer实例级保护、数据库级保护和数据层应用程序功能。
版权信息
本文档按“原样”提供。
本文档中的信息和表达的观点（包括URL和其他Internet网站引用）如有更改，恕不另行通知。
您应承担使用本文档所带来的风险。
本文档中提及的某些示例只是为了便于说明，纯属虚构。
不应据此联想或妄加推断。
本文档不向您提供对任何Microsoft产品中的任何知识产权的任何法律权利。
您可以出于内部参考目的复制和使用本文档。
©2012Microsoft。
保留所有权利。
高可用性和灾难恢复的概念
当所有利益相关者对规划、管理和测量RTO和RPO目标的相关业务驱动因素、面临的挑战和要实现的目标达成共识后，您就可以为高可用性和灾难恢复解决方案选择最合适的数据库技术。
熟悉这些概念的读者可以直接阅读本文的概述：
使用MicrosoftSQLServer2012实现高可用性一节。
高可用性简介
对于一个软件应用程序或服务来说，高可用性归根到底是要根据最终用户的体验和期望来判断。
我们感受得到的停机时间对业务的影响可能包括：
信息丢失、资产受损、生产效率下降、机会丢失、合同无法履行或信誉受损。
高可用性解决方案的主要目标是尽量减小停机时间的负面影响。
合理的策略应实现业务流程、
服务级别协议（SLA）与技术能力、基础结构成本之间的最佳平衡。
根据协议以及客户和利益相关者的期望，平台应该是高度可用的。
系统的可用性可按以下公式
计算：
所得的值在业界通常用解决方案能够提供的9的个数来表示：
这个值代表了每年解决方案运行的实际分钟数，或相反，代表了解决方案停机的分钟数。
9的个数
可用性百分比
每年总停机时间
2
99%
3天15小时
3
99.9%
8小时45分钟
4
99.99%
52分钟34秒
5
99.999%
5分钟15秒
计划内停机时间与计划外停机时间
系统停机可能是计划或意料之中的行为，也可能是意外故障导致的。
如果正确管理停机时间，
它将不会带来负面影响。
有两类主要的可预见的停机时间：
∙计划的维护。
在执行计划的维护任务（如软件修补、硬件升级、密码更新、脱机重建索引、数据加载或灾难恢复过程演习）之前，应该预先公布和协调相应的时间范围。
详尽、管理良好的操作过程可以最大程度减少停机时间和防止数据丢失。
计划的维护活动可以看作一项必要的投资，以预防或减轻更严重的计划外潜在停机故障。
∙计划外停机。
这种情况通常可能是发生了系统级、基础结构或流程故障，而这种故障不在计划之内或不可控制，或者是虽然可以预见但是发生的可能性很小，或认为故障的影响在可接受的范围之内。
可靠的高可用性解决方案可以检测这类故障，自动从停机中恢复，然后重建容错功能。
在确定高可用性的SLA时，您应针对计划的维护活动和计划外停机时间分别计算关键性能指标（KPI）。
此方法使您可以将计划的维护活动方面的投资金额同这些活动避免计划外停机时间所减小的损失进行比较。
降级的可用性
高可用性不应该是一种非黑即白的硬性指标。
在出现故障的时候，最终用户通常可以接受系统是部分可用的，或具有有限的功能或降级的性能，而不是完全彻底的停机。
这些不同的可用性级别包括：
∙只读和延迟的操作。
在进行维护期间或在分阶段的灾难恢复期间，仍可以检索数据，但新的工作流和后台处理可能暂时停止或排队。
∙数据滞后和应用程序响应能力下降。
由于工作负荷繁重、处理工作积压或部分平台故障，
有限的硬件资源可能被过度使用或容量变小。
用户体验可能变差，但是工作仍然可以完成，只是效率降低了。
∙部分、暂时性或紧急故障。
取决于遇到错误时重试或自我更正的应用程序逻辑或硬件堆栈的可靠性。
这类错误可能以数据滞后或应用程序响应能力下降的形式显示给最终用户。
∙部分端到端故障。
计划内或计划外停机可能以温和的方式发生在解决方案堆栈的垂直层（基础结构、平台和应用程序）内，也可能以水平方式发生在不同功能组件之间。
根据受影响的功能或组件，用户可能会遇到任务部分成功或性能降级的情况。
应该在解决方案中考虑接受这些退而求其次的方案，将它们视为一种代替完全停机的次级可用性方案，也可以作为分阶段的灾难恢复过程的中间环节。
停机时间的量化
一旦发生停机事件，无论是计划内还是计划外，主要业务目标都是尽快使系统重新联机并尽量减少数据丢失。
每一分钟的停机时间都会产生直接和间接成本。
对于计划外的停机时间，您需要花时间和精力去确定停机发生的原因、当前的系统状态以及还原所需的步骤，但是必须精确把握这些工作所需的时间和工作量。
一旦某个停机事件达到某个预定的临界点，您应该做出或者寻求相应的业务决策，以便停止调查停机事件或者执行维护任务，使系统恢复联机状态，并且在需要时重建容错功能。
恢复目标
数据冗余是高可用性数据库解决方案的重要组成部分。
主SQLServer实例上的事务活动以同步或异步方式应用到一个或多个辅助实例。
发生停机时，正在进行中的事务可能回滚，或由于数据传播的延迟而在辅助实例上丢失。
您可以测量这种影响并设置相关的恢复目标：
业务恢复需要多长的时间，以及恢复的最后一个事务有多长时间的滞后。
∙恢复时间目标（RTO）。
这是指停机的持续时间。
初始目标是使系统重新联机，至少提供一个只读容量以便于调查故障。
但是，最终的目标是将整个服务还原到可以执行新事务的点。
∙恢复点目标（RPO）。
这通常指可接受的数据丢失的度量值。
它是故障前最后提交的数据事务与故障后恢复的最新数据之间的时间间隔或滞后值。
实际的数据丢失可能会有所不同，具体取决于发生故障时系统的工作负荷、故障类型和所使用的高可用性解决方案类型。
您应使用RTO和RPO值作为目标来指示业务容忍的停机时长和可接受的数据丢失量，并将它作为监视可用性状况的度量值。
确定合理的ROI或机会成本
停机时间的业务成本可能是金钱损失，也可能是企业信誉的损失。
这些成本可能随时间而累积，也可能在停机期间的某个点发生。
除了使用指定的恢复时间和数据恢复点来预测停机导致的成本之外，您还可以计算实现您的RTO和RPO目标或避免停机所需的业务流程和基础结构的投资总额。
这些投资的目的应包括：
∙避免停机时间。
如果从一开始没有发生停机，则可以完全避免停机恢复成本。
投资中包含容错和冗余硬件或基础结构的成本、将工作负荷分布到多个隔离的故障点的成本以及出于预防性维护目的而发生的计划停机的成本。
∙自动恢复。
如果发生系统故障，您可以通过自动透明的恢复机制大大减小停机时间对客户体验的影响。
∙资源利用。
辅助或备用基础结构可以闲置，直到发生停机。
它也可以用于处理只读工作负荷，或通过将工作负荷分布到所有可用硬件来提高总体系统性能。
对于指定的RTO和RPO目标，所需的可用性和恢复投资，以及预测的停机时间成本，可以表示为时间的函数。
在实际停机期间，这允许您根据停机时间长短来进行基于成本的决策。
监视可用性状况
从运行角度，在实际停机期间，您不应尝试实时考虑所有相关的变量和计算ROI或机会成本。
您应监视备用实例上的数据滞后时间，将其作为预期的RPO度量值。
发生停机时，您还应限制在停机期间调查停机原因所花的初始时间，而且应侧重验证恢复环境的运行状况，然后依赖详细的系统日志和数据的辅助副本以进行后续的法医式分析。
规划灾难恢复
高可用性工作是采取一些措施来防止停机发生，而灾难恢复工作则是在停机后采取一些措施来重建高可用性。
应该尽可能在实际发生停机前，制定完善的灾难恢复过程，并且明确各自的责任。
根据活动的监视和警报，是否要启动自动或手动故障转移和恢复计划的决策应该与预先确定的RTO和RPO阈值紧密关联。
合理的灾难恢复计划应包括：
∙故障和恢复的粒度。
根据故障的位置和类型，您可以在不同级别执行更正操作：
数据中心、基础结构、平台、应用程序或工作负荷。
∙可供调查的原始资料。
应准备好基线和最新的监视历史记录、系统警报、事件日志和诊断查询数据，以便有关方面的人士随时查阅。
∙协调依赖关系。
在应用程序堆栈内以及各个利益相关方之间，系统和业务具有怎样的依赖
关系？
∙决策树。
一个预先确定的、可重复操作并且经过验证的决策树应该包括角色责任、故障分类、以RPO和RTO目标表示的故障转移标准以及指定的恢复步骤。
∙验证。
在执行从停机中恢复的步骤之后，必须执行什么操作来验证系统已恢复到正常运行
状态？
∙文档。
用一系列文档记录上述信息，要足够详细并且条理清晰，以便第三方团队可以在尽量不借助外部帮助的情况下执行恢复计划。
此类文档通常称为“运行手册”或“操作指南”。
∙恢复演习。
定期演习灾难恢复计划以确定RTO目标的基准值，并考虑使主站点和每个灾难恢复站点定期轮流充当主生产站点。
概述：
使用MicrosoftSQLServer2012实现高可用性
实现所需的RPO和RTO目标涉及确保关键应用程序的连续运行，以及保护关键数据不受计划内和计划外停机的影响。
SQLServer提供了一系列功能可以帮助您实现这些目标，而且所需的成本和复杂性也不高。
非常熟悉新的AlwaysOn功能的读者可以直接阅读本文的SQLServerAlwaysOn保护层一节，以便更加深入地了解相关的功能。
SQLServerAlwaysOn
AlwaysOn是一种全新的集成式高可用性和灾难恢复解决方案，具有灵活性高、成本经济的特点。
它可以在数据中心内和数据中心间提供数据和硬件冗余，能够缩短应用程序故障转移的时间，从而提高关键任务应用程序的可用性。
AlwaysOn在配置方面极具灵活性，能够重复利用现有的硬件资产。
AlwaysOn解决方案可以利用两个主要的SQLServer2012功能在数据库级别和实例级别配置可用性：
∙AlwaysOn可用性组：
这是SQLServer2012中引入的新功能，它大大增强了数据库镜像的功能，帮助确保应用程序数据库的可用性；它采用基于日志的数据移动来提供数据保护，无需共享磁盘，可以实现零数据丢失。
可用性组提供一组集成的选项，包括逻辑数据库组的自动和手动故障转移，支持多达四个辅助副本，可以快速进行应用程序故障转移和自动页修复。
∙AlwaysOn故障转移群集实例（FCI）：
此功能增强了SQLServer故障转移群集功能并支持跨子网的多站点群集，可以跨数据中心对SQLServer实例进行故障转移。
同时，实例故障转移更快更可预测，从而加快了应用程序恢复。
显著减少计划的停机时间
在任何组织中，应用程序停机的主要原因是操作系统修补、硬件维护等活动导致的计划停机。
这几乎占IT环境中总停机时间的80%。
SQLServer2012通过减少修补要求和支持更多联机维护操作，可以帮助显著减少计划停机时间。
∙WindowsServerCore。
SQLServer2012支持在WindowsServerCore（WindowsServer2008和WindowsServer2008R2的最小简化部署选项）上进行部署。
此操作系统配置可以最大限度地减少操作系统修补要求（可减少60%），从而减少计划停机时间。
∙联机操作。
SQLServer2012增强了对联机操作（如LOB重建索引和添加具有默认值的列）的支持，这可以帮助减少数据库维护操作的停机时间。
∙滚动升级和修补。
AlwaysOn功能为实例的滚动升级和修补提供了便利，这对减少应用程序停机时间有很大帮助。
∙Hyper-V上的SQLServer。
在Hyper-V环境中托管的SQLServer实例还具有实时迁移的好处，它允许您不用停机即可在主机间迁移虚拟机。
管理员可以在主机上执行维护操作而不会影响应用程序。
消除闲置的硬件并提高成本效益和性能
典型的高可用性解决方案通常需要部署昂贵、冗余的被动服务器。
AlwaysOn可用性组使您可以将被动或空闲服务器上的辅助数据库副本用于只读工作负荷，如SQLServerReportingServices报表查询或备份操作。
同时利用主数据库副本和辅助数据库副本可以帮助提高所有工作负荷的性能，因为在您的服务器硬件资产中更均衡地分配了资源。
轻松部署和管理
诸如配置向导、WindowsPowerShell命令行界面支持、面板、动态管理视图（DMV）、基于策略的管理和SystemCenter集成等功能，可以帮助简化可用性组的部署和管理。
比较RPO和RTO能力
恢复点目标（RPO）和恢复时间目标（RTO）的业务目标应是为您的高可用性和灾难恢复解决方案选择SQLServer技术的重要推动因素。
下表粗略比较了这些不同解决方案可能得到的结果类型：
高可用性和灾难恢复
SQLServer解决方案
可能的数据丢失（RPO）
可能的恢复时间（RTO）
自动故障转移
可读辅助
副本
（1）
AlwaysOn可用性组－同步提交
零
几秒
是（4）
0-2
AlwaysOn可用性组－异步提交
几秒
几分钟
否
0-4
AlwaysOn故障转移群集实例
不适用（5）
几秒
到几分钟
是
不适用
数据库镜像
（2）－高安全性（同步+见证服务器）
零
几秒
是
不适用
数据库镜像
（2）－高性能（异步）
几秒（6）
几分钟（6）
否
不适用
日志传送
几分钟（6）
几分钟
到几小时（6）
否
在还原期间
不可用
备份、复制、还原（3）
几小时（6）
几小时
到几天（6）
否
在还原期间
不可用
（1）AlwaysOn可用性组最多可以有四个辅助副本，无论它们是何种类型。
（2）后续版本的MicrosoftSQLServer将删除该功能。
请改用AlwaysOn可用性组。
（3）备份、复制、还原适用于灾难恢复，但是不能提供高可用性。
（4）不支持从可用性组到故障转移群集实例或反向的自动故障转移。
（5）FCI本身并不提供数据保护；数据丢失取决于存储系统的实现形式。
（6）高度依赖于工作负荷、数据量和故障转移过程。
SQLServerAlwaysOn保护层
SQLServerAlwaysOn解决方案有助于在基础结构和应用程序组件的几个逻辑和物理层上提供容错和灾难恢复功能。
从过去经验来看，涉及的各个人员和角色具有不同的职责已成为共识，这样每个责任人只关注这些解决方案层的一部分。
本节的内容将对其中的每个层进行更深入的描述，并为设计方案讨论和实现形式决策提供基本的原理和指南。
成功的SQLServerAlwaysOn解决方案要求了解这些层并协调这些层的活动：
∙基础结构级别。
服务器级的容错和节点内部的网络通信都是利用WindowsServer故障转移群集（WSFC）功能来监视运行状况和协调故障转移。
∙SQLServer实例级别。
SQLServerAlwaysOn故障转移群集实例（FCI）是在WSFC群集中的几个服务器节点上安装并可以在其中进行故障转移的SQLServer实例。
承载FCI的节点都连接到可靠的对称共享存储设备（SAN或SMB）。
∙数据库级别。
可用性组是一组共同实现故障转移的用户数据库。
可用性组由一个主副本和一至四个辅助副本组成。
每个副本均由WSFC群集不同节点上的SQLServer（FCI或非FCI）实例托管。
∙客户端连接。
数据库客户端应用程序可以直接连接到SQLServer实例网络名称，也可以连接到与可用性组侦听器绑定的虚拟网络名称（VNN）。
VNN会提取WSFC群集和可用性组拓扑，以逻辑方式将连接请求重定向到相应的SQLServer实例和数据库副本。
下图中显示了一个典型的AlwaysOn解决方案的逻辑拓扑：
基础结构可用性
AlwaysOn可用性组和AlwaysOn故障转移群集实例都是利用WindowsServer操作系统和WSFC作为平台技术。
想要成为一名成功的MicrosoftSQLServer数据库管理员，您需要比以往更加透彻地了解这些技术。
Windows操作系统
SQLServer依赖Windows平台提供用于网络、存储、安全性、修补和监视活动的底层基础结构和服务。
SQLServer2012的各个版本之间以递增的方式逐渐增加功能和容量，这一点类似于WindowsServer2008R2操作系统的WindowsServer2008R2Standard版本、WindowsServer2008R2Enterprise版本和WindowsServer2008R2Datacenter版本。
有关详细信息，请参阅：
安装SQLServer2012的硬件和软件要求（
zh-cn/library/ms143506（SQL.110）.aspx）。
WindowsServerCore安装选项
作为一项重要的高可用性功能，SQLServer2012支持在WindowsServer2008或更高版本的ServerCore安装选项上进行部署。
ServerCore安装选项是服务器系统的最小环境，可以运行具有有限功能的服务器角色，并且只支持非常有限的GUI应用程序。
默认情况下，只启用必要的服务和命令提示符环境。
此操作模式减小了操作系统的受攻击面和系统开销，并且可以显著降低维护、服务和修补的要求。
在WindowsServerCore上部署SQLServer2012的一个重要注意事项是：
SQLServer和操作系统的所有部署、配置、管理和维护都必须使用脚本环境（如WindowsPowerShell）或通过使用命令行或远程工具来完成。
针对私有云优化SQLServer
高可用性和灾难恢复方案在私有云环境中日显重要。
将SQLServer部署到私有云可以帮助确保高效使用您的计算机、网络和存储资源，减小物理占用空间、投资金额和运行开支。
它将帮助您高效地合并部署、扩展资源，并在不影响控制的情况下按需部署资源。
除了对Hyper-V主机和客户操作系统的WindowsServer故障转移群集支持之外，SQLServer还支持实时迁移，即可以在主机之间移动虚拟机而感觉不到系统停机。
实时迁移还可以与客户群集一起使用。
有关详细信息，请参阅私有云计算-针对私有云优化SQLServer（
WindowsServer故障转移群集
WindowsServer故障转移群集（WSFC）提供了各种基础结构功能来支持所承载的服务器应用程序（如MicrosoftSQLServer）的高可用性和灾难恢复方案。
如果一个WSFC群集节点或服务失败，则该节点上承载的服务或资源可在一个称为“故障转移”的过程中自动或手动转移到另一个可用节点。
使用AlwaysOn解决方案，此过程可同时应用到FCI和可用性组。
WSFC群集中的节点协同工作，共同提供这些类型的功能：
∙分布式元数据和通知。
群集中的每个节点上维护着WSFC服务和承载的应用程序元数据。
除了承载的应用程序设置之外，此元数据还包括WSFC配置和状态。
对一个节点上的元数据或状态的更改会自动传播到群集中的其他节点。
∙资源管理。
群集中的各节点可能提供物理资源，如直接连接的存储（DAS）、网络接口和对共享磁盘存储的访问。
承载的应用程序（如SQLServer）将其本身注册为群集资源，并且可配置启动和运行状况对于其他资源的依赖关系。
∙运行状况监视。
节点间和主节点运行状况检测是通过结合使用信号样式的网络通信和资源监视来实现的。
群集的总体运行状况是由群集中节点仲裁的投票决定。
∙故障转移协调。
每个资源都配置为由主节点承载，并且每个资源均可自动或手动转移到一个或多个辅助节点。
基于运行状况的故障转移策略控制节点之间资源所有权的自动转移。
在发生故障转移时，节点和承载的应用程序会收到通知，以便其做出适当的响应。
有关详细信息，请参阅WindowsServer|故障转移群集和节点平衡（
注意：
数据库管理员了解WSFC群集和仲裁管理的内部工作机制现在变得极为重要。
AlwaysOn运行状况监视、管理和故障恢复步骤在本质上都与您的WSFC配置有关。
WSFC存储配置
WindowsServer故障转移群集依赖于群集中的每个节点来管理与其连接的存储设备、磁盘卷和文件系统。
WSFC假定存储子系统非常可靠，因此如果连接到某一节点的存储设备不可用，则认为该群集节点出现故障。
升级会员 