LegoOS: A Distributed Operating System for Disaggregated Hardware – Architecture and Design Overview

『看看论文』是一系列分析计算机和软件工程领域论文的文章，我们在这个系列的每一篇文章中都会阅读一篇来自 OSDI、SOSP 等顶会中的论文，这里不会事无巨细地介绍所有的细节，而是会筛选论文中的关键内容。

本文要介绍的是 2018 年 OSDI 期刊中的论文 —— LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation，它是 OSDI 2018 的最佳论文（Awarded Best Paper），实现的 LegoOS 操作系统可以将数据中心中的单体服务器拆分成通过网络连接的分散硬件，每个硬件由独立的控制器管理。

我们在集群中部署服务时经常会遇到资源碎片化的问题，因为单独的 CPU 或内存无法直接对外提供服务，需要组合成主机才能运行工作负载。为减少碎片化，云服务厂商提供多种 CPU/内存比例的主机。

图 1 - 谷歌云提供的主机类型

除了常见的 CPU 和内存资源之外，集群中的 GPU 也无法独立对外提供服务，需要将不同资源插入主板后才能被应用程序使用，物理机一旦按照特定规格组装，拆分资源就需要虚拟化等技术。

LegoOS 可以更好地解决集群中的碎片化问题，提高整体资源利用率。它把不同硬件视为标准化的乐高积木，可任意组合构建大规模主机、集群甚至数据中心，同一应用的 CPU、内存和存储资源可能来自多个网络连接的硬件。

图 2 - LegoOS

将硬件解耦自然提升资源利用率，但网络连接硬件带来两个棘手问题：网络不确定性导致需要重试和幂等性保证；网络延迟比 CPU 缓存或内存索引高 1,000×~1,000,000×。

Work

Latency

L1 cache reference

0.5 ns

Branch mispredict

5 ns

L2 cache reference

7 ns

Mutex lock/unlock

25 ns

Main memory reference

100 ns

Compress 1K bytes with Zippy

3,000 ns

Send 1K bytes over 1 Gbps network

10,000 ns

Read 4K randomly from SSD*

150,000 ns

Read 1 MB sequentially from memory

250,000 ns

Round trip within same datacenter

500,000 ns

Read 1 MB sequentially from SSD*

1,000,000 ns

Disk seek

10,000,000 ns

Read 1 MB sequentially from disk

20,000,000 ns

Send packet CA->Netherlands->CA

150,000,000 ns

表 1 - 2012 年延迟数字对比

虽然网络延迟受限于物理条件，但随着网络设备和计算资源的发展，我们可以通过更高带宽、更靠近的网卡来缓解这些问题。

本文将介绍分布式操作系统 LegoOS 的架构与设计思路，包括它如何拆分现有操作系统的模块、各模块功能以及通过网络提供服务的方式。

架构与设计

LegoOS 使用全新的操作系统架构提供资源分离功能，分离内核将操作系统分割成具有不同功能的模块，所有组件通过网络通信，例如处理器、GPU、内存以及 NVM 等硬件。

图 3 - 分离内核架构

分离内核架构包含四个关键概念：

分离操作系统（Split OS functionalities）—— 将传统 OS 功能拆分到不同的监视器（Monitor），每个处理器管理其硬件组件，监视器之间耦合松散，通过网络访问远程资源。

在硬件组件上运行监视器（Run monitors at hardware components）—— 每个非处理器组件运行独立监视器，不同控制器可使用不同实现管理持有的资源。

不一致组件之间的消息传递（Message passing across non‑coherent components）—— 依赖以太网等通用网络层进行通信，仅保证组件内部一致性，应用层自行实现全局一致性。

全局资源管理和错误处理（Global resource management and failure handling）—— 单个组件可为多个应用提供服务，失效影响多个应用，需在全局维度管理并通过冗余处理失效。

LegoOS 的核心设计思想是将 OS 功能拆分为多个模块，由全局组件负责资源管理和错误处理，不同硬件上运行不同监视器，硬件之间通过不可靠网络传递消息，开发者需在应用层实现期望的一致性。

资源管理

LegoOS 将硬件分为处理器（pComponent）、内存（mComponent）和存储（sComponent）三类，分别由 CPU、DRAM、SSD/HDD 组成。

图 4 - LegoOS 的组件

LegoOS 使用两层资源管理机制：顶层有三个全局资源管理器（GPM、GMM、GSM）运行在普通 Linux 服务器上，负责粗粒度的全局资源分配和负载均衡；底层的监视器采用特定策略管理本地资源。

图 5 - 两层资源管理机制

CPU

在每个 pComponent 中，LegoOS 使用简单的本地线程调度模型处理数据中心中的应用程序，使用少量 CPU 处理内核任务，其余 CPU 分配给应用线程。启动新进程时，使用全局策略分配 CPU，线程通常不被抢占。

图 6 - 进程管理器

进程监视器还管理 ExCache 组件，CPU 访问 ExCache 未命中时会从对应的 mComponent 读取缓存行，ExCache 实现 FIFO 与 LRU 机制保证缓存时效。

内存

mComponent 负责处理匿名内存、内存映射文件和存储缓存区，管理虚拟与物理内存的分配、释放和映射。每个进程的主 mComponent 由全局内存资源管理器（GMM）统一分配。

LegoOS 使用两层机制管理分布式虚拟内存：主 mComponent 负责粗粒度的高层分配决策，其他 mComponent 执行细粒度分配，以减少网络通信。

虚拟内存被划分为固定大小的 Virtual Region（vRegion），每个 vRegion 属于一个 mComponent，底层存储用户进程的虚拟空间信息。

图 7 - 分布式内存管理

pComponent 将内存分配请求转发给主 mComponent。

主 mComponent 根据 vRegion 可用空间选择区域分配。

若当前 mComponent 没有合适区域，向 GMM 请求新 mComponent 与 vRegion。

若目标不是主 mComponent，主 mComponent 再转发给对应的 mComponent。

目标 mComponent 分配本地虚拟内存并初始化虚拟内存空间树。

pComponent 与选中的 mComponent 通信，在其 vRegion 中申请内存。

物理内存管理相对直接，每个 mComponent 管理其持有的物理内存，并可自定义虚拟到物理的映射关系。

存储

sComponent 实现核心存储能力，通过 vNode 抽象兼容 POSIX，支持多层级文件接口，用户可在 vNode 挂载点正常存储目录和文件。

为保持文件系统简洁，sComponent 采用无状态设计，所有 I/O 请求必须携带完整信息，存储监视器使用哈希表存储文件名到文件的映射，以降低查找开销。

图 8 - 分布式存储缓冲区

存储缓冲区被放到 mComponent 中。当 pComponent 读取存储数据时，首先检查 mComponent 缓存，若未命中才调用 sComponent 接口获取并写入 mComponent 缓冲区。

总结

今天的软件与硬件与几十年前已经有天翻地覆的差别，分布式系统和复杂软件需要多样硬件支持，硬件异构导致资源管理和调度在单机上更加复杂。

作为 2018 年 OSDI 的最佳论文，LegoOS 的工作展示了网络设备的发展使得将服务器硬件资源拆散重新管理成为可能，这种分布式操作系统设计在数据中心基础设施中具有重要价值，可能会改变未来硬件的组织和管理方式。