大數據時代下的SQL Server第三方負載均衡方案----Moebius測試

一.本文所涉及的內容（Contents）

1. 本文所涉及的內容（Contents）
2. 背景（Contexts）
3. 架構原理（Architecture）
4. 測試環境（Environment）
5. 安裝Moebius（Install）
6. Moebius測試（Testing）
1. 負載均衡測試（Load Balancing Testing）
2. 高可用性測試（Failover Testing）
3. 數據安全性測試（Security Testing）
7. 總結（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壓力測試）

　　獲得的結果如Figure九、Figure10所示，從圖能夠看到：負載基本被平均分配到兩臺服務器（因爲測試工具每一個查詢都會附上Set Statistics IO On和Time On，所以負載應該爲100個線程*10次循環*2）。

（Figure9：Profiler跟蹤信息）

（Figure10：Profiler跟蹤信息）

　　由Figure九、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中從新聯機，如Figure1四、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的大公司來講價值就很是大了，有機會我再進行復雜一些的測試。