SQL Server 負載平衡架構介紹(Load Balancing)

        最近常常遇到有人問我，到底SQL Server的負載平衡(Load Balancing)要怎麼做，Cluster架好後為什麼另一台電腦都不能接收服務，我想在這一起問答給大家好了，也介紹一下我目前的作法給大家。首先我要強調一下，Cluster本身稱為容錯移轉叢集(Failover Cluster)，所以只有支援(Failover)，沒有支援Load Balancing (這個最多人問@_@)所以你會看到另外一台只能在那等著，不能進行服務，那到底Microsoft有沒有計劃推出這類所謂真的叢集架構(Real Cluster)呢，據我自已的推測與Microsoft的說法，因為Windows本身的架構設計，所以目前暫無計劃推出像Oracle的RAC機制，所以我想在SQL Server近期的二版本推出時，應該也不會包含，至少在SQL Server 2012(Denali)就暫時沒有，但就我目前服務客戶的情況下，其實大部份的效能瓶頸都是在I/O的部份，所以我想就算轉換到Oracle的RAC架構，好像也沒有太大的效果，當然詳細的說明大家還是可以參考下列的網址就會更清楚了。

Why SQL Server May Be More Suitable for You than Oracle RAC

http://download.microsoft.com/download/6/9/D/69D1FEA7-5B42-437A-B3BA-A4AD13E34EF6/WhyNotOracleRAC.docx

Oracle RAC架構圖：


SQL Server的負載平衡(Load Balancing)作法：目前在SQL Server上有三種作法可以達到負載平衡(Load Balancing)，我們就逐一的介紹：

1. Replication (複寫)
2. Log Shipping (日記檔傳送)
3. Database Mirroring (鏡射)

1、Replication(複寫)：我想這個功能是我認為目前最佳的負載平衡(Load Balancing)方案，在 Replication 中主要有三種方法，分別是，Snapshot、Transactional、Merge，基本上可以使用Merge與Transactional，因為Snapshot同步化資料時不會比對差異或是否有資料異動，所以不適合，而Merge是一個不錯的選擇方案，而且可以自動比對處理同步衝突，但因為資料比對時間過久，而且衝突排除有時候會失敗需手動排除，所以個人最推薦使用Transactional。

        Transactional Replication主要設定架構上有兩種，第一種是一台讀寫資料庫，其他台為唯讀，另一種為多台資料庫可同時讀寫，架構的選擇上主要看你的程式架構而定，假設你的資料庫中Primary Key使用了大量的流水號(IDENTITY)又同時使用在有Master與Detailed的表格時，就只能使用第一種架構，因為當資料庫將資料同步到另一台電腦時，因為流水號的重取，會造成另一台資料庫中的流水號不同步，所以使用第一種架構把Insert、Update與Delete移到第一台然後再同步到其他台，就可以完成而不需修改太多的程式，而程式只要調整將Select的部份指定到其他台即可達到負載平衡(Load Balancing)，而在第二種的架構上可以使用SQL Server 2005 推出的新架構 Peer-to-Peer Transactional Replication即可達成，而且效能與同步化的時間差絕對讓你滿意，此二種架構的同步時間也是目前所有架構中，同步時間最短的，只需約1~3秒(實際情況示網路架構與資料量而定，但保證是所有架構中最快的一種)內即可完資料的同步。

Peer-to-Peer Transactional Replication架構圖：





參考文章：SQL Server 分散式架構 - 點對點交易式複寫 + NLB

2、Log Shipping (日記檔傳送)：這是三個方案之中最便宜也是最簡單的方案，這個主要將第一台的紀錄檔(Log) 傳送到另外一台，而另外一台可以提供唯讀(Standby)的方式讓使用者進行存取，而同步時間因為是透過SQL Agent的排程進行，所以可以設定在一分鐘以內，而這個方案也是我目前遇到的客戶中最多人使用的方案。

Log Shipping 架構圖：



參考文章：如何建立 Log Shipping

3、Database Mirroring (鏡射)：這是一個在SQL Server 2005推出的新功能，推出的時候真的有讓我非常的驚艷，很多人可能會想說我會不會寫錯了，Database Mirroring 的架構是屬於Active與Passive二種，那到底該如何進行負載平衡(Load Balancing)呢，這個就要透過資料庫快照(Database Snapshot)，透過這個方法就可以將硬體發揮到極限，才不會白白的浪費硬體，但是有一個非常大的問題需要解決，那就是當你要重作快照的時候，需要中斷使用者的需求，所以會有停止服務的時間差產生，這個問題想當然也是有方法可解，那就是透過二個資料庫快照進行切換，假設我已每10分鐘重作一次，10:00的時候使用第一個快照，10:10的時候使用第二個，這時候第一個就可以準備開始重作快照，等到約10:19分的時候就可以開始重作快照，然後再切換回第一個，以此類推，即可達到負載平衡(Load Balancing)。

參考文章：SQL Server - 如何建立 Database Mirroring

Database Mirroring 架構圖：




        最後上面的三個架構並沒有一定的好與壞，主要還是視客戶的需求而定，大家可以嘗試評估看看自已的需求，再選擇最合適的架構即可。


相關文章：

1. SQL Server 2008 R2 容錯移轉叢集環境架設 - 利用 VM 與 Windows Storage Server - Part I
2. SQL Server 2008 R2 容錯移轉叢集環境架設 - 利用 VM 與 Windows Storage Server - Part II
3. SQL Server 2008 R2 容錯移轉叢集環境架設 - 利用 VM 與 Windows Storage Server - Part III(終)
4. SQL Server - 雙主動模式叢集環境架設
5. SQL Server - 如何建立 Database Mirroring
6. 如何建立 Log Shipping
7. SQL Server 分散式架構 - 點對點交易式複寫 + NLB

關鍵字：Load Balancing、Database Mirroring、Replication、Log Shipping