规划可用性 (SharePoint Server 2010)

 

适用于: SharePoint Foundation 2010, SharePoint Server 2010

上一次修改主题: 2016-11-30

本文介绍为 Microsoft SharePoint Server 2010 环境选择可用性策略的关键决策。

如果您仔细阅读可用性要求,便会注意到可用性的级别越高,保护的系统就越多,可用性解决方案可能就会越复杂、越昂贵。

并非组织中的所有解决方案都可能需要相同级别的可用性。您可以为不同的网站、服务或服务器场提供不同级别的可用性。

本文内容:

  • 可用性概述

  • 选择可用性策略和级别

  • 位置相近且配置为单个服务器场(“延伸式”服务器场)的数据中心之间的冗余和故障转移

可用性概述

可用性是指用户检测到 SharePoint Server 环境的可用程度。可用系统是一种可迅速恢复的系统,即很少发生影响服务的事件,并且在发生这些事件时,能够及时有效地采取应对措施。

可用性是业务连续性管理 (BCM) 的一部分,与备份和恢复及灾难恢复有关。有关这些相关流程的详细信息,请参阅在 SharePoint Server 2010 中规划备份和恢复规划灾难恢复 (SharePoint Server 2010)

备注

在计算可用性时,大多数组织都会专门取消或增加计划内维护活动的小时数。

衡量可用性的最常见方法之一是使用运行时间百分比,即表示为若干个九,即给定系统处于活动且运行状态的时间百分比。例如,运行时间百分比为 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

可用性成本

对于一个系统,可用性是成本较高的要求之一。可用性的级别越高,保护的系统就越多,可用性解决方案就会越复杂、越昂贵。在进行可用性投资时,成本包括以下几个方面:

  • 会增加软件应用程序和设置之间交互复杂性的其他硬件和软件。

  • 其他操作复杂性。

应结合业务需求对提高可用性的成本进行评估,并非组织中的所有解决方案都可能需要相同级别的可用性。您可以为不同的网站、服务或服务器场提供不同级别的可用性。

可用性是信息技术 (IT) 小组提供服务级别协议 (SLA) 来设定客户群预期的一个重要方面。许多 IT 组织都提供各种与不同收费级别相关联的 SLA。

确定可用性要求

若要评估贵组织允许网站、服务或服务器场停机的时间限制,请回答以下问题:

  • 如果网站、服务或服务器场不可用时,员工是否无法履行其预期的工作职责?

  • 如果网站、服务或服务器场不可用时,是否会终止业务和客户事务,从而导致业务和客户流失?

对上述任何一个问题,如果回答“是”,则应投资可用性解决方案。

选择可用性策略和级别

您可以在许多方法中进行选择以提高 SharePoint Server 环境中的可用性,其中包括以下方法:

  • 提高服务器硬件组件的容错能力。

  • 提高服务器场中的服务器角色的冗余度。

硬件组件的容错能力

硬件组件容错能力是硬件组件和基础结构系统(例如服务器级别的电源)的冗余度。规划硬件组件容错能力时,请考虑以下因素:

  • 确保服务器中的每个组件具有冗余也许是不可能或不切实际的。您可以使用更多服务器来实现更多的冗余。

  • 确保服务器有多个电源设备与不同的电源相连,以实现最大冗余。

在任何系统中,我们均建议您向硬件供应商咨询以获得适合该系统的容错硬件,包括独立磁盘冗余阵列 (RAID)。有关建议,请参阅性能和容量管理 (SharePoint Server 2010)存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)

服务器场中的冗余

SharePoint Server 2010 支持在服务器场内的冗余计算机中运行服务器角色(即向外扩展)以增加容量并提供基本的可用性。

所需的容量决定服务器场中的服务器数量和服务器大小。在达到基容量要求后,可能需要添加更多的服务器来提高总体可用性。下图说明如何为每个服务器角色提供冗余。

服务器场中的可用性

单个场可用性

下表介绍 SharePoint Server 2010 环境中的服务器角色以及可用于服务器场中每台服务器的冗余策略。

服务器角色 服务器场中的首选冗余策略

前端 Web 服务器

在服务器场中部署多台前端 Web 服务器,并使用网络负载平衡 (NLB)。

应用程序服务器

在服务器场中部署多台应用程序服务器。

数据库服务器

使用群集或高可用性的数据库镜像部署数据库服务器。

数据库可用性策略

您可使用 Microsoft SQL Server 故障转移群集或 SQL Server 高可用性的数据库镜像来支持 SharePoint Server 环境中数据库的可用性。

SQL Server 故障转移群集

故障转移群集可为 SQL Server 实例提供可用性支持。故障转移群集是一个或多个节点或服务器与两个或多个共享磁盘的组合。故障转移群集实例显示为一台计算机,但可以提供从一个节点到另一个节点的故障转移功能(如果当前节点变为不可用)。SharePoint Server 可运行在 SQL Server 支持的群集中的任意组合的主动和被动节点上。

SharePoint Server 将群集作为整体引用;因此从 SharePoint Server 角度看,故障转移是自动且无缝实施的。

有关故障转移群集的详细信息,请参阅 SQL Server 2008 故障转移群集入门 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x804) 和使用 SQL Server 群集配置可用性 (SharePoint Server 2010)

SQL Server 高可用性镜像

数据库镜像是一种 SQL Server 技术,可根据每个数据库提供数据库冗余。在数据库镜像中,当主体数据库的事务日志缓存写入磁盘时,事务将直接从主体数据库和服务器发送到镜像数据库和服务器。此技术可使镜像数据库与主体数据库基本保持一致。SQL Server Enterprise Edition 提供了更多提高数据库镜像性能的功能。有关详细信息,请参阅 SQL Server 2008 R2 和 SharePoint 2010 产品:关联后功能更强大(白皮书)(SharePoint Server 2010)

若要在 SharePoint Server 服务器场中进行镜像,必须使用高可用性的镜像,又称为具有自动故障转移能力的高安全模式。高可用性数据库镜像涉及三个服务器实例:主体、镜像和见证。见证服务器使 SQL Server 能够自动从主体服务器故障转移到镜像服务器。从主体数据库到镜像数据库的故障转移通常需要几秒钟时间。

与之前的版本相比,其中一个变化是 SharePoint Server 具有镜像感知能力。配置 SQL Server 的数据库镜像实例后,便可使用 SharePoint 管理中心或 Windows PowerShell cmdlet 确定配置数据库、内容数据库或服务应用程序数据库的故障转移(镜像)数据库服务器位置。设置故障转移数据库位置将在连接字符串中添加一个参数,SharePoint Server 使用该字符串连接到 SQL Server。如果 SQL Server 出现超时,则会发生以下情况:

  1. 为 SQL Server 镜像配置的见证服务器会自动交换主体和镜像数据库的角色。

  2. SharePoint Server 自动尝试与指定为故障转移数据库的服务器通信。

有关如何配置数据库镜像的信息,请参阅使用 SQL Server 数据库映射配置可用性 (SharePoint Server 2010)

有关数据库镜像的常规信息,请参阅数据库镜像 (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x804)。

备注

无法镜像已配置为使用 SQL Server FILESTREAM 远程 BLOB 存储提供程序的数据库。

单个服务器场的数据库可用性策略的比较:SQL Server 故障转移群集与 SQL Server 高可用性镜像

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

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

故障转移时间

群集成员在故障时立即接管。

镜像在故障时立即接管。

事务一致性?

事务并发性?

恢复时间

恢复时间较短(毫秒)

恢复时间较长(毫秒)。

故障转移所需步骤?

数据库节点自动检测到故障;SharePoint Server 2010 引用群集,以使故障转移无缝自动进行。

数据库自动检测到故障;SharePoint Server 2010 能够感知镜像的位置(如果配置正确),以使故障转移自动进行。

防范存储失败?

不能防范存储失败,因为群集中的节点之间共享存储。

可以防范存储失败,因为主体和镜像数据库服务器均会向本地磁盘写入数据。

支持的存储类型

共享存储(成本较高)。

可使用成本较低的直接附加存储 (DAS)。

位置要求

群集的成员必须位于同一子网上。

主体、镜像和见证服务器必须位于同一 LAN 上(来回最多 1 毫秒延迟)。

恢复模式

推荐使用 SQL Server 完全恢复模式。您可以使用 SQL Server 简单恢复模式,但是如果群集丢失,则只有可用恢复点将包含上次完整备份。有关详细信息,请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)Plan for SQL Server, storage and BLOB configuration (SharePoint Foundation 2010)

要求 SQL Server 完全恢复模式。

性能开销

发生故障转移时,性能可能会稍有降低。

因为高可用性镜像是同步的,所以它会带来事务延迟。同时还需要更多的内存和处理器开销。

操作负担

在服务器级别设置和维护。

操作负担比群集大。必须针对所有数据库进行设置和维护。故障转移后,需要手动进行重新配置。

服务应用程序冗余策略

用来保护在服务器场中运行的服务应用程序的冗余策略会有所不同,具体取决于服务应用程序存储数据的位置。

在数据库外存储数据的服务应用程序

若要保护在数据库外存储数据的服务应用程序,请在多台应用程序服务器中安装服务应用程序以在该环境中提供冗余。

对于此版本的 SharePoint Server,在多台应用程序服务器中安装服务应用程序时,计时器作业将在所有运行服务实例(与该服务应用程序相关)的应用程序服务器上运行,或在第一台可用的服务器上运行。如果一台应用程序服务器出现故障,则下一个计时器作业计划运行时,在该服务器中运行的计时器作业将在另一台服务器上重新启动。

在多台应用程序服务器中安装服务应用程序会使服务应用程序持续运行,但不能保证数据不丢失。如果应用程序服务器出现故障,该应用程序服务器的活动连接将会丢失,用户会丢失一些数据。

以下服务应用程序会在数据库外存储数据:

  • Access Services

  • Excel Services 应用程序

在数据库中存储数据的服务应用程序

若要帮助保护在数据库中存储数据的服务应用程序,必须执行以下步骤:

  1. 在多台应用程序服务器中安装服务以在该环境内提供冗余。

  2. 配置 SQL Server 群集或镜像以保护数据。

以下服务应用程序在数据库中存储数据:

  • Search Service 应用程序,包括以下数据库:

    • 搜索管理

    • 爬网

    • 属性

      备注

      支持镜像搜索数据库,但为搜索提供冗余需要执行其他工作。有关详细信息,请参阅服务器场中的搜索冗余策略一节。

  • User Profile Service,包括以下数据库:

    • 配置文件

    • 社会性

    • 同步

      备注

      不支持镜像同步数据库。

  • Business Data Connectivity Service应用程序

  • Application Registry Service 应用程序

    不建议镜像应用程序注册表数据库,因为仅在将 Microsoft Office SharePoint Server 2007 业务数据目录信息升级到 SharePoint Server 2010 时才使用它。

  • Usage and Health Data Collection Service 应用程序

    备注

    建议不要镜像 Usage and Health Data Collection Service 应用程序日志记录数据库。

  • Managed Metadata Service 应用程序

  • Secure Store Service 应用程序

  • State Service 应用程序

  • Web Analytics Service 应用程序,包括以下数据库:

    • 报告

    • 临时

      备注

      不支持镜像临时数据库。

  • Word Automation Services 服务应用程序

  • Microsoft SharePoint Foundation 订阅设置服务

  • PerformancePoint Services

服务器场中的搜索冗余策略

仅服务器

Search Service 应用程序是服务器场中冗余的特例。下图说明如何为媒体专用的 Search Service 应用程序(对大约 4 千万个项目进行爬网)配置冗余和故障转移。有关 Search Service 应用程序体系结构的详细信息,请参阅技术图表 (SharePoint Server 2010) 一文中的“Microsoft SharePoint Server 2010 的搜索体系结构”。

冗余 Search Service 应用程序

高可用性搜索体系结构

  • 查询服务器。查询服务器承载查询组件和索引分区。

    • 查询组件 会返回搜索结果。每个查询组件均属于索引分区的一部分,与特定的属性数据库相关联,该数据库包含与一组特定已爬网内容相关的元数据。可通过将“镜像”查询组件添加到索引分区并将其放到不同的场服务器中使索引分区变为冗余。

      备注

      使用镜像查询组件 一词是指相同文件副本,而非 SQL Server 数据库镜像。

    • 索引分区 由多个查询组件组成,每个查询组件都包含一部分全文索引并返回搜索结果。每个索引分区均与一个特定的属性数据库相关联,该数据库包含与一组特定的已爬网内容相关联的元数据。可以通过在服务器场中的服务器上创建查询组件来确定哪些服务器将处理查询。若要使多个场服务器中的查询处理达到负载平衡,请将查询组件添加到索引分区,然后将这些组件与要处理查询的服务器相关联。有关详细信息,请参阅添加或删除查询组件。您可通过将镜像查询组件添加到索引分区并将其放到不同的查询服务器中使索引分区变为冗余。

  • 爬网服务器。爬网服务器承载爬网组件和搜索管理组件。

    • 爬网组件 会处理内容源的爬网,将生成的索引文件传播到查询组件,并将有关内容源的位置和爬网计划的信息添加到其关联的爬网数据库中。爬网组件与单个 Search Service 应用程序相关联。您可以通过将爬网组件添加到不同的爬网服务器中来分布爬网负载。在资源允许的情况下,可在给定爬网服务器中包含尽可能多的爬网组件。如果有很多内容位置,可添加爬网组件和爬网数据库并将其提供给特定内容。给定爬网服务器中的每个爬网组件应与单独爬网数据库相关联。关于冗余,我们建议至少有两个爬网组件。每个爬网组件均应设置为对两个爬网数据库进行爬网。如果数据库内容增长到 2500 万个项目以上,我们建议您添加新的爬网数据库和爬网组件。

    • 搜索管理组件 监控传入的用户操作并更新搜索管理数据库。每个 Search Service 应用程序仅允许使用一个搜索管理组件。搜索管理组件可在任何服务器中运行,但更适于在爬网服务器或查询服务器中运行。

  • 数据库服务器。数据库服务器承载爬网数据库、属性数据库、搜索管理数据库和其他 SharePoint Server 2010 数据库。

    • 爬网数据库

      爬网数据库中包含有关内容源位置和爬网计划的数据,以及特定于特定 Search Service 应用程序的爬网操作的其他信息。可以通过将爬网数据库添加到运行 SQL Server 的各台计算机中来分布数据库负载。爬网数据库与爬网组件相关联,可以通过创建主机分布规则使爬网数据库专用于特定的主机。有关爬网组件的详细信息,请参阅添加或删除爬网组件。有关主机分布规则的详细信息,请参阅添加或删除主机分布规则。如果爬网数据库镜像或部署到 SQL Server 故障转移群集,则这些数据库是冗余的。

    • 属性数据库

      属性数据库包含与已爬网内容关联的元数据。可以通过向运行 SQL Server 的各台计算机添加属性数据库来分布查询的数据库负载。属性数据库与索引分区关联,并在查询结果中返回任何与内容相关联的元数据。

      如果属性数据库镜像或部署到 SQL Server 故障转移群集,则这些数据库是冗余的。

    • 搜索管理数据库

      在服务器场中,每个 Search Service 应用程序实例仅有一个搜索管理数据库。

      如果搜索管理数据库镜像或部署到 SQL Server 故障转移群集,则该数据库是冗余的。

有关搜索冗余的详细信息,请参阅管理搜索拓扑

位置相近且配置为单个服务器场(“延伸式”服务器场)的数据中心之间的冗余和故障转移

有些企业拥有高带宽连接且位置相近的数据中心,这样数据中心可配置为单个服务器场。称作*“延伸式”服务器场*。要使延伸式服务器场正常工作,则在同一方向上,SQL Server 和前端 Web 服务器之间的延迟必须少于 1 毫秒,且带宽至少为每秒 1 GB。

在此情形中,您可以执行标准指南使数据库和服务应用程序产生冗余来提供容错能力。

下图演示了延伸式服务器场。

延伸式服务器场

“拉伸”场