Paper Structure
鉴于云计算、网络系统和相关领域研究的高度经验性，测试平台在研究生态系统中发挥着重要作用。在本文中，我们介绍了这样一个设施：CloudLab，它通过提供对可编程硬件的原始访问来支持系统研究，实现大规模的研究，并为可重复的研究创建一个共享平台。
我们介绍了我们设计CloudLab的经验，并对其进行了四年的运营，为近4000名用户提供服务，他们在2250台服务器、交换机和其他数据中心设备上运行了79000多个实验。从这一经验中，我们得出了围绕两个主题的教训。第一组是关于CloudLab使用的数据分析：用户如何与它互动，他们使用它的目的，以及对设施设计和运营的影响。我们的第二组经验来自于对算法的使用方式的研究
诸如资源分配等 "内部 "使用的算法对用户体验和行为产生了重要的、有时是意想不到的影响。这些经验对一般的IaaS设施的设计者和操作者，特别是系统测试平台，以及对了解这些系统是如何建立的用户都有价值。
本文的行文结构如下
- Introduction
- Development and Use of CloudLab
- High-Level Effects of Low-Level Decisions
- Related Work
- Conclusion
Introduction
CloudLab is not Cloud
从表面上看，CloudLab就像一个云计算资源的提供者：用户要求按需配置资源，用他们选择的软件堆栈来配置，并进行实验。与云计算非常相似，测试平台简化了许多围绕资源访问的程序，包括选择硬件配置、创建自定义图像、软件安装和配置的自动化等等。云实验室的工作人员负责设施的建设、维护和运行等工作，让用户专注于他们的研究。云实验室提供了规模经济的好处，并为可重复性提供了一个共同的环境。
然而，CloudLab与云有很大不同，它的目标不仅是让用户建立应用程序，而且是整个云，从 "裸机 "开始。要做到这一点，它必须让用户不经中介地 "原始 "访问硬件。它非常重视运行完全可观察和可重复实验的能力。因此，用户不仅可以使用，而且可以看到、测量、监测和修改所有级别的调查云堆栈和应用程序，包括虚拟化、网络、存储和管理抽象。由于对低层次访问的关注，CloudLab已经能够支持在传统云中无法进行的一系列研究。
随着我们对CloudLab的运营，我们发现，"幕后 "的算法在很大程度上对设施的使用方式和用途产生了深刻的影响。云实验室运行着一些独特的、定制的服务，以支持这一愿景并保持测试平台的运行。这包括一个资源映射器、约束系统、调度器和供应器等。云计算实验室不得不在通用算法和定制算法之间做出权衡，前者可以随着系统的发展而继续良好运行，后者则可以提供更顺畅的用户体验。这些权衡的正确选择在设施的设计过程中并不明显，需要从设施的运行中获得经验才能解决。
本文的主要目的是为大型复杂设施（不仅是测试平台，还有其他IaaS类型的设施）的设计师提供CloudLab的设计选择和运营经验。
- 在第2节中，我们描述了已经建成的云计算实验室设施，并分析了其基本使用模式和在其上进行的研究。这一分析以及与之相关的数据集，代表了对社区对IaaS类型设施的实际操作的理解。
- 在第3节中，我们使用来自运营系统的数据分析了具体的设计选择，研究了设施设计中固有的一些权衡。这种分析产生了关于这些选择如何影响用户行为的重要见解，并指出了其他设施的设计原则。
Development and Use of CloudLab
The Deployed CloudLab Facility
- 硬件：主要介绍了CloudLab的部署情况。包括：硬件托管位置、介绍每个站点的大致目标（威斯康星州的硬件设计用于网络和存储工作……）、CloudLab的功能概括
- 软件：用的是专门的软件，在之上扩展。提供了什么样的能力。
- 实验：CloudLab中的实验是配置文件的实例、实验的流程
- CloudLab和典型的云之间的一个关键区别是，云强调的是弹性，因此倾向于把虚拟机的合奏作为一个协调问题。而CloudLab的配置文件则将重点放在描述一个完整的、可重复的环境上。
Hardware Overview
就是对三个CloudLab站点的列举。有几台，用的什么平台，为什么这么放（允许客户怎么怎么样）。
Usage Patterns
- 使用情况1：CloudLab的用户群是如何随着它的容量而增长的、使用的热点时间
- 铺垫：CloudLab需要优雅地处理高利用率和低利用率的时期。我们建立了一个可选的预订系统，允许用户提前安排资源。现货定价不可取，因为在学年之外做作业是不可能的。
- 使用情况2：配置文件的数量也在增长
- 我们观察到的长尾分布表明，有大量的配置文件具有相对较低和不稳定的使用，但它们的综合利用构成了大部分的用户活动。这对使用模式的分析和设计选择有着重要的意义。
Resource Availability
资源的可用性和多样性在测试平台或其他IaaS设施的采用和持续使用中起着关键作用。我们显示了CloudLab主要硬件类型的短期和长期可用性趋势。
正如我们在前面的分析中所看到的，那些在high level看起来很平稳的指标在low level显示出更多的变化性。这一点很重要，因为往往是细节影响了用户的体验：例如，对于单个用户来说，他们的实验所需的特定节点类型的可用性很重要，而不是整个测试平台的可用性。为了说明这一点，我们包括两个月度图，显示了 "slow "和 "busy "两个月之间发生的变化。例如，pc3000的曲线表明，在2018年1月，用户发现这些节点有80%的时间可供使用。与此相反，在该年4月，没有任何时候这些节点有80%的可用时间。
Research Use of CloudLab
为了了解在CloudLab上进行的研究，我们调查了2017-2018年发表的93篇论文，这些论文部分或全部使用CloudLab进行实验评估。表1按照主要贡献领域对论文进行了分类，使用的是系统和相关研究领域的清单。
在这次分析中，我们发现有两个主要的动机促使实验者来到CloudLab。
- 首先是对硬件的low levle访问
- 第二个动机是性能的可预测性和隔离性
我们从这个分析中得到的主要教训是，作为设施的运营者，我们不断地被用户对设施的使用所惊讶。如果我们一开始就把所有东西都虚拟化，然后根据需要提供对特定系统的低级访问，我们认为我们不太可能预见到这次调查中发现的所有用例。从最大化用户控制的立场出发，有助于最大化设施的使用。
High-Level Effects of Low-Level Decisions
Resource Mapping
对于将用户请求映射到物理资源的问题，存在几种方法。例如，商业云不提供对所选实例类别内的这种映射的控制；它们为有效利用而管理放置和巩固，并向用户隐藏细节。相比之下，变色龙[21]被设计为可重复实验的测试平台（类似于CloudLab，但服务于不同的研究社区），它让用户通过要求他们指定他们想在请求中使用的特定服务器的ID来进行映射。
CloudLab采取了一种独特的方法（源自为Emulab开发的算法[29]，并使用模拟退火法来解决这个NP-hard问题），它在这种映射中认识到两个方面。
- 它是一个约束满足问题，即用户的请求是一个必须满足的规范；具体来说，它类似于子图同构问题[10]，因为请求的和物理拓扑结构都是由服务器、交换机等组成的图。
- 这也是一个优化问题，因为映射必须以最大限度地提高未来映射的可能性的方式进行：它应该避免使用稀缺资源，除非是特别要求或没有可用的替代品。CloudLab将映射的结果暴露给用户，并允许他们在必要时重复使用硬件ID。
设计算法的权衡和思路
基本权衡：一个对设施几乎不做假设的通用算法（因此很容易适应新的资源）和一个更专门的算法
我们对这种权衡的反应是保留一般的算法，但开发一套启发式算法，把some of the more common failure modes变成messages that are easier for users to understand。
设计这些启发式方法的一个主要挑战是它们必须是保守的：也就是说，没有启发式方法也能成功的每一个映射必须仍然成功。
我们的经验是，最好是在映射算法周围而不是在其中建立这样的启发式算法。
小的motivation
表二记录了Distribution of recorded mapping errors。表明经常收到哪些错误，这些错误信息的汇报是否有用。
Interactive Topology Design Feedback
我们发现，在网络拓扑设计中，我们需要相当于实时语法检查的功能，而我们的答案就是CloudLab的拓扑约束系统。建立该系统的最大挑战是设计一个具有简化的映射过程模型的系统，它不产生具体的映射，而是检查这样的解决方案是否应该存在；它必须做到足够快，以便在浏览器中交互运行。
约束系统在两种情况下使用
- CloudLab的图形用户界面，为用户提供了一个 "拖放 "界面来构建配置文件。在这种情况下，它的目标是通过禁用与他们现有选择相冲突的用户界面操作来帮助新手用户，并在他们所绘制的拓扑结构不可能被实例化时向他们发出警告。
- 在第二种情况下，它被用于配置文件实例化的最后阶段，当用户选择在哪个CloudLab集群上运行他们的实验。在这里，它根据每个集群检查请求，并禁止选择任何不能实例化请求的集群。
generating and checking candidates
一些约束条件的合取范式
checking constraints quickly
现实中，实验的节点可能很多。提了几个优化点。
Impact on User Workflow
在许多情况下，IaaS类型设施的建设者面临一个选择：确保用户对以任何方式配置的任何资源集的任何请求都可以在设施上实例化，或者以某种方式限制用户的请求。
虽然前者很有吸引力，但要保证它的成本很高，并可能导致这样的情况：用户可以请求某些组合，但最好不要这样做，因为这些组合在一起的性能并不理想。
CloudLab的拓扑结构约束系统显示了后一种选择的可能路径：约束用户的请求，并在他们设计配置时给予他们早期的互动反馈。
Reserving Resources
CloudLab同时支持FCFS的使用方式和预约系统。预约不是安排在特定时间运行的实验，而是对该时间可用资源的一种保证。这使得用户可以串联运行许多实验（例如，测试不同的场景）或平行运行（例如，一个班级的每个学生一个实验）。
资源分配系统需要回答 "考虑到当前的实验和预约时间表，一个给定的行动（创建一个新的实验，扩展一个现有的实验，或创建一个新的预约）会不会违反该时间表？"
两个挑战：
- 快速
- 支持资源的后期绑定：预订系统应该在未来承诺一些资源集，但应该等到时间到来时再选择具体的资源。
Late Binding
这里利用了云的特性。
考虑到CloudLab的硬件在每种硬件类型都是同质的。只要有足够的空闲节点供所有申请者使用，所有的实验都可以继续。
因此，我们免除了预订系统在预订和特定节点之间寻找精确映射的任务，并将预订操作作为节点计数任务来实现。预订系统只是确保容量足够。
Checking Reservations Quickly
给出关于正在进行的实验的数据--节点数和它们当前的到期时间--以及批准的即将进行的预订的参数，我们的预订系统构建了一个暂定时间表，描述可用节点的数量预计将随时间变化。
实际上，这创造了一个两阶段的过程，其中预订阶段涉及的任务是轻量级和快速的，而费力的资源映射阶段则作为冗长的资源供应过程的一部分运行。
这种快速检查是由一个关键的设计决定促成的：预订是按硬件类型进行的--我们不允许对更广泛的类别进行预订，如 "任何服务器类型"。
在我们的设计中，我们可以独立地检查每种类型的时间表，因为每种类型的节点集并不重叠。
在时间表的每一点上只有一个二进制的解决方案：要么实验中的节点加上保留的节点之和超过该类型的节点总数，要么不超过。
Enforcing Reservations
CloudLab的预订系统基本上是通过 "积累 "空闲节点，直到预订开始的那一刻。
随着预订开始时间的临近，它将仔细检查两种类型的操作：创建新的实验和延长现有实验的时间。
如果这些操作中的任何一个会与预约重叠，并会导致没有足够的空闲节点来满足它，它们就会被拒绝。
Parameter Exploration
除了提交、批准和删除之外，CloudLab的预订系统还支持验证操作。验证允许用户在不提交预订的情况下探索潜在的预订，使他们能够尝试不同的时间、硬件类型和预订大小，以找到适合他们需求的配置。
如果验证成功，用户可以提交预订。
以我们的映射和约束系统为线索，验证程序在验证失败时向用户提供可操作的反馈：消息的形式是 "2018年9月21日星期五18:00:00空闲节点不足（还需要12个）"。这种反馈表明，减少节点的数量，缩短预订的时间，或将预订进一步移到未来，可以帮助用户继续提交一个有效的预订。
Size and Duration
本节是通过实验，看看预定是否成功地促成了比单独使用FCFS更大规模的实验。
Utilization
CloudLab不会在预订开始时为用户自动实例化实验，也不要求预订的结束与实验的结束相一致。因此本节考虑利用率。
我们的结论是，大多数预定的利用率很高，我们确实可以相信用户会预定他们需要的东西并使用他们预定的东西。
相比之下，我们发现有相当多的预定，123个（未在图中显示）没有确定的使用。
Reservations in Action
我们通过研究预订系统的使用与整个测试平台的使用之间的关系来结束我们对预订系统的讨论。
总的来说，我们的分析证实，预订系统构成了CloudLab的一个成功的 "社会工程 "项目，因为该系统确实以预期的方式改变了用户的行为：他们在高需求时期大量使用预订，但在不需要时，预订就会 "淡出背景"，让传统的FCFS模型占据主导地位。
Related Work / Conclusion
略