SharePoint 2016：性能优化和高可用（三，设计高可用性数据库拓扑）
确保主要应用发生故障时继续运行，在正常情况下，发生故障时会中断所有应用。通过搭建高可用性策略。
您可以确保应用不间断。
例如；服务正常运行时间，以百分比来衡量。例如99.99％的正常运行时间，一年是31536000，仅有0.01％的停机时间，相当于87.6小时。也是说有几天的是时间是意外中断的。
所以SharePoint系统搭建高可用，是势在必行的。除非企业买不起服务器，用不起运维，这个不在本文范围内。
当然系统突然中断的原因太多了，如山图所示，设计一个高可用的设计，包含这些基本元素。这里先讨论数据库层面，设计.
- 镜像
在数据库服务创建镜像是实现高可用的方法之一，未来在数据系统会放弃这一功能（SQL Server 2016 会保留，之后会遗弃）下图是一个数据库高可用的镜像架构图，图文来自与MPP
- 故障转移
故障转移集群、日志传送亦或基于磁盘的备份都是作为单一技术出现的，而在真实的大中型企业环境中为了确保数据应用的持续在线，我们通常有一些组合多种高可用技术的方案。通过混合不同可用性技术，我们将可以采长补短。
- 例如数据库镜像技术。
虽然数据库镜像可以解决故障转移集共享存储存在单点失效威胁、依赖于特殊硬件等一系列的问题，但是数据库镜像最大的问题就是故障转移路径过短。对于大中型企业来说，仅有两个节点的故障转移路径有些不足。因此通过增加一个故障转移集群作为数据库镜像的镜像节点就可以解决了数据库镜像故障转移路径过短的问题。
上面这种解决方案当主体服务器失效后，数据库镜像会将启动镜像节点，而由于镜像节点是由一个故障转移集群承担的，因此当镜像节点中的一个节点失效后还有一个后备节点，因此还可以有一个后备节点承担。
其实故障转移集群和数据库镜像是各有利弊，因此这两种技术融合在一起后的解决方案不仅仅是上面这一种，下面就给出另外一种解决方案的示意图：
细心的读者可能会发现，方案二种没有了见证节点，这意味着从主集群切换到镜像集群需要手动完成。那么为什么这种解决方案中没有了见证节点呢？
因为数据库镜像和故障转移集群都拥有自动故障转移的特性，如果两种技术的自动切换都生效的话，那么在主体集群的活动节点失效后就会有两个节点同时试图生效——主体集群的后备节点和镜像集群的活动节点，那么结果就只有一个，数据库镜像会话失败。下图提供一个SharePoint 数据库故障转移的架构图，来自于MPP，
经过多次重试操作SharePoint无法联系主要SQL服务器时。SharePoint将会 - 将会在故障转移时自动尝试连接到同一数据库数据库服务器。
- AlwaysOn
AlwaysOn的数据同步原理
像数据库镜像技术一样，AlwaysOn会在各个副本上都维护一套数据副本。主副本上发生的数据变化，会同步到辅助副本上。所以和镜像一样，AlwaysOn也要完成三件事：
1．把主副本上发生的数据变化记录下来。
2．把这些记录传输到各个辅助副本。
3．把数据变化在辅助副本上同样完成一遍。
- 基本架构
在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。
可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。
因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：
一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。
一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。
如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。
一个数据库只能属于一个可用性组。
AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。
本文核心内容不是Alwayson 如有疑问或不明白的地方，请参考其他资料，下图依然是SharePoint 结合Alwayson 实现高可用的架构图。
- 日志传送（Log shipping for HA）
SQL Server 使用日志传送，您可以自动将“主服务器”实例上“主数据库”内的事务日志备份发送到单独“辅助服务器”实例上的一个或多个“辅助数据库”。 事务日志备份分别应用于每个辅助数据库。 可选的第三个服务器实例（称为“监视服务器”）记录备份和还原操作的历史记录及状态，还可以在无法按计划执行这些操作时引发警报。
- 优点
为单个主数据库以及一个或多个辅助数据库（每个数据库都位于单独的 SQL Server 实例上）提供灾难恢复解决方案。
支持对辅助数据库的受限的只读访问权限（在还原作业之间的间隔期间）。
允许用户将延迟时间定义为：从主服务器备份主数据库日志到辅助服务器必须还原（应用）日志备份之间的时间。 例如，如果主数据库上的数据被意外更改，则较长的延迟会很有用。 如果很快发现意外更改，则通过延迟，您可以在辅助数据库反映此更改之前从其中检索仍未更改的数据。
SharePoint 利用Log Shipping做高可用架构。图片来自MPP
下表是SharePoint数据库支持的高可用技术。
