很多人看到这个标题会很奇怪，Ceph不是有一个RESTful API么，为什么又要造一遍轮子？
的确，Ceph的官方组件Dashboard，内置了一些非常强大的RESTful API，功能也是比较的全面。为啥又要自己写一个呢？在我们的环境里，有一个自己实现的类似Openstack的虚拟机管理平台。而这个平台对接Ceph RBD时，就是使用的Dashboard模块提供的API。个人觉得啊，官方的API，虽然功能全，但确实对于对接的用户来说，真的不是那么友好。这里举几个简单的点：
上一篇服务器网络启动方式探索Part1：Legacy启动篇里，总结了一些在Legacy启动模式下的一些网络启动方案，那么这一篇，很自然的就需要介绍一下在纯UEFI模式下的网络启动了。
相比Legacy启动直接读取MBR启动分区的第一个扇区作为引导的逻辑，UEFI启动变得强大了很多，在UEFI模式下，固件直接具有的读取FAT文件系统的能力，并且直接通过运行EFI可执行文件的方式进行引导。
因为这个显而易见的变化，导致对应到PXE相关的实现上，也会有相应的区别。不过相比于Legacy启动的那些方案，区别不是那么大，依然是可以做到功能上一一对应的，同样的，我们从最简单的情况开始看起。
最近花了很多时间、调研了服务器的网络启动方案，目的呢是想设计并实现一个更加统一和标准化的装机系统尽最大努力把物理机、裸金属、虚拟机、以及基于裸金属的虚拟机的操作系统镜像和装机方案融合起来，同时能适应现代的硬件。
本来以为是一件很轻松的事情，毕竟基于PXE的方案已经运行很多年了，似乎简单的修改一些问题、老方案上打打补丁就能很好的实现。但现实又被疯狂打脸，因为面对多个OEM厂商提供的服务器、每家厂商不同的BMC管理系统、每家厂商不同的接口格式和功能。在没有统一服务器供应商或者基于ODM方案之前，似乎那个“完美”的方案并不很容易实现。
不过呢，这些问题也都不重要，关键是在整个调研的过程中，也是补足了很多似懂非懂、一知半解的技术细节，也算是一个非常大的提升了，其实短期的妥协方案，也不影响最终的实现效果。所以准备写写这段时间学习到的知识，也算是补足了之前网络上找不到技术细节的坑吧，本篇算是第一部分吧，从最简单的开始，说说当前Legacy Boot相关的网络启动方案。
最近为了用上更新一点的软件，把运行在WSL2里的Ubuntu 20.04 LTS版本升级了一下，升级到了Ubuntu 21.04，升级之后呢，大部分功能都正常（当然本身我用的功能也不会很多），但是确实也遇到了个小问题：Docker Daemon无法启动了。这个确实很影响工作，因为很多时候写完代码会本地打个镜像运行一下，简单测试一下代码是否有问题。但是升级之后，突然发现Docker用不了了。
具体点呢，是会报一个iptables相关的错误：
......
WARN[2021-10-23T11:30:05.864210900+08:00] Your kernel does not support cgroup blkio throttle.write_iops_device
INFO[2021-10-23T11:30:05.864538700+08:00] Loading containers: start.
INFO[2021-10-23T11:30:06.135353300+08:00] stopping event stream following graceful shutdown error="context canceled" module=libcontainerd namespace=moby
INFO[2021-10-23T11:30:06.135542600+08:00] stopping healthcheck following graceful shutdown module=libcontainerd
INFO[2021-10-23T11:30:06.136083800+08:00] stopping event stream following graceful shutdown error="context canceled" module=libcontainerd namespace=plugins.moby
failed to start daemon: Error initializing network controller: error obtaining controller instance: unable to add return rule in DOCKER-ISOLATION-STAGE-1 chain: (iptables failed: iptables --wait -A DOCKER-ISOLATION-STAGE-1 -j RETURN: iptables v1.8.7 (nf_tables): RULE_APPEND failed (No such file or directory): rule in chain DOCKER-ISOLATION-STAGE-1
(exit status 4))在上一篇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这个指标继续保持原有的水准，那这个硬盘就不太合格了，那么现在这些大容量硬盘的这个指标做到了多少呢？
于是我就找了找希捷桌面级硬盘的文档：
在上篇Blog：Ceph OSD的心跳机制分析的最后，我们知道Ceph OSD将心跳检测失败的OSD打包成MOSDFailure消息发送给Monitor，但是还遗留了一个问题，就是Monitor是怎么处理这个消息的？又是在什么的情况下会把这个OSD标记为Down状态？所以这篇就是要把整个流程补完。
还是来看代码，首先需要注意的是，MOSDFailure不是一个原始的消息，我们得先找到这个消息对应得MSG TYPE，这样才能知道Monitor是怎么处理的，还是先看src\messages\MOSDFailure.h，找到MOSDFailure类的定义：