【20年品牌建站】找北京网站建设公司就选新鸿儒/提供北京网站建设报价/北京网站制作/北京网站设计/网站开发、北京网站建设公司电话【010-51267718】有优惠哦!
简体
繁体 简体
我们的服务遍布中国

我们的服务遍布中国
乃至世界

新鸿儒所服务的品牌地域与城市
北京 天津 上海 广州 深圳 香港 厦门 江苏 浙江 山东
重庆 长沙 武汉 成都 西安 宁夏 丽江 青海 云南 乌鲁木齐
黑龙江 内蒙古 河北 ...
新鸿儒服务与合作的全球各地
美国 加拿大 德国 法国 英国 瑞士 意大利 荷兰
印度 日本 韩国 ...

不论你的品牌在何处
我们都可以提供完善的服务与帮助

致电

010-5126 7718

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

发布时间:2018-02-12 浏览:94打印字号:

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


  单块架构


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


  以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,做到一点配置,多点更新。

  (原文来自运维派)

现在就与新鸿儒客服交流

010 - 51267718

您也可进行在线咨询或预约项目顾问
我要预约
在线咨询