C0reFast记事本

本文是SPDK文档SPDK “Reduce” Block Compression Algorithm的翻译，在读SPDK的文档过程中，刚好看到了SPDK里bdev reduce模块实现背后的算法描述，于是就想着翻译一下，正好也借翻译的同时仔细理解一下背后算法的原理，当然本人的水平有限，如果译文有任何歧义，还请参考原文并以实际原文为准。

概述

SPDK的“reduce”块压缩方案使用SSD存储压缩后的块数据，同时将元数据存放到持久内存中。此元数据包含用户数据的逻辑块到压缩后的物理块的对应关系。本文档中描述的方案是通用的，不依赖于包括SPDK在内任何特定的块设备框架。该算法会在一个叫做libreduce的库中实现。更高层次的软件可以基于该模块创建和呈现特定的块设备。对于SPDK来说，bdev_reduce模块封装了libreduce库，从而在SPDK中提供一个bdev以实现压缩功能。

本方案仅仅解释压缩后的数据块和用于跟踪这些数据块的元数据的管理。它依赖于高层软件模块来执行压缩操作。对于SPDK，bdev_reduce模块利用DPDK compressdev框架执行压缩和解压缩。

（需要注意的是，在某些情况下，数据块可能是不可压缩的，或者无法压缩到足以实现空间节省的程度。在这些情况下，数据可能不经过压缩，直接存储在磁盘上。“压缩的存储块”包括这些不经压缩的块。）

最近接到一个需求：把K8s的认证和授权体系，整合到我们内部的系统中，使得我们内部系统的用户，可以无缝的直接访问K8s集群，同时也需要限制好用户对应namespace的权限。

对于需求的用户授权也就是authorization (authz)部分，实现思路还是比较简单的，毕竟K8s的RBAC实现相对来说还是非常完善的，而且RBAC对于我们目前的用户和组织权限管理理念十分的接近。所以只需要将目前系统里的用户权限和组织关系，对应到一系列的RBAC Role和RoleBinding里，就可以实现对于用户权限的精细化控制。

而对于用户的认证authentication (authn)部分，K8s提供了非常多的身份认证策略。但是如文档里明确的一点：

很多人看到这个标题会很奇怪，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了啊。。赶紧去主板官方网站上找了下内存兼容性列表，另外也问了一下卖家客服，看看是啥情况。