二.背景（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可以實時的､第一時間切換到其他服務器上來繼續提供服務｡真正的實現零時間的服務器切換,大大提高安全性,真正意義的實現服務器不間斷服

Measure

Measure

總結

以上是生活随笔為你收集整理的SQL Server第三方负载均衡方案 ----Moebius测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。