devconf 19′: virtio 硬件加速

前言 devconf 也是我比较关注的一个 summit,devconf 的内容当然比较偏实践,但有一些东西还是比较前沿的。 很多人会认为 virtio 是一套实现(virtio-net, virtio-blk 等等),但实际上 virtio 是一套标准(或者说抽象层),因为 virtio 通过半虚拟化的方式来加速虚拟化的性能,那么就需要 hypervisor 和 guest 的协作来达到目的,其中 hypervisor 端我们称为 backend driver,guest 端称为 frontend driver。 virtio 的具体介绍在 developer works 有一篇很好的文章,如果对 virtio 不了解的话可以参考这篇: https://www.ibm.com/developerworks/cn/linux/l-virtio/index.html,进一步的,还可以阅读 Rusty 写的原论文:https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf 这里简单介绍一下 virtio 的基本架构,就是下面这张图: 可以看到 IO 的核心就是 virtqueue,virtqueue 定义了 add_buf、get_buf、kick 等几个关键 IO 接口。 virtio 刚提出时其实是很先进的,因为通过共享内存替代了完整的 trap/模拟过程,大大提升了性能,但是随着底层 IO 设备性能的越来越强,大家对 virtio 也逐渐提出了更高的要求,例如通过 vhost […]

Eurosys 19′ Notes:Ursa: Hybrid Block Storage for Cloud-Scale Virtual Disks

Ursa 是美团云 16 就发布过的面向 IaaS 云主机的块存储系统,目前 Ursa 主要有几篇公开文章讨论其架构: 最早:https://tech.meituan.com/2016/03/11/block-store.html 介绍了 motivation、和其他块存储的比较 17 年在知乎专栏发表了基于混合存储的效率优化,和这次 Eurosys 19′ 内容相关:https://zhuanlan.zhihu.com/p/27695512 17 年还有一篇 USENIX 17′ 的文章:https://tech.meituan.com/2017/05/19/speculative-partial-writes-erasure-coded-systems.html 介绍了对 EC 的优化 下面介绍这篇文章,原文地址:https://www.cs.jhu.edu/~huang/paper/ursa-eurosys19.pdf or https://dl.acm.org/citation.cfm?id=3303967 简介 通过追踪块存储的 IO pattern 可以发现其 IO 的 locality 很差,因此相对于使用 SSD 作为 cache layer,Ursa 选择了底层直接使用 SSD-HDD 混布方案,将主副本放在 SSD 上,备副本放在 HDD 上,通过 Journal 来弥补 SSD 和 HDD 之间的性能差距。实验显示之中模式在大部分情况下可以达到与全 SSD 相同的性能,与全 […]

使用 Clion 查看 DRBD(Kernel Module)代码

因为内核里有很多编译参数,所以需要配置下。 可以参考 http://ybin.cc/tools/clion-for-linux-driver-developer/ 我的最终配置是: … include_directories(../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/include) include_directories(../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/include/linux) include_directories(../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/mm) include_directories(../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/arch/x86/include) include_directories(../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/include/uapi) include_directories(../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/arch/x86/include/uapi) include_directories(.) include_directories(drbd) include_directories(drbd/compat) include_directories(drbd/linux) add_definitions(-imacros ../kernel-3.10.0-327.36.1.el7/linux-3.10.0-327.36.1.el7/include/linux/kconfig.h) add_definitions(-D__KERNEL__) add_definitions(-DKBUILD_MODNAME) add_definitions(-DCONFIG_BLOCK) add_definitions(-DCONFIG_HZ) add_definitions(-DMODULE) add_definitions(-std=gnu89) …

NSDI 2019 Notes

前言 NSDI 2019 里有两篇容器网络相关的话题,这篇还是比较有意思的,the morning paper 也谈到了这篇文章:https://blog.acolyer.org/2019/03/22/slim-os-kernel-support-for-a-low-overhead-container-overlay-network/。原版的视频、Slides、文章在 NSDI 官网都可以看:https://www.usenix.org/conference/nsdi19/presentation/zhuo。同时作者在 Github 上开源了实现:https://github.com/danyangz/Slim 大致思路是容器里的应用的流量送到另一个容器里的应用需要经过四次协议栈。 除了底层物理机的协议栈之外,主要是有一层 network namespace: 因此主要思路就是绕过这一层 stack,其效果还是不错的: memcached 吞吐提高 71%,延迟降低 42%,CPU 占用减少 56% Nginx CPU 占用减少 22-24% PostgreSQL CPU 占用介绍 22% Kafka CPU 占用减少 10% 介绍 容器网络往往使用 overlay 网络,但是 overlay 网络会带来显著地性能影响。测试显示 overlay 网络和 host 网络相比的吞吐会下降 23~48%,每个报文的延迟会增长 34~85%,CPU 占用会提高 93%,现有的加速技术往往是针对虚拟化的,对容器支持不够。 这里的核心问题就是一个包要在一个物理机上穿越两次协议栈,来回就是四次。这种设计显示受虚拟化的影响,因为虚拟机是有自己的协议栈的,宿主机不知道任何 Guest 的协议栈知识,但是容器不然,宿主机知道每个网络连接的完整信息。 因此作者设计了一种容器网络,核心思想就是让一个物理机上报文只经过一次协议栈。 这个设计有几个挑战: 网络虚拟化不能要求应用作出修改 […]

TLA+ 笔记

很久以前学过一些 Prolog,当时主要是为了学习人工智能和数理逻辑。TLA+ 与之有一点点像,Prolog 可以用来处理各种规划问题、一阶逻辑推理,TLA+ 可以用来设计各种分布式、异步系统,搭配 TLC(model checker) 来做验证——他们的设计目标都不是解决通用的编程问题,而是通过数理逻辑解决一些特定领域问题。 TLA+ Tools 包含很多工具,可以在这里下载,大部分人都是使用这个 Tools: http://lamport.azurewebsites.net/tla/standalone-tools.html?back-link=tools.html 在里面的链接指向的 github 地址里,有 Windows、Linux、Mac 的二进制版本,良心。 在看 TLA+ Community Meeting 2018 的时候还看到了一个形式验证语言(其实是 Python 的扩展)DistAlgo,整体思路和 Demo 看起来特别棒,就是目前各种材料和介绍还是相对少,所以我没有继续研究下去,有兴趣和时间的话,看看 DistAlgo 也挺好。 下面是笔记。 介绍 分布式系统的正确性特别难验证,所以做出了 TLA+,因为 2015 年 AWS 在 CACM 发了一篇 How Amazon Web Services Uses Formal Methods 引起了很多人注意,年底 TLA+ 作者之一的 Langworthy 和 Lamport 找微软高层推动 TLA+ […]

The design of a practical system for fault-tolerant virtual machines

这篇文章是 MIT 6.824 课程安排的一篇阅读材料。 我 Fork 了别人整理的 MIT 6.824 的课程材料,关于这篇文章的内容可以在这里找到:https://github.com/MatheMatrix/MIT-6.824-Distributed-Systems/tree/master/Lectures/LEC04 下面是笔记。 摘要 VMware 在 2010 年发布了这篇文章,主要描述它们在 vShpere 4.0 上实现的虚拟机高可用方案,这是一个商用的、企业级的方案,虚拟机性能下降在 10% 以内,虚拟机同步需要 20M 左右带宽。文章提到让这样一个系统支撑企业应用除了复制虚拟机的指令外,还有很多其他问题。 介绍 实现高可用的基本思路是主备,主备最简单的想法就是复制主的所有状态,包括 CPU、内存、IO。但是这个方案无疑需要非常大的带宽。 另一种方法是复制状态机思路,简单的说,这个思路就是把虚拟机当作一个确定状态机,两边先保持一个一致的初始状态,然后保证它们能够一样的顺序接收一样的指令。因为总有一些操作造成的结果不是确定性的,因此还需要额外的工作来保持同步(主要是内存)。 这个思路在物理机上无疑很难实现,但是在虚拟机上就好做很多,因为虚拟机就是一个定义的很完善的状态机,其所有操作、设备都是虚拟化的。但是相比物理机,虚拟机自己也有一些非确定性操作,例如读取时间和发送中断,这就是为什么我们刚才说需要额外操作来保持同步。 VMware vSphere FT 基于确定性重放(deterministic replay),但是增加了必要的额外协议和功能来保证系统功能完整。到写这篇文章时,FT 生产版本还只能支持单 CPU 虚拟机,因为对多 CPU 来说,几乎每次读写共享内存都是非确定性操作,由此带来巨大的性能损失。 这个系统的设计目标只处理 fail-stop 错误,也就是系统一旦出错则立即 stop,而且正确的服务器立刻知道它 stop 了。(分布式系统中的各种错误可以参考:http://alvaro-videla.com/2013/12/failure-modes-in-distributed-systems.html, fail-stop 几乎是最简单的错误类型) FT 设计 首先我们将备份虚拟机运行在一个和主虚拟机不同的物理机上,备份虚拟机与主虚拟机保持同步和一致但有一个很小的时间差,这时我们称这两个虚拟机处于 virtual lockstep。 两个虚拟机的虚拟磁盘位于共享存储上(例如 FC 或 iSCSI,后面会讨论非共享存储的场景),只有主虚拟机会在网络上对外通告,所以所有网络输入只会进入主 […]

Glibc 的 Bug

最近恰好碰到,查了下确实是 glibc 的 bug: https://bugzilla.redhat.com/show_bug.cgi?id=1374239 这里还给了一个在 Python 中的解决方法(work around):https://bugs.sugarlabs.org/ticket/1940

使用 Linux Bridge 搭建 VXLAN Overlay 网络

前言 使用 Linux Bridge 搭建 VXLAN 网络不是件很难的事,但是目前确实有一些小坑,这里记录一下。 本文会介绍: 如何使用 Linux Bridge 搭建一个 VXLAN Overlay 网络 如何用 Namespace 模拟虚拟机验证通信 Linux VXLAN DOVE Extension 带来的新参数 本文不会介绍: VXLAN 是什么 现代 VXLAN 协议的发展与控制平面的演化 命令 没有多大难度,直接介绍使用的命令。 iptables -D INPUT -j REJECT –reject-with icmp-host-prohibited # 在我的环境里总会有默认的两条 reject 规则,好烦,先干掉 ip link add vxlan21 type vxlan id 100 dev eth0 # 先添加 vxaln […]

写给 OpenStacker 的 ZStack 指南(一)

前言 相比 OpenStack 而言,ZStack 全异步、追求高稳定性和安全的代码是相对难读的,所以本文希望能通过一些简单的例子和与 OpenStack 的一些对比,将 ZStack 的特点、代码的原理尽量描述出来,降低 ZStack 的入门门槛。欢迎更多 OpenStacker 参与 ZStack 或从 ZStack 的代码中汲取经验。 从执行一个 API 说起 对一个业内人士,观察在页面上一个指令如何逐步被执行,无疑是最直观深入的了解方式。 第一步 前端 打开 Mevoco/ZStack 的界面,可以发现基本设计思路与其他 IaaS 或 OpenStack 是基本类似的,然而打开开发者面板就会发现大有不同。 OpenStack 的面板一般通过 HTTP 到 Web 后端,可能是一个像 Horizon 的中间件,也可能是直接把请求发到后面的具体服务的 API 服务,例如 nova-api 或 neutron-server。当然中间可能还会有负载均衡器或高可用之类的设施。 图1 在OpenStack的Horizon面板上创建虚拟机出发的Post请求 而在 ZStack 的面板中开发者面板是很干净的,打开之后无论什么操作是不会触发 HTTP 请求的,数据和请求都在 WebSocket 传递,比如我们在面板上创建一个虚拟机,可以看到通过 WebSocket 发送一个 frame,一个 […]

为什么在 VyOS(Vyatta)中 commit 会很慢

最近就这个问题调查了蛮久,其实原因比较显然,在看到 strace 的结果就已经明白了大半,但是本着求(xia)知(zhe)探(teng)索的想法,仔细验证了代码逻辑和时间(新技能 get!给 C++、Perl 混合代码调试性能),攒出了这篇文章。 ZStack 是一个开源的 IaaS 软件,架构和性能都很优秀,可以在 103 秒内并发创建 1000 台虚拟机,可惜这个数据是在扁平网络下测试得到的,一旦用上云路由网络,单个虚拟机的启动时间会延长到七秒左右。 我们现看下看下实际的占用时间,我在 vyatta 的代码里添加了日志(Repo 是 https://github.com/vyos/vyatta-cfg )综合 zstack、zstack-vyos、vyos 的日志可以看到大概是这样的(注意 zstack 的日志时间精度只提供到秒,没有毫秒): 2017-02-13 13:22:08 start executing flow[NetworkServiceManagerImpl.java:apply-network-service-DHCP] 2017-02-13 13:22:08 DEBUG [RECV] /setsnat 2017-02-13 13:22:09 DEBUG [HTTP POST][ASYNC REPLY TO /setsnat] 2017-02-13 13:22:09 DEBUG [RECV] /adddhcp # 以下为 vyos 日志 2017-02-13 13:22:09:458 Entered cli_bin::doCommit […]