首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

今天我们来聊一个很基础的话题:如何执行一条命令

作者简介

运小宇 百度高级研发工程师

负责基础运维组件相关开发工作,致力于运维基础设施的建设,夙兴夜寐,只为提高设备操作的便利性,一桥飞架南北,天堑变通途。

干货概览

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

什么是命令

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

图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 简单问题放大后也变得困难

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

执行高效

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

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

控制灵活

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

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

扩展方便

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

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

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

如何解决

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

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

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180302G1CFAF00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券