e-works数字化企业网  »  文章频道  »  基础信息化  »  企业上云

一名运维者的思考:云计算时代的自动化运维走向

2017/7/12    来源:AIX专家俱乐部    作者:覃健祥      
关键字:运维者  云计算时代  
关于题目“云计算时代的自动化运维”,用通俗的话讲,就是应用的自动化部署。

    很多公司的现状是运维工程师开两个ssh终端,一条命令,先在本地环境跑一下看看效果,成功就拿到线上去跑了。更有甚者,不经过本地验证直接到线上操作了。这主要是因为运维工作没有充分代码化,运维代码没入svn、git仓库。
 
    4.6 图形化界面和IDE
 
    运维领域一直都缺少通用的、高效的图形界面和IDE。这大约有两个原因:
 
    一是需求不强劲。运维编程的复杂度毕竟比应用编程简单好几个数量级。运维日常工作也没有代码化,还有大量的人工操作,所以,运维代码通常像冰糖葫芦一样,一个个脚本虽然串在一起,但大都是个独立的个体,没有那么强的代码组织结构。
 
    二是运维社区极客氛围浓重。就连应用编程领域也只有Java、.NET等语言的用户比较偏爱IDE。在PHP、Python、Perl社区,vim党、emacs党、sublime text党、notepad++党各领风骚。这些党派崇拜的编辑器不同,但有一个共同信仰:不依赖IDE写代码是一个优秀程序员的必备素质。
 
    关于这个问题,我是这样认为的,有高科技能提升编程生活质量,为什么不用用?即使puppet、chef把运维编程体验做到这么好了,我仍然期待运维业界涌现一批Eclipse、AdobeFlash这样的图形界面、IDE。让IDE的高效易用和运维的命令行操作相得益彰。
 
    4.7 运维代码分治
 
    运维界有一句祖训:没有折腾,就没有故障。
 
    但为了快速响应业务需求和提高资源利用率,运维又不得不频繁折腾。有没有什么办法能打破“折腾越多、故障越多”的魔咒?有,分而治之。
 
    分治,就是把风险高的和风险低的分开、重要性高的和不高的分开、简单的和复杂的分开、频繁变动的和不频繁的分开。应用编程领域,大家积极探索和实践的各种架构、框架、模式,归根到底都在做两件事:封装复杂度、隔离变化。
 
    运维架构层的分治,在业界已经非常普遍了,比如应用服务器和数据库服务器分离、交易数据库和用户数据库分离;生产环境和测试环境隔绝。
 
    4.7.1 配置项和逻辑代码分开
 
    其实业界早就在这么做了,puppet的hiera和saltstack的pillar都是做这个用的。
 
    有些运维变更,可能只改变了配置项的值,而并没改变运维代码里的业务逻辑、流程控制。如果只改配置文件,不改运维脚本。发布风险就低了很多,起码不会导致语法错误。
 
    4.7.2 会变动的配置项独立
 
    就像应用开发领域里的模板引擎一样,把配置文件写成模板,模板中包含变量,运维工具或者运维平台解析模板内容,把变量替换成真实的值。
 
    4.7.3 服务发现
 
    将会变动的配置项独立出来动态维护,还可以实现服务发现。以haproxy + etcd + confd为例:
 
    confd就是一个模板引擎,类似Java里有Velocity和Python里的jinja。不同之处是:confd还有自动轮询etcd的能力。使用confd解析和管理haproxy的配置文件,摘录如下:
 
一名运维者的思考:云计算时代的自动化运维走向
 
    跟原生的haproxy配置文件不同,最后三行是confd模板。
 
    etcd是一个KV存储,类似memcached,不同之处是etcd生来就是分布式的,自带高可用和负载均衡的基因,同时还有HTTPRESTful API,存取方便。使用etcd存储后端服务器列表。
 
    当后端有一台nginx服务启动的时候,调etcd的api把这台机器的ip地址写入etcd上的列表。confd轮询etcd时查到这台新加入的机器,便会自己把它加进haproxy的backend server里。
 
    这样便实现了负载均衡集群自动化扩容,下线一台nginx机器亦同此理,先调etcd的api删除某台机器,过一分钟在这台nginx上检测不到流量了再把它下线。
 
    扩容过程中没有修改haproxy的配置,也没有部署haproxy。只是调用了etcd的RESTfulAPI,这个风险就比修改haproxy配置文件再部署上线小多了。
 
    4.8 整合基础设施API
 
    所有的公有云厂商都提供了HTTPOpenAPI,包括国外的aws、azure、gce和国内的阿里云、Ucloud、青云。
 
    市场占有率排名靠前的虚拟化软件商也都有HTTPOpenAPI,包括:VMware、Hyper-V、XenServer、OpenStack。
 
    因此技术上有可能把基础设施提供商的API整合进来,实现虚拟机创建、启动、安装操作系统、联网、执行命令、关机、销毁全生命周期的自动化。
 
    和应用部署脚本不同,调用云厂商的API不能由DSL脚本完成,用bash shell来做也非常不方便。应该用PHP、Java之类的应用编程语言写一个应用来做。
 
    至此,虚拟机和操作系统初始化、应用环境部署、应用软件部署全部都实现了自动化,便可以从零创建一台可上线服务的机器。
 
    4.9 跨厂商跨城市故障转移
 
    实现了部署工作代码化和基础设施API整合之后,便可以自由地跨厂商、跨城市迁移:在不同的机房维持两份相同的数据,每分钟同步。当基础设施发生重大故障难以在短时间内恢复时,可以迅速在另外一个有数据的机房将整套应用自动化部署起来。
 
    4.10 弹性伸缩
 
    几乎每一个给人类访问的网站,其服务器资源利用率都是存在明显峰谷的:
 
    · 有的尖峰是一年出现一次,典型的例子是阿里的双十一。每年11月11日,电商狂欢。大卖家的进销存系统、淘宝生态链上的SaaS服务商(如在线打印快递单、发送短信券码、物流跟踪)的系统压力也跟着猛涨1-2个数量级。他们投资扩容的硬件设备,只有这一天才能充分利用,平时利用率极低。
 
    · 有的尖峰是一天出现一次或者多次,比如唯品会、聚划算的10点秒杀。基本每一个电商都一天多波次的秒杀、抢购。
 
    · 更普遍的是白天高峰、凌晨到清晨低谷。
 
    自动化运维(包括自动购买分配虚拟机、自动部署应用环境、自动部署应用软件、自动测试)使按需调度计算资源成为了可能。实时的弹性伸缩,意味着每天、甚至每分钟都在做扩容、缩容,这必须要靠自动化运维实现。
 
    4.10.1 公有云上的按需采购
 
    主流的公有云计费粒度都已经细到小时(aws、阿里云、Ucloud),有的做到了按分钟(azure、gce),甚至还有按秒计费的(青云)。
 
    对出现频率较低、计划中的尖峰,人工干预,提前做好扩容和缩容预案,以双十一为例,人工设定好11月10日购买一批按小时计费的机器(不是包年包月),到了11月15日释放这些机器,厂商会停止计费。
 
    对出现频率高的尖峰,运维平台智能调度,比如每5秒采样系统资源利用率,达到指定的扩容阈值就自动买机器并自动化部署、测试、上线服务,低于指定的回收阈值就自动下线服务器、通知厂商停止计费。这种适用于部署上线时间极短的服务,特别是无状态、无用户数据的应用服务器。若需要较长的预热时间(如数据库、缓存、搜索引擎),则需要提前扩容,这就要根据历史性能曲线做智能预测了。
 
    按需购买对公有云厂商也有积极意义:
 
    · 从宏观角度讲,用多少买多少,杜绝浪费,提升了全球公有云资源池中的资源利用率,任何提升资源利用率的事情都是有积极正面的。
 
    · 从经济角度讲,公有云按小时售卖的机器单价比包年的贵,如果两种售卖方式都能100%把机器卖出去,按小时计费的总收入更高。
 
    · 目前有的公有云厂商已经出现部分机房物理资源售罄的情况。如果提供实时服务(如电商、支付、新闻、社交)的客户都按需采购,就有可能在闲时把资源释放出来给实时性要求不高的客户(如离线大数据处理、动画渲染)使用。
 
    4.10.2 私有云的业务间调配
 
    已经投资购置大量硬件的企业,可以在不同内部业务之间调度,比如白天把大多数机器用来为消费者提供服务,晚上缩减承担消费者请求的机器规模,释放出来的计算资源用来做大数据处理。
 
责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐