规划灾难恢复 (SharePoint Server 2010)
适用于： SharePoint Foundation 2010, SharePoint Server 2010
上一次修改主题： 2016-11-30
本文介绍为 Microsoft SharePoint Server 2010 环境选择灾难恢复策略的关键决策。
本文内容：
灾难恢复概述
选择灾难恢复策略
针对冷备用的规划
针对暖备用的规划
针对热备用数据中心的规划
灾难恢复的系统要求
灾难恢复概述
在本文中，我们将灾难恢复定义为从承载 SharePoint Server 的数据中心变得不可用这一状况中恢复过来的能力。
您用于 SharePoint Server 的灾难恢复策略必须与相关基础结构（包括 Active Directory 域、Exchange Server 和 Microsoft SQL Server）的灾难恢复策略协调一致。您需要与您设计协调的灾难恢复策略和计划时所依赖的基础结构的管理员合作。
在另一个不同的位置启动并运行另一个服务器场所用时间和即时效果通常称为热备用、暖备用和冷备用。我们对这些术语的定义如下：
热备用 辅助数据中心，可以在数秒或数分钟内提供可用性。
暖备用辅助数据中心，可以在数分钟或数小时内提供可用性。
冷备用辅助数据中心，可以在数小时或数天内提供可用性。
对于系统来说，灾难恢复是成本较高的要求之一。故障和可用性之间的间隔越短，保护的系统越多，灾难恢复解决方案就可能会越复杂，成本越高。投资热备用数据中心或暖备用数据中心时，成本包括：
额外的硬件和软件，这经常会增加软件应用程序之间的操作复杂性，如编写自定义脚本以便进行故障转移和恢复。
额外的操作复杂性。
您应根据自己的业务需求，对维护热备用数据中心或暖备用数据中心的成本进行评估。并非组织内的所有解决方案都可能需要相同级别的灾难后可用性。您可以为不同的内容、服务或服务器场提供不同级别的灾难恢复，例如对您的业务有较大影响的内容、搜索服务或 Internet 发布服务器场。
灾难恢复是一个关键领域，信息技术 (IT) 小组需要在这一方面提供服务级别协议 (SLA) 来设定客户群的期望。许多 IT 组织都提供有各种分为不同收费等级的 SLA。
在服务器场之间实施故障转移时，建议首先部署并调整服务器场内的核心解决方案，然后实施并测试灾难恢复。
选择灾难恢复策略
您可以根据自己的业务需求从许多方法中进行选择，以便为 SharePoint Server 环境提供灾难恢复。以下示例演示公司为何选择冷备用、暖备用或热备用灾难恢复策略。
冷备用灾难恢复策略：公司定期将用于支持裸机恢复的备份运送到本地和地区非现场存储，并且拥有在另一个地区进行紧急服务器租赁的有效合同。
优点：
运营方面的维护成本往往最低。
恢复成本往往较高，因为它需要在灾难发生后正确配置物理服务器。
缺点：恢复速度最慢。
暖备用灾难恢复策略：企业定期将虚拟服务器映像发送至本地和区域灾难恢复场。
优点：恢复成本往往相对不高，因为在恢复时虚拟服务器场可能需要很少的配置。
缺点：维护成本可能非常高且耗时。
热备用灾难恢复策略：公司运行多个数据中心，但仅通过一个数据中心提供内容和服务。
优点：恢复速度往往相对较快。
缺点：配置和维护成本可能相当高。
重要
不管您决定为您的环境实施哪种灾难恢复解决方案，都有可能会丢失一些数据。
针对冷备用数据中心的规划
在冷备用灾难恢复方案中，您可以通过在新位置设置新服务器场（最好使用有脚本的部署）并还原备份来进行恢复。也可以通过从备份解决方案（如 Microsoft 系统中心数据保护管理器 2007）还原服务器场来进行恢复，该备份解决方案在计算机级别保护您的数据，并且使您可以单独还原每个服务器。本文不包含如何在冷备用方案中进行创建和恢复的详细说明。有关详细信息，请参阅：
针对暖备用数据中心的规划
在暖备用灾难恢复方案中，您可以通过确保以一致的方式经常创建服务器场内服务器的虚拟映像（这些映像会被运送到辅助位置）来创建暖备用解决方案。在辅助位置，您必须有一个环境，在该环境中，您可以轻松地配置和连接映像以重新创建服务器场环境。
本文不包含如何创建暖备用解决方案的详细说明。有关如何使用虚拟解决方案进行规划以部署服务器场的详细信息，请参阅规划虚拟化 (SharePoint Server 2010)。
针对热备用数据中心的规划
在热备用灾难恢复方案中，您可以设置故障转移服务器场，以在独立于主服务器场的数据中心中进行灾难恢复。具有单独故障转移服务器场的环境具有以下特征：
单独的配置数据库和管理中心内容数据库必须在故障转移服务器场中进行维护。
必须在两个服务器场中部署所有自定义项。
备注
建议通过有脚本的部署使用相同的配置设置和自定义项来创建主服务器场和故障转移服务器场。有关详细信息，请参阅使用 Windows PowerShell 安装 SharePoint Server 2010。
更新必须分别应用到两个服务器场中。
SharePoint Server 内容数据库可以成功地异步镜像或日志传送到故障转移服务器场。
备注
SQL Server 镜像只能用于将数据库复制到单个镜像服务器，但是您可以日志传送到多个辅助服务器。
服务应用程序因是否可以日志传送到服务器场而异。有关详细信息，请参阅本文后面的跨数据中心的服务应用程序冗余。
如果将 SQL Server 配置为日志传送到一个或多个其他数据中心，则可以跨许多数据中心重复此拓扑。
请咨询您的 SAN 供应商，以确定是否可以使用 SAN 复制或其他支持的机制跨数据中心提供可用性。
下图显示故障转移前的主服务器场和故障转移服务器场。
故障转移前的主服务器场和故障转移服务器场
.gif "故障转移前的主服务器场和故障转移服务器场")
跨数据中心的服务应用程序冗余
为了向服务应用程序提供跨数据中心的可用性，建议对可跨服务器场运行的服务，运行从主数据中心和辅助数据中心均可访问的单独的服务服务器场。
对于无法跨服务器场运行的服务，为了向服务服务器场本身提供可用性，为服务应用程序提供跨数据中心冗余的策略会有所不同。采用的策略取决于是否满足以下条件：
当灾难恢复场未在使用时，在其中运行服务应用程序具有商业价值。
可以日志传送或异步镜像与服务应用程序关联的数据库。
服务应用程序可以针对只读数据库运行。
以下各节介绍建议用于每个服务应用程序的灾难恢复策略。可以按策略对服务应用程序分组。
可以日志传送或异步镜像的数据库
在辅助服务器场中最初部署服务应用程序之后，支持以下服务应用程序的数据库可以跨服务器场异步镜像或日志传送：
Managed Metadata Service 应用程序
数据库：Managed Metadata Service
备注
如果使用标签，则若要成功地在灾难恢复场中使用 Managed Metadata Service 应用程序，您必须运行 SharePoint Administration Toolkit 中包含的用户配置文件复制引擎。有关详细信息，请参阅用户配置文件复制引擎概述 (SharePoint Server 2010)。
PerformancePoint Services
数据库：PerformancePoint Service 应用程序
Project Server Service 应用程序
数据库：草稿、已发布、存档和报告
Project Server 2010 需要其数据库之间保持同步。使用异步复制机制（异步数据库镜像、日志传送或异步 SAN 复制），即可在服务器场之间复制 Project Server，但若要进行恢复，必须确保在还原时 Project 数据库日志保持同步。
备注
虽然建议您将 Project Server 数据库日志传送或镜像到灾难恢复场，但是 Project Server Service 应用程序无法针对只读数据库运行。因此，建议您仅在故障转移之后，才在灾难恢复场上运行 Project Server Service 应用程序。若要在灾难恢复场中成功地使各个 Project Server 数据库同步，必须为这些数据库配置时间戳记或日志标记。
Secure Store Service 应用程序
数据库：安全存储
Usage and Health Data Collection Service 应用程序
数据库：日志记录
备注
可对日志记录数据库执行日志传送或镜像。但是，建议您不要在灾难恢复场中运行 Usage and Health Data Collection Service，并且不要对日志记录数据库执行镜像或日志传送。
Web Analytics Service 应用程序
数据库：临时、报告
备注
建议您日志传送或镜像 Web Analytics 临时数据库和报告数据库。但是，建议您仅在故障转移之后，在灾难恢复场中运行 Web Analytics Service 应用程序。
无法通过日志传送或异步镜像的服务应用程序和数据库
以下服务应用程序必须在主服务器场和故障转移服务器场上都进行部署，并且不能日志传送或异步镜像。对于这些服务应用程序中的大多数，建议您先部署它们，然后再验证故障转移服务器场是否与主服务器场具有相同的配置设置。如果影响服务的配置更改是在主服务器场上进行的，您必须更新故障转移服务器场。
Application Registry Service 应用程序
数据库：Application Registry Service
不支持日志传送 Application Registry Service 数据库。
Business Data Connectivity Service 应用程序
数据库：Business Data Connectivity
User Profile Service 应用程序
数据库：配置文件、同步、社会性标签
不能通过日志传送配置配置文件数据库、同步数据库和社会性标签数据库。
若要为 User Profile Service 应用程序提供冗余，必须首先在主数据中心和辅助数据中心中部署服务应用程序。
若要设置配置文件数据库和同步数据库，建议您将数据库的备份恢复到辅助数据中心，并将其附加到该数据中心中的 User Profile Service 应用程序。
若要保持配置文件同步，必须在主服务器场上完成配置文件数据的更新后，运行 SharePoint Administration Toolkit 中附带的用户配置文件复制引擎。有关详细信息，请参阅 用户配置文件复制引擎概述 (SharePoint Server 2010)。
Microsoft SharePoint Foundation Subscription Settings Service 应用程序
数据库：订阅
备注
不支持日志传送订阅设置数据库。
Access Services
数据库：无
Excel Services
数据库：无
Search
数据库：爬网、属性、搜索管理
Search 需要其数据库和索引之间完全同步。由于此要求，无法使用异步复制机制（异步数据库镜像、日志传送或异步 SAN 复制）在服务器场之间复制 Search。
若要在故障转移服务器场上提供最新 Search，必须在辅助服务器场上运行 Search。
重要
故障转移服务器场上的 Search Service 应用程序必须设置为主动对辅助服务器场进行爬网。故障转移时，必须配置 Web 应用程序关联，以使用故障转移 Search Service 应用程序。
State Service
数据库：状态
备注
不支持日志传送状态数据库。
Visio Services
数据库：无
Word Automation Services
数据库：Word Automation Services
不支持日志传送 Word Automation Services 数据库。
灾难恢复的系统要求
在理想方案中，故障转移组件和系统与主组件和系统在所有方面都匹配：平台、硬件和服务器数量。故障转移环境必须至少能够处理故障转移期间的预期流量。请记住，故障转移站点只能为一部分用户提供服务。系统必须至少在以下方面符合要求：
操作系统版本和所有更新
SQL Server 版本和所有更新
SharePoint 2010 产品版本和所有更新
虽然本文主要讨论 SharePoint 2010 产品的可用性，但是系统中的其他组件也会对系统运行时间产生影响。具体而言，请确保执行以下操作：
确保基础架构依赖项（如电源、冷却、网络、目录和 SMTP）处于完全冗余状态。
根据您的需求选择一种切换机制（DNS 或硬件负载平衡）。