温度感知的MapReduce节能任务调度策略

廖彬，张陶，于炯，刘继，尹路通，郭刚



温度感知的MapReduce节能任务调度策略

廖彬1，张陶2，于炯3，刘继1，尹路通3，郭刚3

(1. 新疆财经大学统计与信息学院，新疆乌鲁木齐 830012； 2. 新疆医科大学医学工程技术学院，新疆乌鲁木齐 830011；3. 新疆大学软件学院，新疆乌鲁木齐 830008)

现有的FIFO、Fair、Capacity、LATE及Deadline Constraint等MapReduce任务调度器的主要区别在于队列与作业选择策略的不同，而任务选择策略基本相同，都是将数据的本地性(data-locality)作为选择的主要因素，忽略了对TaskTracker当前温度状态的考虑。实验表明，当TaskTracker处于高温状态时，一方面使CPU利用率变高，导致节点能耗增大，任务处理速度下降，导致任务完成时间增加；另一方面，易发的宕机现象将直接导致任务的失败，推测执行(speculative execution)机制容易使运行时任务被迫中止。继而提出温度感知的节能任务调度策略，将节点CPU温度纳入任务调度的决策信息，以避免少数高温任务执行节点对作业整体进度的影响。实验结果表明，算法能够避免任务分配到高温节点，从而有效地缩短作业完成时间，减小作业执行能耗，提高系统稳定性。

绿色计算；MapReduce；任务调度；温度感知

1 引言

大数据时代，数据从简单的处理对象开始转变为一种基础性资源，如何更好地管理和利用大数据已经成为普遍关注的话题，大数据的规模效应给数据存储、管理以及数据分析带来了极大的挑战[1]。据文献[2]统计，2007年全球数据量达到281 EB，而2007年到2011年这5年时间内，全球数据量增长了10倍。数据量的高速增长伴随而来的是存储与处理系统规模不断的扩大，这使运营成本不断的提高，其成本不仅包括硬件、机房、冷却设备等固定成本，还包括IT设备与冷却设备的电能消耗等其他开销。并且，系统的高能耗将导致过量温室气体的排放并引发环境问题。事实上，在能源价格上涨、数据中心存储规模不断扩大的今天，高能耗已逐渐成为制约云计算与大数据快速发展的一个主要瓶颈[1]。据文献[3]统计，目前IT领域的二氧化碳排放量占全球的2%，而到2020年这一比例将翻番。2008年路由器、交换机、服务器、冷却设备、数据中心等互联网设备总共消耗8 680亿度电，占全球总耗电量的5.3%。纽约时报与麦肯锡经过一年的联合调查后，最终在《纽约时报》上发表了“Power，pollution and the Internet”[4]，调查显示Goolge数据中心年耗电量约300万瓦，Facebook则达到了60万瓦，但巨大的能耗中却只有6%~12%的能耗被用于处理相应用户的请求。与此同时，Barroso等[5]对Google内部5 000多台服务器进行长达半年的调查统计结果表明，服务器在大部分时间里利用率都在10%～50%之间，服务器在负载很低(小于10%)的情况下电能消耗也超过了峰值能耗的50%。

Hadoop[6]作为新的分布式存储与计算架构，参考Google的分布式存储系统GFS[7]实现了分布式文件存储HDFS；参考MapReduce[8]计算模型实现了自己的分布式计算框架；参考BigTable实现了分布式数据库HBase。由于能够部署在通用平台上，并且具有可扩展性(scalable)、低成本(economical)、高效性(efficient)与可靠性(reliable)等优点使其在分布式计算领域得到了广泛运用，并且已逐渐成为工业与学术届事实上的海量数据并行处理标准[9]。虽然Hadoop拥有诸多优点，但是和Google服务器一样，Hadoop集群内部服务器同样存在严重的高能耗低利用率问题[10]。Hadoop主要由分布式存储系统HDFS与分布式任务执行框架MapReduce这2部分组成，现有研究大多从分布式存储系统HDFS入手解决Hadoop的能耗问题，针对MapReduce框架能耗优化方面的研究则相对较少。大量研究围绕通过对存储资源的有效调度，在不影响系统性能的前提条件下将部分存储节点调整到低能耗模式，以达到节能的目的。为提高MapReduce的能耗利用效率，本文做了如下工作。

1)首先对MapReduce系统模型的含义进行了数学表达，并对现有的FIFO、Fair、Capacity、LATE及Deadline Constraint等MapReduce任务调度模型进行了深入的归纳分析，在此基础上总结了现有调度策略存在的问题。

2) 提出了温度感知的节能任务调度策略，将节点CPU温度纳入任务调度的决策信息，以避免少数高温任务执行节点对作业整体进度的影响。算法实现方式上提出了基于心跳信息修改及基于健康监测脚本的2种实现方案。

3) 搭建真实的实验环境，精确地测量了节点CPU温度对任务运行时间及节点能耗的影响。证明了本文算法对不同类型作业任务完成时间及作业执行能耗两方面的改进。

2 相关研究

传统的IT系统一方面通过超额资源供给与冗余设计以保障QoS与系统可靠性[11]，另一方面负载均衡算法专注于将用户请求平均分发给集群中的所有服务器以提高系统的可用性，这些设计原则都没有考虑到系统的能耗因素，这使IT系统的能量利用日益暴露出高能耗低效率的问题[12]。学术与工业界分别从硬件[13~15]、操作系统[16~18]、虚拟机[19~26]、数据中心[27~33]4个层次去解决IT系统的能耗问题。针对分布式计算系统的能耗问题的研究，通常以Hadoop作为研究对象，并且大多从分布式存储系统HDFS入手解决其存在的能耗问题，针对任务执行框架MapReduce能耗优化方面的研究则相对较少。

在分布式存储系统节能方面，根据软硬件角度进行划分，可分为硬件节能与软件节能两方面[34]。硬件节能主要通过低能耗高效率的硬件设备或体系结构，对现有的高能耗存储设备进行替换，从而达到节能的目的。硬件节能方法效果立竿见影，且不需要复杂的能耗管理组件；但是对于已经部署的大规模应用系统，大批量的硬件替换面临成本过高的问题。软件节能通过对存储资源的有效调度，在不影响系统性能的前提条件下将部分存储节点调整到低能耗模式，以达到节能的目的。由于不需要对现有硬件体系进行改变，软件节能是目前云存储节能技术的研究热点。软件节能研究主要集中在基于节点管理与数据管理两方面。节点管理主要研究如何选择存储系统中的部分节点或磁盘为上层应用提供数据服务，并让其他节点进入低能耗模式以达到降低能耗的目的。节点管理中被关闭节点的选择与数据管理技术紧密相关，而目前已有的数据管理技术主要有基于静态数据放置、动态数据放置与缓存预取3种。其中基于静态数据放置的数据管理[35-39]根据固定的数据放置策略将数据存储到系统中各节点上后，将不再改变其存储结构。基于动态数据放置的数据管理[40~46]根据数据访问频度动态调整数据存放的位置，将访问频度高与频度低的数据迁移到不同磁盘上，对存储低频度数据的磁盘进行节能处理以降低系统能耗。基于缓存预取的数据管理[47]借鉴内存中的数据缓存思想，将磁盘中的数据取到内存或其他低能耗辅助存储设备并使原磁盘进入低能耗模式以此达到节能的目的。

研究分布式任务执行框架MapReduce能耗优化方面，少有的研究通过选择部分节点执行任务[48]、任务完成后关闭节点[49]、配置参数优化[50]、DVFS调度[51]、作业调度[52]、虚拟机放置策略[53]及数据压缩[54]等方法达到提高MapReduce能耗利用率的目的。与covering subset思想相反，文献[49]提出all-in strategy(AIS)，即将整个MapReduce集群作为整体用于任务的执行，当任务结束后将整个集群做节能处理(关闭节点)达到节能的目的。Chen等[50]发现MapReduce框架的参数配置对MapReduce能耗的利用具有较大影响，通过大量的实验得到优化MapReduce能耗的配置参数，对提高MapReduce集群系统的能耗利用率具有指导意义。文献[51]中利用DVFS(dynamic voltage and frequency scaling)技术，通过动态调整CPU频率以适应当前的MapReduce任务负载状态达到优化能耗利用的目的。文献[52]提出Hadoop节能适应性框架GreenHadoop，通过合理的作业调度，在满足作业截止时间约束的前提下通过配置与当前作业量相匹配的作业处理能力(活动节点数量)，达到最小化Hadoop集群能耗的目的，实验证明GreenHadoop与Hadoop相比提高了MapReduce的能耗利用率。宋杰等[55]对云数据管理系统(包括基于MapReduce的系统)的能耗进行了基准测试，并定义了能耗的度量模型与能耗测试方法，证明了不同系统在能耗方面存在着较大差异，需要进一步对系统进行能耗优化。

本文与已有工作的不同在于:已有的MapReduce节能任务调度研究是在满足作业截止时间约束的前提下通过减小活动节点的数量，达到最小化集群能耗的目的，是从整个集群的层面进行节能，而本文则提出温度感知的任务调度模型，将节点CPU温度纳入任务调度的决策信息，以避免少数高温任务执行节点对作业整体进度的影响，达到缩短作业完成时间，减小作业执行能耗的目的。相比已有工作，本文是从任务调度的层面出发，实现MapReduce作业能耗效率的提高。

3 MapReduce及其调度模型

3.1 MapReduce系统模型

MapReduce运行环境通常由多个机架RACK组成，而一个RACK内部又由多个节点服务器组成。通常情况下，MapReudce集群由2个NameNode(或JobTracker)管理节点(主管理节点与从管理节点)与多个DataNode(或TaskTracker)节点构成。本文将MapReduce集群中所有的DataNode节点服务器用矩阵表示，MapReduce集群节点矩阵如定义1所示。

定义1 MapReduce集群模型。设MapReduce集群由个RACK组成，并且设所有RACK中都有个DataNode节点服务器，用表示DataNode节点服务器，将MapReduce集群中的所有DataNode节点表示为矩阵

定义2 作业的任务分解模型。如图1所示， MapReduce框架将作业(job)分解为多个Map与Reduce任务并行地在集群中执行，可将这个过程定义为，其中，为映射函数，集合与分别表示job分解后的Map与Reduce任务，其任务分解模型可由式(2)表示。

式(2)表示作业被分解为个Map任务与个Reduce任务。其中，表示Map任务集合，表示任意Map任务；表示Reduce任务集合，表示任意Reduce任务。由于已有的FIFO、Fair、Capacity、LATE及Deadline Constraint等MapReduce作业调度算法已经实现作业到任务的分解。所以，作业的任务分解模型并不是本文的研究重点。作业的分解在作业的初始化阶段完成，JobTracker根据作业输入数据量与作业配置参数(用户指定或系统默认)将作业分解成个Map任务及个Reduce任务，并将作业分解信息存储到相关数据结构中(如XML作业分解描述文件)，供后期调度系统执行。

图1 MapReduce作业的任务分解

定义3 任务(task)资源(slot)映射模型。作业根据定义2被分解为Map与Reduce任务后，将由作业调度系统将任务映射到具有空闲资源槽的DataNode节点上执行。任务与资源映射过程可定义为映射，其中为映射函数，与分别表示Map与Reduce任务的集合，表示MapReudce集群中DataNode节点的集合。具体而言，映射模型可由式(3)描述。

在MapReduce计算模型中，任务与资源之间的映射本质上是任务调度问题。问题的核心是根据当前集群(或资源池)中各节点上的资源(如CPU、内存、磁盘与网络等)的剩余情况与各用户作业的服务质量(QoS)要求，在资源与作业(任务)之间作出最优的匹配。由于资源剩余与用户作业QoS需求之间存在多样化的特点，所以MapReduce中的任务资源映射模型是一个多目标优化问题，属于典型的NP难问题。

3.2 MapReduce调度模式

Hadoop中引入资源槽(slot)的概念来抽象表示各节点(DataNode或TaskTracker)上的资源。Hadoop将各节点上的资源(如CPU、内存、磁盘与网络等)进行等量的切分，将每一份资源称作资源槽，同时将slot分成Map slot与Reduce slot这2种，对执行Map与Reduce任务时的资源使用差异进行了区分。Hadoop将任务对多维资源的需求抽象成slot，大大简化了资源的表示及管理问题；规定一个task可根据实际情况占用一个或多个slot(大部分调度器(如FIFO、 Fair Scheduler)只支持一个task占用一个slot，而Capacity Scheduler可根据作业内存需求占用多个slot)，大大简化了任务与资源之间的映射问题。在实际运用环境中，需要根据节点硬件配置及作业特点对同节点上的Map slot(配置参数: mapred.tasktracker.map.tasks.maximum)及Reduce slot (配置参数：mapred.tasktracker.reduce. tasks.maximun)数进行设置。图2所示为MapReduce作业调度模型，一个MapReduce作业从提交到执行的整个过程可分为7步。

Step1 用户通过调用作业提交函数将作业信息(包括作业数据及作业配置信息等)提交到JobTracker。

Step2 当JobTracker收到用户新提交的作业后，JobTracker将通知任务调度器TaskScheduler对作业进行初始化操作。

Step3 某个具有空闲slot的TaskTracker向JobTracker发送心跳(heartbeat)信息，其中包含剩余的slot数目，资源状态信息及能否接受新任务等信息。

Step4 如果某TaskTracker能够接受新任务，则JobTracker调用TaskScheduler中的assignTasks方法为该TaskTracker分配新的任务。

Step5 TaskScheduler按照系统配置的调度策略(如 FIFO、Fair、Capacity、LATE及Deadline Constraint等)为该TaskTracker选择出最合适的任务(或任务列表)。

Step6 JobTracker将Step5中确定的任务(或任务列表)通过心跳应答的方式返回给Step4中确定的TaskTracker。

Step7 当TaskTracker收到JobTracker发送的心跳信息后，如果发现心跳信息中包含需要执行的新任务，则立即启动该任务的执行。

Hadoop中任务调度是一个可插拔的独立模块，Hadoop集群管理员可根据自己的实际应用需求设计任务调度器，可通过参数配置项mapred.jobtracker，taskScheduler对调度器进行配置。任务调度器TaskScheduler与JobTracker之间存在较为密切的功能互相调用关系，JobTracker需要调用TaskScheduler的assignTasks函数为具有空闲slot的TaskTracker分配新任务，而JobTracker中保存着整个集群中节点、作业及任务等相关元数据信息，而这些元数据信息是TaskScheduler进行调度决策时需要用到的。

3.3 MapReduce能耗模型

在3.2节对MapReduce及调度模式的分析基础上，本节对MapRedcue能耗模型进行建模，理论上证明高温节点对能耗的影响，其中，5.2节通过实验数据证明了高温对能耗的影响。

由于DataNode节点功耗由静态功耗与动态功耗2部分组成[56]，可进一步细化为与2部分，即可表示为

由于CPU是最主要的能耗部件，并且系统整体能耗通常与CPU利用率成正比[57]。同时，随着节能技术在处理器应用上的不断推广，比如Intel的Speedstep与AMD的PowerNow技术，使处理器能够根据负载动态调节性能，从而使能耗与负载之间具有较好的比例性[58]。那么，可将与分别用式(6)进行表示

(6)

从MapReduce能耗模型式(7)可以看出，计算MapReduce作业执行能耗的唯一前提条件是取得任务运行过程中的CPU利用率序列。从5.2节实验数据表明，过高的节点温度将加大作业运行时的CPU利用率。通过式(7)理论上证明了CPU利用率的升高将导致系统能耗的增加。

4 温度感知的节能任务调度算法

4.1 现有调度策略存在的问题

从3.2节中对MapReduce调度模式的分解可以看出，现有的MapReduce均为3级调度模型(如图2所示)，即当一个TaskTracker出现空闲资源槽时，调度器会首先选择一个作业队列，再选择作业队列中的作业，最后选择作业中的任务，并最终将选中的任务分配给这个空闲TaskTracker。现有的MapReduce任务调度器的主要区别在于队列选择策略与作业选择策略的不同，而任务选择策略基本相同，都是将数据的本地性(data-locality)作为选择的主要因素。

当某TaskTracker出现空闲资源槽时，会立即向JobTracker发送心跳信息，向JobTracker告知自己当前的资源状态信息及能够接受新任务的意愿。而JobTracker也将立即通过任务调度器TaskScheduler为TaskTracker所在的空闲资源槽分配新的任务。5.2节中实验数据表明，当节点处于高温状态时，作业完成时间变长，作业运行时功耗增加，作业运行时CPU利用率变高，作业(数据)处理速度变慢。实际应用环境中，节点的高温状态可能由如下2种原因造成。

1) 节点散热系统出现故障。节点散热系统一方面包括节点机身内部的散热系统，另一方面包括节点外部的，即数据中心(或机房)的散热系统。当节点散热系统出现故障时，节点产生的热量得不到及时的驱散，加之节点在任务运行过程中将不断产生新的热量，当热量累加到一定值时，将影响节点的运行状态，直到引起导致宕机，机器自动关闭，甚至导致硬件的烧毁。

2) 节点长时间处于高负荷运行状态。节点高负载运行时功耗达到峰值，散发出大量热量。长时间的高负荷运行容易导致节点的高温。

从上文中对已有的任务调度策略的分析可以发现调度系统并不关心拥有空闲资源槽节点当前的温度状态，一旦节点出现空闲资源槽，调度系统就尽最大努力为该节点分配合适的任务。此种调度策略最大程度上增加了系统资源利用率，使大多数作业能够更快地被处理完毕。但是，当任务被分配到处于高温状态的节点时，任务的运行会出现以下2种情况。

1) 任务完成时间变长。虽然MapReduce任务执行过程中任务之间并不是完全按照并行的方式进行的，但Map与Reduce任务之间存在不同程度的执行顺序与数据调用的制约关系(如只有当一个作业的Map任务成功完成的数量超过一定的阈值时，才能开始分配该作业的Reduce任务)，这使慢任务将造成等待时延，并最终影响到作业的整体完成时间。实际上， Hadoop的推测执行(speculative execution)机制，容易使高温节点的运行时任务被迫中止。推测执行机制是为了防止运行速度慢的任务影响作业的整体执行速度，根据推测算法推测出“拖后腿”的任务，并为该任务启动一个备份任务，并最终选用最先成功运行完成任务的计算结果作为最终结果。推测执行机制很可能使在高温节点上执行的任务“白忙活”。

2) 任务执行失败。高温节点出现宕机将导致任务的执行失败，调度系统将对该任务重新启动。造成资源浪费的同时延迟了作业的完成时间。

基于以上考虑，4.2节将提出温度感知的任务调度算法2种实现方法，将节点当前温度考虑到任务调度过程中，以此避免高温对作业执行的影响，提高系统的稳定性。

4.2 算法实现方法

本节主要针对3.2节中MapReduce调度模式中的Step4进行改进，添加任务到资源映射(或任务调度)前对节点温度的考虑，将节点当前温度考虑到任务调度过程中，以此避免高温对作业执行的影响，提高系统的稳定性。温度感知的任务调度算法有以下2种实现机制。

1) 将TaskTracker节点CPU温度信息添加到心跳信息类TaskTrackerStatus中。当JobTracker接受到心跳信息后，进行任务调度前判断该TaskTracker的CPU温度是否超过设定的高温阈值，如果低于高温阈值，则进行正常的调度；否则，不给该TaskTracker分配任务。

2) 配置TaskTracker健康监测脚本。节点健康监控NodeHealthCheckerService线程允许Hadoop管理员配置特定的健康监测脚本，该脚本中可添加任何检查语句作为节点是否健康运行的依据。

4.2.1 基于心跳信息修改的实现方法

基于心跳信息修改的实现方法主要需要修改心跳信息类TaskTrackerStatus及调度器任务分配策略。

1) JobTracker与TaskTracker采用基于pull的通信模型， JobTracker不会主动与TaskTracker进行通信，而是被动等待TaskTracker将当前节点运行时信息(如TaskTracker基本信息、节点资源使用情况、各任务运行状态等)以心跳(heartbeat)的形式封装起来。这些信息都被封装到类TaskTrackerStatus中，该类是可序列化的，TaskTracker每次发送心跳时，必须重新构造一个TaskTrackerStatus对象。

2) Hadoop任务调度器是一个可插拔模块，用户可以自己的实际需求设计调度器，新的调度器需要继承TaskScheduler类。温度感知的调度器进行任务调度前需要从心跳信息中提取出TaskTracker温度信息，判断该TaskTracker的CPU温度是否超过设定的高温阈值，如果低于高温阈值，则进行正常的调度;否则，不给该TaskTracker分配任务。该算法需要在新的调度器中实现，温度感知的任务调度算法如下所示。

算法1 温度感知的任务调度算法

Input:

TaskTrackerStatus/*修改后的心跳信息对象*/

TempThreshold/*高温阈值*/

TaskTracker/*待调度TaskTracker*/

Output:

/*是否分配任务标识*/

Steps:

算法输入参数包括心跳信息、高温阈值与待调度TaskTracker。算法第8)行调用调度器TaskScheduler类中assignTasks函数为待调度的TaskTracker分配新任务。

4.2.2 基于健康监测脚本的实现方法

在Hadoop中，节点健康监控NodeHealthChecker Service线程允许Hadoop管理员配置特定的健康监测脚本，该脚本中可添加任何检查语句作为节点是否健康运行的依据。脚本运行时如果检测到该节点处于不健康状态，将输出以“ERROR”开头的不健康信息。NodeHealthCheckerService线程一方面周期性调用健康监测脚本对节点进行健康检查；另一方面对脚本的输出进行检查，一旦发现脚本输出中出现“ERROR”关键字，此时便认为该节点处于不健康状态，此时该节点将被标记为“unhealthy”并通过心跳告知JobTracker。当JobTracker收到节点“unhealthy”心跳后，将该节点节点加入黑名单中，不再为其分配新的任务。当然，只要该节点上的TaskTracker服务处于活动状态，健康监测脚本则仍处于运行状态，当发现节点重新进入“healthy”状态后，JobTracker会立刻将节点从黑名单中移除，使节点重新进入工作状态。脚本伪代码如下所示。

算法2 健康监测算法

Input:

NodeStatus/*节点状态信息*/

TempThreshold/*高温阈值*/

Output:

/*节点健康状态信息*/

Steps:

算法第2)行判断节点实际温度大于高温阈值，输出错误信息并设置节点健康状态为“unhealthy”;当算法判断出节点温度低于高温阈值后，输出温度正常信息，设置节点健康状态为“healthy”，算法第10)行将节点健康状态信息返回。特别地，需要考虑怎样合理地确定高温阈值(threshold)参数的值，需要考虑集群中每台机器的硬件特点，对每个节点的高温阈值进行个性化设定。一方面要考虑到高温对作业执行的影响，另一方面也需要考虑到高温对节点硬件的损坏可能性。基于健康监测的脚步实现方法相比基于心跳信息修改的实现方法较为简单，不需要修改MapReduce调度源代码。

5 实验评价与比较

5.1 实验环境

项目组搭建了拥有22个同构节点的Hadoop集群实验环境，其中，NameNode与SecondNameNode分别独立为一个节点，其余20节点为DataNode (5RACK×4 DataNode)，实验环境拓扑结构如图3所示。

为了控制实验过程中的Map任务数量，达到控制实验数据的统计与计算量的目的，特将数据块分块大小配置为512 MB，即dfs.block.size=512 MB。单个DataNode节点上Map与Reduce任务Slot资源槽数设置为1，即配置项mapred.tasktracker.map. tasks.maximum=1与mapred.tasktracker.reduce. tasks. maximum=1。能耗数据测量方面，实验采用北电电力监测仪(USB智能版)，数据采样频率设置为1秒/次，各节点能耗数据(包括瞬时功率、电流值、电压值、能耗累加值等)可通过USB接口实时地传输到能耗数据监测机上，实现能耗数据的收集。实验总体环境描述如表1所示。

5.2 高温对任务及能耗的影响分析

为了精确地测量出节点CPU温度对任务运行时间及节点能耗的影响，本实验将WordCount、TeraSort、NuthIndex、-means、PageRank这5种作业调度到配置相同但温度不同的节点上。本实验中涉及到的5种作业参数配置如表2所示。

表1 总体实验环境描述

表2 作业类型说明

按照表3所示配置，将作业所有任务调度到单节点上执行。实验分为2组，一组节点散热良好，CPU温度控制在50℃~75℃之间；另一组节点具有散热故障，CPU温度控制在75℃~90℃之间。实验进行10次后取平均值，分别关注CPU温度对作业完成时间、节点功耗、CPU利用率以及任务的计算能力的影响。

5.2.1 高温对CPU利用率及节点能耗的影响

如表3所示为高温与常温任务执行节点CPU利用率及功耗的对比。从表中对比数据可以看出，在执行相同作业的条件下，高温节点的CPU利用率都高于常温节点，并且，高温节点任务的平均功率都高于常温节点，证明了3.3节中提出的MapReduce能耗模型的正确性。

表3 高温与常温任务执行节点CPU利用率及功耗的对比

表4表明了高温与常温节点CPU利用率及能耗之间的静态特征。为了测量CPU利用率与系统功耗的之间动态性关系，在原WordCount、TeraSort、NuthIndex、-means、PageRank这5种作业的基础上，本实验加入Bayes任务，并通过10台能耗监测仪对作业运行中的所有DataNode节点功耗进行实验采样，利用时间戳关联实时功耗数据与节点CPU利用率。

通过图4可以看出6种作业实时功耗与CPU利用率之间联系紧密；当CPU利用率上升时，能耗上升；当CPU利用率下降时，能耗下降；CPU变化趋势与能耗变化趋势基本一致。事实上，通过图4表明了3.3节中提出的MapReduce能耗模型的可行性。

通过大量的能耗数据分析得出常温与高温条件下的节点功耗与CPU利用率之间的关系(包括理论值与实验值)如图4所示。其中图4(a)表示散热良好的节点，图4(b)表示高温节点，即具有散热故障的节点。实验值取大量测试数据的平均值，如CPU利用率在50%时功耗测试数据为{83.1，85.7，88.4，87.5，89.2，84.7，90.3，83.5，82.4，87.2，82.6， 85.8，86.9，85.1，84.3，88.2，86.1，83.2，88.8， 86.8}，取其平均值85.99为其实验值。实验中本文发现散热良好(常温)的与出现散热故障(高温)的节点功耗存在较大的差异，散热良好的节点静态功耗为[64，65] W，运行时CPU温度稳定在50℃~75℃；而出现散热故障的节点静态功耗为[70，72] W，运行时CPU在75℃~90℃。基于CPU利用率估算的能耗模型的计算方法(式(5)与式(6))，可得出散热良好节点CPU利用率与功耗之间的理论函数为

其中，表示CPU利用率，()表示CPU利用率为时节点的功耗。节点静态功耗为64 W，峰值功耗为110 W，由式(6)得出参数。同样方法可得到出现散热故障的节点CPU利用率与功耗之间的理论函数

(9)

当节点出现散热故障时，节点静态功耗为70 W，峰值功耗为135 W，参数。式(8)、式(9)及图4中所示的CPU与功耗关系曲线与文献[57]中的结论一致，表明本文结论的正确性。

5.2.2 高温对任务计算能力及作业完成时间的影响

如表5所示为高温与常温任务执行节点任务完成时间及计算能力的对比。如表5数据所示，当节点处于高温状态时，5种作业Map阶段与Reduce阶段计算能力都比常温状态时慢，表明过高的节点温度减慢任务的处理速度。高温使节点计算能力下降，会增加作业完成时间。所以，当节点处于高温状态时，5种作业运行时间都不同程度的比常温状态时耗时长。

另外，实验过程中本文发现，当节点CPU温度高于90℃并持续一段时间后，大量节点出现宕机的现象，并且温度越高，宕机的现象越严重。

5.3 算法对作业运行时间及能耗的影响

本实验选取了FIFO和Capacity这2种原作业调度策略(简称Org-FIFO和Org-Capacity)，并在FIFO和Capacity作业调度策略基础上添加了温度感知的功能(简称TempA-FIFO和TempA-Capacity)，在此基础上对本文提出的温度感知的任务调度模型进行实验分析。

本节实验从22节点构成的集群中分离出2组子集群进行对比实验。2组子集群都分别拥有10个节点，并由8个散热良好和2个具有散热故障的节点组成(节点CPU温度始终高于高温阈值)。不同的是，子集群1利用TempA-FIFO及TempA-Capacity调度策略执行表6中的作业 (设置高温阈值为80℃)，而子集群2则采用Org-FIFO及Org-Capacity执行表6中的作业。实验中采用的作业及参数配置如表6所示。

表5 高温与常温任务执行节点任务完成时间及计算能力的对比

表6 作业类型说明

实验分别将表6中作业在2个子集群中运行10次，记录作业运行时间及能耗，取平均值后得到表7中的数据。其中，作业总能耗为各节点在作业运行过程中能耗的总和。实验过程中，算法设置节点CPU温度超过阈值80℃时，该节点将不接受任何任务。在任务分配过程中，集群1中的任务全部分配到CPU温度低于高温阈值的节点上，高于高温阈值的节点始终处于空闲状态。而集群2中，任务则随机分布到集群各节点中。如表7所示为实验作业完成时间及能耗对比数据总表。

图5所示为Org-FIFO与TempA-FIFO调度下的作业完成时间对比，TempA-FIFO较Org-FIFO分别提高作业WordCount、TeraSort、NuthIndex、-means、PageRank及Bayes完成时间30 s、22 s、50 s、17 s、82 s、77 s；提升率分别为3.257%、3.509%、5.995%、3.786%、13.099%、13.775%，作业之间的差异性使各作业的提升率不同。

如图6所示为Org-Capacity与TempA-Capacity调度下的作业完成时间对比。Org-Capacity较TempA-Capacity分别提高作业WordCount、TeraSort、NuthIndex、-means、PageRank及Bayes完成时间51 s、18 s、48 s、19 s、61 s、78 s；提升率分别为5.849%、3.025%、5.79%、4.481%、9.967%、14.773%。

表7 作业完成时间及能耗对比

如图7所示为Org-FIFO与TempA-FIFO作业完成能耗对比。TempA-FIFO相比Org-FIFO (WordCount、TeraSort、NuthIndex、-means、PageRank及Bayes 6种作业)分别节能28 690 J、29 348 J、40 720 J、17 591 J、44 086 J、60 374 J；节能率分别为4.072%、5.633%、6.314%、5.194%、9.413%、13.918%。

如图8所示为Org-Capacity与TempA-Capacity作业完成能耗对比。TempA-Capacity相比Org-Capacity (WordCount、TeraSort、NuthIndex、-means、PageRank及Bayes 6种作业)分别节能58 693 J、41 817 J、89 838 J、19 855 J、34 669 J、70 602 J；节能率分别为8.741%、8.242%、14.106%、5.9%、7.895%、16.978%。

从实验数据可以发现，本文算法对WordCount、TeraSort、NuthIndex及-means 4种作业完成时间及节能效率提升并不明显，而PageRank及Bayes 2种作业有较为明显的提升。实验过程中，发现PageRank及Bayes 2种作业在运行过程中出现高温节点触发推测执行机制概率较其他4种作业高，由此造成作业完成时间及节能效率提升较其他4种作业更为明显。

6 结束语

大数据时代，数据量的高速增长伴随而来的是存储与处理系统规模不断的扩大，使云计算中心的能耗成本不断的提高。节能的分布式任务调度系统成为研究热点。本文通过对已有的MapReduce任务调度模型的深入研究，发现调度系统并不关心拥有空闲资源槽节点当前的温度状态，一旦节点出现空闲资源槽，调度系统就尽最大努力为该节点分配合适的任务。此种调度策略最大程度上增加了系统资源利用率，使大多数作业能够更快地被处理完毕。但实验表明当TaskTracker处于高温状态时，一方面使CPU利用率变高，导致节点能耗增大，任务处理速度下降，导致任务完成时间增加；另一方面，易发的宕机现象将直接导致任务的失败，推测执行机制容易使运行时任务被迫中止。所以本文提出温度感知的节能任务调度策略，将节点CPU温度纳入任务调度的决策信息，以避免少数高温任务执行节点对作业整体进度的影响。算法实现方式上提出了基于心跳信息修改及基于健康监测脚本的2种实现方案。最后，通过搭建真实的实验环境，精确的测量了节点CPU温度对任务运行时间及节点能耗的影响，证明了本文算法对不同类型作业任务完成时间及作业执行能耗两方面的改进。

下一步工作主要是对MapReduce执行能耗进行建模。 MapReduce能耗模型是将来开发Hadoop作业能耗监控及优化软件的理论基础，能耗模型能够实现在作业执行前对能耗进行预测，执行过程中为节能调度系统提供调度依据，执行后对作业进行能耗计算。

[1] 孟小峰, 慈祥. 大数据管理: 概念、技术与挑战[J]. 计算机研究与发展,2013,50(1):146-149. MENG X F, CI X. Big data management: concepts, techniques and challenges[J]. Journal of Computer Research and Development, 2013, 50(1): 146-149.

[2] GANTZ J, CHUTE C, MANFREDIZ A, et al. The diverse and exploding digital universe: an updated forecast of worldwide information growth through[EB/OL]. http://www.ifap.ru/library/ book268.pdf.

[3] Global action plan, an inefficient truth[R/OL]. Global action plan report, 2007. http://globalactionplan.org.uk.

[4] TIMES N Y. Power, pollution and the Internet [EB/OL]. http://www.nytimes.com/2012/09/23/technology/ data-ceneters-waste- vast-amounts-of-energy-belying-industry-image.html.

[5] BARROSO L A, HLZLE U. The datacenter as a computer: an introduction to the design of warehouse-scale machines [R]. Morgan: Synthesis Lectures on Computer Architecture, Morgan & Claypool Publishers, 2009.

[6] BORTHAKU D. The hadoop distributed file system: architecture and design[J]. Hadoop Project Website, 2007, 11(11):1-10.

[7] GHEMAWAT S, GOBIOFF H, LEUNG S T. The google gile system[C]//19th ACM Symposium on Operating System Principles. New York, ACM, c2003: 29-43.

[8] DEAN J, GHEMAWAT S. MapReduce: simplifed data processing on large clusters[C]//The Conference on Operating System Design and Implementation (OSDI). New York, ACM, c2004: 137-150.

[9] 王鹏, 孟丹, 詹剑锋, 等. 数据密集型计算编程模型研究进展[J]. 计算机研究与发展,2010,47(11):1993-2002. WANG P, MENG D, ZHAN JF, et al. Review of programming models for data-Intensive computing[J]. Journal of Computer Research and Development, 2010, 47(11): 1993-2002.

[10] LI D, WANG J E. Energy efficient redundant and inexpensive disk array[C]//The ACM SIGOPS European Workshop. New York, ACM, c2004: 29-35.

[11] 林闯, 田源, 姚敏. 绿色网络和绿色评价: 节能机制、模型和评价[J].计算机学报,2011,34(4):593-612. LIN C, TIAN Y, YAO M. Green network and green evaluation: Mechanism, modeling and evaluation [J]. Chinese Journal of Computers, 2011, 34(4): 593-612.

[12] 廖彬, 于炯, 张陶, 等. 基于分布式文件系统HDFS的节能算法[J]. 计算机学报, 2013, 36(5):1047-1064. LIAO B, YU J, ZHANG T, et al. Energy-efficient algorithms for distributed file system HDFS[J]. Chinese Journal of Computers, 2013, 36(5): 1047-1064.

[13] ALBERS S. Energy-efficient algorithms [J]. Communications of the ACM, 2010, 53(5): 86-96.

[14] WIERMAN A, ANDREW L L, TANG A. Power-aware speed scaling in processor sharing systems[C]//The 28th Conference on Computer Communications (INFOCOM 2009). Piscataway, NJ, c2009: 2007-2015.

[15] ANDREW L L, LIN M, WIERMAN A. Optimality, fairness, and robustness in speed scaling designs[C]//ACM International Conference on Measurement and Modeling of International Computer Systems (SIGMETRICS 2010). New York, ACM, c2010: 37-48.

[16] NEUGEBAUER R, MCAULEY D. Energy is just another resource: energy accounting and energy pricing in the nemesis OS[C]//The 8th IEEE Workshop on Hot Topics in Operating Systems. Piscataway, NJ, c2001: 59-64.

[17] FLINN J, SATYANARAYANAN M. Managing battery lifetime with energy-aware adaptation [J]. ACM Transactions on Computer Systems (TOCS), 2004, 22(2): 179-182.

[18] MEISNER D, GOLD B T, WENISCH T F. PowerNap: eliminating server idle power [J]. ACM SIGPLAN Notices, 2009, 44(3): 205-216.

[19] YE K, JIANG X, YE D, et al. Two optimization mechanisms to improve the isolation property of server consolidation in virtualized multi-core server[C]//The 12th IEEE International Conference on High Performance Computing and Communications. Melbourne, Australia, c2010: 281-288.

[20] CHOI J, GOVINDAN S, JEONG J, et al. Power consumption prediction and power-aware packing in consolidated environments[J]. IEEE Transactions on Computers, c2010, 59(12):1640-1654.

[21] YE K, JIANG X, HUANG D, et al. Live migration of multiple virtual machines with resource reservation in cloud computing environments[C]//The 4th IEEE International Conference on Cloud Computing. Washington, USA, c2011: 267-274.

[22] LIAO X, JIN H, LIU H. Towards a green cluster through dynamic remapping of virtual machines[J]. Future Generation Computer Systems, 2012, 28(2):469-477.

[23] JANG J W, JEON M, KIM H S, et al. Energy reduction in consolidated servers through memory-aware virtual machine scheduling[J]. IEEE Transactions on Computers, 2011, 99(1): 552-564.

[24] WANG X, WANG Y. Coordinating power control and performance management for virtualized server cluster[J]. IEEE Transactions on Parallel and Distributed Systems, 2011, 22(2):245-259.

[25] WANG Y, WNAG X, CHEN M, et al. Partic: power-aware response time control for virtualized web servers[J]. IEEE Transactions on Parallel and Distributed Systems, 2011, 22(2):323-336.

[26] DASGUPTA G, SHARMA A, VERMA A, et al. Workload management for power efficiency in virtualized data-centers[J]. Communications of the ACM, 2011, 54(7): 131-141.

[27] SRIKANTAIAH S, KANSAL A, ZHAO F. Energy aware consolidation for cloud computing [J]. Cluster Computing, 2009, 12(1): 1-15.

[28] GARG S K, YEO C S, ANANDASIVAM A, et al. Environment-conscious scheduling of HPC applications on distributed cloud-oriented data centers [J]. Journal of Parallel and Distributed Computing, 2010, 71(6): 732-749.

[29] KUSIC D, KEPHART J O, HANSON J E, et al. Power and performance management of virtualized computing environments via lookahead control [J]. Cluster Computing, 2009, 12(1): 1-15.

[30] SONG Y, WANG H, LI Y,et alMulti-tiered on-demand resource scheduling for VM-based data center[C]//Proceedings of the 9th IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid 2009). Piscataway, NJ, c2009: 148-155.

[31] GMACH D, ROLIA J, CHERKASOVA L, et al. resource pool management: Reactive versus proactive or let’s be friends [J]. Computer Networks, 2009, 53(17): 2905-2922.

[32] BUYYA R, BELOGLAZOV A, ABAWAJY J. Energy-efficient management of data center resources for cloud computing: a vision, architectural elements, and open challenges[J]. Eprint Arxiv, 2010,12(4): 6-17.

[33] KIM K H, BELOGLAZOV A, BUYYA R. Power-aware provisioning of cloud resources for real-time services[C]//The 7th International Workshop on Middleware for Grids. New York, c2009: 1-6.

[34] 王意洁, 孙伟东, 周松, 等. 云计算环境下分布存储关键技术[J].软件学报,2012,23(4):962-986.

WANG Y J, SUN W D, ZHOU S, et al. Key technologies of distributed storage for cloud computing[J]. Journal of Software, 2012,23(4): 962-986.

[35] GREENAN K M, LONG D D E, MILLER E L, et al. A spin-up saved is energy earned: achieving power-efficient, erasure-coded storage[C]//The HotDep 2008. Berkeley: USENIX Association, c2008:4.

[36] WEDDLE C, OLDHAM M, QIAN J, et al. A gear-shifting power-aware raid[J]. ACM Transactions on Storage, 2007, 3(3): 1553-1569.

[37] LI D, WANG J. Conserving energy in conventional disk based RAID systems[C]//The 3rd Int Workshop on Storage Network Architecture and Parallel I/Os (SNAPI 2005). Piscataway, NJ, c2005: 65-72.

[38] YAO X, WANG J. Rimac: a novel redundancy-based hierarchical cache architecture for energy efficient, high performance storage systems[C]//The EuroSys. New York, ACM, c2006: 249-262.

[39] PINHEIRO E, BIANCHINI R, DUBNICKI C. Exploiting redundancy to conserve energy in storage systems[C]//The SIGMetrics Performance 2006. New York, ACM, c2006: 15-26.

[40] NARAYANAN D, DONNELLY A, ROWSTRON A. Write off-loading: practical power management for enterprise storage[J]. ACM Transactions on Storage (TOS), 2008, 4(3):253-267.

[41] STORER M, GREENAN K, MILLER E, et al. Replacing tape with energy efficient, reliable, disk-based archival storage[C]//The FAST 2008. New York, ACM, c2008: 1-16.

[42] ZHU Q, CHEN Z, TAN L, et al. Hibernator: Helping disk arrays sleep through the winter[C]//The 20th ACM Symposium on Operating Systems Principles (SOSP). New York, ACM, c2005: 177-190.

[43] VASIC N, BARISITS M, SALZGEBER V. Making cluster applications energy-aware[C]//The ACDC 2009. New York, ACM, c2009: 37-42.

[44] 廖彬, 于炯, 孙华, 等. 基于存储结构重配置的分布式存储系统节能算法[J].计算机研究与发展, 2013, 50(1): 3-18. LIAO B, YU J, SUN H, et al. Energy-efficient algorithms for distributed storage system based on data storage structure reconfiguration[J]. Journal of Computer Research and Development, 2013, 50(1): 3-18.

[45] LIAO B, YU J, SUN H, et al. A QoS-aware dynamic data replica deletion strategy for distributed storage systems under cloud computing environments[C]//Cloud and Green Computing (CGC), 2012 Second International Conference. IEEE, c2012: 219-225.

[46] 廖彬, 于炯, 钱育蓉, 等. 基于可用性度量的分布式文件系统节点失效恢复算法[J].计算机科学, 2013, 40(1):144-149.

LIAO B, YU J, QIAN Y R, et al. The node failure recovery algorithm for distributed file system based on measurement of data availability[J].Computer Sicence, 2013, 40(1): 144-149.

[47] ZHU Q, DAVID F M, DEVARAJ C F, et al. Reducing energy consumption of disk storage using power-aware cache management[C]//The HPCA 2004. Piscataway, NJ, c2004: 118-129.

[48] LEVERICH J, KOZYRAKIS C. On the energy (in)efficiency of hadoop clusters [J]. ACM SIGOPS Operating Systems Review, 2010, 44 (1): 61-65.

[49] LANG W, PATEL J M. Energy management for mapreduce clusters[J]. Proceedings of the VLDB Endowment, 2010, 3(1-2): 129-139.

[50] CHEN Y, KEYS L, KATZ R H. Towards energy effcient mapreduce [R]. Berkeley: EECS Department, University of California, 2009-10-9.

[51] WIRTZ T, GE R. Improving MapReduce energy efficiency for computation intensive workloads[C]//Green Computing Conference and Workshops (IGCC). IEEE, c2011: 1-8.

[52] GOIRI Í, LE K, NGUYEN T D, et al. GreenHadoop: leveraging green energy in data-processing frameworks[C]//The 7th ACM european conference on Computer Systems. ACM, c2012: 57-70.

[53] CARDOSA M, SINGH A, PUCHA H, et al. Exploiting Spatio-Temporal Tradeoffs for Energy Efficient MapReduce in the Cloud[D]. Department of Computer Science and Engineering, University of Minnesota, 2010.

[54] CHEN Y, GANAPATHI A, KATZ R H. To compress or not to compress-compute vs. IO tradeoffs for mapreduce energy efficiency[C]//The First ACM SIGCOMM Workshop on Green Networking. New Delhi, India, c2010: 23-28.

[55] 宋杰, 李甜甜, 朱志良, 等. 云数据管理系统能耗基准测试与分析[J]. 计算机学报,2013,36(7):1485-1499.

SONG J, LI T T, ZHU Z L, et al. Benchmarking and analyzing the energy consumption of cloud data management system [J]. Chinese Journal of Computers, 2013, 36(7): 1485-1492.

[56] ANDREWS M, ANTA A F, ZHANG L, et al. Routing for energy minimization in the speed scaling model[C]//The 29th IEEE Conference on Computer Communications (INFOCOM’10). San Diego, USA, c2010: 1-9.

[57] BARROSO L A, HOLZLE U. The case for energy-proportional computing[J]. Computer, 2007, 40(12): 33-37.

[58] 林闯,田源,姚敏.绿色网络和绿色评价:节能机制、模型和评价[J].计算机学报,2011,34(4):593-612.

LIN C, TIAN Y, YAO M. Green network and green evaluation: Mechanism, modeling and evaluation [J]. Chinese Journal of Computers, 2011, 34(4): 593-612.

Temperature aware energy-efficient task scheduling strategies for mapreduce

LIAO Bin1,ZHANG Tao2,YU Jiong3, LIU Ji1,YIN Lu-tong3, GUO Gang3

(1. College of Statistics and Information, Xinjiang University of Finance and Economics, Urumqi 830012, China; 2. Department of Medical Engineering and Technology, Xinjiang Medical University, Urumqi 830011, China; 3. School of Software, Xinjiang University, Urumqi 830008, China)

The main difference among the existing MapReduce task schedulers such as FIFO, Fair, Capacity, LATE and Deadline Constraint is their choice of operation strategy of the queue and job. On the count of the task selection strategies of these task schedulers are basically the same, taking the data-locality as the key factor of selection, they all ignore the current state of the temperature of the TaskTracker. The experiments show that when the TaskTracker is in a state of high temperature it will cause some negative results. On one hand, utilization of the CPU becomes higher, which means more energy is consumed at each node. And as a result of task processing speed dropping off, more time will be needed to complete the same task. On the other hand, the prone downtime phenomenon will directly lead to the failure of the task, and speculative execution mechanism is easy to make the runtime task suspend. Temperature aware energy-efficient task scheduling strategy is put forward to solve the problem. CPU temperature of the node was put into the task scheduling decision-making information to avoid bad impact on the overall progress of the job form the task execution nodes with a high temperature. The experimental results show that the algorithm can avoid allocating task to high temperature nodes, which effectively shorten the job completion time, reduce energy consumption of job execution and improve system stability.

green computing, MapReduce, task scheduling, temperature aware

TP393.09

A

10.11959/j.issn.1000-436x.2016008

2014-10-14；

2015-01-07

国家自然科学基金资助项目(No.61562078, No.61262088, No.71261025); 新疆财经大学博士科研启动基金资助项目(No.2015BS007)

The National Natural Science Foundation of China (No.61562078, No.61262088, No.71261025), The Doctoral Research Foundation of Xinjiang University of Finance and Economics(No.2015BS007)

廖彬（1986-），男，四川内江人，博士，新疆财经大学副教授，主要研究方向为绿色计算、数据库系统理论及数据挖掘等。

张陶（1986-），女，新疆乌鲁木齐人，新疆医科大学讲师，主要研究方向为云计算、医学大数据分析等。

于炯（1964-），男，北京人，博士，新疆大学教授、博士生导师，主要研究方向为网格计算、大数据与云计算等。

刘继（1974-），男，新疆乌鲁木齐人，博士，新疆财经大学教授，主要研究方向为信息管理及数据挖掘。

尹路通（1992-），男，河南信阳人，新疆大学硕士生，主要研究方向为节能计算、大数据计算模式等。

郭刚（1990-），男，新疆乌鲁木齐人，新疆大学硕士生，主要研究方向为节能计算、大数据计算模式等。