通过

规划可用性 (SharePoint Foundation 2010)

  • 项目

 

适用于： SharePoint Foundation 2010

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

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

当您仔细审阅自己的可用性需求时，请注意，可用性级别越高，保护的系统越多，您的可用性解决方案有可能就越复杂，成本也就越高。

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

本文内容：

  • 可用性概述

  • 选择可用性策略和级别

  • 配置为单个服务器场（“延伸式”服务器场）的位置相隔不远的数据中心之间的冗余和故障转移

可用性概述

可用性是指用户感受到 SharePoint Foundation 环境的可用程度。一个可用的系统是指有恢复能力的系统，即不会经常发生影响服务的意外事件，如果意外事件一旦发生，能够采取及时有效的措施加以解决。

可用性是业务连续性管理 (BCM) 的一部分，并且与备份、恢复以及灾难恢复相关。有关这些相关流程的详细信息，请参阅规划备份和恢复 (SharePoint Foundation 2010) 和规划灾难恢复 (SharePoint Foundation 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 Foundation 环境可用性的方法可供选择，包括：

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

  • 提高服务器场内服务器角色的冗余能力。

硬件组件容错能力

硬件组件容错能力是硬件组件和基础结构系统（比如服务器级别的电源）的冗余能力。规划硬件组件容错能力时，请考虑以下几点：

  • 服务器内每个组件完全冗余是不可能或不现实的。使用更多服务器来实现额外冗余。

  • 确保服务器有多个电源插头连接到不同的电源，以实现最大冗余。

在任何系统中，我们建议您与硬件供应商合作以获取适合系统的容错硬件，包括独立磁盘冗余阵列 (RAID) 阵列。

服务器场内的冗余

SharePoint Foundation 2010 支持在服务器场内的冗余计算机（即扩展）上运行服务器角色，以增加容量并提供基本可用性。

您要求的容量决定服务器数量以及服务器场中服务器的规格。满足基容量要求后，您可能想要增加更多的服务器来提高整体可用性。下图显示您如何为每个服务器角色提供冗余。

服务器场中的可用性

单个场可用性

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

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

前端 Web 服务器

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

应用程序服务器

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

数据库服务器

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

数据库可用性策略

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

SQL Server 故障转移群集

故障转移群集可以为 SQL Server 实例提供可用性支持。故障转移群集是一个或多个节点或服务器与两个或多个共享磁盘的组合。一个故障转移群集实例显示为一个计算机，但是在当前节点不可用的情况下，它具有提供从一个节点到另一个节点的故障转移功能。SharePoint Foundation 可以在 SQL Server 支持的群集中任何主动节点和被动节点的组合上运行。

SharePoint Foundation 将群集作为一个整体引用，因此，从 SharePoint Foundation 的角度看，故障转移是自动且无缝的。

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

SQL Server 高可用性镜像

数据库镜像是一种可以基于每个数据库来提供数据库冗余的 SQL Server 技术。在数据库镜像中，当主体数据库的事务日志缓冲区写入磁盘时，事务直接从主体数据库和服务器发送到镜像数据库和服务器。此技术可以使镜像数据库与主体数据库几乎保持同步更新。SQL Server Enterprise Edition 提供提高数据库镜像性能的更多功能。

若要在 SharePoint Foundation 服务器场中实现镜像，必须使用高可用性镜像，也称为带有自动故障转移的高安全性模式。高可用性数据库镜像有三个服务器实例：主体、镜像和见证。见证服务器使 SQL Server 可以自动从主体服务器故障转移到镜像服务器。从主体数据库故障转移到镜像数据库一般需要几秒钟。

与之前版本不同的是，SharePoint Foundation 是可感知镜像的。您在已配置了 SQL Server 的数据库镜像实例后，可以使用 SharePoint 管理中心或 Windows PowerShell cmdlet 来识别配置数据库、内容数据库或服务应用程序数据库的故障转移（镜像）数据库服务器位置。设置故障转移数据库位置会在连接字符串上增加一个参数，SharePoint Foundation 使用该参数连接到 SQL Server。如果出现了 SQL Server 超时事件，则会出现下列情况：

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

  2. SharePoint Foundation 自动尝试联系指定为故障转移数据库的服务器。

有关如何配置数据库镜像的信息，请参阅使用 SQL Server 数据库镜像配置可用性 (SharePoint Foundation 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 Foundation 2010 引用群集，从而使故障转移无缝且自动化。

数据库自动检测出故障；SharePoint Foundation 2010 可感知镜像位置，如果已进行了正确配置，将自动进行故障转移。

是否对发生故障的存储进行了保护？

对发生故障的存储不提供保护，因为存储是在群集中的节点中共享的。

对发生故障的存储提供保护，因为主体和镜像数据库服务器都写入本地磁盘。

支持的存储类型

共享存储（费用较高）。

可使用较便宜的直接附加存储 (DAS)。

位置要求

群集成员必须在同一子网。

主体、镜像和见证服务器必须在同一 LAN 上（最多 1 毫秒延迟往返）。

恢复模式

建议使用 SQL Server 完整恢复模式。您可以使用 SQL Server 简单恢复模式，但是如果群集丢失，唯一可用的恢复点将是上次的完整备份。

要求使用 SQL Server 完整恢复模式。

性能系统开销

发生故障转移时，可能会出现性能降低。

高可用性镜像可能会引起事务性延迟，因为它是同步的。它还要求更多的内存和处理器开销。

运行负担

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

运行负担大于群集。必须对所有数据库进行设置并维护。故障转移后需要手动重新配置。

服务应用程序冗余战略

您为保护服务器场中运行的服务应用程序而遵循的冗余战略会有所变化，具体取决于服务应用程序存储数据的位置。

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

为了保护在数据库中存储数据的服务应用程序，必须遵循下列步骤：

  1. 在环境中的多个应用程序服务器上安装服务以提供冗余。

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

下列服务应用程序在数据库中存储数据：

  • Business Data Connectivity Service 应用程序

  • Application Registry Service 应用程序

    我们建议您不要镜像 Application Registry 数据库，因为仅当将 Windows SharePoint Services 3.0 业务数据目录信息升级到 SharePoint Foundation 2010 时才使用它。

  • Usage and Health Data Collection Service 应用程序

    备注

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

  • Microsoft SharePoint Foundation 订阅设置服务

配置为单个服务器场（“延伸式”服务器场）的位置相隔不远的数据中心之间的冗余和故障转移

有些企业的数据中心位置相隔不远，有高带宽连接，因此可以配置为一个服务器场。这称为*“延伸式”服务器场*。若要使延伸式服务器场正常工作，SQL Server 和前端 Web 服务器之间在一个方向上必须有小于 1 毫秒的延迟，而且至少有每秒 1 GB 的带宽。

在此方案中，您可以按照使数据库和服务应用程序冗余的标准指导来提供容错能力。

下图展示了一个延伸式服务器场。

延伸式服务器场

“拉伸”场