细说自动化运维的前世今生

《细说自动化运维的前世今生》要点：
本文介绍了细说自动化运维的前世今生，希望对您有用。如果有疑问，可以联系我们。

作者介绍：
朱祥磊,山东移动BOSS系统架构师,负责业务支撑系统架构规划和建设.获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项,申请发明专利13项.

系统规模的不断发展以及应用软件架构的发展,推动着自动化运维的演进.因此在说自动化运维之前,需要先说说应用软件架构的发展简史.回顾过去,应用软件架构先后经过了单块架构、多层架构、服务化架构、分布式、微服务架构等：

单块架构

应用软件发展早期,系统规模一般很小,特点是应用功能集中、代码和数据中心化,表现为一个软件发布包,集中部署,各模块运行在同一个进程的应用程序.此时一般几台机器就可以完成全部应用软件功能.

以Web应用程序为例,在Web应用程序开发的早期,由于受到面向过程的思维及设计方式的影响,所有的逻辑代码并没有明显的区分,因此代码之间的调用相互交错,错综复杂.譬如,我们早期使用的ASP、JSP以及PHP,都是将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起,这是我们通常提到的单块架构.

在这种架构下,所需的机器数量很小,完全的scale-up模式,据说IBM公司在上世纪50年代曾经宣称, 全世界只需要5台计算机就够了!

多层架构

为了解决单块架构扩展性差的问题,同时解决代码集中带来的并行开发测试困难等问题,逐步出现了多层架构,把表示层、业务逻辑层、数据访问层适当分离,分别打包部署.如通过实现Model-View-Controller的模式将数据、业务、展现进行分离.还有一种RPC架构,通过远程过程调用实现应用架构分离.

此时每层都独立打包,独立部署于容器和单独的服务器中,应用结构更加复杂但也更加清晰,当然所需的服务器数量就进一步增加了.

服务化架构

多层架构尽管大幅提升了应用的扩展性,但是随着软件和系统规模的不断扩大,垂直应用越来越多,应用之间交互不可避免,此时层间应用接口变得越来越庞大,最终会变得难以管理.通过将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速地相应多变的市场需求,也使不同服务的独立扩展成为可能.

在这种模式下,可以按服务进一步拆分部署,应用可以扩展到更多的机器和容器上.

分布式云化架构

随着业务不断发展,硬件成本的下降,基于X86架构的廉价硬件+分布式软件的模式日趋成熟,得到了大规模应用,分布式服务框架逐渐替代传统的服务化架构,解决了传统服务化的弊端,例如企业集成总线ESB是实体总线,性能线性扩展能力有限,硬件负载均衡器的压力越来越大,不断扩容导致硬件成本增加,随着业务规模的不断增长,传统的数据库、配置中心等逐渐成为单点瓶颈.当然应用也彻底变为了scale-out架构,导致机器和容器数量大幅上升.

微服务架构

微服务架构是对上面分布式云化架构的拓展、服务化的进一步延伸,通过对服务进一步细化,形成微服务,运行于单独的容器平台,可实现云的弹性和敏捷,如弹性伸缩、线上线下一致的环境、提升自动化运维能力等.

别着急,下面再允许我介绍下自动化运维的内容,究竟包含哪些内容?

1、硬件和网络的自动管理

2、云化、虚拟机的自动管理

3、操作系统和软件的自动化安装、配置

4、常规任务(健康检查、安全加固和检查、备份、清理、数据管理、弹性伸缩等)

5、手工任务(容灾切换、应急操作、应用部署和起停……)

6、监控

7、问题诊断

8、可视化

其中1、2、3主要是传统IaaS层关注的工作内容,重点是计算、存储、网络的自动化管理,4到8主要是PaaS层关注的工作内容,IaaS层和PaaS层相互结合,共同完成自动化运维.

好了,终于到正题了,自动化运维前世今生来了…..

1、史前时代：此时系统规模很小,一般几台,不超过几十台,此时一般通过手工单台登录即可满足运维要求.
2、中世纪时代(集中管理阶段)：系统规模有了较大扩展,从几十台到上百台,此时再通过手工方式已经无法进行,于是出现了各种Shell脚本,通过脚本实现相关的运维,脚本仅仅是针对特定的场景,难以实现全流程的自动化.
3、中世纪拓展(集中管理的进阶)：为了方便管理以及可视化,出现了各类商用或开源工具软件实现自动化运维,如HP Openview、puppet、SaltStack、Chef等等,做为脚本方式的提升.
4、新时代：系统规模进一步扩大,从上百台演进到上千上万台,以前的方式由于存在弊端,如缺乏统一的CMDB或太简单、不支持复杂环境、缺乏友好的可视化界面等,难以满足要求,此时又出现了几个分枝：
分枝一：从底向上的云平台方案：通过云管理平台实现计算、网络、存储的IaaS层自动化管理,同步建立软件PaaS层自动管理,最终实现融合.
分枝二：从上向下的云平台方案：通过上层PaaS层自动化管理,逐步向下探索,如容器等.

新生代自动化运维初探

下面重点介绍几个自动化运维工具或平台：

Openstack

Openstack是IaaS层目前最活跃的一个开源的云计算 IaaS 平台,即云操作系统,类似于AWS(亚马逊的云服务),通过各种开源组件实现了不同功能,目前大部分云管理平台均基于Openstack实现计算、网络、存储的统一管理,Openstack支持如下功能组件：

计算服务(Nova)：按需提供计算资源,创建和管理批量虚拟机 ,动态虚拟机管理：创建、重启、调整大小、迁移等.
对象存储服务(Swift)：基于普通硬件的大规模存储,无中心节点,分布式存储、水平扩展,同时多数据备份,保证安全,通过API接口对外访问.
块存储服务(Cinder)：为虚拟机提供云硬盘.
网络服务(Neutron)：为虚拟机提供网络访问能力.
编排服务(Heat)：提供自动化部署及管理服务.
数据库服务(Trove)：提供数据库管理服务.
认证服务(Keystone)：提供身份认证机制服务.
镜像服务(Glance)：提供虚拟机镜像存储服务.
监控服务(Ceilometer)：提供计量与监控服务.
Dashboard(Horizon)：自服务、权限、图形化界面.

Openstack尽管对IaaS层的自动化管理比较强大,但仍然需要注意如下几点：

1、Openstack版本众多,如何选择是一个难题.

例如存在社区版、发行版、商业公司定制版本等,如何选择是一个难题,而且Openstack每半年一个稳定版本,演进很快.一般认为对Openstack项目中的开源代码进行修改定制是个不错的主意,但这从长期角度来看不一定最佳.“定制云”很可能需要付出高昂的代价,不仅投资巨大、成本高昂,企业用户还将被迫面对一大堆后续的管理及维护开销,并被绑定在单一供应商或版本身上.

建议企业如果有很强的技术能力的话,可以根据自己的需求做定制,但需要把握好和社区发展的关系. 一般来说,需要根据自己的需求,选择合适的版本,尽量不改变社区版本,定制化需求尽量在外围进行改动.如果采用了厂商的版本,实际上也是某种绑定,可能离社区越来越远.

2、需要慎重选择相关组件合功能

由于Openstack理念是分布式、最终一致性,因此所有的原始功能组件都是基于这一设计,企业用户考虑采纳Openstack之前,必须对企业业务应用进行分析：应用程序是否有可扩展性和弹性伸缩的要求? 应用程序是否可以接受最终一致性? 应用程序是否无状态化? 应用程序的性能要求?应用程序的可靠性要求? 应用程序的安全要求? 应用程序的容灾备份需求? 不同的要求决定了Openstack不同的计算、存储、网络等模块设计.

3、Openstack对PaaS层和物理机管理较弱,需借助其他工具实现

Openstack已经能够支持很多的IaaS自动化运维和部分PaaS自动化运维任务,但不能满足全部,如批量运维、深入监控、软件管理等功能缺少,特别是对物理机运维较弱,一般需要结合其他PaaS层管理进一步完善自动化运维体系.

SaltStack+定制

PaaS层自动化运维工具就太多了,例如监控就有Nagios、Ganglia、Zabbix等,运维工具则有Puppet、Chef、SaltStack、Ansible等,不同企业根据企业自身开发实力、结合配置管理工具的资源丰富程度、依赖复杂程度考虑,会有不同的选择.通过对运维工具本身的研究,结合运维人员的运维经验和评估企业未来的规模,下面以开源SaltStack+定制实现的方案进行介绍.

SaltStack是继 Puppet、Chef 之后新出现的S配置管理及远程执行工具,与 Puppet 相比,SaltStack较为轻量；不像 Puppet有一套自己的 DSL 用来写配置,SaltStack 使用 YAML 作为配置文件格式,相对简单,同时也便于动态生成；此外,SaltStack 在远程执行命令时的速度快,由于使用了ZeroMQ,这个下发过程可以并行执行,速度比Ansible的无agent ssh通信快得多,是一个分布式远程执行系统,用来在远程节点(可以是单个节点,也可以是任意规则挑选出来的节点)上执行命令和查询数据.

从部署结构上看,SaltStack的在部署上可以分为master和minion两个部分,其中master相当于统领所有机器的总管,而minion则是部署在被管理机器上面的agent进程,master通过网络将配置管理相关的操作下发到minion,由minion在对应机器的本地执行.典型的部署例子如下图所示：

在现实生产环境中,大批量的用户创建需求,文件上传需求、配置变更需求、软件升级需求占用了维护人员大量的时间,引入SaltStack后,该工具的远程执行和配置管理可以解决该问题,真正实现批量化和自动化,满足海量运维的需求.

容器

有了Openstack和SaltStack为代表的的PaaS层自动化工具还不够,针对应用自动化运维场景,如弹性伸缩、DevOps(开发运维一体化、开发测试一致的环境、自动资源调度、应用日志统一管控、应用服务的编排、微服务管理等),此时出现了容器技术,容器技术实现有很多种,但最流行的是Docker.

传统容器技术相较虚拟机优势不是特别大.Docker能够流行一大重要因此就是它的创新–Docker镜像.Docker构建了一整套构建、发布、运行体系：容器(Container)、仓库(Repository)、镜像(Images).传统容器只解决了容器运行(run)的问题.而Docker定义了一套容器构建(build)分发(ship)的标准,使应用管理非常便捷,尤其适合微服务管理.

注意容器对应用有特定的要求,并不是所有应用都适合,例如需要无状态化、镜像文件不能太大等.

自动化运维需要注意的几点：
​
一般的自动化运维工具均缺乏良好的可视化界面,需要进行结合定制开发.良好的界面可以更易于在企业内部推广自动化运维.
自动化运维工具众多,各有所长,应结合熟悉程度、技术特点进行针对性选择.
多层的自动化管理工具,多头的配置管理是个难题,建议考虑定制化,设计统一的CMDB,做到一点配置,多点更新.

Ok,本文就到这里,由于自动化运维是个很大的话题,涉及话题很大很广,这次仅仅是答题的概述,后续将结合专题进行细化讨论.

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4355.html