17611538698
webmaster@21cto.com

基于空闲资源的弹性计算实践

资讯 0 2011 2018-03-07 12:02:29
项目背景
 
 
微信,QQ,空间等用户每天上传了海量图片及视频,图片上传下载时需压缩,视频播放前需转码;AI热潮兴起后,围棋,游戏等对弈数据的生成需要大量的计算能力;计算成本逐步成为不可承受之重。同时由于公司业务的多样化,难以均衡用满各类资源;现网服务器主要承载在线业务,有明显的波峰波谷效应;同时设备购买,裁撤,流转形成了大量的短期空闲设备,公司整体资源利用并不充分,故架平虚拟化团队建设了弹性计算平台,致力于挖掘复用现网的空闲资源,以满足当前对海量计算能力的需求。
 
a1.jpg

 
  
关键挑战 
 
复现网的空间资源主要存在2个挑战:
 ➤ 易影响现网在线业务的服务质量,如下图所示:
a2.jpg

 
a3.jpg

 
计算业务可能与在线业务共享cpu执行单元,L1,L2,L3 cache,内存,磁盘,网络等,哪一个环节没控制好,都会影响在线业务的服务质量,比如仅仅L3 cache的冲突,便可能使得计算性能下降60%以上。
 ➤ 挖掘出来的弹性资源本身难以用好,如上图所示,弹性资源非常多样,资源规格不一,可用端口不同等,且资源非常易变,比如资源份额(quota)随在线业务负载变化可能动态调整,影响了在线业务时会立即被清除,业务用好这些资源很难。
  
技术架构 
 
为解决上述挑战,我们设计了弹性计算技术架构下图所示,其中:
 
a4.jpg

 
 
 ➡ 接入层:负责提供服务化接口,包括服务访问,服务配置,镜像管理等;
 ➡ 调度层:通过名字服务屏蔽多样易变资源,实现负载均衡,扩缩容调度,故障调度,错峰调度,灰度变更等能力;
 ➡ 节点层:实现资源隔离,冲突检测,容器管理监控等机制,供上层使用;
下面针对关键挑战详细描述技术解决方案。    
  
避免影响在线业务 
 
本节主要从避免影响在线业务计算容量,计算质量(计算延时),调度延时,故障率等4个方面来分别阐述。
  
避免在线业务容量受影响
 
为保障在线业务的容量,首先要做好业务间合理混搭,如下图所示,消耗CPU资源多,但网络带宽少的,尽量混搭到消耗网络带宽多但CPU空闲的,实现混搭关键点在于提炼合理的性能模型,因为现网业务资源需求差异大,服务器硬件资源规格也不统一,性能模型要能抽象这种差异,用最简单的公式表达出性能特点,弹性计算平台首先通过cpu相对模型来识别是否适合混搭,比如万兆服务器每核配比带宽73M/s,A业务1核跑满消耗100M/s,B业务1核跑满消耗40M/s,那A与B适合1:1混搭;在此基础上再通过规格模型来隔离计算业务,比如用C4-8-100,表示分配给容器业务4核CPU,8GB内存,100GB磁盘。分核心时会综合考虑是否通过超线程共享物理核,设置合理的软硬配额,由于当前内核协议栈对网络及磁盘IO的隔离并不理想,我们主要是通过业务性能模型匹配解决网络及磁盘冲突的问题。
 
a5.jpg

 
 
在线业务有明显的波峰波谷效应,如下图所示,在波谷时有更多的资源容量可让出供给给计算使用,所以我们也广泛应用了错峰调度,在线业务波谷时,比如0点到6点,让出更多的资源给离线计算型业务使用,比如围棋AI的对局演绎。
 
a6.png

 
  
避免在线业务计算延时受影响
 
解决在线业务资源容量保障后,业务计算延时的影响主要来源于指令执行延时:
 
➡计算型指令由硬件执行,时间基本固定(温度影响带来的差异可忽略不计);
➡控制型(主要跳转等)指令主要由业务逻辑本身决定,业务逻辑没优化好时频繁分支预测失败可能造成延时增加;
➡访存型指令:这块由于cpu cache结构,可能造成延时的波动,如下表所示,一级cache访问延时与内存相差了40倍以上,共享时主要影响的是访存指令的延时;
 
 

a7.png

 
 
为监控业务计算延时,我们引入了CPI(cycles-per-instruction)监控,简单来说,CPI = CPU周期数/CPU指令数,CPI放映了业务整体的指令执行延时,如下图所示,通过历史数据可提炼合理的CPI标准值及方差值,监控当前实际值,对比模型来判断业务计算延时是否正常。这个值与业务指令模型(主要是访存指令的比例等)及CPU型号相关,故需区分业务模块及CPU型号建模。 
 
a8.png

 
 
CPI延时变化时,反应了真实的指令执行延时增加,但指令延时的增加不一定对业务有实际影响,所以监控的关键点在于怎么确认实际业务影响,解决误报的问题,我们主要是通过三种办法来解决:
 
➡对接业务延时监控,但业务延时监控精度可能不一致,且可能无便捷的数据访问接口,故这种方案只能在重点业务上采用;
➡增加确认值,比如监控cpu cache miss的次数及计算型业务的cpu利用率,利用这些值来反推计算业务是否影响了在线业务质量;
➡消除监控噪点,比如连续3个点以上延时增加才真正告警处理;
 
检测到CPI异常时,我们会先通过本地动态调整计算业务CPU配额减轻影响,效果不明显时,才会将计算业务调度至其它服务器,先本地调度有利于于避免瞬时的计算毛刺造成频繁的分布式调度。
  
避免在线业务调度延时受影响
 
前面通过资源隔离解决了在线业务计算容量保障问题,通过CPI监控及调度解决了计算质量保障的问题,剩下的便是在线业务调度延时保障了,如下图所示。由于Linux是非抢占内核,默认情况下在线业务获取时间片的时间是无保障的,混搭上计算型业务后,调度延时更不可控,为解决这个问题,我们在内核层面实现了业务优先级调度。

a9.jpg

 
我们通过设置不同docker容器cpu.share的值,将业务优先级传导至内核,指导内核调度,比如默认1024代表普通优先级,4096代表高优先级,3代表低优先级,配置了4096的容器,可抢占配置为3的容器的时间片。应用优先级调度后,在线业务的毛刺(这里为平均延时10倍)点,对比优化前缩减了32.6%,基本与不共享时持平,某场景的优化效果如下表所示。
 
 

a10.png

 
  
避免在线业务故障率提升
 
CPU,网络IO及磁盘IO是可压缩资源,共享时可能使得在线业务延时增加,内存是不可压缩资源,如果冲突,可能导致在线业务或关键系统进程被OOM,而导致业务异常;为解决这个问题,平台与内核结合一起研发了OOM优先级调度,如下图所示:
 
a11.jpg

 
 
➡平台主要解决可预测,持续性的OOM调度,比如平台收到内存不足预警通知时,如果近期内存一直持续上升,会立即调走计算型业务;
➡内核主要解决不可预测,突发性的OOM调度,比如计算型业务或在线业务收到异常业务请求,导致内存突然暴涨时,Kill掉低优先级的计算型业务容器,并给平台发送事件通知,平台做清理善后。
  
用好弹性资源 
 
本节主要从筛选业务提供场景式服务,封装资源的多样与易变性及更上层的服务接口三方面阐述。
  
筛选业务提供场景式服务
 
由于弹性资源的多样易变,短期难以成为通用的计算平台,故结合实际需求选择了图片压缩,视频转码,AI计算,日志计算4个场景,该4个场景总结起来的共同点是单核流量小于10M/s,且业务平台能容忍节点的变动或失效,如下图所示。
 
a12.png

 
 
对于无计算状态的业务,比如图片压缩,弹性计算平台提供服务化接口,接管计算节点的扩缩容,对于有状态的计算,比如视频转码切片,AI计算中间数据缓存,日志计算map/reduce模型等,则提供API接口,让业务自行发起扩缩容等调度。
 
弹性资源由于其特殊性难以保障所有接入业务的计算质量,故我们区分优先级,提供差异化服务,优先保障在线计算型服务质量,如下表所示。
 
 

a13.png

 
  
对业务屏蔽资源的多样与易变性
 
现网弹性资源的多样及易变主要来源于3点:
 
➡可弹性资源规格不一样,比如有些服务器可复用2核,有的可复用4核;
➡ 硬件性能有差异,如下表所示,最好的cpu与最差的cpu性能可差距一倍;
➡计算业务容器可用配额(quota)会随着在线业务负载变化,甚至被销毁;
 

a14.png

 
 
我们采用了CL5名字服务来屏蔽弹性资源的多样易变性,如下图所示,用户只看到服务名字,无须关心背后绑定的资源及权重动态变化,扩缩容,冲突调度,错峰调度,灰度调度时修改资源的绑定,权重调度修改资源的权重,如下表所示:
 
a15.jpg

 
 
权重的设置如下表所示,综合考虑资源规格(核心数),资源能力(性能基准值),可用配额(quota)等设置总权重,并记录单核权重作为负载均衡参考。
 

a16.png

   
 提供更上层的服务接口
 
使用好弹性资源,仍然需要业务了解弹性资源本身,并做适配处理,比如和弹性计算平台API集成,协调可用端口等,使用门槛依然较高,为解决这个问题,我们提供了云函数使用接口,如下图所示,类比S3存储,数据以文件为载体,用户上传下载数据无须关心S3分布,容灾,扩容等;计算以函数为载体,用户提交函数后无须了解函数执行背后的资源调度,容灾,扩缩容等,可更专注于业务逻辑创新。从弹性计算平台孵化出了腾讯云-无服务器云函数,欢迎大家试用。
 
a17.jpg

  
实践的经验教训 
 
在建设弹性计算平台实践过程中,我们有一些经验教训,在这里和大家分享下。
  
提供机制还是策略?
 
➡故事1:A业务利用率扩缩容阈值设置不合理,高峰期保留大量资源没充分利用;B业务设置很合理,高峰期确没资源扩容了。---让用户自身做策略,难以达到整体最优,造成业务间资源利用不均衡,老实人反而容易吃亏;
 
➡故事2:平台默认打开自动扩缩容,自动调配资源;A业务对自动扩缩容机制不知情,发起了版本变更,造成现网多版本共存。---平台来做策略,难以了解完整业务流程,可能影响业务的可用性;
 
在提供机制或策略的选择上我们有过反复,对于平台方,最理想的是将策略控制起来,以达到整体资源调度的最优化,但这里需要一个前提,平台能够收拢所有业务变更入口,如果做不到闭环,只能优先保障业务可用性,平台提供机制,由业务方自身实现策略,平台方通过其它手段,比如定期公布低负载业务,推动业务方主动关注资源高效利用。
  
扩缩容前先要负载均衡
 
扩缩容的目标在于将计算型业务维持在合理的负载,以实现质量和成本的均衡,但如果业务负载不均衡,扩缩容难以达到预期的效果,如下图所示:
 
a18.png

 
➡当业务不均时,同计算业务下不同实例表现为个别实例负载高,以图片压缩为例,出现此场景的一般由于收到大图,此时扩容不能缓解高负载,反而容易导致更多实例空闲;
 
➡当资源性能不均时,同计算业务下不同实例表现为部分实例负载高,出现的原因可能由于CPU性能或在线业务负载差异,此时如果以整体平均负载扩容容易导致部分实例高负载,以前50%实例平均负载扩容,容易导致另一部分实例低负载;
 
最完美的状态是同计算业务下各实例负载波动上下波动不超过5%,此时在扩缩容调度下,整体能保持在较高的负载而不影响服务质量,但这个需要业务和平台方共同努力才能实现:
 
➡对业务方来说,要实现用户请求轻重分离,发送给同业务模块的请求,后台消耗的资源需基本一致,以图片压缩为例,需要业务方做好大小图分离;
 
➡对平台方来说,需要更综合更动态的权重,为计算实例设置权重时,需综合考虑资源规格,硬件性能基准值,动态可用配额等多方面因素。
  
重视底层风险及能力
 
弹性计算依赖底层提供资源隔离,优先级调度等机制,底层的稳定性会影响整个平台的稳定性,且修复代价很大,在弹性计算早期,如下图所示,为了避免平台建设打扰到正常业务运营,规避机房间穿越流量,在容器存储选型上,我们选择了loopback+devicemapper方案,因为此方案无须格式化磁盘。使用之前已了解到社区对此方案的应用存在很多问题,所以打齐了补丁,并采用灰度部署的方式以及时发现并解决问题,在规模不大时,问题并不突出,但上1w台规模,经常现网出现dm设备ioutil 100%, cpu100%等问题,有时需重启才能修复,影响了在线业务的体验。由于loopback+dm机制实现比较复杂,我们对短期内完全修复信心不足,不得已花大代价重新格式化,切换至实现上更简单的XFS+Overlay方案。
 
a19.png

 
 
从这个例子,我们得到的经验是,底层技术要选择最简单,主流,被大家广为认可的,而不是存侥幸心理选择在当前条件下最容易实现的方案。另外由于底层故障修复代价过大,在规模上线前,最好配备热补丁修复能力,以在底层故障出现时低成本的修复问题。
  
结束语 
 
 
感谢大家参加腾讯弹性计算的分享,希望通过此分享能抛砖引玉,能引发一些大家对资源高效利用的思考和实践,当前整个行业大概6%~12%的CPU平均利用率,有较大的提升空间,怎么去提升利用效率,减少对能源的浪费,应该是我们每一位IT从业人员的职责,欢迎大家一起探讨,今后一起提升做到更好。
 


来源:微信架构师
地址:https://mp.weixin.qq.com/s/c-QGtlSF1aTgiqW-euPuPQ


评论