PlanetLab架构综述.doc

1・引言PlanetLab根据一组设计原则［9］,在过去三年中快速地发展演进，但没有其 底层架构的止式文档本文档通过定义PlanetLab主要的架构单元而克服了这个缺陷这是 一系列共同地定义PlanetLab架构［1］版本4的文档中的第一份后续的文档更详细地定义 特定单元（和它们的接口）：分片和管理权威机构：接口规范［4］节点管理器和分片创建服务：接口规范［6］安全地启动PlanetLab节点:参考实现［3］PlanetFlow和审计存档：参考实现［2］煨拟化的执行环境：参考实现注意出了最后一个文档，这个系列在全局层次定义了 PWnctLdb；这并不意图作为典型用户 的参考手册也要注意，虽然对应于多种接口调用的伪代码包括在这个文档中，以用于说明 目的，如上索引到规范文档应该查阅以了解权威性的定义我们使用两个旁条以讨论现实性的问题：实现注释：识別出这样的方式，其中当前实现低于架构所要求的；或者识別出这样的方式, 其中当前实现可能是平庸地扩展以支持一个更清晰的架构定义演化注释：讨论这样的方式，其中架构和实现可能在未来演化2.组织原则PlanetLab围绕5个组织原则而设计，每个或来源于用户要求或来源于PlanetLab将运行的环境约束。

本节明确这些要求以及它们所引发的组织原则在这个过程 中，文章引出PlanetLab之下的一些关键概念2. 1分布式虚拟化PlanetLab的主要目标是提供一个全球平台，支持广域覆盖服务，这些服务 从网络的多个存在点而受益PlanetLab同时支持两个使用模型PlanetLab W7——典型 指研究人员和服务开发人员一一或者运行短期的实验，或者部署持续运行的服务，该服务支 持一定的客户负载PlanetLab通过支持分布式虚拟化而支持这个使用模型一一每个服务运行于 PlanetLab全球资源的一个分片多个分片同时运行于PlaiietLab之上，其中分片作为网 络范I韦I的容器将服务相互分离开来2. 2非绑定的管理PlanetLab面临一个两难问题:PlanetLab设计用来支持在广域覆盖的网络服 务内的研究，而其管理平而自身是一个广泛分布的服务在我们完全理解为了管理平台什么 服务是需要的之前，必要的是部署PlanetLab并开始从网络服务中获得经验结果是， PlanetLab必须被设计为明确支持演化到此为止，PlanetLab将管理功能分解成大量独立的基础设施服务集合，每 个运行于其自身的分片中，并由第三方开发，正象任何其他服务一样。

我们称这种解耦合为 非绑定管理例如，一个基础设施服务也许在一组节点上创建分片；购买、出售和交易节点 资源；使运行于一分片内的代码保持最新；监控分片的行为，等等2. 3责任链PlanetLab利用由全世界范围内的研究组织贡献的节点接着，这些节点代 表來自其他研究组织的用户驻留服务对接点拥有者而言是不知道个体用户的，且使问题更 糟的是，他们部署的服务可能发送潜在地不连续报文到Interneto PlanetLab委员会(PLC) 起到被信任中间人的作用，因此将每个拥有者从必须与每个用户协商一个驻留协议的负担中 解放出来PlanetLab的一项重要责任是在所有相关当事人中保持责任链即，PlanetLab必须可能地将外部可见的行为（如，一个被传输的报文）映射到负责那个报文的 当事人，即用户这个能力对于在多方间保持信任关系是必要的注意责任链没有试图减少 坏事情发生的可能性，它仅要求当出问题时，系统能够识别责任方2.4非中心化控制PlanetLab是一个全球范围的平台，构建于由许多自治组织拥有的部件关 于它们的资源如何使用，每个组织必须保留某些控制，并且在定义和管理系统中，PlanetLab 作为一个整体必须给子国家和地理上的区域以尽可能多的自治。

结果是，PlanetLab必须支持非中心化控制，这进而要求系统功能的最小化, 而系统功能是要求全球协议的如此做就允许自治组织协作以形成一个全球的设施，并为这 些组织协作定义相互间的对等关系2. 5有效的资源共享虽然PlanetLab的商业变种也许具有充足的资源（和花销恢复机制）以确保 每个分片能够被保证所有它所需的资源，但PlanetLab必须运行在资源不够的环境中这意 味着保守的分配策略是有问题的，并只有必要提升高效的资源共享保证应该是可能的，但 系统必须也支持“最大努力”分片和一种分片获得资源的灵活方式在此上下文中，PlanetLab采用一个两头的资源分配策略首先，它将分片 创建和资源分配解耦合这意味着当所有分片首次创建时，它们仅给定最大努力的承诺之 后随时间变化它们获得并释放资源，由可用的代理服务协助执行在分片的整个生命周期中, 它绑定到一组可确保资源的集合，这不是事实第二，甚至一些分片在一段时间内能够获得 确保的资源，就规范而言，我们预期这超额预订了PlanetLab必须提供由于严重资源使用 而造成的系统抖动中恢复的机制3责任人和信任关系PlanetLab架构识别三种主要责任人:1 一个掰歹普是一个组织，它驻留（拥有）一个或多个PlanetLab节点。

每个拥有者保留对它们自己节点的最后控制，但将管理那些节点的责任委托给被信任的PLC 中间人PLC提供机制，其中允许拥有者对它们的节点定义资源分配策略1 一个用戶是在一组PlsnetLdb节点上部署一个服务的硏究人员PlanetLab用户目前局限在由研究组织（例如大学、非盈利和公司研究实验室）雇佣的人员， 但这不是架构上的耍求用户使用由被信任的PLC中间人提供的机制在PlanetLab节点上创 建分片1 PlanetLab委员会（PLC）是一个被信任的中间人，它代表一组拥有者管理节点，并代表一组用户在那些节点上创建分片图1在责任人间的信任关系图1描画出节点拥有者、用户和PLC中间人间的信任关系在图中：1. PLC通过向用户分发证书而表示出对用户的信任，该证书让用户访问分片这意味着 用户必须向PLC充分地证明其身份（例如，加入某个组织或团体）2. 一个用户相信PLC作为其代理，代表它创建分片并检查证书，以保证只有那个用户能 够安装并修改运行在其分片中的软件3. 一个拥有者相信PLC安装软件，软件能够将网络活动映射到所负责的分片这个软件 也必须分隔分片的资源使用并约束/限制分片行为4. PLC相信拥有者能保证它们的节点物理上是安全的。

不欺骗PLC是拥有者最好的选择 （拥有者依靠PLC 了解其节点的准确监控）PLC也必须验证它管理的每个节点实际上属于一个拥有者，PLC和这个拥有者有协议虽然初始情况下PLC是PlanetLab中仅有的被新人中间人,迅速成为问题的是其他实体（如, 国家和地区中心、私有内网）期望扮演类似PLC的角色这意味着PlanetLab .IF迅速地成为 这些系统的联合体虽然这个转换到联合体的过程仍在进行之中，并一且我们不能准确地预测 它最后的形式，但我们能够从确定PLC扮演的不同角色入手，并明确地在体系架构中将它们 解耦合图2责任人间的信任关系特别地，PLC扮演两个角色：它代表拥有者管理一组节点，并代表用户创建分片因此，PLC 既是一个管理权威,又是一个分片权威 d 明确地将这两个角色解耦允许新的象 PLC之实体独立地发展这两个单元图2显示PLC分割成这两个权威这个分割在拥有者和 用户间的信任关系链中添加了条新连接5. 为了支持审计，每个管理权威（进而间接地，管理权威所代表的拥有者）相信分片权 威可靠地将分片映射到用户如果一个管理权威不能解决问题，一个拥有者可以选择一个不 同的管理权威，或旁路它的管理权威而配置其节点，以将某些分片或分片权威列入黑名单。

6. 每个分片权威（进而间接地，分片权威所代表的用户厂nJ以仅信任某些管理权威作如 下工作：（a）向它提供可工作的V*和（b）不要错误地控告用户的超限行为就避免节 点被无赖的管理权威而言，一个用户总是自由的从架构性的观点来看，信任关系的关键特征是延伸于责任人Z间的成对信任关系链换句话 说，在拥有者和用户之间不需要信任依赖当然，分片和管理权威仅是代理，且拥有者和用 户总是自由地旁路它们的代理权威，并形成直接的信任关系（例如，一个节点拥有者能够将 分片列入黑名单）但是，如果权威正在尽其职资，这样做就应该不是必要的第二个特征 是在管理和分片权威之间没有固有的依赖关系它们是相互独立的，自由地发展演化当系统发展演化时，这种解耦合提供了一个重要的自由度例如，多个自治区域能够运行它 们自己的管理权威，而单个全球分片权威授予服务开发人员跨越管理边界的节点访问这分 布了节点管理问题而没有分割分片类似地，能够有多个分片权威，它们可以与管理域耦合, 或不能与管理域耦合例如，可能保留单个“研究”分片权威，对应于今天的PLC,还有一 个“公共良好”分片权威，它仅授权那些提供网络报告或SET I HOME风格服务的开发人员， 还有一个“商业的”分片权威，它代表为盈利而提供的服务。

也可能有私有的分片权威，允 许用户在一个站点访问站点特定的资源，这些资源不对外开放一定意义上，一个分片权威 类似于一个虚拟组织［1］4架构的组件本节描述架构的单元，它们合在一起定义了 PlanetLabo这些单元由两个主 要成分组成：（1） 一组软件模块，运行于每个节点上，和（2）执行PLC的全球机制之集合4.1节点一个节点是一台能够驻留一个或多个虚拟机器（VM）的机器一个节点必须 具有至少一个非共享（不是NAT方式的）1P地址每个节点由一唯一 node_id标识，该标 识绑定到节点的一组属性；例如，驻留站点（由一网络前缀表示）、节点的当前1P地址、 节点的MAC地址等等除了站点的网络前缀之外，这些属性允许随时间而改变这有效地允 许实现节点的硬件能被替换，或者增量式的或整体的，但一个节点（和其node_id）不能从 一个站点移植到另一个站点并不要求一个节点的IP地址是全球可路由的，但对来自PLC组件运行的站点 内之所有节点必须是可达的（见4. 7和4.8节）实现注释：今天，一个节点的IP地址必须是经台地指定的，虽然它能够由DIICP 提供这个限制好像不是本质上的，并可能在最近的将来被去除。

在节点和物理机器之间经常存在一对一映射，但这不是一个要求（注：即不 必须是一对一）对一个节点可能在一个虚拟机器内实现，甚至也许从一台物理机器迁移到 另一台物理机器的节点，后一种情形可能是一个簇内的情形但是，在这样一种情况中，一 个非共享的IP地址必须指定到节点作为一个实际问题而言，修改指定给一个节点的IP 地址期望是一个不频繁的操作不要求所有节点是相同的机器架构，虽然目前的实现限于 x86处理器架构假定有一种方式，通过它PLC能够远程启动一个节点较好的实现是在 机器上的重启能力（如，HP的Lights-Out产品）,虽然其它实现是可能的机制也应该支 持控制台记录 （console logging）一个节点以永久的、写保护的、存储的状态方式提供三块：一个bootfile、 一个名字为plnode, txe的网络配置文件和PLC的一个公钥信息的所有三块内容是通过一 个离线进程而由节点拥有者和PLC的参与创建的，并由拥有者安装在节点中Bootfile是一个可执行映象，当节点启动时这是节点配置运行的这个程序 使节点与PLC交互以下载所有必要的软件模块(见4. 8节)Plnode, txt是节点特定的文 本文件，从bootfile启动的执行程序读取它＜=它给出节点的各种属性，包括节点的node_ids DNS名字和IP地址，还有由PLC产生并指定给节点的一个唯一。