SharePoint 2010的高可用性（HA）

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

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

SharePoint服务器场本身是一个典型的三层架构（从2007、到2010、再到2013，这个基本的架构都是一样的），也就是前端服务器 - 应用服务器 - 数据库服务器（在一些小型部署中，前端服务器往往同时充当了应用服务器的角色、甚至同时充当了数据库服务器的角色）。因此，在高可用性方便，也必须同时考虑到这三个层面。

首先，前端服务器。

前端服务器的高可用性其实是这三层里面最容易的了，因为前端服务器上只有程序、配置文件和一些模版文件，所有的“实际”数据都存放在最后端的数据库中。因此在前端服务器一层，只需要保证所有的自定义程序都是一致的（这也是用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）

4、混合模式

对于要求更高的需求而言，可以把上面三种方式混合使用：比如群集的同时再做镜像，或者同时通过Log Shipping的方式实现异地部署的灾备方案等等。

参考资料：

1、存储和SQL Server容量规划和配置（http://technet.microsoft.com/zh-cn/library/cc298801）

2、规划可用性（http://technet.microsoft.com/zh-cn/library/cc748824）

3、规划灾难恢复（http://technet.microsoft.com/zh-cn/library/ff628971）

4、规划RBS（http://technet.microsoft.com/zh-cn/library/ff628583）

5、《SharePoint 2010 Disaster Recovery Guide》，这本书对各个方面都写的很详细，包括配置的步骤等等，如果有需要的话可以细读一下。（我不会告诉你网上可以搜到电子版的）