大資料時代下的SQL Server第三方負載均衡方案----Moebius測試
一.本文所涉及的內容（Contents）
二.背景（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的大公司來說價值就非常大了，有機會我再進行復雜一些的測試。