Technically, KVM-based VM is a special type of virtual machine which relies on physical machine features. Following lists some popular VM types that do not use KVM. Hope you also find it interesting. VM Name Translation Technologies Executable Format Runtime Dalvik VM (Register based VM) Interpretation Android (<2.2, 2008) Dalvik VM JIT + Interpretation (Just […]
What is a “Container Runtime” ? As already explained in a previous blog (容器生态技术栈 – JciX ~), container runtimes are the components that will take the responsibility to run the container. They will be invoked by container engines (like containerd, and CRI-O), and will create the containers using Linux kernel primitives (like cgroups, and namespaces). […]
In the Linux world, there are many interprocess communication (IPC) methods available for system programmers. After some web searching, I found that there are rarely blogs or books that summarize them all. This article roughly lists them all with minimal explanation and some links to official manuals. POSIX IPCs POSIX-flavor IPCs include semaphores, shared memory, […]
本文概述 HotCloud ’18 中的一篇讲云原生文件系统的论文，来回顾下存储领域大佬 Arpaci-Dusseau 在 6 年前对云原生文件系统的想法。论文链接 hotcloud18-paper-arpaci-dusseau.pdf (usenix.org) 文章的贡献主要有两点： 提出一些云原生文件系统所应该遵循的设计原则； 提出一种云原生文件系统 CNFS 的大概设计。 云原生文件系统的设计原则 作者把设计的原则分为存储和计算两个层次，但总体来讲都聚焦于成本和性能的权衡。这种权衡是云环境相对传统环境更容易做到的，也是云原生文件系统设计的核心。 存储原则 可靠性已经通过更底层的云存储服务得到保障。云存储比如对象存储 S3 或者块存储 EBS，已经提供了多副本等可靠性功能，因此云原生文件系统可以把这部分功能卸载到更底层的云存储。 云存储空间便宜且可以无限扩展。云原生文件系统的设计应该尽量利用这些便宜的存储空间对数据建立索引，用空间换时间。 云存储与本地存储有很大差异：带宽通常较高；延迟根据服务分级不同差异明显；更快分级的云存储访问成本反而更低。因此云原生文件系统应该按冷热层次化地放置数据，来兼顾成本和高性能。 CPU 原则 云上 A 个 CPU 计算 B 秒和 B 个 CPU 计算 A 秒（A * B = B * A）的成本相同。因此，云原生文件系统的计算任务应该尽量并行起来，这样可以在尽可能短的时间内完成任务。 类似于云存储的空间，云上的 CPU 数量也很容易扩展。云原生文件系统应该按需地使用 CPU，但也需要注意根据负载的变化对之前扩容的 CPU 数进行缩容，来控制成本。 由于云存储可以在计算节点间共享，可以适当的将与文件系统相关后台任务从计算节点分离出来，让计算节点的 CPU 资源更多地用于计算任务。 云服务中 […]
MinIO 是一个用 Golang 编写的对象存储 server 开源实现。s3fs 是一个基于 FUSE 框架的以 s3 存储服务作为后端并导出 POSIX 文件系统挂载的开源实现。 本文首先基于 MinIO 搭建一个简单的对象存储服务。然后进一步借助 s3fs 将这个对象存储服务挂载为一个文件系统目录。 搭建 MinIO 对象存储 安装 Minio go install github.com/minio/minio@latest 启动 mkdir minio_dir minio server minio_dir CLI 操作 curl https://dl.min.io/client/mc/release/linux-amd64/mc \ –create-dirs \ -o $HOME/minio-binaries/mc chmod +x $HOME/minio-binaries/mc export PATH=$PATH:$HOME/minio-binaries/ # 设置 alias，之后就可以将 myminio 作为第一级目录操作了 mc alias set myminio […]
本文以我的视角对 ublk 进行了最基本的分析，希望也为你带来帮助。 ublk ublk 是一个 6.X 内核全新的实现用户态块设备驱动的内核框架，之前的类似框架还有 TCMU、vdpa-user (VDUSE) 和 NBD。ublk 框架中，一个额外的 ublk Server 用户态进程作为 ublk 块设备的服务后端，实现了主要的存储逻辑。区别于其他用户态块设备框架，ublk 采用 io_uring 作为内核与用户态通信的传输机制。ublk 架构图如下： 使用 ublk 框架，内核会多出几种设备，包括一个唯一的 ublk_ctl 设备，多个名为 /dev/ublkcN 的字符设备，以及同样数量的 /dev/ublkbN 块设备。其中， 块设备是实际的存储服务设备，可以格式化文件系统或者作为裸设备使用，这也是 ublk 存在的最终目的； 字符设备是 ublk 框架的数据面接口，主要被用户态 ublk Server 进程用于与内核通信，处理块设备的实际 IO 请求； ublk_ctl 设备(/dev/ublk-control)则可以看作的是 ublk 框架的控制面通道，ublk Server 通过请求 ublk_ctl 设备来创建出多对字符设备和块设备， 类似于其他用户态驱动框架，ublk 为了方便用户态 ublk-server 的开发，也提供了用户态 SDK […]
汇总一些容易混淆的容器领域技术概念，希望对你有所帮助。 技术栈架构 生态对比 Ecosystem Orchestration Service Orchestration Agent Container Engine ContainerRuntime CLItools OCI / CNCF k8s kubelet containerd(CRI runtimes) runc / kata(OCI runtimes) ctr,crictl Docker docker swarm dockerd(docker CLI) containerd runc docker LXD /Canonical clusterd lxd lxd lxd lxc lxc OpenShift / Redhat k8s kubelet CRI-O runc podman 当然，这里列出的只是各个生态的默认技术栈，开源社区中还有各种项目让不同生态的组件互相组合协同工作。比如：Mirantis/cri-dockerd: dockerd as a compliant Container Runtime […]