跳转至

ProtoGENI: Designing a Federated Testbed as a Distributed System

这篇太形而上学了, 主要讨论的是联邦 Testbed 的设计原则和架构理念, 并没有具体的系统实现细节.

"爹味"十足, 拿AI扫一遍吧...

背景与动机 (Background & Motivation)

  • 传统局限性:
    • 传统的网络与系统研究测试床通常是独立的设施 (stand-alone facilities), 每个设施由单一实体管理, 且彼此隔离
    • 这种孤立模式无法满足研究人员对更大规模实验和更多样化网络技术日益增长的需求
  • 联邦模型 (Federated Model): 论文提倡一种联邦模型, 其中每个联邦成员保持自治和独特的优势, 但共同在一个通用框架下提供资源
  • 设计挑战: 核心挑战在于设计一个既能建立信任又能保持设施自治的框架
    • 既能提供统一接口又能暴露资源多样性
    • 既能协调工作又能避免单点故障
  • 核心论点: 作者认为应该将测试床设计视为一个 联邦分布式系统问题 (federated distributed systems problem)

五大设计原则 (Design Principles)

ProtoGENI 的设计遵循以下五项原则, 以满足联邦测试床的需求:

  1. 分区信任 (Partitioned Trust): 每个联邦成员负责自己的资源和用户, 仅在涉及对方资源和用户时才信任其他成员. 每个成员保留制定本地授权和策略的权利, 没有任何测试床在联邦中占据特权地位.
  2. 分布式知识 (Distributed Knowledge): 没有单一实体拥有系统的完整知识. 这允许本地扩展 (local extensions), 使成员能够提供独特的资源和新功能, 而不受全局框架的限制.
  3. 最小抽象 (Minimal Abstraction): ProtoGENI 框架提供访问资源的低级 API, 而不是将资源细节隐藏在高级抽象之后. 这给了用户工具开发者定义适合特定用户群体的更高级抽象的灵活性.
  4. 去中心化架构 (Decentralized Architecture): ProtoGENI 只有一个中心化实体 (Clearinghouse), 仅用于引导和便利. 系统中不存在全局锁, 而是利用本地事务 (local transactions) 来协调跨联邦的操作.
  5. 最小依赖 (Minimal Dependencies): 每个 ProtoGENI 调用都尽可能携带完整的上下文. 这最小化了服务间的依赖, 使它们不需要在线联系其他服务即可正确运行.

架构组件 (Architecture)

ProtoGENI 基于 GENI 的 "基于切片的联邦架构" (Slice-based Federation Architecture, SFA) 构建.

  • 基本概念:
    • Slice (切片): 物理设施的分区容器, 用于运行实验.
    • Sliver: 用户在特定组件 (Component) 上分配到的资源集合 (如虚拟机, VLAN).
    • URN: 系统中的主体和对象通过分层的 URN 唯一命名.
  • 主要实体:
    • Aggregate Managers (AMs): 负责管理资源 (组件), 处理资源分配和授权.
    • Slice Authorities (SAs): 负责创建切片名称并授予用户操作这些切片的凭证. SA 对其用户在切片内的行为负责.
    • Clearinghouse (CH): 唯一的中心化服务, 用于发布证书以建立信任, 以及发现其他联邦成员. CH 的信息更新不频繁, 可以被缓存.

实验流程与生命周期 (Workflow & Lifecycle)

alt text

4.1 运行实验的步骤:

  1. 创建切片 (Creating a Slice): 用户联系 SA 获取切片名称和凭证.
  2. 发现资源 (Discovering Resources): 用户通过 CH 获取 AM 列表, 并向各 AM 请求资源广告 (advertisement).
  3. 创建 Slivers (Creating Slivers): 用户选择组件并发送请求给 AM, AM 返回 "Ticket" (票据). 用户随后 "兑换" (redeem) 票据以创建 Sliver.
  4. 使用资源 (Using Resources): 用户登录 Sliver 运行实验.

4.2 状态管理与事务

  • Sliver 状态机: Sliver 的生命周期包含四种状态: Null, Ticket (持有票据但未实例化), Sliver (已实例化但无票据), Sliver and Ticket.
  • 三步分配过程:
    1. 获取资源列表.
    2. 请求新 Ticket (获取资源保证, 但不实例化).
    3. 兑换 Ticket (提交资源变更).
  • 乐观并发控制: 由于没有全局锁, 系统采用乐观并发控制. 如果步骤 2 失败, 用户可以选择只兑换成功的票据, 放弃票据, 或尝试从其他 AM 获取替代资源.

资源规范 (Resource Specification - RSpec)

ProtoGENI 开发了一种基于 XML 的描述语言 RSpec.

  • 渐进式注释 (Progressive Annotation): 操作接受一个资源规范作为输入, 并输出带有附加信息的同一规范. 这一机制支持了 "分布式知识" 模型.
  • 三种变体:
    1. Advertisements (广告): AM 描述其可用资源.
    2. Requests (请求): 客户端描述其所需的资源 (绑定或未绑定的).
    3. Manifests (清单): AM 在 Sliver 创建后返回的详细信息 (如主机名, IP 等).
  • 可扩展性: RSpec 允许通过 XML 命名空间插入扩展, 不支持的扩展会被安全忽略.

系统评估与经验 (Experiences & Evaluation)

  • 部署规模: 此时联邦包含 16 个 AM, 超过 300 名用户创建了 3000 多个切片.
  • 设计教训:
    • 生命周期困惑: 用户常对 Slice 和 Sliver 的生命周期感到困惑 (Sliver 不能比 Slice 活得长, Slice 未过期前名字不能重用).
    • 标识符: 最初使用 UUID, 后改为包含授权机构信息的 URN, 以减少对查找服务的依赖.
  • 性能测试:
    • Sliver 创建时间随节点数量增加而增加.
    • 涉及的 AM 数量越多, 分配时间越长.
    • 缓存信息 (如 AM 列表, 凭证) 平均可减少 17 秒的创建时间.
  • 故障容忍:
    • 由于上下文传递和缓存机制, 即使 CH 或 SA 发生故障/断连, 用户仍可执行部分操作 (如在已知 AM 上操作现有 Slice).
    • 表格 1 详细列出了在 CH, SA 或 AM 故障时各项操作的可行性.