一.本文所涉及的内容（Contents）
- 本文所涉及的内容（Contents）
- 背景（Contexts）
- 架构原理（Architecture）
- 测试环境（Environment）
- 安装Moebius（Install）
- Moebius测试（Testing）
- 总结（Summary）
二.背景（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的大公司来说价值就非常大了，有机会我再进行复杂一些的测试。
