服务器中的集群与网络中的集群虽然都是为了提供冗余的服务能力,但是在实现上有一定的差异,主要原因为网络冗余只需要实现流量有冗余路径,当主的链路故障后,流量可以通过备的链路通行即可。对于有状态的如TCP协议,某些设备如防火墙需要对其进行状态检测,那么只需要在主备设备之间开启会话同步功能即可。但是对于服务器而言较为复杂,主要原因是因为服务器作为流量的终结点,是需要直接对外提供服务的,其上存储的数据则需要被服务访问,不再是流量穿越就可以。本人一起从事网络相关的工作,在第一次接触服务器集群时,对其实现原理机制完全不了解,在反复学习后才有一些粗浅的认识,本篇先简单的介绍一下服务器集群原理,后续慢慢对学习中的实验进行总结。
服务器集群主要实现服务的冗余能力以及高性能,从目前我所了解到的来看,主要有两种类型:
Split brain:集群节点无法有效获取其他节点的状态信息时,产生脑裂,出现资源抢占情况。这种情况在网络中我们称其为双主状态。
脑裂最严重的后果是抢占共享存储导致数据损坏。
当集群主出现故障时,备设备需要取代主设备的功能,但是如何确认是对端故障,而不是自身故障呢?
具体实现:
Massage Layer:
Heartbeat:v1(古老版本),v2(成熟版本),v3 ,监听UDP协议的694号端口
Heartbeat v3分裂为多个独立项目:
Heartbeat v3:MessageLayer层
Pacemaker:
cluster-glue
Corosync:Redhat6.0以后默认使用的软件:corosync,性能比heartbeat优越,但是不具有pacemaker的功能,需要配合使用,组合后相当于heartbeat v3
Cman:redhat5.0,cluster manager:红帽上有专门的RHCS套件,cman是RHCS的核心组件
Keepalived:本身为了LVS的DC高可用而设计
Ultramonkey:
CRM:
Heartbeat v1自带管理器功能,haresources,为heartbeat v1提供CRM;
Heartbeat v2 自带的资源管理器,为heartbeat v2提供CRM;
Haresources:兼容V1版本
Crm:需要监听在某个接口,可以通过图形界面管理
Heartbeat v3:
Pacemaker:Heartbeat v3 中CRM 发展为独立的项目。为heartbeatv3或者corosync提供CRM功能。
Rgmanager:资源组管理器,cman专门提供的CRM
Resource Type:资源类别
Primitive:主资源,某一个时刻只能运行在一个节点上,比如说对外提供服务的虚拟IP地址;
Clone:将主资源克隆一份,资源必须同时运行在多个节点上,比如STONITH管理的RA;
Group:多个资源归为一类,当作一个容器,同进同退;
Master/save:一种特殊的clone资源,只能运行在两个节点上,资源具有主从关系。
RA 类别:接收LRM传递过来的指令,完成对资源的控制
Legacy heartbeat v1 RA:专用于heartbeat v1
LSB:(/etc/rc.d/init.d/)遵循linux SHELL编程风格,可以接收四种参数:start|stop|restart|status.
OCF:open cluster framework,除了上述四种参数,还可以接受类似monitor等参数,可能由不同的vendor提供
Pacemaker
Linbit(drbd)
STONITH:专门管理硬件 STONITH设备。
原文地址:http://blog.51cto.com/9652359/2106092