LinuxCon+ContainerCon+CloudOpen 参会总结

在北京的国家会议中心参加了一年一度的LC3会议,LC3以前都是在北美/欧洲/日本举行,这是第一次来中国,为此Linux和Git的作者Linus也来到了LC3现场。

这次会议我主要是关注LinuxCon相关的演讲,对Container以及Cloud关注较少。
会议共持续两天,具体日程安排见LC3 schedule

存储、文件系统相关

来自Google的Theodore Ts’o分享了他针对SMR磁盘在Ext4上所做的优化,他是Ext4的maintainer。 他演讲的内容跟发表在LWN上的这篇文章内容差不多:Evolving ext4 for SMR drivesEvolving Ext4 for Shingled Disks

传统磁盘( conventional drives)有存储的物理上限,为了突破这种上限,就有了SMR, 中文名叠瓦式磁盘。这种磁盘他的离散IO较多时性能会很差,为了提升SMR随机写时的性能,Ted对Ext4做了一些改造,使得SMR的随机写性能大幅提升。这些工作主要是在JBD层来做的,有几百行的样子,然后Ext4层也稍微做了一些改动。
Ext4在SMR磁盘上之所以性能差,主要是因为Ext4的metadata在磁盘上的存储位置比较发散(the metadata is spread across the disk,这是因为Ext4的metadata是跟data存储在一起的), 而且metadata的写操作都是4K的随机写,这种行为对SMR磁盘就是致命的。(PS:这就是Ext4远不如ZFS的其中一个原因,Ext4的metadata需要写两次,一次是往journal,一次是往最终的存储位置,从journal写往最终的存储位置是就是随机写。而ZFS只需要一次写操作,因为它没有journal,是通过checksum来确保数据的integirty的。Ext4在有生之年怕是永远也追不上ZFS)
所以Ted就想到了一个办法来改善这种表现:Lazy IO,把data和metadata分开存储,然后把metadata以log的方式来管理从而变成顺序写。
这个改动在metadata-light和metadata-heavy的业务上都得到了很明显的性能提升。
Ext4的metadata存储位置比较发散是有一些历史原因的,主要是因为一开始认为随机读的代价较大,所以才把metadata跟data存储在了一起,但是在SMR磁盘上随机读远没有随机写的代价大。

在下午intel的吴峰光主持的大师训练营上,跟Ted做了一些交流,主要问了他对pagecache以及ZFS的看法。Ted的意思,pagecache的目的是OK而不是good,它是一个很通用的东西,他让很多的存储设备得到了性能提升这就可以了,如果你真的很在意pagecache,你就自己去搞个cache去(就像database做的那样)。Ted的观点其实也是现在业界公认的看法:pagecache不够好,别想着去把pagecache给做好了,去实现自己的专用cache来bypass掉它才是王道,哇哈哈,这跟Linus的看法还是有区别的。
我问题的第二个问题是关于ZFS vs EXT4的,我们知道EXT4的log在RAID4/5/6上是个硬伤,因为它没有可靠的writeback device而且log要写很多次并且比较分散,但是ZFS的writeback device就很可靠而且可以做到O(1)的复杂度来写入,所以在RAID4/5/6上不得不去关掉journal(虽然有风险,但是碰运气吧)。Ted的回答是EXT4本身并不是针对RAID来设计的一个文件系统,因为ext4 主要是是应用在大规模分布式系统中,分布式存储本身就考虑了冗余和容灾的问题,如果是用在RAID上最好还是ZFS。Ted还说,“经常有人问我会不会有未来的文件系统,我都是告诉他们不会有的,一个文件系统太重要了,因为文件系统出故障这就是数据不可靠了,跟系统crash还不一样,系统crash只要重启下就好了, 但是文件系统一出问题,别人就不敢用你了。ZFS从研究到商用用了7年时间,然后再到被大家认可又花了很长时间。EXT4也好,ZFS也好,各自有自己擅长的地方,不会有一个统一的fs来管理一切”。

附上跟Ted交流后的合照:


PS:请观察体型对比

资源隔离/资源利用率

阿里云的马涛分享了阿里巴巴在资源管理上面的一些实践(Alibaba’s Work on Resource Management in Linux Kernel), 主要是围绕CPU/内存/磁盘/网络这四大块。
他们做这个事情的背景是,阿里的很多机器资源利用率都很低(具体表现是CPU利用率低,load低),所以通过线上线下业务混布来提升资源利用率,但是线上线下业务一旦混布在一起,就难免线下业务会影响到线上业务,所以需要做一些资源隔离来更好的让线上业务不会受太大影响。
我们知道,电商线上业务很敏感(or 最敏感?)的一个指标就是RT,因为这牵涉到金钱交易,实实在在的钱,反应太慢了用户怒了直接不跟你交易了。但是只要你的RT能够控制在一定范围内,即使有增大只要不给用户带来太差的体检,就是可以接受的,这也是离线/在线混布的理论基础。离线在线混布,离线业务对在线业务多多少少都会有一些影响,这是无解的,我们要做的就是让这种影响尽量小。 这也是技术的一个前进方向:榨干硬件的所有性能,把硬件用到极致。

所谓影响少,具体到技术细节就是隔离性,隔离做的好影响就会少,隔离不彻底影响就会失控。所以做离线在线业务混布的前提就是要评估好隔离性。
阿里现在在资源的隔离性上只有CPU这一块做的较好,内存/磁盘/网络都还是在摸索中。
在CPU隔离这部分,他们现在可以做到针对CPU超线程的动态隔离。举个例子,一个socket会有很多core,一个core现在都会有两个超线程,如果在线业务跟离线业务同时跑在一个socket上,那么LLC(last level cache)上就会有争抢,所以必须要妥善处理好LLC,否则RT就可能会抖动很大。如果在线业务和离线业务同时跑在同一个core的不同超线程上,那影响就更大了,所以必须要避免这种情况,这也是可以通过技术手段来细粒度控制的,通过修改Linux的调度器来实现。intel有个做法是在线业务一个调度器,离线业务一个调度器,彼此互不干扰。
在磁盘/网络的隔离性上,他们还是在摸索中,更多的是借助tools来观察性能指标。

PS: 一朋友点评道,难道IO调度器真的是个天堑么?国内云计算企业永远也达不到Joygent的水平么。

更加轻量级的服务化方案:unikernel

来自vmware的陈铁俊分享了他在unikernel的一些实践。
虚拟化的一个趋势:先是KVM/Zen这种操作系统级的虚拟化,再是container这种资源隔离级虚拟化,再接着就是更加彻底的进程级的虚拟化方案—unikernel。

任务都是以进程为单位来执行的,(当然进程里面还有线程,还有协程),所以如果可以做到进程级别的虚拟化,不是更加轻量级么,这就是unikernel的初衷。

unikernel的特征以及优势:

  • 单进程
    unikernel里只有一个进程,进程里面可以有多线程,所以unikernel的调度非常轻量,这也使得它的启动更快,销毁更快,非常适合服务化。
    这样子也有其他一些优势:一个任务故障了不会影响到整个系统,其他的任务不会受到任何影响,你只需要重启你的任务就可以了。

  • 单一地址空间
    它的进程不存在内核态,全部都是在用户态来执行,所以也没有系统调用的开销也没有了内核空间用户空间相互拷贝的操作(zero-copy)

  • 安全性
    由于逻辑的精简它的安全性非常好

为了实现unikernel,需要在调度/网络协议栈/地址空间管理等等上面对现有的机制做很大改造,或者说,重写一个operating system。

unikernel现在已经开始商用了,而不是仅仅停留在理论研究上,华为他们搞的libOS(unikernel的一种形式)已经开始了在IoT(internet of things,物联网)上面商用。

关于系统安全漏洞(CVE): live patch

安全问题一直都是很严重的问题,对于操作系统而言,它的安全漏洞存在的一个问题是,即使我们找到了漏洞有了好的解决方案,但是也很难去部署到线上来修复这个漏洞,因为操作系统升级往往要重启整个机器这就不得不中断当前线上的任务,一旦规模大了这就很难接受。

所以针对系统级的CVE,都是通过live patch的方案来修复,即给当前正在运行的业务打热补丁,从而避免了影响当前在运行的业务。

来自Critix的Lars Kurth分享了Xen在hypervisor级别的live path方案,以及在hypervisor上如果通过DMI这个技术来解决安全问题。

当前live patch方案的比较:

technology function+data data struct inline patching
kernel live patching Y N N
kCrarft(Suse) Y N N
ksplice(Oracle) Y Y Y
Xen livepatch Y Y future

others

这次大会上还有很多关于K8s, openstack, container, IoT等等的分享,大家感兴趣的可以去LC3 schedule上去下载文档。PS:有些演讲没有把文档放上来。

Comments