数据库负载均衡集群解决方案.docx

数据库负载均衡集群解决方案.docx

《数据库负载均衡集群解决方案.docx》由会员分享，可在线阅读，更多相关《数据库负载均衡集群解决方案.docx（12页珍藏版）》请在冰豆网上搜索。

数据库负载均衡集群解决方案

双节点数据库负载均衡解决方案

问题的提出？

　　在SQLServer数据库平台上，企业的数据库系统存在的形式主要有单机模式和集群模式（为了保证数据库的可用性或实现备份）如：

失败转移集群（MSCS）、镜像（Mirror）、第三方的高可用（HA）集群或备份软件等。

伴随着企业的发展，企业的数据量和访问量也会迅猛增加，此时数据库就会面临很大的负载和压力，意味着数据库会成为整个信息系统的瓶颈。

这些“集群”技术能解决这类问题吗？

SQLServer数据库上传统的集群技术

MicrosoftClusterServer（MSCS）

　　相对于单点来说MicrosoftClusterServer（MSCS）是一个可以提升可用性的技术，属于高可用集群，Microsoft称之为失败转移集群。

MSCS

　　从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQLServer数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；

　　因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。

当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。

Mirror

　　镜像是SQLServer2005中的一个主要特点，目的是为了提高可用性，和MSCS相比，用户实现数据库的高可用更容易了，不需要共享磁盘柜，也不受地域的限制。

共设了三个服务器，第一是工作数据库（PrincipalDatebase），第二个是镜像数据库（Mirror），第三个是监视服务器（WitnessServer，在可用性方面有了一些保证，但仍然是单服务器工作；在扩展和性能的提升上依旧没有什么帮助。

Mirror

结论：

在SQLServer数据库平台上，用户遇到性能瓶颈只能更换更高配置的服务器，如果用户搭建了镜像、失败转移集群或其它HA集群，则要同时更换两台更大的服务器。

这种扩展方式称为向上扩展，即向单一节点添加硬件设备或将其升级为一个大型节点，然而升级到综合性能更强大的硬件，带来的问题是硬件的浪费，单节点体系结构最终会达到一个瓶颈并无法实现进一步的有效扩展。

具体表现为逐渐缩小的回报率或者价格惊人的昂贵硬件设备，系统得不到可持续的扩展。

Moebius集群解决方案

　　Moebius集群是融合数据库的负载均衡、高可用于一体的综合集群解决方案，在Moebius集群中，两个数据库是同等地位的，都是可读写的，Moebius中间件保证两个节点中数据实时一致性。

Moebius双节点集群

功能对比

价值所在

∙实现两个节点同时提供服务，而且相互之间可以负载均衡，显著提升数据库的性能，提高设备利用率。

同时Moebius集群提供故障检测及自动故障转移，保证了系统的可用性。

冗余的数据结构可以保证数据的安全。

∙在原有系统上升级，充分利用企业原有设备，总体拥有成本（TCO）低。

∙可以充分利用现有设备组建集群，Moebius支持无共享磁盘架构，节约成本。

∙HA集群中，随着服务器配置的增加，设备的浪费越严重，Moebius集群可以提升设备的利用率。

∙可持续发展的架构，方便扩展，随着系统压力的增长只需简单增加服务器的数量就可以了，不需要升级现有系统的硬件配置，不需要改动应用程序。

横向多节点数据库负载均衡解决方案

问题的提出？

　　对于一些企业级的应用系统，数据库的访问量比较大，为了实现系统的快速响应，用户往往会选择一些高配置的服务器如小型机；为了保证数据库系统的可用性，还要搭建高可用集群（失败转移集群、镜像或其他的高可用集群），这样的设计将会带来高额的硬件投入，与此同时设备的利用率却很低，而且系统也得不到持续扩展。

那如何方便地解决用户所遇到的数据库高性能、高可伸缩性与低价格之间的矛盾呢？

传统的一些解决办法

更改业务系统，人工分拆业务、分拆数据库

　　在这样的应用背景下，用户通过对应用程序的更改，将一个统一的业务拆分成多个并行的业务系统，进而数据库也拆分成多个并行的数据库，达到化整为零的目的。

业务分拆

　　通过分拆，实现了扩展，但是，这样的调整是非常有限的，仅仅限于用户自己开发的系统或者允许更改的应用系统，对于一些软件产品则无法更改；这样的操作将给数据库管理人员、开发人员带来非常大的麻烦，实现起来不透明，要经常更改应用程序的代码。

数据库迁移

　　在这样的应用背景下，一些SQLServer用户甚至选择移植到其它数据库平台上，如采用Oracle’RAC（可以实现数据库的负载均衡）来解决此类问题，大家都知道，这将是一个即费财力又费物力、人力，同时还要面临很大风险的一个艰难过程。

数据库迁移

Moebius集群解决方案

　　采用MoebiusforSQLServer企业版或高级版构通过多个中小服务器构建集群，取代单个大型服务器，在实现数据库负载均衡、横向扩展及高可用的同时节约大量的成本。

Moebius多节点集群

价值所在

∙通过几台服务器构建集群，不但实现了数据库的负载均衡、数据库的高可用，而且实现了数据库的持续扩展，为企业提供了一个稳健的数据库平台。

∙用户无需采购价格高昂的大型服务器，利用Moebius集群软件，可以用几个廉价的PC服务器组建数据库集群，实现优于单个大型服务器的综合性能，节约投资（几个PC服务器的综合性能>>单个大型服务器）。

∙可以充分利用现有设备组建集群，Moebius支持无共享磁盘架构，节约成本。

∙HA集群中，随着服务器配置的增加，设备的浪费越严重，Moebius集群可以提升设备的利用率。

∙可持续发展的架构，方便扩展，随着系统压力的增长只需要添加进新的机器就可以了，不需要升级现有系统的硬件配置，不需要改动应用程序。

数据实时复制解决方案

问题的提出？

　　经过分析，大多数应用系统以查询操作为主，造成数据库压力迅速增加的主要因素也是复杂的查询操作，为了能够得到同一份数据的多个副本来响应用户的查询，SQLServer提供了复制技术（Replication），主要有合并复制、事务复制、快照复制等，这些技术可以有效缓解查询的压力。

伴随着企业发展的需要，企业对信息实时性要求越来越高，如股票、航空票务、连锁店甚至是一些服务系统等等，这些系统的用户希望更新的数据马上就可以查询到，那SQLServer提供的复制技术能够很好地解决这些问题吗？

SQLServer数据库的复制/订阅技术

　　复制/订阅数技术可以实现读、写分离，数据先写到中心数据库上，写成功即返回给应用程序；通过复制将数据复制到只读服务器，查询时从只读服务器查。

复制/订阅

　　这就意味着订阅端的数据和中心数据库的数据不同步，是个异步的过程，所以数据滞后严重，数据同步的实时性得不到保障，中心数据库在正常的压力下10秒左右。

当访问负荷很高或者中心数据库在整理数据时，将出现大量DML操作延迟时间比较长或者出现堵塞的情况；

　　某些修改操作需要重新建立复制关系并初始化，这期间需要停止数据库的读取服务，规模越大的应用停止的时间越长，严重影响了数据库的可用性。

结论：

复制订阅技术的实时性差，初始化时对系统的影响非常大；在数据复制过程中没有采用智能的策略，数据的复制速度慢；中心数据库仍然为失败转移集群模式。

Moebius实时复制技术

　　Moebius构建的数据库集群中，节点间数据同步都是实时的，数据是一致性的，可以部署为读、写分离，也可以部署为所有节点可读可写；Moebius中间件监测到数据库变化并同步数据，数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。

Moebius中间件在同步数据时采用了多项智能同步策略，满足了不同类型的应用模式，可以同步数据，同步SQL语句，并行执行SQL语句，升级数据库的锁，启用数据压缩等。

更多关于Moebius中间件同步策略，请参见帮助文档

Moebius实时复制

价值所在

∙同步过程是在SQLServer的执行环境中进行的，整个操作是在事务的环境下完成的，解决了数据实时性问题，满足了用户对数据实时性的要求。

∙Moebius中间件在同步数据时采取了智能同步策略，同步速度更快；提供了多种人工干预的机制，对数据库表结构的调整、批量更改数据等操的时间大幅缩减。

∙无需搭建失败转移集群，中心数据库Cluster中闲置的一台机器被利用起来，提高了整个系统的使用率；系统支持无共享磁盘架构，可以节省共享的存储设备。

∙连接数据库，提供专门针对数据库系统的负载均衡软件，无需使用昂贵的均衡硬件，无需程序员自己实现。

∙提供故障检测及失败转移功能。

数据库实时灾备解决方案

问题的提出？

　　对重要的业务系统，除了保证核心数据不丢失，同时保证其能持续、可靠地提供服务是非常关键的。

传统备份解决方案往往是从存储角度出发，保证存储数据的安全性，不是专业针对数据库来解决，面临的问题是出现故障时，备用系统恢复速度及其缓慢，而且备用系统不能提供服务，硬件资源浪费非常严重。

Moebius实时灾备解决方案

　　Moebius实时灾备技术是专门针对数据库的应用而开发的，两个节点处于实时的工作状态，发生故障时，另一个节点是不需要重新恢复数据的，可以直接对外提供服务，极大地降低了停止服务所导致的损失，所以Moebius灾备方案是一种可以提供持续服务的容灾方案。

Moebius实时灾备

价值所在

∙保障关键的业务系统持续服务，支撑企业的运营；

∙针对数据库实现，采用SQLServer应用系统专属的复制引擎；

∙实时复制，达到“零丢失”的数据保护，实现“零窗口”备份；

∙实时同步,发生故障时无需恢复数据，目标系统直接处于运行状态，提高抗灾性；

∙对主备系统硬件一致性无要求，极大的降低系统投入成本。

∙备用系统可以提供服务，提升了设备的利用率。

大型分布式数据库解决方案

问题的提出？

　　企业数据库的数据量很大时候，即使服务器在没有任何压力的情况下，某些复杂的查询操作都会非常缓慢，影响最终用户的体验；当数据量很大的时候，对数据库的装载与导出，备份与恢复，结构的调整，索引的调整等都会让数据库停止服务或者高负荷运转很长时间，影响数据库的可用性和易管理性。

如大型网站、省级人口系统、大型考试系统、大型物流系统、游戏平台等等，涉及海量数据的系统。

微软提供了分区表、分布式分区视图、库表散列等，这些技术能很好的解决这类问题吗？

SQLServer数据库的一些数据分区技术

分区表技术

　　SQLServer2005引入的分区表技术，让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。

但是分区表只能把数据分散到同一机器的不同磁盘中，也就是还是依赖于一个机器的硬件资源，不能从根本上解决问题。

分区表

分布式分区视图

　　分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。

但是并没有简化分区数据集的管理、设计。

用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数据完整性约束，管理工作变得非常复杂。

而且还有一些限制，比如不能使用自增列，不能有大数据对象。

对于全局查询并不是并行计算，有时还不如不分区的响应快。

分布式分区视图

库表散列

　　一些大公司在开发基于库表散列的数据库架构，比如MySpace经过数次数据库升级，最终采用按照用户进行的库表散列，微软为MSN/Hotmail和纳斯达克开发的数据依赖型路由（Data-DependentRouting，DDR）。

但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。

客户在实际应用中要投入很大的研发成本，面临很大的风险。

Moebius集群解决方案

　　面对海量数据库在高并发的应用环境下，仅仅靠提升服务器的硬件配置是不能从根本上解决问题的，Moebius分布式网格集群通过数据分区把数据拆分成更小的部分，分配到不同的服务器中。

查询可以由多个服务器上的CPU、I/O来共同负载，通过各节点并行处理数据来提高性能；写入时，可以在多个分区数据库中并行写入，显著提升数据库的写入速度。

Moebius分布式网格集群

价值所在

∙通过分区把数据放到不同的机器中，每次查询可以由多个机器上的CPU,I/O来共同负载，通过各节点并行处理数据来提高性能。

∙冗余的数据结构（矩阵列）消除了单点故障，任何一个机器出现故障后都不会影响系统的正常

运行，数据库集群能提供不中断的服务。

∙无共享磁盘架构节省了硬件，利用中小型的服务器取代大型服务器大幅降低了硬件的成本，系统中不再有闲置的资源，降低了系统TCO（总体拥有成本）。

∙分区把数据分成更小的部分，提高了数据库的可用性和可管理性。

∙根据业务的需要，访问层和数据层都可以增加，Moebius集群具有良好的扩展性。

∙中间件宿主在数据库中的创新使集群变得更透明，数据库的管理成本，以及面向数据库的开发成本都最小化。