AchievingCost-efficient, Data-intensive Computing in the Cloud
Abstract
云计算提供商最近开始提供高性能虚拟化闪存存储和虚拟化网络I / O功能，这些功能有可能增加应用性能。由于用户只支付他们使用的资源部分，因此这些新资源是有降低总体成本的潜力。然而实现低成本需要选择正确的资源组合，这种唯一可能性，是只要他们的性能和伸缩行为是已知的。
在本文中，我们将对最近推出的虚拟化存储和网络I / O进行亚马逊网络服务（AWS）系统测量。我们的经验表明依赖于这些新功能的集群中存在扩展限制特征。一个结果就是，大规模集群进行配置与小规模部署是大不相同。我们描述规模部署的观察对于实现大规模云部署效率的影响。为了确认我们的方法的价值，我们部署使用经济高效，高性能分类的100 TB的作为大规模评估。
类别和主题描述符C.4 [系统]：测量技术
一般条款 性能，测量
关键词 云，I / O性能
1. Introduction
云提供商如亚马逊网络服务（AWS）[3]，Google CloudPlatform [9]和Microsoft Azure [4]提供几乎即时访问可配置的计算和存储资源，这类资源可根据应用需求进行增长和reduce，使其成为支持大规模数据处理任务的理想选择。然而，支持现代互联网站点的需求不仅需要原始的可扩展性，而且还需要经济成本和资源效率的运作：这是为了至关重要的最大限度的减少完成特定工作量所需的资源预算，或者反过来最大化数量给定特定的资源预算可能的工作。
最小化云成本需要选择组合根据给定的应用程序和工作量量身定制的资源。对云资源的性能进行了多次测量研究[17,20,32]，并进行了一些旨在自动选择适合给定工作负载的云资源配置[14,15,34]的努力。这不是简单的任务，而是因为在过去的五年中快速发展中，公共云平台的多样性已经成为一件容易的事情。例如，截至撰写本文时，亚马逊提供了53种不同类型的虚拟机，数量不同的虚拟CPU核心，数量不同的内存，本地存储设备的类型和数量，GPU处理器的可用性以及可用带宽到集群中的其他VM。上述提供工具已经显示出了公共云平台多样性的可能实现希望，特别是对于这类的作为CPU时间和内存空间，可以在位于同一个虚拟机管理程序上的租户虚拟机之间进行精确划分的资源。另一方面，共享资源，如网络带宽和存储，已被证明是一个更大的挑战[10,33]。
虚拟化I / O方面的最新进展，如SR-IOV[28]，通过允许虚拟化快速访问固态硬盘和高速网络，是有可能提高运作效率的。由于用户只支付他们使用的资源，更高的效率导致更低的成本。但是，选择在这种环境下，正确的资源集合比以前因为空间配置实现更加困难了。此外，随着集群的大小增加，整体集群利用率和效率可能下降，要求更多虚拟机可以满足性能目标又提高整体成本[7]。 因此在任何大型部署中为了实现成本效益，理解伸缩行为的虚拟化云网络和存储资源是关键点。
在本文中，我们描述了一个AWS公共云中系统度量，针对最近推出的虚拟化网络和存储资源的伸缩属性。我们的目标是确定用于为数据密集型应用程序配置群集的最佳价格点，具体来说I / O绑定的应用程序。 作为一个案例研究，I /O绑定数据处理应用程序在各种效率和数据持久性假设下，我们部署了Themis [22]，我们在内部实现MapReduce。我们使用从中得到的工作，对我们的方法进行大规模的年度100TB数据量的“GraySort”分类比赛[27] 的评估。
我们发现，尽管新引入了I / O虚拟化功能，AWS群集仍然具有可扩展性限制，导致更大的集群规模比由少量节点的集群性能预计的更大。我们进一步发现在规模较小的云规模的选择上与预测的配置显著不同。 因此，实际的部署成本显着偏离基于小规模测试的估算。
我们进一步表明，通过衡量绩效的规模，可以在AWS中配置高效的集群公共云。 为了演示这一点，我们的部署将ThemisMapReduce升级到由100个组成的AWS群集的节点和100兆兆字节的虚拟化SSD存储，并在GraySort比赛中创造了三项新的世界纪录，而成本是非常低。我们将我们的排序结果与其他记录获胜者进行比较，并找出几个共同之处获奖作品，进一步支持了这项工作的成果。
本文的贡献是：
1.一种通过应用程序级基准用于测量公共云中高性能虚拟机的I / O功能的系统方法。
2.虚拟化I / O上的大规模测量当前的AWS产品，。
3.对于在100个经济高效的节点上以及100个TB字节的数据排序进行大规模评估测量方法。
4.根据我们的评估结果，在分类速度和经济效益方面创造了三项新的世界记录。
2. Related Work
尽管以前的许多作品都研究了公有云的性能，但我们注意到我们的作品具有独特之处
以下几个方面：
我们测量由100个虚拟机组成的集群
•我们测量提供高性能虚拟化的虚拟机存储和网络设备
•我们测量使用100兆兆字节的工作负载的基于云的存储
•在高速分拣上，我们用我们研究的结果打破了几个世界记录。
现在我们讨论几个相关的研究。
测量：许多公司已将公有云视为科学计算的平台的潜力。 沃克[32]将亚马逊弹性计算云（EC2）与最先进的高性能计算（HPC）集群进行了比较 .而Mehrotra等人在 四年后，于NASA在HPC工作负载中进行了类似的研究[20]。 两者都得出了同样的结论：公共云中的网络对于HPC工作负载来说不够快。
其他人已经研究了虚拟化对I/ O资源的影响。 Wang和Ng [33]测量了EC2上各种网络性能指标，发现EC2（Elastic Compute Cloud (EC2)）方面的差异明显大于私有集群。 Ghoshal等人 [10]研究I / O存储，发现EC2虚拟机比专为科学计算而设计的私有云具有更低的性能和更高的可变性。
云的可变性也扩展到CPU和内存资源。 Schad等人 [25]衡量各种虚拟机资源的可变性，并发现其中，底层服务器硬件的异构性显着增加了性能差异。 两个相同类型的虚拟机可以运行在具有不同性能配置文件的不同代的处理器。
在一个稍有不同的研究路线中，Li等人 [17]衡量云间差异，即云提供商之间的性能差异。他们在各种维度上比较了Amazon EC2，Microsoft Azure，Google AppEngine和RackSpace CloudServers，并发现每个云提供商都有自己的性能配置文件，与其他文件大不相同，从而使公共云中资源配置的选择更加复杂。
配置：测量云的一个目标是优化的自动群集配置。Herodotou等人 [14]描述了Elasticizer，一个用于剖析Hadoop MapReduce作业并在EC2上选择最佳作业配置的系统。 Wieder等人 [34]介绍了Conductor，一个将云服务和本地服务器结合部署在同一个系统。
在共享群集的最后期限之前进行调度是另一种常见的工作。 ARIA [30]是Hadoop的调度程序，它使用MapReduce的分析模型满足最终期限，以解决适当数量的映射和减少插槽的问题。Jockey [8]是一个类似的系统，用于更一般的数据并行应用。 Bazaar [15]将这些努力转化到云中，将典型的以资源为中心的云API转换为以作业为中心的API，用户请求的是作业最终期限而不是VM集合。在此模型中，云提供商将作业配置文件应用于分析模型，以计算出最便宜的方式来完成作业的截止日期。
规模：在公共云中，用户通常会选择使用大量慢速，廉价的虚拟机或少量快速，昂贵的虚拟机。扩大或缩小的选择取决于可用的技术。迈克尔等人 [21]比较了一个扩展的SMP服务器和一个横向扩展的刀片服务器集群，并发现该日历配置更具成本效益。 半年后，Appuswamy等人 [2]在Hadoop的情境中中重新讨论了这个问题，发现相反的事实：单个纵向扩展服务器比大规模扩展配置更具成本效益。
虽然两种方法的相对成本随时间而变化，但向外扩展配置必须警惕过度变化。 Dean和Barroso [7]研究了Google Web服务的尾部延迟，并展示了生产数据中心的长尾延迟分布。 他们呼吁开发人员在他们的系统中建立尾部容差以避免性能损失。 Xu等人 [38]采取务实的方法，并开发一个系统来筛选和移除长尾虚拟机。
同时，Cockcroft [5]演示了Netflix如何利用EC2上的扩展VM来降低成本，同时极大地简化了群集配置。Cockcroft依靠较新的基于SSD的虚拟机，表明可用硬件驱动选择是扩展还是扩展。当然，该软件还必须能够利用扩展。塞维利亚等人。 [26]描述了对MapReduce的优化，可以缓解扩展配置中的I / O瓶颈。
3. Background
我们现在简要介绍AmazonWeb Services（AWS）中的I / O资源并描述我们的应用程序模型。
3.1 Amazon Elastic Compute Cloud
亚马逊弹性计算云（EC2）是一种云计算服务，按小时计费按需提供虚拟机（称为实例）的访问权限。有许多类型的实例可用，每种实例都有特定的虚拟CPU核心（vCPU），内存，本地存储和网络带宽。表1列举了一些例子。
表1：具有各种CPU，内存，存储和内存的四个EC2VM网络功能。 一些虚拟机使用闪存（*）而不是硬盘。
虚拟机实例位于可用区域，这些区域分布在各个地理分布的区域。同一区域内的虚拟设备被设计为提供低延迟和高带宽的网络访问。随着AWS中部署新硬件，各个VM的成本因实例类型以及时间而异。在本文中，我们只考虑“按需”定价，代表在给定工作中保留和保留实例的成本。最后，虽然云提供了无限计算和存储资源的抽象，但实际上，给定可用区中的资源数量是有限的。这使群集配置变得复杂，因为当用户需要时，给定作业最经济的群集可能无法使用。根据我们的经验，推出甚至100个特定类型的虚拟机需要与亚马逊的工程师进行两周的来回通信。即使那样，我们也只能在几小时的短时间内分配虚拟机。
3.2 Virtualized I/O
I / O虚拟化技术的最新进展使云成为数据密集型计算的有吸引力的平台。这里我们讨论云中可用的三种虚拟化I / O。
3.2.1 Virtualized Storage
在2012年，亚马逊推出了具有固态存储设备的首款EC2虚拟机。在此之前，所有EC2 VM都运行在硬盘或持久性网络连接存储上。在接下来的两年中，越来越多的带有SSD的虚拟机变得可用。到2014年中，亚马逊开始强调其SSD产品，将基于硬盘的VM降级到“上一代”VM。其他云供应商也纷纷效仿新型更快的存储技术。谷歌最近为其Compute Engine [11]云增加了一个本地SSD产品。 Microsoft Azure的新G系列虚拟机包含大量本地SSD存储[4]。
由于提供的带宽非常高，访问时间如此之短，因此需要付出巨大的努力才能在虚拟化环境中全速支持这些设备。如果虚拟机管理器花费太多时间处理共享设备上的I / O，则性能将受到影响。最近的虚拟化技术（如单根I / O虚拟化（SR-IOV））使供应商能够像许多更小的虚拟化设备一样将高速I/ O设备展示出来[28]。使用SR-IOV，管理程序不在数据路径中，从而使访客虚拟机能够更快地访问这些设备。
3.2.2 Virtualized Network
今天，高速网络在公共云平台中很常见。 早在2010年，EC2就提供了连接到10 Gb/ s网络的虚拟机，尽管这些虚拟机主要针对科学集群计算。最近，10 Gb / s网络已经推出到针对更多通用工作负载的VM类型。虽然在专用硬件上实现最大网络性能是困难的，但虚拟化增加了需要解决的另一个级别的复杂性以实现效率。就存储而言，像SR-IOV这样的技术可以减少虚拟化开销并充分利用高速网络。在共享环境中，可以使用SR-IOV对10 Gb / s接口进行分片，以便每台虚拟机接收一部分带宽。在单个访客VM的情况下，消除开销使得10 Gb / s的传输速度成为可能。
亚马逊通过称为增强型网络的功能提供SR-IOV。尽管并非所有虚拟机都支持增强型网络，但大部分较新的虚拟机都可以访问该功能。这些不仅包括支持10 Gb / s的虚拟机，还包括较小的虚拟机，这些虚拟机可能使用SR-IOV从大型实例类型中划分出来，以便高效地共享一个10 Gb / s NIC。
增强的联网功能还使虚拟机能够在一个放置组中启动。 展示位置组指示EC2在网络中战略性地配置虚拟机以增加分割带宽。 鉴于超额预订在大型数据中心网络中很常见[13]，安置组在为用户提供高性能方面发挥着重要作用。
3.2.3Network-Attached Storage
第三种类型的虚拟化I / O即网络连接存储是在云环境中实施持久存储的常用方式。 VM关闭或迁移后，通常会删除第3.2.1节中描述的本地存储设备。为了存储持久性数据，用户被定向到单独的存储服务，例如AmazonSimple Storage Service（S3）或Amazon Elastic Block Store（EBS）。 这些服务可通过各种接口远程访问。 例如，S3支持RESTful API，可通过HTTP访问，而EBS则作为标准块设备公开。 在这项工作中，我们评估EBS是因为它的接口类似于本地存储设备，支持未修改的应用程序。 要访问EBS，用户只需将一个卷附加到正在运行的实例。 可以使用接近任意大小和IOPS要求创建卷，可以通过硬盘或SSD支持。
在持久的网络附加存储上实现高性能带来了自身的复杂性。 在后端，存储服务必须配备足够的存储设备以满足用户的需求，并且还有一种将其刻录成卷的有效方式。通常这些存储服务也被复制，进一步增加了复杂性。在客户端，存储服务的黑盒性质使得发布最佳I / O模式复杂化。最后，网络中的拥塞或来自同位置VM的干扰可能以不可预知的方式降低性能。
3.3Application Models
在这项工作中，我们专注于I / O绑定作业的性能并部署我们的内部MapReduce [22,24]的Themis。 Themis将MapReduce作为双通道流水线算法实现。在第一张地图和随机播放过程中（图1），Themis将硬盘输入数据读入小内存缓冲区。然后它将map（）函数应用于这些缓冲区中的记录，并将生成的映射输出或中间数据分成多个分区。与将中间数据写入本地硬盘的传统MapReduce系统不同，Themis将中间数据缓冲区通过网络传输到远程
节点写入到远程节点的本地硬盘上的分区文件之前。这种实现避免了传统的任务级容错，有利于提高I / O性能。
在第二次排序和减少传递（图2）中，Themis从本地硬盘读取整个中间分区到内存中。 然后它对这些分区进行排序并应用reduce（）函数。最后，将结果记录写入本地硬盘上的输出分区文件。在极少数情况下，分区不适合内存，这是一个单独的机制
处理这些过大的分区。
图1：Themis阶段1：map（）和shuffle。
图2：Themis阶段2：排序和reduce（）。
我们现在根据关于I / O效率和数据持久性的几个假设对Themis的性能进行建模。
3.3.1 2-IO
由于Themis避开了传统的任务级容错，它具有2-IO属性[22]，该属性表明每条记录都是从存储设备读取和写入存储设备的两倍。 在本文中，我们将数据排序视为我们的激励应用。 对于外部排序，Themis实现了I / O操作的理论最小数量[1]。 这个属性不仅使Themis有效率，而且还产生了一个非常简单的计算模型。 当我们将焦点限制在I /O绑定应用程序中时，映射和混洗阶段的处理时间可以建模为：
其中Min和Mout表示每个节点的映射输入和输出数据大小，Bread，Bwrite和Bnetwork表示每个节点的存储和网络带宽。为了清楚起见，我们在图1和图2中标出了这些变量排序，映射输入和输出的特殊情况是相同的，如果我们确保读写带宽相同，我们将留下：
其中D是每个节点要排序的数据大小。 接下来我们计算排序和reduce阶段的处理时间。由于此阶段只涉及本地计算，存储是唯一的I / O瓶颈：
其中Rout是reduce输出数据大小。 同样在排序的情况下，这等于D，即每个节点的数据大小，所以处理时间是：
实际上，可能并不是读写带宽相同，在这种情况下，我们有：
因此最后的排序处理时间是：
最后，我们考虑虚拟机的每小时费用Chourly来计算这种类型的总美元成本：
3.3.2 Application-LevelReplication
2-IO模型代表了I / O约束工作的成本效率和性能的上限。实际上，只存储一份数据会大大降低耐久性。我们现在考虑应用程序为每个输出文件创建一个远程副本以提高耐用性的情况。
图3：使用应用程序级复制进行排序和reduce（）。
我们通过输出复制来增强排序和reduce阶段，如图3所示。除了将输出分区写入本地输出硬盘，系统还会在远程节点的本地输出硬盘上创建每个输出文件的副本。这会导致为每个输出分区文件进行额外的网络传输和硬盘写入。此联机复制会影响排序和reduce阶段的总处理时间：
在排序的情况下，将变成：
请注意，映射和混排阶段（等式2）与排序和reduce阶段（等式9）之间的存储带宽要求存在不对称性。这种不对称将需要更改存储配置，正如我们将在5.2节中看到的那样。
3.3.3Infrastructure-Level Replication
如第3.3.2节所述实现应用程序级复制会增加显着的复杂性和成本。 云提供商通常提供基础架构服务以减轻应用程序开发人员的负担。
为了说明基础架构级别复制的使用，我们考虑在Amazon EC2上运行Themis MapReduce，其中使用3.2.3节中描述的EBS存储服务用于输入和输出数据，而本地硬盘仅用于中间数据。Map和混洗阶段的时间变为：
同样，排序和reduce的时间是：
我们在接下来的部分中考虑这三种模型的性能和成本影响。 第4部分深入探讨了2-IO模型，而第5部分描述了对所有三个模型的大规模评估。
3.3.4Model Generality
虽然我们的模型涵盖了几个用例，但我们承认它们是特定于Themis MapReduce的。我们现在讨论这些模型如何推广到其他平台。
Themis MapReduce从其流水线实现中获得了很多I / O效率，这限制了与Hadoop [39]等框架相关的无关I / O的数量。 MapReduce Online [6]为Hadoop带来了流水线化，尽管容错仍需要额外的硬盘I / O。一般来说，我们的模型可以更新以处理其他框架执行的其他I/ O操作。
在这项工作中，我们假设I/ O密集型工作是I / O 界限。 虽然计算绑定作业超出了本工作的范围，但我们假设可以根据作业的计算需求构建新模型。这样的模型可以包括I / O和计算时间的术语。
我们的模型假定零调度开销，因为Themis一次运行一个作业，每个节点每个阶段运行一个进程。通常，模型可以被更新以解决框架调度开销。
最后，许多I / O密集型应用程序运行不是MapReduce的框架。 例如，大型图的计算可能受益于专门的框架[18,19]。 这些框架将需要不同的计算模型，但应包括一些类似的I / O密集型工作术语，并可能从本工作中描述的技术中受益。
4.Profiling AWS Storage and Networking（分析AWS存储和网络）
现在我们将注意力转向选择EC2上的I / O绑定应用程序的集群配置。 正如我们将要展示的那样，了解虚拟机规格并不够简单。 必须考虑每个虚拟机的缩放行为。
为此，我们设计实验来估计EC2上的I / O绑定作业的性能。 首先，我们测量本地存储的每个虚拟机带宽（第4.2节）。当网络不是瓶颈时，这近似于工作绩效（在我们的模型中Bnetwork =∞）。接下来，我们测量每个VM类型的网络性能（第4.3节）。综合起来，这些指标提供的性能估计可以解决瓶颈问题，但假定网络性能完美地扩展。然后，我们使用更大的群集大小来衡量网络的实际缩放行为，以优化此性能估计。最后，我们将这些结果与公布的每小时成本结合起来，选择在3.3.1节描述的2-IO模型下运行大规模100TB分拣作业的最具成本效益的VM。
我们使用两个定制的microbenchmark（微基准测试）工具运行分析：（1）DiskBench，它测量单个节点内存储子系统的整体吞吐量;（2）NetBench，它通过综合生成数据而不涉及本地存储1来测量网络性能。我们在后面的章节中描述这些工具。
4.1Measurement Limitations
在进行公共云测量时，常见的问题是方差。 客户之间的资源共享（共同位于同一台机器上或使用相同的网络）会增加差异并使测量更加困难。通过每天不同时间测量的昼夜工作负载模式，对云性能进行完全公正的评估变得复杂。在工作时间发起的工作可能会导致周末和工作日看到不同级别的表现。不太频繁的定期工作甚至可能导致基于一年的月份或月份的变化。
除了用户创建的差异外，底层基础架构还在不断变化，这意味着任何度量仅仅是当前状态下云的快照。例如，在本文实验和出版物之间的时间内，亚马逊增加了16个新的实例类型到EC2，所有这些都会影响共享网络的性能。差异甚至可以存在属于同一供应商的不同的方面的数据中心。不同的数据中心可能包含具有不同性能水平的I / O设备，如Schad et al [25]已经表明。
尽管我们承认存在这种差异，但我们承认我们对其进行量化的能力有限。尽管得到了亚马逊教育补助计划的部分支持，但本文中的实验总计超过5万美元的AWS成本，因此我们无法继续深入研究AWS以解释这些形式的差异。
这些成本大部分来自运行大规模基准测试和评估以梳理网络的缩放属性。 有人更深入了解云的网络属性，例如 供应商可能会将其纳入第3.3节所述的模型中，从而消除大部分成本并腾出资源进行深入的可变性分析。
最后，分配大量按需虚拟机并不总是可能的。第5节中的大规模评估只有在与AWS工程师进行数周的往返通信后才有可能。当我们终于能够分配虚拟机时，我们被指示在几个小时后解除它们，证明不可能进一步测量。由于这些原因，本文没有提供云中变化的全面研究。
4.2 Local StorageMicrobenchmarks
我们通过使用DiskBench分析每个EC2 VM类型上可用的本地存储来开始我们的测量研究。由于本地存储设备通常比网络连接存储更快，因此这些测量通常是存储性能的上限。我们在4.4节重新讨论本地与远程存储的选择。
图4：DiskBench存储微基准标记本地运行在单个节点上，而不涉及网络。
4.2.1 The DiskBenchMicrobenchmark
如图4所示，DiskBench是一个流水线应用程序，它重用了Themis MapReduce的许多组件（第3.3节）。 DiskBench通过读取记录而不应用map（）函数来将存储子系统从映射和混洗阶段中分离出来。记录被随机分配到同一节点上的分区，并写回本地硬盘而不涉及网络混洗。
我们将DiskBench配置为使用本地硬盘的一半进行读取，而将另一半用于写入具有多个硬盘的VM。这种配置通常是本地存储设备的理想选择，实际上是我们早期高速分类经验中使用的配置[24]。因此，由DiskBench报告的带宽可以度量读/写工作负载，并且在很多情况下，它们大约是只读或只写工作负载的一半可用带宽。
4.2.2Experimental Design
我们在us-east-1a可用性区域中实例化AWS提供的每种类型的两到三个VM。我们在每个集群上运行三次DiskBench，并计算平均每节点存储带宽Bstorage，以兆字节每秒（MB / s）为单位。我们在多个实例上运行DiskBench，以解决VM之间的性能自然变化。
4.2.3Analysis
DiskBench的结果如图5所示。我们报告平均读/写存储带宽以及提供的每VM存储容量。根据对100 TB输入数据进行排序所需的簇大小，我们将VM分为多个区域; 最右边的区域表示需要少于100个虚拟机的实例类型。中间区域代表需要100到1,000个虚拟机的类型。最后，最左边的区域表示需要超过1,000个虚拟机的类型。我们强调这些区域，因为提供大型群集并非总是可行。例如，我们发现即使在亚马逊工程师的帮助下，我们也只能在单个可用区域内分配至多186个i2.8xlarge实例。此外，正如我们将要表明的，网络性能会随着更大的集群而显着降低。
在图5中，我们标记了一些更有趣的实例类型。 其中很多位于图的右上方，代表了一组候选实例类型，它们既提供高存储性能，又提供足够的本地存储，以满足100TB的小群集容量要求。sub-100VM区域中性能最高的实例类型是i2.8xlarge，它是包含8个800 GB SSD，DiskBench测量的同时读/写带宽为1.7 GB / s。 i2.4xlarge实例类型具有SSD数量的一半，因此具有一半的存储带宽。另一个有趣的实例类型是hs1.8xlarge，它使用HDD而不是SSD来提供最高的存储密度。 hs1.8xlarge实例类型包括24个本地硬盘，支持1.06 GB / s的读写带宽。由于其高存储密度，仅需要7个实例即可满足100 TB排序操作的容量需求。
Estimating the dollar costof sorting: 接下来我们使用DiskBench的结果和列出的AWS每小时成本预测使用Themis运行100 TB 2-IO排序的总美元成本。 在这里，我们只考虑本地存储性能（B网络=∞），并将图5中的结果应用到公式7来估算分类100 TB的总成本。
表2显示了按总分类成本排序的这些结果的一个子集。 为了突出容量限制，我们计算了容纳300 TB所需的VM数量，其中涵盖了100 TB排序的输入，中间和输出数据。
从表2中我们可以看出c3.large是最经济的，每类成本为28美元。但是，每个VM只有32 GB的存储空间，因此需要9,375个实例才能保存必需的300TB数据。接下来是m3.large和m3.medium实例类型，排序成本约为65美元。再次，缩放以满足容量要求是一个重大挑战。实际上，直到m1实例类型为止，O（100）节点的集群才足够。具有O（10）节点簇大小的第一种实例类型是i2类型，它们使用SSD阵列构建。 100TB排序可以完成只有47个i2.8xlarge实例，成本为218美元。作为参考，最昂贵的实例类型是cr1.8xlarge，这是一种内存优化的32核心实例类型，带有两个120 GB固态硬盘，其中100 TB类型的成本为2966美元，比最便宜的实例类型贵100倍以上。值得注意的是，两种实例类型的小时成本可能相差一个数量级，但用户的总成本可能非常相似，例如m1.xlarge和i2.4xlarge。
总结：衡量虚拟机存储带宽可以深入了解大型数据密集型应用程序的总体成本。许多高性能虚拟机配置可以使用少量节点提供合理的成本。
4.3Network Microbenchmarks
接下来，我们测量AWS网络基础架构的性能和可伸缩性。 我们关注第4.2节中测量的具有较高性能和较高存储容量的实例类型的子集。
4.3.1The NetBench Microbenchmark
图6：NetBench网络microbenchmark使用合成输入数据来衡量网络可伸缩性和性能。
与DiskBench类似，NetBench（图6）是从Themis衍生出的一种面向管道的应用程序。 类比之后，NetBench的目标是将网络子系统从map和混洗阶段中分离出来。 合成数据记录在内存中生成，并通过网络混合到远程节点，从而简单地删除数据记录。NetBench完全在内存中运行，不会触及本地硬盘。
4.3.2Experimental Design
我们执行两个实验来衡量AWS网络基础架构。 第一个实验确定每种实例类型的基线网络带宽。 对于每种VM类型，我们在us-east-1a可用区中分配一个由两个节点组成的集群。 在这些集群的每一个上，我们运行NetBench三次。从这三个数据点中，我们计算出平均观测的网络带宽，B网络，我们以非常规单位兆字节每秒（MB / s）报告，以便与DiskBench的结果进行比较。该测量表示网络的理想缩放行为。如果可用，我们启用增强型网络功能并将节点分配到单个放置组中，并且我们在节点之间使用两个并行TCP连接来最大化高速VM的带宽。
接下来，我们量化候选VM类型集中的网络缩放行为。 对于每种类型，我们通过分配两个虚拟机来获得一个大小为2的簇，再分配两个以获得大小为4的簇，再分配四个以获得大小为8的簇，从而构建更大的簇。依此类推。在每个群集上，我们运行一次NetBench并测量最慢VM所观察到的全部网络带宽。
最大测量群集因实例类型而异。 在许多情况下，由AWS施加的限制阻止了更大的研究。 对于一些较昂贵的虚拟机，由于资金有限，我们限制了最大集群规模。我们在此实验中不使用展示位置组，因为这样做会改变网络的自然缩放行为并限制群集大小。当所有虚拟机同时启动时，安置组也可以发挥最佳效果。这种启动模式既不是弹性缩放应用的代表，也不适用于我们的实验设置。此外，我们使用虚拟机之间的单个TCP连接，因为使用多个TCP连接会降低较大群集大小的性能，并且我们最终对大规模性能感兴趣。
4.3.3Analysis
我们在图7中显示了一部分虚拟机的基准网络性能。为了比较，我们还展示了在4.2节中测量的存储性能。对于许多虚拟机，存储和网络带宽不匹配。等式2（第3.3节）表明，我们需要等量的存储和网络带宽来处理map和shuffle阶段，但这通常不会实现。例如，i2.8xlarge的网络带宽仅为其测量的存储带宽的63％。这种不匹配会降低必须同时使用存储和网络I / O的应用程序的端到端性能，从而导致未充分利用的资源。
图7：存储和网络性能之间的比较。
图8：网络性能可扩展性显示为图7中给出的基准网络性能的一部分。
图8显示了网络的缩放行为，显示为基线带宽的一部分。 这种比较并不完美，因为这些实验是在不同的日子里，在两周的时间和不同的时间在不同的虚拟机上运行的。这可能解释了m1.xlarge和hi1.4xlarge在小簇大小时如何达到比基线快20％的速度。
但是，主要的一点是随着更多节点添加到群集中，性能显着下降。在测量的九种VM类型中，有八种在实验期间性能下降到基线的80％以下。一个实例类型cc2.8xlarge显示性能一直很差。我们推测这种类型位于网络的高度拥塞部分，只能在高性能时才能实现
展示位置组已启用。
重新排序的经济成本：最后，我们使用DiskBench和NetBench的结果来预测在每个VM实例类型上运行100 TB2-IO排序操作的总货币成本。我们将我们的测量应用到公式7（第3.3节）以确定总经济成本。
图9：在各种网络性能假设下，对EC2VM类型子集中的100 TB进行排序的估计成本。
预测成本如图9所示。对于选定的虚拟机，我们显示（1）假设网络不是瓶颈的总成本，（2）假定网络带宽以理想方式缩放的成本，以及（3）成本基于观察到的横向扩展网络性能。结果显示，排序成本最低的VM为m1.xlarge，每种排序为362美元，紧接着是i2.8xlarge和i2.xlarge。 有趣的是，虽然i2.8xlarge的理想网络可扩展性成本大于m1.xlarge，但i2.8xlarge具有更好的实际网络扩展性能，导致非常相似的总体美元成本。但是，i2.8xlarge实例类型支持放置组，如果使用它们，实际上会导致总体成本低于m1.xlarge。我们将此配置表示为i2.8x P，估计成本为325美元，比m1.xlarge便宜37美元。
总结：估计成本时必须考虑网络性能，特别是在规模上。伸缩性能不佳可能会显着增加成本。更好的网络隔离，例如安置小组，可以大幅降低成本。在排序情况下，网络隔离可节省37美元，即约10％。
4.4 Persistent Storage Microbenchmarks
我们现在将注意力转向网络附加存储。 虽然本地存储通常具有更好的性能，但许多云部署将希望输入和输出数据在VM重置和迁移中保持不变。我们现在考虑Elastic Block Store（EBS）的性能属性，EBS是AWS提供的持久性网络附加存储服务。
4.4.1 Experimental Design
为了测量EBS的性能，我们在us-east-1a中分配了三个i2.4xlarge实例，并启用了增强型网络和EBS优化功能。 在实验时，i2.4xlarge是支持250 MB / s最大EBS吞吐量的少数VM类型之一。 截至撰写本文时，亚马逊提供了三种新的实例类型，速度高达500 MB / s。 EBS提供三种类型的存储卷：硬盘，通用SSD和IOPS供应SSD。对于每种类型，我们创建并将八个215 GB EBS卷附加到三个i2.4xlarge实例中的每一个实例。然后，我们运行DiskBench，并更改使用的EBS卷的数量。
我们将DiskBench配置为以只读和只写模式运行，但不以第4.2.1节中描述的读/写模式运行。这更接近于实际的EBS备份应用程序，该应用程序将从永久性存储读取输入数据，使用本地每个VM存储进行处理，然后将输出数据写回持久性存储。这种使用模式直接对应于3.3.3节中描述的基础设施级复制模型。
我们在三个节点的每一个节点上运行EBS卷类型，EBS卷的数量和DiskBench模式的三种组合，以获得平均带宽度量。
4.4.2 Analysis
图10：i2.4xlarge观察到的EBS性能。 虚线表示最大广告表现。
图10a和10b显示了只读和只写结果。 有四个关键点。 首先，单个EBS卷不能使虚拟机和EBS之间的链接饱和。随着更多的卷被添加到250 MB / s限制，带宽也随之增加。其次，只需使用三种任意类型的卷即可实现接近最大的读取性能。第三，使用三个基于SSD的卷可以实现接近最大的写入性能。最后，即使是八卷，硬盘也无法实现最大的写入带宽。
我们得出结论：EBS优化的虚拟机可以在基于SSD的卷上实现最大速度。但是，EBS卷比本地每个虚拟机存储要慢得多。例如，图5显示i2.4xlarge对其本地固态硬盘的读/写带宽能力接近900 MB / s。因此，EBS带宽很可能成为基础设施级复制的瓶颈（公式10和11），并且将会比4.3.3节中推导出的成本分析略微偏移一些。
总结：使用SSD构建的持久存储系统可以提供合理的存储性能。 但是，本地的每个虚拟机存储提供了更高的性能水平，因此持久存储可能会成为瓶颈。
4.5Key Takeaways
为了清楚起见，我们强调了四个关键要点：
1. DiskBench可用于以较低的成本评估各种虚拟机的存储性能，从而估算工作成本。较小的VM类型提供较低的成本，但需要成千上万的VM。较大的虚拟机提供合理的成本级别，虚拟机的数量级别更少。认为太贵的虚拟机可以从进一步考虑中删除。
2. NetBench可用于细化此成本分析，同时考虑到小型和大型网络的网络性能。许多虚拟机显示较差的网络缩放属性，导致估计成本远高于基于虚拟机规格的后盖计算。
3.将i2.8xlarge与放置组一起使用可以获得最佳性能，并且可以使用少量VM来提供最低的估算分类成本。其他虚拟机，例如hs1.8xlarge，最初看起来不错，但在实践中表现不佳，导致成本增加3倍。
4.支持SSD的EBS卷可以为需要增强数据持久性的应用程序提供完整性能。但是，EBS远远低于某些虚拟机上的本地存储，并且可能会成为瓶颈。
5.Evaluation
到目前为止，我们已经在第3.3.1节中描述的2-IO模型的背景下测量了AWS中几个云产品的I / O性能和可伸缩性。 我们现在对第2部分以及第3部分介绍的其他模型进行大规模评估。我们考虑分类100 TB并在每种情况下衡量性能和成本的问题。每个评估对应于大量已建立的大规模排序基准[27]之一，因此代表了一个人们可能想要使用公共云解决的现实问题。
5.1 2-IO
我们通过对100 TB数据集进行排序来评估2-IO的性能和成本，该数据集由一万亿个100字节的键值对组成。每对包含一个10字节的密钥和一个90字节的值。密钥均匀分布在25610个可能密钥的空间中。
实验设置：我们在us-east-1a可用区中的单个放置组中分配178个i2.8xlarge的按需实例。 我们使用本地，每个VM SSD输入，中间和输出数据集。
在运行排序应用程序之前，我们在群集上运行DiskBench和NetBench微型基准以获得基准性能测量结果，并使硬件故障或缓慢的VM失效。 DiskBench报告最低VM的读写存储带宽为1515 MB / s，这是第4.2节中测量的带宽的87％。 NetBench产生一个网络带宽
879 MB / s，这是4.3节测量的基线的81％。我们注意到这个实验是在与第四部分不同的日子进行的，因此可能有不同的性能特征。
如第4.2.1节所述，我们将Themis配置为使用八个本地SSD中的四个用于输入和输出文件，其余四个SSD用于中间文件。
结果：100 TB 2-IO排序在888秒内完成，需要299.45美元。 为了更好地理解此特定工作的瓶颈和局限性，我们使用sar，iostat和vnStat [29,31]收集系统级性能指标。使用这些测量，我们发现在完成map和shuffle阶段所需的大约500秒内，Themis是网络绑定的。图11a显示了三台随机选择的服务器的网络利用率与时间的关系。10 Gb / s网络几乎被充分利用，结果，CPU和SSD仅被轻度利用，如图11b和11c所示。
图11：运行100 TB2-IO排序的三个VM的资源使用情况。在t≈500s时，瓶颈从网络转移到存储。
在映射和混洗阶段结束后立即开始的排序和缩小阶段由本地SSD进行I / O限制。由于在这个阶段没有网络传输，Themis可以充分利用可用的存储带宽，图11c显示硬盘写入带宽接近底层硬件的限制。多个排序线程允许CPU使用率显着增加。但是整个系统不会成为CPU限制的，如图11b所示。
由于排序工作是I / O限制的，因此最终成本（$299.45）非常类似于具有放置组（$ 325）的i2.8xlarge的4.3节给出的估计成本。我们得出结论，第4节中的方法可以合理准确地预测I / O约束作业的成本。
分类基准：尽管迄今为止的分析一直侧重于成本效益，但原始性能也是一个非常令人失望的特性。我们的100 TB 2-IO排序符合Indy GraySort 100 TB排序基准[27]的指导原则，实现了6.76 TB / min的总吞吐量。我们的排序比前一年的Indy GraySort记录快12倍（见表3），但成本还不到300美元。
我们将这个结果归因于本文中的方法论以及我们的Themis MapReduce框架。然而，重要的是要注意，它不仅仅是我们的代码库，可以产生高性能。事实上，我们的Indy GraySort速度已经被百度[16]超过20％，使用来自TritonSort[23,24]的系统，该系统也显示出2-IO。 因此，2-IO计算模型对性能和成本效率都有强大的影响。
表3：我们的100 TBIndy GraySort条目。显示过去和现在的记录持有人进行比较。
表4：我们的100TB DaytonaGraySort记录。
5.2Application-Level Replication
接下来，我们评估第5.1节中描述的同一个100TB数据集上的应用级复制。我们运行支持输出复制的Themis的变体，如图3所示。此特定配置符合Daytona GraySort基准规范[27]。
实验设置：这次我们分配了186个on2和i2.8xlarge的实例。 和以前一样，我们在一个放置组中启动所有实例。 但是，由于美国东部1a的能力不足，我们使用美国东部1d的可用性区域。
正如3.3.2节所提到的，应用级复制中的存储不对称需要对Themis的配置进行一些细微的改变。这里我们使用八个SSD中的五个用于输入和输出文件，其余三个用于中间文件。这种配置更均衡地平衡了MapReduce作业的存储和网络需求。
结果：100 TB应用程序级复制需要1,378秒，总成本为485.56美元。尽管由于在不同日期的不同可用区域中使用不同的资源集合，所以将该结果与第5.1节中的2-IO结果进行比较并不完全公平，但值得注意的是，改进的数据耐久性增加了从5.1节测量的299.45美元减去186.11美元，即62％。
对基准进行排序：如表4所示，我们的ApplicationLevelReplication的性能超过了前一年的记录持有者3倍以上，设置了100 TB Daytona GraySort记录。 由Databricks运行的ApacheSpark提交了一个比我们稍慢的基准测试结果[35-37]，尽管我们的结果足够接近以至于被认为是平分。但是，我们的系统资源效率稍高一些，从而节省了66美元的成本，即约12％。
有趣的是，Apache Spark也运行了i2.8xlarge，因为EC2在这个基准测试中不是必需的。乍一看，i2.8xlarge可能看起来像是分拣这类I / O密集型工作的明显选择。但是，这项工作的结果显示，规模效益可能与最初的估计大不相同。例如，hs1.8xlarge似乎也是一个明显的选择，尽管其性能较差，如第4节所示。
5.3Infrastructure-Level Replication
最后，我们通过使用EBS卷运行Themis的2-IO实现来进行输入和输出，从而在同一个100 TB数据集上评估基础架构级复制。这种配置符合Indy和Daytona CloudSort基准测试的规格[27]，测量公共云上排序的美元成本。
初步结果：EBS更改了第4节中的成本分析，我们的测量结果表明最便宜的VM类型为c3.4xlarge。 我们在us-east-1a可用性区域的单个放置组中分配326个c3.4xlarge VM，并将其附加到每个161 GB通用SSD EBS卷。不幸的是，这种配置在读取性能方面有显着的差异图12显示了从EBS读取100 TB时经历1,304个EBS卷的运行时间的概率密度函数。
大约95％的节点在1,400秒内完成，但剩下的节点需要三倍的时间。 这种长时间的分布使得c3.4x大规模地成为基础设施级复制的无效选择。
表5：我们的100TBIndy和Daytona CloudSort记录。
实验设置：c3.4xlarge之后的下一个最佳选择是r3.4xlarge，这比价格高出60％，并且提供了大致相同的预计性能。 我们在us-east-1c可用区中的单个放置组中分配330个r3.4xlarge实例。 我们使用不同的区域，因为正如本文前面所述，通常不可能在特定区域中分配大量实例。对于每个实例，我们附上八个145 GB2通用EBS卷。我们使用EBS
用于输入和输出数据以及用于中间数据的本地SSD，如3.3.3和4.4节所示。
结果：我们运行三次，平均完成时间为2,981秒，平均成本为450.84美元（表5）。这个完成时间包括两轮完整的EBS I / O，远低于在相当规模的c3.4xlarge集群上运行单轮I / O所需的4000秒（图12）。我们得出结论，r3.4xlarge不会遇到相同的长尾行为。 EBS的黑盒性质禁止进一步分析，但有一种假设认为，将c3.4xlarge连接到EBS的网络比r3.4xlarge更加拥塞，因此变得更加可变。美国东部1c可用区本身也可能在规模上经历更好的EBS性能。
图12：由326c3.4xlarge虚拟机群读取的从EBS读取100 TB的双峰消耗时间。
我们注意到每个虚拟机的吞吐量几乎是EBS最大250 MB / s吞吐量的一半。这表明该类别的每个阶段都以接近最佳的EBS速度运行。实际上，第4.4节引出了理想的读写带宽
分别为243和226 MB / s。这表明理想的端到端吞吐量为117 MB / s，因此我们的分类速度最佳为87％。
排序基准：这些结果为Indy和DaytonaCloudSort设定了世界纪录。尽管在性能方面远低于Daytona GraySort，但我们的CloudSort记录实际上将100TB的价格降至35美元左右，或者更便宜8％左右，具有更强的耐用性要求。
6.Extending to Other Clouds
尽管对其他云提供商的分析超出了本工作的范围，但我们希望将结果扩展到其他云。我们现在简要讨论一下Google Compute Engine [11]并考虑我们的工作可能如何推广。
Compute Engine提供的虚拟机非常像EC2。截至本文撰写时，有18种虚拟机类型分为四类，我们在表6中列出了一个子集。
表6：五个示例计算引擎VM。
默认情况下，虚拟机不具有任何本地存储。 永久硬盘是一种类似于EBS的服务，是默认的存储模型。 用户可以选择将有限数量的本地SSD添加到虚拟机中以获得一个价格。但是无法添加本地HDD。
我们有限的经验表明，Themis，DiskBench和NetBench可以在各种VM类型上小规模地实现高水平的性能。 计算引擎目前缺乏明确的网络布局机制。 这可能会影响大量虚拟机所观察到的网络性能，但需要进行进一步分析才能做出此声明。
7.Conclusions
高速闪存存储和支持SR-IOV的10 Gb / s虚拟化网络已经实现了公共云平台上的高性能数据计算，然而，实现这些工作负载的效率仍然充满挑战。我们提供了一种测量高性能VM的I / O功能的系统方法，并使用我们的定制microbenchmark与DiskBench工具和NetBench广泛测量EC2内的这些功能。我们发现，由于网络扩展性差，预期成本会急剧上升，从而改变虚拟机配置的最佳选择。通过基于规模性能测量的巡视，我们展示了对EC2的高效分拣，并以极低的成本创造了三项新的世界纪录。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
