AENV 运行时有下面这些组件：

• 控制面节点（Controller Node）：
  • Gateway 进程：二进制名 agentenv-gateway。这个是反向代理，控制面和数据面数据都要经过这里。
  • Scheduler 进程：二进制名 agentenv-scheduler。提供路由信息，比如哪一个 Sandbox 跑在哪一个上面 Runtime Node 上。
• 数据面节点（Compute Node）：
  • AgentENV Server 进程：二进制名 server；
  • uvm-ublk-daemon 进程：二进制名 uvm-ublk-daemon；
  • Firecraker 进程：一个 Sandbox 一个。

其实 AENV 当前没有强制的控制节点的概念，AENV 里的 Node 数据类型指的就是一个 Runtime Node 或者说就是计算节点。为什么没有控制节点呢，因为控制面其实是一组服务，这些服务部署在哪里是无所谓的，不需要有一个什么 bundle 强制一个物理节点上必须跑这个 bundle 的一个 replica。 因此，Gateway 和 Scheduler 这两个控制面服务可以放在不同控制节点上。

ublk 的 Userspace 这一侧的 handler 是 uvm-ublk-daemon，这是一个 systemd service aenv.service 的一个子进程。

AENV 用到哪些数据库？

可以看到控制面依赖的数据库服务并不多，一个 Redis 就够了。

数据库 / 数据服务	类型	部署位置	主要用途	是否必需
Redis	分布式 KV 数据库	控制面，供 Scheduler 使用	保存 sandboxID → Runtime Node 的路由绑定；支持 Scheduler 重启恢复、多个 Gateway/Query-only Scheduler 共享 binding	可选；不配置时使用内存存储
RocksDB	嵌入式本地 KV 数据库	每个 Runtime Node 本地	保存 paused sandbox 元数据、image cache metadata、P2P artifact catalog	按功能使用；不是独立数据库服务
OSS / S3-compatible Object Storage	对象存储数据服务	集群外部共享存储	持久化 snapshot catalog、alias、vm_state.bin、Firecracker manifest、memory/rootfs/extra-drive layers，支持跨 Runtime Node 恢复	可选；使用 posix_fs snapshot backend 时不需要

AENV Gateway

AENV Gateway 本质上是一个 k8s 的 Service。可以有多个 Replica 分散在多台机器上，只要是这个 k8s 集群内的机器就可以。

AENV Scheduler

AENV Scheduler 也是一个 k8s 的 Service。

AENV 存储

之前试过一版基于 UFFD 的存储实现，后面切换到了 OverlayBD 的格式。没有直接用阿里云的代码，而是自己实现了一套。

Guest VirtIO Driver (Frontend) -> Firecraker VirtIO Device (Backend) -> /dev/ublkbN -> uvm-ublk-daemon -> OverlayBD ImageFile。

注意 ublk 的设备和能直通的 BDF 设备是不同的，ublk 是 Linux 软件所呈现的设备概念，主要是从更上层应用层角度来看；而 BDF 才是真的物理设备。

我们来一步一步拆解：

1. VirtIO Driver 到 VirtIO Device：这一步太简单了，就是标准 VirtIO 协议的 FrontEnd 到 BackEnd 的流程，不需要解释；
2. VirtIO Device 到 /dev/ublkbN 设备：通过 offset 参数直接访问对应虚拟块设备的偏移；就像访问一个真实的块设备一样；
3. /dev/ublkbN 会转发到后面的 uvm-ublk-demon 服务，这个服务进程是处理 CoW, Diff 存储等等的核心进程；

MinIO

MinIO 是由 MinIO, Inc. 发起并开源的对象存储项目。MinIO 本体主要是一个服务端程序。它启动后监听 HTTP 端口，对外提供兼容 Amazon S3 的对象存储 API。MinIO 可以部署成多节点、多磁盘的分布式对象存储集群。

uvm-ublk-daemon 服务

AENV 网络