在Windows Server 2012 R2中搭建SQL Server 2012故障转移集群

　　需要说明的是我们搭建的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故障转移集群就搭建完成了。