为 SharePoint Server 创建具有高可用性的体系结构和策略

适用于：2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

高可用性策略是生产 SharePoint Server 环境的重要要求。 端到端策略包括操作过程、平台管理、体系结构和技术解决方案。 本文重点介绍高可用性的体系结构和技术方面。 该指南阐述了特定 SharePoint 设计元素和技术选项，它们可以确定您的高可用性策略。

注意

[!注意] 高可用性和灾难恢复概念不同。 虽然规划和解决方案之间存在重叠，但它们是业务连续性的子集。 高可用性的目的是在主要数据中心和计划停机中提供弹性。 灾难恢复的目的是，当主要数据中心的灾难使基础结构不可用时，它可以使组织在辅助数据中心内恢复计算机操作。 有关 SharePoint Server 的灾难恢复的信息，请参阅 选择 SharePoint Server 的灾难恢复策略。

高可用性通常用于描述当以下错误域的一个或多个类别中发生错误时，系统继续操作并为用户提供资源的能力：硬件、软件或应用程序。 可用性级别表示为系统继续操作以支持业务功能的时间的百分比度量。 不同组织要求的可用性级别有所不同。 虽然业务单位的要求可能也有不同，但服务级别协议适用于整个组织。 从用户的角度来看，当用户可以访问该场并使用他们必须完成工作的功能和服务时，可以使用 SharePoint 场。

高度可用的 SharePoint 服务器场具有以下目标和特征：

• 服务器场设计可以减少潜在的故障点。 由于不可能消除故障点，所以整体策略必须提供响应故障事件的方式。

• 故障转移事件是无缝的，并对用户活动产生最小的影响。

• 服务器场将继续采用较小容量进行操作，而不会完全失败。

• 服务器场具有弹性。 影响服务的事件不常发生，并且将在发生事件时采取及时有效的操作。

简介

在为您的 SharePoint 环境创建现实、经济的高可用性体系结构和策略之前，您必须定义并限定可用性目标。 这些目标可以反映您的组织依赖 SharePoint Server 的程度，以及丢失服务可能对组织的操作造成哪些影响。 丢失服务造成的影响取决于丢失的特性（完整或部分）和持续时间。

成功的高可用性策略必须反映您的组织的特定需要。 此外，它必须在业务需求、IT 服务级别协议 (SLA)、技术解决方案的可用性、 IT 支持功能以及基础结构成本之间提供最佳平衡。

为您的组织定义可用性要求之后，您可以开始创建高可用性设计和策略来减少停机和缩减操作的风险。 设计和部署高度可用系统的 IT 专业人员可以使用以下指导原则来实现其目标：

• 在每个错误域和整个系统的每个可能的层（操作系统、软件和 SharePoint 应用程序）上，消除单个故障点。

• 非常快速地实施错误检测、隔离以及解决方案。

高可用性解决方案范围广泛，并提供一组系统范围内的集成共享资源，这些资源可以提供所需的预定义服务。 解决方案将使用硬件和软件的不同组合，以便在系统或部分系统出现故障时最小化停机时间并恢复服务。

容错解决方案以硬件为中心，并且使用特定硬件检测错误，然后立即切换到冗余硬件组件。 该组件可能是处理器、内存板、电源、I/O 子系统或存储子系统。 通过切换到冗余组件，可以提供高级别的服务。

容错解决方案和高可用性解决方案的成本-收益分析使组织可以创建有效策略，以实现其 SharePoint 服务器场的可用性目标。 通常，这两个解决方案之间存在成本权衡。

实施高可用性的过程是用于 SharePoint 服务器场更昂贵的投资之一。 随着可用性级别和要使其高度可用的系统数量的增加，可用性解决方案的复杂性和成本也会增加。

虚拟化技术的进步使组织可以将虚拟计算机用作热、暖或冷的空闲设备。 虚拟计算机可能适合用于提供相同功能。 虚拟化可以提供灵活性和成本效率。 然而，您必须验证虚拟机是否有能力处理要替代的物理计算机的负载。

创建可以支持高可用性的服务器场体系结构

下图显示了如何分发和配置 SharePoint 环境的不同部分，以提高服务器场中的可用性。 此示例还演示了冗余如何解决容错域问题。

注意

[!注意] 我们的示例并不全面。 例如，它没有显示所有错误域和容错硬件。

服务器场拓扑中用于解决故障点的冗余的示例

参考上图中的拓扑，请注意以下内容：

• 该示例中的服务器场服务器可能是物理计算机或在 Hyper-V 主机服务器上部署的虚拟机。 用于标识和响应故障点的原则适用于这两种环境。

• 四个服务器 (W1-W4) 都专用于提供内容，如果在一个或多个服务器中发生故障，该冗余可以提高可用性。 此冗余级别还使服务器场可以在应用软件更新时继续操作。

• 四个应用程序服务器 (A1-A4) 可以提高服务器场服务和特定应用程序组件（例如搜索）的可用性。 搜索角色和组件均为冗余。

• 服务器场数据库服务器为冗余，并且可以使用数据库镜像或群集来实现数据库高可用性。

• 在虚拟环境中，虚拟机均放置在单独的 Hyper-V 主机服务器上，以消除单个故障点。 该虚拟机放置方法遵循了用于可用性和性能的最佳实践指南。

• 主要数据库服务器（标记为 1）和包含两个虚拟化主机计算机的机架 2（标记为 2）都标识为错误域，以显示如何将您的服务器场和基础结构作为错误域集合进行查看。 它将显示如何深入分析环境以开发整体策略和成本优势分析。

其他服务器场角色和服务

我们的示例不包含所有角色、服务和可能在特定 SharePoint 服务器场中运行的服务应用程序。 您不能对 SharePoint 服务器场中的所有对象使用高可用性的通用方法。 以下是使用高可用性的标准方法时重要的排除部分：

• 在故障转移期间，应特别关注分布式缓存。 有关详细信息，请参阅 规划分布式缓存服务以及在 SharePoint Server 中管理分布式缓存服务。

• SharePoint 工作流要求工作流管理器 1.0 累积更新 3。 配置 SharePoint Server 2016 的工作流与配置 SharePoint Server 2013 的工作流的过程相同。 有关详细信息，请参阅工作流管理器 1.0 累计更新 3 的说明和在工作流管理器 1.0 中配置具有高可用性的工作流。

  注意

  [!注意] SharePoint Server 2016 工作流的配置从 SharePoint Server 2013 后再未更改。 必须安装工作流管理器 1.0 累积更新 3。

• 虽然服务应用程序可以在多个计算机上运行（我们建议的做法），但一些计算机具有用于高可用性的独特安装和配置要求。 User Profile 应用程序就是一个已知示例。

在您的高可用性解决方案中使用容错

在设计可以支持高度可用的角色和工作负荷的体系结构之后，您可以使用容错组件来提高可用性。 容错解决方案可用于整个基础结构，其中包括数据库。

容错基础结构

容错可用于 SharePoint 服务器场的基础结构中的几乎每个硬件组件。 作为您的高可用性设计的一部分，它可以从操作和成本的角度确定基础结构的哪些部分应具有容错功能。 您可以使基础结构的每个部分都具有容错功能，但这并不意味着您应该这样做。

容错数据库服务器和数据库

因为 SharePoint 平台及其应用程序工作负荷取决于所有 SharePoint 数据库的可用性和可靠性，所以高度可用的数据库是高可用性策略中非常重要的方面。 您可以使用以下功能作为 SharePoint 数据库服务器和数据库的容错解决方案：

• SQL Server 2014 中使用 Service Pack 1 (SP1) ) 和 SQL Server 2012 的 SQL Server 2014 (FCI) 的 SQL Server 故障转移群集实例 (AlwaysOn 故障转移群集实例

• AlwaysOn 可用性组

• SQL Server 高可用性数据库镜像

关于 Always On 故障转移群集实例和 Always On 可用性组

故障转移集群需要两台计算机之间共享的磁盘存储。 在具有两个节点的配置中，计算机将配置为主动/被动，这可以提供主节点的完全冗余的实例。 仅当主节点失败时，被动节点才会联机。 一次仅向一台计算机显示共享磁盘。 该配置通常需要最冗余的硬件。 在 SQL Server 2014 (SP1) 和 SQL Server 2012 中，这种类型的群集配置是 AlwaysOn 故障转移群集实例，它是安装 SQL Server 的特定方法。 由于配置要求，不可以采用标准 SQL Server 安装，且无法轻松地将其更改为故障转移集群实例。

Always On 可用性组是 SQL Server 2014 (SP1) 和 SQL Server 2012 中的不同技术， (将其视为使用 Windows 群集公开的某些功能的数据库镜像) 的后代。 然而，它不需要共享的磁盘存储，并且可用性组中的计算机不必具有所安装的 SQL Server 的指定配置。 将数据库服务器添加到 Windows 群集后，可以相当轻松地启用 Always On 可用性组，然后配置所需的可用性组。

总之，任何运行 SQL Server 2014 (SP1) 和 SQL Server 2012 Enterprise Edition 的服务器都可以通过加入群集和配置可用性组来使用 Always On 可用性组。 AlwaysOn 故障转移群集需要特殊的硬件和配置步骤来设置故障转移群集实例。 这些技术中的每一种都可用于特定环境，并且两者都是互补的竞争对手。 有关这些功能的详细信息，请参阅高可用性解决方案 (SQL Server)。 有关决定使用哪种 SQL Server 可用性技术的帮助，请参阅 业务连续性和数据库恢复 - SQL Server。

重要

[!重要说明] 因为每个 SQL Server 高可用性选项都具有自己的功能、优点和缺点，所有单个选项之间并无优劣的区别。 例如，在使用 Always On 可用性组的给定方案中，尽量减少数据丢失可能比 Always On 故障转移群集实例实现的任何性能提升要好。 您必须基于业务要求和 IT 基础结构要求选择高可用性解决方案。

选择要使用的 SQL Server 选项的决定因素是 SharePoint 数据库。 您必须了解 SharePoint Server 数据库的特征。 每个数据库可能具有特定要求或约束，它们将确定在生产环境中完全受到支持的适合的 SQL Server 容错解决方案。 我们建议您查看以下文章：

• SharePoint Server 中的数据库类型和说明

• SharePoint 数据库的受支持的高可用性和灾难恢复选项

SQL Server 故障转移集群

故障转移集群为 SQL Server 2014 (SP1) 或 SQL Server 2012 上的 SQL Server 实例提供可用性支持。

故障转移集群是一个或多个节点或服务器以及两个或多个共享磁盘的组合。 虽然故障转移集群的实例显示为单个计算机，但如果当前节点不可用，实例将提供从一个节点到另一个节点的故障转移。 SharePoint Server 可以在 SQL Server 所支持的集群中的主动和被动节点的任何组合上运行。

SharePoint Server 将整体引用集群。 因此，可以从 SharePoint Server 方面自动进行无缝故障转移。

注意

如果发生计划或未计划的故障转移，连接将断开，并且在从一个集群节点转换到另一个集群节点时必须重新建立连接。

有关 SQL Server 故障转移群集的详细信息，请参阅 AlwaysOn 故障转移群集实例 (SQL Server) 。

SQL Server Always On 可用性组和 SQL Server 数据库镜像

SQL Server Always On 可用性组和 SQL Server 数据库镜像的主要优势是，两者都提供完整或几乎完整的数据冗余，具体取决于为事务处理配置它们的方式。 除了最大程度地减少数据丢失之外，自动故障转移还可以最大程度地缩短生产数据库的停机时间。

重要

[!注意] 虽然 SQL Server 2016、SQL Server 2014 (SP1) 和 SQL Server 2012 支持数据库镜像，但该功能已计划弃用。 我们建议避免在新的开发工作中使用此功能。 请计划更改当前使用该功能的应用程序。 请改用 Always On 可用性组。

AlwaysOn 可用性组

SQL Server Always On 可用性组功能是一种高可用性和灾难恢复解决方案，可提供数据库镜像的企业级替代方案。 Always On 可用性组支持针对用户定义的集合中包含的一个或多个用户数据库使用故障转移环境。 该集合（可用性组）包含以下组件：

• 副本是一组称为可用性数据库的离散的用户数据库，它们被作为一个单位进行处理。 可用性组可以支持一个主副本和最多四个辅助副本。

• 用于托管每个副本并维护属于可用性组的每个数据库的本地副本的 SQL Server 的指定实例。

当可用性组故障转移到目标实例或目标服务器时，该组中的所有数据库也将进行故障转移。 由于 SQL Server 2014 (SP1) 和 SQL Server 2012 可以在单个服务器上托管多个可用性组，因此可以将 Always On 配置为故障转移到不同服务器上的 SQL Server 实例。 这减少了配备空闲的高性能备用服务器来应对主服务器出现满载情况的需求，这正是可用性组的若干优势之一。

注意

数据库因数据文件丢失、数据库删除或事务日志损坏而变得可疑等数据库问题不会引起故障转移。

有关 Always On 可用性组的优势和 Always On 可用性组术语概述的详细信息，请参阅 Always On 可用性组 (SQL Server) 。

数据库镜像

注意

[!注意] 虽然 SQL Server 2016、SQL Server 2014 (SP1) 和 SQL Server 2012 支持数据库镜像，但该功能已计划弃用。 我们建议避免在新的开发工作中使用此功能。 请计划更改当前使用该功能的应用程序。 请改用 Always On 可用性组。

数据库镜像可以通过在主要数据库服务器上保留数据库的镜像副本来提供数据库冗余。 将基于每个数据库实现镜像，并且镜像仅与使用完全恢复模型的数据库一起使用。

注意

存在两种镜像操作模式。 其中一种是高安全性模式，它支持同步操作。 在高安全性模式中，当会话开始时，镜像服务器将尽快同步镜像数据库和主体数据库。 同步数据库之后，事务将立即写入辅助服务器上的日志，然后重新播放。 (控制在事务强化后立即返回到主体服务器。) 另一种镜像模式是高性能的，它使用异步操作来降低事务延迟，但代价是数据丢失增加。

对于 SharePoint 服务器场中的高可用性镜像，您必须结合使用高安全性模式和自动故障转移。 高安全性数据库镜像需要三个服务器实例：主体、镜像和见证。 见证服务器将使 SQL Server 可以从主体服务器自动故障转移到镜像服务器。 从主体数据库到镜像数据库的故障转移通常需要几秒钟。

有关数据库镜像的常规信息，请参阅数据库镜像。

重要

对于配置为使用 SQL Server FILESTREAMD 远程 BLOB 存储提供程序的数据库，不能进行镜像。

用于单个服务器场的数据库可用性和恢复策略的对比

选择用于高可用性和灾难恢复的 SQL Server 技术时，应该基于组织的恢复点目标 (RPO) 和恢复时间目标 (RTO) 的业务目标。 虽然 RPO 和 RTO 通常与灾难恢复相关联，但某些故障超出灾难的范围，却需要从主体数据中心的本地备份媒体中恢复。

重要

[!重要说明] 根据特定数据库，各种 SharePoint Server 数据库仅支持特定的 SQL Server 高可用性选项。 有关详细信息，请参阅SharePoint 数据库的受支持的高可用性和灾难恢复选项。

下表将提供可用 SQL Server 解决方案实现的 RPO 和 RTO 结果之间的总体比较。

注意

[!注意] 下表中的时间用于比较数据库选项。 实际上，所有时间都取决于工作负荷、数据量和故障转移过程。

基于数据库技术的 RPO 和 RTO 之间的比较

SQL Server 解决方案	潜在数据丢失 (RPO)	潜在恢复时间 (RTO)	自动故障转移	可读辅助副本 注意： SharePoint Server 支持运行时使用的可读次要副本。 有关详细信息，请参阅 Office 2013 2014 年 4 月累积更新 和 运行在 SharePoint Server 中使用只读数据库的场。
AlwaysOn 可用性组 (同步提交)	零	秒	是	0 - 2
AlwaysOn 可用性组 (异步提交)	秒	分钟	否	0 - 4
AlwaysOn 故障转移群集实例	不应用 FCI 自身不提供数据保护。 数据丢失的量取决于存储系统的实现。	秒到分钟	是	不应用
数据库镜像 - 高安全性（同步模式 + 见证服务器）	零	秒	是	不应用
数据库镜像 - 高性能（异步模式）	秒	分钟	否	不应用
备份、副本、还原	小时或零（如果出现故障后可以访问日志的尾部。）	小时到天	否	不在还原期间

SQL Server 群集、Always On 可用性组和数据库镜像的比较

进程	SQL Server 故障转移集群	SQL Server 2014 (SP1) 和 SQL Server 2012 Always On 可用性组	SQL Server 高可用性镜像
用于故障转移的时间	集群成员将在出现故障后立即接管。 集群节点进行调节时，将出现延迟。	副本将在出现故障后立即接管。 辅助副本进行调节时，将出现延迟。	镜像将在处理弃用队列后立即接管。
事务一致性	是	是	是
事务并发率	是	是	是
用于恢复的时间	用于恢复的时间少于可用性组。	用于恢复的时间多于故障转移集群，但少于镜像解决方案。	用于恢复的时间稍微多于集群或可用性组。
故障转移需要的步骤	数据库节点可以自动检测故障。 SharePoint Server 将引用集群，以便自动进行无缝故障转移。	可用性组侦听器可以自动检测故障，并自动进行无缝故障转移。	数据库将自动检测故障。 如果正确配置 SharePoint Server，并允许自动故障转移，它就可以知道镜像位置。
针对出现故障的存储的保护	故障转移集群自身不提供数据保护。 数据丢失的量取决于存储系统的实现。 例如，SAN 环境具有冗余组件，例如多个文件路径、RAID 和热的空闲设备。	因为主副本将写入辅助副本上的本地磁盘，所有要针对出现故障的存储进行保护。	因为主体和镜像数据库服务器都将写入本地磁盘，所有要针对出现故障的存储进行保护。
支持的存储类型	需要比专用存储成本更昂贵的共享存储。	可以使用成本较低的直接附加的存储解决方案。	可以使用成本较低的直接附加的存储。
位置要求	集群的成员必须在相同的子网上。 Note: 这不适用于 SQL Server 2014 (SP1) 和 SQL Server 2012。	只要延迟不导致性能问题，副本就可以位于不同的子网。	主体、镜像和见证服务器必须在相同的 LAN（延迟往返行程最多为 1 毫秒）上。
恢复模型	建议使用 SQL Server 完整恢复模型。 您可以使用 SQL Server 简单恢复模型。 然而，集群丢失时，仅有的可用恢复点将是最后的完整备份。	需要 SQL Server 2014 (SP1) 和 SQL Server 2012 完整恢复模型。	需要 SQL Server 完整恢复模型。
性能开销	发生故障转移时，可能出现性能下降。 故障转移期间，服务器将不可用，并将断开连接，然后在新的活动节点上重新建立连接。	由于次要副本上的同步提交，AlwaysOn 可用性组引入了事务延迟。 延迟的量取决于必须同步的辅助副本的数量。 内存和处理器开销大于集群，但小于镜像。	由于高可用性镜像具有同步功能，所以引入了事务延迟。 它还要求额外的内存和处理器开销。
操作开销	在服务器级别设置和维护。	操作开销大于集群和镜像。 除了 Windows Server 级别之外，Always On 还需要 SQL Server 数据库服务器级别的开销。 注意：必须手动维护服务器级对象（如登录和代理作业）。 如果你添加内容服务器，必须将其添加到可用性组，然后将主副本同步到辅助副本。 SharePoint 服务器场环境需要多个配置步骤，以确保 SharePoint Server 连接字符串正确地与可用性组侦听器名称相关联。	操作开销大于集群。 必须为所有数据库进行设置和维护。 在手动故障转移后重新配置。 注意：必须手动维护服务器级对象（如登录和代理作业）。 如果您添加内容服务器，必须将其添加到主体，然后将主体同步到镜像。

将两个数据中心配置为单个服务器场（"拉伸"场）以提供高可用性

一些企业具有紧密放置的数据中心，它们由高带宽的光纤链路进行连接。 当该环境可用时，可以将两个数据中心配置为单个服务器场。 该分布式服务器场拓扑称为"拉伸"场。

若要将拉伸场体系结构用作受支持的高可用性解决方案，必须满足以下先决条件：

• 服务器场内延迟 <高度一致， (单向) ,99.9% 的时间在 10 分钟内。 (场内延迟通常定义为前端 Web 服务器和数据库服务器之间的延迟。)

• 带宽速度必须至少每秒 1 GB。

若要在拉伸场中提供容错，请使用用于配置冗余服务应用程序和数据库的标准最佳实践指南。

下图显示拉伸场。

延伸式服务器场

合并高可用性策略中的备份和还原操作

您的高可用性策略必须包含适合的备份和还原操作，以确保 SharePoint 服务器场具有弹性。 当发生媒体故障或用户错误时，必须可以及时还原服务器场环境或服务器场数据受影响的部分。 有效的备份和还原解决方案应该使您可以达到您所定义的恢复时间目标 (RTO) 和恢复点目标 (RPO)。

另请参阅

概念

SharePoint Server 中的高可用性和灾难恢复概念

选择 SharePoint Server 的灾难恢复策略