C0reFast记事本

to inspire confidence in somebody.

0%

上一篇Blog里遗留一个问题:在打开了kube-proxy得tracing日志之后,除去定时同步iptables得日志之外,还出现了一些Calling handler.OnEndpointsUpdate相关得日志输出,这些输出其实是不太寻常的:

13:55:13 localhost kube-proxy[20761]: I0609 13:55:13.290051   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:14 localhost kube-proxy[20761]: I0609 13:55:14.502924   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:15 localhost kube-proxy[20761]: I0609 13:55:15.299633   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:16 localhost kube-proxy[20761]: I0609 13:55:16.515500   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:17 localhost kube-proxy[20761]: I0609 13:55:17.316952   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:18 localhost kube-proxy[20761]: I0609 13:55:18.525537   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:19 localhost kube-proxy[20761]: I0609 13:55:19.326566   20761 config.go:167] Calling handler.OnEndpointsUpdate
13:55:20 localhost kube-proxy[20761]: I0609 13:55:20.541238   20761 config.go:167] Calling handler.OnEndpointsUpdate

频率大约是1s一条,如果熟悉K8S的Watch-List机制的一眼就应该可以看出来原因:因为kube-proxy会watchEndpoints的变化,并对这些变化做相应动作,然后某些Endpoints更新了之后,就触发了这条日志。其实这个机制是没有问题的,在正常的K8S集群里,这些输出也没有问题。但是在我们的集群里就有些不正常了,因为我们当前的应用场景,根本就不存在需要Endpoints的情况!那到底是什么地方触发了Endpoints的更新?

阅读全文 »

在我们内部的一个系统是跑在K8S之上的,而这批机器上的dmesg日志里,老是会不停的刷下面的这个日志:

03:52:42 localhost kernel: nf_conntrack: falling back to vmalloc.
03:52:42 localhost kernel: IPVS: Creating netns size=2048 id=97719
03:54:37 localhost kernel: nf_conntrack: falling back to vmalloc.
03:54:37 localhost kernel: nf_conntrack: falling back to vmalloc.
03:54:37 localhost kernel: IPVS: Creating netns size=2048 id=97720
03:56:48 localhost kernel: nf_conntrack: falling back to vmalloc.
03:56:48 localhost kernel: nf_conntrack: falling back to vmalloc.
03:56:48 localhost kernel: IPVS: Creating netns size=2048 id=97721
03:58:20 localhost kernel: IPVS: Creating netns size=2048 id=97722

本来这些日志刷就刷了,也没什么大问题,但是呢,时间一长,因为logrotate机制,会把之前产生的日志给顶掉,导致有些时候想看之前的dmesg日志看不了了,这就比较难受了,终于,在当鸵鸟很长时间之后,想想还是找找原因,把这个问题解决一下。

阅读全文 »

自己5年前配的一台电脑比较老了,在那个Intel一家独大,疯狂挤牙膏的时代,i5-6500的CPU加上微星的B150M迫击炮,也算是当时比较主流的中端配置了。不过这么多年过去了,只有4核4线程的6500确实有点孱弱了,最近明显感受到CPu性能不够用了。正好趁着今年618,终于把平台换新了,我一直是AMD Yes党,喊了这么长时间,终于入手了微星的B550M Mortar迫击炮+AMD 5600X的套装,一下子从4核4线程进化到了6核12线程,整体性能应该要强很多了。

不过好事多磨啊,好不容易等到CPU和主板快递到货,到家兴致勃勃把CPU插上主板、装上散热器,又把老的主板从机箱里换出来,原来老机器有两条8G 2400MHz的内存,虽然相比现在动辄3600MHz、4000MHz的内存频率低了点,好在我也就日常使用对内存带宽和延迟也不太敏感,这个钱就省了。另外还有传家宝1060显卡、硬盘什么的统统不用换。

本来想着一次点亮,可惜事与愿违、一度心态炸裂!一开电源,发现启动不了,主板上Debug灯卡在内存上,一动不动。这就有点小尴尬了,按理现在内存这东西兼容性都比较好,为啥会卡在内存上?一顿折腾、4个插槽、两根内存、各种插法全试了一遍、又尝试恢复CMOS到出厂设置、仍然不好使。难不成真得让AMD背锅?这AMD不Yes了啊。。赶紧去主板官方网站上找了下内存兼容性列表,另外也问了一下卖家客服,看看是啥情况。

阅读全文 »

在几年前,写的一篇Blog:Unrecoverable Read Error Rate (URE),主要说起硬盘的一个重要指标:不可恢复读取错误率,在当时的场景下,如果是非企业级硬盘,一般这个指标是在1 bit per 10^14bit这个水平,也就是说每读取10^14bit的数据,其中某个bit有可能就是错误的,这会导致一些问题,比如如果是组建了一个比较大的RAID5阵列,当容量越大时,如果出现硬盘损坏,就会有很大概率无法恢复数据。

当然也不是没有其他办法,比如使用RAID 6,或者购买企业级硬盘,因为企业级硬盘在当时就可以提供1 bit per 10^15bit的指标,这样算下来读取100TB数据都是没什么大问题的。

不过随着近几年硬盘技术的发展,机械硬盘的容量越来越大,很多桌面级硬盘已经超过了10T,很显然,如果URE这个指标继续保持原有的水准,那这个硬盘就不太合格了,那么现在这些大容量硬盘的这个指标做到了多少呢?

于是我就找了找希捷桌面级硬盘的文档

barracuda-pro

阅读全文 »

在上篇Blog:Ceph OSD的心跳机制分析的最后,我们知道Ceph OSD将心跳检测失败的OSD打包成MOSDFailure消息发送给Monitor,但是还遗留了一个问题,就是Monitor是怎么处理这个消息的?又是在什么的情况下会把这个OSD标记为Down状态?所以这篇就是要把整个流程补完。

还是来看代码,首先需要注意的是,MOSDFailure不是一个原始的消息,我们得先找到这个消息对应得MSG TYPE,这样才能知道Monitor是怎么处理的,还是先看src\messages\MOSDFailure.h,找到MOSDFailure类的定义:

阅读全文 »

心跳机制在Ceph中承担非常重要的角色,所有OSD之间都需要通过心跳来确认各个OSD的状态,并且在OSD出现失联,Crash等情况下能及时的被发现,从而进行故障OSD摘除,触发数据重平衡等,保证数据的安全性。

所以弄明白当前Ceph的心跳机制,理顺OSD从故障到被集群踢出的流程是十分必要的。

心跳初始化 & 心跳发送

首先我们从Ceph OSD进程的启动main函数开始,代码在src/ceph_osd.cc

阅读全文 »

最近在尝试切换到CentOS 8,虽然不久前CentOS宣布从RHEL下游转向CentOS Stream了,但是相信以后会有类似的替代品出现,本质上也是在适应RHEL 8。这一试不要紧,一开始就被NetworkManager给吓住了,这都什么玩意,怎么这么难用?

一开始呢,想着先用被废弃但是还没被删除的老network-scripts顶一顶,想回滚也很简单:执行dnf install -y network-scripts && systemctl disable NetworkManager && systemctl enable network就好了,剩下的操作和CentOS 7里的ifup、ifdown脚本没什么区别,只是在执行的时候会出现一些警告信息提示这种方式已经废弃。

但是又想了想,面对新事物,第一个反应就是想着禁用或者删除它,特别是一个这和当初从CentOS 6切换到CentOS 7时候抵制systemd一样的么?特别是从大方向上看,NetworkManger会和systemd一样被越来越多的发行版接受,那学习一下并且适应新的网络管理方式,不是个坏事。

其实NetworkManager不是个新事物了,之前笔记本装的ArchLinux系统,很早就切换到NetworkManager了,只不过因为有GUI管理工具,而且场景比较单一,所以没有过多的关注。等到了服务器端,场景比较复杂,以前积累的东西就不管用了。最主要的,是和之前管理网络的思路出现了一些冲突,产生了一些排斥心理,觉得不好用。等静下心来仔细看了看相关的文档,也做了一些实验,适应了这种新的管理方式之后,发现NetworkManager还是值得一试的。所以还是面对几个场景分享一下几个例子,希望能帮助到更多的人完成切换吧。

阅读全文 »

在上一篇Blog:/proc/cpuinfo里的CPU型号怎么来的?里,可以知道Linux系统是根据CPUID指令来显示具体的CPU型号的。所以很自然的一个想法:是不是可以自定义显示的内容呢?

答案显而易见,必然是可以的。但是如果要改物理CPU的寄存器,那确实会有些困难,不过没关系,我们还有虚拟机嘛,理论上虚拟机可以虚拟这些东西,那改动起来应该也是比较方便的。

想要修改这些寄存器,首先得先看看CPUID指令在Qemu里是怎么处理的:

阅读全文 »

今天有一件小事,勾起了我的好奇心。有个同事反馈说,我们虚拟的CPU主频较低,对性能有影响,于是就问了一下,怎么看主频的,很简单,看看lscpu里的Model name:字段就行了:

[root@]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
...
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Gold 6240R CPU @ 2.40GHz
Stepping:              7
CPU MHz:               2394.374
BogoMIPS:              4788.74
Hypervisor vendor:     KVM
Virtualization type:   full
...

可以看到这台机器的Model name:Intel(R) Xeon(R) Gold 6240R CPU @ 2.40GHz,@符号后面就是2.40GHz,也就是这颗CPU的基础频率,其实之前写过一个文章再谈CPU的电源管理(如何做到稳定全核睿频?),我们线上实际也是跑在睿频频率上的。实际这个@后面的频率并不能反映证实频率。

那么问题来了。这个Model name到底从哪读的?

阅读全文 »