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

互联网上有两大主要元素”内容和眼球”,”内容”是互联网公司(或称ICP)提供的网络服务,如网页、游戏、即时通信等,”眼球”则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中,越来越多的”眼球”在盯着ICP所提供的内容,互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验,互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务,并为业务模块间的通信建立IDC内部网络、城域网和广域网,同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长,运维部门也显得愈发重要。他们经过这些年的积累,逐步形成了高效的运维体系。本文将结合国内互联网公司的经验,重点针对IT基础设施的新一代自动化运维体系展开讨论。

互联网上有两大主要元素”内容和眼球”,”内容”是互联网公司(或称ICP)提供的网络服务,如网页、游戏、即时通信等,”眼球”则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中,越来越多的”眼球”在盯着ICP所提供的内容,互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验,互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务,并为业务模块间的通信建立IDC内部网络、城域网和广域网,同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长,运维部门也显得愈发重要。他们经过这些年的积累,逐步形成了高效的运维体系。本文将结合国内互联网公司的经验,重点针对IT基础设施的新一代自动化运维体系展开讨论。

<<互联网敏捷DevOps和自动化之4.运维自动化>>

一、运维的三个阶段

一、运维的三个阶段

威尼斯人娱乐场官网 1

威尼斯人娱乐场官网 1

随着信息时代突飞猛进般的持续发展,IT运维已经成为IT服务中最重要的组成部分。近年来,云计算、大数据等技术日趋成熟,生产应用自动化运维也被推到了风口浪尖。通过传统手段对大型计算机集群进行运维即使是简单的日常备份、服务器状态监控和报警,效率也十分低下,因此对自动化运维的需求已经迫在眉睫。
传统运维的弊端:
1.由人来发起运维事件,运维人员被动、效率低。
2.系统异构性大,缺乏高效的运维流程。
威尼斯真人娱乐,3.随着云计算大数据的爆发带来更大的困难,极度缺乏一套高效的运维工具。
由于这些问题的存在,自动化应该遵循四化原则:管理体系化、工作流程化、人员专业化、任务自动化。
以监控作为自动化运维的核心概念
运维工作效率不高,主要原因是响应速度。由于大量的人员长期盯着报警页面,等待故障,然后通知相应人员。所以在生产系统中,需将服务器的状态监控作为自动化运维的核心问题。下图为自动化运维平台处理流程图,由监控来驱动运维事件的发起、处理和结束,由ElkStack
、Zabbix 和
Zabbix-Agent来获取到服务器的日常工作状态和服务信息,并生成时序统计图等用于成果分析。

● 第一个阶段:人人皆运维

● 第一个阶段:人人皆运维

关于题目“云计算时代的自动化运维”,用通俗的话讲,就是应用的自动化部署。

关于题目“云计算时代的自动化运维”,用通俗的话讲,就是应用的自动化部署。

威尼斯人娱乐场官网 3

在早期,一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模),不一定有专门的运维人员或部门,运维的工作分担在各类岗位中。研发人员拥有服务器权限,自己维护和管理线上代码及业务。

在早期,一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模),不一定有专门的运维人员或部门,运维的工作分担在各类岗位中。研发人员拥有服务器权限,自己维护和管理线上代码及业务。

第一个关键词是自动化,自动化代表高效率、低成本;第二个关键词是应用部署。即,不涉及讲物理基础设施的运维(如机房基建、能源、消防、安保、布线等等)。

第一个关键词是自动化,自动化代表高效率、低成本;第二个关键词是应用部署。即,不涉及讲物理基础设施的运维(如机房基建、能源、消防、安保、布线等等)。

● 第二个阶段:纵向自动化

● 第二个阶段:纵向自动化

假设一个企业要做一个电商网站,典型的运维流程是这样:

假设一个企业要做一个电商网站,典型的运维流程是这样:

互联网公司的运维部署架构 基本都是以下模式

随着业务量的增长,IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模),开始有专门的运维人员,从事日常的安装维护工作,扮演”救火队员”,收告警,有运维规范,但运维主要还是为研发提供后置服务。

随着业务量的增长,IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模),开始有专门的运维人员,从事日常的安装维护工作,扮演”救火队员”,收告警,有运维规范,但运维主要还是为研发提供后置服务。

1.
购买硬件设备:服务器、交换机。可能还有路由器、负载均衡器、防火墙,不一一穷举了。

1.
购买硬件设备:服务器、交换机。可能还有路由器、负载均衡器、防火墙,不一一穷举了。

威尼斯人娱乐场官网 4

这个阶段已经开始逐步向流程化处理进行过渡,运维部门开始输出常见问题处理的清单,有了自己业务范围适用的自动化脚本,开始利用开源软件的拼装完成大部分的工作。

这个阶段已经开始逐步向流程化处理进行过渡,运维部门开始输出常见问题处理的清单,有了自己业务范围适用的自动化脚本,开始利用开源软件的拼装完成大部分的工作。

  1. 在服务器上安装操作系统

  2. 在服务器上安装配置基础环境(数据库、Web服务器、搜索引擎等)

  3. 在服务器上安装配置应用软件(用Java、PHP开发的电商软件)

  4. 把硬件设备送进机房托管,开通公网访问

  5. 监控运维中的业务,并做日常备份、扩容/缩容、迁移、升级

  1. 在服务器上安装操作系统

  2. 在服务器上安装配置基础环境(数据库、Web服务器、搜索引擎等)

  3. 在服务器上安装配置应用软件(用Java、PHP开发的电商软件)

  4. 把硬件设备送进机房托管,开通公网访问

  5. 监控运维中的业务,并做日常备份、扩容/缩容、迁移、升级

image.png

具体表现为:各产品线有自己编写的脚本,利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。

具体表现为:各产品线有自己编写的脚本,利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。

如果是使用公有云,则没有第1,2,5步,直接购买公有云的虚拟机、容器、平台服务(文件存储、关系数据库、内容分发等)

如果是使用公有云,则没有第1,2,5步,直接购买公有云的虚拟机、容器、平台服务(文件存储、关系数据库、内容分发等)

结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:一、支持混合云的CMDB现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。
CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。。。
二、比较完备的监控+应用性能分析(APM)能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。
现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。
开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。
而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。APM这方面的商业工具,国外比较主流的有New
Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
三、有一个还不错UI的批量运维工具在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。
现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。
我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。ansible有官方的web
ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB
UI。
四、日志集中分析工具线上系统最常规的问题定位方式,就是日志分析了。随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。
国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。另外还有一家log
insight,也是做这个领域,但产品好像还处于beta阶段。
日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。
比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。Sentry的官网在此:[Sentry

● 第三阶段:一切皆自动

● 第三阶段:一切皆自动

应用环境和应用软件部署是指第3步和第4步。

应用环境和应用软件部署是指第3步和第4步。

  • Track exceptions with modern error logging for JavaScript, Python,
    Ruby, Java, and
    Node.js**]()
    五、持续集成和发布工具这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。
    而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN来完成文件的上传、分发、版本管理、回滚等各种操作。
    六、安全漏洞扫描工具现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。安全工具方面我了解不多,不太熟这个领域的开源工具。
    Git Web Portal URL address —>
    GOGS
    http://www.jianshu.com/p/424627516ef6
    https://gogs.io/

在互联网化的大潮中,越来越多的黑马团队应运而生,都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中,ICP的互联网基础服务设施是否能够很好的跟进,直接决定了业务内容能否满足海量用户的并发访问。

在互联网化的大潮中,越来越多的黑马团队应运而生,都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中,ICP的互联网基础服务设施是否能够很好的跟进,直接决定了业务内容能否满足海量用户的并发访问。

1 操作系统自动化部署

1 操作系统自动化部署

威尼斯人娱乐场官网 5

与此同时,运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队,有一套或多套自动化运维系统可供参照,运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

与此同时,运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队,有一套或多套自动化运维系统可供参照,运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

第2步是物理祼机的部署,现在市面上的主流服务器,都支持IPMI管理,通电接上管理端口就可以完成BIOS设置,再辅以DHCP,
TFTP, KickStart可以实现无人值守的自动化安装操作系统。

第2步是物理祼机的部署,现在市面上的主流服务器,都支持IPMI管理,通电接上管理端口就可以完成BIOS设置,再辅以DHCP,
TFTP, KickStart可以实现无人值守的自动化安装操作系统。

image.png

威尼斯人娱乐场官网 6

威尼斯人娱乐场官网 7

目前虚拟化、私有云、公有云已经相当普及,除了一些对特殊硬件有要求的场合,和一些历史遗留场合,其它大部分场合都可以用虚拟机,物理机上安装的是宿主操作系统,应用软件装在虚拟机里,这样物理祼机就只需要安装宿主操作系统,需求相对简单,没有应用部署那么复杂。装完之后不会经常去改动,运行稳定。

目前虚拟化、私有云、公有云已经相当普及,除了一些对特殊硬件有要求的场合,和一些历史遗留场合,其它大部分场合都可以用虚拟机,物理机上安装的是宿主操作系统,应用软件装在虚拟机里,这样物理祼机就只需要安装宿主操作系统,需求相对简单,没有应用部署那么复杂。装完之后不会经常去改动,运行稳定。

威尼斯人娱乐场官网 8

图1.大型互联网公司IT基础设施情况概览

图1.大型互联网公司IT基础设施情况概览

2 应用部署

2 应用部署

image.png

二、BAT(百度、阿里、腾讯)运维系统的分析

二、BAT(百度、阿里、腾讯)运维系统的分析

与操作系统部署相比,应用部署复杂性高得多,主要表现在:

与操作系统部署相比,应用部署复杂性高得多,主要表现在:

威尼斯人娱乐场官网 9

国内的互联网公司百度、阿里、腾讯(以下简称:BAT)所提供的主要业务内容不同,IT架构不同,运维系统在发展过程中有不同的关注点。

国内的互联网公司百度、阿里、腾讯(以下简称:BAT)所提供的主要业务内容不同,IT架构不同,运维系统在发展过程中有不同的关注点。

· 场景繁多

· 场景繁多

image.png

1.腾讯运维:基于ITIL的运维服务管理

1.腾讯运维:基于ITIL的运维服务管理

一个小型的B2C网站,有负载均衡器、Web服务器、应用服务器、缓存服务器、搜索引擎、分布式文件系统、监制中心、日志中心、VPN服务器等十多种服务器角色

一个小型的B2C网站,有负载均衡器、Web服务器、应用服务器、缓存服务器、搜索引擎、分布式文件系统、监制中心、日志中心、VPN服务器等十多种服务器角色

威尼斯人娱乐场官网 10

预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功,目前正在进行自动化验收的工作。在网络设备方面,后续将实现从需求端开始的全自动化工作:设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功,目前正在进行自动化验收的工作。在网络设备方面,后续将实现从需求端开始的全自动化工作:设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

· 依赖复杂

· 依赖复杂

image.png

威尼斯人娱乐场官网 11

威尼斯人娱乐场官网 12

软件包之间有依赖,服务器之间有通信依赖

软件包之间有依赖,服务器之间有通信依赖

威尼斯人娱乐场官网 13

图2.腾讯基于ITIL的运维服务管理

图2.腾讯基于ITIL的运维服务管理

· 配置各异

· 配置各异

image.png

2.阿里运维系统:基于CMDB的基础设施管理+逻辑分层建模

2.阿里运维系统:基于CMDB的基础设施管理+逻辑分层建模

除标准的ini,xml, yaml, json, properties文件外,iptables, sysctl, nginx,
haproxy,
pptpd等都有自己独特的配置文件格式,多达上百种。文档描述和运维脚本编写都有相当大的难度。

除标准的ini,xml, yaml, json, properties文件外,iptables, sysctl, nginx,
haproxy,
pptpd等都有自己独特的配置文件格式,多达上百种。文档描述和运维脚本编写都有相当大的难度。

GITLAB
https://about.gitlab.com/gitlab-com/

CMDB(Configuration Management Database)
配置管理数据库(以下简称:CMDB),将IT基础架构的所有组件存储为配置项,维护每个配置项的详细数据,维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库,CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时,CMDB与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中,CMDB常常被认为是构建其它ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。

CMDB(Configuration Management Database)
配置管理数据库(以下简称:CMDB),将IT基础架构的所有组件存储为配置项,维护每个配置项的详细数据,维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库,CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时,CMDB与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中,CMDB常常被认为是构建其它ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。

3 应用部署技术发展历程

3 应用部署技术发展历程

威尼斯人娱乐场官网 14

3.百度自动化运维:部署+监控+业务系统+关联关系

3.百度自动化运维:部署+监控+业务系统+关联关系

下面以在CentOS上安装nginx为例,回顾一下应用部署技术的发展历程:

下面以在CentOS上安装nginx为例,回顾一下应用部署技术的发展历程:

威尼斯人娱乐场官网,image.png

百度主要面临的运维挑战包括:突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为,当服务器规模达到上万台时,运维视角需要转为以服务为粒度。万台并不等于”百台*100″;机器的运行状态,也不再代表业务的工作状态;运维部门为研发提供前置服务,服务与服务之间关系也随着集群的扩大逐渐复杂起来。

百度主要面临的运维挑战包括:突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为,当服务器规模达到上万台时,运维视角需要转为以服务为粒度。万台并不等于”百台*100″;机器的运行状态,也不再代表业务的工作状态;运维部门为研发提供前置服务,服务与服务之间关系也随着集群的扩大逐渐复杂起来。

3.1 手工安装配置

3.1 手工安装配置

威尼斯人娱乐场官网 15

威尼斯人娱乐场官网 16

这是最古老的部署方式,直到今天也被广大小规模团队广泛采用。部署过程往往会产生这样一份文档供日后参考:

这是最古老的部署方式,直到今天也被广大小规模团队广泛采用。部署过程往往会产生这样一份文档供日后参考:

图3.百度自动化运维技术框架

图3.百度自动化运维技术框架

威尼斯人娱乐场官网 17

威尼斯人娱乐场官网 17

百度的自动化运维技术框架,划分为部署、监控、业务系统、关联关系四大部分,整个框架更多突出了业务与IT基础设施的融合,注重”关联关系”的联动。所谓关联关系,主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系,分别对应到任务调度、数据传输、资源定位的服务流程中,形成了多条服务链。

百度的自动化运维技术框架,划分为部署、监控、业务系统、关联关系四大部分,整个框架更多突出了业务与IT基础设施的融合,注重”关联关系”的联动。所谓关联关系,主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系,分别对应到任务调度、数据传输、资源定位的服务流程中,形成了多条服务链。

3.1.1 优点

3.1.1 优点

关联关系的运维与业务较强相关,需要有一套系统能够理清楚关系的全貌,从而在复杂的服务链上,定位运行所在的环节,并在发生故障时预估影响范围,及时定位并通知相应的部门。在这样的一套系统中,自动化监控系统非常重要。百度的技术监控框架,主要通过数据采集、服务探测、第三方进行信息收集,进行监控评估后交给数据处理和报警联动模块处理,通过API接口进行功能扩充(如图4所示)。

关联关系的运维与业务较强相关,需要有一套系统能够理清楚关系的全貌,从而在复杂的服务链上,定位运行所在的环节,并在发生故障时预估影响范围,及时定位并通知相应的部门。在这样的一套系统中,自动化监控系统非常重要。百度的技术监控框架,主要通过数据采集、服务探测、第三方进行信息收集,进行监控评估后交给数据处理和报警联动模块处理,通过API接口进行功能扩充(如图4所示)。

3.1.1.1 灵活性高

3.1.1.1 灵活性高

威尼斯人娱乐场官网 19

威尼斯人娱乐场官网 20

可以安装任何想要的版本,启用任何想要的模块(包括自行开发的私有模块)

可以安装任何想要的版本,启用任何想要的模块(包括自行开发的私有模块)

图4.百度自动化技术监控框架

图4.百度自动化技术监控框架

3.1.1.2 学习门槛低

3.1.1.2 学习门槛低

其实无论是BAT等互联网企业还是其他行业的企业,在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践,采用自动化IT管理解决方案以实现重要的业务目标,如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL
v3.0的发布和推广,两者已经成为事实上的某种标准。在当今企业IT管理领域,对两个标准有着很迫切的需求。特别是ISO20000的认证要求,已经成为企业越来越普遍的需求
。ITIL
v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理,相关方案往往覆盖了多个领域和多个产品,规划实施和工具的选择会比较纠结。如果选择开源的工具,从CMDB开始就会遇到很多的开发工作,对于很多注重成本收益比的企业,可以参考,但由于无法保证性能与效果并不一定适用。因此,成熟的商业方案会是更好的选择。

文档是自然语言写成,阅读和书写都很简单,不需要额外学习其它技术语言。安装配置用到的工具、命令也较少,主要是网络下载、解压缩、编译、文本编辑几种,容易掌握。

文档是自然语言写成,阅读和书写都很简单,不需要额外学习其它技术语言。安装配置用到的工具、命令也较少,主要是网络下载、解压缩、编译、文本编辑几种,容易掌握。

最新的iMC
V7版本,围绕资源、用户、业务三个维度进行创新,发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件,增加了对服务器的管理,能很好的满足更多互联网化的场景需求。

3.1.2 缺点

3.1.2 缺点

通常认为,一个高效、好用的配置管理数据库一般需要满足6条重要标准,即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种,如网络设备、服务器、虚拟机等,因此对于多种信息的存储需要有合适的联合的方法。虽然
iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足,但是随着服务器虚拟化技术的发展,虚拟机正越来越多的成为IT基础架构的一大元素。因此,针对这一需求华三通信基于CAS
CVM虚拟化管理系统,对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同,华三通信的网管软件面向全行业,目前虽然没有对域名管理等特殊资源的管理,但是能够通过API接口等方式与特有系统进行联动,进而满足定制化运维的需求,尤其是在互联网化的场景中,针对不同的业务需求,可以实现很多定制化的对接需求,例如,iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接,打通了iMC工具与用户自有运维平台,很好的实现了架构融和。另外,与阿里的逻辑分层建模相似,H3C
“iMC+CAS”软件体系在上层也做了很多的逻辑抽象、分层,形成了诸多的模块,也即是大家看到的各种组件。

作为最古老的部署技术,缺点也是显而易见的:

作为最古老的部署技术,缺点也是显而易见的:

三、网络自动化运维体系

3.1.2.1 文档不精确

3.1.2.1 文档不精确

“哪怕是一个只有基础技术能力的陌生人,也能做专业的IT运维;哪怕是一个只有初中学历的运维人员,也能够带队完成中小型机房节点的建设,并负责数百至上千台服务器的维护管理工作”–这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑,但实际上依托于强大的IT运维系统,国内已经有不少互联网公司能够达到或者接近这一标准。

由于文档是自然语言写的,是写给运维工程师阅读的,而不是给机器执行的。文档写的是什么,跟机器上实际执行的是什么,并不是100%一致的,需要人肉转换。在长期版本变更、人员更替中极容易出现疏漏。当然,可以从行政管理上解决这类隐患。很多大公司都喜欢搞流程,用测试审核流程来督促人少犯错。然而,只要是这个文档是给人看而不是给机器执行的,这个文档就会一直面临笔误、表达不精确、更新不及时等隐患,要用流程来彻底杜绝这些隐患,成本很高。

由于文档是自然语言写的,是写给运维工程师阅读的,而不是给机器执行的。文档写的是什么,跟机器上实际执行的是什么,并不是100%一致的,需要人肉转换。在长期版本变更、人员更替中极容易出现疏漏。当然,可以从行政管理上解决这类隐患。很多大公司都喜欢搞流程,用测试审核流程来督促人少犯错。然而,只要是这个文档是给人看而不是给机器执行的,这个文档就会一直面临笔误、表达不精确、更新不及时等隐患,要用流程来彻底杜绝这些隐患,成本很高。

这些企业都经历了运维发展过程中的各个阶段,运维部门曾经也是被动的、孤立的、分散的”救火队”式的团队,在后来的发展过程中,IT系统架构逐渐走向标准化、模型化,运维部门建立了完整的设备、系统资源管理数据库和知识库,包括所有硬件的配置情况、所有软件的参数配置,购买日期、维修记录,运维风险看板等等,通过网管软件,进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统,不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构,在这样一套系统中,主要的IT资源包括计算、存储、网络资源,近些年随着网络设备厂商的推动,网络设备管理方面的自动化技术也得到十足的发展。

3.1.2.2 效率低

3.1.2.2 效率低

总结来看,一个企业在进行互联网化的建设初期,就需要考虑到随着用户访问量的增加,资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。

上述5个步骤都是串行的,必须做完一步才能进行下一步。第1步和第3步是比较耗时的,若网速不快,或者编译时间太长,运维工程师会浪费时间等待。

上述5个步骤都是串行的,必须做完一步才能进行下一步。第1步和第3步是比较耗时的,若网速不快,或者编译时间太长,运维工程师会浪费时间等待。

1.规划模型化

另一方面,若有多台机器需要执行同样的部署操作,也无法减少重复性操作。

另一方面,若有多台机器需要执行同样的部署操作,也无法减少重复性操作。

为了确保后续业务能够平滑扩容,网管系统能够顺利跟进,互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化,新增业务资源就好比点快餐,随需随取。

3.2 自动化部署:shell脚本

3.2 自动化部署:shell脚本

标准化:一是采用标准协议和技术搭建,扩展性好,使用的产品较统一,便于管理;二是采用数据中心级设备,保证可靠性、灵活性,充分考虑业务系统对低时延的要求。

若服务器稍有规模的团队里,上述手工部署就成了一个大问题。

若服务器稍有规模的团队里,上述手工部署就成了一个大问题。

模型化:基于业务需求设计网络架构模型,验证后形成基线,可批量复制,统一管理,也适宜通过自动化提高部署效率、网管效率。

人肉阅读的文档急需转换成机器执行的代码。最早也最广泛运用的自动化部署技术便是shell脚本。以bash为例,上述5步写成bash
shell就像这样(示例代码,未经测试):

人肉阅读的文档急需转换成机器执行的代码。最早也最广泛运用的自动化部署技术便是shell脚本。以bash为例,上述5步写成bash
shell就像这样(示例代码,未经测试):

威尼斯人娱乐场官网 21

威尼斯人娱乐场官网 22

威尼斯人娱乐场官网 22

图5.常见互联网IDC架构

直接运行这个脚本,就可以自动安装配置好nginx了。

直接运行这个脚本,就可以自动安装配置好nginx了。

2.建设自动化

相比手工部署,使用shell脚本的缺点只有两点:一是写代码需要一定学习门槛。二是维护的技术难度会略高。

相比手工部署,使用shell脚本的缺点只有两点:一是写代码需要一定学习门槛。二是维护的技术难度会略高。

互联网IT基础设施具备批量复制能力之后,可以通过自动化技术,提高上线效率。在新节点建设过程中,3~5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求,一共派遣了2名工程师到现场进行设备安装部署和基本配置,而后通过互联网链路,设备从总部管理系统中自动获取配置和设备版本,下载业务系统,完成设备安装到机房上线不超过1周时间。

3.2.1 优点

3.2.1 优点

要达到自动化运维的目标,建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。

3.2.1.1 精确

3.2.1.1 精确

批量复制:根据业务需要,梳理技术关注点,设计网络模型,进行充分测试和试点,输出软、硬件配置模板,进而可进行批量部署。

由于shell脚本是给机器执行的,shell脚本自身就是一份精确的可执行的文档,所以,不存在笔误、表达不精确、更新不及时的问题。

由于shell脚本是给机器执行的,shell脚本自身就是一份精确的可执行的文档,所以,不存在笔误、表达不精确、更新不及时的问题。

自动化上线:充分利用TR069、Autoconfig等技术,采用零配置功能批量自动化上线设备,效率能够得到成倍提升。

3.2.1.2 效率高

3.2.1.2 效率高

威尼斯人娱乐场官网 24

运维工程师只要把脚本启动起来就可以做别的工作了。

运维工程师只要把脚本启动起来就可以做别的工作了。

图6.批量配置与自动化上线

3.2.2 bash的缺点

3.2.2 bash的缺点

○ Autoconfig与TR069的主要有三个区别:

Bash是几乎所有linux发行版内置的,环境兼容性好,简洁易学。但它却不是运维编程的终极之选。具体来说有两大缺点:

Bash是几乎所有linux发行版内置的,环境兼容性好,简洁易学。但它却不是运维编程的终极之选。具体来说有两大缺点:


Autoconfig适用于零配置部署,后续一般需要专门的网管系统;TR069是一套完整的管理方案,不仅在初始零配置时有用,后续还可以一直对设备进行监控和配置管理、软件升级等。

3.2.2.1 缺少高级语言特性

3.2.2.1 缺少高级语言特性


Autoconfig使用DHCP与TFTP–简单,TR069零配置使用DHCP与HTTP–复杂,需要专门的ACS服务器。

Bash不是一门高级编程语言,和Perl/Python/Ruby/PHP这些同样可以用作shell编程的语言相比,缺少很多高级语言特性,而这些特性在运维部署工作中会用到。

Bash不是一门高级编程语言,和Perl/Python/Ruby/PHP这些同样可以用作shell编程的语言相比,缺少很多高级语言特性,而这些特性在运维部署工作中会用到。

安全性:TR069更安全,可以基于HTTPS/SSL。

3.2.2.1 工具链不丰富

3.2.2.1 工具链不丰富

而H3C iMC
BIMS实现了TR-069协议中的ACS(自动配置服务器)功能,通过TR-069协议对CPE设备进行远程管理,BIMS具有零配置的能力和优势,有灵活的组网能力,可管理DHCP设备和NAT后的私网设备。BIMS的工作流程如图7所示。

由于不支持OOP,因此没有完整的单元测试框架。

由于不支持OOP,因此没有完整的单元测试框架。

威尼斯人娱乐场官网 25

开发框架、缺陷分析、性能分析工具也几乎是一片空白。IDE支持虽有(JetBrains公司IntelliJ就有bash
shell插件),但功能不多。

开发框架、缺陷分析、性能分析工具也几乎是一片空白。IDE支持虽有(JetBrains公司IntelliJ就有bash
shell插件),但功能不多。

图7.H3C iMC BIMS工作流程

3.3 自动化部署:运维DSL

3.3 自动化部署:运维DSL

3.管理智能化

得益于虚拟化和公有云的快速普及,高效高质量地完成应用部署不再是大公司专有的需求,也成了中小企业的刚需,前面分析过了,bash
shell不能胜任大规模的、复杂的应用部署,自动化运维编程语言DSL(Domain
Specific Language)被发明出来,puppet, chef,ansible,
saltstack是其中杰出的代表。

得益于虚拟化和公有云的快速普及,高效高质量地完成应用部署不再是大公司专有的需求,也成了中小企业的刚需,前面分析过了,bash
shell不能胜任大规模的、复杂的应用部署,自动化运维编程语言DSL(Domain
Specific Language)被发明出来,puppet, chef,ansible,
saltstack是其中杰出的代表。

对于网管团队而言,需要向其他团队提供便利的工具以进行信息查询、告警管理等操作。早期的网管工具,往往离不开命令行操作,且对于批量处理的操作支持性并不好,如网络设备的MIB库相比新的智能化技术Netconf,好比C和C++,显得笨拙许多。因此使用的角度考虑,图形化、智能化的管理工具,往往是比较受欢迎。

4 自动化运维技术发展趋势展望

4 自动化运维技术发展趋势展望

智能化:使用新技术,提升传统MIB式管理方式的处理效率,引入嵌入式自动化架构,实现智能终端APP化管理(如图8所示)。

4.1 部署工作代码化

4.1 部署工作代码化

威尼斯人娱乐场官网 26

无论是使用bash / python
shell,还是使用puppet、chef等DSL,都可以完成代码化这个过程。把手工操作变成代码。

无论是使用bash / python
shell,还是使用puppet、chef等DSL,都可以完成代码化这个过程。把手工操作变成代码。

图8.消息、事件处理智能化

使用代码自动化部署应用环境和应用,才能保证无论在办公室测试环境,还是在机房生产环境,每次运行这个部署代码,都能得到相同的结果。这是一切自动化部署的基础。

使用代码自动化部署应用环境和应用,才能保证无论在办公室测试环境,还是在机房生产环境,每次运行这个部署代码,都能得到相同的结果。这是一切自动化部署的基础。

● Netconf技术

4.2 运维代码版本化

4.2 运维代码版本化

目前网络管理协议主要是SNMP和Netconf。SNMP采用UDP,实现简单,技术成熟,但是在安全可靠性、管理操作效率、交互操作和复杂操作实现上还不能满足管理需求。Netconf采用XML作为配置数据和协议消息内容的数据编码方式,采用基于TCP的SSHv2进行传送,以RPC方式实现操作和控制。XML可以表达复杂、具有内在逻辑、模型化的管理对象,如端口、协议、业务以及之间的关系等,提高了操作效率和对象标准化;采用SSHv2传送方式,可靠性、安全性、交互性较好。二者主要对比差异如表1所示。

运维代码要和Java,PHP等应用代码一样,纳入SVN、GIT代码仓库,执行严格的开发-测试-上线-回滚流程。

运维代码要和Java,PHP等应用代码一样,纳入SVN、GIT代码仓库,执行严格的开发-测试-上线-回滚流程。

威尼斯人娱乐场官网 27

这样便可利用svn/git的成熟SCM功能,用于这样一些场景:

这样便可利用svn/git的成熟SCM功能,用于这样一些场景:

表1 网管技术的对比

4.2.1 新建分支

4.2.1 新建分支

● EAA嵌入式自动化架构

运维代码由1.0升级到2.0,增加了缓存层。则可以从1.0复制出一个分支出来,命名为2.0,然后再在2.0的基础上修改。

运维代码由1.0升级到2.0,增加了缓存层。则可以从1.0复制出一个分支出来,命名为2.0,然后再在2.0的基础上修改。

EAA自动化架构的执行包括如下三个步骤。

4.2.2 差异比较

4.2.2 差异比较


定义感兴趣的事件源,事件源是系统中的软件或者硬件模块,如:特定的命令、日志、TRAP告警等。

若要了解1.0和2.0的运维架构到底发生了什么变化,执行svn和git的diff即可查看每一行代码的变化。

若要了解1.0和2.0的运维架构到底发生了什么变化,执行svn和git的diff即可查看每一行代码的变化。

○ 定义EAA监控策略,比如保存设备配置、主备切换、重启进程等。

4.2.3 历史归档

4.2.3 历史归档

○ 当监控到定义的事件源发生后,触发执行EAA监控策略。

1.0版稳定运行了半年,升级到2.0版本,此时1.0版冻结写请求,归档留存。2.0上线运行一段时间,发现稳定性不够。可以从归档中找出1.0版本的部署代码,回滚到1.0版本。

1.0版稳定运行了半年,升级到2.0版本,此时1.0版冻结写请求,归档留存。2.0上线运行一段时间,发现稳定性不够。可以从归档中找出1.0版本的部署代码,回滚到1.0版本。

4.监控平台化

4.3 测试环境高保真

4.3 测试环境高保真

利用基本监控工具如Show、Display、SNMP、Syslog等,制作平台化监控集成环境,实现全方位监控(如图所示)。

很多公司的测试和生产环境存在操作系统不一致、软件版本不一致、配置项不一致的情况。这种不规范的运维有两大后果:一是bug在测试环境未能测出,导致线上故障;二是线上出现异常时,测试环境不能复现。

很多公司的测试和生产环境存在操作系统不一致、软件版本不一致、配置项不一致的情况。这种不规范的运维有两大后果:一是bug在测试环境未能测出,导致线上故障;二是线上出现异常时,测试环境不能复现。

一个应用至少有两种环境:测试环境、生产环境。大一点的公司还会分成:开发环境、功能测试环境、性能测试环境、预发环境、生产环境。这么多的环境的自动化部署代码,原则上应该是90%以上都相同,只有少数地方不一样。

一个应用至少有两种环境:测试环境、生产环境。大一点的公司还会分成:开发环境、功能测试环境、性能测试环境、预发环境、生产环境。这么多的环境的自动化部署代码,原则上应该是90%以上都相同,只有少数地方不一样。

4.4 自动化测试

4.4 自动化测试

使用代码自动化部署完之后,服务器是否立即可用,需要测试验证。自动化测试能让整个运维过程更加高效。

使用代码自动化部署完之后,服务器是否立即可用,需要测试验证。自动化测试能让整个运维过程更加高效。

在应用开发领域,自动化测试、单元测试已经非常普及了,运维开发也可以做一些类似的自动化验收测试工作:

在应用开发领域,自动化测试、单元测试已经非常普及了,运维开发也可以做一些类似的自动化验收测试工作:

4.4.1 终端应用测试

4.4.1 终端应用测试

模拟一个客户端访问刚刚部署好的服务,例如:验证其RESTfulAPI是否得到预期的结果。

模拟一个客户端访问刚刚部署好的服务,例如:验证其RESTfulAPI是否得到预期的结果。

优点是,最接近实际用户,若此测试通过,则说明装软件、改配置、启服务各项工作都正确。缺点是,若测试不通过,不能立即定位出哪里出错了。定位问题需借助下面更底层的测试。

优点是,最接近实际用户,若此测试通过,则说明装软件、改配置、启服务各项工作都正确。缺点是,若测试不通过,不能立即定位出哪里出错了。定位问题需借助下面更底层的测试。

4.4.2 四层网络测试

4.4.2 四层网络测试

使用nmap之类的工具检测目标端口是否正常响应(包括防火墙是否放行)

使用nmap之类的工具检测目标端口是否正常响应(包括防火墙是否放行)

4.4.3 本机测试

4.4.3 本机测试

· 用yum,apt检测包是否安装

· 用yum,apt检测包是否安装

· 用service status检测守护进程是否正常支持

· 用service status检测守护进程是否正常支持

· 用ps检测进程是否正在运行

· 用ps检测进程是否正在运行

· 用ls检测文件是否存在

· 用ls检测文件是否存在

· 用grep检查配置荐是否设置成了指定的值

· 用grep检查配置荐是否设置成了指定的值

自动化测试用例覆盖足够全面,我们便有可能实现一台机器从祼机到上线服务全部自动化完成,无人值守。若没有自动化测试,应用部署完成之后,仍然需要人工验证是否满足上线服务的要求。

自动化测试用例覆盖足够全面,我们便有可能实现一台机器从祼机到上线服务全部自动化完成,无人值守。若没有自动化测试,应用部署完成之后,仍然需要人工验证是否满足上线服务的要求。

4.5 工作流

4.5 工作流

运维代码从开发到上线发挥作用,也应该和应用代码一样遵循下面的工作流:

运维代码从开发到上线发挥作用,也应该和应用代码一样遵循下面的工作流:

威尼斯人娱乐场官网 28

威尼斯人娱乐场官网 28

这个流程图只展示了最基本的要求:部署到生产环境前必须经过测试环境验证。更复杂的还有代码reivew、性能测试环境验证、漏洞扫描环境验证、预发环境验证,生产环境分批发布等环节。

这个流程图只展示了最基本的要求:部署到生产环境前必须经过测试环境验证。更复杂的还有代码reivew、性能测试环境验证、漏洞扫描环境验证、预发环境验证,生产环境分批发布等环节。

很多公司的现状是运维工程师开两个ssh终端,一条命令,先在本地环境跑一下看看效果,成功就拿到线上去跑了。更有甚者,不经过本地验证直接到线上操作了。这主要是因为运维工作没有充分代码化,运维代码没入svn、git仓库。

很多公司的现状是运维工程师开两个ssh终端,一条命令,先在本地环境跑一下看看效果,成功就拿到线上去跑了。更有甚者,不经过本地验证直接到线上操作了。这主要是因为运维工作没有充分代码化,运维代码没入svn、git仓库。

4.6 图形化界面和IDE

4.6 图形化界面和IDE

运维领域一直都缺少通用的、高效的图形界面和IDE。这大约有两个原因:

运维领域一直都缺少通用的、高效的图形界面和IDE。这大约有两个原因:

一是需求不强劲。运维编程的复杂度毕竟比应用编程简单好几个数量级。运维日常工作也没有代码化,还有大量的人工操作,所以,运维代码通常像冰糖葫芦一样,一个个脚本虽然串在一起,但大都是个独立的个体,没有那么强的代码组织结构。

一是需求不强劲。运维编程的复杂度毕竟比应用编程简单好几个数量级。运维日常工作也没有代码化,还有大量的人工操作,所以,运维代码通常像冰糖葫芦一样,一个个脚本虽然串在一起,但大都是个独立的个体,没有那么强的代码组织结构。

二是运维社区极客氛围浓重。就连应用编程领域也只有Java、.NET等语言的用户比较偏爱IDE。在PHP、Python、Perl社区,vim党、emacs党、sublime
text党、notepad++党各领风骚。这些党派崇拜的编辑器不同,但有一个共同信仰:不依赖IDE写代码是一个优秀程序员的必备素质。

二是运维社区极客氛围浓重。就连应用编程领域也只有Java、.NET等语言的用户比较偏爱IDE。在PHP、Python、Perl社区,vim党、emacs党、sublime
text党、notepad++党各领风骚。这些党派崇拜的编辑器不同,但有一个共同信仰:不依赖IDE写代码是一个优秀程序员的必备素质。

关于这个问题,我是这样认为的,有高科技能提升编程生活质量,为什么不用用?即使puppet、chef把运维编程体验做到这么好了,我仍然期待运维业界涌现一批Eclipse、AdobeFlash这样的图形界面、IDE。让IDE的高效易用和运维的命令行操作相得益彰。

关于这个问题,我是这样认为的,有高科技能提升编程生活质量,为什么不用用?即使puppet、chef把运维编程体验做到这么好了,我仍然期待运维业界涌现一批Eclipse、AdobeFlash这样的图形界面、IDE。让IDE的高效易用和运维的命令行操作相得益彰。

4.7 运维代码分治

4.7 运维代码分治

运维界有一句祖训:没有折腾,就没有故障。

运维界有一句祖训:没有折腾,就没有故障。

但为了快速响应业务需求和提高资源利用率,运维又不得不频繁折腾。有没有什么办法能打破“折腾越多、故障越多”的魔咒?有,分而治之。

但为了快速响应业务需求和提高资源利用率,运维又不得不频繁折腾。有没有什么办法能打破“折腾越多、故障越多”的魔咒?有,分而治之。

分治,就是把风险高的和风险低的分开、重要性高的和不高的分开、简单的和复杂的分开、频繁变动的和不频繁的分开。应用编程领域,大家积极探索和实践的各种架构、框架、模式,归根到底都在做两件事:封装复杂度、隔离变化。

分治,就是把风险高的和风险低的分开、重要性高的和不高的分开、简单的和复杂的分开、频繁变动的和不频繁的分开。应用编程领域,大家积极探索和实践的各种架构、框架、模式,归根到底都在做两件事:封装复杂度、隔离变化。

运维架构层的分治,在业界已经非常普遍了,比如应用服务器和数据库服务器分离、交易数据库和用户数据库分离;生产环境和测试环境隔绝。

运维架构层的分治,在业界已经非常普遍了,比如应用服务器和数据库服务器分离、交易数据库和用户数据库分离;生产环境和测试环境隔绝。

4.7.1 配置项和逻辑代码分开

4.7.1 配置项和逻辑代码分开

其实业界早就在这么做了,puppet的hiera和saltstack的pillar都是做这个用的。

其实业界早就在这么做了,puppet的hiera和saltstack的pillar都是做这个用的。

有些运维变更,可能只改变了配置项的值,而并没改变运维代码里的业务逻辑、流程控制。如果只改配置文件,不改运维脚本。发布风险就低了很多,起码不会导致语法错误。

有些运维变更,可能只改变了配置项的值,而并没改变运维代码里的业务逻辑、流程控制。如果只改配置文件,不改运维脚本。发布风险就低了很多,起码不会导致语法错误。

4.7.2 会变动的配置项独立

4.7.2 会变动的配置项独立

就像应用开发领域里的模板引擎一样,把配置文件写成模板,模板中包含变量,运维工具或者运维平台解析模板内容,把变量替换成真实的值。

就像应用开发领域里的模板引擎一样,把配置文件写成模板,模板中包含变量,运维工具或者运维平台解析模板内容,把变量替换成真实的值。

4.7.3 服务发现

4.7.3 服务发现

将会变动的配置项独立出来动态维护,还可以实现服务发现。以haproxy + etcd +
confd为例:

将会变动的配置项独立出来动态维护,还可以实现服务发现。以haproxy + etcd +
confd为例:

confd就是一个模板引擎,类似Java里有Velocity和Python里的jinja。不同之处是:confd还有自动轮询etcd的能力。使用confd解析和管理haproxy的配置文件,摘录如下:

confd就是一个模板引擎,类似Java里有Velocity和Python里的jinja。不同之处是:confd还有自动轮询etcd的能力。使用confd解析和管理haproxy的配置文件,摘录如下:

跟原生的haproxy配置文件不同,最后三行是confd模板。

跟原生的haproxy配置文件不同,最后三行是confd模板。

etcd是一个KV存储,类似memcached,不同之处是etcd生来就是分布式的,自带高可用和负载均衡的基因,同时还有HTTPRESTful
API,存取方便。使用etcd存储后端服务器列表。

etcd是一个KV存储,类似memcached,不同之处是etcd生来就是分布式的,自带高可用和负载均衡的基因,同时还有HTTPRESTful
API,存取方便。使用etcd存储后端服务器列表。

当后端有一台nginx服务启动的时候,调etcd的api把这台机器的ip地址写入etcd上的列表。confd轮询etcd时查到这台新加入的机器,便会自己把它加进haproxy的backend
server里。

当后端有一台nginx服务启动的时候,调etcd的api把这台机器的ip地址写入etcd上的列表。confd轮询etcd时查到这台新加入的机器,便会自己把它加进haproxy的backend
server里。

这样便实现了负载均衡集群自动化扩容,下线一台nginx机器亦同此理,先调etcd的api删除某台机器,过一分钟在这台nginx上检测不到流量了再把它下线。

这样便实现了负载均衡集群自动化扩容,下线一台nginx机器亦同此理,先调etcd的api删除某台机器,过一分钟在这台nginx上检测不到流量了再把它下线。

扩容过程中没有修改haproxy的配置,也没有部署haproxy。只是调用了etcd的RESTfulAPI,这个风险就比修改haproxy配置文件再部署上线小多了。

扩容过程中没有修改haproxy的配置,也没有部署haproxy。只是调用了etcd的RESTfulAPI,这个风险就比修改haproxy配置文件再部署上线小多了。

4.8 整合基础设施API

4.8 整合基础设施API

所有的公有云厂商都提供了HTTPOpenAPI,包括国外的aws、azure、gce和国内的阿里云、Ucloud、青云。

所有的公有云厂商都提供了HTTPOpenAPI,包括国外的aws、azure、gce和国内的阿里云、Ucloud、青云。

市场占有率排名靠前的虚拟化软件商也都有HTTPOpenAPI,包括:VMware、Hyper-V、XenServer、OpenStack。

市场占有率排名靠前的虚拟化软件商也都有HTTPOpenAPI,包括:VMware、Hyper-V、XenServer、OpenStack。

因此技术上有可能把基础设施提供商的API整合进来,实现虚拟机创建、启动、安装操作系统、联网、执行命令、关机、销毁全生命周期的自动化。

因此技术上有可能把基础设施提供商的API整合进来,实现虚拟机创建、启动、安装操作系统、联网、执行命令、关机、销毁全生命周期的自动化。

和应用部署脚本不同,调用云厂商的API不能由DSL脚本完成,用bash
shell来做也非常不方便。应该用PHP、Java之类的应用编程语言写一个应用来做。

和应用部署脚本不同,调用云厂商的API不能由DSL脚本完成,用bash
shell来做也非常不方便。应该用PHP、Java之类的应用编程语言写一个应用来做。

至此,虚拟机和操作系统初始化、应用环境部署、应用软件部署全部都实现了自动化,便可以从零创建一台可上线服务的机器。

至此,虚拟机和操作系统初始化、应用环境部署、应用软件部署全部都实现了自动化,便可以从零创建一台可上线服务的机器。

4.9 跨厂商跨城市故障转移

4.9 跨厂商跨城市故障转移

实现了部署工作代码化和基础设施API整合之后,便可以自由地跨厂商、跨城市迁移:在不同的机房维持两份相同的数据,每分钟同步。当基础设施发生重大故障难以在短时间内恢复时,可以迅速在另外一个有数据的机房将整套应用自动化部署起来。

实现了部署工作代码化和基础设施API整合之后,便可以自由地跨厂商、跨城市迁移:在不同的机房维持两份相同的数据,每分钟同步。当基础设施发生重大故障难以在短时间内恢复时,可以迅速在另外一个有数据的机房将整套应用自动化部署起来。

4.10 弹性伸缩

4.10 弹性伸缩

几乎每一个给人类访问的网站,其服务器资源利用率都是存在明显峰谷的:

几乎每一个给人类访问的网站,其服务器资源利用率都是存在明显峰谷的:

·
有的尖峰是一年出现一次,典型的例子是阿里的双十一。每年11月11日,电商狂欢。大卖家的进销存系统、淘宝生态链上的SaaS服务商(如在线打印快递单、发送短信券码、物流跟踪)的系统压力也跟着猛涨1-2个数量级。他们投资扩容的硬件设备,只有这一天才能充分利用,平时利用率极低。

·
有的尖峰是一年出现一次,典型的例子是阿里的双十一。每年11月11日,电商狂欢。大卖家的进销存系统、淘宝生态链上的SaaS服务商(如在线打印快递单、发送短信券码、物流跟踪)的系统压力也跟着猛涨1-2个数量级。他们投资扩容的硬件设备,只有这一天才能充分利用,平时利用率极低。

·
有的尖峰是一天出现一次或者多次,比如唯品会、聚划算的10点秒杀。基本每一个电商都一天多波次的秒杀、抢购。

·
有的尖峰是一天出现一次或者多次,比如唯品会、聚划算的10点秒杀。基本每一个电商都一天多波次的秒杀、抢购。

· 更普遍的是白天高峰、凌晨到清晨低谷。

· 更普遍的是白天高峰、凌晨到清晨低谷。

自动化运维(包括自动购买分配虚拟机、自动部署应用环境、自动部署应用软件、自动测试)使按需调度计算资源成为了可能。实时的弹性伸缩,意味着每天、甚至每分钟都在做扩容、缩容,这必须要靠自动化运维实现。

自动化运维(包括自动购买分配虚拟机、自动部署应用环境、自动部署应用软件、自动测试)使按需调度计算资源成为了可能。实时的弹性伸缩,意味着每天、甚至每分钟都在做扩容、缩容,这必须要靠自动化运维实现。

4.10.1 公有云上的按需采购

4.10.1 公有云上的按需采购

主流的公有云计费粒度都已经细到小时(aws、阿里云、Ucloud),有的做到了按分钟(azure、gce),甚至还有按秒计费的(青云)。

主流的公有云计费粒度都已经细到小时(aws、阿里云、Ucloud),有的做到了按分钟(azure、gce),甚至还有按秒计费的(青云)。

对出现频率较低、计划中的尖峰,人工干预,提前做好扩容和缩容预案,以双十一为例,人工设定好11月10日购买一批按小时计费的机器(不是包年包月),到了11月15日释放这些机器,厂商会停止计费。

对出现频率较低、计划中的尖峰,人工干预,提前做好扩容和缩容预案,以双十一为例,人工设定好11月10日购买一批按小时计费的机器(不是包年包月),到了11月15日释放这些机器,厂商会停止计费。

对出现频率高的尖峰,运维平台智能调度,比如每5秒采样系统资源利用率,达到指定的扩容阈值就自动买机器并自动化部署、测试、上线服务,低于指定的回收阈值就自动下线服务器、通知厂商停止计费。这种适用于部署上线时间极短的服务,特别是无状态、无用户数据的应用服务器。若需要较长的预热时间(如数据库、缓存、搜索引擎),则需要提前扩容,这就要根据历史性能曲线做智能预测了。

对出现频率高的尖峰,运维平台智能调度,比如每5秒采样系统资源利用率,达到指定的扩容阈值就自动买机器并自动化部署、测试、上线服务,低于指定的回收阈值就自动下线服务器、通知厂商停止计费。这种适用于部署上线时间极短的服务,特别是无状态、无用户数据的应用服务器。若需要较长的预热时间(如数据库、缓存、搜索引擎),则需要提前扩容,这就要根据历史性能曲线做智能预测了。

按需购买对公有云厂商也有积极意义:

按需购买对公有云厂商也有积极意义:

·
从宏观角度讲,用多少买多少,杜绝浪费,提升了全球公有云资源池中的资源利用率,任何提升资源利用率的事情都是有积极正面的。

·
从宏观角度讲,用多少买多少,杜绝浪费,提升了全球公有云资源池中的资源利用率,任何提升资源利用率的事情都是有积极正面的。

·
从经济角度讲,公有云按小时售卖的机器单价比包年的贵,如果两种售卖方式都能100%把机器卖出去,按小时计费的总收入更高。

·
从经济角度讲,公有云按小时售卖的机器单价比包年的贵,如果两种售卖方式都能100%把机器卖出去,按小时计费的总收入更高。

·
目前有的公有云厂商已经出现部分机房物理资源售罄的情况。如果提供实时服务(如电商、支付、新闻、社交)的客户都按需采购,就有可能在闲时把资源释放出来给实时性要求不高的客户(如离线大数据处理、动画渲染)使用。

·
目前有的公有云厂商已经出现部分机房物理资源售罄的情况。如果提供实时服务(如电商、支付、新闻、社交)的客户都按需采购,就有可能在闲时把资源释放出来给实时性要求不高的客户(如离线大数据处理、动画渲染)使用。

4.10.2 私有云的业务间调配

4.10.2 私有云的业务间调配

已经投资购置大量硬件的企业,可以在不同内部业务之间调度,比如白天把大多数机器用来为消费者提供服务,晚上缩减承担消费者请求的机器规模,释放出来的计算资源用来做大数据处理。

已经投资购置大量硬件的企业,可以在不同内部业务之间调度,比如白天把大多数机器用来为消费者提供服务,晚上缩减承担消费者请求的机器规模,释放出来的计算资源用来做大数据处理。

5 自动化运维平台

5 自动化运维平台

2012年,我刚在极其艰苦的环境下做了一个自营B2C,恰好看到12306故障频频,觉得自己能带队做一个比他们好的,于是试着去做数据库建模,结果,就是有了《身为码农,为12306说两句公道话》这篇文章,那篇文章太火了,各种微博、微信、论坛累计转发可能有几十万,还登上了《科技日报》、《南方都市报》、《新京报》等10余家平面媒体,连12306的技术负责人(中国铁科院计算所副所长)接受人民网采访都引用我的观点。后来微博上很多人转发说“这兄弟生动地诠释了:你行你上,不行别逼逼”。

2012年,我刚在极其艰苦的环境下做了一个自营B2C,恰好看到12306故障频频,觉得自己能带队做一个比他们好的,于是试着去做数据库建模,结果,就是有了《身为码农,为12306说两句公道话》这篇文章,那篇文章太火了,各种微博、微信、论坛累计转发可能有几十万,还登上了《科技日报》、《南方都市报》、《新京报》等10余家平面媒体,连12306的技术负责人(中国铁科院计算所副所长)接受人民网采访都引用我的观点。后来微博上很多人转发说“这兄弟生动地诠释了:你行你上,不行别逼逼”。

2015年,我对运维做了这么多展望,技痒难耐,决定再实践一次“你行你上”,于是我自投资金百万,做了“运维厨房”这样一个自动化运维平台。在这里就不再多做阐述了。

2015年,我对运维做了这么多展望,技痒难耐,决定再实践一次“你行你上”,于是我自投资金百万,做了“运维厨房”这样一个自动化运维平台。在这里就不再多做阐述了。

威尼斯人娱乐场官网 30

威尼斯人娱乐场官网 30

作者介绍:覃健祥

作者介绍:覃健祥

全球最先进自动化运维平台【运维厨房】创始人,投身软件开发和开源事业 16
年,历任博客中国CTO、雅虎高级技术专家、阿里巴巴高级技术专家、上市公司香江控股电商总经理。Segmentfault
社区享有声望的答题专家和演讲嘉宾。

全球最先进自动化运维平台【运维厨房】创始人,投身软件开发和开源事业 16
年,历任博客中国CTO、雅虎高级技术专家、阿里巴巴高级技术专家、上市公司香江控股电商总经理。Segmentfault
社区享有声望的答题专家和演讲嘉宾。

【编辑推荐】

【编辑推荐】

相关文章