跳转至

Planetlab 串烧: 一文看懂 Planetlab 的前世今生, 以及对 Crowd-source 模式的影响

作为一个计算机网络和分布式系统领域的里程碑式平台, PlanetLab 的设计理念对后来的云计算, 边缘计算以及软件定义网络 (SDN) 都产生了深远影响

PlanetLab 目前已停止核心运营 (其"精神遗产"部分转移到了 Measurement Lab / GENI / EdgeNet), 但理解其架构对于研究大规模分布式系统, 全球范围分布式crowd-source模式至关重要

alt text

Planetlab 的诞生

PlanetLab 建立的核心愿景是 "作为一种微观世界的互联网 (Microcosm of the Internet)". 在 2002 年左右, 研究人员发现传统的网络模拟器 (如 ns) 无法真实反映互联网的复杂性, 不可靠性和异构性.

其具体目的可以细分为以下三个层面:

  • Overlay Networks 的试验场:

    • PlanetLab 旨在允许研究人员在现有的物理互联网之上, 构建和测试新的网络协议和架构 (即 Overlay Network)
    • 它允许用户"编程"网络节点, 而不仅仅是使用网络
    • 这在当时是为了打破互联网架构的"僵化" (Ossification), 让 CDN, P2P 网络, 分布式哈希表 (DHT) 等技术得以在真实环境中验证

  • Large-scale 真实服务部署:

    • 它不仅仅是为了跑"Hello World"测试, 而是为了长期运行服务. 例如, 著名的 CDN 服务 CoDeen 和分布式哈希表 OpenDHT 都是在 PlanetLab 上长期运行的
    • 它的目的是 让实验性的服务能够承载真实的流量, 从而暴露在实验室环境下无法预见的 Bug 和性能瓶颈

  • 分布式系统的 Benchmarking:

    • 提供一个 分布在全球各地的节点集合 , 让研究人员能够测量不同地理位置之间的延迟, 带宽抖动和路由路径变化.
    • 这是纯软件模拟无法做到的.
Recall: Good old days in 2002

March 2002: Larry Peterson (Princeton) and David Culler (UC Berkeley and Intel Research) organize an "underground" meeting of researchers interested in planetary-scale network services, and propose PlanetLab as a community testbed.

The meeting, hosted by Intel Research - Berkeley, draws 30 researchers from MIT, Washington, Rice, Berkeley, Princeton, Columbia, Duke, CMU, and Utah.

David Tennenhouse (Intel Research) agrees to seed-fund the project with 100 machines.

August 2002: Nearly 80 network system researchers meet at CMU the day before the SIGCOMM '02 conference to learn about PlanetLab and discuss its general architecture.

Planet 的互动模式

合作模式 / 运营模式 / 用户交互模式

PlanetLab 并非像传统的"众包" (如 RIPE Atlas) 那样由个人随意加入, 而是基于 "联盟 (Consortium)" 和 "互惠 (Reciprocity)" 的模式

合作模式: 互惠原则 (Reciprocity)

PlanetLab 的扩张依赖于一种独特的"入场券"机制, 这种机制构成了其硬件资源的众包来源:

  1. "Institutional Crowd-sourcing": 个人用户通常不能直接注册, 必须依附于一个机构 (univ or research labs)

  2. "Pay-to-Play": 一个机构想要加入 PlanetLab 联盟并获得全球 1000+ 个节点的使用权, 必须贡献自己的资源

    • 门槛: 该机构必须购买至少 2 台符合标准的服务器, 安装 PlanetLab 的专用操作系统软件, 并将其托管在自己的网络环境中 (保证公网 IP 和带宽)

    • 回报: 作为交换, 该机构的研究人员将获得在 PlanetLab 全球所有其他节点 (由其他机构提供的服务器) 上运行代码的权限

  3. 结果: 这种模式极大地降低了中心化运营的成本.

    • 普林斯顿大学研究中心 (PLC, PlanetLab Central) 不需要购买数千台服务器, 只需要维护核心管理软件, 硬件成本被"众包"分摊到了全球数百个大学手中

运营架构: 中心化管理 + 去中心化资源

PlanetLab 的架构分为两个主要部分, 体现了其管理模式:

  1. PLC (PlanetLab Central): 位于 Princeton Univ. 这是一个中心化的数据库和管理系统. 它负责:
    • 维护用户账户和认证
    • 监控全球节点的健康状态
    • 分发"切片(Slice)"凭证
  2. Nodes (节点): 分散在全球各地的物理服务器.
    • 它们运行着定制的 Linux 系统, 受 PLC 的远程管理, 但物理上由当地机构维护 (重启, 更换硬盘等)

用户交互模式: Slice-based Interaction

Planetlab 技术层面最核心的创新点 (虚拟化的早期应用)

alt text

  1. 抽象概念 - Slice: PlanetLab 的核心资源单位不是"一台服务器", 而是一个 Slice

    • 一个 Slice 代表了一组跨越全球多个节点的虚拟资源集合
    • 例如: 用户 bxhu 创建了一个 Slice princeton_bxhu_test. 他可以在这个 Slice 中通过软件命令瞬间包含位于东京, 伦敦和洛杉矶的 50 个节点

  2. 虚拟化技术 (Virtualization with Isolation):

    • 使用了 Linux VServer (一种操作系统级虚拟化, 类似于现在的 Docker/LXC 容器的前身)
    • Sliver (Slice 的一小块): 当 bxhu 的 Slice 在某个具体物理节点上运行时, 分配给他的那部分资源 (CPU, 内存, 磁盘空间) 被称为 Sliver

  3. 具体操作流程:

    • Step 1 (创建): 用户 bxhu 在 PLC 网站上申请创建一个 Slice
    • Step 2 (绑定): bxhu 通过 API 或脚本, "手动"将全球范围内感兴趣的物理节点 (Nodes) 添加到这个 Slice 中
    • Step 3 (部署): PlanetLab 会在这些"指定的"物理节点, 为用户生成独立的运行环境 (Sliver)
    • Step 4 (访问): bxhu 通过 SSH 登录到这些节点
      • 注意, 用户拥有该 Sliver 的 root 权限 (在容器内), 可安装软件, 绑定端口, 运行 Python/C++ 程序. 但这不会影响同一台物理机上其他用户的 Sliver (OS-level isolation)
安全与信任模型

  • Intra-node:

    • 沙箱机制: 虽然是共享硬件, 但通过 chroot 和命名空间隔离, 用户 A 无法看到用户 B 的进程

  • Inter-node:

    • 审计与黑名单: 由于节点 IP 属于各个大学, 如用户运行恶意代码 (如 DDoS 攻击), 该大学的网络管理员会投诉
    • PLC 拥有"Kill Switch", 可以瞬间冻结某个 Slice 在全球的运行

技术实现问题

PlanetLab 之所以成为分布式系统历史上的经典, 正是因为它在 Docker 和 Kubernetes 诞生之前的 10 年, 就为了解决大规模异构环境下的管理难题, 创造了许多当时非常前沿, 现在已成行业标准的机制.

这一部分主要记录我在逐步了解Planetlab过程中, 针对架构实现想咨询的问题. 鉴于 planetlab 本身已经关闭, 这一部分的答案来源来自 gemini / claude.

"静态"问题

  1. "用户通过 SSH 登录到这些节点": 这些隶属于同一个slice的节点同时分布在世界各地, 用户一个会话是如何同时连接到这么多个节点的?
  2. "监控全球节点的健康状态": 位于普林斯顿大学的服务中心, 是如何同时实时监测全球范围内这么多个节点?

Answer 1: 用户一个会话是如何同时连接到这么多个节点的?

身份与密钥的解耦: 在 PlanetLab 中, SSH 认证不是由单台服务器管理的, 而是由 PLC 统一分发的

  1. 公钥上传:

    • 你作为用户, 在 PLC 网站 (中心端) 注册账户, 并上传你的 SSH Public Key

  2. 密钥传播:

    • 当你创建一个 Slice (my_experiment) 并把全球 50 个节点加入这个 Slice 时, PLC 会通过后台协议 (XML-RPC) 通知这 50 个节点
    • Node Manager (NM): 每个节点上运行的守护进程 (NM) 收到指令: "为 my_experiment 这个 Slice 创建一个容器 (Sliver), 并将用户的公钥写入该容器的 ~/.ssh/authorized_keys 文件中"

  3. Namespace Mapping:

    • PlanetLab 修改了 SSH 的登录逻辑: 用户登录时使用的用户名不是 root 或 user, 而是其 Slice Name
    • 命令: ssh my_experiment@node-in-tokyo.planetlab.org
    • 节点上的 SSH Daemon 收到请求后, 会根据用户名 my_experiment, 将用户的会话, 路由 (chroot) 到对应的 VServer 容器中

Parallel Execution Tools: Parallel SSH (pssh)

用户显然不会蠢到手动开启 100 个终端窗口, PlanetLab 社区开发并推广了并行执行工具, 如上述 pssh:

  1. 用户写一个脚本或命令

  2. 用户导出一个包含该 Slice 所有节点域名的列表 (从 PLC API 获取)

  3. 使用工具: pssh -h node_list.txt -l my_experiment -P "git pull && python run_test.py"

  4. 客户端并发:

    • 对用户而言, 逻辑上是 "单次session"
    • 对底层系统而言, 实际上是用户的电脑 (或跳板机) 同时发起了 100 个 TCP 连接
    • 本质: 逻辑上是一个操作, 物理上是 100 个独立的 SSH 会话

Answer 2: PLC 如何同时实时监测全球范围内这么多个节点?

要监控分布在不可靠公网上的几千个节点, 传统的 rolling 模式是不可扩展的, 会导致中心瓶颈和网络风暴. PlanetLab 采用了 "分层监控" 和 "被动遥测" 的设计

alt text

  1. 节点主动汇报. Heartbeat

    • 方向反转: 不是中心去问节点"你活着吗?", 而是节点必须每隔几分钟向 PLC 发送一个 HTTPS 请求 (Heartbeat)
    • heartbeat pkt 内容: "我是 Node-123, 我当前负载 1.2, 状态正常, 我还在"
    • 判定死亡: 如果 PLC 在预定时间内 (例如 15 分钟) 没有收到某节点的心跳, 数据库会自动将其标记为 boot 或 offline 状态

  2. 中心化资源监测. CoMon (Co-Monitoring)

    • 这是 PlanetLab 最著名的监控子项目. 它解决的问题是: 如何在不登录节点的情况下, 知道哪个节点空闲?
    • 节点端 (Daemon):
      • 每个 PlanetLab 节点运行一个极轻量级的 HTTP 服务
      • 它在后台读取 /proc 文件系统, 生成一个包含 CPU, 内存, 带宽, 丢包率等几百个指标的摘要文件
    • 聚合端 (Aggregator):
      • CoMon 的中心服务器每 5 分钟并发抓取全球所有节点的这个摘要文件
    • 查询接口:
      • 用户可以通过 CoMon 的 Web 界面或 API 查询: "给我列出全球所有带宽剩余 > 10Mbps 且 CPU 占用 < 20% 的节点"

"动态"问题

PLC是如何根据全球范围的分布式节点进行 "实验安排" 和 "实验资源分配" 和 "实验资源调度"呢?

比如, user-a 说: "我要做一个大规模CDN实验". 解析出来他需要1000台服务器(简化起见, 不考虑server配置). 但是单个分布式节点很难有这么多server, 因此需要 node A 贡献 10, node B 贡献 50, ... 共同凑成1000台

那么在这个场景下: PLC是如何通知 "每个node"贡献多少?

这其中是否存在跨节点的资源调度? (比如: nodeB一开始贡献了50, 但后来nodeB里由于其他资源需要, 只能贡献25, 那么差额的25是否需要再找一个node接盘? 如何找?)

Answer:

TLDR: 上述假设 (Node A 贡献 10, Node B 贡献 50, 系统自动调度) 在 PlanetLab 的经典架构中是不成立的!

(1) 在 PlanetLab 的模型中, 一个 Slice 在同一个物理 Node 上, 只能拥有一个 Sliver (容器)

  • 我的假设模型 (云模型/K8s)
    • "我需要 1000 个计算单元 (Pod/VM), 请帮我调度到集群里, 不管它们在哪, 只要有资源就行"
    • Node A 资源多, 所以跑 50 个 Pod
  • PlanetLab 的模型 (地理位置模型): "我需要访问XXX这个具体的地点"
    • 如果 User-A 想要 1000 个节点, 这意味着他必须 "自行手动"找到 1000 台不同的物理机器
    • 他不能在 Node A 上开 50 个实例. 他在 Node A 上只能有一个实例 (Sliver)
  • PLC 不参与"初始化选择配置/调度", 这些是用户自己"手动指定"的
    • PLC的逻辑是: 只要你把 Node A 加入了你的 Slice, Node A 就必须为你创建一个运行环境, 与其他 50 个用户的 Slice 共享这台机器

(2) 实验安排与资源分配流程

  • Step 1: PLC 不会像 Kubernetes Scheduler 那样自动为你"安置"节点. 选择权完全在用户手中
    1. 用户行为: 使用脚本或工具 (PlanetLab Selector) 查询 PLC 数据库, "列出所有位于欧洲, 带宽大于 10Mbps, 且当前 CPU 负载低于 5.0 的在线节点"
    2. PLC 反馈: 返回一个包含 1500 个候选节点的列表
    3. 用户决策: User 的脚本从中挑选出 1000 个他最想要的节点 ID
  • Step 2: 静态绑定映射关系
    1. 用户通过 API 告诉 PLC: "把这 1000 个节点 ID 加入我的 Slice (my_cdn_slice)"
    2. PLC 仅仅是在中心数据库里更新了映射表: Slice: my_cdn_slice -> Nodes: [101, 102, ... 1100]
    3. 通知机制 (基于拉取): PLC 不主动推送指令给节点
      • 全球各地的 Node Manager (NM) 每隔几分钟会轮询 PLC: "我有新的 Slice 任务吗?"
      • 上述这 1000 个节点发现自己榜上有名, 于是各自在本地启动创建 Sliver 的流程
  • Step 3: 本地资源调度
    • Core Question: "当 1000 个节点都启动了 User-A 的 Sliver 后, User-A 能拿到多少 CPU 和带宽?"
    • Principle: 没有"绝对分配额度", 使用 "分层令牌桶" 算法
      • 如果 Node A 上只有 User-A 一个用户在跑任务, User-A 可以占用 100% 的 CPU
      • 如果 Node A 上有 10 个 Slice 都在跑死循环, User-A 只能分到 10% 的 CPU
Exception: Sirius

PlanetLab 曾有一个叫 Sirius 的服务, 允许用户"预约"某段时间的专用资源 (比如"周三下午2点我要独占 Node A 的 CPU"), 但这需要排队和审批

来源: USENIX WORLDS '05 - Using PlanetLab for Network Research: Myths, Realities, and Best Practices

"PlanetLab has two brokerage services, Sirius and Bellagio, that perform admission control to a pool of resources. Researchers can use these services to receive more than a “fair share” of the CPU, for fixed periods of time, during periods of heavy load."

来源: PlanetLab Europe Technical Overview

Page 37 of this pdf

(3) 不支持: "跨节点资源调度"与"接盘"

PlanetLab 不支持自动迁移 (Live Migration) 或自动故障转移!

原因:

  1. "网络位置" 是核心属性
    • alt text
    • 如果你在 Node A (Tsinghua Univ) 运行 CDN 节点, 目的是测试"北京用户访问的速度"
    • 如果系统发现 Node A 负载高了, 自动把你的任务迁移到了 Node B (UC Berkeley)
    • 虽然计算资源够了, 但物理位置变了, 你的 CDN 实验数据 (延迟, 路由跳数) 就完全失效了...
  2. 当年的技术限制
    • PlanetLab 上的应用通常stateful. 比如: 你的 CDN 缓存了 1GB 的数据在 Node A 的硬盘上
    • 当时(~2005/2006), Cross-WAN 实时迁移一个带状态的容器 (及其内存和硬盘数据) 极其困难, 带宽成本太高
  3. 遵循"端侧"调度原则
    • 基础设施 (PlanetLab) 只提供 "Best Effort" 的服务
    • 系统不负责"保姆式"的自动扩缩容, 用户自己负责:
      • 如果 Node A 变慢了, User-A 的代码应该检测到这一点
      • 然后由 User-A 的控制脚本决定: "Node A 太慢了, 我要放弃它; 手动去 PLC 申请把 Node C 加入我的 Slice"

Planet 的退幕与继任者

事实上, 在整理 Planet 这篇文章的过程中, 笔者整理的越是深入, 越是能直观感受到这份沉重的"历史厚重感". 😭

这种"兴衰更替"在当下(2026)依然存在体现:

alt text

(yysy, deepseek放在这里有点凑数性质...)

(1) Planet 的理念赢了，但它的实现架构被时代抛弃了

Planet 的提出/发扬, 无疑是网络测量和分布式系统研究的里程碑. 这一过程中离不开很多伟大的互联网研究人员的核心贡献. 尤其是, 笔者注意到, UC Berkeley 的 Scott Shenker 教授曾深度参与其中. 笔者曾以为他的最核心贡献是"提出SDN", 但发现并不然, PlanetLab 也是其巨著之一. 此处致敬之意更为浓烈! 🫡

这里简单整理一下这个具有划时代意义、集中体现"互联网精神"产品的"历史兴衰":

  1. 鼎盛期 (2010年前后)：

    • 此时 PlanetLab 拥有遍布全球 1000 多个地点的节点
    • 是网络测量和系统顶级会议（如 SIGCOMM, OSDI）论文实验的标配

  2. 衰退期 (2014 - 2019)：

    • 节点流失： 由于硬件老化和维护困难，大量节点显示为 Offline。原本号称 1000+ 的节点，实际可用的活跃节点逐渐降至 200-300 个
    • 联邦分裂：
      • PlanetLab Central (PLC, 普林斯顿主节点) 的维护力度下降
      • 同时，PlanetLab Europe (PLE / OneLab) 变得更加活跃，实际上接管了很多欧洲的运营，并开始尝试通过 SFA (Slice-based Federation Architecture) 寻找新出路

  3. 正式落幕 (May 2020)：

    • 2020 年 5 月，PlanetLab Central (PLC) 的核心服务正式关闭。这意味着位于普林斯顿的 PLC 全球切片的数据库和 API 停止服务 [Farewell Post: It's Been a Fun Ride]
    • 用户无法再创建新的 Slice，现有的节点也无法再从 PLC 接收指令。
    • 注意： 虽然美国的主节点关闭了，但 PlanetLab Europe 的部分基础设施至今仍在通过 OneLab 联盟以某种形式存在，并正在向下一代设施迁移

(2) "继承之战"

分成3个流派:

  1. "网络测量"的直接继承者 —— Measurement Lab (M-Lab)

    • Intro: 由 Google 主导，联合 PlanetLab 团队和学术界成立
    • Traits: M-Lab 不允许用户上传任意代码（不能创建 Slice）。它是一个专用平台，专门用于运行经过审核的网络测量工具。它的节点由 Google 等大厂维护，极其稳定
    • Access: https://www.measurementlab.net/

  2. "大规模可编程网络"的演进 —— GENI & FABRIC

    • GENI (Global Environment for Network Innovations)
      • 时代: 2010 +/-
      • Access: https://www.geni.net/
      • 更新: GENI has transitioned to FABRIC (2023年关闭)
    • FABRIC
      • 时代: 2020 +/-
      • Access: https://portal.fabric-testbed.net/
      • 地位: 目前 NSF 资助的核心测试床，可以看作是 PlanetLab 的“孙子辈”

  3. "云计算"的演进 —— CloudLab & Chameleon

    • Motivation: 针对那些觉得 "PlanetLab 虚拟化太弱 + 云计算又太黑盒, 难客制化" 的研究者
    • CloudLab. by Utah Univ.
    • Chameleon. by UChicago.