C0reFast记事本

在我们内部的一个系统是跑在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这个指标继续保持原有的水准，那这个硬盘就不太合格了，那么现在这些大容量硬盘的这个指标做到了多少呢？

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

在上篇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到底从哪读的？

当一台机器有超过1块网卡，并且配置的IP地址不在一个段里的时候，会出现在外部只有一个IP地址能够ping通的情况，举个最简单的例子：

一个有2块网卡的机器：

[root@test]# ip addr
2: enp24s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 11:11:11:11:11:11 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.10/24 brd 192.168.100.255 scope global enp24s0f1
       valid_lft forever preferred_lft forever
3: enp24s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 22:22:22:22:22:22 brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.10/24 brd 192.168.200.255 scope global enp24s0f1
       valid_lft forever preferred_lft forever

可以看到两块网卡，分别配置了192.168.100.10和192.168.200.10这两个IP，再看看机器的默认路由：

针对网卡名字这个问题，其实之前也讨论过一次，主要是如何利用udev去重命名网卡，里面提到了新的一致性命名规则，但是没有细说。

当然肯定是遇到问题了，所以针对网卡命名的细节，需要再探讨一下。

其实目前大家还是更熟悉老的那种eth0,eth1…那种命名，目前我们大部分生产环境里也是这么用的。但是随着网卡数量越来越多（在我们使用的SR-IOV场景，加上VF虚拟网卡，机器上已经有超过16个网卡）这种命名规则已经不适应现代的硬件和操作系统了，所以最近我们也从老的命名方式，切换到操作系统默认的一致网络设备命名。

不过因此也带来了一些问题，发现不同厂商，或者不同机器会有命名不一致的情况，举个例子：

这是某台机器的网卡名字：