服务器如何实现集群和负载均衡

你可以直接买一台负载均衡交换机啊，何必要浪费1台服务器呢。

2 应该是每台都会有一个IP地址 外网 访问连接到的那个IP地址 是你的负载均衡交换机的IP地址 他随机把你的访问请求分配到你的3台服务器上

3 无主从关系，负载均衡交换机它会没2秒左右向你的服务器发送一个健康检查，如果发现你的服务器出现问题，它会自动屏蔽你这台服务器

4 你问的重复问题。

最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。 

整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。 

1集群架构改造的目标

在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：

1）之前 的GP segment数量设计过度 ，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。

2）GP集群 的存储资源和性能的平衡不够 ，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。

3)集 群的异常场景的恢复需要完善， 集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。

4）集群版本过 低 ，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。

5）操作系统版本升 级 ，之前的操作系统是基于CentOS6，至少需要适配CentOS 7 。

6）集群TPCH 压测验收 ，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。

2集群规划设计的选型和思考

明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：

1）Greenplum的版本选择 ，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了 开源版本的6162 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。

2）数据集市的技术选型 ，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。

3）GP的容量规划 ，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）10+2，整体的配置情况类似下面的模式。

4）部署架构方案选型 ，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。

除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。

  方案1 ：Master,Standby和segment混合部署

  方案2 ：Master,Standby和segment独立部署，整个集群的节点数会少一些

  方案3 ：Segment独立部署，Master,Standby虚拟机部署

  方案4 ：最小化单节点集群部署（这是数据集市最保底的方案）  

这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课， 越是想走捷径，越是会让你走一些弯路 ，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。

3集群架构的详细设计和实践

1）设计详细的部署架构图

在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。

2）内核参数优化

按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：

vmswappiness=10

vmzone_reclaim_mode = 0

vmdirty_expire_centisecs = 500

vmdirty_writeback_centisecs = 100

vmdirty_background_ratio = 0 # See System Memory

vmdirty_ratio = 0

vmdirty_background_bytes = 1610612736

vmdirty_bytes = 4294967296

vmmin_free_kbytes = 3943084

vmovercommit_memory=2

kernelsem = 500 2048000 200 4096

4集群部署步骤

1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。 

2）配置用户，很常规的步骤

groupadd  gpadmin

useradd gpadmin -g gpadmin

passwd gpadmin

3）配置sysctlconf和资源配置

4）使用rpm模式安装

# yum install -y apr apr-util bzip2 krb5-devel  zip

# rpm -ivh open-source-greenplum-db-6162-rhel7-x86_64rpm

5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作

6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件

gpssh-exkeys -f hostlist

7）较为复杂的一步是打包master的Greenplum-db-6162软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下

gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6162targz =:/tmp

或者说在每台服务器上面直接rpm -ivh安装也可以。

8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。 

mkdir -p /data1/gpdata/gpdatap1

mkdir -p /data1/gpdata/gpdatap2

mkdir -p /data2/gpdata/gpdatam1

mkdir -p /data2/gpdata/gpdatam2

9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

10）部署GP集群最关键的命令是

gpinitsystem -c gpinitsystem_config -s standby_hostname

其中文件gpinitsystem_config的主要内容如下：

MASTER_HOSTNAME=xxxx

declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1  /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)

TRUSTED_SHELL=ssh

declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1  /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)

MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts

整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

5集群部署问题梳理

集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：

1） 资源配置问题 ，如果/etc/security/limitsconf的资源配置不足会在安装时有如下的警告：

2） 网络问题 ，集群部署完成后可以正常操作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count() from customer,但是会抛出如下的错误：

这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。 

对于数据节点可以开放略大的权限，如：

入口的配置：

-A INPUT -p all -s xxxxx    -j ACCEPT

出口的配置：

-A OUTPUT -p all -s xxxxx    -j ACCEPT

3）网络配置问题 ，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count() from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。

为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。

gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp

$ cat /etc/hosts

127001   localhost localhostlocaldomain localhost4 localhost4localdomain4

::1      localhost localhostlocaldomain localhost6 localhost6localdomain6

#127001    test-dbs-gp-128-230

xxxxx128238 test-dbs-gp-svr-128-238

xxxxx128239 test-dbs-gp-svr-128-239

其中127001的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。

5集群故障恢复的测试

集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。

整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。

第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。

1）服务器宕机修复后集群恢复

select from gp_segment_configuration where status!='u';

gprecoverseg  -o /recov

gprecoverseg -r

select from gp_segment_configuration where status='u'

2）服务器不可用时集群恢复

重构数据节点的过程中，总体来看网络带宽还是使用很充分的。

select from gp_segment_configuration where status='u'

select from gp_segment_configuration where status='u' and role!=preferred_role;

gprecoverseg -r

select from gp_segment_configuration where status='u' and role!=preferred_role;

经过测试，重启节点到数据修复，近50G数据耗时3分钟左右

6集群优化问题梳理

1）部署架构优化和迭代

对于优化问题，是本次测试中尤其关注，而且争议较多的部分。 

首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。

数据集市的集群部分因为节点相对较少，所以就选用了第二套方案

实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。

所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。

这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。

在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。

所以经过对比后，还是选择了方案2的混合部署模式。

2）SQL性能优化的分析

此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。 

在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。

性能较差的SQL执行计划：

# explain analyze select count()from customer;

QUERY PLAN   

Aggregate  (cost=00043100 rows=1 width=8) (actual time=2479291624792916 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00043100 rows=1 width=1) (actual time=325516489394 rows=150000000 loops=1)

         ->  Seq Scan on customer  (cost=00043100 rows=1 width=1) (actual time=07801267878 rows=4172607 loops=1)

Planning time: 4466 ms

   (slice0)    Executor memory: 680K bytes

   (slice1)    Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 24832611 ms

(9 rows)

Time: 24892500 ms

性能较好的SQL执行计划：

# explain analyze select count()from customer;                            

QUERY PLAN

Aggregate  (cost=00084208 rows=1 width=8) (actual time=15193111519311 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00084208 rows=1 width=8) (actual time=6347871519214 rows=36 loops=1)

         ->  Aggregate  (cost=00084208 rows=1 width=8) (actual time=14732961473296 rows=1 loops=1)

               ->  Seq Scan on customer  (cost=00083433 rows=4166667 width=1) (actual time=0758438319 rows=4172607 loops=1)

Planning time: 5033 ms

   (slice0)    Executor memory: 176K bytes

   (slice1)    Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 1543611 ms

(10 rows)

Time: 1549324 ms

很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：

analyze customer;

但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。

3）集群配置优化

此外也做了一些集群配置层面的优化，比如对缓存做了调整。 

gpconfig -c statement_mem -m 2457600 -v 2457600

gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000

7集群优化数据

最后来感受下集群的性能：

1）10个物理节点，（6+6）10+2

tpch_1t=# iming on

Timing is on

tpch_1t=# select count()from customer;

   count   

-----------

150000000

(1 row)

Time: 1235801 ms

tpch_1t=# select count()from lineitem;

   count    

------------

5999989709

(1 row)

Time: 10661756 ms

2）6个物理节点，（6+6）6

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1346833 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 18145092 ms

3）4个物理节点，（6+6）4

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1531621 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 25072501 ms

4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。

在1T基准下的基准测试表现：

1 利用节点名称的唯一性来实现共享锁

ZooKeeper抽象出来的节点结构是一个和unix文件系统类似的小型的树状的目录结构。ZooKeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在Zookeeper目录/test目录下创建，两个客户端创建一个名为Lock节点，只有一个能够成功。

算法思路: 利用名称唯一性，加锁操作时，只需要所有客户端一起创建/test/Lock节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/test/Lock节点，其余客户端再次进入竞争创建节点，直到所有客户端都获得锁。

基于以上机制，利用节点名称唯一性机制的共享锁算法流程如图所示：

该共享锁实现很符合我们通常多个线程去竞争锁的概念，利用节点名称唯一性的做法简明、可靠。

由上述算法容易看出，由于客户端会同时收到/test/Lock被删除的通知，重新进入竞争创建节点，故存在"惊群现象"。

使用该方法进行测试锁的性能列表如下：

总结 这种方案的正确性和可靠性是ZooKeeper机制保证的，实现简单。缺点是会产生“惊群”效应，假如许多客户端在等待一把锁，当锁释放时候所有客户端都被唤醒，仅仅有一个客户端得到锁。

2 利用临时顺序节点实现共享锁的一般做法

首先介绍一下，Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/lock/0000000001、/lock/0000000002、/lock/0000000003。

ZooKeeper中还有一种名为临时节点的节点，临时节点由某个客户端创建，当客户端与ZooKeeper集群断开连接，则开节点自动被删除。

利用上面这两个特性，我们来看下获取实现分布式锁的基本逻辑：

客户端调用create()方法创建名为“locknode/guid-lock-”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。

客户端调用getChildren(“locknode”)方法来获取所有已经创建的子节点，同时在这个节点上注册上子节点变更通知的Watcher。

客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁。

如果在步骤3中发现自己并非是所有子节点中最小的，说明自己还没有获取到锁，就开始等待，直到下次子节点变更通知的时候，再进行子节点的获取，判断是否获取锁。

释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。

上面这个分布式锁的实现中，大体能够满足了一般的分布式集群竞争锁的需求。这里说的一般性场景是指集群规模不大，一般在10台机器以内。

不过，细想上面的实现逻辑，我们很容易会发现一个问题，步骤4，“即获取所有的子点，判断自己创建的节点是否已经是序号最小的节点”，这个过程，在整个分布式锁的竞争过程中，大量重复运行，并且绝大多数的运行结果都是判断出自己并非是序号最小的节点，从而继续等待下一次通知——这个显然看起来不怎么科学。客户端无端的接受到过多的和自己不相关的事件通知，这如果在集群规模大的时候，会对Server造成很大的性能影响，并且如果一旦同一时间有多个节点的客户端断开连接，这个时候，服务器就会像其余客户端发送大量的事件通知——这就是所谓的惊群效应。而这个问题的根源在于，没有找准客户端真正的关注点。

我们再来回顾一下上面的分布式锁竞争过程，它的核心逻辑在于：判断自己是否是所有节点中序号最小的。于是，很容易可以联想的到的是，每个节点的创建者只需要关注比自己序号小的那个节点。

3、利用临时顺序节点实现共享锁的改进实现

下面是改进后的分布式锁实现，和之前的实现方式唯一不同之处在于，这里设计成每个锁竞争者，只需要关注”locknode”节点下序号比自己小的那个节点是否存在即可。

算法思路：对于加锁操作，可以让所有客户端都去/lock目录下创建临时顺序节点，如果创建的客户端发现自身创建节点序列号是/lock/目录下最小的节点，则获得锁。否则，监视比自己创建节点的序列号小的节点（比自己创建的节点小的最大节点），进入等待。

对于解锁操作，只需要将自身创建的节点删除即可。

具体算法流程如下图所示:

使用上述算法进行测试的的结果如下表所示：

该算法只监控比自身创建节点序列号小(比自己小的最大的节点)的节点，在当前获得锁的节点释放锁的时候没有“惊群”。

总结 利用临时顺序节点来实现分布式锁机制其实就是一种按照创建顺序排队的实现。这种方案效率高，避免了“惊群”效应，多个客户端共同等待锁，当锁释放时只有一个客户端会被唤醒。

4、使用menagerie

其实就是对方案3的一个封装，不用自己写代码了。直接拿来用就可以了。

menagerie基于Zookeeper实现了javautilconcurrent包的一个分布式版本。这个封装是更大粒度上对各种分布式一致性使用场景的抽象。其中最基础和常用的是一个分布式锁的实现： orgmenagerielocksReentrantZkLock，通过ZooKeeper的全局有序的特性和EPHEMERAL_SEQUENTIAL类型znode的支持，实现了分布式锁。具体做法是：不同的client上每个试图获得锁的线程，都在相同的basepath下面创建一个EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要创建的是临时znode，创建连接断开时会自动删除； SEQUENTIAL表示要自动在传入的path后面缀上一个自增的全局唯一后缀,作为最终的path。因此对不同的请求ZK会生成不同的后缀，并分别返回带了各自后缀的path给各个请求。因为ZK全局有序的特性，不管client请求怎样先后到达，在ZKServer端都会最终排好一个顺序，因此自增后缀最小的那个子节点，就对应第一个到达ZK的有效请求。然后client读取basepath下的所有子节点和ZK返回给自己的path进行比较，当发现自己创建的sequential node的后缀序号排在第一个时，就认为自己获得了锁；否则的话，就认为自己没有获得锁。这时肯定是有其他并发的并且是没有断开的client/线程先创建了node。

分布式与集群是不一样的，简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行改任务需10小时。

采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。

而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，10小后，10个任务同时完成，这样，整体来看，还是1小时内完成一个任务。

扩展资料

分布式系统可以分为机体内系统、建筑物内系统、建筑物间系统和不同地理范围的区域系统等，它们的耦合度依次由高到低按应用领域的性质决定耦合度，可以分成三类：

一、是面向计算任务的分布并行计算机系统和分布式多用户计算机系统，它们要求尽可能高的耦合度，以便发展成为能分担大型计算机和分时计算机系统所完成的工作。

二、是面向管理信息的分布式数据处理系统。耦合度可以适当降低。

三、是面向过程控制的分布式计算机控制系统。耦合度要求适中，当然对于某些实时应用，其耦合度的要求可能很高。

一、集群的基本概念

有一种常见的方法可以大幅提高服务器的安全性，这就是集群。

Cluster集群技术可如下定义：一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。

大多数模式下，集群中所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。Cluster必须可以协调管理各分离的组件的错误和失败，并可透明地向Cluster中加入组件。

一个Cluster包含多台（至少二台）拥有共享数据存储空间的服务器。任何一台服务器运行一个应用时，应用数据被存储在共享的数据空间内。每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间上。

Cluster内各节点服务器通过一内部局域网相互通讯。当一台节点服务器发生故障时，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。当一个应用服务发生故障时，应用服务将被重新启动或被另一台服务器接管。当以上任一故障发生时，客户将能很快连接到新的应用服务上。

二、集群的硬件配置

镜像服务器双机

集群中镜像服务器双机系统是硬件配置最简单和价格最低廉的解决方案，通常镜像服务的硬件配置需要两台服务器，在每台服务器有独立操作系统硬盘和数据存贮硬盘，每台服务器有与客户端相连的网卡，另有一对镜像卡或完成镜像功能的网卡。

镜像服务器具有配置简单，使用方便，价格低廉诸多优点，但由于镜像服务器需要采用网络方式镜像数据，通过镜像软件实现数据的同步，因此需要占用网络服务器的CPU及内存资源，镜像服务器的性能比单一服务器的性能要低一些。

有一些镜像服务器集群系统采用内存镜像的技术，这个技术的优点是所有的应用程序和网络操作系统在两台服务器上镜像同步，当主机出现故障时，备份机可以在几乎没有感觉的情况下接管所有应用程序。因为两个服务器的内存完全一致，但当系统应用程序带有缺陷从而导致系统宕机时，两台服务器会同步宕机。这也是内存镜像卡或网卡实现数据同步，在大数据量读写过程中两台服务器在某些状态下会产生数据不同步，因此镜像服务器适合那些预算较少、对集群系统要求不高的用户。

硬件配置范例：

网络服务器 两台

服务器操作系统硬盘 两块

服务器数据存贮硬盘 视用户需要确定

服务器镜像卡（部分软件可使用标准网卡） 两块

网络服务网卡 两块三、双机与磁盘阵列柜

与镜像服务器双机系统相比，双机与磁盘阵列柜互联结构多出了第三方生产的磁盘阵列柜，目前，豪威公司、精业公司等许多公司都生产有磁盘阵列柜，在磁盘阵列柜中安装有磁盘阵列控制卡，阵列柜可以直接将柜中的硬盘配置成为逻辑盘阵。磁盘阵列柜通过SCSI电缆与服务器上普通SCSI卡相连，系统管理员需直接在磁盘柜上配置磁盘阵列。

双机与磁盘阵列柜互联结构不采用内存镜像技术，因此需要有一定的切换时间（通常为60？D？D180秒），它可以有郊的避免由于应用程序自身的缺陷导致系统全部宕机，同时由于所有的数据全部存贮在中置的磁盘阵列柜中，当工作机出现故障时，备份机接替工作机，从磁盘阵列中读取数据，所以不会产生数据不同步的问题，由于这种方案不需要网络镜像同步，因此这种集群方案服务器的性能要比镜像服务器结构高出很多。

双机与磁盘阵列柜互联结构的缺点是在系统当中存在单点错的缺陷，所谓单点错是指当系统中某个部件或某个应用程序出现故障时，导致所有系统全部宕机。在这个系统中磁盘阵列柜是会导致单点错，当磁盘阵列柜出现逻辑或物理故障时，所有存贮的数据会全部丢失，因此，在选配这种方案时，需要选用一个品质与售后服务较好的产品。

硬件配置范例：

网络服务器 两台

服务器操作系统硬盘 两块

第三方生产的磁盘阵列柜 一台

磁盘柜专用SCSI电线 两根

磁盘阵列柜数据存贮硬盘 视用户需求确定

网络服务网卡 两块

除此之外，一些厂商还有更优秀的技术的解决方案，比如 HP

四、HP双机双控容错系统

HP NetServer为双机双控容错系统提供了高品质和高可靠的硬件基础……

HP双机双控容错系统结合了HP服务器产品的安全可靠性与Cluster技术的优点，相互配合二者的优势。

硬件配置范例：

HP L系统的网络服务器 两台

服务器操作系统硬盘 两块

HP硬盘存贮柜（SS/6，RS/8，RS/12） 一台

磁盘柜专用SCSI集群适配电缆 两根

磁盘柜数据存贮硬盘 视用户需求确定

HP集群专用阵列卡 两块

网络服务网卡 两块五、HP光纤通道双机双控集群系统

光纤通道是一种连接标准，可以作为SCSI的一种替代解决方案，光纤技术具有高带宽、抗电磁干扰、传输距离远、质量高、扩展能力强等特性，目前在FC-AL仲裁环路上可接入126个设备。

光纤设备提供了多种增强的连接技术，大大方便了用户使用。服务器系统可以通过光缆远程连接，最大可跨越10公里的距离。它允许镜像配置，这样可以改善系统的容错能力。服务器系统的规模将更加灵活多变。SCSI每条通道最多可连接15个设备，而光纤仲裁环路最多可以连接126个设备。

光纤集群系统组成：

HP光纤集群系统硬件设备包括有两台HP服务器（需支持光纤卡，目前有LC2000、LH3000、LH4、 LH6000、LT6000、LXr8000、LXR8500）及光纤适配卡，可以使用RS/12FC光纤磁盘阵列柜，需另加一对或两对网卡用于心跳检测和与客户端连接。在配置过程中还需另外选配光纤卡到光纤存贮设备的光纤电缆。

硬件配置：

HPL系统的网络服务器 两台

服务器操作系统硬盘 两块

HP光纤阵列存贮柜（RS/12FC） 一台

光纤磁盘柜专用光纤电缆 两根

光纤磁盘柜数据存贮硬盘 视用户需求确定

HP光纤适配卡 两块

网络服务网卡 两块

六、集群的软件配置

基于NT平台的集群软件

Microsoft的MSCS，也有许多第三方的专业软件公司开发的集群软件，如豪威的DATAWARE，VIN CA公司的STANDBY　SERVER，NSI公司的DOUBLE-TAKE

MS　WolfPack的特点

MS WolfPack是MS　Cluster server的别称，是 微软针对Cluster技术研制开发的双机软件。它集成在NT SERVER上，支持由二台机器组成的双机系统，提供一种高可用且易管理的应用环境。

主要特点：

自动检测和修复服务器或应用程序的错误

可实现对服务器中应用程序的切换

可通过TCP/IP连接各种客户端，如MS-DOS、WINDOWS　3X/9X/NT，Apple Macintosh、UNIX等

生产主机无需人工干涉即可自动恢复数据并接管任务

易管理性：

可自动审核服务器和应用程序的工作状态

可建立高可用性的应用程序、文件共享、打印请求等

可灵活设置应用程序和数据的恢复策略

简单操作即可进行应用程序的离线，重新再线，服务器间的迁移。

目前，WINDOWS 2000 Advanced Server与WINDOWS 2000 DataCenter Server都集成有更先进集群技术。

其它的网络操作系统平台上也有许多集群软件，比如：

基于novell平台的集群软件有Novell HA Server、Novell SFT III

基于sco UNIX平台的集群软件有Sentinel集群软件

基于Linux平台的集群软件有TurboCluster

七、集群技术的发展趋势

集群技术随着服务器硬件系统与网络操作系统的发展将会在可用性、高可靠性、系统冗余等方面逐步提高。未来的集群可以依靠集群文件系统实现对系统中的所有文件、设备和网络资源的全局访问，并且生成一个完整的系统映像。这样，无论应用程序在集群中的哪台服务器上，集群文件系统允许任何用户（远程或本地）都可以对这个软件进行访问。任何应用程序都可以访问这个集群任何文件。甚至在应用程序从一个节点转移到另一个节点的情况下，无需任何改动，应用程序就可以访问系统上的文件。

在今天，利用服务器的集群技术，通过周密计划和网络维护，系统破坏的机率是非常小的。所以，企业服务器的稳定必须使用集群技术。

集群和负载均衡的区别如下：

1、集群(Cluster)

所谓集群是指一组独立的计算机系统构成的一个松耦合的多处理器系统,它们之间通过网络实现进程间的通信应用程序可以通过网络共享内存进行消息传送,实现分布式计算机

2、负载均衡(Load Balance)

网络的负载均衡是一种动态均衡技术,通过一些工具实时地分析数据包,掌握网络中的数据流量状况,把任务合理均衡地分配出去这种技术基于现有网络结构,提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法,加强了网络数据处理能力,提高了网络的灵活性和可用性

3、特点

(1)高可靠性(HA)利用集群管理软件,当主服务器故障时,备份服务器能够自动接管主服务器的工作,并及时切换过去,以实现对用户的不间断服务

(2)高性能计算(HP)即充分利用集群中的每一台计算机的资源,实现复杂运算的并行处理,通常用于科学计算领域,比如基因分析化学分析等

(3)负载平衡即把负载压力根据某种算法合理分配到集群中的每一台计算机上,以减轻主服务器的压力,降低对主服务器的硬件和软件要求

LVS系统结构与特点

1 Linux Virtual Server:简称LVS是由中国一个Linux程序员章文嵩博士发起和领导的,基于Linux系统的服务器集群解决方案,其实现目标是创建一个具有良好的扩展性高可靠性高性能和高可用性的体系许多商业的集群产品,比如RedHat的Piranha Turbo Linux公司的Turbo Cluster等,都是基于LVS的核心代码的

2 体系结构:使用LVS架设的服务器集群系统从体系结构上看是透明的,最终用户只感觉到一个虚拟服务器物理服务器之间可以通过高速的 LAN或分布在各地的WAN相连最前端是负载均衡器,它负责将各种服务请求分发给后面的物理服务器,让整个集群表现得像一个服务于同一IP地址的虚拟服务器

3 LVS的三种模式工作原理和优缺点: Linux Virtual Server主要是在负载均衡器上实现的,负载均衡器是一台加了 LVS Patch的22x版内核的Linux系统LVS Patch可以通过重新编译内核的方法加入内核,也可以当作一个动态的模块插入现在的内核中

推荐你看看这个服务器产品的集群方案，性价比很高

产品型号：ZI11S4-4532E

产品类型：单路四核机架式服务器

处 理 器：Xeon E3-1220

V3

内 存：4G DDR3 ECC

硬 盘：HD SATA3 500G

机 构：1U机架式

产品地址：http://wwwzrwaycom/server/product_param/1003/7993html