本文作者洪志国原文发布于个人技术博客。作者基于 Cube Sandbox v0.1.1 测试环境对其存储架构进行了一次深度拆解公众号经作者同意对原文做了少量适配性编辑。如果你已经在用 Cube Sandbox可能会想过几个问题◆ 我跑一个沙箱容器镜像到底放在宿主机上还是微虚机里◆ 我同时拉起 10 个一样的沙箱会不会浪费 10 倍内存去缓存同一份镜像◆ 我对沙箱里的文件做的修改最终落到了哪一块磁盘上◆ Cube 号称几十毫秒起一台沙箱这件事在存储层是怎么做到的◆ “从快照启动和从镜像启动”——名字差不多底层走的是同一套存储路径吗这些问题不影响你用Cube但会影响你信任它、调优它或者真的把它跑到生产。我自己最近想搞清楚这些就在一个 v0.1.1 的测试环境里把存储这条链路从头到尾扒了一遍。整个过程比想象中要曲折还顺手扒出了一个我觉得可能有问题的设计先卖个关子文末讲。这篇就把我看到的东西整理出来希望对你有用。◆一、先看一台沙箱启动时到底都准备了什么◆Cube Sandbox 的运行时模型是“宿主机 → 微虚机 (MVM) → 容器”这样一个三层夹心。要看清存储架构最方便的入口是微虚机的配置文件 vm.info。以一个 sandboxid 取头一段 4d656bd3...为例可以通过一条命令拿到它的完整 vm.infocurl --unix-socket /run/vc/vm/4d656bd3.../chapi \http://localhost/api/v1/vm.info | jqvm.info 里包含了这台微虚机的所有秘密——内核启动参数、虚拟块设备清单、virtiofs 挂载、网络配置等等。后面的所有分析都是从这个文件里反推出来的。另外Cube 启动一台沙箱有两种入口◆从镜像创建—— 直接拉一个 Docker 镜像跑◆从快照恢复—— 从一个预先打好的模板template恢复这两条路径在存储这一块走的不是同一条流水线。下面分开讲。◆从镜像创建四块磁盘各司其职◆从镜像创建 sandbox 的存储架构总览图2.1 一个最小化的启动请求长什么样{volumes: [{ name: rootfs-wlayer, volume_source: { empty_dir: { SizeLimit: 1Gi } } },{ name: tmp, volume_source: { empty_dir: { SizeLimit: 2Gi } } }],containers: [{name: nginx,image: { image: nginx:latest },command: [sleep], args: [1000000],volume_mounts: [{ name: rootfs-wlayer, container_path: / },{ name: tmp, container_path: /mnt1 }],resources: { cpu: 500m, mem: 512Mi },security_context: { readonly_rootfs: false }}]}注意两个 empty_dir一个挂到容器根目录 /其实是当作可写层用另一个挂到 /mnt1类似 k8s 的 emptyDir 临时卷。后面会看到它俩在虚机里其实是两块 virtio-blk 磁盘。执行 cubecli cubebox create req.json沙箱起来了。下面开始一块一块磁盘看进去。2.2 微虚机的系统盘只读的 pmem没有 page cache 开销从 vm.info 的 .config.payload.cmdline 字段可以看到root/dev/pmem0 rootflagsdax,errorsremount-ro ro rootfstypeext4这说明微虚机的根文件系统挂在/dev/pmem0上只读、启用DAX。进一步从 .config.pmem[0].file 找到这个 pmem 的真身——宿主机上的一个 raw image 文件/usr/local/services/cubetoolbox/cube-image/cube-guest-image-cpu.img可以手动 loop 挂载验证里面就是一个标准的 ext4 文件系统。这里 Cube 做了两件挺聪明的事◆用 pmem 而不是 virtio-blk—— 微虚机里的 ext4 访问数据时不走 block I/O 请求路径直接当内存读◆挂载时加 daxalways—— 微虚机内绕过 page cache避免每台沙箱都给自己复制一份系统盘缓存。如果你在一台宿主机上跑十几个沙箱这一条直接省下十几份系统盘缓存的内存开销。小结微虚机系统盘 宿主机上的一个 raw image pmem DAX 只读挂载。多沙箱共享零 page cache。2.3 容器镜像宿主机 containerd 解压 virtiofs 透传容器镜像这一块走的是相对传统的路线镜像先被 cubelet 下载到宿主机并按 containerd 的 overlayfs snapshotter 展开/data/cubelet/root/io.containerd.snapshotter.v1.overlayfs/refs/default├── f68a8bcb.../{fs,work}├── cbf2c778.../{fs,work}├── 894f3fad.../{fs,work}└── a464c54f.../{fs,work}每个子目录是镜像的一个 layer。然后 Cube 通过virtiofs把这些 layer 目录透传给微虚机——vm.info 的 .config.fs 部分里能看到 4 个 layer 全部 mount 了进来tag 统一是 cubeShared。但注意 virtiofs 的一个关键参数backendfs_config.cache 2。cache 值策略一致性 vs 性能0 (none)Guest 不缓存每次走 Host一致性最好性能最差1 (auto)元数据缓存 1sclose-to-open默认推荐2 (always)所有内容永久缓存性能最好一致性最差Cube 选了最激进的 always。这意味着镜像内容会在微虚机里产生 page cache。如果同一台宿主机上 10 个沙箱用同一个镜像会产生 10 份重复的 page cache——这个跟系统盘 pmem 的零 cache形成了一个有意思的反差。不过考虑到容器镜像在沙箱里是高频读取的、且 Cube 这里追求的是启动快这个权衡是说得通的。小结容器镜像 宿主机 containerd 解压成 layer virtiofs 透传给微虚机。性能优先会有重复 page cache。2.4 容器的可写层reflink 预热池两层启动加速这一节是 Cube 工程细节最密、也最值得拆出来讲的部分。◆2.4.1 宿主机上的空磁盘文件长什么样vm.info 里有两个 virtio-blk 磁盘vda、vdb对应宿主机上 /data/cubelet/storage/io.cubelet.internal.v1.storage/emptydir/ 目录下的两个 raw image 文件emptydir/├── 1Gi/│ ├── 0/{16ab39..., 7cdb97..., base.raw}│ └── 1/{0c8cfd..., 0ebae4..., base.raw}├── cubebox/└── othersv2/├── 0/base.raw└── 1/{4b4302..., base.raw}每个 UUID 文件就是一个微虚机 virtio-blk 设备的后端初始内容是一个空的 ext2 文件系统。1Gi 的放 1Gi/ 下其他容量的放 othersv2/。那么问题来了——沙箱启动那一刻这些空磁盘是从哪冒出来的格式化一个 ext 文件系统不是瞬间能完成的事为什么 Cube 能做到几十毫秒起一个沙箱答案是两层优化叠加reflink 预热池。◆2.4.2 第一层reflink让复制磁盘几乎不消耗磁盘空间reflinkCopy-on-Write Link是支持 CoW 的文件系统提供的高效文件克隆能力。◆ 普通 cp复制 inode 复制所有数据块时间和空间都跟原文件大小成正比◆cp --reflink只复制 inode两个文件共享底层数据块只有被修改的块才会真正复制——典型的写时复制。对 Cube 这个场景来说这等于一个 1GiB 的 base.raw 可以瞬间复制出一堆派生文件磁盘几乎不占额外空间IO 也几乎为零。但 reflink 有一个硬性前提——底层文件系统必须支持它。目前 ext 系列不支持xfs 和 btrfs 支持。所以官方建议 /data/cubelet 用 xfscubelet 启动时 plugin.go 的 checkPoolType() 会自动探测不支持 reflink 就回退到普通拷贝——能跑但启动会慢一些。如果你在生产里跑 Cube这是一个一定要确认的部署细节。◆2.4.3 第二层预热池把 reflink 也提前做好光有 reflink 还不够——cubelet 把这条优化又往前推了一步连 reflink 这一步本身都提前做掉。配置项 PoolDefaultFormatSizeList默认 [1Gi]声明了要为哪些容量做预热。以 1Gi 为例◆ 在 emptydir/1Gi/ 下预先创建0 ~ 99 共 100 个子目录◆ 每个子目录里预先生成一个 base.raw◆ 然后从这个 base.raw 通过 reflink预先克隆出一批可直接拿走的 raw 文件——这就是上面目录树里那些 UUID 文件。base.raw 本身的创建逻辑在 newExt4BaseRaw() 函数里流程是touch → truncate → mkfs.ext4 → mount → mkdir → umount这是一次性的、相对耗时的格式化 初始化目录结构。但只要做一次后续所有需要 1Gi 可写层的沙箱都能直接拎走一个。◆2.4.4 不常见容量怎么办othersv2 走即时创建路径如果请求的可写层容量经过 normalizeRootfsSizes 规整化后没有落在预热池里比如 2Gi、5Gi就会走 othersv2/ 路径。othersv2/ 也有 100 个预创建子目录、每个里面也有 base.raw但不预先 reflink。当请求来了cubelet 现场做reflink(base.raw → new.raw) → truncate → e2fsck → resize2fs—— 把基础镜像 reflink 出来再 truncate 到目标大小跑 e2fsck 修一下文件系统最后 resize2fs 把文件系统真正撑到指定容量。这条路径比预热池慢但比从零格式化还是快得多。小结Cube 把几十毫秒起一个沙箱做到的关键秘诀之一是把磁盘准备的成本拆成两层往前移——base 文件系统预先 mkfs 好常见容量的 reflink 副本也预先做好沙箱真正启动时只需要从池子里拎走一个 inode。作者注这块逻辑在后续新版本中发生了巨大变化后面有空专门再梳理一下。本文基于 v0.1.1仅作为参考。2.5 微虚机里怎么把这一堆磁盘拼成容器的根目录登进微虚机看一眼挂载bash-5.2# mount/dev/pmem0 on / type ext4 (ro,relatime,errorsremount-ro,daxalways)/dev/vda on /run/blk-cube/vda type ext4 (rw,relatime)/dev/vdb on /run/blk-cube/vdb type ext4 (rw,relatime)cubeShared on /run/cube-containers/shared/containers type virtiofs (ro,relatime)overlay2 on /run/cube-containers/b48b9c8.../rootfs type overlay(rw,lowerdir/run/cube-containers/shared/containers/{f68a8bcb..,cbf2c778..,894f3fad..,a464c54f..}/fs,upperdir/run/blk-cube/vda/disk/b48b9c8.../upper,workdir /run/blk-cube/vda/disk/b48b9c8.../work)最后那条 overlayfs 挂载就是容器真正的 rootfs。逻辑很清晰◆lowerdir virtiofs 透传进来的 4 个镜像 layer只读◆upperdir virtio-blk vda 上的子目录可写◆挂载点 /run/cube-containers/sandbox-id/rootfs这个就是容器进程看到的根目录至于 vdb对应 req.json 里那个挂到 /mnt1 的 emptyDir——通过 bind mount 暴露到容器里就行了。到这里从镜像启动的整条存储链路就串完了宿主机 raw image (pmem 只读根) 宿主机 containerd layer (virtiofs 透传) 宿主机预制空磁盘 (virtio-blk 可写层) → 微虚机 overlayfs 合并 → 容器 rootfs◆三、从快照启动另一条路径主要差在镜像怎么走◆如果你用的是 E2B 协议那 sandbox 必须从模板快照创建。这条路径跟前面主要差在容器镜像怎么从宿主机进到微虚机这一步。从快照创建 sandbox 的存储架构总览图3.1 快照里到底存了什么快照包含三部分分别落在两个目录下/usr/local/services/cubetoolbox/├── cubebox_os_image/│ └── rfs-32b1e04a.../│ ├── rfs-32b1e04a....ext4 ← 容器镜像合并视图打包成 ext4 raw image│ ├── rfs-32b1e04a....vm ← 微虚机内核二进制│ └── version└── cube-snapshot/cubebox/└── tpl-kvm-1/2C4096M/├── metadata.json└── snapshot/├── config.json├── memory-ranges ← 内存快照└── state.json ← CPU 状态注意 .ext4 文件——这是 Cube 启动加速的关键设计把容器镜像所有 layer 合并叠加之后的视图整体打包成一个 ext4 文件系统。这样从快照启动时不需要再走 containerd 的解压流程一个文件直接挂上去就能用。3.2 微虚机里看到的差异进微虚机看/dev/pmem0 on / type ext4 (ro, daxalways)/dev/pmem1 on /run/cube-containers/sandbox/pmem-cube/pmem1 type ext4 (ro, daxalways) ← 新增/dev/vda on /run/blk-cube/vda type ext4 (rw)多了一个/dev/pmem1——就是上面那个 .ext4 镜像合并视图以 pmem DAX 方式挂载。然后 overlayfs 就用 pmem1 作 lowerdirvda 作 upperdir跟从镜像启动的拼装方式一样。3.3 关键差异从 virtiofs 走到了 pmem把两种方式对照一下就一目了然了从镜像创建从快照创建宿主机上镜像形态每个 layer 一个子目录containerd 默认layer 合并后打包成一个 ext4 raw image镜像怎么进微虚机virtiofscachealwayspmem 块设备 DAX微虚机内 page cache会产生重复 page cache零 page cache 开销启动速度较慢要先解压 virtiofs 拉起快一个文件挂上去就行所以走快照这条路不仅是为了 I/O 快、内存省更是为了启动快。这也回应了为什么 E2B 协议要求sandbox 必须从模板创建——快照不只是省心它本身就是性能模型的一部分。不过对于不走 E2B 协议、直接从镜像创建沙箱的场景镜像如果也能用 pmem 方式即接入打包成 ext4这一步I/O 性能和内存开销都会更优。缺点是要多一步打包的工序。这或许是 Cube 后续可以优化的一个方向。◆四、扒着扒着我发现了一个隐患◆上面 3.1 节里我列了快照保存的目录结构仔细看的话其中少了一样东西——微虚机的系统盘镜像 cube-guest-image-cpu.img。从快照拉起一台沙箱时微虚机系统盘总是固定使用宿主机上 cubetoolbox/cube-image/cube-guest-image-cpu.img 这个文件——它没有被打包进快照。这意味着如果在 T1 时刻基于 v1 版本的 cube-guest-image-cpu.img 打了一个快照之后宿主机上的这个 image 文件被升级到了 v2那么 T2 时刻从这个快照恢复出来的沙箱微虚机系统盘已经是 v2 而不是当初打快照时的 v1 了。正常情况下guest image 是向后兼容的但如果某次升级里改了 init 流程、改了内核命令行解析逻辑或者新增了对某个内核版本的依赖——从老快照恢复出来的沙箱行为可能就和当初打快照那一刻对不上了。类似的事情对内核二进制是处理过的——.vm 文件就是为了避免快照里的内存状态和宿主机上 vmlinux 的符号表对不上而单独存的。但系统盘镜像这一份看起来还是被漏掉了。后续我会尝试给社区提一个 PR把系统盘镜像也纳入快照打包流程让从某个快照恢复真正意味着完全回到打快照那一刻的状态。如果你也在生产里跑 Cube建议先关注一下这个点避免在 guest image 升级期间踩到。◆五、写在最后◆把这条链路扒下来之后我对 Cube 的整体观感是““它在 怎么让一台沙箱又快又省又隔离’这件事上确实下了功夫。”几个让我印象深的设计点◆ 系统盘走 pmem DAX多沙箱零 cache 共享◆ 容器镜像 layer 走 virtiofs用激进 cache 换启动速度◆ 可写层用reflink 预热池两层叠加把格式化磁盘这件事彻底从启动路径上挪走◆ 快照里把 layer 合并打包成 ext4让从快照启动快到不需要再解压当然也有可以改进的地方——比如上面提到的快照里少打包了系统盘镜像比如直接从镜像启动场景下镜像还没法用 pmem 方式。这些都是开源项目自然的成长空间也是社区共建可以发力的地方。Cube 的代码我读下来风格挺清爽新人友好度还不错有兴趣的同学可以一起来看看。GitHub 仓库https://github.com/TencentCloud/CubeSandbox本文作者博客https://honkiko.github.io/p/cubesandbox-storage-analysis/ 欢迎在 GitHub issue 或 Cube Sandbox 社区群里继续交流。如果你也在扒源码、找设计点欢迎投稿。