Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederichenfu.com
C0reFast记事本
Get the latest updates from C0reFast记事本 directly as they happen.
Follow now 17 followers
Latest posts
Last updated about 3 hours ago
一个中断关闭时间太长导致的网络延迟问题
about 3 hours ago
近期线上出现了一个问题，现象是有一台机器，网络出现了不定时的延迟：# ping -i 0.05 192.168.0.5#...64 bytes from 192.168.0.5: icmp_seq=673 ttl=63 time=0.203 ms64...
一个Linux新老内核对于硬件中断的统计差异
17 days ago
最近接到一个客户反馈，说他们的机器，遇到了top命令中，hardirq的值特别高的问题。top - 15:27:37 up 43 days, 3:42, 1 user, load average: 44.75...
IPIP隧道导致的DPDK收包RSS队列不均匀问题
5 months ago
最近线上出现一些VM网卡收包队列不均匀的问题，即使是将网卡队列中断均匀的绑定到各个CPU上，依然会出现某个核特别高的情况：%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa...
在KVM虚拟机中开启TSC作为时钟源
5 months ago
上一篇x86平台的TSC（TIME-STAMP COUNTER）中大概分析了一下TSC的一些相关的特性，以及TSC作为系统时钟源的一些基础条件。那么，在虚拟化的场景下，如何让Guest也用上TSC呢？这篇文章就来讨论一下TSC在KVM虚拟化中的使用。基础分析默认情况下，KVM虚拟机首选的时钟源是kvm-clock，即使将VM的CPU Model设置为host-passthrough，也不会使用TSC作为时钟源。# lscpu|grep FlagsFlags: fpu vme de pse tsc msr pae...
x86平台的TSC（TIME-STAMP COUNTER）
6 months ago
今天跟着Intel的开发手册，看看如何随着Intel对TSC不断的修改和增加新特性，让TSC从一个简单的性能计数器发展成当前Linux上x86平台最重要的时钟源之一。本文基本上可以看作是Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming...
一个UFO引发的惨案
about 1 year ago
首先需要解释一下标题，原谅我当了一回标题党，此UFO不是Unidentified flying object，而是在网络中的一个Oflload卸载技术UDP fragmentation offload。事情的起因是这样的，我们最近尝试将线上的虚拟机，从基于网卡SR-IOV+直通的方案，切换到基于DPDK+vhost-user的方案，以换取热迁移的效率提升。从之前的模拟压测和线上灰度效果来看，新的DPDK方案的性能和稳定性都处于很好的水平，在我们的场景下可以很好地满足需求。直到灰度到某个业务的时候，发生了一些问题，导致了虚拟机的网络中断。我们通过热拔插方式进行网络切换，首先，会把当前直通的网卡从虚拟机中热拔出来，然后，再把一个vhost-user网卡热插到虚拟机中，从而实现网卡的切换。在切换过程中，大致会有3-5s左右的网络中断，但根据和业务的沟通，在单线程的操作情况下，这样的中断是没有问题的，不会影响业务。为了保证业务的稳定，我们在网卡切换后，会持续ping 10s对应的虚拟机，确保网络正常后才会进行下一台的操作。然后问题就发生了，在某些虚拟机切换网卡之后，大约5分钟内，网络是正常的，但是超过5分钟之后，突然网络就不通了，这个问题也是随机的，而对于网络不通的机器，通过重启DPDK进程的方式，网络又可以恢复几分钟，然后继续不通。这些现象确实在之前的测试中没有遇到过。从日志看，有少量的DPDK进程打印了这两条日志：VHOST_DATA: (/tmp/ens8f0-2.sock) failed to allocate memory for...
DIY一个8盘位全闪NAS
over 2 years ago
接上篇LSI RAID卡芯片和各个OEM对应卡型号列表里说的后续DIY NAS的想法，经过快3个月的时间，终于来更新整个DIY过程了，总结起来在整个过程中，收获的主要还是折腾的乐趣，要说折腾的尽头是白群晖，随着时间的推移，个人还是比较认同的，不过不得不说白群晖确实太贵了，都说群晖是买软件送硬件，但是这软件也太贵了点。需求描述和分析说起来，为啥会有个DIY NAS的需求呢？一个重要的原因是家里的小宝贝出生了，不知不觉也拍了好多的照片和视频，还是希望能更长久的把这些记忆保留下来。另外呢，之前更新自己的电脑，淘汰下来一套i5 6500 CPU加16G内存以及主板的准系统，买个机箱还有电源就直接可以用了，本着废物利用的原则，做个NAS也不亏，而且还多了很多可玩性。其实单纯从保存数据来说，将数据存放到任何一个公有云的对象存储上，是个最终极的方案，因为目前各个厂商提供的对象存储数据持久性SLA都达到了11或者12个9（99.999999999%-99.9999999999%），这基本意味着几乎不存在数据丢失的可能性了。但是确实这个方案也是最贵的，毕竟每TB存储每月都需要消耗对应的存储费用，随着时间增长，即使是最便宜的冷归档类型，也依然是个不小的消耗。那到底需要多少的存储容量呢？针对我个人而言，目前可预见的容量，应该不会超过10T，当前1-2年内所需求的容量更小，大概只需要1到2T的样子。针对这个容量，其实已经可以考虑全SSD的存储方案了，其实相比于使用HDD的方案，纯SSD的NAS有以下几个好处：首先是噪音角度，相比HDD运行时的“炒豆子”声来说，SSD 0噪音，这可以直接解决夜间安静环境下HDD低频噪音对睡眠质量的影响；其次是稳定性和数据安全角度，根据我们公司数据中心有比较大规模的SSD和HDD的使用经验，同时参考backblaze提供的统计数据，可以看出SSD的稳定性远超过HDD，这带来了两个优势，一个是相比HDD，SSD损坏的概率低，这可以减少存储池修复的可能性，另外因为读写速度上SSD快很多，在坏盘的情况下，SSD也可以做到更坏的修复速度，从而可以提供更好的数据持久性。当然SSD依然还是有缺点的，很明显当前SSD比HDD依然贵很多，以当前的价格来说，SSD成本大约0.4元/GB（大多数1T SATA SSD），HDD大概只有0.12元/GB（西数HC550 16T）。但是对于我目前的容量需求来说，使用SSD的成本相比HDD没有差距太大，多花的那部分成本，对于0噪音来说是相当值得的。除了磁盘的选型，还有一些其???的需求，诸如盘位数量大于等于4，硬盘需要支持热拔插，存储池可以动态扩容，移动端、桌面端数据自动同步等等，不过这些也都算是比较基础的需求了。硬盘笼选择针对硬盘热拔插的需求，肯定还是要搞个硬盘笼的，不管怎么说，相比于直接把硬盘塞机箱里，有个热拔插硬盘笼一下子逼格就上来了。所以一直花了不少精力去找合适的硬盘笼，主要还是集中于服务器的拆机件，这里给几个当时考虑的一些方案。浪潮12盘位3.5寸硬盘笼首先第一个选择是买浪潮的12盘位3.5寸硬盘笼，目前的价格大概150块钱的样子，还挺便宜，感觉应该都是当初Chia矿老板淘汰下来的，这些硬盘笼基本都有大4P的电源接口以及MiniSAS（SFF8087）接口，使用起来还是比较方便的，当然缺点是确实占地比较大，毕竟是适配的2U机箱，因为本来也一直坚持全闪的方案，所以3.5寸的硬盘位就没有必要了，即使很便宜，依然放弃了这个方案。Intel 8盘位热插拔笼子(8 AnyBay)这是Intel一个颜值和功能都超级能打的硬盘笼，具体的参数可以参考Intel的Spec文档（不得不说Intel的文档写的是真的好），甚至当前这个时间点，依然在量产状态，这个笼子一般来说都是在2U机箱上做竖插24盘位的组件的，这几乎是我心目中最理想的硬盘笼选择，8盘位AnyBay，支持SATA、SAS、U.2...
分享一个记录LSI RAID卡芯片和各个OEM对应卡型号列表的神贴
over 2 years ago
最近想买一张拆机的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...
在移动硬盘盒上启用SSD的Trim功能
over 2 years ago
最近折腾了一小段时间的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操作的：jetson-nano:chenfu:# lsblk --discardNAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZEROsda 0 0B 0B...
SPDK的“Reduce”块压缩算法
about 3 years ago
本文是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框架执行压缩和解压缩。（需要注意的是，在某些情况下，数据块可能是不可压缩的，或者无法压缩到足以实现空间节省的程度。在这些情况下，数据可能不经过压缩，直接存储在磁盘上。“压缩的存储块”包括这些不经压缩的块。）一个压缩块存储设备是一个建立在拥有相似大小的后备存储设备之上的一个逻辑实体。其中的后备存储设备必须是精简置备（thin-provisioned）的从而才能真正意义上从后文描述的实现中获得空间节省。同样该算法除了一直使用后备存储设备上可用的编号最低的块之外，对后备存储设备的实现没有直接的了解。这保证了在精简配置的后备存储设备上使用此算法时，在实际需要空间之前不会分配对应空间。后备存储的大小，必须考虑最坏情况，也就是所有数据都不可压缩的情况。在这种情况下，后备存储的大小和压缩块设备的大小是一致的。另外，本算法基于永远不会原地写这个前台来保证原子性，所以在更新元数据之前，可能还需要额外的一些后备存储空间来作为临时写缓存。为了最佳性能考虑，所有后备存储设备都将以4KB为最小单位进行分配、读取和写入。这些4KB的单元被称作“后备IO单元”（backing IO units）。他们被一个称作“后备IO单元索引”（backing IO unit indices）的索引列表中以0到N-1编号进行索引。在一开始，这个完整的索引代表了“空闲后备IO单元列表”（free...
实现一个Kubernetes的身份认证代理服务
about 3 years ago
最近接到一个需求：把K8s的认证和授权体系，整合到我们内部的系统中，使得我们内部系统的用户，可以无缝的直接访问K8s集群，同时也需要限制好用户对应namespace的权限。对于需求的用户授权也就是authorization (authz)部分，实现思路还是比较简单的，毕竟K8s的RBAC实现相对来说还是非常完善的，而且RBAC对于我们目前的用户和组织权限管理理念十分的接近。所以只需要将目前系统里的用户权限和组织关系，对应到一系列的RBAC Role和RoleBinding里，就可以实现对于用户权限的精细化控制。而对于用户的认证authentication (authn)部分，K8s提供了非常多的身份认证策略。但是如文档里明确的一点：Kubernetes 假定普通用户是由一个与集群无关的服务通过以下方式之一进行管理的：负责分发私钥的管理员类似 Keystone 或者 Google Accounts 这类用户数据库包含用户名和密码列表的文件有鉴于此，Kubernetes 并不包含用来代表普通用户账号的对象。 普通用户的信息无法通过API调用添加到集群中。K8s并不自己管理用户实体，所以是没有办法像RBAC那样，通过创建一个“User”资源，来把某个用户添加到集群里的。其实这个特点，对于系统集成来说，可能更是一个优点，因为这直接避免了第三方系统的用户属性和K8s“用户”属性可能存在的不兼容问题。而对于目前的需求而言，需要做到以下几点：最好是基于Token实现，并且这个Token由我们自己的系统生成，同一个Token，既可以调用原有的API，也可以调用K8s的API。尽可能保证K8s兼容性，最好用户可以无缝的，不需要经过复杂的配置，直接使用kubectl访问到集群。记录所有用户的访问记录以便于各种审计工作。针对这几个需求，又通读了一遍文档之后，最终决定使用身份认证代理这个方式，怎么理解呢：K8s...
使用Go-Ceph库编写一个更简单的RBD HTTP API
about 3 years ago
很多人看到这个标题会很奇怪，Ceph不是有一个RESTful API么，为什么又要造一遍轮子？的确，Ceph的官方组件Dashboard，内置了一些非常强大的RESTful API，功能也是比较的全面。为啥又要自己写一个呢？在我们的环境里，有一个自己实现的类似Openstack的虚拟机管理平台。而这个平台对接Ceph RBD时，就是使用的Dashboard模块提供的API。个人觉得啊，官方的API，虽然功能全，但确实对于对接的用户来说，真的不是那么友好。这里举几个简单的点：官方API基于Token进行鉴权，而Token又通过用户名和密码进行获取，并且有一个固定的过期时间，这就会有两个选择，一个暴力点的选择是不管发送什么请求，都会获取一个新的Token，这样可以保证基于新Token的请求都可以成功；或者，每次在请求之前请求auth/check接口，确认Token的有效性，如果失效了，那就重新获取；再或者，根据请求的返回值，如果出现401错误等等情况，再重新获取新的Token。但是无论是哪种方法，都会显得冗余和逻辑复杂，特别是在多线程等等环境下，还需要考虑使用单例等等。另外，这多出来的这些Token请求，确实也拖慢了整体的效率，毕竟Python写的API，确实不算快。官方API是一个异步API，怎么理解呢？让我们先看下大部分接口的返回值，以创建RBD为例：201 Created – Resource created.202 Accepted – Operation is...