需要說明的是我們搭建的SQL Server故障轉移集群（SQL Server Failover Cluster）是可用性集群，而不是負載均衡集群，其目的是為了保證服務的連續性和可用性，而不是為了提高服務的性能。
SQL Server始終在負載均衡集群方面都缺少自己的產品，多由第三方廠家提供，但SQL Server故障轉移集群卻由來已久，在SQL Server 2012還提供了一個可用性組（AlwaysOn High Availability Groups）的新特性，我們知道微軟的故障轉移集群（Windows Server Failover Clustering , WSFC）一般需要共享存儲，SQL Server故障轉移集群也是建立在WSFC的基礎之上，可用性組卻可以不依賴於共享存儲實現SQL Server的故障轉移，這為沒有共享存儲的環境提供了一個實現SQL Server高可用的解決方案，關於AlwaysOn特性可以參閱相關文檔，這里我們實現的是仍是基於共享存儲的包含兩個節點的SQL Server故障轉移集群。
一、搭建Windows故障轉移集群（WSFC）
SQL Server故障轉移集群是基於WSFC的，因而我們需要事先在兩個節點中搭建一個WSFC，這里需WSFC僅是一個容器，可以放置多個角色以實現這些角色的故障轉移。為搭建一個WSFC，除了需要域環境，還需要在節點，存儲，網絡等方面做准備。
1、在各節點中添加Failover Clustering服務器功能。
2、確保各節點操作系統的更新一致，新安裝的系統要么更新到最新，要么暫不更新。
3、在各節點中配置管理網絡和心跳網絡，雖然一個可用網絡既可以搭建集群，但是最佳實踐還是分開。
4、在各節點中配置共享存儲磁盤，初始化並格式化磁盤，分配盤符。這里的共享存儲磁盤可以是基於IP SAN和FC SAN的磁盤，也可以是基於文件服務器的虛擬磁盤，具體可以參考Windows Server 2012 虛擬化測試：存儲。在節點中可見磁盤如下：
為搭建SQL Server故障轉移集群，至少需要准備兩塊共享磁盤：集群見證磁盤Q、為存儲SQL Server數據庫和日志文件准備的集群磁盤S。另外我們需要為SQL Server的集群實例配置分布式事務協調器（Distributed Transaction Coordinator, DTC），因而需要為DTC准備磁盤M。微軟建議將SQL Server各類文件分開存儲，最佳實踐需准備兩塊以上共享磁盤，分別存儲User Database、Backup和User Database Log文件，這就至少需要另一個集群磁盤L。綜上我們對存儲做如下配置：
- 集群見證磁盤Q
- DTC磁盤M
- SQL Server程序：本地磁盤C
- User Database文件：集群磁盤S
- User Database Log文件：集群磁盤L
- TempDB文件：本地磁盤D，SQL Server 2012支持將Temp DB文件可以放在本地快速磁盤中，但是需要特別注意的是必須在各節點都建立相同的路徑，以便SQL Server存放TempDB文件。
- Backup文件：集群磁盤S
另外值得一提的是到SQL Server 2014才提供了對集群共享卷的支持，因而這里只能使用集群磁盤。
5、使用Failover Cluster Manager驗證並創建集群。
過程中需要定義集群的域名稱和IP地址，Failover Cluster Manager將通過該域名稱或IP訪問集群。完成創建集群后的集群磁盤視圖如下：
二、安裝SQL Server故障轉移集群
Windows故障轉移集群（WSFC）搭建成功后即完成了SQL Server故障轉移集群的基礎，接下來我們繼續完成SQL Server部分。先在一個節點上安裝SQL Server Failover Cluster，然后再另一個節點安裝加入集群節點。
SQL Server集群部分，先通過驗證，這里的警告主要是搭建Windows故障轉移集群存在警告的警告，升級警告以及防火牆警告，可以繼續。
選擇Database Engine Services和管理組件，注意這里只有Database Engine Services和Analysis Services支持集群，其他服務都不支持。其他組件如需要也可以隨后再添加，但是添加其他組建時選擇Add features to an existing installation，然后選擇Perfom a new installation of SQL Server 2012，而不是Add features to an existing instance of SQL Server 2012，否則最后會出現Existing clustered or cluster-prepared instance的錯誤，具體參考Installing SQL Integration Services after SQL Cluster Setup has Completed。
配置一個網絡名稱，類似於計算機名稱，今后將通過該名稱訪問數據庫實例。
三、配置DTC和SQL Server 集群
分布式事務協調器（Distributed Transaction Coordinator, DTC）在Windows中是默認安裝並運行的服務。DTC的主要目的是為了實現分布式事務，確保跨進程通信的一致性，這里的進程可以是同一計算機中的兩個進程，也可以是不同計算機中的進程。因而在微軟的世界里，常常看到DTC的身影。
如果只是獨立安裝SQL Server數據庫引擎則無需配置DTC。但是在同時運行SQL Serve集成服務（SQL Server Integration Services, SSIS）或者搭建SQL Sever故障轉移集群等需要分布式事務的場景中，則需要配置DTC。不配置DTC並不影響SQL Server集群的安裝，但是DTC沒能正確配置，SQL Server集群的功能將受到影響。
Windows Server 2008及以后版本在一個Windows集群中可以有多個DTC實例，這些DTC實例可以是集群實例也可以是本地實例（這里“實例”概念的類似於SQL Server數據庫引擎實例，是作為操作系統服務運行的，是同一個可執行程序的副本，在Windows集群中運行的各類服務都是以實例的形式存在，這些實例依賴Windows集群實現故障轉移），甚至可以為SQL Server集群中每個SQL Server實例配置一個專屬的DTC實例。SQL Server集群實例按照如下的是順序選擇DTC實例：
-
使用SQL Server實例專屬的DTC實例，該DTC實例作為SQL Server實例以來的資源，如果DTC實例失敗，將造成SQL Server實例的失敗。SQL Server 2008及以后版本才有此項。
-
使用映射給SQL Server實例的DTC實例，使用命令msdtc可以為SQL Server實例映射DTC實例。
-
使用默認的DTC集群實例，SQL Server 2008及以后版本可以在Windows集群中創建多個DTC實例，第一個創建的DTC實例為默認實例，DTC集群實例並未指定給SQL Server實例專用，因而其他應用程序也可以使用該實例。
-
使用安裝在本地計算機上DTC實例。
由於SQL Server集群實例做出選擇之后是不會自動重新選擇的，比如SQL Server集群實例選擇了專屬的DTC實例，即使該實例失敗，也不會更換下一個可用的DTC實例，除非手動刪除專屬的DTC實例，因而微軟建議在SQL Server 2008及以后版本要么為SQL Server集群中的每個SQL Server實例創建專屬的DTC實例，要么就不要在SQL Server集群中創建任何DTC實例（這里的DTC實例都是集群實例，即可以實現DTC故障轉移），這時SQL Server集群實例會選擇實例所在節點的本地DTC實例。關於DTC的更多信息，可以查閱這里。當然這里我們不會什么也不做，下面我們將為SQL Server實例配置專屬的DTC實例。
為實現DTC的高可用性，需要在各節點安裝Application Server角色。
在Windows故障轉移集群管理器中的SQL Server實例右鍵選擇Add Storage，確保將用於DTC的磁盤加入為SQL Server實例資源。
在SQL Server實例右鍵選擇Add Resource > More Resources > Distributed Transaction Coordinator，創建SQL Server實例專屬的DTC實例。
右鍵新創建的DTC實例New Distributed Transaction Coordinator，在Dependencies里為DTC實例配置先前准備的集群磁盤和主機名稱（這里使用SQL Server的集群名稱）。
右鍵DTC實例選擇Bring Online，至此就為SQL Server集群實例創建一個專屬的DTC實例。這種配置雖然提高了效率，但卻使DTC實例成為SQL Server依賴的資源，DTC實例失敗將造成SQL Server集群實例的失敗。
接下來我們需要為DTC實例做適當的配置。登錄集群的任意節點，在服務器管理器菜單工具中選擇Component Services或者在使用命令dcomcnfg，啟動Component Services。在DTC集群實例右鍵屬性，如下圖配置Security。配置完成后將重啟DTC服務，在其他節點同樣位置也會看到一樣的配置。
另外需要特別注意在發起分布式事務的應用程序服務器上也要做同樣的配置。
四、測試DTC和SQL Server集群
下面我們就使用微軟的DTCPing工具（可以在這里下載）來測試服務器cloud-pm-da01和SQL Server集群cloud-pm-sql01之間的DTC是否正常工作。
- 首先需要在服務器cloud-pm-da01上對其本地的Local DTC做如同SQL Server節點上一樣的配置，即雙方做同樣的配置。
- 事先關閉雙方的防火牆，由於DTC使用RPC進行通信，而RPC會動態的使用1024-65535之間的端口，目前我們也不知道在防火牆中開放哪些端口，因而先保證測試成功再考慮防火牆的問題。
- 在服務器cloud-pm-da01和SQL Server集群的有效節點上同時運行DTCPing工具。這里有效節點，即是DTC實例所在節點，也是SQL Server實例所在節點。由於按照上面的配置DTC實例是專屬與SQL Server實例的，那么DTC實例所在節點和SQL Server實例相同，而且通過網絡訪問該DTC實例的NetBIOS也是cloud-pm-sql01。比如有兩個節點cloud-pm-cn01和cloud-pm-cn02，那么SQL Server實例在cloud-pm-cn02上，那么DTC實例也在cloud-pm-cn02，那么在cloud-pm-cn02上運行DTCPing工具。
- 在服務器cloud-pm-da01的DTCPing工具上輸入cloud-pm-sql01，然后點擊Ping按鈕執行測試。正常情況下將獲得如下消息，表示cloud-pm-da01至cloud-pm-sql01方向的DTC通信正常。同理，在cloud-pm-cn02的DTCPing工具測試至cloud-pm-da01的DTC通信。
- 最后我們加入防火牆設置。在cloud-pm-cn02上運行DTCPing工具，運行netstat –anob命令，查看DTCPing在監聽哪些端口。會發現每次DTCPing啟動后監聽的端口都不一樣。如上所述，由於DTC使用RPC進行通信，而RPC會動態的使用1024-65535之間的端口，那么開放這么大范圍的端口不是可行的辦法，因而需要限制RPC使用的端口范圍，注意這里將影響所以使用RPC的進程，而不僅僅是DTC。
在服務器管理器菜單工具中選擇Component Services或者在使用命令dcomcnfg，啟動Component Services，配置MyComputer > Properties > Default Protocols，選擇 Connection-oriented TCP/IP 屬性，加入端口范圍，該設置要求重啟計算機。在防火牆中加入同樣的端口范圍例外（這里應開放TCP端口，且端口范圍要足夠大，最好有100個以上端口，另外Port range assignment 和Default dynamic port allocation都選擇Internet range）。同理在應用程序服務器和集群各節點中作同樣配置，需要注意的是在集群節點是非有效狀態時，配置可能不可用，需要將SQL Server實例移動到該節點后在配置。更多DTC問題可以查閱Troubleshooting MSDTC issues with the DTCPing tool。
- 在防火牆中同時開放SQL Server的1433端口和SQL Server Agent的135端口，在SQL Server Management Studio測試連接cloud-pm-sql01是否正常，在Failover Cluster Manager中測試集群是否能夠正常實現故障轉移，至此SQL Server故障轉移集群就搭建完成了。