SQL Server 数据库服务器的负载均衡C

《SQL Server 数据库服务器的负载均衡C》由会员分享，可在线阅读，更多相关《SQL Server 数据库服务器的负载均衡C（4页珍藏版）》请在金锄头文库上搜索。

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

2、le的负载均衡机制。下面，我们先简 单了解Oracle的负载均衡的实现方案。Real Application Clusters 是并行服务器(8i 及以前版本称作 Oracle Parallel Server，OPS),用来在集群环境下实现多机共享数据库，以保证应用的高可用性， 同时可以自动实现并行处理及均分负载，还能实现数据库在故障时的排 错和无 断点恢复。它可以自动进行负载平衡、故障修复和规划停机时间，以支持高可用 性应用程序。若并行服务器中某节点失效，透明的应用程序容错能够把用户自 动 转接到另一节点上继续运行，应用程序在用户没有察觉的情况下继续执行。这使 周期性和非周期性发生故障的系统

3、增大了连续可用性。进程的失效可以完全透明 地 转移到另一节点上去，通过适当地配置，可以指定所有查询都在客户端进行 缓存，这样它们便可以在转移后的节点上重新设置。那么在SQL Server平台上 是否也可以实现类似的效果？1、集群的分类 一般来讲，集群软件根据侧重的方向和试图解决的问题，分为三大类：高性能集 群(High performance cluster, HPC)、负载均衡集群(Load balance cluster, LBC)，高可用性集群(High availability cluster, HAC)。高性能集群(High performance cluster, HPC)，它是利

4、用一个集群中的多台 机器共同完成同一件任务，使得完成任务的速度和可靠性都远远高于单机运行的 效果。弥补了单机性能上的 不足。该集群在天气预报、环境监控等数据量大， 计算复杂的环境中应用比较多；负载均衡集群(Load balance cluster, LBC)，它是利用一个集群中的多台单 机，完成许多并行的小的工作。一般情况下，如果一个应用使用的人多了，那么 用户请求的响应时间就会增大，机器的性能 也会受到影响，如果使用负载均衡 集群，那么集群中任意一台机器都能响应用户的请求，这样集群就会在用户发出 服务请求之后，选择当时负载最小，能够提供最好 的服务的这台机器来接受请 求并相应，这样就可用用集

5、群来增加系统的可用性和稳定性。这类集群在网站中 使用较多；高可用性集群(High availability cluster, HAC)，它是利用集群中系统的 冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来 启动服务，等待故障机的维修和返回。最大限度的保证集群中服务的可用性。这 类 系统一般在银行，电信服务这类对系统可靠性有高的要求的领域有着广泛的 应用。2、Microsoft Cluster Server(MSCS) 相对于单点来说 Microsoft ClusterServer(MSCS)是一个可以提升可用性的技术，不可以负载均衡的，Microsoft称 之为故障转移

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

7、照镜像是 SQL Server 2005 中的一个主要特点，目的是为了提高可用性，同时和 MSCS相比，用户实现SQL Server的高可用更容易了，不需要共享磁盘柜，也不 受地域的限制。共设了三个服务器，第一是工作数据库(Principal Datebase)， 第二个是镜像数据库(Mirror)，第三个是监视服务器(Wi tn ess Server)在可用性方面有了一些保证，但仍然是单点工作；在扩展和性能的提升上依旧没 有什么帮助。数据库快照是SQL Server 2005中引入的另一项特性。快照是某一个时间点上的 数据库的克隆。只要对镜像数据库进行了快照，就可以让用户查询快照。快照的 生

8、成通常只需要几秒钟，因 为它实际上在这个过程中并没有拷贝任何数据。因 此，要把负载分布到主服务器和备用服务器上，就可以将数据库做镜像，然后阶 段性地对备份服务器进行快照。而 且还可以使用快照在主服务器上进行报告。 尽管快照是可以为一些静态系统的提供查询，如报表业务等， 但是由于是快照， 实时性就非常差，所以在使用上大大受到限制。4、复制、订阅我们知道，SQL Server提供了复制技术(Replication)，可以有多个只读服务 器供查询用，这个技术可以有效缓解查询的压力。我们知道，复制、订阅是一个 读写分离的技 术，数据先写到中心数据库上，写成功即返回给应用程序；通过 复制将数据复制到只读

9、的服务器，查询的时候从只读服务器查。sDB1Central DB负共为堂努客户瑞T写操佯DBt QB2.DB3中存有网林的数据 言户崔折匀的曲诧*注竜中读戢.实理T读的炎裁均衡这就意味着订阅端的数据和中心数据库的数据不同步，是个异步的过程，所以数 据滞后严重，数据同步的实时性得不到保障，中心数据库在正常的压力下 10 秒 左右。当访问负荷很高或者中心数据库在整理数据时，将出现大量 DML 操作时延 迟时间比较长或者出现堵塞的情况；某些修改操作需要重新建立复制关系并初始化，这期间需要停止数据库的读取服 务，规模越大的应用停止的时间越长，严重影响了数据库的可用性。 另外中心 数据库所采用的结构还是

10、MSCS，只是提供了一种故障转移的机制，当有一个节 点出现问题后把负载转移到另一个节点上；结 论：从上面可以看出，在 MS-SQL Server 平台上没有提供类似 Oracle RAC 的技术，实现不了负载均衡。数据库的高并发及横向扩展是用户经常遇到的问题， 所以好多SQL Server用户遇到这样的困惑时就移植到Oracle平台上，采用RAC 来解决。这将是一个即费财力又费物力、人力，同时还要面临很大风险的一个艰 难过 程。所以说在MS-SQL Server平台上实现像Oracle RAC 一样高性能、高可用性和方 便扩展的集群解就成广大 SQL Server 用户期待的一个焦点，就目前来说，这类 技术似乎只能在在一些专业研究第三方数据库集群的公司看到。