奥门威尼斯网址云计算对服务器运维的挑战

云计算:拼的是运维

云计算的技术难点

到今天,云计算的工业实现已经不太难了。现在有开源软件KVM和Xen,这两个东西基本把虚拟化搞定;而OpenStack则把管理、控制系统搞定,也很成熟。PaaS也有相应的开源,比如OpenShift,而Java里也有N多的中间件框架和技术。另外分布式文件系统GFS/TFS,分布式计算系统Hadoop/Hbase等等,分布式的东西都不神秘了。技术的实现在以前可能是问题,现在不是了。

对于云计算工程方面,现在最难的是运维。管100台、1万台还是100万台机器,那是完全不同的。机器少你可以用人管理,机器多是不可能靠人的。运维系统不属于功能性的东西,用户看不见,所以这是被大家严重低估的东西。只要你做大了,就必然要在运维系统上做文章。数据中心/云计算拼的就是运维能力。

为什么我说运维比较复杂,原因有这么几个。

一方面,云计算要用廉价设备取代那些昂贵的解决方案。所谓互联网的文化就是屌丝文化,屌丝就是便宜,互联网就是要用便宜的东西搭建出高质量的东西,硬件和资源一定不会走高端路线——比如EMC、IBM小型机、SGI超级计算机等等,你如果用它去搭建云计算,成本太贵。用廉价的解决方案代替昂贵的解决方案是整个计算机发展史中到今天唯一不变的事情。所以如果你要让夏利车跑出奔驰车的感觉,你需要自己动手做很多事,搭建一个智能的系统。用廉价的东西做出高质量的东西,运维好廉价的设备其实是云计算工程里最大的挑战。

另一方面,因为你机器多了,然后你用的又不是昂贵的硬件,所以故障就变成了常态,硬盘、主板、网络天天坏。所以,没什么好想的,运维就必须要跟上。云计算的目标是在故障成为常态的情况下保证高可用——也就是我们所说的,你服务的可用性是3个9、4个9还是5个9。

最后,这一大堆机器和设备都放在一起,你的安全就是一个挑战,一方面是Security,另一方面是Safety,保证数十台数百台的设备的安全还好说,但是对于数万数十万台的设计,就没有那么简单了。

面对这样的难题,人是无法搞得定的,你只能依靠技术来管理和运维整个平台。比如必须有监控系统。这跟操作系统一样,对资源的管理,对网络流量、CPU利用率、进程、内存等等的状态肯定要全部收集的。收集整个集群各种节点的状态,是必然每个云计算都有的,都是大同小异的。

然后,你还要找到可用性更好的节点,这需要有一些故障自检的功能。比如阿里云就遇到过磁盘用到一定时候就会莫名其妙的不稳定,有些磁盘的I/O会变慢。变慢的原因有可是硬盘不行了,于是硬盘控制器可能因为CRC校验出错需要要多读几次,这就好比TCP的包传过来,数据出错了,需要重新传。在这种硬盘处理半死不活的状态时,你肯定是需要一个自动检测或自动发现的程序去监控这种事情,当这个磁盘可能不行了,标记成坏磁盘,别用它,到别的磁盘上读复本去。我们要有故障自动检测、预测的措施,才能驱动故障,而不是被动响应故障,用户体验才会好。换句话说,我们需要自动化的、主动的运维。

为了数据的高可用性,你只能使用数据冗余,写多份到不同的节点——工业界标准写三份是安全。然而,你做了冗余,又有数据一致性问题。为了解决冗余带来的一致性问题,才有了paxos的投票玩法,大家投票这个能不能改,于是你就需要一个强大的控制系统来控制这些东西。

另外,公有云人来人往,里面的资源和服务今天用明天不用,有分配有释放,有冻结,你还要搞一个资源管理系统来管理这些资源的生命状态。还有权限管理,就像AWS的IAM一样,如果没有像AWS的IAM权限管理系统,AWS可能会不会像今天这样有很多大的公司来用。企业级的云平台,你需要有企业级的运维和管理能力。

云计算的门槛

为啥云计算有这么多开源的东西,却不是人人都能做?

一方面,这就跟盖楼一样。盖楼的技术没什么难的(当然,盖高楼是很难的),但是你没地你怎么盖?我觉得云计算也一样,带宽的价格贵得就像土地的价格。其实云计算跟房地产一样,要占地、占机房、占带宽。如果能把中国所有的机房、机柜、带宽资源都买了,你就不用做云计算了,卖土地就够了——因为这些是有限的。最简单的例子,IP地址是有限的。你有带宽、有机房,但是如果你没有IP,这就不好玩了。尤其是你要提供CDN服务,这个就更明显,因为有多少物理节点直接决定你的CDN服务质量。

另一方面,正如前面所说的,运维是件很难的事,运维这个事并不是一般人能搞的事。没有足够的场景、经验和时间,这种能力很难出现。

从用户的角度来说呢,云计算是一种服务,你需要对用户企业内的解决方案要有很好的了解,这样才能提高很好的服务。能提供“好服务”的通常都是把自己真正当成用户公司。

卖汽车也是卖服务。造出汽车来,并不代表你搞定这个事了。如果没有公路、没有加油站、没有4s店、没有交通管理、规则等等,你要么用不了,要么就是乱七八糟。不能只让用户在那看着你的汽车好牛啊,但是用户不知道怎么用。所以说,云计算最终旁边必须要有一套服务设施,而这套服务设施也是今天被人低估的。

云计算有两个东西我觉得是被人低估的,一个是运维,一个是那堆服务。做服务的需要有生态环境,有人帮你做。所以做云计算要落地并不简单。

总之,云计算是需要吃自己的狗食才能吃出来的,绝不是像手机上的Apps一样,你想一想、试一试就能搞出来的,你首先需要让自己有这样的场景,有这样的经历,你才可能会有这样的经验和能力。

还是那句话,云就是服务,只要提供了好的服务,无论公有还是私有都是会有价值的。

云计算的技术难点
到今天,云计算的工业实现已经不太难了。现在有开源软件KVM和Xen,这两个东西基本把虚拟化搞定…

陈皓(@左耳朵耗子),CoolShell.cn博主。15年软件开发相关工作经验,8年以上项目和团队管理经验。擅长底层技术架构,团队建设,软件工程,软件研发咨询,以及全球软件团队协作管理。对高性能,高可用性,分布式,高并发,以及大规模数据处理系统有一些经验和心得。喜欢关注底层技术平台和互联网行业应用。技术擅长C/C++/Java和Unix/Linux/Windows。曾于Amazon中国任研发经理,负责电子商务全球化业务(全球开店)和全球库存预测系统的研发。曾在阿里巴巴北京研发中心、商家业务部曾任资深专家一职,负责电商云平台、开放平台,云监控和电商多媒体平台。现在阿里巴巴核心系统专家组从事阿里核心系统和阿里云ECS相关的虚拟化平台的开发工作。

引入了云计算之后,运维的重点将不仅仅是原来管理的设备运行正常,网络畅通,还将关注资源的主动供给、自动配置、可持续性、可追踪的实时配置管理。

对云计算的定义

在传统的运维管理中,为了保证可靠性和伸缩性,不仅需要在部署阶段进行支持,而且还需要随时监视应用的运行状态,判断是否存在节点失效或者负载过高等情况,一旦发生异常,管理员根据事先制定好的工作流程来启动备用的服务器,运行相应的管理脚本来对新的服务器进行配置和初始化等。而在云计算环境中运维人员一部分负责物理设备运转,一部分负责应用相关的监控和管理。运维人员定位系统故障不再只是依靠传统的网管手段,需要更深入地通过云计算管理平台以及虚拟设备管理平台,来分析系统的运行效率和故障原因。

奥门威尼斯网址 1

奥门威尼斯网址 1

云计算其实跟PC机有一样的概念,有CPU、硬盘、操作系统、应用软件。云计算的计算节点(虚拟机)就是PC中的CPU,数据缓存服务就是PC的内存,存储节点就是PC的硬盘,提供数据服务,让数据不丢、高可用,PC中的控制器就是云计算的控制系统。PC机的硬件上面要有操作系统。操作系统很大一块是给开发人员提供系统的API接口,提供系统监控以看运行情况,并且还要有系统管理——如用户账号的权限管理、备份恢复等等。操作系统上面要有应用软件,这样才能服务于最终用户,应用软件就是真正落地的业务,这样才会有用户;有了用户,整个体系就运转起来了。

在云计算环境中,虚拟机虚拟镜像磁盘文件把基本操作系统、客户需要使用的应用及运行应用所需的中间件等组件一并打包在内,免去了传统环境下为用户进行复杂安装配置的过程,做到开箱即用,实际上成为了企业的虚拟资产。这和传统环境下需要保留主机运行环境,保存安装软件不同,虚拟机镜像文件随时加载意味着新的虚拟设备可以在需要时快速进入生产状态,特别是一些测试开发环境的准备,可以通过原始的虚拟镜像快速恢复到用户所需要的状态。

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

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

这就是工程师说的stack,也就是我们听到的IaaS、PaaS、SaaS三个层。IaaS层就像PC机的基础硬件加驱动程序,PaaS层就像PC机上的操作系统——把基础硬件抽象、包起来并屏蔽硬件和硬件驱动细节、调度基础硬件,而SaaS层就是PC机里的应用软件。另外,我们还得给开发人员提供各种开发框架、类库和开发环境,这就是为什么AWS还做通知、消息、工作流,这是用于粘合操作系统和业务层的,比如可以让你方便地做水平扩展和分布式。云计算自然也会像PC机一样,三个层上都会有用于控制和管理的系统。这就是为什么云计算会做成这个样子,其实计算机的发展就在这个圈子里绕。

在云计算实践之前,数据中心的绝大多数应用服务都部署在物理机上,随着物理设备逐渐老化,性能逐渐下降,所运行的应用软件的稳定性和可靠性都受到了极大的影响。要把服务迁移到新的系统上会面临很大的风险:一方面是因为开发人员的流动性,当需要迁移服务时,难以找到原开发团队的相关人员;另一方面是软件对新运行环境的兼容性问题,软件所依赖的特定接口或者函数库在新的系统里并不一定兼容。引入云计算技术以后,人们采用新的虚拟化的辅助技术(P2V)能够把应用服务与操作系统一起从物理服务器上迁移到虚拟环境中,管理员不再需要触及与系统紧密整合的应用的相关代码,大大提高了系统迁移的可行性和成功率。迁移后的服务器,不仅可在一个统一的界面中进行管理,而且借助虚拟机化管理软件,在这些服务器因故障停机时,可以自动切换到网络中其他可替代的虚拟服务器中,从而达到不中断业务的目的。

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

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

其实,最终用户基本并不关心你CPU用的啥,存储用的是啥,你用什么框架开发,他们关心更多的是可以解决什么问题,有什么样的用户体验。像以前Windows用户体验之所以比Linux好,就是因为应用层用的舒服;而Linux对开发者的用户体验比Windows好,就是因为其开放和可以让开发人员更灵活、更自由。我们可以看到SaaS层上有的像SalesForce、Dropbox、Evernote、Netflix这样的给最终用户的服务,他们更倾向于最终用户和业务。

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

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

说到底,云计算的IaaS、PaaS、SaaS最后那个S都是Service。就是说,无论你云计算长成什么样,都得要向用户提供“服务”而不仅仅是软硬件和各种资源。

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

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

云计算的技术难点

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

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

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

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

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

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

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

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

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

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

到今天,云计算的工业实现已经不太难了。现在有开源软件KVM和Xen,这两个东西基本把虚拟化搞定;而OpenStack则把管理、控制系统搞定,也很成熟。PaaS也有相应的开源,比如OpenShift,而Java里也有N多的中间件框架和技术。另外分布式文件系统GFS/TFS,分布式计算系统Hadoop/Hbase等等,分布式的东西都不神秘了。技术的实现在以前可能是问题,现在不是了。

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

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

对于云计算工程方面,现在最难的是运维。管100台、1万台还是100万台机器,那是完全不同的。机器少你可以用人管理,机器多是不可能靠人的。运维系统不属于功能性的东西,用户看不见,所以这是被大家严重低估的东西。只要你做大了,就必然要在运维系统上做文章。数据中心/云计算拼的就是运维能力。

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

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

为什么我说运维比较复杂,原因有这么几个。

1 操作系统自动化部署

1 操作系统自动化部署

一方面,云计算要用廉价设备取代那些昂贵的解决方案。所谓互联网的文化就是屌丝文化,屌丝就是便宜,互联网就是要用便宜的东西搭建出高质量的东西,硬件和资源一定不会走高端路线——比如EMC、IBM小型机、SGI超级计算机等等,你如果用它去搭建云计算,成本太贵。用廉价的解决方案代替昂贵的解决方案是整个计算机发展史中到今天唯一不变的事情。所以如果你要让夏利车跑出奔驰车的感觉,你需要自己动手做很多事,搭建一个智能的系统。用廉价的东西做出高质量的东西,运维好廉价的设备其实是云计算工程里最大的挑战。

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

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

另一方面,因为你机器多了,然后你用的又不是昂贵的硬件,所以故障就变成了常态,硬盘、主板、网络天天坏。所以,没什么好想的,运维就必须要跟上。云计算的目标是在故障成为常态的情况下保证高可用——也就是我们所说的,你服务的可用性是3个9、4个9还是5个9。

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

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

最后,这一大堆机器和设备都放在一起,你的安全就是一个挑战,一方面是Security,另一方面是Safety,保证数十台数百台的设备的安全还好说,但是对于数万数十万台的设计,就没有那么简单了。

2 应用部署

2 应用部署

所以,面对这样的难题,人是无法搞得定的,你只能依靠技术来管理和运维整个平台。比如必须有监控系统。这跟操作系统一样,对资源的管理,对网络流量、CPU利用率、进程、内存等等的状态肯定要全部收集的。收集整个集群各种节点的状态,是必然每个云计算都有的,都是大同小异的。

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

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

然后,你还要找到可用性更好的节点,这需要有一些故障自检的功能。比如阿里云就遇到过磁盘用到一定时候就会莫名其妙的不稳定,有些磁盘的I/O会变慢。变慢的原因有可是硬盘不行了,于是硬盘控制器可能因为CRC校验出错需要要多读几次,这就好比TCP的包传过来,数据出错了,需要重新传。在这种硬盘处理半死不活的状态时,你肯定是需要一个自动检测或自动发现的程序去监控这种事情,当这个磁盘可能不行了,标记成坏磁盘,别用它,到别的磁盘上读复本去。我们要有故障自动检测、预测的措施,才能驱动故障,而不是被动响应故障,用户体验才会好。换句话说,我们需要自动化的、主动的运维。

· 场景繁多

· 场景繁多

为了数据的高可用性,你只能使用数据冗余,写多份到不同的节点——工业界标准写三份是安全。然而,你做了冗余,又有数据一致性问题。为了解决冗余带来的一致性问题,才有了paxos的投票玩法,大家投票这个能不能改,于是你就需要一个强大的控制系统来控制这些东西。

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

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

另外,公有云人来人往,里面的资源和服务今天用明天不用,有分配有释放,有冻结,你还要搞一个资源管理系统来管理这些资源的生命状态。还有权限管理,就像AWS的IAM一样,如果没有像AWS的IAM权限管理系统,AWS可能会不会像今天这样有很多大的公司来用。企业级的云平台,你需要有企业级的运维和管理能力。

· 依赖复杂

· 依赖复杂

云计算的门槛

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

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

为啥云计算有这么多开源的东西,却不是人人都能做?我觉得有以下原因:

· 配置各异

· 配置各异

一方面,这就跟盖楼一样。盖楼的技术没什么难的(当然,盖高楼是很难的),但是你没地你怎么盖?我觉得云计算也一样,带宽的价格贵得就像土地的价格。其实云计算跟房地产一样,要占地、占机房、占带宽。如果能把中国所有的机房、机柜、带宽资源都买了,你就不用做云计算了,卖土地就够了——因为这些是有限的。最简单的例子,IP地址是有限的。你有带宽、有机房,但是如果你没有IP,这就不好玩了。尤其是你要提供CDN服务,这个就更明显,因为有多少物理节点直接决定你的CDN服务质量。

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

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

另一方面,正如前面所说的,运维是件很难的事,运维这个事并不是一般人能搞的事。没有足够的场景、经验和时间,这种能力很难出现。

3 应用部署技术发展历程

3 应用部署技术发展历程

奥门威尼斯网址,从用户的角度来说呢,云计算是一种服务,你需要对用户企业内的解决方案要有很好的了解,这样才能提高很好的服务。能提供“好服务”的通常都是把自己真正当成用户公司。

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

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

这跟做汽车一样,底层做引擎、轮子、油箱、控制系统,给你弄一堆零件,上层可以拼装。PaaS相当于给你一个很快可以打造成的汽车的工作台。而SaaS就是成品——两厢、三厢、卡车、轿车,最终用户要的是这个。后面什么Xen、存储、分布式,跟我一毛钱关系没有,我就要知道汽车是安全的,性能好的,省油的,不会抛锚、耐用的,千万别速度快了或者坡度大了或是别的怎么样就失灵了。

3.1 手工安装配置

3.1 手工安装配置

卖汽车也是卖服务。造出汽车来,并不代表你搞定这个事了。如果没有公路、没有加油站、没有4s店、没有交通管理、规则等等,你要么用不了,要么就是乱七八糟。不能只让用户在那看着你的汽车好牛啊,但是用户不知道怎么用。所以说,云计算最终旁边必须要有一套服务设施,而这套服务设施也是今天被人低估的。

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

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

云计算有两个东西我觉得是被人低估的,一个是运维,一个是那堆服务。做服务的需要有生态环境,有人帮你做。所以做云计算要落地并不简单。

奥门威尼斯网址 3

奥门威尼斯网址 3

这跟IBM一样。IBM有段时间也是快不行了,他们的CEO写了一本《谁说大象不能跳舞》,讲IBM的转型,从卖硬件的转成卖服务、解决方案,有流程、咨询,顺便卖硬件,带着一堆系统集成商一起玩。我给你解决方案,谁来实现呢,就是集成商帮你,然后顺便把硬件卖给你。一样。未来是什么样,历史上已经有了。你看,要干那么多事,而且还不是用人堆就可以堆出来的。这就是云计算的门槛。

3.1.1 优点

3.1.1 优点

总之,云计算是需要吃自己的狗食才能吃出来的,绝不是像手机上的Apps一样,你想一想、试一试就能搞出来的,你首先需要让自己有这样的场景,有这样的经历,你才可能会有这样的经验和能力。

3.1.1.1 灵活性高

3.1.1.1 灵活性高

云计算的市场细分

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

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

市场细分必然是市场来驱动的。市场变化太快,说不清楚,不过大的方向应该会是这样的:有类是需要玩计算密集型的(比如大数据计算、网络游戏),有类是需要玩IO密集型的(比如视频网站),有类就是为了建网站的(比如电子商务、门户网站、无线),有类是为了数据安全和保密的(比如金融数据)。

3.1.1.2 学习门槛低

3.1.1.2 学习门槛低

从更高的层面来看,社会也需要分工。有的人卖土地,有的人卖房子,有的人装修,有的人是中介。我相信没人愿意把所有的赌注都押在一个地方。云计算也是一样。上面也说过,无论IaaS、PaaS、SaaS,后面的S都是service,本质上都是提供服务。所以,我认为,市场的细分本质上就是服务的细分。

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

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

看看历史我们知道,细分永远是跟着行业走的,也是跟着业务走的,所以,在业务层会出现更多的细分。

3.1.2 缺点

3.1.2 缺点

对阿里云产业细分的看法

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

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

政府云、金融云不太清楚,不过我很清楚电商云——就是我之前负责的聚石塔。聚石塔时间不长,2012年9月正式上线,去年是大发展的一年,作为垂直云解决的很好。天猫和淘宝做的都是下单前的东西,下单后,商家每天处理好几百单,需要做订单合并、筛选,有的商家规模不大但订单很多。海尔有ERP,这些商家没有,但是每天也1000多单,如果没有信息化的系统,人肉是处理不了的,必然要有ERP系统处理订单。另外还要管理用户,给用户做营销、发展忠实用户。总之,都是卖东西以后的事情。咋办?

3.1.2.1 文档不精确

3.1.2.1 文档不精确

淘宝天猫给了一堆开放API,你可以调我的API接入,在你那边有ISV帮你做一套东西远程访问淘宝API,把订单拉过去,仓库进货了之后,通过API把库存改一下,就可以连起来了。天猫用户下单,到他的系统、他的仓库,他就发货了,仓库补完货,在他的系统里一改,自动就到天猫店了。这是电子信息化。

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

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

但是一到双十一就受不了:订单量太大。正好云平台出现了,再怎么样,阿里的运维能力也要比你商家的要强吧。你看,聚石塔卖的是服务,不是主机。另外是数据安全:商家的系统天天被黑客盯着,如果我们把用户信息都给商家,不是所有的商家的系统安全都做得很好,内部的人插个什么U盘,上面一堆木马,数据就被偷走了。偷走了之后,别人还说是阿里搞丢的,这当然不行。所以,我们又要开放,还要保证安全,聚石塔这个云平台就这样出来的:你来我这儿,我才开放给你,因为安全很重要。

3.1.2.2 效率低

3.1.2.2 效率低

保证性能和安全也是商家的利益诉求也在里面,商家也不希望用户数据被偷,他也希望双十一能抗住。

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

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

另外,很多商家自己不会做,所以要ISV(第三方软件开发商)来做,所以这个是卖解决方案,跟IBM很相似。银行要一套系统,IBM提供硬件和解决方案,系统集成商来帮银行写代码和集成系统。聚石塔也很像,聚石塔提供API、ECS、数据库,第三方的ISV进来帮商家集成一个系统。这是很经典的也是很传统的IBM的玩法,只不过是玩在了云端。

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

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

你看,这也是做自己的长项做出来的细分市场。所以说,吃自己的狗食很重要。

3.2 自动化部署:shell脚本

3.2 自动化部署:shell脚本

对PaaS的看法

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

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

无论是Google的GAE还是新浪的SAE都是给个容器,给个容器的好处是不用管数据连接、CPU什么,程序一传就能用,什么水平扩展都不用管。不爽的是,一个是在编程上限制太多:AppEngine总会阉割很多系统相关的功能,比如Java、PHP、Python的很多系统调用都阉割了,因为如果给你这些系统调用,你就可以突破沙箱;另一个是有故障的时候:技术人遇到问题都恨不得自己上去解决,想看看后面在忙啥,但是看不到,很无助,只能等你解决,就看你的人解决的好不好、快不快。所以如果IaaS没做好,运维、故障自动处理、迁移没做好,出了问题用户只能干瞪眼,PaaS必然不好用。当然IaaS层也有这个问题,但是至少你还可以登到机器上看一看,大不了重启一下。像AWS,你重启一下就跑到别的物理机,问题也许就解决了。

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

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

其实,对于PaaS中间这层的确很尴尬。怎么解决?我觉得还是要依赖某种业务场景。单纯一个平台要阉割很多功能,搞得用户不舒服,还不如干脆一步到位,根据业务场景给一个编程框架。比如SAE可以就做微博app,上来就调API,数据库都ready;或者微信如果做个PaaS,上面只玩微信公众平台上的东西,也可以。我觉得PaaS层更贴合业务会更成功。给新浪微博做个插件,你去买个VM、买数据库?这种时候很需要PaaS。我觉得PaaS层要成功就要贴近业务场景。比如:腾讯的风铃系统(虽然不知道企业帐号看见是什么样的),就做无线建站,这样多好。干巴巴的PaaS有点高不成低不就。

奥门威尼斯网址 5

奥门威尼斯网址 5

对SDN的看法

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

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

SDN其意图是想改变目前超级复杂的网络结构。意图是挺好的。想一想,如果以后我家的网络不用因为买个新的路由器都要重新设计一把,只要一次设置,然后对所有的路由器都通过,的确是挺方便的,这点对企业非常好。不过,不知道在操作上怎么做,也许会从企业内部开始这场革命,这个不得而知。

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

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

就像开车一样,机械式的方向盘和刹车油门系统这么多年都没什么变化,也提过很多更好更高科技的解决方案,但是传统还是这样延续下来了。所以,SDN真不知道未来会怎么样。总之,一个老的事物到一个新的事物需要有一个过程,这个过程中会出现很多过渡产品或是过渡方案,如果没有这些过渡产品和方案,也就没法达到新的事物。未来是什么样,无法预知。

3.2.1 优点

3.2.1 优点

对私有云的看法

3.2.1.1 精确

3.2.1.1 精确

私有云跟公有云,都会存在。这跟人一样,私人生活和公众生活都会需要的。大公司有1万、2万人,这么多数据,要存,需要一个很稳定的解决方案。要稳定可以买IBM,但是贵。云计算出来说,我可以写三份,但他不想上公有云,我的数据放在别人那里,总感觉不好的,所以有了私有云做物理隔离,他觉得安全。

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

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

安全这个词对应两个英文,security和safety,其实security和safety不一样:云计算解决safety,保证数据不丢;宁可数据丢也不让人看到,那是security。比如私人照片我更愿意存家里,有一个小的云存储,所有设备同步,跟老家父母同步,这样比较好。放公网很恐怖。

3.2.1.2 效率高

3.2.1.2 效率高

一定会有公司不愿意上云的,比如金融方面的企业,他们觉得互联网不安全,他们要的更多的是安全。在公网上你的系统的安全攻防能力都要跟上,但如果物理不通的话就不用考虑的太复杂。企业内部私有云肯定有市场。你看,好些企业内部目前还被EMC、IBM所垄断着呢。计算机发展史就是廉价的东西取代昂贵的东西,所以私有云一定没问题,而降低私有云的运维复杂度、提供一个或多个方便的运维系统和工具就是重中之重中。其中,SDN之类的东西肯定会是其中一个很重要的一块。

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

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

另外,还是那句话,云就是服务,只要提供了好的服务,无论公有还是私有都是会有价值的。

3.2.2 bash的缺点

3.2.2 bash的缺点

本文转载自infoQ

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

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

3.2.2.1 缺少高级语言特性

3.2.2.1 缺少高级语言特性

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

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

3.2.2.1 工具链不丰富

3.2.2.1 工具链不丰富

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

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

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

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

3.3 自动化部署:运维DSL

3.3 自动化部署:运维DSL

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

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

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

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

4.1 部署工作代码化

4.1 部署工作代码化

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

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

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

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

4.2 运维代码版本化

4.2 运维代码版本化

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

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

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

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

4.2.1 新建分支

4.2.1 新建分支

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

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

4.2.2 差异比较

4.2.2 差异比较

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

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

4.2.3 历史归档

4.2.3 历史归档

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.3 测试环境高保真

4.3 测试环境高保真

很多公司的测试和生产环境存在操作系统不一致、软件版本不一致、配置项不一致的情况。这种不规范的运维有两大后果:一是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 工作流

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

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

奥门威尼斯网址 7

奥门威尼斯网址 7

这个流程图只展示了最基本的要求:部署到生产环境前必须经过测试环境验证。更复杂的还有代码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年,我对运维做了这么多展望,技痒难耐,决定再实践一次“你行你上”,于是我自投资金百万,做了“运维厨房”这样一个自动化运维平台。在这里就不再多做阐述了。

奥门威尼斯网址 9

奥门威尼斯网址 9

作者介绍:覃健祥

作者介绍:覃健祥

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

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

【编辑推荐】

【编辑推荐】

发表评论

电子邮件地址不会被公开。 必填项已用*标注