《运维之下》——第四章：服务器资源使用率

服务器数量达到一定规模后，老板们开始担心了：“每季度这么大金额的服务器采购支出，我们的服务器资源使用率如何？”

&＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211; &＃8211;

指标计算

了解资源使用率的前提是记录所拥有的服务器资源以及归属，在服务器采购到位后，就开始跟踪服务器的各项资源指标。但每次老板们问到这个问题时，作为运维人员还是很难直接回答。我们记录了每台机器历史的各项资源使用数据，但如何体现整体的资源使用情况，通过简单的指标表示出来还是比较麻烦的。

首先，我们不能把所有服务器罗列出来，逐台给老板汇报。

其次，每台服务器每天的资源占用情况是随时间，随业务特性动态变化的，需要将CPU、内存、磁盘、IO等每个动态变化的资源指标分别换算成一个值。

例如：一台CPU密集型的服务器，每个时间点访问量的不同，CPU使用率也是不同的，如图4-1所示。

最后，每台服务器每天的平均值，由于高峰期或低峰期的差值很大，均值没有任何参考意义。取每台服务器每天的最大峰值，有时候可能由于某一次数据传输，或者跑一个临时MD5运算导致CPU使用率突增，也不能合理代表这台服务器的CPU使用率。

图4-1  CPU使用率

了解到的业界一般的计算方法是：

◎ 定义每天的业务高峰期为 10:00AM—10:00PM，求这段时间平均值表示该台服务器当天的使用率；

◎ 每天取峰值的3个点，求这3个峰值点的平均值表示该台服务器当天的使用率。

对于定义业务高峰期，然后求平均值，我们认为不够精准，很多业务不一定白天时间达到它的峰值。如果每个业务都个性化定义高峰时间，工作量比较大，管理起来也很麻烦。每天取峰值的3个点求平均值，很多时候人工操作或者临时性的计算很容易把这个峰值提得太高。

经过多次讨论后，确定了下面的计算方法：

（1）每台服务器的CPU、内存、磁盘、IO、网卡数据每2秒钟采集一次；

（2）每天分别取这些数据的TOP n%求平均值。

如图4-2所示为某台服务器某天的监控数据，我们计算出CPU、内存、磁盘和IO的数值如表4-1所示。

图4-2  监控数据

表4-1  资源数值

当然，怎么计算这个资源数值都没有问题，只要是统一的计算模型，能够表示所有机器的资源占用指标即可。我们这么计算是希望能够更接近服务器的平均峰值，消除一些临时性尖峰导致数值较大的问题。

指标展现

完成了资源使用率计算，但如何整体展现所有服务器的资源使用率也是一个问题。由于业务特性的不同，有消耗CPU的，有消耗内存的，也有类似离线存储消耗磁盘空间的，不可能把所有服务器的某项值加起来，然后求平均值，这样说明不了任何问题，而且值会低得可怜。在一个案例中，公司所有服务器每天的CPU值求平均值，CPU使用率只有23%左右。所有人看到这样的数据都会问一句话：“为什么我们的服务器资源使用率这么低？”

对于如何体现公司整体的服务器资源使用率这个问题，我们也没有什么好的方法，不过可以从另外两个维度去体现。

（1）将整个公司这个维度拆解到最小的相同功能集群的粒度，统计和展现这些小集群的资源使用率情况。这个时候就需要结合之前提到过的“服务树”，我们通过服务树将公司的产品划分到产品线->子系统->集群这样的粒度，每个小集群的功能是类似的，这群服务器的资源使用模型也是类似的。研发或运维在提交采购预算时，以最小集群为单位。领导在审批预算时，可以很方便地查看该集群的资源使用情况，决定是否购买。

（2）每月统计出资源使用率不达标的服务器，发给相关的研发主管和运维人员，督促他们尽快利用或者归还资源。比如某个集群每月不达标的服务器数量超过该集群的5%，则认为这个产品线资源使用不达标。

这样侧面解决了如何整体展现公司资源使用率的问题，给出最小集群资源使用率不达标的情况，展现的数据量比较少，而且能够很好地跟进和解决。还可以给出资源使用率不达标服务器和所有服务器的占比曲线，用来观察整个公司服务器资源使用率的变化情况。

这样既满足了工程师需要了解具体信息，执行改进的需求，也满足了老板需要了解整体信息，把握全局的需求。

怎么计算、怎么展现才算合理，每个公司都有自己的做法。当然，在你认为公司整体资源使用率都还不错的情况下，所有服务器的平均值也许可以作为一个基准，用来宏观监控整体资源使用率有没有变好或变坏也是挺不错的。

不达标原因分析

完成上述工作后，我们开展了一次资源使用率未达标服务器原因分析，按照未达标的原因进行了归类。如图4-3所示。

图4-3  资源使用率未达标原因归类

每类原因说明如下：

◎ 灾备：该类型服务器属于对重要服务的备份服务器，平时没有或有很少的流量。

◎ 特殊服务：该类型服务器属于特殊用途需要独占或者多副本存在，如ZooKeeper，或类似博客对外服务又需要安全隔离的业务等。

◎ 服务部署中：服务扩容、搬迁时，暂时未引入业务流量。

◎ 流量未达预期：业务已经在线上运行，但由于流量预估不准确，服务上线后流量和计算量未达到预期。

◎ 开发测试中：新服务小流量运行，处于开发联调阶段。

◎ 测试环境：研发或测试的线下集群，用于压力测试、功能测试等。

◎ 计划下线：服务优化、架构调整、业务功能裁剪等，空闲服务器处于待下线归还状态。

◎ 故障中：服务器故障停止业务，处于维修状态中。

◎ 高峰预留：为了应对比如业务促销活动、特殊节假日等流量高峰，提前储备的服务器资源。

下面分析导致前几类原因出现的问题。

1．业务线预算不准确

◎ 预估的业务流量较大，实际业务流量未达到预期，导致已经上线的服务器资源浪费。

◎ 项目计划不准确，原计划3月份进行新服务上线或者扩容，结果项目延迟到6月份，导致3个月时间的服务器资源闲置。

2．服务器采购效率低，缺少快速伸缩的能力

◎ 随着公司对于服务器需求的数量越来越大，很早以前那种随用随买的模式已经不适合了，转而采用服务器集采的模式，从预算申请，到领导审批、采购招标、供货商送货、服务器上架、系统装机交付等多个环节，在正常情况下会耗时2个月。那么业务部门往往会提前并较多地购买服务器，造成一定时间段的服务器资源浪费。

◎ 为了应对某次突增几倍的业务促销活动流量，需要提前准备服务器资源。当活动结束后，服务器资源的归往往不及时，归还后其他业务部门消化这部分资源的时间也比较长。

◎ 服务器采购时资产是划分到各个部门的。服务器资源归还后，还存在部门间资产更新计算的问题。

3．缺少资源监控平台

缺少资源监控和审查机制，业务部门浪费的机器也不会及时归还。

资源优化

看到这几类原因后，第一时间能够想到的解决方案就是公有云。类似AWS的服务，能够快速地交付或归还虚拟机资源，按时间、按流量收费。虽然大部分业务是可以部署在公有云上的，但还有很多类似HBase、离线计算等对磁盘IO、内网带宽有较高需求的业务，不太适合在虚拟机上部署，成熟公司这部分业务的服务器数量一般占到30%～60%。

先不讨论公有云是否真正省成本，仅就对目前国内云服务商的安全评估，我们还不敢把高敏感、高安全要求的用户数据、现金支付类业务放置在云端。另外，多机房服务冗余、机房间专线互通等各种因素也需要考虑进去。

我们的目标是通过缩短服务器采购周期，资源能够具备快速伸缩的能力，结合预算审批、资源监控等手段，将不达标服务器控制在合理范围内。综合考虑后，可选的解决思路如下：

（1）支持物理机租赁模式，提高服务器交付效率；

（2）支持私有云和公有云的使用，降低物理机的需求；

（3）统一预算平台，限制不达标业务的申请；

（4）资源监控，不达标服务器资源能够及时归还。

作为一些互联网公司，不希望投入过多的资源在固定资产上。运维人员也不愿意投入过多的精力在服务器的采购、上架、维保以及后续的报废处理上。当前已经有很多公有云支持虚拟机和物理机的租赁业务，传统的IDC厂商也陆续提供物理机租赁业务，由他们负责服务器的采购、上架等一系列工作，按照我们要求的时间、地点（IDC、机柜位置等）进行交付。公有云或服务器外包公司提供足够的备机池资源，能够应对我们对于服务器快速伸缩的需求，按照实际租赁时间收费。

成本方面，按照服务器3年淘汰，每次物理机采购实际是预付了3年的使用费用。采用租赁的方式按实际使用时间付费，不需要提前支付未来的费用。对于项目计划不合理、预算不准确、高峰期预留等问题，我们可以通过快速的服务器交付、归还的方式缓解这些问题，将成本支出降到最低。当前，足够的备机池、快速的交付时间是有成本支出的。

预算平台和资源监控的结合，限制和发现那些资源使用率不达标的服务器，督促业务线及时归还资源，减少成本支付。

提升服务器资源使用率还有很多方法，比如服务模块混布、资源闲时利用，这些属于运维可控的范围。另外，研发对于代码和功能的优化，效果往往会更加明显。