Ctdb Rados（二）：多场景断网高可用

原文地址： https://www.tony-yin.site/201…

之前写过一篇文章【Ctdb Rados方式导致All Banned的问题】，谈到了当ctdb将recovery lock设置成rados的方式后，断网master节点会造成所有ctdb节点All Banned，主要原因是master意外断网没有释放锁，其他节点无法获取到锁，当时的解决方案是每5分钟检查一次ctdb状态，如果连续两次发生了All Banned的情况，则手动删除lock，这种做法在最近的测试中遇到了一些问题，本文对这些问题进行剖析并对相应的解决方案进行分享。

完整代码地址：https://github.com/tony-yin/C…

场景一

如果基于原来的做法，ctdb发生All Banned的情况，需要十分钟的监控时间加上两分钟左右的recovery时间，也就是说大概需要十二分钟才能恢复ctdb服务，这样看来高可用有点名实其副了，这个也会明显地影响存储业务的正常运行。后来，我们讨论出新的方案：每5s检查一次ctdb的状态，All Banned的次数累计到5次才确定为该故障场景，然后手动删除lock，最终要保证ctdb能够在2min内完成恢复。

问题1

cron tab最短周期只支持分钟级别，所以如何5s检查一次便是一个问题。

代码是死的，人是活的，虽然cron tab只支持分钟级别，但是我们可以每分钟调用一个脚本，然后在这个脚本中遍历12次，每次调用ctdb monitor脚本，然后sleep 5s，这样就可以达到每5s检查一次ctdb的效果了。

# ctdb_monitor
* * * * * root /etc/ctdb/cron-seconds# cron-seconds
#!/bin/bash
for((i=1;i<=12;i++));do../monitor_ctdb
sleep 5
done

这样检查到ctdb发生All Banned情况，只需要花费25s，剩下的就是recovery的时间了。

问题2

当ctdb master节点的network服务断掉，其他两个节点（我的开发环境是三节点的虚拟机环境）便会选举一个为master节点，然后去获取lock，因为原master没有释放锁，导致所有节点All Banned，即使我们手动删除了锁，但是这时候其他两个节点仍然处于Banned的情况，需要等到Ban Timeout才会再次尝试获取锁并开始恢复过程，这个timeout的时间是300s，即5min，这显然是我们不能接受的，所以我们要在删除lock后，重启所有节点的ctdb服务。

不过该如何触发该重启操作呢？

我们在删除lock后将ctdb所有节点的ip作为对象存进rados中，然后在每5s监控的脚本中，查看rados中是否存在本节点的ip对象，如果有，则尝试重启ctdb操作，重启后便删除该对象。

function save_nodes_ip() {nodes=$(ctdb listnodes)for node in $nodes; doecho "$node" > $noderados -p rbd put $node $noderm -f $nodedone
}function get_current_node_ips() {ips=$(/usr/sbin/ip addr | grep "inet " | awk '{print $2}')echo $ips
}function monitor_nodes_ip_in_rados() {ips=$(get_current_node_ips)for ipinfo in $ips; doip=${ipinfo%/*}if $(timeout 10 rados -p rbd ls | grep "$ip" -qw); thensystemctl restart ctdbrados -p rbd rm $ipfidone
}

至于为什么三个节点的ip都要存入rados，这个是因为原master节点恢复网络后，ctdb服务的状态为failed，同样需要重启ctdb服务才能正常恢复原master节点。

注意：

这边有两个问题，当时浪费了我不少时间，问题不是多么深奥，但是不易发现。。。

第一个问题便是ips=$(/usr/sbin/ip addr | grep "inet " | awk '{print $2}')这行代码，原来的写法是ips=$(ip addr | grep "inet " | awk '{print $2}')，当时发现ip总是获取不到，然后无论是命令行还是脚本运行都可以正常获取到，后来还是同事提醒才发现在crontab脚本中，shell命令默认是/usr/bin/下的，而ip命令则是/usr/sbin/下，所以这里的命令我们需要全路径。（这个需要格外注意！！！被坑的不要不要的。。。）

第二个问题便是rados -p rbd ls | grep "$ip" -qw这行代码，当时没注意写成了rados -p rbd ls | grep "$ip" -w，发现if判断时常有问题，一开始还以为不能grep数字什么的，后来才发现没有加q，q表示安静模式，不打印任何标准输出，如果有匹配的内容则立即返回状态值0。

场景二

“断网”这个词不够具体，在实际生产环境中，一个集群中，一般都会有多个网络，就拿本人的ceph集群环境来说（物理机环境，并非前文提及的虚拟机开发环境），ceph有个public network和cluster network，而ctdb也有它的node network和public network，ceph的public和ctdb的public是同一网段，ceph的cluster是单独网段，ctdb的node是单独的网段。所以ctdb master断网可以分为三种情况：

拔掉ctdb master node网段网线
拔掉ctdb master public网段网线
断掉ctdb master network服务

当拔掉ctdb master public网段网线，这没有什么好说的，ctdb master节点服务还存在，只是master节点上的public address不可用了，会漂移到其他节点上。

问题1

当拔掉ctdb master node网段网线后，master节点仍然有public网卡，（这里注意）它仍然可以获取其他ctdb节点的状态，而其他节点却不可以获取它的状态，因为master的node节点ip不存在。所以造成的结果就是原master节点还默认自己是master节点，而其他的节点却又选举出了新的master，我们的脚本因为All Banned手动删除了lock，这时候其他节点可以正常恢复ctdb服务，但是当ctdb master节点断网再恢复后，它还以为自己是master，会不断去获取锁，而原来的锁已经被我们手动删除，这时候新的锁被新的master掌握，所以此时产生脑裂，我们要牺牲原master节点，也就是断网节点，所以需要重启它。这个重启触发机制我们是通过在每次删除lock之后在rados中存入ctdb所有节点的ip作为object（这就是为什么要存入所有节点的ip），然后只要发现有这个object便执行ctdb重启操作，然后便删除这个对象。至于为什么要存所有对象是因为除了原master需要重启之外，另外两个正常节点发生All Banned的情况，默认timeout时间是300s（这个上面也提到过），我们为了减少恢复时间，直接在删除lock后重启ctdb；

问题2

由于现在ctdb的锁是放在rados中，而不是以前的cephfs的方式了。所以当master断网再恢复时，它会不断地去rados获取他原来的锁，这是获取锁的进程越来越多，会阻塞住rados服务，我们可以通过ps -ef | grep rados_helper看到进程不断变多，那么rados服务不能正常读写就影响到我们上一条的机制，不能读rados中是否含有本节点ip的对象，就没办法进行重启操作，那么这样它就会不断地继续获取lock，所以我们在这里又加了一个机制，如果ps -ef | grep rados_helper的数目超过6个，就默认启动重启ctdb服务。

function monitor_get_lock_timeout() {count=$(ps -ef | grep rados_helper | wc -l)if [ $count -ge $RADOS_HELPER_PROCESS_MAX ]; thensystemctl restart ctdbupdate_last_ctdb_restart_timefi
}

问题3

ctdb目前重启的机制有点多，有自身自带的故障重启，也有我们监控脚本的异常情况，很容易发生重复重启，还有可能rados_helper堆积的进程很多，比如20个，我们的脚本是5s一次，也许20个的时候重启了，过5s，进程释放也需要时间，可能此时还有10个，那么大于我们规定的6个，就会继续重启，这种重复重启没有必要，所以我们要加上ctdb重启的周期限定2min。

function get_ctdb_restart_interval() {last_time=$(get_ctdb_restart_last_time)if [ -z "$last_time" ]; theninterval=$(expr $RESTART_CTDB_INTERVAL_MAX + 1)elsecurrent_time=$(date +%s)interval=$(expr $current_time - $last_time)fiecho $interval
}

考虑并解决以上提到的问题，基本上可以覆盖以上三种断网的场景了，在监控和管理ctdb的过程中，一定要小心，不能影响到业务正常运行。

总结

生产环境网络结构错综复杂，往往在虚拟机上开发的功能当时好好的，到了物理机上面测试会发生各种问题，此时，我们首先要搞清楚网络拓扑结构，熟悉硬件配置，各网段的作用和相互之间的关联，这样遇到问题我们可以顺藤摸瓜，同样ctdb的原理也需要掌握才能了解它各种行为的触发机制，才能更好的定制化监控和管理。之后我会花点时间好好地研究一下ctdb，然后再单独做分享。

完整代码地址：https://github.com/tony-yin/C…

Ctdb Rados（二）：多场景断网高可用相关推荐

当当网高可用架构之道--转
声明:本文内容来自于TOP100Summit旗下技术沙龙品牌into100沙龙第17期:高可用高并发解决之道,如需转载请联系主办方进行授权. 嘉宾:史海峰,当当架构部总监.2012年加入当当,负责总 ...
当当网高可用架构之道
嘉宾:史海峰,当当架构部总监.2012年加入当当,负责总体架构规划.技术规范制定,善于把握复杂业务需求,提出创新性解决方案,参与重点项目方案设计,对系统架构进行持续改造优化,推动技术革新,组织内外部技 ...
[转]当当网高可用架构之道--转
本文转自:http://www.cnblogs.com/davidwang456/articles/5340650.html 声明:本文内容来自于TOP100Summit旗下技术沙龙品牌into100 ...
字节跳动异构场景下的高可用建设实践
本文首发于:火山引擎开发者社区: 作者:字节跳动基础架构团队系统治理方向负责人邵育亮本文主要为大家介绍字节跳动在高可用建设上的一些思考和落地经验.先给大家简单介绍一下系统治理团队是做什么的.系统治理 ...
消息系统kafka之二 kafka的HA（高可用）
在前面的<消息系统kafka之一系统简介>的为什么选择kafka中已经提到了kafka高可用的特性. 下面是kafka与其他消息系统之间的区别可以看出,kafka支持持久化消息,消息回 ...
走进GBase 8s之高可用功能（二）HAC灾备高可用
GBase 8s HAC(容灾高可用)采用基于数据库日志的增量数据同步技术实现节点高可用.根据灾备距离不同分为同城容灾高可用和异地灾备高可用.同城容灾高可用支持一主一从的部署方式,异地灾备高可用支持一 ...
【Redis】分布式场景下Redis高可用部署方案
文章内容 1.Redis高可用概述 2.持久化 1)RDB持久化 2)AOF持久化 3.Redis主从复制 4.Redis哨兵模式 3.Redis集群模式 1.Redis高可用概述参考博文: 深入学 ...
微信新功能-手机停机断网也可用微信充话费
长久以来,我们使用手机,一直都面临一个悖论:如果你的手机欠费,就会停机,这个时候你最需要的就是赶紧充值.但是停机之后,手机就没了信号.如果再加上没有WiFi,那就陷入了死循环. 前几天,微信宣布,微信 ...
【错误记录】Flutter 设备连接显示 Loading... ( 断网 | 删除 flutter/bin/cache/lockfile 文件 )
文章目录一. 报错信息二. 解决方案一. 报错信息手机已经打开开发者模式 , USB 调试一打开 , 但是在 Androud Studio 中的设备一直显示 " Loading &q ...

Ctdb Rados（二）：多场景断网高可用

Ctdb Rados（二）：多场景断网高可用

场景一

问题1

问题2

场景二

问题1

问题2

问题3

总结

Ctdb Rados（二）：多场景断网高可用相关推荐

最新文章

热门文章