C0reFast记事本

在之前的好几篇Blog里，都使用了火焰图来对业务进行性能优化，之前为了抓取火焰图，需要用到好几个工具进行组合，流程还是比较麻烦的。随着RHEL的版本更新，Redhat提供了一个更简单快速的方法实现了一键抓取火焰图的功能。

对于比较了解云计算的人来说，一定接触过AWS、阿里云的API接口，这两者的API调用方式很相似，当然具体谁参考谁这里就不深究了。以给EC2/ECS添加Tag这个接口为例：

AWS:

https://ec2.amazonaws.com/?Action=CreateTags
&ResourceId.1=ami-1a2b3c4d
&ResourceId.2=i-1234567890abcdef0
&Tag.1.Key=webserver
&Tag.1.Value=
&Tag.2.Key=stack
&Tag.2.Value=Production
&AUTHPARAMS

阿里云：

https://ecs.aliyuncs.com/?Action=TagResources
&RegionId=cn-hangzhou
&ResourceId.1=i-bp1j6qtvdm8w0z1o0****
&ResourceId.2=i-bp1j6qtvdm8w0z1oP****
&ResourceType=instance
&Tag.1.Key=TestKey
&Tag.1.Value=TestKey
&<公共请求参数>

接上篇LSI RAID卡芯片和各个OEM对应卡型号列表里说的后续DIY NAS的想法，经过快3个月的时间，终于来更新整个DIY过程了，总结起来在整个过程中，收获的主要还是折腾的乐趣，要说折腾的尽头是白群晖，随着时间的推移，个人还是比较认同的，不过不得不说白群晖确实太贵了，都说群晖是买软件送硬件，但是这软件也太贵了点。

最近想买一张拆机的HBA卡组一个NAS玩玩，目前用SAS 2308的拆机OEM HBA卡（IT Mode，也可以刷固件刷成IR Mode从而直接变成RAID卡，但是只支持RAID 0, 1, 1E和10）只需要不到100块钱，非常划算，除了功耗高点（差不多10W）比较热之外，感觉没啥缺点。

于是就被各种原厂的或者OEM厂的各种型号搞晕了，因为基于这个芯片的各种OEM马甲卡实在太多了。于是乎就找到了一篇神贴，帖子里覆盖了几乎所有的LSI的RAID卡芯片以及大部分国外厂商对应的OEM卡型号，而且一直在更新，最新的一些SAS芯片也有记录，比较可惜的是国内的一些OEM厂商，特别是在淘宝保有量相当大的浪潮的OEM卡型号没有记录。

帖子的地址在：LSI RAID Controller and HBA Complete Listing Plus OEM Models。有需要的可以参考一下。

后续组NAS的经历我也会持续分享，敬请关注~

最近折腾了一小段时间的PCDN，家里刚好有一个闲置的JetsonNano和一块闲置的SSD，刚好可以跑跑PCDN，每天挣个宽带钱。具体跑的哪家，就不说了，说说在这过程中遇到的一个小问题：一般来说，PCDN或者类似的业务，对磁盘的写入压力还是比较大的，虽然可能平均的写入带宽并不高，但是也架不住每天读写的时间相当长，虽然我这块SSD是闲置的，但好歹是个传家宝，不管怎么说，还是有那么点点心疼的，肯定是不太希望哪天这SSD被写坏了。

在这种场景下，尽可能延长SSD的写入寿命就很重要了，而方法之一呢，就是想办法把SSD的Trim命令给用上。

用上Trim命令之前，可以先简单了解一下背后的逻辑，具体的可以参考Wiki，简单来说呢，因为SSD依赖垃圾回收机制来平衡NAND的磨损，但是呢具体到一整个LBA空间，只有文件系统知道哪些数据块是有效数据，所以就需要通过Trim命令，建立文件系统空闲空间和SSD底层数据块的关联，从而让SSD的主控更好的进行垃圾回收操作，一般来说，合理的使用Trim，可以有效的提高SSD的性能和寿命。当然了，Trim命令是ATA指令集里的，也就是SATA接口SSD才会有，对于SCSI以及SAS接口SSD，还有NVMe SSD来说，也有相应的UNMAP和Deallocate指令，作用都是一样的。

一般来说，在Linux下，一个设备是否支持Trim操作，可以通过lsblk --discard进行查看，当输出中的DISC-GRAN和DISC-MAX列不为0时，说明这个设备是支持Trim操作的：

本文是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相关的网络启动方案。