服务器集群的服务器集群简介

一旦在服务器上安装并运行了集群服务，该服务器即可加入群集。集群化操作可以减少单点故障数量，并且实现了群集化资源的高可用性。下述各节简要介绍了群集创建和集群操作中的节点行为。

注意：有关安装群集服务器的信息，请参阅 Windows server 2003产品家族的帮助和部署指南。

关于Windows Server 2003的企业版和Datacenter版都可以支持最大达8个节点的集群配置;其典型的特征是可为数据库、消息系统、文件与打印服务这些关键业务应用，提供高可用性和可扩展性，在集群中的多个服务器(节点)保持不间断的联系。即是说如果在集群中的某一节点因出错或维护不可用时，另一节点会立刻提供服务，以实现容错。正在访问服务的用户可以继续访问，而不会察觉到服务已经由另一台服务器(节点)提供。

群集方法介乎两种计算机系统结构之间。当把多台计算机配置或互连在一起时，可采取松散耦合或紧密耦合结构。网络就是一个松散耦合的系统，我们也称其为异类系统结构。网络把由各种CPU、应用软件、NIC（网络接口控制器）、甚至是操作系统组成的多台计算机连接在一起。计算机之间的地理距离可以近在咫尺，也可以远在天边。可以用实时和/或异步方式耦合网络。

因特网就是一个典型的极为松散与异类配置的例子。因特网本身不能“实时”控制与它连接的任何主机。在松散耦合网络中，单机崩溃一般不会影响网络的其它部分。

相反，紧密耦合系统则高度依赖于构成系统的所有部件。当系统由相同部件组成，采用并行操作方式并共享所有子系统（存储器）时，我们称其为同类系统结构。紧密耦合系统最常见的例子是SMP（对称多处理）。在SMP状态下，根据工作量的多少把任务分给几台处理器，这样可均匀地分配工作量，以便提高数据吞吐量。

我们举了两个典型的松散和紧密耦合系统的例子，群集就介于松散和紧密耦合系统之间。根据系统的配置，在某些方面（比如操作系统），群集控制的系统也许更偏向紧密耦合的系统，或者偏向松散耦合的系统（比如独立计算能力，通过公共存储器连接）。

通常群集器放在同一设备区或同一办公楼里。从理论上说，群集控制方法可应用于闭路广域网环境中（现正在美国东北部地区进行试验）。可是在考虑到视频服务器应用时，一般来说只能把设备放在主要设施运行所在地。

公共数据共享

群集允许共享几个节点的数据。在此应用中，这些节点包括客户工作站、中央或多服务器。我们知道可以通过许多路径（比如星形结构）连接节点，客户可通过不同连接的节点路径存取数据。当节点就是服务器时便可共享公共存储器，某个服务器节点故障不会导致整个群集器系统瘫痪。

在12月专栏里，我们把群集描述成一个提供高可得性的系统。对广播或有线电视操作来说，视频服务器必须要提供连续的或高可得性的数据。考虑到这一点，我们认为视频服务器体系结构采用群集是大有潜力的。

待命或无源服务器结构就是一种群集形式。在这种结构下，一个或多个服务器（或节点）平时保持在待命状态，随时可以启动。利用后台控制系统管理待命服务器内容数据。在未发生故障之前一般不启用无源服务器。

无源服务器未必就是主服务器的完全镜像，它也可以有一些有限的数据源，包括存储器，要经常清除这些数据，然后重新装入最新的节目或广告。通过这一循环过程把适量的数据（或视频媒介）保持在待命状态，在需要时随时可以上线使用。

服务器在待命状态时通常由少量的部件组成，比如编解码器，在出现故障或另一个服务器需要它支持的时候，该服务器可立即被集成到系统中应用。此时，服务器进入负载均衡状态。

数据共享

数据共享是群集器需要提供的最基本功能之一。我们还是以视频服务器的应用为例，多个编辑站在这里独立地工作，不过利用一组公共服务器来管理数据和应用层的处理。

在这个例子中，多个新闻编辑站（或客户工作站）可以选择用哪个编辑服务器（包括编辑用的软件和硬件）来进行编辑。这些服务器控制对公共媒体数据库的存取，编辑站只是这些服务器的简单控制器GUI（图形用户界面）。编辑服务器进一步控制接入另一个更大的数据存储库（通常是新闻档案）。

这个概念可通过群集软件实现。在独立的编辑站通过群集器存取数据的过程中，编辑与数据存取或存储处理自动进行，不会影响其它的客户编辑站或预放站。通过提供连续的数据可得性，每个服务器可以是有源的，也可以是无源的，视工作负荷而定。假如有一个服务器发生了故障，该结构也可提供冗余或保护方式。

共享一个操作系统和平台是群集的又一个共同特点。让硬件与软件平台同属一类，也就是说，基本上是相同的，就可采用公用互连方案与公共文件格式结构。在SMP这样的系统中，所有部件都依赖于公用硬件而像单独部件一样运行。正如我们已提到的，群集可以让一部分系统保持同类结构，但脱离所有系统都有的依赖性，其它性能就会下降。

其它优点

我们现在还是回到基于群集服务器的编辑环境中来，我们又发现了其它一些优点。服务器硬件具有的冗余性可对数据起保护作用。在新闻编辑环境中，当即将播放时，一个或更多的服务器便可将客户工作站的功能变成播出功能，直接把新闻播出去。这样还能让所有客户和服务器接入别的服务器的数据，包括在最后一分钟直接存取中央存储库的数据。

通过使用多个服务器（每个服务器收集、编辑、存档和重放的资源是一个类型的），系统便可对硬件进行备份。在某个服务器出现故障时，可把资源转给或分给其它用户，系统的其余部分仍继续工作。

除了上述的数据共享外，其它群集器结构也是可行的。在有些情况下，某些资源可被一个特定的节点“拥有”，在未接到指令前不会放弃。可将该系统的结构配置成一个节点有多个输入编码器，但只有一个输出解码器。另一个节点可能没有输入，但有好几个输出供放像和预看用。如果某一个节点出现故障，可让与它相对应的节点顶替它，直到它被修复为止。

非共享结构

从硬件上说，每个节点的能力（或资源）基本上相同，但内部系统配置是用各种形式锁定的，除非另有要求。按照群集语言可把此结构

叫做非共享结构。在此结构里，某些资源在未被传送给其它节点或者该节点未出故障之前归一个节点所有。在采用非共享结构的计算机与模式里运用群集法通常会把硬盘等设备分配给一个节点，并阻止其他人使用它，除非将其开放或该节点发生故障。

群集结构的其它实施方面增加了系统的复杂程度。除了非共享结构外（只提供最简单的性能和可得性），还有磁盘共享结构。磁盘共享可提高存储接入不同主机系统的能力。

从硬件的角度看，系统的磁盘阵列控制器可以很容易地管理这个共享结构。比较难办的是在最低级别（文件或记录层）上协调更新数据。

协调工作必须成为群集软件的一部分。可以设想一下，如果两个用户同时接入同一记录层会发生什么情况。假定每个用户都修改了文件。用户1先把数据写入服务器，他发现用户2做了完全不同的修改并且把修改后的文件用同一文件名存入相同的磁盘，或许存在另一个服务器上，这样就有可能把第一个用户修改的文件冲掉。没有一个控制方案，就会乱成一团。

尽管每个文件或记录层都有简单的口令或锁定保护，但要确保用文件的正确版本存成另一个文件名或是“正式”版，则要求具有更高层的数据控制与管理能力。磁盘快速缓存问题又是另一种情形，我们等一会儿再说。

另一个防止错误数据覆盖正确数据的方法是在修改未最后定之前限制接入某一特定文件。在计算机数据域中，用一个称为信息传送的程序通知管理员（通常是应用后台软件的一部分）文件存取被锁定，直到修改程序结束为止。

原子操作

原子操作的三个步骤是：读数据、修改数据、然后重新写入新数据。在原子操作过程中，在未执行完操作之前不会受到任何干扰。还必须有其他保护措施，以防隐藏的备份文件在以后某个无法预测的时间改写其它的文件。

当数据分布在不止一个存储磁盘上时，或者当公共存储阵列中的数据被不同用户在不同时间存取时，如何防止数据不一致是群集软件需要解决的又一个问题。无论是通过硅缓存器还是通过远程接入的临时磁盘缓存器（甚至分区）进行高速缓存都会遇到定时和同步的问题。我们把这个问题叫做缓存相关性，它是因磁盘驱动器定时问题引起的。

磁盘驱动器并不一定能马上写入数据，磁头也许定位在错误的磁道上，导轮也许偏离相位190度，等结束运转后才能开始磁头的写入操作，或许还因为温度问题造成暂时性延缓，直到一切都符合条件为止。

这通常被称为等待时间，磁盘驱动器的机械部分要求在驱动器等待写入时暂存一下数据。最常见的方法是在驱动器上安一个硅缓存器，这个过程被叫做写回高速缓存。在把主机储存器中的数据转存到磁盘驱动器的过程中，设一个写回缓存器标识，对数据源表示写入程序成功了。实际上，得过一会儿才能开始真正的电磁机械式的数据储存过程。

假如系统上的另一个节点也从这个驱动器读数据，（这是经过许可的操作，因为数据发生器已接到通知，新数据已发送到了这个位置），那么缓存器已在指定位置存储了正确新数据的指示信号就不见了。我们用失效数据一词来表示未更新数据进入新数据区的状态。

无效数据

RAID控制器在各自磁盘阵列的写回缓存器里为与这个特殊的阵列有关的磁盘管理失效数据。假如在软件里设一些适当的开关来检测和阻止它发生，那么数据相关性就只是一个小问题了。

当系统是由多层阵列构成的时候，控制失效数据问题的任务就交给高级别软件去完成，把信号传送给各自的阵列，就不会发生孤立或失效数据问题了。

在这个简化的单一视频服务器模型里，媒体是通过单编码器输入的，并存在一个单实体阵列上。由一个更高级别（通常是第三方API，应用程序接口）登记和管理活动图像数据。通常将其作为任选的“媒体管理”或“资产管理器”包出售。通过这个软件，控制活动图像和数据的过程成为一个闭路过程，因为输入与输出指令必须通过这个管理软件包。该软件在自己的数据库里始终跟踪着数据的有效性。

如果有好几个服务器，每个服务器有自己的任务，情况就变得比较复杂了。这时可以让几个信号源的输入进入不同的编码器，并存在一个较大的磁盘阵列里。这些阵列通常与光纤通道仲裁环相连，由于它的连接方式决定，它可迫使部分重写动作由服务器推迟到存储器，直到有了充足的带宽来把该数据从这个存储器存入另一个存储器。

在类似的应用中，媒体管理软件就更完善，更必不可少了。有时候制造商会提供一个完全独立的CPU和资源管理软件包（作为选件）。这个软件包就像看门狗那样管理服务器之间的数据共享操作。除了这些基本概念外，还有大量的定时和数据验证问题，这些问题会经常在服务器结构的软件与子系统中碰到。

群集的过程和功能正在扩展到设备内和设备间应用中。群集器理念最终将允许整个广播集团通过光纤或通过广域网共享资源。虽然可以让设施连成网共享媒介，可是在这些设施相互离得很远的情况下实现节点资源共享的设想似乎还很遥远。

日常无论测试环境还是生产环境，在进行多台服务器（集群）安装配置的时候，经常需要对集群内服务器SSH访问做免密码设置。比如Hadoop、HBase等集群的安装配置，或者多台服务器为便于后续运维也需要做SSH免密配置。

结合近期搭建测试环境的过程，对如何快速给多台服务器做相互SSH访问免密配置做一个说明。主要分为几个步骤：修改主机名称、配置汇聚服务器的秘钥、汇聚其他服务器秘钥、拷贝汇聚秘钥文件、生成know_hosts文件、拷贝know_hosts文件。

1、集群规划

主机IP

主机名称

1014193101

dmz01

1014193102

dmz02

1014193103

inside01

1014193104

inside02

1014193105

inside03

1014193106

inside04

1014193107

inside05

1014193108

inside06

1014193109

inside07

1014193110

inside08

1014193111

inside09

1014193112

inside10

1014193113

inside11

1014193114

inside12

1014193115

inside13

1014193116

inside14

1014193117

inside15

1014193118

inside16

该集群共有18台服务器，划分为DMZ区2台，INSIDE区16台。主要用于web服务器和应用服务器、数据库、缓存等。为了部署应用、管理集群服务器方便，将18台服务器做SSH互访免密码配置。

2、修改主机名称

无论初装系统或云主机，其主机名称localhost或VM_75_173_centos都不容易进行区分服务器作用。所以便于安装、部署、维护方便，会重新修改主机名称hostname。

修改主机名称可以使用下面命令：

hostnamectl set-hostname inside01

使用上述命令修改主机名称后重新ssh登陆，即可看到主机名称已经修改。

3、配置汇聚服务器秘钥

此处所谓汇聚服务器就是选定集群中的一台服务器，然后其他服务器与其做SSH免密码信任。本文选定dmz01（1014193101）作为汇聚服务器。关系图如下所示：

其他服务器向dmz01做SSH登陆免密码信任配置。此处dmz01就是汇聚服务器。

配置汇聚服务器秘钥的命令如下所示：

[root@dmz01 ~]#ssh-keygen -t rsa

Generating public/private rsa key pair

Enter file in which to save the key (/root/ssh/id_rsa):[Enter键]

Enter passphrase (empty for no passphrase):[Enter键]

Enter same passphrase again:[Enter键]

Your identification has been saved in /root/ssh/id_rsa

Your public key has been saved in /root/ssh/id_rsapub

The key fingerprint is:

43:0d:08:18:ec:9e:d6:1f:ea:5f:04:30:0f:66:26:41 root@dmz01

The key's randomart image is:

+--[ RSA 2048]----+

| oE+O |

| o= = o |

| o |

| o |

| o S |

| + |

| o |

| |

| |

+------------------+

进入/root/ssh目录，拷贝生成authorized_keys文件，使用命令如下：

cat id_rsapub authorized_keys

结果如下所示：

[root@inside01 ssh]# ll

total 12

-rw-r--r-- 1 root root 395 Nov 12 16:25 authorized_keys

-rw------- 1 root root 1675 Nov 12 16:24 id_rsa

-rw-r--r-- 1 root root 395 Nov 12 16:24 id_rsapub

4、拷贝其他服务器秘钥

经过第3节配置汇聚服务器秘钥后，需要依次配置dmz02，inside01，，inside16等17台服务器的秘钥。方法同第三节命令。

配置完成其他17台服务器的秘钥后，需要将该17台服务器的秘钥复制拷贝到汇聚服务器dmz01上。其拷贝命令如下：

[root@dmz01 ssh]# ssh-copy-id -i dmz01

[root@inside01 ssh]# ssh-copy-id -i dmz01

依次将17台的秘钥汇聚拷贝到dmz01上。

5、拷贝汇聚秘钥文件

从汇聚服务器将汇聚的秘钥文件依次拷贝到其他17台服务器的/root/ssh目录下面，命令如下所示：

[root@dmz01 ssh]# scp authorized_keys dmz02:/root/ssh/

[root@dmz01 ssh]# scp authorized_keys inside01:/root/ssh/

[root@dmz01 ssh]# scp authorized_keys inside16:/root/ssh/

root@inside16's password:

authorized_keys 100% 7104 69KB/s 00:00

如上所示进行scp拷贝秘钥文件authorized_keys，该过程需要输入密码。

Ssh免密码验证：

[root@dmz01 ssh]# ssh dmz02

The authenticity of host 'dmz02 (1014168179)' can't be established

ECDSA key fingerprint is 22:49:b2:5c:7c:8f:73:56:89:29:8a:bd:56:49:74:66

Are you sure you want to continue connecting (yes/no) yes

Warning: Permanently added 'dmz02,1014168179' (ECDSA) to the list of known hosts

Last login: Sat Nov 12 17:19:19 2016 from 1014193186

由上面可以看出ssh dmz02，ssh登陆dmz02服务器时，没有再需要输入密码。但是提示需要将dmz02添加到dmz01的know hosts列表文件中。这样下次ssh访问dmz02就不会再提示需要加入know hosts列表了。

6、生成know_hosts文件

从汇聚服务器依次ssh其他17台服务器，经过前面的免密码设置。不需要再输入密码，但是都有加入know hosts列表的提示。

注意：为了把自己dmz01也加入到know hosts文件中，也需要[root@dmz01ssh]# ssh dmz01一下。

最后生成的know_hosts文件内容如下所示：

查看know_hosts文件行数：

[root@dmz01 ssh]# wc -l known_hosts

18 known_hosts

可以看出每个主机一行内容，表示dmz01知道了包括自己在内的所有18台服务器。

7、拷贝know_hosts文件

经过第六节生成18台服务器对dmz01的know host设置，将dmz01的/root/ssh/know_hosts文件scp拷贝到其他17台服务器上。

ssh免密码登陆验证：

[root@dmz01 ssh]# ssh inside10

Last login: Tue Nov 15 15:01:18 2016 from 1014193186

[root@inside10 ~]# ssh inside15

Last login: Sat Nov 12 17:52:29 2016 from 1014193186

[root@inside15 ~]# ssh dmz02

Last login: Sat Nov 12 20:05:59 2016 from 1014193186

[root@dmz02 ~]# ssh dmz01

Last login: Thu Nov 17 23:56:05 2016 from 2181089246

[root@dmz01 ~]# ssh inside15

Last login: Fri Nov 18 00:23:54 2016 from 10141114152

ssh免密码登陆顺序：dmz01inside10inside15dmz02dmz01inside15。

8、总结

本文主要涉及以下几个命令：

hostnamectl set-hostname inside01

ssh-keygen -t rsa

ssh-copy-id -i dmz01

这篇文章就介绍到这了，希望大家以后多多支持我们。

　　12并行技术

　　这是一个非常简单的建造四节点的小集群系统的例子，它是构建在Linux操作系统上，通过MPICH软件包实现的，希望这个小例子能让大家对集群系统的构建有一个最基本的了解。

　　2使用MPICH构建一个四节点的集群系统

　　这是一个非常简单的建造四节点的小集群系统的例子，它是构建在Linux操作系统上，通过MPICH软件包实现的，希望这个小例子能让大家对集群系统的构建有一个最基本的了解。

　　21 所需设备

　　1)4台采用Pentium II处理器的PC机，每台配

　　置64M内存，2GB以上的硬盘，和EIDE接口的光盘驱动器。

　　2)5块100M快速以太网卡，如SMC 9332 EtherPower 10/100(其中四块卡用于连接集群中的结点，另外一块用于将集群中的其中的一个节点与其它网络连接。)

　　3)5根足够连接集群系统中每个节点的，使用5类非屏蔽双绞线制作的RJ45缆线

　　4)1个快速以太网(100BASE-Tx)的集线器或交换机

　　5)1张Linux安装盘

　　22 构建说明

　　对计算机硬件不熟的人，实施以下这些构建步骤会感到吃力。如果是这样，请找一些有经验的专业人士寻求帮助。

　　1 准备好要使用的采用Pentium II处理器的PC机。确信所有的PC机都还没有接上电源，打开PC机的机箱，在准备与网络上的其它设备连接的PC机上安装上两块快速以太网卡，在其它的 PC机上安装上一块快速以太网卡。当然别忘了要加上附加的内存。确定完成后盖上机箱，接上电源。

　　2 使用4根RJ45线缆将四台PC机连到快速以太网的集线器或交换机上。使用剩下的1根RJ45线将额外的以太网卡(用于与其它网络相连的那块，这样机构就可以用上集群)连接到机构的局域网上(假定你的机构局域网也是快速以太网)，然后打开电源。

　　3 使用LINUX安装盘在每一台PC机上安装。请确信在LINUX系统中安装了C编译器和C的LIB库。当你配置TCP/IP时，建议你为四台PC分别指定为19216811、19216812、19216813、19216814。第一台PC为你的服务器节点(拥有两块网卡的那台)。在这个服务器节点上的那块与机构局域网相连的网卡，你应该为其指定一个与机构局域网吻合的IP地址。

　　4当所有PC都装好Linux系统后，编辑每台机器的/etc/hosts文件，让其包含以下几行：

　　19216811 node1 server

　　19216812 node2

　　19216813 node3

　　19216814 node4

　　编辑每台机器的/etc/hostsequiv文件，使其包含以下几行：

　　node1

　　node2

　　node3

　　node4

　　$p#

　　以下的这些配置是为了让其能使用MPICH’s p4策略去执行分布式的并行处理应用。

　　1 在服务器节点

　　，建一个/mirror目录，并将其配置成为NFS服务器，并在/etc/exports文件中增加一行：

　　/mirror node1(rw) node2(rw) node3(rw) node4(rw)

　　2 在其他节点上，也建一个/mirror目录，关在/etc/fstab文件中增加一行：

　　server:/mirror /mirror nfs rw,bg,soft 0 0

　　3 /mirror这个目录从服务器上输出，装载在各个客户端，以便在各个节点间进行软件任务的分发。

　　4 在服务器节点上，安装MPICH。MPICH的文档可在

　　5任何一个集群用户(你必须在每一个节点新建一个相同的用户)，必须在/mirror目录下建一个属于它的子目录，如 /mirror/username，用来存放MPI程序和共享数据文件。这种情况，用户仅仅需要在服务器节点上编译MPI程序，然后将编译后的程序拷贝到在/mirror目录下属于它的的子目录中，然后从他在/mirror目录下属于它的的子目录下使用p4 MPI策略运行MPI程序。

　　23 MPICH安装指南

　　1如果你有gunzip，就d下载mpichtargz，要不然就下载mpichtarZ。你可以到http://wwwmcsanlgov/mpi/mpich/downloa下载，也可以使用匿名FTP到ftpmcsanlgov的pub/mpi目录拿。(如果你觉得这个东西太大，你可以到pub/mpi/mpisplit中取分隔成块的几个小包，然后用cat命令将它们合并)

　　2解压：gunzip ;c mpichtargztar xovf-(或zcat mpichtarZ　tar xovf-)

　　3进入mpich目录

　　4执行：/configure为MPICH选择一套适合你的实际软硬件环境的参数组，如果你对这些默认选择的参数不满意，可以自己进行配置(具体参见MPICH的配置文档)。最好选择一个指定的目录来安装和配置MPICH，例如：

　　/configure -prefix=/usr/local/mpich-120

　　5执行：make >&makelog 这会花一段较长的时间，不同的硬件环境花的时间也就不同，可能从10分钟到1个小时，甚至更多。

　　6(可选)在工作站网络，或是一台单独的工作站，编辑mpich/util/machines/machinesxxx(xxx是MPICH对你机器体系结构取的名称，你能很容易的认出来)以反映你工作站的当地主机名。你完全可以跳过这一步。在集群中，这一步不需要。

　　7(可选)编译、运行一个简单的测试程序：

　　cd examples/basic

　　make cpi

　　ln ;s //bin/mpirun mpirun

　　/mpirun ;np 4 cpi

　　此时，你就在你的系统上运行了一个MPI程序。

　　8(可选)构建MPICH其余的环境，为ch_p4策略使

　　用安全的服务会使得任何启动速度加快，你可以执行以下命令构建：

　　make serv_p4

　　(serv_p4是一个较新的P4安全服务的版本，它包含在MPICH 120版中)，nupshot程序是upshot程序的一个更快版本，但他需要tk 36版的源代码。如果你有这个包，你就用以下命令可以构建它：

　　make nupshot

　　9(可选)如果你想将MPICH安装到一个公用的地方让其它人使用它，你可以执行：

　　make install 或 bin/mpiinstall

　　你可以使用-prefix选项指定MPICH安装目录。安装后将生成include、lib、bin、sbin、www和man目录以及一个小小的示例目录，

到此你可以通告所有的用户如何编译、执行一个MPI程序。

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。