文章总述:
本篇文章主要是对cluster-level甚至是datacenter-level的能耗进行了比较详细的分析,数据都是在真实的环境下采集的,使用的节点有5000个,每十分钟采集一次,一共采集了六个月。整篇论文没有提出具体的解决能源分配的方法,只是就一些现在面临的问题进行了分析,并且提出了研究方向
目前面临的问题:
通过对现在cluster及datacenter的特点进行描述,当前nameplate rating一般都要远远大于实际上系统使用的能耗,造成了很大的能源浪费,而且node都具有activity range,当前的负载类型又分为很多种,比如I/O密集型以及计算密集型等一系列的问题
具体的分析和解决方案:
现在因为大规模的互联网服务,所以需要大规模的计算设施,我们将大量的computing infrastructure组成的系统称为:warehouse-sized computing system
有效的power provisioning策略就是决定一个可以让计算设备们都能安全有效的工作的power budget
我们发现即使是在well-tuned的应用中在cluster-level事实最大能源利用率和理论最大能源利用率上也会有7%-16%的gap,在整个datacenter中更会使这个gap增加到40%,我们可以利用这些headroom来增加设备的部署
在cluster-level(thousands of servers)比在rack-level(tens)更能够提高资源的利用率
最后将会讨论我们的能源效率是要面向整个activity range的而不是仅仅面向peak performance level
现在在cluster中,集群的能耗的花费在不断地增加,但是相比较而言硬件的价格处于比较稳定的价格,因此未来可能cluster整个生存期的能耗的使用费用要远远高于cluster本身的费用
只要你知道了在整个datacenter中你需要的每个组件中最大的能源传输能力,那么构建这个datacenter的费用就是固定的了,但是如果你在使用的时候没用充分利用好它的能力,那么你的利用率越低,你的组件的相对的成本就越高;其次能够很好的利用我们的power budget对设备而言也是非常重要的
这是能够提供1MW的Tier-2的datacenter 设备
ATS(automatic tranfer switch):用来实现在Generator和mains之间的自动转换;
UPS(uninterruptible power supply):它与generator一起工作,当main power fail的时候为设备提供power,但是UPS提供short-term back-up,generator提供long-term back-up.
从ATS开始往下有两条路线,是为了容错设置的,下面每一个PDU(power distribution units)都配备一个STS(static transfer switch),其中STS可以在两个路线中得到能量,从而实现uninterrupted supply.
左面的数字是每个单元的power capacity.
一个rack包含10-80个计算节点,一个PDU可以连接20-60的racks
实际上power budget在实际情况中的利用率总是要低的,具体分为以下几个原因:
1.阶段性部署——在一开始的时候就不是为初始的任务来分配power,而是考虑到以后公司的发展,所以新的设备的这一gap将会是非常大的
2.碎片——因为可能增加一个单元就会超过组件的可提供服务的范围,例如一个2.5KW的电路只能够为4个520W的服务器提供power,这样就会造成对电路的利用率的浪费
3.保守的设备评级——Nameplate中的数据表一般就是反应最大的能耗使用情况,而不是根据特定组件的实际上的peak power来设定的,所以说Nameplate 是高估了设备的能耗
4.动态负载——server system的能耗在整个的activity的阶段中不是一成不变的,而是根据数据负载的多少在不断变化的,这就给我们的能耗管理带来了一定的挑战
5.统计因子效应——随着group的不断的增大,large group就更不容易达到peak power了
以上的5点原因中,第4、5两点是其中最主要的原因,在接下来就这两点进行分析(对于能耗的分析,不包括power转换的损耗以及冷却系统的能耗损耗)
我们通过计算power intensive benchmark在这样的机器上的能耗的多少,来作为实际上的server peak power,使用一个模型来对server的实际的能耗的利用率进行估计,并且用数据验证准确性
模型:以CPU的利用率的变化范围来作为整个系统的总体的利用率的变化范围,并且用microbenchmark做为data运行在server(几百个servers)上来看准确率,发现除了有少量的offset外,整体的变化情况与实际的变化情况是吻合的,考虑到一些model没有考虑的设备,比如switch等的影响,所以认为模型是可用的(只有CPU的变化情况是最大的,其他的组件要么是变化情况没有很大,要么就是和CPU的联系相当的密切)
数据采集:数据采集方法的基础架构
由collector采集server上的CPU的利用率的信息,然后把采集到的信息(raw data)储存在central data repository中,然后提交到分析层,分析层根据不同的job所产生的信息进行分类,然后以时间序列来对数据进行存储(分析层使用了Google的MapReduce)
主要选择了三类数据分别代表了大规模服务的三种不同的类型:
Websearch:每个请求都要求有高的请求吞吐量以及非常大的数据处理需求,提供了系统的在线的特征
Webmail:磁盘I/O密集型的互联网请求,但是与time of day有很强的相关性
MapReduce:用来处理大量的offline的批处理作业,使用成百上千台的服务器来处理terabyte的数据,因为是离线的数据,所以对时间没有很大的要求
两个节省能耗的方法:
1.CPU (DVS):当CPU的利用率低于某一个值的时候,就将CPU的能耗降低为总的CPU能耗的一半,而其他组件的能耗保持不变。通过实验发现对于websearch这种计算密集型的负载来说DVS不论在peak power和energy saving上都有很好的影响;但是像webmail和mapreduce这样的负载来说,因为他们是I/O型的对CPU使用很少,所以DVS对这样的负载的作用不是很明显(因为在这里我们使用的是粗粒度的数据(10min),可能对于细粒度的时间来说DVS的作用可能会更好一些)
2.提高non-peak的能源效率:现在idle时的能耗不会低于peak power的50%,在模型中将idle power设置为peak power的10%,其他的参数不变,这样使得能耗得到了很大的提升(但是如何在真是的cluster中实现idle power=10%peak power,还需要人们的继续努力)