- 本文所涉及的内容（Contents）
- 背景（Contexts）
- 架构原理（Architecture）
- 测试环境（Environment）
- 安装Moebius（Install）
- Moebius测试（Testing）
二.背景（Contexts）
前几天在SQL Server MVP宋大侠（宋沄剑）的一篇文章"数据库集群技术漫谈”中看到了格瑞趋势在SQL Server上的负载均衡产品Moebius，搞数据库的都知道：在Oracle上有RAC，MySQL也有对应的方案（可参考：MySQL搭建Amoeba系列），而SQL Server上直到SQL Server 2012版本的AlwaysOn到来，微软都没有提供一个负载均衡方案，我从宋大侠那里找来一个Moebius的测试版本进行一下测试，下面是我测试的过程。
三.架构原理（Architecture）
（Figure1：Moebius for SQL Server逻辑架构图）
四.测试环境（Environment）
操作系统：Windows Server 2008 R2
数据库版本：SQL Server 2012
服务器A：10.0.0.1
服务器B：10.0.0.2
虚拟IP：10.0.0.15
五.安装Moebius（Install）
Moebius的安装非常简便，在装有SQL Server引擎的服务器上直接点击安装包进行安装，安装过程中一直下一步即可。在此就不再多说。
在此交待一下我的测试环境，是两台虚拟机，IP分别为10.0.0.1和10.0.0.2，操作系统和SQL Server的版本分别为Windows Server 2012和SQL Server 2012。安装完成后在Management Studio管理工具中右击数据库，在弹出菜单中即可找到Moebius的菜单，如Figure2所示。
（Figure2：Moebius for SQL Server 2012）
安装完成后，打开配置管理器界面，如Figure3所示。
（Figure3：Moebius for SQL Server 2012）
分别将10.0.0.1和10.0.0.2这两台服务器加入集群，这里可以注意到，Moebius是以数据库为粒度的，相比实例而言，该种粒度会更加灵活，如Figure4所示。
（Figure4：设置数据库）
将10.0.0.1和10.0.0.2两台服务器的数据库分别加入集群后，建立虚拟IP和端口，建立的虚拟IP为10.0.0.15，端口为5000，之后所有前端应用的连接就可以通过该虚拟IP进行了，完全不需要理会后端的架构，可以让前端与后端解耦，如Figure5和Figure6所示。
（Figure5：设置虚拟IP）
（Figure6：设置连接属性）
建立完成后，集群就配置好了，效果如Figure7所示。
（Figure7：Moebius for SQL Server 2012）
六.Moebius测试（Testing）
(一).负载均衡测试（Load Balancing Testing）
集群的搭建完成后，就可以开始对集群进行测试。首先是负载均衡测试。负载均衡的测试办法是使用压力测试工具，然后分别查看两个实例的Profiler，根据我咨询宋沄剑的说法是，负载均衡的算法是默认根据两台服务器的过去一段时间采集的性能指标进行分析，优先将查询导到负载低的服务器中，但集群刚搭建的时候没有历史数据，则按照平均分配的原则。下面是我使用SQLQueryStress进行负载均衡测试的结果，如Figure8所示。我开了100个线程，每个线程循环10次，来进行一个非常简单的查询。
（Figure8：SQLQueryStress压力测试）
得到的结果如Figure9、Figure10所示，从图可以看到：负载基本被平均分配到两台服务器（由于测试工具每个查询都会附上Set Statistics IO On和Time On，因此负载应该为100个线程*10次循环*2）。
（Figure9：Profiler跟踪信息）
（Figure10：Profiler跟踪信息）
由Figure9、Figure10大概可以看出：负载基本被平均分配到集群中的两台服务器中。
(二).高可用性测试（Failover Testing）
接下来就是测试高可用性。高可用的测试我主要集中于故障转移切换的速度。首先，我开100个线程，每个线程循环20次，在集群上运行负载均衡，如Figure11所示。
（Figure11：SQLQueryStress）
Figure11大概执行了20秒，此时我再次执行，并在执行过程中，强制关闭集群中10.0.0.1的SQL Server服务，运行结果如Figure12所示。
（Figure12：SQLQueryStress）
我们看到，已经发送到到10.0.0.1服务器的部分事务给前端应用程序提示失败并回滚，除去停止服务所花的时间，以及所有的查询由10.0.0.1和10.0.0.2负载均衡执行，到仅仅只剩下10.0.0.2单独执行所花的时间，故障转移的切换时间在10秒以内，这个速度已经和SQL Server的镜像几乎持平了。
此时，再来看Moebius集群管理器，就发现10.0.0.1服务器已经被集群脱机，且虚拟IP已经漂移到了10.0.0.2，如Figure13所示。
（Figure13：Moebius for SQL Server 2012）
(三).数据安全性测试（Security Testing）
在Figure13描述的情况之后，此时只有10.0.0.2一台服务器处于活的状态 ，因为Moebius采用的是Share-Nothing架构，因此应该可以利用冗余数据防止数据丢失，从而保证了数据安全。此时我在10.0.0.2上新建立一张表Demo。并重新启动10.0.0.1的数据库服务，在Moebius中重新联机，如Figure14、Figure15所示。
（Figure14：Moebius for SQL Server 2012）
（Figure15：Moebius for SQL Server 2012）
在联机的过程中，有一个恢复差异数据的步骤，联机完成后我们来看10.0.0.1数据库，Demo表已经咋恢复差异数据的时候被自动同步了，如Figure16所示。
（Figure16：Demo表）
七.小结（Summary）
通过上面对Moebius的简单测试来看，Moebius的确实现了对SQL Server的负载均衡、高可用以及保证数据的安全。对于国内能够有公司实现类似Oracle RAC这样的负载均衡方案还是让我非常惊讶的，如果该结果在复杂的数据库环境下依然能够保持同样的结果，那么这个方案对于使用SQL Server的大公司来说价值就非常大了，有机会我再进行复杂一些的测试。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL Server几乎能在所有的系统和平台中进行数据的处理，作为最为普及的数据处理软件之一。那么，关于它的负载均衡问题我们也应该掌握好。那么对于这个问题，下文就将为大家详细介绍一下。望大家能对此部分的知识内容能有所了解。
然而,长期以来,SQL Server数据库服务器都只有“热备"的解决方案,而没有“负载均衡" 和“集群"的解决方案｡这种解决方案固然提升了系统的可靠性,但也存在一些问题:
◆面对大数据量和大量的数据库查询请求,只能采取纵向提升服务器档次的方法,而纵向提升的成本远远高于横向扩展｡
◆在热备时,数据库服务器只有一台在工作,另一台处于闲置备份的状态,造成了投资的浪费｡
◆非实时切换｡
而数据库路由器软件ICX的出现,为基于MS SQL Server的数据库系统提供了一种更优秀的集群解决方案｡它可以真正的实现SQL Server数据库服务器的动态负载均衡,提高性能和速度;它可以真正的保证SQL Server数据库服务器不间断的提供服务,在服务器发生故障的时候实时切换到其他服务器上继续提供服务,切换时间为“零"｡
数据库路由器是实时并发数据库事务处理同步复制器和负载平衡器｡
数据库路由器--ICX(意思是:I SEE X DATABASE SERVERS),也就是说,在ICX后面可以同时连接N个数据库,结构如下图所示:
1.所有的数据库客户都通过ICX访问数据库｡当访问､查询SQL Server数据库的时候ICX可以根据实际情况分配服务器来提供服务,大大提高服务速度和优化性能,完成负载均衡｡
2.ICX可以同时连接多台数据库(2-16台,具体连多少台,看客户的具体需求而定),这若干台数据库的内容在任何时刻由ICX保证是完全一致的｡也就是说,ICX采用了全新的并发事务处理的方式,向连接的N台数据库同步复制事务处理,使得系统在任何时刻具有多个一致的最新逻辑数据库数据集｡当其中一台数据库服务器发生故障的时候,ICX可以实时的､第一时间切换到其他服务器上来继续提供服务｡真正的实现零时间的服务器切换,大大提高安全性,真正意义的实现服务器不间断服
