关于国内IaaS市场的一些个人看法

By , February 27, 2013 4:45 pm

前段时间我通过电子邮件接受了《网络世界》记者于翔的采访,就国内的IaaS市场发表了一些看法。于翔关于国内IaaS市场一系列的综述性文章今天正式发表,其中引用了我的一些观点。我在接受采访时还对国内的IaaS市场做了一些分析,但是没有被收录在于翔的文章中。我把采访提纲中的主要观点重新整理了一下,算是对《网络世界》这篇专题的一点补充吧。

特别需要说明的是,本人的博客文章仅仅代表个人观点,而不代表本人所在公司的观点。

(1)如何评价中国IaaS市场的整体发展?

目前国内的公有云市场的不可知与不可控因素比较多。从服务提供商的维度看,传统IDC服务提供商、大型互联网企业、以及小型创业公司同场竞技,似乎是百花齐放百家争鸣的一片大好局面;从具体产品的维度看,大部分所谓“云计算”产品基本上还停留在国外五年前的虚拟主机这个层次,而忽视用户体验已经成为整个行业的共同特征;从服务质量的维度看,大部分服务提供商没有为产品提供SLA保障,整个行业普遍缺乏质量评估与质量控制体系。在整个行业成熟度较低的情况下,部分规模较大的服务提供商已经开始通过价格战抢占市场。这样的短视行为使得公有云市场在短时间内沦落为红海,公有云服务沦落为物廉价美的代名词,也导致公众普遍认为使用公有云服务存在较大的风险。

相比之下,国内的私有云市场显得相对成熟。大型互联网企业基本上都有自己的私有云规划,部分先行者已经完成私有云的实施。更重要的是,地方政府和传统行业的IT部门纷纷表示出对云计算的兴趣,开始评估实施云计算所需要的投入以及可能的收益。在过去两年间,国内市场上涌现出大量在国外开源软件的基础上简单地改头换面后形成的自有品牌云管理平台,其目标客户基本上都是地方政府和传统行业的IT部门。可以比较乐观地认为,国内的私有云市场已经开始进入了收割期。

对于公有云市场来说,主要的困难在于解决用户的信任问题。经过多年的市场培育,现在很多用户已经逐渐接受了公有云服务的概念,并且愿意使用Amazon或者Linode等等国外云主机服务,但是对使用国内云主机服务心存疑虑。在过去两年间,阿里云和盛大云都发生过云主机宕机以及用户数据丢失的事故,使得原本就很突出用户信任的问题雪上加霜。除此之外,由于国家政策以及运营商之间恶性竞争等等原因,数据中心之间的互联互通问题非常突出。这使得公有云服务降级为通过物廉价美的VPS替代价格昂贵的主机租赁业务,无法承载大型互联网应用的压力,更无法成为培育新型应用和新型业务模式的温床。

对于私有云市场来说,最大的困难则在于降低客户的期望值。特别是在非IT行业,云计算的推广基本上是销售先行吹牛,技术跟进善后。这样造成的结果就是客户认为云计算几乎是无所不能的,就像前几年被神化的ERP一样,云计算俨然已经成了解决企业IT问题的新万金油。需要强调的是,云计算不是一种新的IT技术,而是一种新的IT模式。这种新的IT模式要求用户以新的方式来使用IT资源,譬如说应用程序需要考虑虚拟机的性能特性,需要从架构层面支持横向扩展,甚至是逐步具备“云觉知”的能力。如果客户仅仅是打算把历史遗留应用迁移到云平台上的话,可能不能够充分发挥云计算的优势,甚至是得到完全相反的效果。

(2)如何看待国际IaaS服务提供商进军中国市场?

亚马逊和微软的云服务进入中国,对本土IaaS服务提供商而言仅仅具有参考作用。在技术层面上,本土研发团队应该早就对亚马逊和微软的云服务有所了解,没有在其产品中提供与亚马逊和微软类似的功能应该是出于市场方面的考虑。在市场层面上,国外大企业或者由于法律和道德方面的双重制约而不具备与国内企业进行正面竞争的能力(例如搜索领域的谷歌),或者只能够在牺牲服务水准的前提下与国内企业进行竞争(例如电商领域的卓越亚马逊)。可以认为,亚马逊和微软的云服务在国内也许可以落地,但是其发展前景并不乐观。整体来说,中国的电信市场是一个保护性非常强的市场,这一点给国外厂商所带来的不便要远大于给本土厂商所带来的不便。对于本土IaaS服务提供商而言,不存在所谓时间窗口的问题,只有国际巨头什么时候黯然离场或者是沦落为本土厂商的问题。

(3)如何看待IaaS服务提供商的混合交付能力?

从现阶段的情况来看,国内大部分公有云产品基本上还停留在国外五年前的虚拟主机这个层次,尚不具备提供混合交付的能力。从技术层面来考虑,提供混合交付能力需要服务提供商支持一系列类似于AWS API的编程接口,目前大部分国内厂商都具备实现这些编程接口的能力。从市场层面来考虑,提供混合交付能力意味着用户能够在公有云和私有云之间进行切换,也意味着用户能够在不同的公有云之间进行切换。换句话说,提供混合交付能力意味着存在用户流失的风险,规模较大的服务提供商一般不会主动拓展这方面的能力,但是处于起步阶段的创业企业有可能会将此作为吸引用户的重要特性。

(4)如何看待企业内部私有IaaS服务?

Eucalyptus公司在中国的业务主要帮助企业规划和建设自己的私有云。我们的客户主要集中在政府、教育、制造、流通等行业。我们的客户对于披露与自身相关的信息存在一定的顾虑,因此我们无法提供与客户或者项目相关的信息。

通常来讲,传统行业的私有云客户不仅仅是为了整合服务器资源而部署IaaS。他们在弹性负载均衡、自动横向扩展等等方面的需求超过一般人的想象。要满足这方面的需求,往往意味着需要对现有应用进行改造,或者是将应用部署在PaaS之上。前面我们已经说过,不同的客户对IaaS有不同的期望值,部署IaaS之后的使用情况也不尽相同。

(5)如何看待IaaS领域开源与闭源多种解决方案群雄并起的局面?

竞争促进创新,多家厂商之间的竞争必然会给用户带来实惠,譬如更低的价格和更好的功能。目前云计算市场依然在持续发展之中,远远还没有达到成熟的程度。可以预见,未来这个领域的竞争还有越来越激烈。

关于闭源技术与开源技术之间的竞争,我在去年10月的博客文章《虚拟化、云计算、开放源代码及其他》中曾经有过专门的论述。我们今天所处的商业环境,与上个世纪80年代自由软件运动(Free Software Movement)刚刚兴起的时候已经有了很大不同。自1998年NetScape第一次提出开放源代码(Open Source)这个术语起,开放源代码就已经成为一种新的软件研发、推广与销售模式,而不是与商业软件相对立的替代品了。开放源代码作为一种新的商业模式,并不比传统的闭源模式具有更高的道德水准。同样,在解决工程问题的时候,客户所看重的往往是解决方案的性价比而不是道德水准。

关于开源项目的盈利问题,Marten Mickos(Eucalyptus的CEO)在担任MySQL公司CEO期间曾指出:“如果要在开源软件上取得成功,那么你需要服务于:(A)愿意花费时间来省钱的人;和(B)愿意花钱来节约时间的人。”在中国的商业环境中,IT公司(或者说互联网公司)通常是愿意花费时间来省钱的,而非IT公司(或者说传统行业)通常是愿意花钱来节约时间的。需要指出的是,中国的非IT公司往往不在乎软件是否开源,但是非常注重开源软件的可定制性。

怎样用好Eucalyptus?

By , February 24, 2013 10:24 am

来自OpenNebula项目的Ignacio M. LIorente最近发表了一篇题为EUCALYPTUS, CLOUDSTACK, OPENSTACK AND OPENNEBULA: A TALE OF TWO CLOUD MODELS的博客文章,从应用场景的角度分析了Eucalyptus、CloudStack、OpenStack和OpenNebula这四个云管理平台的不同点。Ignacio认为VMWare vCloud和AWS分别代表了数据中心虚拟化和按需获取计算资源的两种典型的应用场景,如上所述四个开源云管理平台基本上都是以VMWare vCloud或者AWS为参考原型但是在实现细节上又与参考原型有所差别。Ignacio将开源云平台与其参考原型之间的差异之处称为灵活性(Flexibility),并以数据中心虚拟化、按需获取计算资源、低灵活性、高灵活性为四象限将如上所述四个开源云管理平台放到不同的位置(如下图所示)。Ignacio进一步指出这个图例并不是为了说明某个开源云平台优于其他开源云平台,而是为了说明不同的开源云管理平台适用于不同的客户需求以及不同的应用场景。以目前的状况而言,私有云市场规模很大,客户需求以及应用场景之间的差别很大,并不存在一个能够通吃所有应用场景的云管理平台。未来Eucalyptus、CloudStack、OpenStack和OpenNebula这四个云管理平台之间既有竞争也会有合作,并在这种竞争与合作并存的关系中找准适合自己的市场和客户。

CMP_Quadrant1

我基本上认同Ignacio M. LIorente的观点,就是不同的云管理平台适用于不同的客户需求以及不同的应用场景,并不存在一个能够通吃所有应用场景的云管理平台。出于同样的道理,Eucalyptus也有自己所擅长的应用场景,以及自己所不擅长的应用场景。作为Eucalyptus的员工,我自然希望各行各业的用户都使用Eucalyptus来搭建他们的私有云。但是为了能够充分发挥Eucalyptus的潜力,我建议所有潜在的客户首先了解一下Eucalyptus是什么(或者不是什么),Eucalyptus能做什么(或者不能做什么),以及应该如何规划、实施、使用基于Eucalyptus的私有云。

Eucalyptus是(不是)什么?

Eucalyptus是一个开放源代码的、与AWS高度兼容的云管理平台。以AWS为参考原型的各种云管理平台(例如OpenStack)都在某种程度上兼容AWS API,但是只有Eucalyptus将忠诚地兼容AWS API上升到企业战略与核心竞争力的层面。忠诚地兼容AWS API意味着客户能够在私有云环境中继续使用各种现有的与AWS API相兼容的工具、脚本和映像(AMI),能够在基于Eucalyptus的私有云和AWS公有云之间迁移负载和数据,或者是将基于Eucalyptus的私有云作为开发测试环境但是将AWS公有云作为生产环境。

根据Ignacio M. LIorente的云管理平台四象限图,VMWare vCloud和AWS分别代表了数据中心虚拟化和按需获取计算资源的两种典型的应用场景。以数据中心虚拟化为应用场景的云管理平台通常采取自下而上的架构设计,旨在解决数据中心的复杂度问题;以按需获取计算资源为应用场景的云管理平台通常采取自上而下的架构设计,旨在通过简单高效的接口提供计算资源。设计理念上的差异,决定了一个云管理平台很难同时具备VMWare vCloud和AWS的种种特性。Eucalyptus与AWS的高度兼容性决定了Eucalyptus不是VMWare vCloud或者VMWare vCenter的替代品。Eucalyptus和VMWare试图解决的是不同的问题,适用于不同的应用场景,因此具有不同的功能和特性。常常有用户将Eucalyptus和VMWare vCloud或者是VMWare vCenter进行功能或者特性对比。他们没有意识到Eucalyptus和VMWare vCloud或者是VMWare vCenter完全不是同一类型的软件,是没有办法直接进行功能或者特性对比的。

值得一提的是,Eucalyptus是一个开放源代码的产品,但是桉树公司并不为特定客户提供提供软件定制化服务。经常有一些潜在的客户问我们是否可以为其提供定制的版本。的确,作为一个开源项目的主要开发者,桉树公司具备为特定客户提供特定版本的能力,但是桉树公司通常不会这么做。为特定客户提供定制化版本意味着要对产品进行修改,也意味着使用定制版本的用户在升级到Eucalyptus后续版本时可能会遇到不可预知的风险。尽管在短期内定制化版本可能为客户解决了某些问题,但是从长期来看它所带来的问题要大于它所解决的问题。(Eucalyptus是一个开源项目,如果客户愿意并且具备相应的开发能力的话,当然也可以自己对Eucalyptus进行定制化。但是,用户自己对Eucalyptus进行定制化同样也会遇到升级的问题。)

Eucalyptus能(不能)做什么?

目前Eucalyptus的最新发行版本是3.2.1,它能够很好地用作开发测试环境,或者是用来支撑各种可扩展的Web服务。这两个应用场景的共同特点是大量地使用非持久性虚拟机实例(Ephemeral Instance),以及使用弹性块存储(EBS)来保存持久性数据。尽管Eucalyptus也支持从弹性块存储启动(Boot from EBS, BfEBS)的持久性虚拟机实例,但是由于架构设计方面的原因,在一个集群中存在大量BfEBS实例时整个集群的性能会有所下降。一个集群中BfEBS实例的数量越大,集群的性能恶化就越严重。因此,我们不建议客户在Eucalyptus上运行大量BfEBS实例。

Eucalyptus也不能很好地支持各种磁盘IO密集型应用,例如需要高速读写磁盘的数据库应用。严格地说,这不是Eucalyptus自身的问题,而是底层虚拟化技术的问题。目前各种虚拟化技术 - 例如VMWare ESX、Xen、KVM等等 - 已经较好地解决了CPU和内存的性能损失问题,但是在磁盘IO方面还是存在一定的性能损失。因此,我们不建议客户在虚拟机上运行各种磁盘IO密集型应用,包括负载较重的数据库应用。

在VMWare vCenter里面,系统管理员可以根据应用特征为应用定制网络参数。在Eucalyptus里面,如果系统管理员希望具备同样的能力,恐怕他很快就要失望了。为了以简单高效的途径提供计算资源,Eucalyptus尽可能自动化地管理整个私有云的网络配置,留给系统管理员自由发挥的空间不大。

Eucalyptus的硬件拓扑

接下来我们介绍几个典型的硬件拓扑结构,以帮助各位读者深入了解适合Eucalyptus的应用场景。在这些拓扑结构图中有一些缩写,含义如下:

CLC - 云控制器(Cloud Controller),Eucalyptus中的前端组件

Walrus - Eucalyptus中类似于Amazon S3的对象存储服务

CC - 集群控制器(Cluster Controller),管理一个Eucalyptus集群

SC - 存储控制器(Storage Controller),为一个Eucalyptus提供弹性块存储(EBS)服务

NC - 计算节点(Node Controller)

GE - 千兆网

10 GE - 万兆网

FC - 光纤通道

SAN - SAN存储

屏幕快照 2013-02-23 上午10.30.33

上面这个拓扑图展示的是一个只有一个计算集群的小型Euclayptus私有云。在这个私有云中,所有服务器都连接到一台千兆网交换机上,其中CLC和Walrus共同部署在同一台物理服务器上,CC和SC共同部署在同一台物理服务器上,SAN存储通过光纤通道连接到Walrus和SC服务器。如果为了进一步降低成本,SAN存储设备也可以替换成DAS存储设备。

在这样一种拓扑结构下,Eucalyptus使用开源的iSCSI TGT驱动提供EBS服务。大量的实践表明,开源的iSCSI TGT驱动存在稳定性问题,在存储压力比较大的情况下会莫名其妙的崩溃掉。(这个问题不仅仅在Eucalyptus中存在,在所有使用开源的iSCSI TGT驱动的应用中都会发生。)EBS服务存在稳定性问题,意味着处于运行状态的虚拟机可能会突然访问不到挂载的弹性块存储设备,也意味着从弹性块存储启动的BfEBS实例会突然崩溃。这样的拓扑结构部署在对数据持久性要求不高的开发测试环境中的问题不是很大,但是我们不建议客户在对数据持久性要求较高的生产环境中使用。

除了EBS的稳定性问题之外,这个拓扑结构的瓶颈在于SC与整个计算集群之间的连接是一个千兆网。整个计算集群访问EBS服务的吞吐量受到千兆网带宽的限制,有效吞吐量大概在100 MB/s左右。假设每个EBS实例所造成的平均压力为2 MB/s,一个计算集群能够同时支持40到50个EBS实例。假设每个EBS实例所造成的平均压力为4 MB/s,一个计算集群只能够同时支持20到25个EBS实例。需要指出的是,4 MB/s相当于一个质量中等的U盘(USB 2.0)的吞吐能力,其性能远远不及老式笔记本电脑中常用的7200转SATA硬盘,而2 MB/s更是一个性能非常低下的极端情况了。如果客户希望在这样一种拓扑结构下大量使用EBS服务,建议将SC通过万兆网连接到交换机。(现在很多接入交换机都带2~4个万兆接口了,这样的改造成本不大。)经过这个简单改造之后,EBS服务的有效吞吐量一下子增长了10倍,基本可以消除由于带宽限制所带来的性能瓶颈。

屏幕快照 2013-02-23 下午3.27.31

在生产环境中,我们建议客户使用基于IP SAN的存储设备来提供EBS服务。上面这个拓扑图展示的是一个可用于生产环境的Euclayptus私有云。在这个私有云中,所有Eucalyptus前端组件(CLC、Walrus、CC、SC)都部署到独立的物理服务器上,所有可能有大流量的组件(IP SAN、Walrus、CC、SC)都通过万兆网连接到私有云。目前Eucalyptus支持EMC、EqualLogic、NetApp等多个厂商的IP SAN设备,在这种拓扑结构下Eucalyptus使用官方支持的iSCSI驱动EBS服务,其稳定性和可靠性与开源的iSCSI TGT相比都有大幅度的提高。

即使如此,我们依然不建议客户在Eucalyptus上运行大量从弹性块存储启动的BfEBS实例。Eucalyptus的设计初衷是鼓励用户尽可能多地使用非持久性虚拟机实例,在这种情况下虚拟机磁盘映像被存储在计算节点上,虚拟机内部的磁盘IO不会对私有云的网络造成压力,运行在不同计算节点上的虚拟机基本上不会互相影响。由于从弹性块存储启动的虚拟机实例是持久性实例,需要频繁地与存储设备进行交互,对网络带宽的压力是很大的。因此,我们对客户的一般性建议是:(1)尽可能使用非持久性虚拟机实例;(2)在必须使用BfEBS实例的情况下,尽可能将操作系统盘做得比较小,例如10 GB;(3)将操作系统盘与数据存储盘分离,也就是首先启动一个尺寸较小的BfEBS实例,然后挂载一个尺寸较大的EBS卷用于存储持久性数据。

屏幕快照 2013-02-23 下午3.59.12

上面这个拓扑结构可以进一步加以改造,将存储网与业务网分离。这样存储流量就不会对业务流量造成影响,对私有云各个组件的健康监控也可以在存储网上进行。

屏幕快照 2013-02-23 下午3.37.45

当一个计算集群的容量达到极限的时候,可以往私有云中增加新的计算集群进行扩容,就形成了上面这个拓扑结构。

Eucalyptus的使用建议

前面我们已经说过,不同的云管理平台有不同的设计理念,适用于不同的应用场景。有些潜在的客户认为只要投资买了X硬件按照Y拓扑安装好Z软件就可以应付一切类型的应用,这种期望基本上是不切实际的。类似于AWS的云计算更多地是一种新的管理和分配计算资源的理念,而不是一种新的技术。使用类似于AWS的云计算服务要求用户了解一些基本的概念,并且通常需要对应用做一些修改才能够达到最佳的效果。我们给Eucalyptus客户提供的一般性建议包括:

(1)尽可能使用非持久性虚拟机实例;

(2)当必须使用BfEBS实例时,尽可能缩小磁盘映像的尺寸;

(3)使用EBS卷保存持久性数据,并且将操作系统盘和数据存储盘分离;

(4)不要在虚拟机上运行磁盘IO密集型应用;

(5)不要对虚拟机进行纵向扩展,要通过横向扩展提高应用的处理能力;

(6)通过负载均衡实现应用的高可用性;

(7)避免虚拟机级别的在线迁移,当物理服务器需要进行维护时,使用Eucalyptus的维护模式。

屏幕快照 2013-02-23 下午9.35.30

如上图所示,我们建议用户将同一个应用部署到多个计算集群上。

屏幕快照 2013-02-23 下午9.38.08

当一个计算集群发生失效的时候,应用依然是可用的,但是其处理能力降低了。

屏幕快照 2013-02-23 下午9.39.45

对于有计划的系统维护,可以先将应用的负载迁移到不需要进行维护的计算集群上,然后对处于空闲状态的计算集群进行维护。这样既保证了应用的可用性,又保证了应用的处理能力。

需要说明的是,上面我们所提到的“负载迁移”并不是指将一个处于运行状态的虚拟机从一个计算集群动态迁移到另外一个计算集群,而是在另外一个计算集群中基于同样的EMI创建一个新的虚拟机实例,并通过负载均衡设置将应用的负载重定向到新的虚拟机实例。到目前为止,Eucalyptus并不提供VM级别的动态迁移(类似于VMWare vMotion)的功能。对于类似于AWS的云服务来说,最终用户与底层的基础设施是通过多个层次的抽象措施彻底隔离的。对于最终用户来说,他所看到的计算资源只有自己的虚拟机。至于他的虚拟机运行在什么样的物理服务器上以及该服务器上的负载情况,最终用户应该是一无所知的。因此,提供虚拟机级别的在线迁移功能,其实质是违反了通过抽象措施将最终用户与基础设施进行隔离的原则。

在Eucalyptus 3.3中即将提供一个称为维护模式的功能,允许系统管理员将某个计算集群中的特定物理服务器标志为维护状态。这时系统就会自动地将指定物理服务器上的所有虚拟机实例迁移到同一计算集群中的其他物理服务器上。这个功能允许系统管理员对计算集群中的特定物理服务器进行维护,同时又不必清空该计算集群中的所有负载。

屏幕快照 2013-02-23 下午9.44.27

当应用的负载上升时,通过横向扩展提升应用的处理能力。

屏幕快照 2013-02-23 下午9.47.04

在Eucalyptus 3.3中即将提供的实例监控(Monitoring)、弹性负载均衡(Elastic Load Balancing,ELB)、自动扩展(Auto Scaling,AS)功能,会使得应用的横向扩展更加容易。简单地说,实例监控功能允许用户对自己的虚拟机实例进行监控,监控对象包括虚拟机实例的CPU、内存、磁盘IO、网络IO等等;自动扩展功能允许用户设定一些简单的触发参数,并在监控参数达到触发参数要求的时候自动地创建或者是销毁虚拟机实例;弹性负载均衡功能则负责修改与应用相关的负载均衡策略,自动地添加新创建的虚拟机实例或者是移除旧的虚拟机实例。

屏幕快照 2013-02-23 下午9.55.43

综上所述,可以得到我们向客户所建议的一般性的应用架构设计。可以看出,这个架构设计与我们所熟悉的Web应用架构基本上是一致的。一个典型的Web应用,可能仅仅需要进行少量的改动(如果应用在设计之初就充分考虑到横向扩展的话,甚至是完全不需要改动),就可以充分利用Eucalyptus私有云的种种特性。

除此之外,在弹性块存储EBS服务的使用方面,建议各位感兴趣的用户读一读Why EBS was a bad idea这篇文章。尽管我并非完全同意文章中的观点,但是作者的许多观察和思考是值得云管理员和应用开发者深入思考的。

Eucalyptus的容量规划

现在各位读者已经大致了解了Eucalyptus是(不是)什么,能(不能)做什么,以及应该如何使用基于Eucalyptus的私有云。如果您觉得上面这些描述与您的应用场景相符合,并希望使用Eucalyptus来搭建您的私有云的话,我们建议您在动手之前做一些简单的容量规划。容量规划的基本方法,是将可预见的负载与物理资源进行映射,以确保私有云的容量能够承载应用和业务所带来的压力。一般来说,需要进行考察的参数包括CPU(物理核心数量)、内存、网络(吞吐量)、存储(吞吐量和IOPS)。

对于CPU和内存来说,可以通过标准化的VM产品类型(VM Types)进行简单的换算,其结果可以表达为特定的硬件设备可以支撑多少个某个类型的虚拟机实例。

对于网络来说,往往需要对即将运行在私有云上的应用的网络行为进行采样,获取其真实的流量特征,并在此基础上与私有云的网络配置进行对比。

对于存储来说,一个集群的容量往往受限于IOPS而不是吞吐量。上个月Eucalyptus公司的联合创始人之一Graziano Obertelli写了一篇题为Will My Internet Be Faster的博客文章,用较长的篇幅讨论了如何基于IOPS进行容量规划的问题。我将Graziano Obertelli的博客文章翻译为《我的网络会变得更快吗?》,可供参考。

服务等级协议

经常有客户问我们:“用了Eucalyptus之后,是不是就可以保证我的云主机不会宕机了呢?”坦率地说,不仅Eucalyptus不能,其他的云管理平台也不能。

宕机时间,或者说不宕机时间,是数据中心领域的一个奇妙参数,通常被称为服务等级协议(Service Level Agreement,SLA)。服务等级协议是服务合同的一部分,通常用年度不宕机时间百分比(Annual Uptime Percentage)来表示。很显然,根据年度不宕机时间百分比,可以计算出一年内允许宕机的总时间。常见的SLA条款包括99%(一年可以宕机3.65天,也就是87.6小时),99.9%(一年可以宕机8.8小时),99.99%(一年可以宕机53分钟)。Linode的SLA条款为99.9%(一年可以宕机8.8小时),AWS的SLA条款为99.95%(一年可以宕机4.4小时),阿里云的SLA条款为99.9%(一年可以宕机8.8小时),而盛大云则没有任何关于SLA的承诺。通常来说,更高的SLA条款意味这更高的硬件、软件和人力资源投入。到目前为止,尚未出现能够保障100% SLA条款的产品和技术。

其他

成功地运用云计算,需要硬件与拓扑、软件架构、应用场景、容量规划、服务等级协议等等多个方面的准备。我们在前面已经说过,类似于AWS的云计算更多地是一种新的管理和分配计算资源的理念,而不是一种新的技术。使用类似于AWS的云计算服务要求用户了解一些基本的概念,并且通常需要对应用做一些修改才能够达到最佳的效果。成功的云计算要求服务提供商和服务使用者都要为云计算做好准备。如果你只是想延用老的方式来使用云计算,基本上很难获得成功。

 

Eucalyptus私有云 - 从规划到交付

By , February 18, 2013 2:45 pm

我们意识到只有少数大规模的软件部署(包括Eucalyptus和其他软件)是完全按照计划进行的。这个文档简单描述了基于Eucalyptus部署一个应用于生产环境的私有云的关键环节。这个文档的目的是帮助帮助桉树团队与客户方面进行有效沟通,使得部署计划能够按计划进行,以量化的方式评估并记录项目进度,最终向客户交付基于Eucalyptus的私有云。我们并不认为所有的部署都能够精确地按照本文档所描述的步骤 进行。这个文档的目的是为一个新的项目提供一个指导性的框架,帮助桉树团队与客户方面进行有效沟通,制订合理的部署规划,并且按照部署计划付诸实施。

triangle

 

我们将Eucalyptus私有云的规划和实施分为多个环节,其设计原则是上一个环节要为下一个环节的安全实施打好基础。在上面这张图例中,我们将各个环节进行分组,并用不同的层次来表示这些环节在私有云的规划和实施当中的作用。

一个项目可以由桉树的团队来实施,也可以由客户的团队来实施,也可以由桉树的团队与客户的团队来共同实施。无论如何,部署实施的过程都应该按照一定的步骤进行。如果各个步骤的顺序混乱,或者同时进行多个步骤,就会导致项目无法顺利实施。

对于大部分项目来说,桉树团队会参与部署实施的所有环节,只是在不同环节所起的作用有所不同。如果桉树团队没有参与某些环节(具有充分经验或者具有强烈学习意愿的用户可能愿意自己完成某些环节),桉树团队至少应该与客户保持沟通,及时获得与项目相关的更新信息,向客户提出必要的建议,并且在客户需要的情况下提供技术支持。

如下是我们列出的部署实施一个Eucalyptus私有云的关键环节。此后我们会对每一个环节的主要任务、检查参数、以及刹车信号进行详细描述。

  • 步骤一:场景分析
  • 步骤二:部署规划
  • 步骤三:物理部署
  • 步骤四:基础设施的配置与管理
  • 步骤五:基础设施的测试
  • 步骤六:Eucalyptus的安装与配置
  • 步骤七:Eucalyptus的测试
  • 步骤八:Eucalyptus的交付
  • 步骤九:Eucalyptus的维护

步骤一:应用场景分析,基础设施分析,项目实施计划

在这个环节中,我们需要了解具体的应用场景、可以使用的物理资源和预算资源、项目实施计划、以及参与项目规划和实施的人物和角色。

主要任务:

  • 通过与客户进行讨论,详细了解与项目相关的一切信息,包括具体的应用场景、可以使用的物理资源和预算资源(以及资源到位情况)、项目实施计划、以及对项目效果的期望值。
  • 确定客户方面参与项目规划和实施的团队(以及团队成员)、具体角色、具体责任。
  • 确定桉树方面在本项目规划和实施中所扮演的角色以及担负的责任。
  • 确保客户已经向桉树购买恰当的技术咨询或者技术支持服务。

检查参数:

  • 获取完整的客户以及项目资料。
  • 客户对项目整体情况和实施计划有充分的了解。
  • 客户对桉树方面所扮演的角色和担负的责任有充分的了解。
  • 桉树已经确定参与本项目的具体人员。

刹车信号:

  • 没有完整的客户资料或者项目资料。
  • 客户尚未购买恰当的技术咨询或者技术支持服务。
  • 项目资料表明客户的应用场景、设施资源、预算资源、项目团队可能会导致项目失败。

步骤二:部署规划

在这个环节中,我们的目标是细化具体的项目目标,通过与客户讨论达成一个合理的项目实施计划,在此基础上设定关键的时间点。在这里我们以在上一个环节中所获得的信息作为讨论的基础,开始与客户讨论项目实施计划本身。在这个过程中,我们需要尽可能利用现有的、已经经过验证的、与客户的应用场景相匹配的参考构架作为讨论的基础。

主要任务:

  • 与客户讨论并制订部署计划。
  • 制订网络拓扑图、Eucalyptus部署拓扑图、存储部署拓扑图。
  • 制订与客户网络环境密切相关的Eucalyptus配置参数,包括网络名称、网段配置、网卡名称、VLAN范围、存储位置、数据路径等等。
  • 以在上一个环节中所获得的信息作为讨论的基础,判断特定部署配置所能够提供的能力或者容量,并与客户进行讨论。
  • 制订详细的项目实施计划,包括关键的时间点。
  • 制订详细的测试方案。
  • 更新客户资料与项目资料。

检查参数:

  • 客户完全理解项目对物理硬件的要求。
  • 制订并讨论通过相关部署图表。
  • 制订并讨论通过详细项目实施计划,包括关键的时间点。

刹车信号:

  • 未完成相关部署图表。
  • 项目实施计划不合理。
  • 部署规划与项目资料存在严重差异。
  • 项目资料表明客户的应用场景、设施资源、预算资源、项目团队可能会导致项目失败。

步骤三:购买物理资源,部署基础设施

在这个环节中,我们的目标是确保部署规划中所描述的所有基础设施资源已经到位以及正确安装。我们需要确保桉树不在硬件设施尚未完全d 情况下进行部分部署,因此部分部署往往需要对部署规划中所制订的拓扑结构进行修改,并且会给将来实施完整部署带来很大困难。

主要任务:

  • 与客户进行充分沟通,维护并更新相关部署图表。

检查参数:

  • 所有必须的硬件设施已经就位。
  • 电源、网络等等基础设施已经就绪,可以进入配置环节。
  • 明确列出可以配置或者重新配置Eucalyptus所需资源的人员(或者角色)。

刹车信号:

  • 部分资源尚未到位(例如,所有的东西都准备好了但是还差一个SAN存储)。

步骤四:基础设施的配置和管理

在这个环节中,我们所需要的物理资源已经安装完毕以及正常运行。我们需要确保用于Eucalyptus的相关资源处于有效管理的状态、能够提供稳定的服务、并且不会被其他项目挪作他用。此外,我们还需要确保我们已经获得登陆进入各个系统所需要的身份认证信息。

主要任务:

  • 与客户讨论基础设施的配置管理以及监控方案,尤其是这些方案如何与Eucalyptus有效整合。

检查参数:

  • 物理设施已经配置完毕(或者是提供了必要的配置管理工具)。
  • 不属于Eucalyputus的各项服务运行正常(例如物理资源的监控和报警)。
  • 具备访问物理设施的必要权限。
  • 在征得客户同意的前提下,具备从远程访问物理设施的能力(或者是客户已经明确拒绝提供该能力)。

刹车信号:

  • 如果上述检查参数当中有任何一个没有达到要求,均不可以进入后续步骤。

步骤五:基础设施的测试

在这个环节中,我们通过模拟一些影响基础设施正常运转的事件(故障)来对即将运行Eucalyptus的物理设施进行测试。

主要任务:

  • 通过检查、测试、讨论来确定物理设施的健康状况。

检查参数:

  • 测试物理设施的配置管理和监控系统。
  • 确认物理设施的升级维护窗口(或者决定在升级维护期间暂时停用)。
  • 完成模拟故障测试(掉电测试、压力测试、断网测试)。
  • 确认用于运行Eucalyptus的物理设施(从网卡到交换机的物理连接,空闲的VLAN、MultiCast环境、防火墙配置、物理资源的性能测试)。

刹车信号:

  • 如果上述检查参数当中有任何一个没有达到要求,均不可以进入后续步骤。

步骤六:Eucalyptus的安装

在这个环节中,我们在一个稳定的、经过测试的环境上安装Eucalyptus软件。

主要任务:

  • 基于事先与客户制订好的部署规划和拓扑结构安装Eucalyptus的各个组件,或者
  • 为客户提供必要的指导,让客户根据事先制订好的部署规划和拓扑结构安装Eucalyptus的各个组件。

检查参数:

  • Eucalyptus的安装情况与事先制订好的部署规划和拓扑结构完全相符。
  • Eucalyptus的虚拟机、网络、EBS卷功能正常(创建、描述、销毁)。
  • 创建必要的用户帐号,保存必要的登陆凭据(credentials)。
  • 将配置管理以及监控系统与Eucalyptus集成(能够监控Eucalyptus的各个组件以及虚拟机)。
  • 将用户的工作流管理工具与Eucalyptus集成。
  • 完成制订Eucalyptus备份方案,必要的工具已经安装完毕并且通过测试。

刹车信号:

  • 如果上述检查参数当中有任何一个没有达到要求,均不可以进入后续步骤。

步骤七:Eucalyptus的测试

在这个环节中,我们通过模拟负载或者真正负载对Eucalyptus进行压力测试,验证我们所规划并部署的物理架构资源以及Eucalyptus部署方案是否能够满足负载要求。

主要任务:

  • 根据事先制订好的测试计划对Eucalyptus的各个组件进行性能测试,或者
  • 为客户提供必要的指导,让客户根据事先制订好的测试计划对Eucalyptus的各个组件进行性能测试。

检查参数:

  • 至少在Eucalyptus上运行一部分真实的应用,并对其负载进行采样。
  • 测试云平台可以支撑虚拟机、EBS卷、Walrus、网络的最大规模。
  • 完成模拟故障测试(掉电测试、系统重启、网络重启)。

刹车信号:

  • 如果上述检查参数当中有任何一个没有达到要求,均不可以进入后续步骤。

步骤八:Eucalyptus的交付

通过严格的测试之后,我们需要向客户交付可以用于生产环境的Eucalyptus云平台,并与客户共同制订为生产环境提供维护和支持的相关程序。

主要任务:

  • 与客户讨论并制订长期维护程序和维护计划。
  • 回顾部署实施期间发生的任何与部署规划不相符合的配置、临时性方案、替代方案、警告信息、特别的措施,并更新客户资料与项目资料。

检查参数:

  • 确定维护窗口,规划第一个维护窗口。
  • 制订未来的升级计划和升级程序。
  • 制订技术支持的程序(响应事件、远程支持、越级程序)。
  • 制订基本的除错规范。
  • 制订从备份恢复规范。
  • 客户已经具备独立管理私有云的能力,但是在必要的情况下还需要从Eucalyptus获得技术支持,需要与客户签订必要的服务协议。
  • 更新客户资料与项目资料,记录项目投入生产的细节。

步骤九:Eucalyptus的维护

最后,我们需要为已经部署的Eucalyptus提供不间断的维护和支持,直到所部署的云平台已经被客户弃用为止。

主要任务:

  • 在Eucalyptus发生问题的情况下,为客户提供必要的技术支持。
  • 产品升级、新增功能、安全补丁、其他技术补丁。
  • 与客户保持沟通,为后续研发工作收集必要的反馈信息(产品缺陷、新增功能)。

打油一首

By , February 3, 2013 4:30 pm

某日,在微博上“遇见”某文中师妹,得打油诗一首。

文昌河畔浪荡子,
紫贝山阳戏娇娘。
微博相见不相识,
阿飞亦是文中郎。

Panorama Theme by Themocracy