如何执行一条命令

干货概览

 

今天我们不聊上层建筑,不聊单机房自愈,也不聊智能运维的暗夜与黎明,今天我们聊一个很基础的话题:如何执行一条命令。许多人看到这,可能觉得这是一个简单至极的问题,事实果真如此吗,别急,下面我们来抽丝剥茧,一探究竟。

 

什么是命令

 

首先回顾一下“命令”的具体含义,发令以使之,谓发令而使其做某事,这是“命令”一词的基础释义。从这里我们可以看命令的三个最基本的要素:命令内容(令)、命令传递(发)、命令执行(使)。如果将这三要素限定在服务器上,它们又是如何运作的呢?

 

图1 windows与linux下的命令

 

命令内容(令)

 

无论是windows还是linux操作系统,都会提供相应的CLI(不要吐槽windows的CLI难用),供使用者交互执行命令或运行批处理脚本。仔细观察,所有命令行都有一个相同的特点:固定词+选项+参数,无出其右。因CLI伴随着操作系统的诞生,且命令行处理又是一个复杂但相似的过程,因此各种语言也都提供了相应的库支持,如C语言提供了getopt/getopt_long等函数,C++的boost提供了Options库,shell中处理此事的是getopts和getopt。

 

命令传递(发)

 

命令传递有两种方式,一种是文件形式,将bat/shell脚本上传到服务器然后执行。另外一种就是交互式,通过telnet/ssh等方式远程连接服务器后,直接在命令行界面执行。虽然从形式上我们将命令传递分为了两种方式,但从本质上来说,服务器上的命令传递,都没有逃脱网络传输这个过程。

 

命令执行(使)

 

对于操作系统来说,命令的执行,其实就是启动一个进程并传递相应的参数,运行完成后得到相应的结果。这里我们并不关心进程如何创建,PBC的结构如何等细节,我们只关心命令进程的启动方式以及结果的获取方式。

 

为什么要执行命令

 

在分布式产品的开发维护过程中,有三个主题是无法绕过的,分别是配置管理、部署升级和监控采集。

 

配置管理

 

配置管理的目标是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲,配置管理是一种标识、组织和控制修改的技术。通常情况下,配置管理都会统一部署配置服务器来同步所有节点的配置。但是在开发测试过程中,总会出现临时修改某个或某一批节点的配置的情况,这时通过人工逐个登录来完成修改显然是不太可能的。

 

部署升级

 

DevOps的概念如今日趋流行,部署升级越发成为开发运维过程中重要的一环,频繁的交互意味着频繁的部署。部署过程可以拆解为两个小的步骤,一是新软件包的上传,二是服务进程的重新启动。服务进程的重新启动不必多说,软件包的上传可能有多种方式,如sftp的集中式,p2p的点对点式等。

 

监控采集

 

软件运维过程需要时刻监控系统及业务软件的运行状态,各种运维决策都是以这些数据为依据进行的。随着自动化运维的发展,很多运维动作都从人工执行变为了自动执行,自动执行的决策过程更是需要采集大量的实时信息(前期文章《百度大规模时序数据存储》中介绍的TSDB就是为了解决这些数据的存储问题而研发的)。监控数据的来源主要分两种,一种是通过业务软件提供的接口直接读取状态数据,另一种是通过日志/进程状态/系统状态等(如使用grep提取日志,通过ps查询进程状态,通过df查询磁盘使用等)方式间接查询。

 

无论是配置管理、部署变更还是监控采集,都有一个共同的目的:控制服务器。在现阶段,要想对服务器进行控制,离不开“在大量服务器上执行命令并收集结果”这一基础能力,这也是今天我们的主题“如何执行一条命令”的意义所在。

 

面临的困难

 

命令行的三要素,也是如何执行一条命令行面对的三个问题,如前文所述,对于单机环境来说,这三个问题在前人的努力下已经被很好的解决。可是如果要在几十万台机器上每天执行几十亿条命令,同时保证时效性,保证执行成功率,保证结果正确收集,保证7*24小时稳定运行,就不是一件简单的事情了。所谓远行无轻担,量大易也难,在构建这样的执行系统的过程中要面临诸多困难,此处举几个突出的例子如下:

 

信息存储问题:为了支持水平扩展,需要高效的内存数据库作为缓存。为了做到执行命令的可追溯、可统计,需要对执行过的命令信息持久化。日均几十亿的热数据,年均上万亿的冷数据,需要仔细选择存储方案。

 

任务调度问题:为了达到在任意多台服务器上执行命令的要求,需要确定何时分发命令、何时回收结果以及怎么样的并发度批量下发。

 

消息传输问题:为了保证命令高效正确送达目标服务器,需要构建一个可靠的命令传输网络,使命令信息在准确送达的前提下保障传输的可靠与高效,毕竟百度的几十万台服务器分布在世界各地。

 

代理执行问题:为了更好的处理权限、单机并发等单机执行问题,需要在目标机构建执行代理,以应对单机的复杂执行环境。

 

图2简单问题放大后也变得困难

 

百度目前拥有分布在世界各地的几十万台服务器,并且随着业务的不断扩张,这个数字还在持续增长,构建一个高效稳定通用可扩展的命令描述、传递、执行系统在这样的环境中有着重要的现实意义。对百度各产品线的用户来说,这样的一个系统,最基础的要求是:执行高效,控制灵活,扩展方便。

 

1.执行高效:

 

单机执行,要求能够达到秒级命令下发/执行/结果收集。

 

集群执行,要求支持同时在10万台服务器上并行执行,同时保证集群中每个机器达到单机执行的性能。

 

2.控制灵活:

 

单机控制,要求支持暂停、取消、重做功能。

 

集群控制,要求支持暂停点功能,也即可以在执行到某台服务器时暂停,等待人工检查确认无问题后可继续执行。

 

3.扩展方便:

 

支持插件,要求支持自定义执行插件,用户可编写自己的插件执行相应操作。

 

支持回调,要求支持自定义用户回调,如任务执行失败调用相应回调接口。

 

除了以上的业务需求外,一个分布式系统的搭建,还要考虑可用性、可扩展性、性能、一致性等方面的硬性要求。

 

如何解决

 

为了解决这个简单的难题,我们设计了如图3所示的百度集群控制系统(Cluster Control System,简称CCS系统),通过分离控制信息与执行信息建立了两级数据模型,结合命令执行及机房部署特点建立了四级传输模型,通过三级守护方式建立了稳定的执行代理,在大规模服务器集群上解决了“命令三要素”问题。

 

图3百度集群控制系统架构

 

截至目前,CCS系统已经部署在全百度的所有机房中,用户可以方便的在任意一台机器上进行秒级命令下发和结果收集,日均承载数亿次来自各产品的接口调用。关于数据模型、传输模型、执行代理这“分布式命令三要素”的设计及应用,我们将在下一篇文章中详细介绍。

 

收藏 评论(2)
分享到:
共2条回复 最后由乐观的徐小小 回复于2019-09-05 02:55
#2 Q1058204131 回复于2019-08-05

棒棒哒

0
#3 乐观的徐小小 回复于2019-09-05

0