云计算时代的自动化运维趋势
发布时间：2022-01-15 17:38:03 所属栏目：云计算 来源：互联网
导读：关于题目云计算时代的自动化运维，用通俗的话讲，就是应用的自动化部署。 云计算时代的自动化运维走向 第一个关键词是自动化，自动化代表高效率、低成本;第二个关键词是应用部署。即，不涉及讲物理基础设施的运维(如机房基建、能源、消防、安保、布线等等)。
|
自动化测试用例覆盖足够全面，我们便有可能实现一台机器从祼机到上线服务全部自动化完成，无人值守。若没有自动化测试，应用部署完成之后，仍然需要人工验证是否满足上线服务的要求。 4.5 工作流 运维代码从开发到上线发挥作用，也应该和应用代码一样遵循下面的工作流： 云计算时代的自动化运维走向 这个流程图只展示了最基本的要求：部署到生产环境前必须经过测试环境验证。更复杂的还有代码reivew、性能测试环境验证、漏洞扫描环境验证、预发环境验证，生产环境分批发布等环节。 很多公司的现状是运维工程师开两个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 私有云的业务间调配 已经投资购置大量硬件的企业，可以在不同内部业务之间调度，比如白天把大多数机器用来为消费者提供服务，晚上缩减承担消费者请求的机器规模，释放出来的计算资源用来做大数据处理。 （编辑：惠州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
