Moebius For SQL Server负载均衡集群解决方案.docx

Moebius集群解决方案 在数据库上采用向外扩展的架构并不是没有难度的，如何在数据库上构建负载均衡集群，如何用低消耗保证集群中各节点数据的实时同步？能否解决这一个问题成为集群应用成功的关键。 Moebius 核心理念和价值恰恰就在此处，核心程序宿主在SQL Server内部，监测数据的变化，同时还要解析引起数据变化的SQL语句的类型及其特点，经智能分析后，以最经济的方式完成与其他节点的数据同步。 解决方案一：评价: 此一解决方案，集群不是instance-level的，应该是通过client的DP layer增加dispatcher来实现的，然后在两个宿主DB instance之间进行同步。 “数据同步完成后客户端才会得到响应”，这样的performance和原来比较是什么样的？例如：client的写请求被dispatch到 node1，因为没有shared storage，node1写完之后将同步到node2，node2同样要处理这些写请求，其实并没有load balance，而是load duplicate。 当然，对于读操作，的确是load balance了，而实际上是以写操作load duplicate为代价的。 如果您正在使用或者将要安装使用SQL Server Cluster 、SQL Server2005 Mirror或第三方的HA集群软件实现失败转移，保证数据库的可用性。推荐您阅读解决方案一。SQL Server Cluster 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，Microsoft称之为故障转移集群。 从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份： 1. 因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。2. 当现有的机器不能满足应用的负载时只能更换更高配置的机器。3. 对于一个小型的应用来说，使用一个共享设备和一个在正常情况下用不到的机器， 总体成本的浪费还是很严重的。从细节上讲，当一个节点出现故障的时候，另一个节点接管业务又是需要一定的步骤和时间。SQL Server2005 Mirror 镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性。每个数据库镜像配置均包含一个主体服务器（包含主体数据库）、一个镜像服务器（包含镜像数据库）和一个 见证服务器（可选）。主体服务器和镜像服务器要求是独立的服务器实例。见证服务器监视主体服务器和镜像服务器，确保在给定的时间内这两个故障转移服务器中 有且只有一个作为主体服务器，从而支持自动故障转移。 SQL Server2005 Mirror在可用性方面有了一些保证，但仍然是单点工作； 在扩展和性能的提升上依旧没有什么帮助。Moebius集群解决方案: 采用Moebius For SQL Server 标准版搭建集群，集群中两个数据库是同等地位的，中间件驻留在每个机器的数据库中，监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完 成后客户端才会得到响应，同步过程是并发完成的，同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份 数据在任何时刻数据的一致性。 该方案能给您带来以下的益处： 1.在SQL Server Cluster中闲置的那台机器被利用上了，不仅能失败转移还能负载均衡，提高了性能。 2.使用无共享磁盘架构，数据存储在每台机器的硬盘中，因此可以节省投资。 3.无共享磁盘架构在日常的维护以及故障时的修复等管理成本比SQL Server Cluster要低。 4.可持续发展的架构，方便扩展，随着系统压力的增长只需要添加进新的机器就可以了，不需要升级现有系统的硬件配置，不需要改动应用程序。解决方案二：评价:此一种解决方案，同样的问题，读操作的load balance是以写操作的load翻倍为代价的 如果您现在使用的是基于 SQL Server复制/订阅的方案。推荐您阅读解决方案二。 如图，所有的写操作都提交到中心数据库上，然后通过 SQL Server 的复制/订阅功能把数据复制到其他几个只读的数据库中，这样可以做到读写的分离，并且读可以做到负载均衡。 SQL Server复制/订阅对于性能的提升还是很大的，但是在实际应用中存在以下不足： 1. 数据同步的实时性得不到保障，中心数据库在正常的压力下10秒左右。当访问负荷很高或者中心数 据库在整理数据时，将出现大量DML操作时延迟时间比较长或者出现堵塞的情况； 2. 某些修改操作需要重新建立复制关系并初始化，这期间需要停止数据库的读取服务，规模越大的应 用停止的时间越长，严重影响了数据库的可用性。 另外中心数据库所采用的结构还是MSCS，只是提 供了一种故障转移的机制，当有一个节点出现问题后把负载转移到另一个节点上； 3. 复制/订阅的管理维护的成本比较高。Moebius集群解决方案: 采用Moebius企业版搭建横向多节点的集群（若数据量大也可采用Moebius高级版搭建网格分布式数据集群）， 这种冗余的结构不但保证了数据库的可用性，而且可以提供高性能，随着压力的增加，只需增加节点就可以保证系统的服务。 1.操作是并发的，整个操作的响应时间和更新一个数据库的响应时间基本相同； 2.数据同步是基于语句的，在同步的过程中，中间件会智能的分析，采用数据压缩等手段来减少 网络的消耗。 3.整个操作是在事务的环境下完成的，是一个同步的过程，保障了多个数据库中的数据是一致的、 实时的。 Moebius应用程序读取数据时，可以任意从多个数据库中的一个中查找，进而很容易实现集群各节点间负载均衡。 该方案能给您带来以下的益处： 1解决了数据实时性的问题。 2在复制/订阅结构中的中心数据库Cluster中闲置的一台机器被利用起来提高了整个系统的使用率。 3节省了维护复制/订阅的管理成本。 4系统支持无共享的架构，数据可以存储在各自机器自己的硬盘中，因此可以节省下共享的存储设备。 5数据库结构修改时不需要重新初始化复制/订阅，提高了数据库的可用性。 6当系统出现性能问题时，只需简单增加节点就可以，方便扩展。解决方案三：评价: 第三种解决方案，从逻辑上来看，访问调度层充当了database instance的角色，负责所有的读写操作，并且可能还有distributed QO的逻辑，可是，访问调度层同样是系统的瓶颈，一旦该层出现问题，系统还是无法达到HA，如果保证该层的HA？ 当然，这种解决方案可以存储海量数据，对scalable OLTP是不错的，前提是如果在访问调度层实现了很好的Query Optimizer。 如果您的数据库规模很大， 正在考虑使用分区表，分区视图或者自己拆分业务逻辑做一些库表散列，推荐您阅读解决方案三。分区表 SQL Server 2005引入的分区表技术，让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。但是分区表只能把数据分 散到同一机器的不同磁盘中，也就是还是依赖于一个机器，不能从根本上解决问题。理想的解决办法是把数据分散到不同的机器中，通过多个机器上的 CPU,I/O的并行处理来提高性能。分布式分区视图 分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。但 是并没有简化分区数据集的管理、设计。用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数据完整性约 束，管理工作变得非常复杂。而且还有一些限制，比如不能使用自增列，不能有大数据对象。另外经过实际测试，对于符合分区规则的查询性能还可以，对于全局查 询并不像我们预期的那样，是并行计算，有时还不如不分区的响应快。库表散列 一些大公司也在自己开发基于库表散列的数据库架构，比如My Space经过数次数据库升级，最终采用按照用户进行的库表散列，微软为MSN/Hotmail和纳斯达克开发的数据依赖型路由(Data- Dependent Routing，DDR）。但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。客户在实际应用中要投入很大的研发成本，面临很大的风险。Moebius集群解决方案: 采用Moebius高级版搭建网格分布式数据库集群，利用一群廉价的PC服务器，构建综合性能超强的数据库集群，集群充分发挥每个机器的CPU、IO等资源。 该方案能给您带来以下的益处： 1.通过分区把数据放到不同的机器中，每次查询可以由多个机器上的CPU,I/O来共同负载，通过各节点并 行处理数据来提高性能。 2.冗余的数据结构（矩阵列）消除了单点故障，任何一个机器出现故障后都不会影响系统的正常运行，数据库集群能提供不中断的服务。 3