规划可用性 (Search Server 2008)

更新时间: 2009年3月

应用到: Microsoft Search Server 2008

 

上一次修改主题： 2015-03-09

本文介绍可用性的一般概念、SharePoint 产品和技术环境中可用性的成本和问题，以及您可在该环境中使用的策略和解决方案。如果您的服务器场运行 Microsoft Search Server 2008，您应阅读本白皮书。您可能需要下载并打印本文随附的 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。

SharePoint 产品和技术中可用性面临的挑战

SharePoint 产品和技术部署会面临以下可用性难题：

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

• 无法通过在多台服务器上安装索引角色来实现索引服务器冗余。为了避免索引服务器引起的损失，您需要重新安装服务器，并从备份还原服务器或者在搜索功能重新对内容进行爬网时依赖略有过时的结果。此外，还可以使用故障转移后的搜索可用性部分中介绍的某种方法来缩短恢复搜索功能所用的时间。

• SharePoint 产品和技术不支持 SQL Server 镜像。尽管我们建议您考虑将 SQL Server 镜像用作一种可用性方法，但这样做需要更多自动化操作。

何时考虑可用性

建议您将可用性要求视为 SharePoint 解决方案的核心设计的一部分。还可以在部署解决方案之后提供增强的可用性。为便于操作，建议您在服务器场中部署和调整核心解决方案，然后测试可用性解决方案。

确定可用性要求

若要评估组织对网站、服务或服务器场的故障时间的容限，请回答以下有关网站、服务或服务器场的问题。

• 如果网站、服务或服务器场不可用，组织的员工能否履行其预期工作职责？

• 如果网站、服务或服务器不可用，是否会中断业务和客户交易，从而导致业务和客户丢失？

如果对以上任一问题的回答是肯定的，则应投资于可用性解决方案。

选择可用性策略

可以从许多不同的方法中进行选择以增强可用性，具体包括：

• 组件的容错能力。

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

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

可用性的系统要求

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

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

• SQL Server 版本和所有更新

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

尽管本文主要讨论 SharePoint 产品和技术的可用性，但系统中的其他组件也会影响系统运行时间。尤其应考虑以下方面：

• 应确保基础架构依赖项（如电源、制冷、网络、目录和 SMTP）是完全冗余的。

• 为系统选择符合需要的转换机制（无论是 DNS 还是硬件负载平衡）。有关负载平衡 Web 服务器的最佳方案，请参阅以下文章：

  • 负载平衡的企业设计（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=122194&clcid=0x804)（该链接可能指向英文页面）

  • DNS 的企业设计（该链接可能指向英文页面）(https://go.microsoft.com/fwlink/?linkid=122196&clcid=0x804)（该链接可能指向英文页面）

组件的容错能力

在任何系统中，都建议您与硬件供应商合作，以获得适合该系统的容错硬件，包括独立磁盘冗余阵列 (RAID)。有关建议，请参阅性能和容量规划 (Windows SharePoint Services)。

规划组件的容错能力时，请考虑以下方面：

• 可能无法实现服务器中每个组件的完全冗余，这可能也是不现实的。此时可使用其他服务器来实现额外冗余。

• 考虑索引服务器角色的组件冗余，因为无法将索引服务器角色设置为冗余角色。

• 确保服务器有多个电源并且分别连接到不同的供电设备，以获得最大冗余。

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

SharePoint 产品和技术支持在服务器场中的冗余计算机上运行服务器角色（即向外扩展），以增大容量和提高性能并提供基本可用性。容量和性能决定着服务器场中服务器的数量和大小。满足基本要求后，可能需要添加更多服务器以提高服务的总体可用性。

由一台服务器组成的服务器场中的可用性

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

服务器上的服务	服务器场中的首选基本冗余策略
SQL Server	群集或同步镜像。群集较容易实现，但成本较高。 有关使用同步镜像的详细信息，请参阅使用数据库镜像 (Office SharePoint Server)（白皮书）。
Web 服务器	通过使用软件或硬件负载平衡部署到多台服务器并实现负载平衡。
中型服务器场的 Web 服务器（Web 应用程序和搜索查询服务）	部署到多台服务器。
搜索索引	无法部署到多台服务器，且无法实现冗余。必须使用其他可用性策略。有关详细信息，请参阅故障转移后的搜索可用性。
Excel 计算	部署到多台服务器。
Project 应用程序	部署到多台服务器。

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

单服务器场的数据库可用性策略比较：SQL Server 故障转移群集与 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 和 Web 服务器之间的单向延迟必须小于 1 毫秒，并且必须至少使用每秒 1 GB 的带宽。

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

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

在延伸式服务器场中，可以通过配置以下服务器为运行 SSP 的应用程序服务器提供容错能力：

• 多台查询服务器

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

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

“延伸式”服务器场

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

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

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

  提示

  如果已经为主服务器场配置了备用访问映射，则需要以同样的方式在故障转移服务器场上配置备用访问映射，这一点尤其重要。

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

• 必须分别为这两个服务器场应用修补程序。

• 只有内容数据库可异步成功镜像到故障转移服务器场或将日志传送到故障转移服务器场。

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

• SSP 数据库可备份和还原到故障转移服务器场。

若要确定是否可以使用 SAN 复制或其他支持的机制在数据中心提供可用性，请咨询您的 SAN 供应商。

如果要对 SQL Server 日志进行配置以传送到一个或多个其他数据中心，则可以在许多数据中心重复此拓扑结构。

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

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

服务器或服务器角色	服务器场之间的首选基本冗余策略
SQL Server	SQL Server 异步数据库镜像、SQL Server 日志传送或其他异步复制机制。 提示 不能用于承载搜索信息的 SSP 数据库。
前端 Web 服务器	在两个服务器场上部署，包括自定义设置。
中型服务器场的 Web 服务器（Web 应用程序和搜索查询服务）	在两个服务器场上部署。
搜索索引	在两个服务器场上部署。从原始服务器场恢复备份以转到故障转移服务器场。
Excel 计算	在两个服务器场上部署。如果 SSP 未承载搜索，则可以使用异步数据库镜像、SQL Server 日志传送或其他异步复制机制将数据移到故障转移服务器场。 如果 SSP 也承载搜索，则必须从原始服务器场恢复备份才能移动数据。
Project 应用程序	在两个服务器场上部署。从原始服务器场恢复备份以转到故障转移服务器场。

异步复制和搜索

搜索需要搜索数据库、SSP 数据库和索引之间完全同步。由于存在此项要求，无法使用异步复制机制（异步数据库镜像、日志传送或异步 SAN 复制）在服务器场之间复制搜索。若要在故障转移服务器场上提供搜索功能，必须恢复搜索 SSP。

故障转移后的搜索可用性

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

• 如果企业不需要在故障转移后立即恢复搜索时效性和可用性，则可以备份搜索 SSP 备份并将其还原到故障转移网站。

• 如果企业需要快速恢复搜索时效性和可用性，则可以使用以下服务器场之一：

• 具有两个相同的 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 附加到主网站。

具有两个共享服务提供程序的单服务器场

此拓扑结构具有以下限制：

• 在每台查询服务器上需要两倍的空间来存放索引

• 需要手动切换 Web 应用程序才能使用故障转移 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)。

及时对大型数据集进行爬网的能力受诸多因素的影响，其中包括索引服务器和 Web 服务器之间的延迟和带宽。

在具有有限带宽的环境中，此拓扑结构会显著降低性能。对内容进行两次爬网会增加爬网内容库的负担，从而影响库的性能。还可能对保持最新索引的搜索能力造成负面影响。

集中式 SSP 服务器场

在下面的体系结构中，使用父 SSP 服务器场可确保不发生索引服务器故障。尽管它可能是一个硬件密集型解决方案，但只要索引服务器位于单独的服务器上，单独的 SSP 服务器场就可共享某个硬件（如群集或镜像数据库服务器）。有关规划和配置 SSP 服务器场的详细信息，请参阅规划 SSP 体系结构。

此拓扑结构具有以下优点：

• 对 SSP 进行集中管理。

• 服务器场出现故障后不需要重新爬网。

集中式 SSP 服务器场

此拓扑结构具有以下限制：

• 通过广域网 (WAN) 对内容进行爬网需要占用带宽。

• 在具有大量数据且更改速率很快的环境中难以保持索引最新。

• WAN 链接的性能可能会影响查询性能。

• 默认情况下，如果启用了配置文件，则不会将故障转移 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)。

摘要

仔细查看可用性要求。可用性级别越高，要保护的系统越多，可用性解决方案的复杂性和成本可能也就越高。

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

致谢

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 高级现场工程部门首席高级现场工程师 Todd Carter

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

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

• Microsoft Search 部门项目经理 Sid Shah

• Microsoft SharePoint 产品和技术部门项目经理 Luca Bandinelli