自由人
作者自由人2017-06-30 15:40
系统管理员, 电信运营商

云计算时代IT资源扩容的思考

字数 3911阅读 2154评论 0赞 12

利用率达到多少的时候就应该扩容?

近期,我和周围的同事在多个项目中,经常被计划部门或业务部门同事问到的一个问题就是:某某业务系统的服务器、存储资源,乃至整个私有云资源池,利用率达到多少的时候就应该扩容?
这个问题,真不是一两句话能说清楚的。首先,确保业务可用与提升资源利用率这两个出发点就不同;其次,不同的业务系统,难以有“一刀切”的结论;再次,我们很多业务系统都缺乏全面的资源利用率监控数据,很难为分析判断提供技术依据。
不过在这些讨论过程中,我自己逐步意识到:与决定IT资源是否扩容关系最大的,也许并不是你的资源利用率,而是你的扩容速度。

资源扩容是云计算时代的新课题

在运营商传统的通信网络建设中,一套设备或系统的性能或容量,通常相对比较明确。在规划建设阶段根据用户数、话务量等指标估算建设规模,上线后基于网管系统监测忙时利用率,达到一定阈值(例如70%)即启动新一轮扩容。这种建设模式确保了系统的安全运行,在长期的实践中特别是通信业务快速增长的背景下,是被广泛接受的行之有效的手段。
在后来的IT支撑系统建设中,这种模式也被继续沿用。其实许多计划或业务部门的同事其实已经意识到,IT系统合理性能需求估算和容量规划,并没有通信网络那么简单明了。为了尽力确保资源满足业务需求,笔者见过不少估算资源的过程中乘以1.3、再除以0.7之类的冗余算法,甚至还有x86服务器CPU利用率超过50%性能就会不稳定等说法。不过同样因为业务增长快、IT投资盘子总体太小,这种相对粗放式的扩容方式也没有太大问题。
但到了云计算时代,情况不太一样了。一则业务的多样性、技术的演进等都比以前要显著;二则云平台的建设运营部门与业务需求部门有不同的关注点,前者更重视利用率等指标,后者对业务的稳定性更为关注;三则提升资源利用率、降低成本本身也被认为是云平台建设的目标,还有Google、Amazon等互联网公司超高的资源利用率传说作为标杆。因此,IT资源扩容的矛盾、以及合理的判断依据等问题,随着公司内部私有云的建设、运营,必然作为一个新的课题浮现出来。

资源利用率并不直接决定扩容

IT资源或者说云平台是为上层业务服务的,需要满足业务的性能要求。在业务负载(访问量、处理量等)最高的时候,IT资源需要能够提供足够的处理能力,确保相关业务指标(时延、并发用户数等)达到预定要求。如果资源不能或者预计不能满足业务要求,就说明需要扩容了。
从IT资源角度看业务负载的高低,最直接的指标就是资源利用率,如CPU利用率、带宽利用率等等。与高业务负载对应的就是业务的峰值资源利用率,其理论最大值是100%。那么,当前峰值利用率的高低,是不是就是判断是否需要扩容的直接依据呢?其实不是的,下面就是两个反例:
1)当前峰值利用率高不等于一定需要扩容

当前峰值利用率高不等于一定需要扩容。有些业务是离线批处理类型的,在按照预定计划启动批处理任务的时候,其CPU利用率可能接近100%。但是,如果系统完成批处理任务的时间,能够完全满足业务指标要求,就不需要扩容。例如,下图蓝色线条的某业务系统就是属于这种情况:
1.png

1.png

2)当前峰值利用率低不等于一定不需要扩容
当前峰值利用率低不等于一定不需要扩容。 与离线业务不同,在线业务对并发访问数、响应时延等业务指标要求较高,需要更仔细规划资源来满足峰值的业务需求。试想一下,社交平台上的特殊时间、淘宝“双11”、微信春节“红包”的业务负载可能是平时的数倍甚至数十倍,所以就算阿里在每年“双11”之前的峰值利用率只有20%,面对连年刷高的销售额目标,基础设施部门敢不扩容?
2.png

2.png

以上两个反例并不少见,我们还能说,根据峰值利用率是否达到一个阈值就确定是否启动扩容吗?这里的核心不在于这个阈值是40%、70%还是90%,而是这个方法本身就有问题。

决定扩容的核心因素

既然峰值利用率仅仅是一个参考指标,不是扩容的决定因素,那是否扩容到底有什么决定呢?答案应该就是:看业务是否真正受到(或可能受到)影响。
笔者在一次交流过专门请教过为“双11”准备扩容服务器的阿里同事,类似这种扩容,总结起来主要有以下两个核心因素:
尽量准确预测你的下一次业务高峰。业务部门需要预测它出现的时间、需要满足的业务量,相对当前资源最高处理能力的增加幅度等等;
明确满足下一次业务高峰所需要的准备时间。为了应对新的业务需求,技术部门需要有一个协同、全盘的考虑:是否启用新的硬件平台技术?是否对原有软件进行大幅升级?硬件的测试、采购、到货、部署时间,软件的开发、测试、上线部署时间,以及其它可能的技术或非技术因素所消耗的时间。
如果这两个核心因素搞清楚了,扩容就成为自然而然的事情了:以在某一个时间点需要满足的某一个业务需求为目标,倒排工作计划并完成它。当然要明确这两点并不是单一的一个云的运营部门能够搞定的,需要与业务部门详细沟通业务发展预期、优化目前现有的建设采购模式等,这正体现了做云的运营所需要的整体协调性和与业务贴近性。
在这里,你当前的资源峰值利用率是20%还是50%都不重要,是确保业务不受影响的目标决定了你的扩容动作。
所以为什么总是在“双11”之前即使加班加点也要完成扩容,因为一旦过了这一峰值,业务量甚至回落到你扩容前资源就能满足的规模,没有按期完成的扩容就失去了意义。

扩容越快也许你的利用率越高

那么,有没有既能确保满足业务需求,又尽量提高资源利用率的方法呢?其实是有的,那就是尽量加快你的扩容速度。
3.png

3.png

如图是一个典型的例子。因为扩容是为了满足业务预期的需求,实际上就形成了一个阶梯状的资源分布。扩容时间越长,意味着阶梯的每一级越大,与实际业务需求之间的差距也越大,导致资源利用率长期出于低水平。如果缩短扩容时间,一个个小阶梯就更加贴近实际的业务需求,资源利用率也就自然提高了。
这种扩容时间的变化,反过来对于业务的影响实际上是巨大的。试想一下,我们为什么不在家放大量的现金以备不时之需?原因很简单,我们如果需要,可以随时到银行去取、甚至有24小时自助银行。
如果一次扩容需要一年甚至更长时间,面对业务发展的不确定性,任何业务部门都会倾向于早扩容、多扩容。换言之,如果有足够的资源明天就能到位,今天的业务峰值利用率就算用到99%又有何不可呢?
当然,上图只是业务持续增长的情况,对于实际大多数业务的波动情况,与“扩容”相对的就是“缩容”了,但道理是一致的。那业务“缩容”后的资源去了哪里呢?可以用于其它业务,或者作为资源直接销售给你的客户。这就是为什么自有业务使用大量服务器的公司做公有云有优势、以及为什么国内云服务商通常在12月份促销云主机的原因之一吧。

如何缩短扩容时间?

首先是资源集中和池化

云计算将原来业务独占的资源变成共享的池化资源。传统上业务可能觉得把资源抓在自己手上更为放心,但其实不然,因为池化资源能够提供更大的弹性空间,对每个业务更为有利。
对此,我们常举的一个例子就是,假设每个业务实际有100台服务器需求,预估资源时会各自预留30%的备用,最终也仅仅有30台可用;如果资源池有1000台服务器,考虑总体预留10%的资源备用,那么给每个业务可能最多有100台额外可用资源。前者利用率低、承担业务冲击能力差,后者的优势不言自明。
池化不仅是建设问题,更是运营问题,需要从之前的“集中建设”向“统一运营”方向转变。资源不再属于任何一个业务,而应该由专门的部门或技术团队来负责管理,分配和回收并行,以减轻不同业务资源“多寡不均”的问题。

其次是提高资源动态分配和调度的能力

资源集中和池化后,资源平台需要能够提供资源动态分配和调度的能力。这也就是为什么云平台倾向于采用虚拟化、容器等虚拟资源管理技术,为什么推动业务做软硬件解耦、做云化或微服务化改造,为什么推自动化部署甚至在线/离线业务混布等等,核心都是为了让资源池中的资源能够尽量快速、灵活的被各类业务所使用。

再次是合理的资源预留

为了防范可能出现业务量突增的未知风险,资源池应该长期保留一定量的资源预留,并预留紧急扩容预案。如前面所说,因为池化的资源规模足够大,预留资源的比例相对可以减少。
例如,国内某互联网公司大约在全网预留服务器总量的约1%作为机动资源,并且与服务器供应商签约,要求能够随时满足在数日内增加一定量供货的要求。这有点类似于数据中心柴油发电机的做法:数据中心会预留少量的油,但会与加油站签约,8小时内保证送油到场。

最后是采购和建设周期

在之前与某互联网公司交流中,对方说他们目前的服务器采购,已经从之前相对固定的例如半年一次,调整为按需随时启动采购,这也是提高灵活性的措施之一。业务的发展有其自身的时间要求,无论是IT设备集采、或者建设项目,如果错过了这拨再等一年,那业务部门也只能选择早报、多报新建或者扩容资源需求。

总结

我公司IT系统目前仍然非常分散,业务发展很快,资源规模扩张迅速但整体资源利用率低下,希望通过统一的资源利用率指标等要求,来指导资源的扩容的做法可以作为权宜之计,但应该考虑调整优化。因为决定扩容的主要依据往往不是当前的资源利用率,而是业务预期与扩容速度。
云计算的核心目标就是提升IT系统的灵活性,为上层动态按需的提供资源。真正按照云计算模式重构我们的IT系统,有效缩短业务的扩容时间,寻找满足业务需求与提升资源利用率的最佳平衡,或许是破解扩容难题的一种方法。
现在,我们的基础网络业务也开始向IT化、云化方向发展。在新的云化时代,无论是管理还是技术都需要因时而动,构建面向未来的随需应变的灵活的IT技术与管理架构。

文章作者:唐华斌

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

12

添加新评论0 条评论

Ctrl+Enter 发表