SharePoint Server 中的高可用性和灾难恢复概念
适用于：
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
为 SharePoint 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)。 通过此方法，您可将在计划维护活动方面的投资与避免计划外停机的成效进行比较。
可用性降级
不应将高可用性视为全有或全无的方案。 作为完全中断的替代，最终用户通常可接受系统部分可用，或具有有限功能或性能降级。 这些不同程度的可用性包括：
只读和延迟操作。 在维护时间内，或在分阶段灾难恢复期间，仍可进行数据检索，但新工作流和后台处理可能会暂时停止或排队。
数据延迟和应用程序响应能力。 由于工作负荷繁重、处理积压工作或部分平台故障，有限的硬件资源可能会过度订阅或不够用。 用户体验可能较差，但仍可完成工作，只是工作效率较低。
部分、短暂或将来的故障。 应用程序逻辑或硬件堆栈中的强健性可在遇到错误时重试或自我纠正。 这些类型的问题对最终用户显示为数据延迟或应用程序响应能力较差。
部分端对端故障。 计划或计划外中断可能会正常发生在解决方案堆栈（基础架构、平台和应用程序）的垂直层，或以水平方式发生在不同的功能组件之间。 根据受影响的功能或组件，用户可能会遇到部分成功或降级。
应将这些非最优方案的可接受程度视为导致完全中断的一系列降级可用性的一部分和分阶段灾难恢复中的中间步骤。
量化停机
确实发生停机时（无论是计划内还是计划外），主要业务目标是使系统恢复联机和尽量减少数据丢失。 每分钟的停机时间都有直接和间接的成本。 对于计划外停机，必须权衡考虑确定发生中断的原因所需的时间和工作量、当前的系统状态，以及需要哪些步骤来从中断恢复。
在任何中断的预确定点，应做出或寻找停止调查中断或执行维护任务的业务决策，通过使系统恢复联机来从中断恢复，以及重新建立容错（如果需要）。
恢复目标
数据冗余是高可用性数据库解决方案的主要组件。 主要 SQL Server 实例上的事务活动以同步或异步方式应用于一个或多个辅助实例。 发生中断时，可回滚将处理的事务，否则由于数据传播的延迟，它们可能会在辅助实例上丢失。
您可根据恢复业务所需时间和恢复的上次事务中存在的时间延迟衡量影响和设置恢复目标：
恢复时间目标 (RTO)。 它是中断的持续时间。 初始目标是使系统恢复联机状态，使其至少能提供只读容量，以方便进行故障调查。 但主要目标是将整个服务还原到可发生新事务的点。
恢复点目标 (RPO)。 通常将它称为可接受数据丢失的标准。 它是故障前最后一次提交数据事务和故障后恢复的最新数据之间的时间差或延迟。 根据故障时系统上的工作负荷、故障的类型和使用的高可用性解决方案的类型，实际数据丢失可能会有所不同。
注意
[!注意] 相关目标是 恢复级别目标 (RLO)。 此目标定义必须能够通过其恢复数据的粒度 是否必须能够恢复整个服务器场、Web 应用程序、网站集、网站、列表或库或者项目。 有关详细信息，请参阅在 SharePoint Server 中规划备份和恢复。
应将 RTO 和 RPO 值用作指示停机和可接受数据丢失的业务容忍度的目标，以及监控可用性运行状况的指标。
调整 ROI 或商机成本
停机的业务成本可能是财务的，也可能是客户信誉方面的。 这些成本可能是随时间产生的，也可能是在中断时间中的某个点引发的。 除预测给定恢复时间和数据恢复点引发的中断的成本外，还可计算实现 RTO 和 RPO 目标或避免所有中断所需的业务流程和基础架构投资。 这些投资主题应包括：
避免停机。 如果起始未发生故障，则会避免所有故障恢复成本。 投资包括容错和冗余硬件或基础架构的成本、在单独的故障点分布工作负荷和预防性维护的计划停机。
自动恢复。 如果发生系统故障，则可通过自动和透明的恢复显著缓解停机对客户体验的影响。
资源利用率。 辅助或备用基础架构可能会处于空闲状态，等待中断。 还可能会将其用于只读工作负荷，或用于通过在所有可用硬件上分布工作负荷来改进整体系统性能。
对于给定 RTO 和 RPO 目标，所需的可用性和恢复投资以及预测的停机成本可能是明确的，并判断为时间的功能。 在实际中断时，它允许您根据经过的停机时间做出基于成本的决策。
监控可用性运行状况
从运营的角度看，在实际中断时，不应尝试考虑所有相关变量，以及实时计算 ROI 或商机成本。 相反，应作为预期 RPO 的代理监控待机实例上的数据延迟。
在发生中断时，还应限制在中断时在调查根源上花费的最初时间，而将重点放在验证恢复环境的运行状况上，然后依赖详细系统日志和辅助数据副本来进行后续辩证分析。
规划灾难恢复
高可用性工作限定防止中断所需的操作，而灾难恢复工作解决中断后重新建立高可用性所需的项目。
在实际发生中断前，应尽可能规定灾难恢复过程和责任。 根据活动监控和警报，启动自动或手动故障转移和恢复计划的决策应绑定到预先确定的 RTO 和 RPO 阈值。 良好的灾难恢复计划的范围应包括：
故障和恢复的粒度。 根据故障的位置和类型，可在不同的级别采取纠正性措施；即：数据中心、基础架构、平台、应用程序或工作负载。
调查原始资料。 基准和最新监控历史记录、系统警报、事件日志和诊断查询应可供相应方访问。
相关项协调。 在应用程序堆栈中和利益干系人中，系统和业务相关项有哪些？
决策树。 包括责任、故障分类、以 RPO 和 RTO 目标为依据的故障转移标准和规定的恢复步骤在内的预先确定的、可重复的、经验证的决策树。
验证。 在执行从中断恢复的步骤后，必须执行哪些操作以验证系统已返回到正常条件？
文档。 将以上所有项目详细而清晰地捕获到一组文档中，以便第三方团队能够在尽可能少的帮助下执行恢复计划。 此类文档通常称为"指导手册"或"操作手册"。
恢复演练。 定期练习灾难恢复计划，以建立对 RTO 目标的基准预期，并考虑在主要网站和每个灾难恢复网站上定期循环承载主要生产网站。