规划可用性 (Office SharePoint Server)

  • 项目

本文介绍可用性的一般概念、SharePoint 产品和技术环境中可用性的成本和问题，以及您可在该环境中使用的策略和解决方案。如果您的服务器场运行的是 Microsoft Office SharePoint Server 2007，您应阅读本白皮书。您可能需要下载并打印本文随附的 Office SharePoint Server 2007 可用性模型（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x804)。它以海报形式显示了本文内容的摘要。

可用性概述

可用性是指用户所感觉到的 SharePoint 产品和技术环境的可用程度。确保可用性就是确保系统具有良好的恢复能力 — 也就是说，确保影响服务的事件不经常发生，并在这些事件发生时能够采取及时有效的措施。可用性策略可最大程度地缩短用户感觉到的计划内和计划外故障时间。

最常见的可用性度量标准之一是正常运行时间百分比（表示为九的个数）— 也就是说，给定系统处于活动和工作状态的时间所占的百分比。例如，正常运行时间所占百分比为 99.999 的系统的可用性为五个九。

下表列出了九的个数与关联的日历时间等效值。

可接受的正常运行时间百分比 每日故障时间 每月故障时间 每年故障时间

95

72.00 分钟

36 小时

18.26 天

99

14.40 分钟

7 小时

3.65 天

99.9

86.40 秒

43 分钟

8.77 小时

99.99

8.64 秒

4 分钟

52.60 分钟

99.999

0.86 秒

26 秒

5.26 分钟

如果能够对可能发生的总故障时间小时数作出有根据的推测，您可以使用以下公式来计算一年、一个月或一周的正常运行时间百分比：

每年运行时间百分比 = 100 –（8760 – 每年故障时间总小时数）/8760

每月运行时间百分比 = 100 –（24 * 当月天数– 该日历月中故障时间总小时数）/（24 * 当月天数）

每周运行时间百分比 = 100 –（168 – 该周故障时间总小时数）/168

可用性不是什么

可用性不是数据保护和恢复，也不是灾难恢复，尽管这些概念和可用性相关，并且在任何高度可用的系统中都应有数据保护和灾难恢复计划。保护和恢复数据是构成以下特定业务需求基础的一般业务需求：

  • 保留且能够查看项或网站的多个版本。

  • 恢复意外删除的项或网站。

  • 基于法律、监管或业务方面的原因对数据进行存档。

  • 在发生意外硬件或软件故障时还原系统。

此外，可用性也不是业务持续管理 (BCM)。BCM 由您预先准备好用于处理危机的业务决策、过程和工具组成。危机可能是本地、地区或国家事件，或者可能只与您的业务相关。

SharePoint 产品和技术可用性以及数据保护管理策略可能是您的技术 BCM 计划的一部分，但您的总体 BCM 计划应更加全面，其中包括以下元素：

  • 清晰记录的过程。

  • 关键业务记录的非现场存储。

  • 明确指派的联系人。

  • 持续的员工培训。

  • 非现场恢复机制。

可用性的成本

可用性是系统成本较高的要求之一。可用性级别越高以及保护的系统越多，可用性解决方案的复杂程度和成本可能就越高。当您在可用性方面投资时，成本包括：

  • 额外的硬件和软件，通常涉及软件之间的复杂操作，例如用于故障转移和恢复的自定义脚本。

  • 额外的操作复杂性。

应基于您的业务需求对实现可用性的成本进行评估 — 并非组织内的所有解决方案都可能需要相同级别的可用性。您可以为不同的网站、不同的服务（例如，搜索和商业智能）或不同的服务器场提供不同级别的可用性。

可用性是一个重要领域，信息技术 (IT) 团队在该领域提供服务级别协议 (SLA) 来与客户群设定服务期望。许多 IT 组织都提供各种 SLA，这些 SLA 需要根据不同的费用级别付费。

备注

在计算可用性时，大多数组织都会根据具体情况去除或增加计划内维护活动所用的小时数。

SharePoint 产品和技术中的可用性难题

SharePoint 产品和技术部署会导致在提供可用性时出现以下难题：

  • 在应用修补程序或升级服务器场时，服务器场不可用。

  • 无法通过在多台服务器上安装索引角色来实现索引服务器冗余。为了防止索引服务器丢失，您将需要重新安装服务器，并且从备份进行还原，或者当搜索对内容重新爬网时依赖于稍微陈旧的结果。或者，您可以使用服务器场中的搜索可用性和服务器场之间的搜索可用性节中介绍的方法之一来缩短恢复搜索所花费的时间。

  • SharePoint 产品和技术无法识别 Microsoft SQL Server 2005 数据库镜像。尽管我们建议您考虑使用 SQL Server 镜像作为 SharePoint 的可用性技术，但这样做需要额外的自动控制。

何时考虑可用性

我们建议您在进行 SharePoint 解决方案的核心设计时考虑可用性要求。您也可以在部署解决方案后提供增强的可用性。在操作上，我们建议您在服务器场内部署和调整核心解决方案，然后测试可用性解决方案。

确定可用性要求

为了评估组织对网站、服务或服务器场故障时间的容忍程度，请回答有关网站、服务或服务器场的以下问题。

  • 如果网站、服务或服务器场变为不可用，组织的员工是否将无法履行他们预期的工作职责？

  • 如果网站、服务或服务器场变为不可用，业务和客户事务是否会中断，从而导致失去业务和客户？

如果对以上任意问题的回答都是“是”，则您应在可用性解决方案上投资。

选择可用性策略

您可以选择许多不同的方法来增强可用性，这些方法包括：

  • 组件的容错。

  • 服务器场内服务器角色与数据库之间的冗余和故障转移。

  • 服务器场之间的冗余和故障转移。

可用性的系统要求

在理想方案中，故障转移组件和系统在以下所有方面都与主要组件和系统匹配：平台、硬件和服务器数量。故障转移环境必须至少能够处理故障转移期间的预期流量。请记住，故障转移网站只能为少量用户提供服务。这些系统必须至少在以下方面相匹配：

  • 操作系统版本和所有更新

  • SQL Server 版本和所有更新

  • SharePoint 产品和技术的版本和所有更新

尽管本文主要介绍 SharePoint 产品和技术的可用性，但系统正常运行时间将还会受到系统中其他组件的影响。特别是，请考虑以下事项：

服务器场中的可用性

若要支持服务器场中的可用性，应计划安装容错组件、冗余服务器角色以及对数据库可用性的支持，无论是采用群集还是数据库镜像，或同时采用这两者。

组件容错

在任何系统中，我们建议您与硬件供应商合作以采购适合于系统的容错硬件，其中包括独立磁盘冗余阵列 (RAID) 阵列。有关建议，请参阅性能和容量规划 (Office SharePoint Server)。

在规划组件容错时，请考虑以下事项：

  • 为服务器内的每个组件建立完整冗余可能无法实现或不切实际。请使用额外的服务器来实现额外的冗余。

  • 考虑为索引服务器角色使用组件冗余，因为无法建立索引服务器角色的冗余。

  • 确保服务器有连接到不同电源的多个供电系统，以实现最大程度的冗余。

服务器场内服务器角色之间的冗余和故障转移

SharePoint 产品和技术支持在服务器场内的冗余计算机上运行服务器角色（即向外扩展），以提高容量和改善性能，并提供基本可用性。容量和性能决定服务器的数量和服务器场内服务器的规模。满足了基本要求后，您可以添加更多服务器以提高服务的整体可用性。

单服务器场中的冗余

单个场可用性

下表介绍 SharePoint 管理中心网站“服务器上的服务”页上列出的 SharePoint 产品和技术环境中的服务器角色和服务，以及可用于服务器场内每台服务器的基本冗余策略。

服务器上的服务 服务器场内的首选基本冗余策略

Web 服务器

部署到多台服务器，并通过使用软件或硬件负载平衡来实现负载平衡。

中型服务器场的 Web 服务器（Web 应用程序和搜索查询服务）

部署到多台服务器。

搜索索引

无法部署到多台服务器并实现冗余。您必须使用其他可用性策略。有关详细信息，请参阅服务器场中的搜索可用性。

Excel 计算

部署到多台服务器。

Project 应用程序

部署到多台服务器。

有关详细信息，请参阅规划冗余 (Office SharePoint Server)。

单个服务器场的数据库可用性策略

可以使用 SQL Server 群集或 SQL Server 高可用性镜像（也称为同步镜像）提供服务器场中的数据库可用性。

群集：故障转移群集提供对 SQL Server 的整个实例的可用性支持。故障转移群集是一个或多个节点或服务器（具有两个或多个共享磁盘）的组合。故障转移群集实例显示为一台计算机，但如果当前节点变得不可用，则可以提供从一个节点故障转移到另一个节点的功能。

Office SharePoint Server 2007 作为一个整体引用群集，因此从 SharePoint 产品和技术的角度来看，故障转移是自动和无缝的。

同步数据库镜像：数据库镜像通过在每次将主体数据库的事务日志缓冲写入磁盘时，都直接将事务从主体数据库和服务器发送到镜像数据库和服务器，从而提供可用性支持。建议您使用高可用性数据库镜像，也称为带自动故障转移的高安全模式。高可用性数据库镜像涉及三个服务器实例：主体、镜像和见证服务器。见证服务器使 SQL Server 能够自动从主体服务器故障转移到镜像服务器。从主体数据库故障转移到镜像数据库通常需要几秒钟的时间。

每种技术都各有利弊。群集较容易实现，但成本较高。Microsoft Office Project Server 2007 数据库不支持 SQL Server 镜像。

下表比较了故障转移群集与 SQL Server 高可用性镜像。

SQL Server 故障转移群集 SQL Server 高可用性镜像

发生故障时镜像立即接管。

发生故障时镜像立即接管。

在事务上保持一致。

在事务上保持一致。

在事务上保持并发。

在事务上保持并发。

恢复时间最短（数秒到数分钟）。

恢复时间稍长（数秒到数分钟）。

数据库节点自动检测故障；SharePoint 产品和技术引用群集，因此，从 SharePoint 产品和技术的角度来看，故障转移是无缝并且自动进行的。

需要脚本来实现 SharePoint 产品和技术故障转移。

不保护失败的存储，因为存储是在群集中的节点之间共享的。

保护失败的存储，因为主体数据库服务器和镜像数据库服务器都写入本地磁盘。

需要成本较高的共享存储。

可以使用成本不太高的直接附加存储 (DAS)。

同一子网。

SQL Server 和 Web 服务器之间的延迟最多 1 毫秒 (ms)。

可使用 SQL Server 简单恢复模式，尽管群集丢失时的唯一可用恢复点是上次完整备份。

需要 SQL Server 完整恢复模式。

无性能开销。

引起事务性延迟。增加内存和处理器开销。

操作负荷最小。

存在额外的操作负荷，包括脚本处理和设置 SQL Server 别名。

有关如何使用群集的详细信息，请参阅通过使用 SQL Server 群集配置单个服务器场中的可用性。

有关如何使用同步镜像的详细信息，请参阅通过使用 SQL Server 数据库镜像配置单个服务器场中的可用性和使用数据库镜像 (Office SharePoint Server)（白皮书）。

配置为单一服务器场的密集数据中心（“延伸式”服务器场）之间的冗余和故障转移

某些企业的数据中心通过高带宽连接密集放置，因此可以将它们配置为单一服务器场。此服务器场称为“延伸式”服务器场。为使延伸式服务器场正常工作，SQL Server 和 Web 服务器之间的单向延迟必须小于 1 毫秒，并且必须有至少每秒 1 GB 的带宽。

  • 在此方案中，您可以通过使用同步镜像为 SharePoint 数据库提供冗余。在延伸式服务器场内，您可以对配置数据库和内容数据库进行镜像。有关一个公司如何使用延伸式服务器场的案例研究，请参阅使用数据库镜像对 SharePoint 进行高可用性的案例研究（白皮书）。

  • 请咨询您的 SAN 供应商，以确定您是否能使用 SAN 复制或另一种支持的机制来提供跨数据中心的可用性，例如运行于地理位置上分散的服务器群集上的 SQL Server。确保 SAN 复制解决方案可提供足够级别的并发性和事务一致性。

在延伸式服务器场内，您可以通过以下各项为运行 SSP 的应用程序服务器提供容错：

  • 多台查询服务器

  • 多台运行 Excel Calculation Services 的服务器

索引服务器是此方案内的单一故障点。您可以备份和还原搜索，或者，如果恢复时的搜索时效性非常重要，可使用故障转移 SSP 服务器场。有关详细信息，请参阅服务器场中的搜索可用性。

Project Server 是此方案内的另一个单一故障点。请计划备份和还原 Project Server 数据库。

“延伸式”服务器场

“拉伸”场

服务器场中的搜索可用性

服务器场中的索引服务器角色无法实现冗余。企业对故障转移后的搜索时效性的要求可决定解决方案的逻辑体系结构。

如果业务不要求故障转移后的即时搜索时效性和可用性，您可以将搜索 SSP 备份和还原到故障转移网站。

如果企业要求快速搜索时效性和可用性，则可以使用以下方法之一：

  • 包含两个相同 SSP 的单一服务器场体系结构。

    备注

    如果企业需要快速搜索并发性和可用性，并且您使用的是配置文件，则不会将故障转移 SSP 上的配置文件与主 SSP 上的配置文件同步，它们将处于最初导入时所处的状态。若要使所有 SSP 上的配置文件保持同步，您必须使用 32 位 SharePoint 管理工具包（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x804)（该链接可能指向英文页面） 或 64 位 SharePoint 管理工具包（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x804)（该链接可能指向英文页面） 中随附的用户配置文件复制引擎。有关详细信息，请参阅用户配置文件复制引擎 (Office SharePoint Server)。

  • 一个承载搜索和其他 SSP 的集中式父服务器场。位于中央服务器场的搜索服务对位于所有其他服务器场的内容进行爬网。可使用此体系结构来支持一个或多个服务器场。

包含两个 SSP 的单一服务器场

以下体系结构可防止索引服务器出现故障。在此拓扑结构中，两个 SSP 使用相同规则对相同内容进行爬网。除非发生故障转移，否则故障转移 SSP 不会附加到主网站。

包含两个共享服务提供程序的单一服务器场

带有 2 个 SSP 的场

这种拓扑结构有以下限制：

若干因素会对是否能够及时对大型数据集进行爬网产生影响，其中包括索引服务器和 Web 服务器之间的延迟和带宽。

在带宽有限的环境中，这种拓扑结构可能会大幅降低性能。对内容爬网两次会使所爬网的内容库产生额外的负荷，从而可能影响内容库性能。搜索保持索引最新的能力也可能会受到负面影响。

集中式 SSP 服务器场

在以下体系结构中，使用父 SSP 服务器场可以防止索引服务器出现故障。尽管这可能看起来像是一种硬件密集型解决方案，但是，只要索引服务器位于单独的服务器上，单独的 SSP 服务器场就可以共享某一硬件（例如群集数据库服务器或镜像数据库服务器）。有关如何规划和配置 SSP 服务器场的详细信息，请参阅规划 SSP 体系结构。

这种拓扑结构有以下好处：

  • SSP 管理是集中进行的。

  • 如果服务器场出现故障，则无需进行重新爬网。

集中式 SSP 服务器场

SSP 故障转移场

这种拓扑结构有以下限制：

具有多个服务器场的数据中心之间的冗余和故障转移

可以设置故障转移服务器场以在主服务器场之外的单独数据中心中提供可用性。具有单独故障转移服务器场的环境具有以下特征：

  • 必须在故障转移服务器场上维护单独的配置数据库和管理中心内容数据库。

    备注

    如果为主服务器场配置了备用访问映射，请务必在故障转移服务器场上以同样的方式配置该映射。

  • 所有自定义项都必须同时部署在两个服务器场上。

  • 必须将修补程序逐个应用于两个服务器场。

  • 只有内容数据库才能以异步方式成功地镜像或日志传送到故障转移服务器场。

  • 必须将镜像数据库或日志传送的数据库设置为使用完整恢复模式。

  • 可以将 SSP 数据库（包括 Office Project 2007 数据库）备份和还原到故障转移服务器场。

请咨询您的 SAN 供应商，以确定您是否能使用 SAN 复制或另一种支持的机制来提供跨数据中心的可用性。

如果您将 SQL Server 配置为日志传送到一个或多个其他数据中心，则可以跨多个数据中心重复此拓扑。

备注

SQL Server 镜像只能用于一台镜像服务器，但您可以日志传送到多台辅助服务器。

故障转移之前的主服务器场和故障转移服务器场

故障转移前的主服务器场和故障转移服务器场

下表列出了 SharePoint 产品和技术环境中的服务器角色和服务，以及可在服务器场之间使用的基本冗余策略。

服务器或服务器角色 服务器场之间的首选基本冗余策略

SQL Server

SQL Server 异步数据库镜像、SQL Server 日志传送或其他异步复制机制。

Note注意：
不能用于承载搜索信息的 SSP 数据库，也不能用于 Project Server 数据库。

前端 Web 服务器

同时部署在两个服务器场上（包括自定义项）。

中型服务器场的 Web 服务器（Web 应用程序和搜索查询服务）

同时部署在两个服务器场上。

搜索索引

同时部署在两个服务器场上。从原始服务器场恢复备份以移到故障转移服务器场。

Excel 计算

同时部署在两个服务器场上。如果 SSP 未承载搜索，则可以使用异步数据库镜像、SQL Server 日志传送或另一种异步复制机制以将数据移到故障转移服务器场。

如果 SSP 也承载搜索，则必须从原始服务器场恢复备份才能移动数据。

Project 应用程序

同时部署在两个服务器场上。从原始服务器场恢复备份以移到故障转移服务器场。

服务器场之间的搜索可用性

搜索要求搜索数据库、SSP 数据库和索引之间完全同步。由于有这样的要求，因此无法通过使用异步复制机制（异步数据库镜像、日志传送或异步 SAN 复制）在服务器场之间复制搜索。

备注

如果在不使用搜索或 Project 的情况下运行 SSP，您可以使用异步复制机制来转移数据。

若要在故障转移服务器场上提供搜索，您必须使用以下方法之一：

  • 将搜索 SSP 的备份恢复到故障转移服务器场。

  • 使用承载搜索和其他 SSP 的集中式父服务器场。位于中央服务器场的搜索服务对位于所有其他服务器场的内容进行爬网。

摘要

请仔细检查您的可用性要求。可用性级别越高以及保护的系统越多，可用性解决方案的复杂程度和成本可能就越高。

应基于业务需求对实现可用性的成本进行评估。并不是组织内的所有解决方案都可能需要相同级别的可用性。您可以为不同的网站、不同的服务（例如，搜索和商业智能）或不同的服务器场提供不同级别的可用性。

鸣谢

Microsoft Office SharePoint Server 内容发布团队谨向本白皮书的以下技术审阅人员致谢：

  • Microsoft 在线服务部门 Hosted SharePoint 技术架构师 Bill Baer

  • Microsoft 咨询服务部门高级顾问 James Petrosky

  • Microsoft 咨询服务部门 IW 高级架构师 Steve Peschka

  • Microsoft 客户支持服务部门专家级工程师 Dan Winter

  • Microsoft SharePoint 产品和技术部门程序经理 Sean Livingston

  • 技术架构师 Mike Watson

  • Microsoft Premier Field Engineering 首席高级现场工程师 Todd Carter

  • Microsoft Office Project Server 部门编写人员 Mike Plumley

  • Microsoft Office Project 部门高级技术产品经理 Christophe Fiessinger

  • Microsoft Search 部门程序经理 Sid Shah

  • Microsoft SharePoint 产品和技术部门程序经理 Luca Bandinelli

下载此书籍

本主题包含在以下可下载书籍内，以方便您阅读和打印：

另请参见

概念

配置高可用性 (Office SharePoint Server)