一个SQL Server集群是由二台或更多运行SQL Server的服务器（节点）组成的虚拟服务器。即，SQL Server故障转移群集建立在Windows故障转移群集之上。多个群集节点分别安装SQL Server服务组件，但互相协同作为一个整体对外提供同一个SQL实例的服务。如果集群中的一个节点发生故障失去其功能时，集群中的另一个节点将接手运行它的SQL Server实例。
认为一个SQL Server集群能够给集群中的两个节点带来负载平衡，这是一种常见的误解。虽然这似乎很有用，但却是不正确的。这也意味着SQL Server集群不能真正提高性能。集群SQL Server只能提供故障转移功能。这种故障可能是由于硬件故障、服务故障、人工故障或各种其它原因。
SQL Server 集群拓扑
集群拓扑示例
这种结构下群集有两个节点，用户在群集上安装一个SQL Server群集实例。这样任意时间只有一个节点上有SQL Server服务在运行，而另一个节点就是“非活跃”节点。这种配置优点就是结构简单明了，无论SQL Server运行在哪个节点上都能获得同样的性能表现。缺点是总有一个节点处于空闲状态，浪费了50%的硬件资源。
类似地，从节约成本角度来考虑，还有所谓的N+1结构，即N个活跃节点加上一个非活跃节点。以3个节点的群集为例，在上面安装两个SQL Server实例，每个实例的Possible Owner包含群集中的两个节点，但是只有一个节点是两个实例共有的。正常情况下，两个SQL Server实例各自运行在非共有的那个节点上，互不相干。一旦某个节点发生故障转移，就会切换到那个共有的非活跃节点上。相对于“活跃/非活跃”，它浪费的节点资源比较少（1/N+1）。另外，两个以上的节点同时发生故障转移，需要同时切换到共有节点的概率是比较低的，因此也在一定程度上解决了“活跃/非活跃”结构的性能问题。
SQL Server集群特点
在实用性方面，集群SQL Server环境令人满意，在进行故障转移时提供了整个SQL Server实例级别的高可用性保护。数据库实例由一台服务器转移到另一台服务器的时间非常短暂，一般只需要3至7秒钟。虽然需要重建连接，但对数据库的终端用户而言，故障转移处理通常是透明的（SQL群集实例对外使用一个虚拟网络名称及虚拟网络IP地址提供服务）。低廉的故障转移成本还可帮助我们对集群中的节点进行维护，而不会造成服务器完全无法访问。
群集节点间共用的共享存储，即数据库文件的存储仍然只有一份，仍然存在潜在的单点故障隐患。一旦数据本身出现问题，群集对此便无能为力。所以，群集技术不是一个提供数据“灾难恢复”的技术。对重要的数据库，仅仅使用群集技术是不够的。
SQL Server 故障转移群集安装只支持使用本地磁盘安装 tempdb 文件。 确保为 tempdb 数据和日志文件指定的路径在所有群集节点上均有效。 在故障转移期间，如果 tempdb 目录对故障转移目标节点不可用，则 SQL Server 资源将无法联机。
