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

本文探讨了服务器资源使用率的计算方法与展现形式,并分析了资源使用率未达标的原因,提出了资源优化方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


指标计算


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

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

其次,每台服务器每天的资源占用情况是随时间,随业务特性动态变化的,需要将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

98.12%

内存

73.29%

磁盘

58.69%

IO

29.05%

 

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



指标展现


完成了资源使用率计算,但如何整体展现所有服务器的资源使用率也是一个问题。由于业务特性的不同,有消耗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年的使用费用。采用租赁的方式按实际使用时间付费,不需要提前支付未来的费用。对于项目计划不合理、预算不准确、高峰期预留等问题,我们可以通过快速的服务器交付、归还的方式缓解这些问题,将成本支出降到最低。当前,足够的备机池、快速的交付时间是有成本支出的。


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


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

### Python 自动化运维的学习路径与最佳实践 #### 1. 基础知识准备 学习任何技术之前,都需要打好基础。对于Python自动化运维而言,建议先熟悉Python的基础语法和常用标准库。以下是推荐的内容范围: - **Python基础知识**:变量、数据结构(列表、字典、元组)、控制流语句(if/else, for循环等)、函数定义与调用[^3]。 - **常用标准库**:`os`, `sys`, `pathlib`, `shutil`, `hashlib`, 和 `logging` 是常用的工具类模块,在文件操作、日志记录等方面非常有用[^5]。 #### 2. 运维相关技能提升 除了Python本身的知识外,还需要掌握与其配合使用的其他技术和工具集。具体如下: - **Linux操作系统管理**:理解并熟练使用Linux命令行界面,尤其是像`grep`, `awk`, `sed`, `find`这样的核心命令,它们被称为“Linux四剑客”,能够极大提高工作效率[^2]。 - **Shell脚本编写能力**:虽然Python可以替代部分shell脚本的功能,但在某些场景下,简单的bash/shell脚本仍然是不可或缺的一部分[^4]。 #### 3. 高级Web框架应用 为了构建更复杂的运维解决方案或内部服务门户,可能需要用到现代web开发框架如Django 或 Flask 来创建定制化的应用程序接口(APIs),从而实现远程监控服务器状态等功能[^2]。这里需要注意的是选择合适的框架取决于实际需求——如果追求简洁轻量则偏向Flask;而当项目规模较大且功能复杂时,则更适合采用全面支持的Django架构。 #### 4. 容器编排与云原生技术 随着容器化趋势的发展,了解 Docker 及其生态系统变得尤为重要。它允许开发者打包自己的软件及其依赖项到一个可移植容器中运行于任意环境中而不需担心兼容性问题。此外还包括 Kubernetes (k8s)这样用于自动部署、扩展以及管理容器集群的服务平台也是不可忽视的一环[^2]。 #### 5. 并发处理机制探索 利用并发编程模型可以让程序在同一时间内执行多个任务,这对于需要高效资源利用率的应用尤其重要。Python提供了多种方式来进行多线程或多进程的操作,其中最值得注意的就是`concurrent.futures`模块,它可以简化异步任务调度过程中的许多细节工作[^5]。 #### 推荐学习资源汇总 针对上述各个方面的知识点,整理了一些优质的学习资料供参考: - 【官方文档】始终是最权威的第一手参考资料; - CentOS系列课程可以帮助初学者快速入门linux环境下的各项配置技巧[^4]; - 关于django/flask的具体案例分析可以通过阅读开源项目的源码获得宝贵经验; - 对于想要深入研究docker/k8s的同学来说,“Kubernetes the Hard Way”这本书籍值得一看因为它强调从零开始搭建整个系统而不是单纯依靠图形界面完成设置. ```python import os from pathlib import Path def create_directory(path): """ 创建目录 """ path_obj = Path(path) if not path_obj.exists(): try: path_obj.mkdir(parents=True) print(f"Directory created at {path}") except Exception as e: print(e) create_directory("/tmp/testdir") ``` 以上代码片段展示了如何使用`pathlib`来安全地创建一个新的目录结构实例演示了前面提到过的关于文件系统的操作方法之一。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值