PlanetLab架构综述.doc

1．引言 ?????? PlanetLab根据一组设计原则[9]，在过去三年中快速地发展演进，但没有其底层架构的正式文档。本文档通过定义PlanetLab主要的架构单元而克服了这个缺陷。这是一系列共同地定义PlanetLab架构[1]版本4的文档中的第一份。后续的文档更详细地定义特定单元（和它们的接口）： ??分片和管理权威机构：接口规范[4]????? 节点管理器和分片创建服务：接口规范[6] 安全地启动PlanetLab节点：参考实现[3] PlanetFlow和审计存档：参考实现[2] 虚拟化的执行环境：参考实现 注意出了最后一个文档，这个系列在全局层次定义了PlanetLab；这并不意图作为典型用户的参考手册。也要注意，虽然对应于多种接口调用的伪代码包括在这个文档中，以用于说明目的，如上索引到规范文档应该查阅以了解权威性的定义。 我们使用两个旁条以讨论现实性的问题： 实现注释：识别出这样的方式，其中当前实现低于架构所要求的；或者识别出这样的方式，其中当前实现可能是平庸地扩展以支持一个更清晰的架构定义。 演化注释：讨论这样的方式，其中架构和实现可能在未来演化。 2．组织原则 ?????? PlanetLab围绕5个组织原则而设计，每个或来源于用户要求或来源于PlanetLab将运行的环境约束。本节明确这些要求以及它们所引发的组织原则。在这个过程中，文章引出PlanetLab之下的一些关键概念。 2.1 分布式虚拟化 ?????? PlanetLab的主要目标是提供一个全球平台，支持广域覆盖服务，这些服务从网络的多个存在点而受益。PlanetLab同时支持两个使用模型。PlanetLab用户——典型指研究人员和服务开发人员——或者运行短期的实验，或者部署持续运行的服务，该服务支持一定的客户负载。 ?????? PlanetLab通过支持分布式虚拟化而支持这个使用模型——每个服务运行于PlanetLab全球资源的一个分片中。多个分片同时运行于PlanetLab之上，其中分片作为网络范围的容器将服务相互分离开来。 2.2 非绑定的管理 ?????? PlanetLab面临一个两难问题：PlanetLab设计用来支持在广域覆盖的网络服务内的研究，而其管理平面自身是一个广泛分布的服务。在我们完全理解为了管理平台什么服务是需要的之前，必要的是部署PlanetLab并开始从网络服务中获得经验。结果是，PlanetLab必须被设计为明确支持演化。 ?????? 到此为止，PlanetLab将管理功能分解成大量独立的基础设施服务集合，每个运行于其自身的分片中，并由第三方开发，正象任何其他服务一样。我们称这种解耦合为非绑定管理。例如，一个基础设施服务也许在一组节点上创建分片；购买、出售和交易节点资源；使运行于一分片内的代码保持最新；监控分片的行为，等等。 2.3 责任链 ?????? PlanetLab利用由全世界范围内的研究组织贡献的节点。接着，这些节点代表来自其他研究组织的用户驻留服务。对接点拥有者而言是不知道个体用户的，且使问题更糟的是，他们部署的服务可能发送潜在地不连续报文到Internet。PlanetLab委员会(PLC)起到被信任中间人的作用，因此将每个拥有者从必须与每个用户协商一个驻留协议的负担中解放出来。 ?????? PlanetLab的一项重要责任是在所有相关当事人中保持责任链。即，PlanetLab必须可能地将外部可见的行为（如，一个被传输的报文）映射到负责那个报文的当事人，即用户。这个能力对于在多方间保持信任关系是必要的。注意责任链没有试图减少坏事情发生的可能性，它仅要求当出问题时，系统能够识别责任方。 2.4 非中心化控制 ?????? PlanetLab是一个全球范围的平台，构建于由许多自治组织拥有的部件。关于它们的资源如何使用，每个组织必须保留某些控制，并且在定义和管理系统中，PlanetLab作为一个整体必须给予国家和地理上的区域以尽可能多的自治。 ?????? 结果是，PlanetLab必须支持非中心化控制，这进而要求系统功能的最小化，而系统功能是要求全球协议的。如此做就允许自治组织协作以形成一个全球的设施，并为这些组织协作定义相互间的对等关系。 2.5 有效的资源共享 ?????? 虽然PlanetLab的商业变种也许具有充足的资源（和花销恢复机制）以确保每个分片能够被保证所有它所需的资源，但PlanetLab必须运行在资源不够的环境中。这意味着保守的分配策略是有问题的，并且有必要提升高效的资源共享。保证应该是可能的，但系统必须也支持“最大努力”分片和一种分片获得资源的灵活方式。 ?????? 在此上下文中，PlanetLab采用一个两头的资源分配策略。首先，它将分片创建和资源分配解耦合。这意味着当所