SharePoint 高可用和备份恢复方案（一， 系统层面的要求与介绍）

Posted 2020-08-31 段传涛



SharePoint 高可用和备份恢复方案（一 SharePoint 层面）

高可用性（High Availability），是指在服务器出现硬件或者网络故障的时候，尽可能不会中断服务，并尽可能减少对用户的影响。

SharePoint服务器场本身是一个典型的三层架构（从2007、到2010、2013再到2016，这个基本的架构都是一样的），也就是前端服务器 - 应用服务器 - 数据库服务器。当然随着系统优化和对高可用要求提升，高可用和恢复技术也有所提高。

也许大家都很清楚SharePoint 2016增加的MinRole 功能，不仅优化服务器资源，高可用和系统恢复也有很大的提高。

在实际项目中，是否需要考虑高可用性方案，除了IT部门的意识外，也有一个很重要的因素就是高可用性的成本。几乎所有的高可用性方案都是靠冗余的硬件来实现的，因此在一些小型SharePoint项目、以及一些对服务和数据并不十分敏感的项目中，出于成本或其他因素的考虑，往往不会考虑使用高可用性方案，一个适当的备份计划可能就足够了。

SharePoint 平台高可用和备份策略整体分为三个方面，SP系统，数据库和Server。三个方面综合在一个合成一个SharePoint 平台的备份方案。 

首先查了一些资料，大致从下面的三个方面入手；

• 不间断业务
• 高可用量化指标
• 意外停机恢复的最少损失方案。

• 一，业务不间断包含

业务连续性管理是定义、评估和帮助管理组织的连续运行风险的管理过程或程序。下表总结业务连续性管理的输入和输出。

业务连续性管理以创建和维护业务连续性计划为重点，在负面条件中断了正常的业务运营时，该计划是连续运营的指南。这些负面条件可能是自然的、人为的，也可能是两者的结合。连续性计划源于以下分析和输入：

• 有效的业务分析

• 最大化风险分析

• 有效的恢复方案

• 一套完整的恢复需求

  结果是解决方案设计或确定的选项、实施计划、测试和组织接受度计划，以及维护计划或安排。

  业务连续性管理的一个良好而简洁的示例是通过业务连续性管理降低运营风险，其中提供了 Microsoft 业务连续性程序的快照。本文和配套的视频确定了程序的目标，并突出了促成其成功的因素。

  很明显，信息技术 (IT)是许多组织的业务连续性计划的重要方面。但是，业务连续性涵盖的范围更广 - 它包括确保组织能够在重大破坏性事件期间和之后立即继续开展业务所需的所有操作。业务连续性计划包括但不限于以下元素：
  

• 策略、流程和过程

• 可能的选项和决策制定责任

• 人员安排计划及其辅助设备

• 信息技术

  尽管高可用性和灾难恢复通常等同于业务连续性管理；但事实上，它们只是业务连续性管理的一部分。

• 二，高可用量化指标

对于给定软件应用程序或服务，高可用性最终依据最终用户的体验和期望来衡量。

停机时间的具体和感知的业务影响可能表现为信息丢失、财物破坏、生产力降低、商机成本、合同破坏或信誉损失。

高可用性解决方案的主要目标是尽量减少或缓解停机时间的影响。

高可用性解决方案的合理策略可以最佳方式平衡业务流程和服务级别协议 (SLA) 与技术功能和基础架构成本。

根据客户和利益干系人的协议和期望，可将某平台视为高可用。系统的可用性可通过以下计算结果表示：

实际运行时间/期望运行时间 X 100%

生成的值通常由行业根据解决方案提供的 9 的个数表示；用于表示每年可能的正常运行分钟数（或相反，停机分钟数）。

9 的个数	可用性百分比	每年总停机时间
2	99%	3 天，15 小时=
3	99.9%	8 小时，45 分钟
4	99.99%	52 分钟，34 秒
5	99.999%	5 分钟，15 秒

计划和计划外停机时间

系统故障是预期的或计划的，或者是计划外故障的结果。如果正确管理停机，则不需要负面考虑停机。主要有两种可预测的停机：

• 计划维护。预先通知和调整了计划维护任务（如软件修补、硬件升级、密码更新、脱机重新编制索引、数据加载或灾难恢复过程演练）的时间窗口。有意的、管理良好的运营过程应尽可能减少停机，并防止任何数据丢失。可将计划维护活动视为阻止或缓解其他可能更严重的计划外故障方案所需的投资。
• 计划外故障。系统级基础架构或流程故障可能会意外或以不可控制的方式发生，或者这些故障是可预测的，但被视为不太可能发生，或者被视为其影响可接受。强健的高可用性解决方案可检测到这些类型的故障，自动从故障恢复，然后重新建立容错。

制定 SLA 以获得高可用性时，应单独计算计划维护活动和计划外停机的关键绩效指标 (KPI)。通过此方法，您可将在计划维护活动方面的投资与避免计划外停机的成效进行比较。

不应将高可用性视为全有或全无的方案。作为完全中断的替代，最终用户通常可接受系统部分可用，或具有有限功能或性能降级。这些不同程度的可用性包括：

• 只读和延迟操作。在维护时间内，或在分阶段灾难恢复期间，仍可进行数据检索，但新工作流和后台处理可能会暂时停止或排队。
• 数据延迟和应用程序响应能力。由于工作负荷繁重、处理积压工作或部分平台故障，有限的硬件资源可能会过度订阅或不够用。用户体验可能较差，但仍可完成工作，只是工作效率较低。
• 部分、短暂或将来的故障。应用程序逻辑或硬件堆栈中的强健性可在遇到错误时重试或自我纠正。这些类型的问题对最终用户显示为数据延迟或应用程序响应能力较差。
• 部分端对端故障。计划或计划外中断可能会正常发生在解决方案堆栈（基础架构、平台和应用程序）的垂直层，或以水平方式发生在不同的功能组件之间。根据受影响的功能或组件，用户可能会遇到部分成功或降级。

应将这些非最优方案的可接受程度视为导致完全中断的一系列降级可用性的一部分和分阶段灾难恢复中的中间步骤。

• 三，意外停机恢复的最少损失方案。

确实发生停机时（无论是计划内还是计划外），主要业务目标是使系统恢复联机和尽量减少数据丢失。

每分钟的停机时间都有直接和间接的成本。对于计划外停机，必须权衡考虑确定发生中断的原因所需的时间和工作量、当前的系统状态，以及需要哪些步骤来从中断恢复。

在任何中断的预确定点，应做出或寻找停止调查中断或执行维护任务的业务决策，通过使系统恢复联机来从中断恢复，以及重新建立容错（如果需要）。

恢复目标

数据冗余是高可用性数据库解决方案的主要组件。主要 SQLServer 实例上的事务活动以同步或异步方式应用于一个或多个辅助实例。发生中断时，可回滚将处理的事务，否则由于数据传播的延迟，它们可能会在辅助实例上丢失。

您可根据恢复业务所需时间和恢复的上次事务中存在的时间延迟衡量影响和设置恢复目标：

·      恢复时间目标 (RTO)。它是中断的持续时间。初始目标是使系统恢复联机状态，使其至少能提供只读容量，以方便进行故障调查。但主要目标是将整个服务还原到可发生新事务的点。

·      恢复点目标 (RPO)。通常将它称为可接受数据丢失的标准。它是故障前最后一次提交数据事务和故障后恢复的最新数据之间的时间差或延迟。根据故障时系统上的工作负荷、故障的类型和使用的高可用性解决方案的类型，实际数据丢失可能会有所不同。

应将 RTO 和 RPO 值用作指示停机和可接受数据丢失的业务容忍度的目标，以及监控可用性运行状况的指标。

调整 ROI 或商机成本

停机的业务成本可能是财务的，也可能是客户信誉方面的。这些成本可能是随时间产生的，也可能是在中断时间中的某个点引发的。除预测给定恢复时间和数据恢复点引发的中断的成本外，还可计算实现 RTO 和 RPO 目标或避免所有中断所需的业务流程和基础架构投资。这些投资主题应包括：

·      避免停机。如果起始未发生故障，则会避免所有故障恢复成本。投资包括容错和冗余硬件或基础架构的成本、在单独的故障点分布工作负荷和预防性维护的计划停机。

·      自动恢复。如果发生系统故障，则可通过自动和透明的恢复显著缓解停机对客户体验的影响。

·      资源利用率。辅助或备用基础架构可能会处于空闲状态，等待中断。还可能会将其用于只读工作负荷，或用于通过在所有可用硬件上分布工作负荷来改进整体系统性能。

对于给定 RTO 和 RPO 目标，所需的可用性和恢复投资以及预测的停机成本可能是明确的，并判断为时间的功能。在实际中断时，它允许您根据经过的停机时间做出基于成本的决策。

监控可用性运行状况

从运营的角度看，在实际中断时，不应尝试考虑所有相关变量，以及实时计算 ROI 或商机成本。相反，应作为预期 RPO 的代理监控待机实例上的数据延迟。

在发生中断时，还应限制在中断时在调查根源上花费的最初时间，而将重点放在验证恢复环境的运行状况上，然后依赖详细系统日志和辅助数据副本来进行后续辩证分析。

规划灾难恢复

高可用性工作限定防止中断所需的操作，而灾难恢复工作解决中断后重新建立高可用性所需的项目

在实际发生中断前，应尽可能规定灾难恢复过程和责任。根据活动监控和警报，启动自动或手动故障转移和恢复计划的决策应绑定到预先确定的 RTO 和 RPO 阈值。良好的灾难恢复计划的范围应包括：

·      故障和恢复的粒度。根据故障的位置和类型，可在不同的级别采取纠正性措施；即：数据中心、基础架构、平台、应用程序或工作负载。

·      调查原始资料。基准和最新监控历史记录、系统警报、事件日志和诊断查询应可供相应方访问。

·      相关项协调。在应用程序堆栈中和利益干系人中，系统和业务相关项有哪些？

·      决策树。包括责任、故障分类、以 RPO 和 RTO 目标为依据的故障转移标准和规定的恢复步骤在内的预先确定的、可重复的、经验证的决策树。

·      验证。在执行从中断恢复的步骤后，必须执行哪些操作以验证系统已返回到正常条件？

·      文档。将以上所有项目详细而清晰地捕获到一组文档中，以便第三方团队能够在尽可能少的帮助下执行恢复计划。此类文档通常称为“指导手册”或“操作手册”。

·      恢复演练。定期练习灾难恢复计划，以建立对 RTO 目标的基准预期，并考虑在主要网站和每个灾难恢复网站上定期循环承载主要生产网站。

首先，前端服务器。

前端服务器的高可用性其实是这三层里面最容易的了，因为前端服务器上只有程序、配置文件和一些模版文件，所有的“实际”数据都存放在最后端的数据库中。因此在前端服务器一层，只需要保证所有的自定义程序都是一致的（这也是用SharePoint标准部署方案WSP的好处，系统会自动帮你部署到所有的服务器场中、甚至新加入的服务器场），多台服务器只需要一个简单的负载均衡（NLB，可以通过软件或者硬件实现），就可以实现这一层的高可用性。

需要说明的是，在SharePoint 2013中，新增加了一个“Request Management”功能，这个功能其中一项应用就是根据服务器的运行情况，来把用户的请求（Request）分配到合适的前端服务器上去执行。

其次，应用服务器。

这里的“应用”主要指的是SharePoint中的那些Service Application，包括但不限于Excel Service、Secure Store Service、Managed Metadata Service、Search Service、User Profile Service等等。这些“应用”——或者叫服务——基本上都可以同时运行在多台服务器中，它们的数据（如果有的话），也都是存放在数据库服务器中（部分服务的临时数据是放在这些服务器本地的，另外搜索服务器中的索引也是放在本地的），因此也可以比较方便地实现这一层面的高可用性。这些服务器之间是靠SharePoint自身来实现负载均衡的。

下面这张图是SharePoint 2010中Service Application的一个架构图：

从图中可以看出来，这些“服务”是运行在“云端”的一到多台服务器上的，服务的调用是由前端服务器上面的代理，通过WCF接口去访问的，具体调用哪一台服务器的逻辑是由SharePoint负责维护的，有其中一台挂掉的话，并不影响其他服务器的运行。我们在管理中心的管理服务应用程序中，会看到每个服务都可以看到两个链接，其中上面那个是对服务本身的设置，下面那个就是运行在前端服务器上的这个服务代理的设置。

从图上也可以看出来，所有的用户请求都是发送到前端服务器上的，并不会直接连接到后面的应用程序层和数据库层，因此这两层的服务器可以完全对最终用户隔离从而保证其安全性。最近这两次微软组织的SharePoint培训，因为时间原因，都把服务架构的课程砍掉了（上面这张图就来自于这个课程的PPT），不过我在介绍BCS的时候，也都大概提了几句，我觉得这个架构对于IT管理员而言还是比较重要的。——这是题外话，嗯。

不过，对于SharePoint的众多服务而言，搜索服务是一个特例。搜索的服务器角色设置是由搜索服务本身来完成的，搜索分为管理、查询、爬网三个组件，细说起来可能会比较复杂，篇幅所限，有兴趣的人可以到这个链接去看详细介绍：规划企业级搜索的拓扑。

需要说的是，在SharePoint 2007中，一个搜索服务中的索引服务器角色只能由一台服务器充当，因此在高可用性方面是一个潜在的风险，从2010开始，这个问题已经得到了解决。

最重要的，数据库服务器。

就如同前面所说的，SharePoint中所有“实际”数据，都是存放在数据库中的，因此，高可用性最重要的，也就是针对数据库层的规划。因为其他几个层面即使不做高可用性，最多带来的就是用户在一段时间内无法访问网站，或者无法使用网站某些功能的问题；而一旦数据库服务器出了问题，带来的很可能就是数据本身的丢失，这往往是更严重的问题。

首先，来介绍一下SharePoint对数据库的要求：必须在1毫秒内对ping作出相应；必须在20毫秒内返回数据的第一个字节——当然，这个要求并不是强制性的，即使达不到这个要求，一般情况下也不会造成什么大问题，只不过在设计数据库方案，尤其是高可用性方案的时候，这也是必须要考虑到的一个问题。

在SharePoint服务器场中，数据库一层的所有高可用性方案，本质上都是由SQL Server所提供的，因此，我们就从SQL Server的角度，来衡量一下几种方案的优劣。

SQL Server的高可用性方案可以分为如下4种：

0、复制（Replication）

1、日志传送（Log Shipping）

2、数据库镜像（Mirroring）

3、故障转移群集（Failover Cluster）

其中的第0种Replication是不被SharePoint支持的，因此我们只考虑剩下的三种。

1、日志传送（Log Shipping）

 

Log Shipping的主要原理，就是主数据库服务器，定时将事务日志（Transaction Log），通过网络传送到第二台数据库中，这第二台数据库根据日志内容进行数据的还原。这个时间间隔，是分钟级别的。

但是由于不是所有的SharePoint数据库都支持Log Shipping（支持的有Managed Metadata Service的数据库、Secure Store Service的数据库，以及最重要的内容数据库等；不支持的比如配置数据库、搜索数据库等等）。尤其是每个服务器场必须的，也是最重要的配置数据库不支持这一技术，因此只能针对Log Shipping后的数据库再建立一个“备用”的服务器场，在这个服务器场中，Log Shipping过来的几个数据库需要设置成只读的（Ship过来的Log是数据的唯一来源，从而保持数据的一致性）。当原始的服务器场挂掉之后，再通过DNS的方式切换到这个“备用”服务器场中，以只读的方式进行访问（SharePoint支持使用只读数据库模式）。当然，你可以再切换之后把数据库重写设置为读写模式，但这样的话想再切换回原始的服务器场，可能由需要做一些额外的工作了。

Log Shipping方式的优点：

• 独立的数据库，由于对带宽的需求并不严格，甚至可以和原始数据库分布在不同的地理位置。
• 可以作为一个“只读”的备份场来使用，可以用于某些场景下跨地域部署的方案。
• 由于日志备份、传送、恢复的过程是异步的，所以这种方案对原始的服务器场几乎没有性能上的影响

Log Shipping方式的缺点：

• 由于日志传送是异步的，因此在主服务器场故障之后，可能会造成一些数据丢失。
• 在出现故障之后，需要手动进行切换（当然也可以通过一些脚本的方式自动实现），后期维护的成本比较高
• 因此，Log Shipping的方式在实际运用中，主要是用来做灾难恢复（Disaster Recovery），而不是高可用性。

2、数据库镜像

（请忽略左下角的那个东西）

数据库镜像从基本原理上来讲其实很简单，就是一份数据写在两处（就像RAID1一样），一个挂了另一个顶上去。

SQL Server的数据库镜像有几种方式，主要差别就是在写两次的具体过程：“高可用性”方案就是写完第一台之后就不管了，立即返回；由第一台去负责写第二台，是不是写成功了也不管，这个其实Log Shipping差不多，主要为了减少镜像功能对原始数据库带来的性能损失；第二种方式就是镜像数据库写完之后返回一个成功标志，然后写数据库这个操作再返回，这样可以保证两个数据库的绝对一致性；第三种方式其实是在第二种方式的基础之上，增加了一台额外的“见证”服务器（也是一台SQL Server，但是本身不存储任何数据），负责实时监控主数据库和镜像数据库的状态，当主数据库挂掉之后，会自动切换到镜像数据库。

数据库镜像的方式其实也是SharePoint比较推荐的一种方式，在SharePoint所有设置数据库的地方，都有两个数据库名称可以填，一个填主数据库、一个填镜像数据库，点确定的时候SharePoint会验证这两个数据库是不是真的配好了镜像。

上图来自SharePoint 2013（懒得再切换到2010的虚机了，其实是一样的），需要特别注意的是，SharePoint的配置数据库是没有界面可以设置镜像的，只能通过PowerShell脚本进行设置。

数据库镜像的优点：

• 支持SharePoint中所有的数据库
• 故障后可以自动进行切换（对于SharePoint来说，如果你想用这种方式的话，最好是使用带见证服务器的那种最保险的方式；如果想追求性能的话，还不如用Log Shipping）
• 数据完整，不会丢失（见上文的括号内容）
• 可以做成“延伸式服务器场”，也就是主前端+主应用+主数据库在一起，二前端+二应用+镜像数据库在另一个机柜/机房，这样可以防止因为电源或者网络原因造成的硬件故障（但是镜像数据库不支持异地部署，因为无法保证带宽）

数据库镜像的缺点：

• 对性能略有影响（写完两次数据库才返回）
• 需要额外的一台见证服务器（不过这台服务器可以使用SQL Server Express）
• 不支持RBS

3、故障转移群集（Failover Cluster）

故障转移群集其实就和SharePoint没什么关系了，完全是SQL Server自己玩的功能，很多非SharePoint的应用也在利用这种方式来做高可用性。

其基本原理，就是两台数据库服务器，连接一个共享存储（使用SAN或NAS），平时由其中一台数据库处理所有操作，当这台服务器故障的时候，SQL Server会自动切换成使用另一台数据库来进行操作。所以共享存储其实在任何时刻，都是只有一台机器在对它进行读写。

SQL Server的标准版支持2台数据库做群集，而企业版支持最多16台数据库做群集。

群集是通过一个虚拟节点暴露给外界的（就像NLB一样），所以对数据库的使用者而言，这种方法是透明的，因此SharePoint表示毫无压力。

故障转移群集的优点：

• 故障之后可以自动切换，后期维护成本低
• 因为同时只有一台机器在写，所以对性能没有任何影响

故障转移群集的缺点：

• 因为要使用共享存储（SAN或者NAS），所以硬件成本会比使用本地直连存储（DAS）要高
• 需要操作系统级别的群集功能的支持（必须是Windows Server企业版），所以软件成本也会高一些
• 对RBS的支持需要考虑：如果使用SQL Server自带的RBS FILESTREAM Provider，因为它只支持本地存储（也就是存储必须被数据库服务器识别成本地磁盘，而不是网络磁盘），所以只能使用SAN的方式，不能使用NAS；如果使用第三方的Provider，那就看第三方的硬件需求了
• 这个高可用性只针对服务器，不针对存储本身（因为是共享存储），所以存储本身也需要考虑高可用性方案（可以使用RAID1、RAID5或者RAID1+0）