HA 四个层次:
1.message layer / infrastructure
心跳
2.ccm 控制台
3.resources allocated 资源分配
4.resources agent 资源代理
第一层 message layer 主要可以由heartbest keepalived corosync/openais 来实现
第三层: 由pacemaker crm 来提供资源分配
案例:
实现两个节点的高可用性群集,用corosync/openais 来实现。
Node1 ip地址:192.168.1.15
Node2 ip地址:192.168.1.20
Vip :192.168.1.100
步骤:
1.在做该案例之前,首先确保自己的yum仓库是否完整,由于在这个案例中牵扯到群集,所以要安装cluster仓库。
各项都要确保时钟同步: hwclock -s
[root@node1 ~]# hwclock -s
2.无障碍密码通讯方式:
[root@node1 ~]# ssh-keygen -t rsa
[root@node1 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@node2 //将node1的钥匙传给node2
比如我们将node1中的/etc/hosts文件 拷贝到 node2中的/etc下:
[root@node1 ~]# scp /etc/hosts node2:/etc
查看node2中的hosts文件内容:
[root@node2 ~]# vim /etc/hosts
这样就实现了两节点之间无障碍密码传送文件和执行一些指令。
3.安装corosync软件包:
红色的都是要安装的。
[root@node1 ~]# yum localinstall *.rpm --nogpgcheck //将本地红色软件包全部安装
4.首先来设置node1这个节点:
安装完成后切换到corosync目录下
[root@node1 ~]# cd /etc/corosync/ 会看到corosync的样本文件
[root@node1 corosync]# cp corosync.conf.example corosync.conf //将样本文件变成正式配置文件
[root@node1 corosync]# vim corosync.conf //编译该文件
需要额外补充一点东西,在下面空白行加入以下内容:
[root@node1 corosync]# mkdir /var/log/cluster //创建该目录
在另外的一个节点上,也就是node2上创建日志目录
[root@node1 corosync]# ssh node2 'mkdir /var/log/cluster'
为了便其他主机加入该集群,需要认证,生成一个authkey
[root@node1 corosync]# corosync-keygen
将上图中的文件连同权限一起远程拷贝到node2中:
[root@node1 corosync]# scp -p authkey corosync.conf node2:/etc/corosync/
[root@node1 corosync]# service corosync start //在node1上启动corosync服务
[root@node1 corosync]# ssh node2 '/etc/init.d/corosync start'
Starting Corosync Cluster Engine (corosync): [ OK ] //在node1上启动node2的该服务
下面来验证corosync引擎是否正常启动了:
[root@node1 corosync]# grep -i -e "corosync cluster engine" -e "configuration file" /var/log/messages
查看初始化成员节点通知是否发出:
[root@node1 corosync]# grep -i totem /var/log/messages
检查过程中是否有错误产生:
[root@node1 corosync]# grep -i error: /var/log/messages |grep -v unpack_resources
(为了检查stonith的错误,因为我们在这里没有安装stonith,所以得将stonith去掉,不去掉的话会报错)
检查pacemaker时候已经启动了:
[root@node1 corosync]# grep -i pcmk_startup /var/log/messages
在节点2上同样做以上相同的验证.
5.在node1节点上查看集群的成员状态:
[root@node1 corosync]# crm status
下面来提供高可用服务:
在corosync中,定义服务可以用两种接口
(1)图形接口 (使用hb――gui)
(2)crm (pacemaker 提供,是一个shell)
查看配置信息:
如何验证该文件的语法错误:
[root@node1 corosync]# crm_verify -L
上述出错时由于stonith,因为我们没有stonith,在高可用的环境里面,会禁止使用任何支援,所以我们得禁用掉stonith。
[root@node1 corosync]# crm //进入crm界面
crm(live)# configure //进入配置模式
crm(live)configure# property stonith-enabled=false //禁用stonith
crm(live)configure# commit //提交上述修改内容
6.下面来定义资源:
集群的资源类型有4种
primitive 本地主资源 (只能运行在一个节点上)
group 把多个资源轨道一个组里面,便于管理
clone 需要在多个节点上同时启用的 (如ocfs2 ,stonith ,没有主次之分)
master 有主次之分,如drbd
我们来提供三种资源: ip地址 httpd服务 共享存储
[root@node1 corosync]# crm
crm(live)# configure
crm(live)configure# ra
crm(live)configure ra# classes
heartbeat
lsb
ocf / heartbeat pacemaker
Stonith 1//查看资源代理
crm(live)configure ra# list heartbeat //列出heartbeat这个资源代理所管辖的资源
配置ip地址资源:
crm(live)configure# primitive webip ocf:heartbeat:IPaddr params ip=192.168.1.100
在这里看看你两个节点的虚拟机上是否安装httpd,没安装的话分别安装。
下面分别在每个节点上设置一个简单的web网页:
[root@node1 corosync]# echo "hello" >/var/www/html/index.html
[root@node2 corosync]# echo "hahaaha" >/var/www/html/index.html
接下来定义web服务资源:
crm(live)configure# primitive webserver lsb:httpd
查看状态:
大家仔细看上图,就会发现存在一个问题:就是ip地址资源在node1上启动,但是web服务却是在node2上启动的,这样一来两个资源分别在两个节点上,这样显然是不行的。出现这样的原因就是在高可用群集中资源比较多,这样是为了将资源平衡到每一个节点上。
看下图来证实这样的问题:
为了解决这样的问题,就用到了我们上面所说的群集资源类型中group的概念:
定义组:
crm(live)configure# group web webip webserver
再次查看群集状态:
此时我们就可以来访问192.168.1.100来查看结果:
能够成功访问。
如果此时我们把node1节点停掉,那么各种资源应该流转到node2上。注意我们在停掉node1节点时,停用corosync服务,不要停用httpd服务。
[root@node1 corosync]# service corosync stop
Signaling Corosync Cluster Engine (corosync) to terminate: [ OK ]
Waiting for corosync services to unload:......... [ OK ]
[root@node1 corosync]# crm status
Connection to cluster failed: connection failed
然后我们在节点node2上查看信息状态:
可以看到node1已经offline,但是node2仍然没有运行,原因是没有票数了(without quorum)
所以我们关闭quorum:
关闭 quorum
可选的参数有如下:ignore (忽略)
freeze (冻结,表示已经启用的资源继续实用,没有启用的资源不能
启用))
stop(默认)
suicide (所有的资源杀掉)
那我们将节点node1的corosync服务启动起来, 改变quorum。
[root@node1 corosync]# crm
crm(live)# configure
crm(live)configure# property no-quorum-policy=ignore
接下来我们停用node1的corosync,查看node2的状态:
[root@node1 corosync]# service corosync stop
可见资源已经流转到node2节点上,现在登录http://192.168.1.100上查看网页状态:
变成了node2节点上web页面的内容。
如果此时将node1节点上的corosync服务开启,此时资源不会自动流转到node1上,还是在node2上。