heartbeat+drbd+nfs高可用部署
heartbeat介绍
heartbeat是一款开源提供高可用(High-Available)服务的软件。 通过HeartBeat,可以将资源(IP以及程序服务等资源)从一台已经故障的机器快速转移到另一台正常运转的机器上继续提供服务,一般称之为高可用的服务。
在实际的生产应用场景中,heartbeat的功能和另一个高可用的开源软件keepalived有很多的相同之处,在我们实际的生产业务中也是有区别的。
例如:keepalived主要是控制IP的漂移、配置,应用简单,而heartbeat则不但可以控制IP漂移,更擅长对资源服务的控制(CRM - 集群资源管理),应用比较复杂。
heartbeat工作原理
通过修改heartbeat软件的配置文件,可以指定哪台heartbeat服务器作为主服务器,则另一台将自动成为热备服务器。然后热备服务器上配置heartbeat守护程序来监听来自主服务器的心跳消息,如果热备服务器在指定之间内未监听到来自主服务器的心跳,就会启动故障转移程序,并取得主服务器上的相关资源服务器的所有权(启VIP、启应用),接替主服务器继续不间断的提供服务,从而达到资源及服务器高可用的目的。(如果设置了回切参数,主恢复时,会切回)
以上描述为heart主备模式,heartbeat还支持主主模式(配置不同业务),即两台服务器互为主备时。这时他们之间会相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的心跳报文,那么,一方就会认为对方失效或者宕机,这时每个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务,继续为用户提供服务。一般情况下,可以较好的实现一台主机故障后,企业业务仍能够不间断的持续运行。注意,所谓的业务不间断,在故障转移期间也是需要切换时间的,heartbeat的主备高可用的切换时间一般是5-20秒左右。 另外:和keeplive服务一样,heartbeat高可用是服务器级别的,不是服务级别的。可以通过简单脚本,实现软件级别的高可用。
切换的常见场景:
服务器物理宕机。(硬件损坏、OS故障) #高可用软件主要解决的目标
heartbeat服务本身故障。
心跳连接故障。 服务故障不会导致切换,可以通过服务宕机把heartbeat服务停掉。
heartbeat心跳连接
要部署heartbeat服务,至少需要两台主机来完成,那么,要实现高可用服务,这两台主机之间是如何做到互相通信和互相监测的呢?
下面是两台heartbeat主机之间通信的一些常用的可行方法:
1、 串行电缆,即串口线连接两台服务器(可选)#距离不能远 /dev/ttvS0
2、 一根以太网电缆两网卡直连(可选) #配置好IP即可,建议与生产不同网段
3、 以太网电缆,通过交换机等网络设备连接(次选,增加了交换机故障点,同时线路不是专用心跳线,容易受其他数据传输的影响,导致心跳报文发送问题)
提示:如果条件允许,上述连接可同时使用,来加大保险系数防止脑裂问题
选择方案小结:1、和数据相关业务,要求较高,可以串口和网线直连方式并用
2、web业务,可以网线直连的方式或局域网通信方式也可
heartbeat裂脑
什么是脑裂
由于两台高可用服务器之间在指定的时间内,无法互相检测到对方心跳而各自启动故障转移功能,取得了资源及服务器的所有权,而此时的两台高可用服务其对都还活着并在正常运行,这样就会导致同一个IP或服务在两端同时启动而发生冲突的严重问题,最严重的是两台主机占用同一个VIP地址,当用户写入数据时可能分别写入到两端,这样可能会导致服务器两端的数据不一致或造成数据丢失,这种情况就被称为脑裂,也有人称其为分区集群或大脑垂直分割,英文为splitbrain。
导致脑裂发生的多种原因
一般来说,脑裂的发生,有以下几个原因导致
1、高可用服务器对之间心跳线链路故障,导致无法通信
a、心跳线坏了
b、网卡及相关驱动坏了,IP配置及冲突问题
c、心跳线间连接的设备故障
d、仲裁的机器出问题
2、高可用服务器对上开启了防火墙阻挡了心跳消息传输
3、高可用服务器对上心跳网卡地址等信息配置不正确,导致发送心跳失败
4、其他服务配置不当等原因,如心跳方式不同,心跳广播冲突、软件BUG等
实际生产环境中,我们可以从以下几个方面来防止脑裂问题的发生
1、同时使用串行电缆和以太网电缆连接,同时用两条心跳线路
2、检测到脑裂时强行关闭一个心跳节点(这个功能需特殊设备支持,如Stonith、fence)。相当于程序上备节点发现心跳线故障,发送关机命令到主节点。
3、做好脑裂的监控报警(邮件、手机、值班),在问题发生时人为第一时间介入仲裁,降低损失。百度监控有上行和下行,和人工交互的过程。
当然在实施高可用方案时,要根据业务实际需求确定是否能容忍这样的损失,对于一般的网站常规业务,这个损失可控。
4、启用磁盘锁。正在服务一方锁住共享磁盘,裂脑发生时,让对方完全抢不走共享磁盘资源。但使用锁磁盘也会有个不小的问题,如果占用共享盘的一方不主动“解锁”,另一方就永远得不到共享磁盘。
现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令,后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能锁”。即,正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁,平时就不上锁。
5、报警报在服务器接管之前,给人员处理留足够时间。(报警后5分钟接管)
6、报警后,不直接自动服务器接管,而是由人为控制接管
7、增加仲裁机制,确定谁该获的资源,这有几个参考思路
a、加一个仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下参考IP,不通则表明断点在本端不仅心跳线,还有对外服务的本地网络链路断了,这样就主动放弃竞争,让能够ping通参考IP的一端去接管服务。
ping不通参考IP的一方可以自我重起以彻底释放有可能还占用着的那些共享资源(heartbeat也有此功能)
b、通过第三方软件仲裁谁该获的资源,这个在阿里集团有类似的软件应用
小结:如何开发程序判断裂脑
1、初步判断,只要备节点出现VIP,告警 (a、主机确实宕机。b、主机没宕,视为裂脑),不管哪个情况,人工查看。
2、严谨判断,备机出现VIP,并且主机及服务还活着,裂脑了。(依赖报警)
fence设备
说下内部fence设备,fence只是HA集群环境下的术语 ,在硬件领域,fence设备就是一个智能电源管理设备(IPMI)。以主流的服务器举例,fence设备在不同的服务器中的名称是不一样的,以下是不同品牌服务器对应的fence设备名称
IBM RSA
HP ILO
DELL iDRAC
小结:
大前提都是主备无法通信(心跳问题)的时候发生
1、各自ping网关,ping不通就自己关机
2、主备和仲裁设备连接,出问题的时候,把各自存活状态写入仲裁设备,由仲裁设备控制主备服务器的电源
Stonith概述(很少用)
http://czmmiao.iteye.com/blog/1174667
stonith是“shoot the other node in the head”的首字母简写,它是Heartbeat软件包的一个组件,它允许使用一个远程或“智能的”连接到健康服务器的电源设备自动重启失效服务器的电源,
stonith设备可以关闭电源并响应软件命令,运行Heartbeat的服务器可以通过串口线或网线向stonith设备发送命令,它控制高可用服务器对中其他服务器的电力供应,换句话说,主服务器可以复位备用服务器的电源,备用服务器也可以复位主服务器的电源。
注意:尽管理论上连接到远程或“智能的”循环电源系统的电力设备的数量是没有限制的,但大多数stonith实现只使用两台服务器,因为双服务器stonith配置是最简单的,最容易理解,它能够长时间运行且不会降低系统的可靠性和高可用性。
Stonith事件触发工作步骤
1、当备用服务器听不到心跳时Stontih事件开始。 注意:这并不一定意味着主服务器没有发送心跳,心跳可能有多种原因而没有抵达备用服务器,这就是为什么建议至少需要两条物理路径传输心跳以避免出现假象的原因了。
2、备用服务器发出一个Stonith复位命令到Stonith设备。
3、Stonith设备关闭主服务器的电力供应。
4、一经切断主服务器的电源,它就不能再访问集群资源,也不能再为客户端提供资源,保证客户端计算机不能访问主服务器上的资源,排除可能发生的头脑分裂状态。
5、然后备用服务器获得主服务器的资源,Heartbeat用start参数运行资源脚本,并执行ARP欺骗广播以便客户端计算机发送它们的请求到它的网络接口上。 一旦主服务器完成重启,它会尝试回收它的资源,要求备用服务器释放资源,除非两台服务器都关闭了auto_failback选项
heartbeat消息类型
heartbeat高可用软件在工作过程中,一般来说,有三种消息类型,具体为a、心跳消息 b、集群转换消息 c、重传请求
心跳消息:心跳消息约为150字节的数据包,可能为串口、单播、广播或多播的方式,控制心跳频率及出现故障要等待多久进行故障转换
集群转换消息:ip-request和ip-request-resp
当主服务器恢复在线状态时,通过ip-request消息要求备机释放主服务器失败时备服务器取得的资源,然后备份服务器关闭释放主服务器失败时取得的资源及服务 备服务器释放主服务器失败时取得的资源及服务后,就会通过ip-request-resp消息通知主服务器它不再拥有该资源及服务,主服务器收到来自备节点的ip-request-resp消息通知后,启动失败时释放的资源及服务,并开始提供正常的访问服务。
重传请求消息:rexmit-request控制重传心跳请求。此消息不太重要
提示:以上心跳控制消息都使用UDP协议发送到/etc/ha.d/ha.cf文件指定的任意端口,或指定的多播地址。
heartbeat IP地址接管和故障转移
heartbeat是通过IP地址接管和ARP广播进行故障转移的
ARP广播:在主服务器故障时,备用节点接管资源后,会立即强制更新所有客户端本地的ARP表(即清除客户端本地缓存的失败服务器的vip地址和mac地址的解析记录),确保客户端和新的主服务器对话。 提示:本节提到的客户端机器是和heartbeat高可用服务器在同一网络中的客户机,并不是最终的互联网用户,这里的客户端机器是相对heartbeat高可用服务器对说的
真实IP/VIP/IP别名/辅助IP
真实IP:又称为管理IP,一般是配置在物理网卡上的实际IP,在负载均衡及高可用环境中,管理IP是不对外提供用户访问服务的,而仅是管理服务器用
VIP:是虚拟IP,实际上就是heartbeat临时绑定在物理网上的别名IP(heartbeat3以上也采用了辅助IP),如eth:0。
在实际生产环境中,需要在DNS配置中把网站域名地址解析到这个VIP地址,提供对外服务。这样做的好处是当提供服务的服务器宕机后,在接管的服务器上会直接自动配置上同样的VIP提供服务。
Heartbeat安装与配置
1、调整系统环境,heartbeat两台机器都要做如下调整
停掉iptables selinux /etc/init.d/iptables stop [root@data-1-2 ha.d]# cat /etc/sysconfig/selinux SELINUX=disabled 调整字符集、时间同步定时任务、yum云仓库为阿里云 [root@data-1-2 ha.d]# cat /etc/sysconfig/i18n LANG="zh_CN.UTF-8" [root@data-1-2 ha.d]# crontab -l #time sync by zhangyao at 2017-10-16 */5 * * * * /usr/sbin/ntpdate time.nist.gov &>/dev/null 调整主机名 [root@data-1-2 ha.d]# hostname data-1-2 [root@data-1-2 ha.d]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=data-1-2 调整文件描述符 [root@data-1-2 ha.d]# cat /etc/security/limits.conf * - nofile 65535
2、heartbeat两台主机的ip地址规划如下:
data-1-1(master)
eth0: 192.168.1.154
eth1: 172.168.1.154
eth2: 10.0.0.154
VIP: 192.168.1.54 #这个vip现在不需要配,在heartbeat配置文件中配置即可
data-1-2(backup)
eth0: 192.168.1.155
eth1: 172.168.1.155
eth2: 10.0.0.155
VIP: 192.168.1.55 #这个vip现在不需要配,在heartbeat配置文件中配置即可
注意点:在添加完网卡后,应该在网卡的配置文件中即 /etc/sysconfig/network-scripts/ifcfg-eth2中将ONBOOT=yes设置好,让系统在下次启动后可以自动启动网卡
3、配置心跳路由
#两台服务器上配置心跳路由,来实现两台机器检查对端时使用这个心跳线线路检查 #在data-1-1上,并将添加路由的命令放到开启自启动中:echo "/sbin/route add -host 10.0.0.155 dev eth2">>/etc/rc.local route add -host 10.0.0.155 dev eth2 #在data-1-2上,并将添加路由的命令放到开启自启动中:echo "/sbin/route add -host 10.0.0.154 dev eth2">>/etc/rc.local route add -host 10.0.0.154 dev eth2
4、heartbeat安装
yum install heartbeat* -y
5、安装好heartbeat后,生成heartbeat主配置文件,认证文件、资源文件
安装好heartbeat后,会在/usr/share/doc/heartbeat-3.0.4/下生成主配置文件、认证文件、资源文件的模板:ha.cf、authkeys、haresources
我们参考这些模板文件来生成自己的配置文件如下:
配置文件一 ha.cf
# cat /etc/ha.d/ha.cf debugfile /var/log/ha-debug #ha调试日志文件位置 logfile /var/log/ha-log #ha日志 logfacility local1 #在rsyslog中使用local1设备接受日志 keepalive 2 #心跳间隔为2秒 deadtime 30 #指定备机在30秒内没有收到主机心跳信息,则接管资源 warntime 10 #指定心跳延迟时间为10秒。当10秒钟内备机不能接收到主节点心跳信号时,就会往日志中写入一个警告日志,但是不会切换 initdead 60 # deadtime*2 #指定heartbeat首次运行后,需要等待120秒才启动主服务器的任何资源,该选项用于解决这种情况产生的时间间隔,取值至少为deadtime的2倍。 单机启动时会遇到绑定vip很慢,为正常现象,该值设置的长的原因# mcast eth1 225.0.0.154 694 1 0 #设置广播通信使用的端口,694为默认端口号 auto_failback on #用来定义当主节点恢复后,是否将服务自动回切,一般off掉 node data-1-1 #主节点主机名uname -n node data-1-2 #备节点主机名uname -n crm no #是否开启Cluster Resource Manager(集群资源管理)功能
配置文件二 authkeys
通过sha1或md5来生成加密字符串放到authkeys文件中,这个文件中的内容在两台主机应该相同,比如用sha1来生成加密字符串,
cat authkeys auth 1 1 sha1 47e9336850f1db6fa58bc470bc9b7810eb397f04
对生成好的authkeys文件权限设置为600 :chmod 600 /etc/ha.d/authkeys
配置文件三 haresources
data-1-1 IPaddr::192.168.1.54/24/eth0 data-1-2 IPaddr::192.168.1.55/24/eth0 提示:以上配置,实际就是执行/etc/ha.d/resource.d/IPaddr 192.168.0.191/24/eth0脚本 #-->表示初始状态会在data-1-1的物理网卡eth0绑定VIP 192.168.1.54/24
上述三个配置文件在两台机器的/etc/ha.d/目录下做同样配置。
6、管理Heartbeat
启动data-1-1的heartbeat
[root@data-1-1 ~] /etc/init.d/heartbeat start
启动data-1-2的heartbeat
[root@data-1-2 ~] /etc/init.d/heartbeat start
通过cat /var/log/ha-log来查看heartbeat启动过程的日志信息
通过ip add|egrep "192.168.1.54|192.168.1.55" 查看各个机器的vip是否生效
[root@data-1-1 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
inet 192.168.1.54/24 brd 192.168.1.255 scope global secondary eth0
[root@data-1-2 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
inet 192.168.1.55/24 brd 192.168.1.255 scope global secondary eth0
如果停掉了data-1-2主机的heartbeat,再用ip add|egrep "192.168.1.54|192.168.1.55"查看vip的情况如下
[root@data-1-2 ha.d]# /etc/init.d/heartbeat stop
[root@data-1-2 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
[root@data-1-1 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
inet 192.168.1.54/24 brd 192.168.1.255 scope global secondary eth0
inet 192.168.1.55/24 brd 192.168.1.255 scope global secondary eth0
表示data-1-2主机释放了管理vip的权限vip漂移到了data-1-1上了
7、heartbeat主动释放资源与资源接管
资源释放
# /usr/share/heartbeat/hb_standby --help
usage:
/usr/share/heartbeat/hb_standby [all|foreign|local|failback]
资源接管
# /usr/share/heartbeat/hb_takeover --help
usage:
/usr/share/heartbeat/hb_takeover [all|foreign|local|failback]
[root@data-1-1 ha.d]# /usr/share/heartbeat/hb_standby
这时候data-1-1资源便被data-1-2接管了vip漂移到data-1-2上了
[root@data-1-2 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
inet 192.168.1.55/24 brd 192.168.1.255 scope global secondary eth0
inet 192.168.1.54/24 brd 192.168.1.255 scope global secondary eth0
然后再让data-1-1来重新接管自己的资源
[root@data-1-1 ha.d]# /usr/share/heartbeat/hb_takeover local
这时候data-1-1遍接管回了自己的资源
[root@data-1-1 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
inet 192.168.1.54/24 brd 192.168.1.255 scope global secondary eth0
[root@data-1-2 ha.d]# ip add|egrep "192.168.1.54|192.168.1.55"
inet 192.168.1.55/24 brd 192.168.1.255 scope global secondary eth0
如果有需求修改了heartbeat配置文件后,最好不要使用重启heartbeat的命令,要用资源释放和资源接管的命令,因为资源释放和接管比重启heartbeat的快的多,也不会对heartbeat服务产生大的影响
8、heartbeat 实现web高可用
在data-1-1 data-1-2安装httpd #在data-1-1上安装httpd服务 [root@data-1-1 ha.d]# yum install httpd -y [root@data-1-1 html]# echo 192.168.1.154>index.html #在data-1-2上安装httpd服务 [root@data-1-2 ha.d]# yum install httpd -y [root@data-1-2 html]# echo 192.168.1.155>index.html 安装好httpd后不要启动httpd服务,接下来要用heartbeat来管理httpd,让httpd启动或停掉 #停掉两台主机的heartbeat服务并修改haresources配置文件,让heartbeat来管理httpd [root@data-1-1 ha.d]# /etc/init.d/heartbeat stop [root@data-1-2 ha.d]# /etc/init.d/heartbeat stop #两台主机的做同样haresources配置文件的修改,将httpd加到heartbeat管理中来 vim haresources data-1-1 httpd IPaddr::192.168.1.54/24/eth0 data-1-2 IPaddr::192.168.1.55/24/eth0 #最后启动heartbeat服务 [root@data-1-1 ha.d]# /etc/init.d/heartbeat start [root@data-1-2 ha.d]# /etc/init.d/heartbeat start 这时候查看80端口只有data-1-1启动了httpd服务,作为备节点的data-1-2没有启动httpd服务 如果这时关掉data-1-1的heartbeat服务,那么data-1-1就会通过heartbeat来管理httpd服务来关掉httpd服务,同时data-1-2接管了data-1-1的资源,就可启动在data-1-2上的httpd服务了
当然可以通过查看日志ha-log来查看两天机器的资源释放和接管的过程,这样对于heartbeat的运行过程就比较了解了。
这里的httpd为什么要放在vip启动的前面呢,主要是为了考虑用户的体验上,因为启动过程是从左到右的方式来启动的,等httpd服务启动好后再启动vip,这样才能保证客户端访问web的时候体验更好
让heartbeat来管理服务的前提条件为:
1、服务的脚本应该在/etc/init.d 或者/etc/ha.d/resource.d/目录下 2、服务的脚本执行能以/etc/init.d/httpd start/stop方式运行 3、脚本要可执行权限 4、比如httpd服务,/etc/init.d/httpd名字和/etc/ha.d/haresources中一致 另外,如果http服务停不掉,会导致系统重启
9、heartbeat管理服务的注意事项
heartbeat要管理的服务必须是heartbeat可以管理的服务,而且这些服务不可以开机自启动,应让heartbeat自己开管理这些服务,让其启动或关闭。如果heartbeat无法管理这些服务的话,可能会导致服务器重启,比如对httpd服务的管理,我们认为的修改了httpd脚本,让heartbeat来管理的时候就会报如下错误并重启服务器
修改httpd脚本
[root@data-1-1 ha.d]# vim /etc/init.d/httpd
case "$1" in
start1)
start
;;
stop2)
stop
;;
关闭heartbeat服务,导致了重启服务器
[root@data-1-1 ha.d]# /etc/init.d/heartbeat stop Stopping High-Availability services: 已杀死
从日志ha-log中可以看到日志记录了重启的命令和重启服务器的原因
[root@data-1-1 ~]# cat /var/log/ha-log ResourceManager(default)[1581]: 2017/10/28_22:19:02 info: Retrying failed stop operation [httpd] ResourceManager(default)[1581]: 2017/10/28_22:19:02 info: Running /etc/init.d/httpd stop ResourceManager(default)[1581]: 2017/10/28_22:19:02 ERROR: Return code 2 from /etc/init.d/httpd ResourceManager(default)[1581]: 2017/10/28_22:19:02 ERROR: Resource script for httpd probably not LSB-compliant. ResourceManager(default)[1581]: 2017/10/28_22:19:02 WARN: it (httpd) MUST succeed on a stop when already stopped ResourceManager(default)[1581]: 2017/10/28_22:19:02 WARN: Machine reboot narrowly avoided!
10、heartbeat调用资源的生产场景的应用
在实际工作中有两种常见方法实现高可用问题 1、heartbeat可以仅控制vip资源的漂移,不负责服务资源的启动与停止------>适合web服务 2、heartbeat既控制vip资源的漂移,同时又控制服务资源的启动与停止----->适合数据服务(数据库和存储)只能一端写。 上述http高可用中,heartbeat正常,web服务宕了,这时候不会做高可用切换。可以写个简单的脚本定时或守护进程判断web服务,如果有问题,则停止heartbeat,主动使其上的业务切换到另一台 3、对于两端服务需要同时起的,最好不要交给heartbeat,上述http高可用中,两端的服务其实可以同时启动状态,所以可以不用交给heartbeat进行资源管理
11、heartbeat 和keepalived的应用场景的区别
1、对于一般的web、db、负载均衡(nginx,haproxy)等,heartbeat 和keepalived都可以实现 2、lvs负载均衡最好和keepalived结合,虽然heartbeat也可以调用带有ipvsadm命令脚本来启动和停止lvs负载均衡,但是heartbeat本身没有对rs的健康检查功能,这个缺陷可以通过ldirectord插件来弥补,所以当你搜索heartbeat+lvs+ldirectord可以有lvs另外的解决方案 3、需要数据同步的高可用性业务最好用heartbeat,如果你解决了数据同步,那么就可以考虑keepalived,例如共享存储或者inotify+rsync,那么就可以考虑keepalived 4、运维人员对哪个更熟悉就用哪个,其实就是你要能控制维护你部署的服务。目前,总体更倾向于使用keepalived多些
有关企业高可用切换特别说明
高可用服务的切换一般用于主故障备用自动切换接管,快速顶替故障机提供服务的 接管后的善后工作,最好人工处理解决 不管准备多么完善,监控多么智能,一般都不会自动切回主库,而是人工控制,因为这个回切是可控的,有时间准备的,而一开始的主挂导致的切换是突然的不可控的 重要的业务数据是不能来回自动切的,即auto_failback 应该是off状态 有关主的heartbeat是不是开机自启动,这个要具体业务具体分析,一般heartbeat和drdb开启都不做自启动,都由人工来控制。 负载均衡和高可用服务器一般来说都非常重要,因此,操作时一定要谨慎小心,一定记得事先写好操作步骤及回滚步骤,然后再去实施操作,贸然很容易导致网站宕机影响用户体验,特别是涉及到数据库和存储高可用的heartbeat的维护就更加要小心
DRBD简介
1、什么是DRBD
Distributed Replicated Block Device(DRBD)是基于块设备,是一种通过TCP/IP网络,在不同的高可用服务器对之间同步和镜像数据的软件
通过它可以实现在网络中的两台服务器之间基于块设备级别的实时或异步镜像或同步复制,其实就是类似于rsync+inotify这样的架构项目软件
只不过drbd是基于文件系统底层,即block层级同步,而rsync+inotify是基于文件系统之上的实际物理文件的同步,因此,drbd效率更高,效果更好
提示:上文中提到的块设备可以是磁盘分区、LVM逻辑卷,或整块磁盘等,但不能是目录
2、drbd工作原理
DRBD是一种块设备,可以被用于高可用(HA)之中.它类似于一个网络RAID-1功能.当你将数据写入本地 文件系统时,数据还将会被发送到网络中另一台主机上.以相同的形式记录在一个文件系统中。
本地(主节点)与远程主机(备节点)的数据可以保证实时同步.当本地系统出现故障时,远程主机上还会保留有一份相同的数据,可以继续使用.
在高可用(HA)中使用DRBD功能,可以代替使用一个共享盘阵.因为数据同时存在于本地主机和远程主机上,切换时,远程主机只要使用它上面的那份备份数据,就可以继续进行服务了。
官方原理图:

3、DRBD数据镜像同步模式
1、实时同步模式
仅仅当数据写入到本地磁盘和远端服务器磁盘都写入成功后才会返回成功写入。DRBD服务的协议C级别就是这种实时同步模式,可以防止本地和远端数据丢失和不一致,此种模式是生产环境最常使用模式
2、异步同步模式
当数据写入到本地服务器成功后就返回成功写入,不管远端服务器是否写入成功。
a、当数据写入到本地服务器以及发送到本地的TCP BUFFER后返回成功写入,这是DRBD服务的协议A级别的工作模式
b、当数据写入到本地服务器以及发送到远端节点后,返回成功写入,这是DRBD服务的协议B级别工作模式
提示:nfs服务器的配资参数sync和async,mount挂载参数也有sync和async
4、DRBD 的3种同步复制协议
性能 A >B>C 数据一致性 A<B<C
协议A:异步复制协议。本地写成功后立即返回,数据放在发送tcp/ip buffer中,可能丢失。
协议B:内存同步(半同步)复制协议。本地写成功并将数据发送到对方接收buffer后立即返回,如果双机掉电,数据可能丢失。
协议C:同步复制协议。本地和对方写成功确认后返回。如果双机掉电或磁盘同时损坏,则数据可能丢失。
一般用协议C,但选择C协议将影响流量,从而影响网络时延。为了数据可靠性,我们在生产环境中还是用C协议。
提示:工作中一般使用协议C,协议不同,将影响数据一致性,以及网络延时
对于A\B协议要考虑数据丢失的风险,当数据写在缓冲区,没有真正写到磁盘上时,系统奔溃会导致数据丢失的风险,有些带电池的硬盘控制器,如带电池的Dell PERC Raid卡,不但带缓存且自带电池
DRBD裂脑(Split brain)
当心跳线路出现暂时性故障时,会导致两端都各自提升为Primary,当两端再次连通时,需要手工处理
裂脑是一个因所有集群节点网络中断产生的一种状态,可能原因有集群管理器的介入,热内错误,此时两个节点都会提升为主
这是个潜在的非常有害的状态,这意味着数据的修改写到了一端,但是没有及时同步到对端,这样可能两端都会产生不同的数据,导致数据无法合并
DRBD部署
drbd的部署环境沿用heartbeat搭建的环境不变,例外增加一个磁盘做drbd的同步
1、添加新硬盘做drbd同步用
#在data-1-1上添加2G的磁盘并分区 [root@data-1-1 ~]# parted /dev/sdb mklabel gpt yes [root@data-1-1 ~]# parted /dev/sdb mkpart primary ext4 0 1000 Ignore [root@data-1-1 ~]# parted /dev/sdb mkpart primary ext4 1001 2000 yes Ignore [root@data-1-1 ~]# parted /dev/sdb p #在data-1-2上添加3G的磁盘并分区 [root@data-1-2 ~]# parted /dev/sdb mklabel gpt yes [root@data-1-2 ~]# parted /dev/sdb mkpart primary ext4 0 2000 Ignore [root@data-1-2 ~]# parted /dev/sdb mkpart primary ext4 2001 3000 yes Ignore [root@data-1-2 ~]# parted /dev/sdb p
2、下载yum安装drbd用到的yum源elrepo源
wget http://www.elrepo.org/elrepo-release-6-8.el6.elrepo.noarch.rpm #安装这个yum源 rpm -ivh elrepo-release-6-8.el6.elrepo.noarch.rpm #查看这个yum源是否安装成功 [root@data-1-1 ha.d]# ll /etc/yum.repos.d/ -rw-r--r-- 1 root root 2142 7月 24 02:57 elrepo.repo
3、安装drbd
yum install drbd kmod-drbd84 -y
下面的导入drbd操作最好不要做,因为对drbd的控制生产上为人为手动控制的,drbd开启也不做自启动,需要手动开启drbd,开启drbd的时候会自动加载drbd模块的,所以下面导入drbd模块是没必要的,只需要在安装完drbd后重启系统即可。
安装完后,导入drbd:modprobe drbd,这时候会报错为:FATAL: Module drbd not found.这是因为安装drbd的时候升级了kernel,这时候重启系统即可
[root@data-1-1 ~]# modprobe drbd [root@data-1-1 ~]# lsmod |grep drbd drbd 374888 0 libcrc32c 1246 1 drbd
将加载drbd放到开启自动中(注意:drbd开启不能设置成自启动,事实上,生产环境中,drbd就是开机不自启动的),如果drbd服务是开机自启动的,会先启动drbd服务在加载drbd的顺序,导致drbd启动不了出现的问题。也就是说加载drbd到开机自启动是不必要的,因为开机的时候我们基本上都是手动启动drbd的
echo 'modprobe drbd' >>/etc/rc.loca
4、配置drbd
默认的drbd配置文件为安装好drbd后在/etc/drbd.d/目录下有个global_common.conf的配置模板,可以参照这个模板来创建自己的drbd配置文件如下:
vim drbd.conf
global {
usage-count no;
}
common {
protocol C;
disk {
on-io-error detach;
#size 454G;
no-disk-flushes;
no-md-flushes;
}
net {
sndbuf-size 512k;
max-buffers 8000;
unplug-watermark 1024;
max-epoch-size 8000;
cram-hmac-alg "sha1";
shared-secret "hdhwXes23sYEhart8t";
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
rr-conflict disconnect;
}
syncer {
rate 120M;
al-extents 517;
}
}
# primary for drbd1
resource data {
on data-1-1 {
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.154:7788;
meta-disk /dev/sdb2[0];
}
on data-1-2 {
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.155:7788;
meta-disk /dev/sdb2[0];
}
}
5、初始化meta分区
[root@data-1-2 ~]# drbdadm create-md data initializing activity log NOT initializing bitmap Writing meta data... New drbd meta data block successfully created.
6、启动drbd,主备都要提前关掉drbd开启自启动
[root@data-1-1 ~]# drbdadm up data [root@data-1-1 ~]# chkconfig drbd off
然后查看主备drbd的同步情况如下:
[root@data-1-1 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:1008622 nr:0 dw:32076 dr:977546 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:1008622 dw:1008622 dr:0 al:16 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
还可以通过如下命令来查看drbd的连接状态,可以作为监控服务器的监控的状态
[root@data-1-1 ~]# drbdadm cstate data Connected [root@data-1-1 ~]# drbdadm dstate data UpToDate/UpToDate [root@data-1-1 ~]# drbdadm role data Primary/Secondary
比如用nagios来监控drbd服务的状态,可以对上面的三个参数的状态做分析生成shell脚本如下:
[root@data-1-1 scripts]# vim nagios_drbd.sh
#!/bin/sh
role=($(drbdadm role all|tr "/" "\n"))
dstate=($(drbdadm dstate all|tr "/" "\n"))
cstate=`drbdadm cstate all`
if [ "Primary" = "${role[0]}" ] && [ "Secondary" = "${role[1]}" ] && \
[ "UpToDate" = "${dstate[0]}" ] && [ "UpToDate" = "${dstate[1]}" ] && \
[ "Connected" = "$cstate" ] ;
then
echo "OK -DRBD_STATUS is ok !"
exit 0
else
echo "CRITICAL -DRBD_STATUS is CRITICAL !"
exit 2
fi
这样远端的nagios监控服务器就可以通过nrpe监控drbd服务主机的运行状况,有报警的话手动连接drbd服务器来人为的控制drbd操作。
7、初始化设备同步(覆盖备节点,保持数据一致)
[root@data-1-1 ~]# drbdadm -- --overwrite-data-of-peer primary data
8、格式化drbd分区,而不是直接格式化磁盘分区
对centos6版本要对/dev/drbd0格式化,不要直接对分区/dev/sdb1格式化,因为直接对磁盘分区格式化,后面同步的时候可能会产生错误现象
而且要对/dev/drbd0格式化的话,主机必须是primary状态才可,对于没有做设备初始化或非primary状态是无法格式化/dev/drbd0的,因为/dev/drbd0只对primary状态的主机可见。
[root@data-1-1 ~]# mkfs.ext4 /dev/drbd0 [root@data-1-1 ~]# tune2fs -c -1 /dev/drbd0
但是备主机也需要对/dev/drbd0格式化的,因为一旦主切到备的机器上的话,那么备就是主drbd了,所以这里对主备角色做个临时切换,然后再对备机器格式化/dev/drbd0
[root@data-1-1 ~]# drbdadm secondary data
[root@data-1-1 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
ns:1008622 nr:0 dw:32076 dr:977546 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ~]# drbdadm primary data
[root@data-1-2 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:0 nr:1008622 dw:1008622 dr:660 al:16 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ~]# mkfs.ext4 /dev/drbd0
[root@data-1-2 ~]# tune2fs -c -1 /dev/drbd0
#做好备节点的/dev/drbd0格式化后,再把主备的drbd角色切回去
[root@data-1-2 ~]# drbdadm secondary data
[root@data-1-2 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:32076 nr:1008622 dw:1040698 dr:1000 al:26 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-1 ~]# drbdadm primary data
[root@data-1-1 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:1008622 nr:32076 dw:64152 dr:978206 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
9、挂载DRBD分区到/data目录
[root@data-1-1 ~]# mkdir /data [root@data-1-1 ~]# mount /dev/drbd0 /data [root@data-1-1 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 7.1G 1.8G 5.0G 27% / tmpfs 491M 0 491M 0% /dev/shm /dev/sda1 190M 58M 123M 33% /boot /dev/drbd0 923M 1.2M 874M 1% /data
模拟主宕机,查看备节点数据是否通过drbd同步过来了
#先向主几点创建数据,然后卸载并停掉drbd服务
[root@data-1-1 ~]# cd /data/
[root@data-1-1 data]# echo 'goser good'>test.txt
[root@data-1-1 ~]# umount /data
[root@data-1-1 ~]# drbdadm down data
#然后备节点手动提升为主,挂载drbd分区,查看数据
[root@data-1-2 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/DUnknown C r-----
ns:32076 nr:1008718 dw:1040794 dr:1000 al:26 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ~]# drbdadm primary data
[root@data-1-2 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
ns:32076 nr:1008718 dw:1040794 dr:1660 al:26 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ~]# mkdir /data
[root@data-1-2 ~]# mount /dev/drbd0 /data/
[root@data-1-2 ~]# cd /data/
[root@data-1-2 data]# ll
总用量 20
drwx------ 2 root root 16384 10月 31 23:10 lost+found
-rw-r--r-- 1 root root 11 10月 31 23:17 test.txt
测试数据保持了一致性,最后再把主备角色还原
10、裂脑解决方案
a、在从节点data-1-2上
drbdadm secondary data
drbdadm -- --discard-my-data connect data #放弃本端数据进行连接
drbdadm disconnect data
drbdadm connect data
b、在主节点data-1-1上,通过cat /proc/drbd查看状态,如果不是WFConnection状态,则需要手动连接
drbdadm disconnect data
drbdadm connect data
11、 大数据迁移操作
当主机的磁盘慢的时候,如何将这个慢的磁盘迁移到大的主机磁盘上,可以使用drbd的方式来同步数据,但是同步好后,备节点的磁盘大小和主节点的磁盘大小是一样的,我们可以使用下面的方法来恢复磁盘大小
我们知道,在前面的环境中添加的磁盘为:主为2G,备为3G,在drbd同步后,备的/dev/sdb1分区的大小和主的/dev/sdb1大小一样了,这样就违背了磁盘扩容的要求了,虽然完成了大数据的同步,所以我们在完成大数据的同步过,还要对磁盘做如下操作来恢复磁盘原来的大小
#处理前的/dev/sdb1的大小 [root@data-1-2 ~]# drbdadm down data [root@data-1-2 ~]# mount /dev/sdb1 /data/ [root@data-1-2 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 7.1G 1.7G 5.1G 25% / tmpfs 491M 0 491M 0% /dev/shm /dev/sda1 190M 58M 123M 33% /boot /dev/sdb1 923M 1.2M 874M 1% /data #还原/dev/sdb1大小,大小恢复到原来分区设置的2G大小 [root@data-1-2 ~]# umount /data [root@data-1-2 ~]# e2fsck -f /dev/sdb1 [root@data-1-2 ~]# resize2fs /dev/sdb1 [root@data-1-2 ~]# mount /dev/sdb1 /data/ [root@data-1-2 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 7.1G 1.7G 5.1G 25% / tmpfs 491M 0 491M 0% /dev/shm /dev/sda1 190M 58M 123M 33% /boot /dev/sdb1 1.9G 1.5M 1.8G 1% /data
用heartbeat来管理drbd
我们知道heartbeat来管理服务的前提条件为:
1、服务的脚本应该在/etc/init.d/或者/etc/ha.d/resource.d/目录下
2、服务的脚本执行能以start或stop方式来执行
3、脚本要有可执行权限
4、自定义的服务的名称,在/etc/init.d/目录下和在/etc/ha.d/resource.d/目录下一致
由于drbd服务的控制脚本是放在/etc/ha.d/resource.d/目录下的,所有heartbeat可以直接来管理drbd服务。下面有两个drbd服务脚本,对drbd服务很重要:
在/etc/ha.d/resource.d/目录下有drbddisk、Filesystem,这两个脚本对于drbd代表的含义为:
drbddisk脚本的作用:当drbd启动后drbd的状态为secondary,可以启动这个脚本让drbd的状态变为primary
Filesystem脚本的作用:启动这个脚本可以挂载drbd分区到本地目录上
下面来模拟当服务器启动后,接着drbd启动后,主备的状态都为Secondary/Secondary时,我们用这两个脚本来改变drbd的状态
#让主备drbd状态都为Secondary/Secondary
[root@data-1-1 ~]# drbdadm secondary data
[root@data-1-1 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
ns:20 nr:40 dw:128083 dr:1956143 al:24 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
#在主上启动drbddisk脚本让其变为主primary状态
[root@data-1-1 ~]# /etc/ha.d/resource.d/drbddisk data start
[root@data-1-1 ~]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:20 nr:40 dw:128083 dr:1956800 al:24 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
#挂载drbd分区,这要启动Filesystem脚本来让drbd自动挂载drbd分区
[root@data-1-1 ~]# /etc/ha.d/resource.d/Filesystem /dev/drbd0 /data ext4 start
[root@data-1-1 ~]# df -h
/dev/drbd0 1.9G 2.9M 1.8G 1% /data
如果卸载drbd分区和取消primary状态的话,对两个脚本执行stop命令即可
[root@data-1-1 ~]# /etc/ha.d/resource.d/Filesystem /dev/drbd0 /data ext4 stop [root@data-1-1 ~]# /etc/ha.d/resource.d/drbddisk data stop
配置heatbeat的配置文件来管理drbd
由于heartbeat管理的服务启动顺序为从左到右启动,关闭的时候为从右向左关闭,所以在编辑heartbeat管理服务的顺序时候要注意点
比如要对drbd服务的管理,顺序则为先提升为主,然后再对drbd分区做挂载,关闭的时候相反,这样才合理,才不会出错。主备两端做同样的操作
cd /etc/ha.d/resource.d/ vim haresources data-1-1 drbddisk::data Filesystem::/dev/drbd0::/data::ext4 IPaddr::192.168.182.54/24/eth0 data-1-2 IPaddr::192.168.182.55/24/eth0
启动heartbeat服务来检查是否的drbd的管理生效
[root@data-1-1 ha.d]# /etc/init.d/heartbeat start [root@data-1-2 ha.d]# /etc/init.d/heartbeat start
启动好heartbeat后查看drbd的状态
[root@data-1-1 ha.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:32 nr:40 dw:128095 dr:1957491 al:24 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-1 ha.d]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 7.1G 2.0G 4.8G 29% /
tmpfs 491M 0 491M 0% /dev/shm
/dev/sda1 190M 58M 123M 33% /boot
/dev/drbd0 1.9G 2.9M 1.8G 1% /data
[root@data-1-2 ha.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:40 nr:32 dw:2081203 dr:2373 al:35 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
当data-1-1主服务释放资源(模拟宕机情况)后,heartbeat管理drbd服务队drbd状态的影响:
[root@data-1-1 ha.d]# /usr/share/heartbeat/hb_standby local
[root@data-1-1 ha.d]# ip add|egrep "182.54|182.55"
[root@data-1-1 ha.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:36 nr:44 dw:128103 dr:1957491 al:24 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ha.d]# ip add|egrep "182.54|182.55"
inet 192.168.182.55/24 brd 192.168.182.255 scope global secondary eth0
inet 192.168.182.54/24 brd 192.168.182.255 scope global secondary eth0
[root@data-1-2 ha.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:44 nr:36 dw:2081211 dr:3047 al:35 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ha.d]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 7.1G 2.5G 4.3G 36% /
tmpfs 491M 0 491M 0% /dev/shm
/dev/sda1 190M 58M 122M 33% /boot
/dev/drbd0 1.9G 2.9M 1.8G 1% /data
最后主上收回资源控制,data-1-1又重新变为了主drbd服务
主机宕机修复后的处理过程:
#当heartbeat配置文件中的auto_failback on为自动接管开启的话
1、data-1-1主不能自动开启heartbeat,drbd(#auto_failback on)。
2、data-1-1主故障备接管后,备对外提供服务,写数据(实验:模拟写100个文件)。
此时data-1-2备节点提升为主后的状态(Primary/Unknown),
3、data-1-1主修复了,不要开启heartbeat及drbd。
手工处理:
a.确保心跳线通信正常。
b.drbdadm up data data-1-1(Secondary/Primary)
c.同步完成,启动heartbeat(/etc/init.d/heartbeat start).
data-1-1(Primary/Secondary),data-1-2(Secondary/Primary)
#当heartbeat配置文件中的auto_failback off为自动接管关闭的话
1、data-1-1主不能自动开启heartbeat,drbd(auto_failback off)。
2、data-1-1主故障备接管后,备对外提供服务,写数据(实验:模拟写100个文件)。
此时data-1-2备节点提升为主后的状态(Primary/Unknown)!
3、data-1-1主修复了,不要开启heartbeat及drbd。
手工处理:
a.确保心跳线通信正常。
b.drbdadm up data后此时data-1-1状态(Secondary/Primary),data-1-2(Primary/Secondary)
c.此时数据流,从data-1-2流向data-1-1.
d.data-1-1启动heartbeat。data-1-1(Secondary/Primary)
f.data-1-2/usr/share/heartbeat/hb_standby(回切服务器)
g.data-1-1 (Primary/Secondary)
配置heartbeat、drbd实现nfs高可用
在drbd主备节点配置nfs的挂载点,让nfs通过vip的方式来访问挂载点。这样一旦drbd主备切换的时候web客户端的nfs挂载点就不需要重新配置,因为vip在drbd主备节点切换的时候做了漂移
1、在data-1-1、data-1-2主备节点和web客户端上安装nfs和rpcbind
客户端安装nfs是为了在客户端可以使用showmount命令
[root@data-1-1 ~]# rpm -qa rpcbind nfs-utils nfs-utils-1.2.3-75.el6.x86_64 rpcbind-0.2.0-13.el6_9.1.x86_64
通过rpm -qa查看主备节点和web客户端都已安装了
1、在主备节点设置nfs挂载点
[root@data-1-1 ~]# vim /etc/exports /data 192.168.1.0/24(rw,sync,all_squash) [root@data-1-2 ~]# vim /etc/exports /data 192.168.1.0/24(rw,sync,all_squash)
设置好挂载点后,让设置生效
[root@data-1-1 ~]# exportfs -rv exporting 192.168.1.0/24:/data [root@data-1-2 ~]# exportfs -rv exporting 192.168.1.0/24:/data
2、设置nfs客户端访问权限
由于web客户端通过nfsnobody用户来访问nfs挂载点的,所以对挂载的目录设置nfsnobody所有者权限
[root@data-1-1 ~]# chown nfsnobody.nfsnobody /data/ [root@data-1-2 ~]# chown nfsnobody.nfsnobody /data/ [root@lnmp01 ~]# chown nfsnobody.nfsnobody /data/
3、设置drbd主备节点的rpcbind和nfs开机自启动
[root@data-1-1 ~]# chkconfig rpcbind on [root@data-1-1 ~]# chkconfig nfs on [root@data-1-2 ~]# chkconfig nfs on [root@data-1-2 ~]# chkconfig rpcbind on
当然nfs、rpcbind开机自启动也可通过heartbeat来管理,主备节点做如下同样操作:
[root@data-1-1 ~]# cd /etc/ha.d/resource.d/ [root@data-1-1 resource.d]# vim nfsd #!/bin/sh case "$1" in start) /etc/init.d/rpcbind restart sleep 2 /etc/init.d/nfs restart ;; stop) /etc/init.d/rpcbind stop sleep 2 /etc/init.d/nfs stop ;; status) /etc/init.d/rpcbind status sleep 2 /etc/init.d/nfs status ;; *) esac exit 0 [root@data-1-1 resource.d]# chmod +x nfsd
然后在heartbeat配置文件中将这个nfsd脚本添加进去,主备设置一样
[root@data-1-1 ha.d]# vi haresources data-1-1 drbddisk::data Filesystem::/dev/drbd0::/data::ext4 IPaddr::192.168.1.54 /24/eth0 nfsd data-1-2 IPaddr::192.168.1.55/24/eth0
这样heartbeat在做主备切换的时候就可以来重启nfs服务了
但是让heartbeat来管理nfs的启动和关闭的话,没什么作用,因为主备如果做切换的话,主就会做重启操作,这样nfs依然是没有启动的。所以不建议用heartbeat来管理nfs,建议用chkconfig来管理nfs开机自启动
4、启动drbd和heartbeat服务
在手动启动完drbd后,主备节点的状态都为Secondary/Secondary时,在启动heartbeat服务,这时候主上就将drbd分区挂载到/data目录了
5、web客户端挂载nfs
[root@lnmp01 ~]# mount -t nfs 192.168.1.54:/data /data
6、当主备切换的时候,客户端挂载夯住的解决办法
当主备切换的时候,web客户端常常会出现夯住的情况,假死的状态。这是因为主备切换时是需要一个过程,这个过程中客户端连接nfs服务端的时候可能超时,但是客户端只要卸载挂载点,重启rpcbind服务、在重新挂载就没有问题了。
我们可以通过主备的heartbeat来管理客户端的卸载、重启rpcbind、重新挂载的操作:当heartbeat管理资源的时候就操作web客户端,heartbeat在做释放资源的时候对客户端不做任何操作
如果主备节点可以控制客户端的话,那么就要用到ssh-key的方式免秘钥的方式连接远端客户端来操作挂载点
配置ssh-key
#在主节点生成ssh秘钥 [root@data-1-1 ~]# ssh-keygen -t dsa #将公钥推送到各个web客户端 [root@data-1-1 ~]# ssh-copy-id -i ~/.ssh/id_dsa.pub 192.168.1.103 #打包/root/.ssh/目录 并拷贝到备节点 [root@data-1-1 /]# tar cvzf data-1-1_ssh.tar.gz /root/.ssh/ [root@data-1-1 /]# scp data-1-1_ssh.tar.gz root@192.168.1.155:~ #备节点切换到根目录,然后解压这个ssh压缩文件 [root@data-1-2 ~]# cd / [root@data-1-2 /]# tar xf /root/data-1-1_ssh.tar.gz
在主备节点生成一个让heartbeat远程管理web客户端的脚本,主备做同样的操作
[root@data-1-1 /]# cd /etc/ha.d/resource.d/
[root@data-1-1 resource.d]# vim remount_allclients
#!/bin/sh
sleep 2
case "$1" in
start)
vip=192.168.1.54
for n in 103
do
ssh 192.168.1.$n "umount -lf /data;/etc/init.d/rpcbind restart;mount -t nfs ${vip}:/data /data"
done
;;
stop)
;;
*)
echo "USAGE:$0 {start|stop}"
esac
[root@data-1-1 resource.d]# chmod +x remount_allclients
在主备节点的heartbeat配置文件haresources中添加remount_allclients脚本,让主备都可管理远端的web客户端的nfs挂载
[root@data-1-1 ha.d]# vim haresources data-1-1 drbddisk::data Filesystem::/dev/drbd0::/data::ext4 IPaddr::192.168.1.54/24/eth0 remount_allclients data-1-2 IPaddr::192.168.1.55/24/eth0
这样一旦heartbeat做切换后,接管资源的一方就会管理web客户端,让客户端卸载原来的挂载,重启rpcbind,重新挂载。。。。
当主从drbd不同步处于下面状态时的解决办法
[root@data-1-1 resource.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r-----
ns:0 nr:0 dw:0 dr:660 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:32072
[root@data-1-2 ha.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:50852
使用列脑的方式来解决这个问题的时候,怎么处理都无法让主备同步,这时候要用清除meta分区,重新构建meta分区的方式就可以让主备drbd同步了
处理方式一
清除meta分区数据,主备做同样的操作
[root@data-1-1 resource.d]# drbdadm detach data [root@data-1-1 resource.d]# drbdadm apply-al data [root@data-1-1 resource.d]# drbdadm dump-md data
然后重建meta分区数据,主备做同样的操作
[root@data-1-1 resource.d]# drbdadm create-md data Valid meta data seems to be in place. Do you really want to overwrite? [need to type 'yes' to confirm] yes md_offset 0 al_offset 4096 bm_offset 36864 Found some data ==> This might destroy existing data! <== Do you want to proceed? [need to type 'yes' to confirm] yes initializing activity log NOT initializing bitmap Writing meta data... New drbd meta data block successfully created.
最后重启主备的drbd,主备做同样操作
[root@data-1-1 resource.d]# /etc/init.d/drbd stop [root@data-1-1 resource.d]# /etc/init.d/drbd start
最后查看drbd的同步状态如下,表示drbd同步正常了。
[root@data-1-1 resource.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:976546 nr:0 dw:0 dr:977206 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
[root@data-1-2 ha.d]# cat /proc/drbd
version: 8.4.9-1 (api:1/proto:86-101)
GIT-hash: 9976da086367a2476503ef7f6b13d4567327a280 build by mockbuild@Build64R6, 2016-12-13 18:38:15
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:976546 dw:976546 dr:0 al:16 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
处理方式二
先停掉两端的drbd
[root@data-1-1 ~]# drbdadm down data [root@data-1-2 ~]# drbdadm down data
重新初始化元数据meta
[root@data-1-1 ~]# drbdadm create-md data [root@data-1-2 ~]# drbdadm create-md data
重新启动drbd
[root@data-1-1 ~]# drbdadm up data [root@data-1-2 ~]# drbdadm up data
最后在主上向备节点同步数据
[root@data-1-1 ~]# drbdadm -- --overwrite-data-of-peer primary data
drbd同步完成了,主备的drbd状态就正常了
浙公网安备 33010602011771号