SQL Server的群集有两类：负载均衡和故障转移，在InformIT的SQL Server参考指南的这篇短文讨论了群集的原因和一些系统需求：
负载均衡群集
在实际的负载均衡群集里，所有的服务器（称为节点）都象一台机器工作，一组电脑称为仲裁，给外面用户形成单一服务器印象的电脑或软件服务称为“仲裁管理器”，仲裁管理器将处理需求传送到一个或多个服务器上。这种工作的分担方式造成非常强大的一台虚拟计算机。如果其中的一个节点离开群集，仲裁管理器就将工作负载转到其它服务器上。
虽然这种群集方式听起来很好，但SQL Server还不支持这样的方式。很遗憾是这样的情况， 它还行不通。没关系，我们继续。
故障转移群集
故障转移群集的设定相对简单， 并能为环境提供高度的安全性。在故障转移群集中，两个服务器共享同一个存储装置。服务器与存储装置建立单一信号联系，单一信号起到象heartbeat一样的作用，使服务器彼此听不到对方。第二个节点接管第一个节点的身份。所有这些过程在处理消费者数据时都很圆满，根据应用程序对连接超时的容忍程度，你的用户甚至可能都没有意识到这个现象的
发生。
SQL Server 7和2000都支持这种群集，实际上，SQL Server在这种群集下有两种模式：主动/主动和主动/被动模式。现在让我们看一下：
主动/主动模式
在这种形式的群集里，每台服务器独立工作，并也能处理其它服务器的故障。假定说在群集里我们有名为服务服务器A和服务器B的两台服务器（节点），群集以另一个名称群集1来标定自己，用户可以用群集1或服务器B，服务器A如果死机的话，服务器B就变成了群集1和服务器B，它使用两个标识。
一个主动/主动群集可以有四个节点接入，最多可以到16个instance，关于instance的话题我们将在另一篇文章里进行深入讨论，但可以把在一个系统上的SQL Server的安装当成instance。在ODBC和其它类型的连接类型中，其命名是以服务器名称接instance的名称，即：服务器名+instance名，而不是你习惯所用的服务器名。
主动/被动模式
在这种模式里， 群集是外面能看到的唯一设备，其它的设备处于“待命”状态，只有在你人工介入或当第一组群集失效后才会启动。
为什么采用群集？
你可能回认为使用群集的唯一原因是为了安全。毕竟我说过SQL Server不支持真正负载均衡，那么你还能想到什么呢？除了高有效性的好处外，你也可以将故障人为转移到第二个节点，升级第一个节点，再将系统转移回来，再升级第二个节点。这可能听起来不太重要，但你如果有一个不容许有任何停机时间的系统，这个功能就是无价的。
要求
不管你选择哪种配制的故障转移群集，需要注意以下几点。首先你需要安装SQL Server的企业版，你也可以采用程序员版本，但在这篇文章中我们按照企业版的情况来讨论。
你还需要安装微软的群集服务(MSCS)，那是这个文章讨论范围之外的另一个大的主题。微软的群集主页的链接也能帮助你的了解。操作系统要求Windows 2000企业版或数据中心版，或Windows 2003服务器的相当系统版本。Windows 2003服务器对系统进行了很多改动，所以要确认你充分了解你要运行群集的操作系统。
每台服务器需要装两块网卡，从技术层面来说这不是要求。但由于服务器之间需要heartbeat，所以最好是不必共享资源。其次，你需要把一个硬盘供服务共享。微软称这是“共享的SCSI总线”。大多数人使用存储区域网络，但即使你没有读到过硬件兼容列表，你也必须遵照着做。微软已经出事这个业务有相当长的时间了，所以在搜索群集和硬件兼容列表时，确认你的硬件应在其中，否则运行将不会顺利。
你可以在微软支持中心读到更多的关于安装群集所需的步骤。
