SQL Server 2005实现负载均衡

前言
Internet的规模每一百天就会增长一倍，客户希望获得7天×24小时的不间断可用性及较快的系统反应时间，而不愿屡次看到某个站点“Server Too Busy”及频繁的系统故障。
随着业务量的提高,以及访问量和数据流量的快速增长，网络各个核心部分的处理性能和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，必将造成现有资源的浪费，而且下一次业务量的提升，又将导致再一次硬件升级的高额成本投入。于是，负载均衡机制应运而生。

ORACLE的“RAC”启示
对于负载均衡，笔者经常接触的当属Oracle的负载均衡机制。下面，我们先简单了解Oracle的负载均衡的实现方案。
Real Application Clusters是并行服务器(8i及以前版本称作Oracle Parallel Server，OPS)，用来在集群环境下实现多机共享数据库，以保证应用的高可用性，同时可以自动实现并行处理及均分负载，还能实现数据库在故障时的排错和无断点恢复。它可以自动进行负载平衡、故障修复和规划停机时间，以支持高可用性应用程序。若并行服务器中某节点失效，透明的应用程序容错能够把用户自动转接到另一节点上继续运行，应用程序在用户没有察觉的情况下继续执行。这使周期性和非周期性发生故障的系统增大了连续可用性。进程的失效可以完全透明地转移到另一节点上去，通过适当地配置，可以指定所有查询都在客户端进行缓存，这样它们便可以在转移后的节点上重新设置。那么在SQL Server平台上是否也可以实现类似的效果？

1、集群的分类
一般来讲，集群软件根据侧重的方向和试图解决的问题，分为三大类：高性能集群（High performance cluster，HPC）、负载均衡集群（Load balance cluster， LBC），高可用性集群（High availability cluster，HAC）。
高性能集群（High performance cluster，HPC），它是利用一个集群中的多台机器共同完成同一件任务，使得完成任务的速度和可靠性都远远高于单机运行的效果。弥补了单机性能上的不足。该集群在天气预报、环境监控等数据量大，计算复杂的环境中应用比较多；
负载均衡集群（Load balance cluster， LBC），它是利用一个集群中的多台单机，完成许多并行的小的工作。一般情况下，如果一个应用使用的人多了，那么用户请求的响应时间就会增大，机器的性能也会受到影响，如果使用负载均衡集群，那么集群中任意一台机器都能响应用户的请求，这样集群就会在用户发出服务请求之后，选择当时负载最小，能够提供最好的服务的这台机器来接受请求并相应，这样就可用用集群来增加系统的可用性和稳定性。这类集群在网站中使用较多；
高可用性集群（High availability cluster，HAC），它是利用集群中系统 的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务，等待故障机的维修和返回。最大限度的保证集群中服务的可用性。这类系统一般在银行，电信服务这类对系统可靠性有高的要求的领域有着广泛的应用。

2、Microsoft Cluster Server(MSCS)相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，不可以负载均衡的，Microsoft称之为故障转移集群。(属于高可用集群共享磁盘架构)

从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。当现有的机器不能满足应用的负载时只能更换更高配置的机器。
升级到综合性能更强大的硬件，带来的问题是硬件的浪费，然而，单节点体系结构最终会达到一个瓶颈并无法实现进一步的有效扩展。具体表现为逐渐缩小的回报率或者价格惊人的昂贵硬件设备，系统得不到可持续的扩展。

3、SQL Server 2005镜像和快照
镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性，同时和MSCS相比，用户实现SQL Server的高可用更容易了，不需要共享磁盘柜，也不受地域的限制。共设了三个服务器，第一是工作数据库（Principal Datebase），第二个是镜像数据库（Mirror），第三个是监视服务器（Witness Server）

 

在可用性方面有了一些保证，但仍然是单点工作；在扩展和性能的提升上依旧没有什么帮助。
数据库快照是SQL Server 2005中引入的另一项特性。快照是某一个时间点上的数据库的克隆。只要对镜像数据库进行了快照，就可以让用户查询快照。快照的生成通常只需要几秒钟，因为它实际上在这个过程中并没有拷贝任何数据。因此，要把负载分布到主服务器和备用服务器上，就可以将数据库做镜像，然后阶段性地对备份服务器进行快照。而且还可以使用快照在主服务器上进行报告。
尽管快照是可以为一些静态系统的提供查询，如报表业务等， 但是由于是快照，实时性就非常差，所以在使用上大大受到限制。

4、复制、订阅
我们知道，SQL Server 提供了复制技术（Replication），可以有多个只读服务器供查询用，这个技术可以有效缓解查询的压力。我们知道，复制、订阅是一个读写分离的技术，数据先写到中心数据库上，写成功即返回给应用程序；通过复制将数据复制到只读的服务器，查询的时候从只读服务器查。

 

这就意味着订阅端的数据和中心数据库的数据不同步，是个异步的过程，所以数据滞后严重，数据同步的实时性得不到保障，中心数据库在正常的压力下10秒左右。当访问负荷很高或者中心数据库在整理数据时，将出现大量DML操作时延迟时间比较长或者出现堵塞的情况；
某些修改操作需要重新建立复制关系并初始化，这期间需要停止数据库的读取服务，规模越大的应用停止的时间越长，严重影响了数据库的可用性。 另外中心数据库所采用的结构还是MSCS，只是提供了一种故障转移的机制，当有一个节点出现问题后把负载转移到另一个节点上；
结论：从上面可以看出，在MS-SQL Server 平台上没有提供类似Oracle RAC的技术，实现不了负载均衡。数据库的高并发及横向扩展是用户经常遇到的问题，所以好多SQL Server用户遇到这样的困惑时就移植到Oracle平台上，采用RAC来解决。这将是一个即费财力又费物力、人力，同时还要面临很大风险的一个艰难过程。
所以说在MS-SQL Server平台上实现像Oracle RAC一样高性能、高可用性和方便扩展的集群解就成广大SQL Server用户期待的一个焦点，就目前来说，这类技术似乎只能在在一些专业研究第三方数据库集群的公司看到。