Linux(HA)高可用集群框架及Corosync详解
集群系统:高可扩展性、高可用性、高性能、高性价比
一、Linux HA cluster架构
1.集群扩展方式:
1).scale on:向上扩展,即升级服务器硬件
扩大服务器的内存容量、增加cpu数量,在一定的范围内能增大服务器性能。
缺点:随着cpu个数的增加需要给CPU仲裁,此外CPU个数的增加会增大资源的竞争性,
所以超出一定范围后,反而会呈现下降的趋势。
2).scale out:向外扩展,即增加服务器数量
优点:增减服务器很方便,而且没有向上扩展随着增加性能下降。
缺点:性价比。
2.集群类别:LB, HA, HP
1).LB: Load Balancing:负载均衡集群
负载均衡集群中有一个Director分发器(调度器),它处在多台服务器的上面,
分发器根据内部锁定义的规则或调度方式从下面的服务器群中选择一个以此来响应客户端发送的请求。
传输层:lvs
应用层:nginx, haproxy, httpd, perlbal, ats, varnish
2).HA:High Availability 高可用集群
顾名思义高可用集群使服务的可用性增高,实现在某台服务器宕机后不会导致服务中断。
其工作模式是将故障的服务器中的服务转交给一个正常工作的服务器,从而实现服务的高可用。
一般来说我们集群中工作在前端(分发器)的服务器都会对我们的后端服务器做一个健康检查,如果发现我们服务器当机就不会对其在做转发。
vrrp(虚拟路由冗余协议)实现: keepalived
AIS: heartbeat, OpenAIS, corosync/pacemaker, cman/rgmanager(conga) RHCS
3).HP:Hight Performance 高性能集群
高性能的集群是当某一个任务量非常大的时,通过一个集群共同来完成。这种处理方式我们称为并行处理集群,
并行处理集群是将大任务划分为小任务,分别进行处理的机制。一般高性能集群应用于科学研究或大数据运算等方面。
并行处理集群:Hadoop
3.分布式系统的CAP原则
数据一致性(consistency):如果系统对一个写操作返回成功,那么之后的读请求都必须读到这个新数据;如果返回失败,那么所有读操作都不能读到这个数据,对调用者而言数据具有强一致性
服务可用性(availability):所有读写请求在一定时间内得到响应,可终止、不会一直等待
分区容错性(partition-tolerance):在网络分区的情况下,被分隔的节点仍能正常对外服务
4.高可用集群故障场景
1).硬件故障:设计缺陷、使用过久自然损坏、人为故障等
network partition:网络分区:在系统中,通过交换机相连的两个冗余节点,因为交换机间连接的网线或管端交换机出现故障导致两个冗余节点不能互信,而本身节点并没有问题
2).软件故障:设计缺陷、程序bug、误操作等
5.系统可靠度(可用性)
计算公式:R=MTBF/(MTBF+MTTR)
MTBF: Mean Time Between Failure 即平均无故障时间
MTTR: Mean Time To Restoration 即平均故障修复时间,指两个相邻故障间的时间的平均值;
值区间:0
90%, 95%, 99% 99.9%, 99.99%, 99.999% 6.高可用集群的可用方案 RHCS: Red Hat Cluster Suite RHEL5: cman + rgmanager + conga (ricci/luci) RHEL6: cman + rgmanager + conga (ricci/luci) corosync + pacemaker corosync + cman + pacemaker RHEL7: corosync + pacemaker centos6 heartbeat v1(haresources) heartbeat v2 (crm) heartbeat v3 + pacemaker X corosync + pacemaker corosync v1 + pacemaker (plugin) corosync v2 + pacemaker (standalone service) cman + rgmanager corosync + cman + pacemaker corosync v1 + cman + pacemaker centos7 corosync + pacemaker keepalived 7.高可用集群结构层:(从下往上) 结构图及各层说明见如下HA Cluster架构图
1).Messaging Layer:消息层,传递心跳以及集群事务信息
heartbeat v1, v2, v3
corosync v1, v2(votequorum)
OpenAIS
2).CRM:Cluster Resource Manager:集群资源管理器
根据消息层传递的健康信息来决定服务的启动、停止和资源的定义、转移、分配。每一个节点上都包含一个CRM,在CRM中还包含LRM和DC等组件。 DC位于主节点上,可以理解为事务协调员,PE和TE也是DC的子组件。
作用:使本身不具备的高可用能力的服务也能够运行在高可用集群中,并以高可用模式提供服务
传递方式:CRM-->LRM:Local Resource Manager -->Pengine:Policy Engine(只运行在主节点上,决策)
CIB:Cluster Information Base:集群信息库
heartbeat v1 haresources (配置接口:配置文件haresources)
heartbeat v2 crm (在每个节点运行一个crmd(5560/tcp)守护进程,有命令行接口crmsh; GUI: hb_gui)
heartbeat v3, pacemaker (配置接口:crmsh, pcs; GUI: hawk(suse), LCMC, pacemaker-gui)
rgmanager (配置接口:cluster.conf, system-config-cluster, conga(webgui), cman_tool, clustat)
集群的全生命周期管理工具:
pcs: agent(pcsd)
crmsh: agentless (pssh)
独立服务:
pacemaker:CRM-->LRM-->Pengine-->CIB
重要的基本组件:cib/crmd/lrmd/pengine
配置接口:crmsh (agentless), pssh 并行ssh
pcs (agent、a/s), pcsd:由pcsd守护进程负责接收pcs发出的命令并执行
conga(ricci/luci)
实现方式:group(资源组、资源类型), constraint(约束)
rgmanager(cman)
resource group
failover domain
3).RA: Resource Agent:资源代理
作用:实际负责操纵(启动、停止、监控等)资源,LRM用于管理本地资源,不能操纵资源,当需要操纵资源时会调用RA来执行,RA通常是脚本文件,在一个节点上可能有多个RA;
RA类型:
LSB: /etc/rc.d/init.d/目录下的脚本; centos5/6/7
systemd:/usr/lib/systemd/system 真正读取:/etc/systemd/system/multi-user.wants 处于enable状态的服务;
OCF:Open Cluster Framework开放集群框架,公司或组织自行研发的脚本: [provider]
heartbeat
pacemaker
linbit
service:通用服务类型: /etc/ha.d/haresources.d/目录下的脚本;
stonith:STONITH:shoot the other node on the head 节点级别隔离:专用于stonith设备的类别
Fence: 资源级别的隔离
8.配置集群的前提:
(1).时间同步
(2).基于当前正在使用的主机名互相访问
(3) 是否会用到仲裁设备
9.HA Cluster工作模型
A/P:active/passive; 两节点集群; 一般只配置一个高可用服务
全局属性:当前集群不拥有法定票数时操作,默认至少三个节点才能使用quorum
without-quorum-policy={stop(关闭)|ignore(忽略)|suicide(自杀)|freeze(冻结,不接受新请求,旧请求服务到停止)}
A/A:双主模型
N-M: N个节点,M个服务,N>M;
N-N: N个节点,N个服务;
二、Corosync:工作于Messaging Layer消息层
1.简述:Corosync是OpenAIS发展到Wilson版本后衍生出来的开放性集群引擎工程。它是OpenAIS工程的一部分,是OpenAIS是具体实现。
1).发展历程:AIS-->OpenAIS-->Corosync
AIS:应用接口规范(AIS)是用来定义应用程序接口(API)的开放性规范的集合。简单地说,AIS就是一个通用的应用程序编程接口
OpenAIS:基于SA Forum 标准的集群框架的应用程序接口规范,是AIS的子项目
2).结构组成:Corosync执行高可用应用程序的通信组系统,由以下部件组成:
A closed process group communication model:一个封闭的程序组通信模式,这个模式提供一种虚拟的同步方式来保证能够复制服务器的状态。
A simple availability manager:一个简单可用性管理组件,这个一个封闭的程序组管理组件可以重新启动应用程序的进程当它失败后。
A configuration and statistics in-memory database:一个配置和内存数据的统计,内存数据能够被设置,回复,接受通知的更改信息。
A quorum system:一个投票系统,定额完成或者丢失时通知应用程序。
2.vote system: 投票系统
少数服从多数:quorum
with quorum: 拥有法定票数 > total/2
without quorum: 不拥有法定票数 <= total/2
[stop|ignore|suicide|freeze]
两个节点(偶数个节点):增加仲裁机制
Ping node
qdisk
3.Heartbeat信息传递
Unicast, udpu 单播
Mutlicast, udp 组播(多播)
Broadcast 广播
组播地址:用于标识一个IP组播域;IANA把D类地址留给组播使用:224.0.0.0-239.255.255.255
永久组播地址:224.0.0.0-224.0.0.255
临时组播地址:224.0.1.0-238.255.255.255
本地组播地址:239.0.0.0-239.255.255.255
4.Corosync配置文件说明
[root@cen7 home]# cd /etc/corosync/
[root@cen7 corosync]# ls
corosync.conf corosync.conf.example corosync.conf.example.udpu corosync.xml.example uidgid.d
[root@cen7 corosync]# cat corosync.conf
totem {
version: 2
#totem:图层,定义集群信息传递协议
crypto_cipher: aes128
crypto_hash: sha1
#安全认证相关
secauth: on
#开启安全加密功能
interface {
#interface:定义集群信息传递接口
ringnumber: 0
#主心跳信息传递接口
bindnetaddr: 192.168.88.0
#绑定的网络地址,方式属于该网段的网络地址都属于ring0
mcastaddr: 239.185.1.188
#组播地址
mcastport: 5405
#组播地址
ttl: 1
}
#transport: udpu
#传播协议:单播传输参数udpu
#transport参数说明:
#如果将 broadcast 设置为 yes ,集群心跳将通过广播实现。设置该参数时,不能设置 mcastaddr 。
#transport 配置项决定集群通信方式。要完全禁用组播,应该配置单播传输参数 udpu 。
#这要求将所有的节点服务器信息写入 nodelist ,也就是需要在配署 HA 集群之前确定节点组成。默认配置是 udp通信方式类型还支持udpu和iba。
}
nodelist {
#nodelist:定义节点信息
#在 nodelist 之下可以为某一节点设置只与该节点相关的信息,这些设置项只能包含在 node 之中,即只能对属于集群的节点服务器进行设置,
#而且只应包括那些与默认设置不同的参数。每台服务器都必须配置 ring0_addr。
node {
ring0_addr: 192.168.88.132
nodeid: 1
}
node {
ring0_addr: 192.168.88.133
nodeid: 2
}
node {
ring0_addr: 192.168.88.134
nodeid: 3
}
}
logging {
#日志子系统
fileline: off
to_stderr: no
#是否发给标准错误输出
to_logfile: yes
#日志文件
logfile: /var/log/cluster/corosync.log
to_syslog: no
#是否发给系统日志,考虑到I/O性能,建议只开一个
debug: off
#是否输出调试信息
timestamp: on
#是否记录时间戳,
#注意:每次记录时间戳都得获取一次系统时间,发起一次系统调用,日志量非常大时会不断发起系统调用,可能影响
logger_subsys {
#logger子系统中的QUORUM子系统也要记录日志
subsys: QUORUM
debug: off
}
}
quorum {
#定义投票系统
provider: corosync_votequorum
}