实际上SAN、NAS、DAS、FC、ISCSI、FC-SAN、IP-SAN等并不是同一类别的概念。SCSI、FC、NAS、ISCSI等概念指的是存储设备类型，DAS、NAS、SAN等指的是存储系统的网络架构。大家常提到的、主流的存储系统网络架构有DAS、NAS、SAN三种网络结构。其中SAN网络环境中，因采用存储设备类型的不同又可以分为FC-SAN(采用光纤通道存储产品)和IP-SAN(采用ISCSI存储设备)。

存储设备类型介绍

存储设备类型是指通过采用SCSI、FC、TCP/IP，ISCSI等接口类型、数据传输协议、以及不同数据存储介质的存储设备。常见的存储设备类型可为SCSI存储、NAS存储、FC存储、iSCSI存储和磁带存储。

存储设备类型这个概念的核心是设备，指的是由存储介质、驱动器、控制器、供电系统、冷却系统等组成的一个整体。它独立与网络层设备和主机层设备，因此当提到存储设备类型的时候，不要涉及与存储设备连接的网络设备和主机。

存储设备的对外提供的接口是FC光纤通道，按照FC光纤通道协议传输数据的存储设备就是FC存储。存储介质为FC磁盘的存储被称为FC-FC存储。存储介质为SATA磁盘的存储被称为FC-SATA存储。

NAS是一种特殊的存储设备类型，虽然NAS对外提供IP接口，按照IP协议进行数据传输，但NAS*终提供给主机的是一个文件系统，SCSI存储、FC存储和ISCSI等提供给主机的是一个裸的、没有文件系统的逻辑卷，且NAS本身是一个服务器+存储的结构，因此严格上讲，NAS应该能算是一种存储系统结构，而不是一个存储类型。不过很多时候我们都把NAS的服务器+存储结构看成一个整体，这个整体又通过标准的IP传输协议来进行访问和数据传输。因此NAS一般都被认为是一个存储设备类型，NAS既是一个存储设备类型，又是一个存储系统网络结构。

存储设备类型指的是存储设备这一个单体的分类，存储系统的网络结构自然是指存储设备、主机、以及存储设备与主机之间的连接系统所形成的整体拓扑结构。

存储系统网络架构介绍

存储系统网络架构是指存储设备与服务器、工作站等需要进行数据读写操作的主机之间的连接方式，网络拓扑结构、数据读写方式、存储共享方式和数据共享方式。存储系统网络结构不同，存储设备的工作方式、流程和性能就会不同。大家常提到的、主流的存储系统网络架构有DAS、NAS、SAN三种网络结构。其中SAN网络环境中，因采用存储设备类型的不同又可以分为FC-SAN(采用光纤通道存储产品)和IP-SAN(采用ISCSI存储设备)。

目前应用*多的是SAN存储系统，在SAN网络环境中，因采用存储设备类型的不同又可以分为FC-SAN(采用光纤通道存储产品)和IP-SAN(采用ISCSI存储设备)，在存储系统设计中可优先考虑。

今天在论坛看到网友自创的漫画，也许就是随笔画画吧， 且不说这位网友是否真的理解云计算（老实说，我也不清楚云计算是什么。），但确实是这位网友还是很有才的，能把自己的看法用这种形式表达出来，已经很难为 可贵了。

“我看了N多的相关介绍也找不到一个好的解释，应该说是我看不懂吧。

谁给个简单通俗点的解释啊

我看了大概就像是网络硬盘吧可以上传电脑备份和文件的还可以在线编辑本人啥的，没啥特别的啊不是已经实现了，只觉的现在大头就是想把他们规划下罢了，
没 啥特别的怎么那么多公司参与呢”
网络硬盘不是云计算。
————————
什么是云计算呢？
*开始，人们使 用算盘。

后来，人们用电脑。

再后来，人们有了网络。

再后来，中国人口大爆炸，男女比例男的比女的多 3700万，这三千多万人没事干，都去上网。于是服务器吃不消了。

于是人们就发明了牛逼的技术，用更好更多的服务器。

再后来，人更多了，于是服务器也更多了。

但事实上这样的效果并不好，过度繁重的结构加大 了网站设计和构架的难度，而且越是复杂的系统越是不稳定。有可能一个出问题，这样一个完整的系统就彻底挂掉。如果考虑到系统的崩溃情况，那势必要引入一个 更复杂的方案来保证不同的服务器可以做不同的支援。这是一个无解的循环，大量的计算资源被浪费在无限制的互相纠结中，很快到了瓶颈。

人们想，那我不用这么乱七八糟复杂的系统，我上个*其牛逼 的服务器不就好了？可是，太贵了……而且*牛逼的也还没制造出来……

于是人们突然想到了一个好办法。将服务器不是简单的链接起 来，说你是缓存，我是数据库。

而是并发使用系统资源，每个操作请求都可以按照一定的规则分割成小片段，分给不同的机器同时运算，每个机 器其实只要做很小的计算就可以，这是哪怕286机器都轻松完成的。*后将这些机器的计算结果整合，输出给用户。

对用户看来，他其实根本 面对的不是许多机器，而是一个似乎真正存在的计算能力巨大无比的单个服务器。

事实上这个服务器是不存在的。但它拥有着成千上万台服务器 的能力。

下面来看实例。

实际上过程没这么简单。哪怕是统计收集资料的过 程也会占据可怕的处理时间。这就将云计算的任务进一步划分下去，哪个服务器的CPU干什么，处理哪个任务段。 这个其实可以由算法安排成自动分配的。 总之，压榨每一个步骤的潜力，让一个任务被服务器集群们一起上，自然能飞速达成。

别忘了，云计算不是弄个两三台服务器就可以达成的。云 计算虽然和分布式计算有着深厚的渊源，但我们现在说的云计算基本上还是海量级别的服务器基数才能达成的。说成千上万台服务器*不夸张。

过 去我们做的是乘法。用户请求多，计算任务重，那么就把服务器叠加，这是一个计算能力的加法。

云计算走的另一个方向。我们在已有的计算资 源的基础不变的情况下，我们把用户的任务请求做除法，一个请求进来，我们把它变成许多个小任务段，*后汇总出去给用户一个完整的结果。
对用户来 说，他根本感觉不到里面哪个cpu做了什么处理，哪部分是哪部分拼接起来的，他就感觉自己面对一台5亿内存3亿GHZ的巨无霸电脑一样。

用 户对这样的计算莫名其妙，云里雾里的，于是他就把这个东西，叫做云计算。

上面对百度的例子其实连雏形都不算。实际上照样有许多的节 点在里面。但总的意思上没错。工程师主要潜心的是算法，提高输出速度这些方面的考虑。除了初期架构和部署的麻烦外，以后考虑到主要还是搜索引擎本身的功能 实现了。

+++++++++++++++++++++++++++++
PS：以上纯为扯淡。我说的是真是假，哪里可信哪里可以 嘲笑，你自己看着办

云计算 之漫画图解

云计算如今已成为又一风靡的概念，什么是云计算?它究竟怎么工作?将为IT产业带来怎样的变革?

首先，我们看一下云计算的定义： 云端(cloud)就代表了互联网(Internet)，通过网络的计算能力，取代使用你原本安装在自己电脑上的软件，或者是取代原本你把资料存在自己硬 盘的动作，你转而通过网络来进行各种工作，并存放档案资料在网络，也就是庞大的虚拟空间上。我们通过所使用的网络服务，把资料存放在网络上的服务器中，并 借由浏览器浏览这些服务的网页，使用上面的界面进行各种计算和工作。

　　就像是不论 你在哪边都看得到天空，你可以在任何能够使用网络访问的地方，连接你需要的云计算服务，即便你不是在自己的电脑上

看完漫画,你将 更加形象的了解云计算，深入云计算。

云计算细分之七大类商业 模式

云计算时下可谓风靡一时，正如Gartner咨询公司资深分析师Ben Pring所说：”云计算已经成为大家津津乐道的话题”。但问题是每个人看起来似乎都有自己不同的定义。

“云”是个大家熟悉的名词，但当它与”计算”相结合，它的含义就演变的泛泛而且虚无缥缈。一些分析师和厂商将云计算狭义的定义为效用计算(Utility computing)的升级版本：*基本的就是在网络范围内应用虚拟服务器。其他方面的应用也很广泛。

当我们考虑到IT的实际需求时，云计算的概念也逐渐清晰起来：那就是在不需要增加基础设施投入，新员工培训或者*新软件授权的前提下提升闲置资源性能和能 力的一种方法。云计算包含了任何通过网络实时提供订阅型（subscription-based）或者按照使用量付费（pay-per-use）的服务模 式，扩展了IT行业现有的能力。

云计算目前还处于萌芽阶段，有大大小小鱼龙混杂的各色厂商在开发不同的云计算服务，从成熟的应用程序到存储服务再到垃圾邮件过滤不一而足。不错，效用模式 基础架构供应商是提供多种服务，诸如Salesforce.com这样的SaaS（软件即服务）的供应商亦是如此。如今在很大程度上，IT业界必须个别的 去接受云服务，不过云计算的开发商和集成商已经开始初具规模。

根据不同的厂商，分析师和IT用户对云计算的看法，我们将云计算细分如下：

1. 软 件即服务（SaaS）

这种类型的云计算是采用multitenant架构通过网络浏览器将单个的应用软件推广到数千 用户。从用户角度来说，这意味着他们前期无需在服务器或软件许可证授权上进行投资；从供应商角度来看，与常规的软件服务模式相比，维护一个应用软件的成本 要相对低廉。迄今为止Salesforce.com是企业应用软件领域中*为知名的供应商，但是软件即服务（SaaS)在人力资源管理软件方面运用比较普 遍，还有诸如Workday这样的ERP软件供应商。谁又能预测来自Google和oho Office的软件即服务（SaaS)桌面系统应用软件是否会出现突然的飞跃呢？

2. 效 用计算（Utility computing）

这种想法本来并无新意，但这种类型的云计算有了 Amazon.com, Sun, IBM和其他从事存储服务和IT随需访问的虚拟机厂商的参与就焕发出了新的生命力。早期的企业主要将效用计算作为补充，不会应用在关键性任务需求上。但是 时至今日效用计算逐渐在数据中心开始占据一席之地。一些供应商向用户提供解决方案来帮助IT企业从商业服务器开始创建数据中心，诸如3Tera的 AppLogic和Cohesive Flexible Technologies的Elastic Server都提供这种随需服务。Liquid Computing公司的LiquidQ也有类似的服务，能帮助企业将内存，I/0，存储和计算容量通过网络集成为一个虚拟的资源池来使用。

3. 云 计算的网络服务

网络服务与软件即服务（SaaS）是密切相关的，网络服务供应商提供API能帮助开发商通过网络拓展 功能性，而不只是提供成熟的应用软件。他们的服务范围从提供分散的商业服务（诸如Strike Iron和Xignite ）到涉及到Google Maps, ADP薪资处理流程，美国邮电服务，Bloomberg和常规的信用卡处理服务等的全套API服务。

4. 平 台即服务（Platform as a service）

平台即服务（Platform as a service）是软件即服务（SaaS）的变种，这种形式的云计算将开发环境作为服务来提供。你可以创建自己的应用软件在供应商的基础架构上运行，然后 通过网络从供应商的服务器上传递给用户。比如乐高公司（Legos）就是这么做的。但这些服务会受到厂商设计和容量的限制，因此用户就没有足够的自由。代 表公司包括Salesforce.com的Force.com和Coghead。

5. 管 理服务供应商（MSP）

管理服务是云计算*古老的形式之一，管理服务是面向IT厂商而并非*终用户的一种应用软件， 诸如用于电子邮件的病毒扫描服务或者应用软件监控服务。由SecureWorks, IBM和Verizon公司提供的管理安全服务就归为此类，还有目前被Google收购的Postini以云为基础的反垃圾邮件服务。其他的产品还包含桌 面系统管理服务，诸如CenterBeam和Everdream提供的产品。

6. 服 务商业平台

服务商业平台是软件即服务（SaaS）和管理服务供应商（MSP）的混合体，这种云计算服务提供了一种与 用户相结合的服务采集器。在贸易领域中应用*为普遍，诸如费用管理系统能允许用户在用户设定的规格范围内从普通平台上订购与所要求的服务和价格相符的旅游 产品或者秘书台服务，就好比一个自动化服务局，知名公司包括Rearden Commerce和Ariba。

7. 网 络集成

云基础服务的集成尚处于初始阶段。软件服务供应商OpSource目前推出了OpSource Services Bus，使用的就是被成为Boomi的云集成技术。软件即服务供应商Workday*近收购了这一领域中的另外一家公司CapeClear，这家 ESB（企业服务总线）供应商主要从事B-TO-B商业模式的服务。Grand Central公司也致力于向用户提供集成解决方案，日前被Google所收购。

如今，云计算的运用还不是非常广泛，对于云计算更精确 的描述可能是”天空运算”。同时，随着虚拟化和SOA在企业中的逐渐普及，这种想法也开始为大家所认同。可扩展的基础架构应该*终能将每一家企业都*为云 的节点。这是个长期可发展的趋势，但是不可否认的是，云计算在很长的时期内还将是业界争论的难点之一。

八大厂商的云计算理念

这些年 技术产业围绕云计算可谓热点不断，我们将来自8大顶尖*厂商的对云计算的观点逐一盘点并总结如下，希望从深度上让大家更多了解云计算。

	谷 歌CEO埃里克·施密特
云计算就仿佛 银行的自动取款机，我们出门再也不用随身携带大量现钞，可以根据需要随时取用。
	EMC 董 事长兼CEO乔图斯
云计算其本身 的性质就是一个虚拟计算，包含所有的虚拟化应用。
	微 软( 中国 ) 董事长张亚勤
目前炒得火热 的“云计算”并没有新鲜的内容，微软也从未曾落后。
	IBM 赵 维义博士
不同于其他云 计算技术仅能给用户提供开发空间，IBM的蓝云技术能让用户建立多个应用。
	亚 马逊总裁杰夫·贝佐
我们正计划进 军规模为17亿美元的企业运算市场，与IBM、惠普、甲骨文和微软较量。
	Salesforce 贝尼奥夫
Salesforce 新的价格模式和新的特色功能就是，把平台作为一种服务
	SUN 软 件业务部 Brewin
SUN计划利 用核心技术提供一个解决方案，让开发者利用Sun的平台创建应用程序和服务
	HP 执 行副总裁Robison
在惠普，我们 把这种模式称之为“一切皆服务(everything as a service)”

2012年企业云计算及云服务开支将达420亿美元

据市场调研机构IDC称，当下美国的经济危机让那些投资云计算的IT公司看到了希望的曙光，这将给他们未来五年带来大幅度的增长。

基于对企业主管、CIO和其他业务领导的调查结果，IDC近日表示，到2012年在IT云服务上的开支将达到420亿美元，而这个增长部分是由于美国经济 危机以及波及全球范围的经济衰退所推动的。

IDC首席分析师兼高级副总裁Frank Gens发表声明称：“云模式为企业提供了一种获得IT和使用IT的更经济的方法，尤其是在经济衰退的情况下。这对中小企业来说非常重要，而中小企业也正 式任何经济恢复计划的主要目标。”

据IDC称，除了经济危机之外，还有其他三个市场力量正在推动向云计算和云服务的整体转移，其中包括在巴西、俄罗斯、印度以及中国等新兴市场的增长以及来 自这几个市场的收入，还有整个中小企业市场领域。

另外两个促进增长的因素是：帮助这些新市场增长IT收入的传统方式存在的不足;来自那些推出新的基于云技术业务和IT模式的厂商的竞争压力。

虽然IDC对云服务和云计算有着不同的定义，但是IDC认为两个领域都将实现大幅度的增长。IDC将云服务定义为人们用过因特网使用的业务和消费者服务， 云计算则是通过因特网向用户实时提供产品和服务的一种新兴IT配置和模式。

IDC预测，到2012年云计算开支将增长25%，到2013年的增长率将近1/3。

而且，到2012年用户在云产品上的开支将占到整个IT开支的10%，其中包括SaaS和云存储。

他说：“云服务将更多地应用到那些制造、金融、医疗、能源、媒体和其他行业的传统公司中，这些用户需要更好地向现有用户提供服务，同时也需要获得新的客 户、新的增长以及更高的利润。”

这*终自然而然地就要归结于推动云计算的发展，因为这些服务需要高可扩展性、经济实惠的、灵活的IT基础架构来提供支持。随着企业越来越多地依赖于通过网 路向用户提供服务，所以他们对服务器、存储、IP网络架构、系统管理软件等的需求也将有所增长。

倪光南：中国的机会在于云计算尚不成熟

中国工程院院士 倪光南

    特别感谢电子学会召集这个会，云计算是科技前沿，很新。我们如果还搞以前的研究那就不行。云计算我感觉还是一个趋势，每家说的不完全一样，所以说明不成 熟。我觉得这个时机很好，中国一个省等于欧洲一个国家，我们现在有很多比较大的信息系统，我们现在需要探讨的就是能不能以省为单位构建自己的云？这片云不 能交给Google或者IBM？我们怎么构建自己的云？所以这是个机会，是个好东西但也不能炒作。

我们的网络系统变成云结构的，也很复杂，用户的系统很容易把云计算的优势发挥出来。但我们的大企业，政府大的信息系统，我们需要重视。比如重大专项可不可 以支持一下，我觉得适当的支持是没问题的。我们要有一些引导，新技术确实有一定的优势的，更加经济、更加高效。我们可以适当的启动一些支持，引导一下，也 是跟上潮流。从理论上来讲这个云是新的东西，所以整个应用系统都会改变。正好我们有机会拿出我们的方案，哪怕某一个应用上有自己的创新，*后我觉得可以成 立云计算专门委员会，可以去推动云计算的发展。

云计算——你 必须掌握的十大科普知识

云计算这个新名词*近甚嚣尘上，*近周围不少朋友都在谈，有必要写一个关于云计算的科普了。

一般的业界比较喜欢用一些新名词来体现自己的战略眼光和与对手的区隔。当几个月前google提出云计算的概念的时候，amazon说自己做的事情就是云 计算，IBM、intel、Sun都声称自己在云计算领域有深刻的计划。只可惜大家听了半天仍然不知道什么是云计算，依旧云里雾里知道这个与计算有关，干 脆就叫“云计算”吧。

到底云计算是什么呢?

这个问题不好回答，专业一点的回答是：云计算是依靠强大的计算能力，使得成千上万的终端用户不担心所使用的计算技术和接入的方式等都能够进行有效的依靠网 络连接起来的硬件平台的计算能力来实施多种应用。

非专业一点的回答就是，一堆你不需要搞清楚的硬件、软件在服务你。这堆硬件和软件构成的东东大的像朵云彩，又拥有*强的计算能力，这就叫云计算。

那么云计算是怎么来的?我们为什么又需要云计算?

1. 云计算的前身是grid computing。

说起grid computing 可能知道的人就很多了，就是传统的网格计算。网格计算就是将一个计算分割成片段，提交到网络系统上的各个计算机上(格点)，工作做好进行汇总完成。比较流 行的软件例如globe bus + afs(提供存储映射服务)。不过grid一般都是用在学术界，例如cern的几个实验都采用了大规模的grid计算，例如进行新粒子的发现，需要处理t 级别的数据，单台计算机的运算和存储显然是不可能完成的，因此就必须使用网格计算了。

2. 云 计算有实实在在的例子么?

很幸运，我们还可以找到几个：google appengine，Amazon的S3+EC2系统都是云计算的雏形。

3. 云 计算的基础是什么?

*基本的需求：存储+处理器，当然，要支持无数的应用请求并负责保证存储和计算的性能，这两方面 都是挑战。

4. 我自己能够搭建一个云计算环境么?

当 然可以，我们可以利用开源的项目来搭建一个云计算环境：你可以利用hadoop+hbase+php(包装API)也许就实现一个简单的云计算环境。

5. 有没有更简单的例子？

也许一个分布式的邮件系统就是一个云计算的雏形：计算分 布在各个节点上，应用(邮件收发)通过一个统一的平台来处理，也算是符合云计算的定义了，不过只能支持*简单的一种固定应用。

6. 有没有复杂一点的例子?

google的云计算的逻辑关系：gfs 实现存储，bigtable 实现结构化、半结构化数据存储，map/reduce 实现将分布在各个节点上的计算和merage起来，剩下的就是进行job的管理器，管理工作的提交和触发，然后就是我们看到的appengine了。

7. 程序员应该关注哪些软件?

hadoop 项目应该是一个比较有前途的一个，当然powerset在hadoop之上的Hbase应该是一个更接近能够替代简单database的应用。

8. 我 们为什么需要云计算?

很简单，企业的雄心+个人电脑性能进展缓慢+我们处在数据指数膨胀的年代。当我们在 google上提交一个搜索的时候，会有成千上万的计算机被卷入这一个简单的一个查询过程中，未来的计算越来越庞大，到了我们干脆说“云”来替代其中的一 切细节的时候。

9. 云计算平台的下一步是什么?

云 计算api的标准化也许是一个*需要进行竞争的，可惜基础的技术平台的完善还需要时日，而且云计算未来也许会是免费的，这个遵从 “竞争导致利润下降”的原则，难度不是么?当更多的云计算平台出现的时候，然而跑在云上的应用却没有那么多，当然免费的午餐就会来。

10. 还有更有趣的么?

当然，你可以提供一个云计算，利用 google，amazon的云计算包含在你自己的云计算里，然后提供一个统一的api，或者也许未来的云计算会整合在一个，云里雾里，成为一个超大的云 计算平台，那个时候，也许自己家的电脑也可以接入云计算平台成为其中的一个计算的提供者。这个听起来很有意思，不过13年前就已经存在了，那个分布在全球 电脑上的寻找外星et的屏保就是一个云计算的平台，如果他们该行做云计算的话，估计能够盖过 google和amazon。

云计算时下可谓风靡一时，正如Gartner咨询公司资深分析师Ben Pring所说：”云计算已经成为大家津津乐道的话题”。但问题是每个人看起来似乎都有自己不同的定义。

“云”是个大家熟悉的名词，但当它与”计算”相结合，它的含义就演变的泛泛而且虚无缥缈。一些分析师和厂商将云计算狭义的定义为效用计算(Utility computing)的升级版本：*基本的就是在网络范围内应用虚拟服务器。其他方面的应用也很广泛。

当我们考虑到IT的实际需求时，云计算的概念也逐渐清晰起来：那就是在不需要增加基础设施投入，新员工培训或者*新软件授权的前提下提升闲置资源性能和能力的一种方法。云计算包含了任何通过网络实时提供订阅型（subscription-based）或者按照使用量付费（pay-per-use）的服务模式，扩展了IT行业现有的能力。

云计算目前还处于萌芽阶段，有大大小小鱼龙混杂的各色厂商在开发不同的云计算服务，从成熟的应用程序到存储服务再到垃圾邮件过滤不一而足。不错，效用模式基础架构供应商是提供多种服务，诸如Salesforce.com这样的SaaS（软件即服务）的供应商亦是如此。如今在很大程度上，IT业界必须个别的去接受云服务，不过云计算的开发商和集成商已经开始初具规模。

根据不同的厂商，分析师和IT用户对云计算的看法，我们将云计算细分如下：

1.软件即服务（SaaS）

这种类型的云计算是采用multitenant架构通过网络浏览器将单个的应用软件推广到数千用户。从用户角度来说，这意味着他们前期无需在服务器或软件许可证授权上进行投资；从供应商角度来看，与常规的软件服务模式相比，维护一个应用软件的成本要相对低廉。迄今为止Salesforce.com是企业应用软件领域中*为知名的供应商，但是软件即服务（SaaS)在人力资源管理软件方面运用比较普遍，还有诸如Workday这样的ERP软件供应商。谁又能预测来自Google和oho Office的软件即服务（SaaS)桌面系统应用软件是否会出现突然的飞跃呢？

2.效用计算（Utility computing）

这种想法本来并无新意，但这种类型的云计算有了Amazon.com, Sun, IBM和其他从事存储服务和IT随需访问的虚拟机厂商的参与就焕发出了新的生命力。早期的企业主要将效用计算作为补充，不会应用在关键性任务需求上。但是时至今日效用计算逐渐在数据中心开始占据一席之地。一些供应商向用户提供解决方案来帮助IT企业从商业服务器开始创建数据中心，诸如3Tera的AppLogic和Cohesive Flexible Technologies的Elastic Server都提供这种随需服务。Liquid Computing公司的LiquidQ也有类似的服务，能帮助企业将内存，I/0，存储和计算容量通过网络集成为一个虚拟的资源池来使用。

3.云计算的网络服务

网络服务与软件即服务（SaaS）是密切相关的，网络服务供应商提供API能帮助开发商通过网络拓展功能性，而不只是提供成熟的应用软件。他们的服务范围从提供分散的商业服务（诸如Strike Iron和Xignite ）到涉及到Google Maps, ADP薪资处理流程，美国邮电服务，Bloomberg和常规的信用卡处理服务等的全套API服务。

4.平台即服务（Platform as a service）

平台即服务（Platform as a service）是软件即服务（SaaS）的变种，这种形式的云计算将开发环境作为服务来提供。你可以创建自己的应用软件在供应商的基础架构上运行，然后通过网络从供应商的服务器上传递给用户。比如乐高公司（Legos）就是这么做的。但这些服务会受到厂商设计和容量的限制，因此用户就没有足够的自由。代表公司包括Salesforce.com的Force.com和Coghead。

5.管理服务供应商（MSP）

管理服务是云计算*古老的形式之一，管理服务是面向IT厂商而并非*终用户的一种应用软件，诸如用于电子邮件的病毒扫描服务或者应用软件监控服务。由SecureWorks, IBM和Verizon公司提供的管理安全服务就归为此类，还有目前被Google收购的Postini以云为基础的反垃圾邮件服务。其他的产品还包含桌面系统管理服务，诸如CenterBeam和Everdream提供的产品。

6.服务商业平台

服务商业平台是软件即服务（SaaS）和管理服务供应商（MSP）的混合体，这种云计算服务提供了一种与用户相结合的服务采集器。在贸易领域中应用*为普遍，诸如费用管理系统能允许用户在用户设定的规格范围内从普通平台上订购与所要求的服务和价格相符的旅游产品或者秘书台服务，就好比一个自动化服务局，知名公司包括Rearden Commerce和Ariba。

7.网络集成

云基础服务的集成尚处于初始阶段。软件服务供应商OpSource目前推出了OpSource Services Bus，使用的就是被成为Boomi的云集成技术。软件即服务供应商Workday*近收购了这一领域中的另外一家公司CapeClear，这家ESB（企业服务总线）供应商主要从事B-TO-B商业模式的服务。Grand Central公司也致力于向用户提供集成解决方案，日前被Google所收购。

如今，云计算的运用还不是非常广泛，对于云计算更精确的描述可能是”天空运算”。同时，随着虚拟化和SOA在企业中的逐渐普及，这种想法也开始为大家所认同。可扩展的基础架构应该*终能将每一家企业都*为云的节点。这是个长期可发展的趋势，但是不可否认的是，云计算在很长的时期内还将是业界争论的难点之一。

本文写的是云计算下的这些细分领域 你都了解吗？【IT168 评论】云计算的“云”源于绘制互联网的网络图表时的一个习惯——会将其画成一朵云。*受认同的关于云计算含义的解释是，在一个商业供应者的数据中心上通过互联网远程运行工作负载——也就是所谓的“公有云”模式。AWS、Azure、谷歌云等平台都是这一云计算概念的例证。

但是，云计算还有一个更精确的解释：数据中心资源的虚拟化和中心管理。其关键优势是敏捷性：根据工作负载的需求，使用抽象计算、存储和网络等资源，且具备大量的预构建服务。

从客户的角度来看，公有云能够提供一种方式，在不投入新的硬件和软件的情况下，获得新的功能。同时，客户只需按照自己所使用的资源为他们的云供应商支付费用。只要填写web表单，用户就可以设置账户、加速虚拟机或提供新的应用程序。根据客户在运行自己的工作负载时的需求增加更多计算资源，这种特性被称为伸缩性。

云计算中可用的服务种类是很多的，不过主要可以分为以下几类：

SaaS(software as a service，软件即服务)

这种类型的公有云在互联网上通过浏览器对应用程序进行交付。*受欢迎的商务级SaaS应用程序有谷歌的G Suite和微软的Office 365;而在企业级应用中，Salesforce独占鳌头。但是几乎所有的企业级应用，包括从Oracle到SAP的ERP套件，都采用SaaS模型。通常，SaaS应用可提供广泛的配置选项以及开发环境，使客户能够自己对代码进行修改和添加。

IaaS(infrastructure as a service，基础设施即服务)

在基础层面上，IaaS公有云供应商提供存储和计算服务。但所有主要公有云供应商提供的服务都是惊人的：高可伸缩数据库、虚拟专用网络、大数据分析、开发工具、机器学习、应用程序监控等等。AWS是*个IaaS供应商，且目前仍是领袖，紧随其后的是微软Azure、谷歌云平台和IBM Cloud。

PaaS(platform as a service，平台即服务)

PaaS所提供的服务和工作流专门针对开发人员，他们可以使用共享工具、流程和API来加速开发、测试和部署应用程序。Saleforce的Salesforce的Heroku和Force.com是非常受欢迎的公共云PaaS产品;Pivotal的Cloud Foundry和红帽的OpenShift可以在本地部署或通过一些主要的公有云来访问。对于企业来说，PaaS可以确保开发人员对已就绪的资源的访问，遵循一定的流程和只使用一个特定的系列服务，运营商则维护底层基础设施。

值得一提的是，专为移动端开发人员使用的各种PaaS一般被称作MBaaS(移动后端即服务)，或者只是BaaS(后端即服务)。

FaaS(functions as a service，功能即服务)

FaaS，无服务器计算的云实例化，为PaaS增加了另一个抽象层，以便开发人员在堆栈中完全隔*一切优先级低于他们代码的东西。不是去搞虚拟服务器、容器和应用运行时间，而是上传功能代码块，让它们被某个事件触发(例如表单提交或上传文件)。所有主要云都会在IaaS之上提供FaaS：AWS Lambda、Azure Functions、谷歌云Functions以及IBM OpenWhisk。FaaS应用的一个特殊的好处是，在事件发生之前不会使用IaaS资源，可通过降低资源使用率来减少费用。

私有云

私有云可以说是小尺寸的IaaS公有云，使软件可以部署和运行在客户的数据中心。与公有云一样，内部客户可以提供自己的虚拟资源，以构建、测试和运行应用程序，通过计量资源消耗进行收费。对于管理员而言，私有云数据中心*好就是自动化，而*差的情况则是手动配置和管理。VMware的软件定义数据中心栈是*受欢迎的商业私有云软件，虽然OpenStack是开源方面的领袖。

混合云

混合云是私有云与公有云的集成。混合云涉及创建并行环境，是应用程序可以在私有云和公有云之间轻松移动。在其他情况下，数据库可能待在客户数据中心与公有云应用程序集成——在需求高峰期，虚拟化数据中心的工作负载可能会被复制到云。私有云和公有云之间的集成类型差别很大，但他们必须各自互相适应，以成为一个混合云的模式。

公有 API(API，应用程序设计接口)

正如SaaS在互联网上为用户交付应用程序，共有API为开发人员提供应用程序功能，可以以编程的方式访问。例如，在构建Web应用时，开发人员经常会利用谷歌地图API提供行车路线;为了集成到社交媒体，开发人员可能会呼吁API通过Twitter或Facebook被保持。Twilio已经建立了一个成功的业务，致力于通过公共API提供电话和消息传递服务。*终，任何企业都可以提供自己的公有API实现客户消费数据和应用程序功能的访问。

iPaaS(integration platform as a service，集成平台即服务)

数据集成是任何具备一定规模的公司的一个关键问题，尤其对于那些大规模采用SaaS的企业而言。iPaaS供应商通常提供预先构建的连接器，为流行的SaaS应用程序和本地企业应用程序之间提供共享数据，尽管供应商可能或多或少地关注B2B电子商务集成、云集成或传SOA风格的集成。

IDaaS(identity as a service，身份即服务)

在私有数据中心和公有云网站上，与云计算相关的*大的安全问题就是管理用户身份及其相关权利和权限。IDaaS供应商保持基于云计算的用户配置文件,验证用户身份,并使访问资源或应用程序基于安全策略、用户组和个人的特权。能够集成各种目录服务(Active directory LDAP,等等)，而且这是至关重要的。

协作平台(Collaboration platforms)

协作解决方案如Slack、微软Teams和HipChat已经成为重要的信息沟通平台，是组织内部能够有效地沟通和合作。基本上，这些解决方案是相对简单的SaaS应用程序，支持聊天形式的消息传递以及文件共享和音视频交流。大多数提供API来促进与其他系统的集成，使第三方开发者创建和共享插件，增强功能。

垂直云(Vertical clouds)

在金融、医疗、零售、生命科学和制造行业提供PaaS云使客户建立垂直应用程序，接近行业特定的、API-accessible服务。垂直云可以减少垂直应用程序投放到市场的时间，加速特定领域的B2B集成。大多数垂直云的构建都带着一些培养生态合作伙伴系统的目的。

云计算的吸引力与反对意见

云计算的主要吸引力是减少市场投放时间以及应用程序的动态化的规模扩展。不过，越来越多的开发商正将大量先进的服务引进到云中，并且可以合并到应用程序中，从机器学习到物联网。

虽然有时候企业遗留应用程序会迁移到云来减少数据中心的资源需求，但真正的福利在于利用云服务和“云原生”属性增加新的应用程序。后者包括微服务架构、Linux容器，可增强应用程序的可移植性，容器管理解决方案如Kubernetes基于容器的服务编排。原生云方法和解决方案可以是公有云或私有云的一部分，有助于高效使用Devops风格的工作流。

对公有云的反对意见，一般源于安全问题，虽然主要的公有云供应商已经证明自己的数据中心比一般企业更不容易收到攻击影响。更大的问题是客户与公有云供应商之间安全策略以及身份管理之间的集成。同时，政府的监管可能会禁止客户让敏感数据离开本地。其他一些问题包括服务中断的风险和长期运营成本。

但公有云和私有云都已成为大型应用程序的首选平台，尤其是对于那些需要经常动态地改变规模的客户。更重要的是，现在的公有云供应商在技术开发上一直处在前列。企业选择云之后，会源源不断地被邀请使用一些令人兴奋的新技术。

转载于:https://blog.51cto.com/mooon/904854

Hadoop并不完全代表云计算，所以，要用Hadoop搭建完整的云计算平台，答案是不够。我们常说云计算，实际上还是通过计算机的大规模或者 说海量处理来为生活中各式各样的人和各行各业服务——所以，核心在“服务”。关于服务，展开来就是常用的那3种(也是事实上的标 准)：SaaS,PaaS,IaaS。对云计算来说，公有和私有，虚拟和存储，这其实是相对讨论的核心。

回头说Hadoop。在Google三大论文的直接刺激下，Hadoop社区兴起，而在众多的开源实现中，Hadoop(主项目)可以说是所有已知云计算方面开源项目的一个Top项目。

云计算中有哪些构件?发展到目前的技术与规模，并没有一个确切的定论，今天的说的话明天可能就不一样了。但对Hadoop来说，实现了的部分，就是大部分企业在不断发展中所遇到的大部分问题。直接上图：

从整体生态系统的角度，从底层存储，到中间的计算模型和框架，再到上层的逻辑处理和流、显示，都有相应开源的实现。这就是你说的构件了。

包括我们看到的Hadoop2.0中，引入的新的处理框架，Spark，Storm，YARN(取代MR)，都是Hadoop生态系统的完善与实现。

Hadoop实现的是在简易硬件的基础上进行尽量高可用性海量计算与处理的中上层模型。Hadoop处理了存储(也只是一部分)，虚拟化是没有涉 及的，而底层硬件Hadoop也是不涉及的，不管是Hadoop还是其他的项目，只是在软件的层面想通过纵向或者横向的拓展解决所有的问题是不现实的。 Hadoop在硬件这方面，只是在实现中预留或者接入硬件特性，也就是在虚拟化这方面Hadoop只是个“APP”，不是“始作俑者”(用词不当了)。

那么，完整的云计算平台呢?

按照企业级来说，是要看具体的企业方向和企业类型的，包括IBM和VMware都有提供不同的解决方案。大致上一定是由单点–>集群 –>多层(准分布式)–>硬件–>分布式(地域分布)来解决的。具体到Hadoop体系的技术，直接去对应上图就好了。

从云计算这个概念出现到今天，资料可以说“浩如烟海”了，但很多资料只是互相复制黏贴，并没有说到云计算的核心。我想提出的一个观点是，完整的云计算平台，依赖的是业务，提供的是存储与支持。

没有业务需求而是照搬网上的资料或者自认为“活用”了某些技术，都可能只是“娱人娱己”。我们看一下互联网负载均衡技术是如何发展的就就更容易理解云计算：

客户端缓存–>CDN缓存–>Apache&Nginx静态页面缓存–>PHP和Java动态内存 –>Memcache&Other Nosql–>Mysql&Oracle–>HDFS&Other Big Table

从技术的角度看，所有问题解决起来都是层次化的(大家肯定都有写Demo吧)，都是根据不同的需求引入不同的技术，在单层单点乃至集群都无法解决 问题的时候，新的计算框架，云计算与网格计算乃至动画需要的大规模渲染都在需要的时候顺理成章的引入。总之，完整的云计算平台，对于不同的公司业务都是不 同的，拿腾讯来说，平台的组件多如牛毛，“平台”只是提供*基础的服务：存储与支持，其他的都需要业务根据自身的特点在其上进行构建(相信大公司都是有自 己的完整方案的，这里我就不能再说了……)，至于提高什么样级别的这种“服务”，就要看公司的业务规模，需要支撑的体系，乃至公司的决策战略了等等

原文链接:
http://www.open-open.com/solution/view/1426725577820

总结:
1、避免一个bucket写入太多的对象，对新建bucket，限制存储对象的*大数量
2、使用比较新的版本0.94以上修复单bucket索引对象过大问题，在Ceph的0.94版本中，已经支持了bucket索引对象的shard功能，一个bucket索引对象可以分成多个shard对象存储，可有效缓解单bucket索引对象过大问题
3、系统上线前需要经过充分的测试，功能，性能，异常，稳定性以及压力测试(大数据量)

Ceph作为一款开源的分布式存储软件，可以利用X86服务器自身的本地存储资源，创建一个或多个存储资源池，并基于资源池对用户提供统一存储服务，包括块存储、对象存储、文件存储，满足企业对存储高可靠性、高性能、高可扩展性方面的需求，并越来越受到企业的青睐。经过大量的生产实践证明，Ceph的设计理念先进，功能全面，使用灵活，富有弹性。不过，Ceph的这些优点对企业来说也是一把双刃剑，驾驭的好可以很好地服务于企业，倘若功力不够，没有摸清Ceph的脾性，有时也会制造不小的麻烦，下面我要给大家分享的正是这样的一个案例。

A公司通过部署Ceph对象存储集群，对外提供云存储服务，提供SDK帮助客户快速实现对图片、视频、apk安装包等非结构化数据的云化管理。在业务正式上线前，曾经对Ceph做过充分的功能测试、异常测试和性能测试。
集群规模不是很大，使用的是社区0.80版本，总共有30台服务器，每台服务器配置32GB内存，10块4T的SATA盘和1块160G的Intel S3700 SSD盘。300块SATA盘组成一个数据资源池（缺省配置情况下就是名称为.rgw.buckets的pool），存放对象数据；30块SSD盘组成一个元数据资源池（缺省配置情况下就是名称为.rgw.buckets.index的pool），存放对象元数据。有过Ceph对象存储运维部署经验的朋友都知道，这样的配置也算是国际惯例，因为Ceph对象存储支持多租户，多个用户在往同一个bucket(用户的一个逻辑空间)中PUT对象的时候，会向bucket索引对象中写入对象的元数据，由于是共享同一个bucket索引对象，访问时需要对这个索引对象加锁，将bucket索引对象存放到高性能盘SSD组成的资源池中，减少每一次索引对象访问的时间，提升IO性能，提高对象存储的整体并发量。
系统上线后，客户数据开始源源不断地存入到Ceph对象存储集群，在前面的三个月中，一切运行正常。期间也出现过SATA磁盘故障，依靠Ceph自身的故障检测、修复机制轻松搞定，运维的兄弟感觉很轻松。进入到5月份，运维兄弟偶尔抱怨说SSD盘对应的OSD有时会变的很慢，导致业务卡顿，遇到这种情况他们简单有效的办法就是重新启动这个OSD，又能恢复正常。大概这种现象零星发生过几次，运维兄弟询问是不是我们在SSD的使用上有什么不对。我们分析后觉得SSD盘的应用没有什么特别的地方，除了将磁盘调度算法修改成deadline，这个已经修改过了，也就没有太在意这个事情。
5月28日晚上21:30，运维兄弟手机上接到系统告警，少部分文件写入失败，马上登陆系统检查，发现是因为一台服务器上的SSD盘对应的OSD读写缓慢引起的。按照之前的经验，此类情况重启OSD进程后就能恢复正常，毫不犹豫地重新启动该OSD进程，等待系统恢复正常。但是这一次，SSD的OSD进程启动过程非常缓慢，并引发同台服务器上的SATA盘OSD进程卡顿，心跳丢失，一段时间后，又发现其它服务器上开始出现SSD盘OSD进程卡顿缓慢。继续重启其它服务器上SSD盘对应的OSD进程，出现了类似情况，这样反复多次重启SSD盘OSD进程后，起不来的SSD盘OSD进程越来越多。运维兄弟立即将此情况反馈给技术研发部门，要求火速前往支援。
到办公室后，根据运维兄弟的反馈，我们登上服务器，试着启动几个SSD盘对应的OSD进程，反复观察比对进程的启动过程：
1、 用top命令发现这个OSD进程启动后就开始疯狂分配内存，高达20GB甚至有时达到30GB；有时因系统内存耗尽，开始使用swap交换分区；有时即使*后进程被成功拉起，但OSD任然占用高达10GB的内存。
2、 查看OSD的日志，发现进入FileJournal::_open阶段后就停止了日志输出。经过很长时间（30分钟以上）后才输出进入load_pg阶段；进入load_pg阶段后，再次经历漫长的等待，虽然load_pg完成，但进程仍然自杀退出。
3、 在上述漫长启动过程中，用pstack查看进程调用栈信息，FileJournal::_open阶段看到的调用栈是在做OSD日志回放，事务处理中是执行levelDB的记录删除；在load_pg阶段看到的调用栈信息是在利用levelDB的日志修复levelDB文件。
4、 有时候一个SSD盘OSD进程启动成功，运行一段时间后会导致另外的SSD盘OSD进程异常死掉。
从这些现象来看，都是跟levelDB有关系，内存大量分配是不是跟这个有关系呢？进一步查看levelDB相关的代码后发现，在一个事务处理中使用levelDB迭代器，迭代器访问记录过程中会不断分配内存，直到迭代器使用完才会释放全部内存。从这一点上看，如果迭代器访问的记录数非常大，就会在迭代过程中分配大量的内存。根据这一点，我们查看bucket中的对象数，发现有几个bucket中的对象数量达到了2000万、3000万、5000万，而且这几个大的bucket索引对象存储位置刚好就是出现问题的那几个SSD盘OSD。内存大量消耗的原因应该是找到了，这是一个重大突破，此时已是30日21:00，这两天已经有用户开始电话投诉，兄弟们都倍感“鸭梨山大”。已经持续奋战近48小时，兄弟们眼睛都红肿了，必须停下来休息，否则会有兄弟倒在黎明前。
31日8:30，兄弟们再次投入战斗。
还有一个问题，就是有些OSD在经历漫长启动过程，*终在load_pg完成后仍然自杀退出。通过走读ceph代码，确认是有些线程因长时间没有被调度（可能是因levelDB的线程长时间占用了CPU导致）而超时自杀所致。在ceph的配置中有一个filestore_op_thread_suicide_timeout参数，通过测试验证，将这个参数设置成一个很大的值，可以避免这种自杀。又看到了一点点曙光，时钟指向12:30。
有些进程起来后，仍然会占用高达10GB的内存，这个问题不解决，即使SSD盘OSD拉起来了，同台服务器上的其它SATA盘OSD运行因内存不足都要受到影响。兄弟们再接再厉啊，这是黎明前的黑暗，一定要挺过去。有人查资料，有人看代码，终于在14:30从ceph资料文档查到一个强制释放内存的命令：ceph tell osd.* heap release，可以在进程启动后执行此命令释放OSD进程占用的过多内存。大家都格外兴奋，立即测试验证，果然有效。
一个SSD盘OSD起来后运行一会导致其它SSD盘OSD进程退出，综合上面的分析定位，这主要是因为发生数据迁移，有数据迁出的OSD，在数据迁出后会删除相关记录信息，触发levelDB删除对象元数据记录，一旦遇到一个超大的bucket索引对象，levelDB使用迭代器遍历对象的元数据记录，就会导致过度内存消耗，从而导致服务器上的OSD进程异常。
根据上述分析，经过近2个小时的反复讨论论证，我们制定了如下应急措施：
1、 给集群设置noout标志，不允许做PG迁移，因为一旦出现PG迁移，有PG迁出的OSD，就会在PG迁出后删除PG中的对象数据，触发levelDB删除对象元数据记录，遇到PG中有一个超大的bucket索引对象就会因迭代器遍历元数据记录而消耗大量内存。
2、 为了能救活SSD对应的OSD,尽快恢复系统，在启动SSD对应的OSD进程时，附加启动参数filestore_op_thread_suicide_timeout，设置一个很大的值。由于故障OSD拉起时，LevelDB的一系列处理会抢占CPU，导致线程调度阻塞，在Ceph中有线程死锁检测机制，超过这个参数配置的时间线程仍然没有被调度，就判定为线程死锁。为了避免因线程死锁导致将进程自杀，需要设置这个参数。
3、 在目前内存有限的情况下，异常的OSD启动会使用swap交换分区，为了加快OSD进程启动，将swap分区调整到SSD盘上。
4、 启动一个定时任务，定时执行命令ceph tell osd.* heap release，强制释放OSD占用的内存。
5、 SSD对应的OSD出现问题的时候，按如下步骤处理：
a) 先将该服务器上的所有OSD进程都停掉，以腾出全部内存。
b) 然后启动OSD进程，并携带filestore_op_thread_suicide_timeout参数，给一个很大的值，如72000。
c) 观察OSD的启动过程，一旦load_pgs执行完毕，可以立即手动执行ceph tell osd.N heap release命令，将其占用的内存强制释放。
d) 观察集群状态，当所有PG的状态都恢复正常时，再将其他SATA盘对应的OSD进程启动起来。
按照上述步骤，我们从17:30开始逐个恢复OSD进程，在恢复过程中，那几个超大bucket索引对象在做backfilling的时候需要较长时间，在此期间访问这个bucket的请求都被阻塞，导致应用业务请求出现超时，这也是单bucket存储大量对象带来的负面影响。
5月31日23:00，终于恢复了全部OSD进程，从故障到系统全部成功恢复，我们惊心动魄奋战了72小时，大家相视而笑，兴奋过度，再接再厉，一起讨论制定彻底解决此问题的方案：
1、 扩大服务器内存到64GB。
2、 对新建bucket，限制存储对象的*大数量。
3、 Ceph 0.94版本经过充分测试后，升级到0.94版本，解决单bucket索引对象过大问题。
4、 优化Ceph对levelDB迭代器的使用，在一个大的事务中，通过分段迭代，一个迭代器在完成一定数量的记录遍历后，记录其当前迭代位置，将其释放，再重新创建一个新的迭代器，从上次迭代的位置开始继续遍历，如此可以控制迭代器的内存使用量。
前事不忘后事之师，汲取经验教训，我们总结如下几点：
1、 系统上线前必须经过充分的测试
A公司的系统上线前，虽然对ceph做了充分的功能、性能、异常测试，但却没有大量数据的压力测试，如果之前单bucket灌入了几千万对象测试，也许就能提前发现这个隐患。
2、 运维过程中的每一个异常都要及时引起重视
此案例中，在问题爆发前一段时间，运维部门已经有反馈SSD异常的问题，可惜没有引起我们重视，倘若当时就深入分析，也许可以找到问题根由，提前制定规避措施。
3、 摸清ceph的脾性
任何软件产品都有相应的规格限制，ceph也不例外。如果能提前深入了解ceph架构及其实现原理，了解单bucket过度存放大量对象所带来的负面影响，提前规划，也不会出现本案例中遇到的问题。RGW对配额的支持非常全面，包括用户级别的、bucket级别的，都可以配置单个bucket允许存放的*大对象数量。
4、 时刻跟踪社区*新进展
在Ceph的0.94版本中，已经支持了bucket索引对象的shard功能，一个bucket索引对象可以分成多个shard对象存储，可有效缓解单bucket索引对象过大问题。

原文链接:
http://stor.51cto.com/art/201803/567763.htm

OpenStack和CloudStack都是功能强大的开源云平台，那OpenStack是凭借什么，在百花齐放的云计算战场取得如此大幅度的*优势呢？本文基于”用户倾向于云计算的理由”这个角度，对OpenStack和CloudStack进行对比，试着来寻找答案。

短短几年间，云计算已不再虚无飘渺，而是落入凡间，变成实实在在的技术。而开源技术更是逐渐成为对公司、厂商更有吸引力的选择。大概一周前，Zenoss刚刚完成了一份名为“2014开源云计算解析”的市场调查显示，69%已经不同程度地应用云计算技术，43%的用户花费大量资源在开源技术上。

在这些选择了开源云的企业中，超过86%的企业关注OpenStack,并且这些数值在过去几年都在不断增长。 排在第二位的CloudStack则被远远甩在后面，只有44%。

OpenStack和CloudStack都是功能强大的开源云平台，满足企业私有云建设的需求，并且因为开放开源，都可以根据需要进行定制。那是什么原因使OpenStack 在这场开源云计算的战争中笑傲群芳呢？

对于用户倾向于开源云计算的理由，在这份Zenoss的报告中的数据也有显示，诸多原因中以下四种*为重要：

灵活性（71%）
避免被厂商锁定（66%）
更低的成本（66%）
开放的标准和API(60%)

那么本文，我们就将讨论的重点放在冠军OpenStack和 亚军 CloudStack上，先从这四个回合看看冠军OpenStack 和亚军 CloudStack分别是怎样迎接这场开源云战役的。

选手简介:

OpenStack由NASA和Rackspace公司在2010年联合发布，两者分别贡献计算代码（Nova）和存储代码（Swift），以Apache许可协议进行授权。OpenStack的目标是提供一个既可以用来建设公有云也能建设私有云的通用的开源云计算平台，而且做到云平台的搭建尽量的简单方便，同时能够快速的横向扩展。

CloudStack*初由Cloud.com公司开发，分为商业和开源两个版本，开源版本通过GPLv3（GNU General Public License, version 3）许可协议进行授权，Citrix公司在2011年收购Cloud.com后，将全部代码开源，并在2012年将CloudStack贡献给Apache软件基金会，成为Apache的孵化项目，同时将授权协议改为更加宽松开放和商业友好的Apache许可协议，CloudStack在2013年3月份升级为Apache的正式项目。CloudStack的目标是提供高度可用的、高度可扩展的能够进行大规模虚拟机部署和管理的开放云平台。

Round 1:灵活性

OpenStack由几个主要的组件组合起来完成具体工作，采用分布式架构。整个平台按照功能不同分为多个模块项目，项目之间通过消息队列中间件和RESTful形式的API进行交互通信，因此每个项目都可以单独部署在不同的主机上，支持几乎所有类型的云环境。

CloudStack采用集中式的单体架构（Monolithic architecture），整个平台只有一个项目构成，不同模块之间通过的本地调用进行交互，在一台主机上就可以完成平台的部署，非常方便。

可以看到，两者的架构几乎是相对的，OpenStack的分布式架构灵活性好，缺点每个项目都要部署配置一遍，比较麻烦；CloudStack因为只有一个项目，部署起来会相对容易很多，然而平台的扩展性就要相对弱一些。

如果单从用户*关注的灵活性的角度来看，本回合OpenStack胜。

Round2: 避免被厂商锁定

OpenStack和CloudStack都是功能强大的开源云平台，满足企业私有云建设的需求，并且因为开放开源，都可以根据需要进行定制。

不同的是CloudStack虽然在云平台构建时会比较方便，对企业来说会更容易上手，但它必竟是从商业软件开源出来的，会带有商业软件属性；而OpenStack自诞生之初就是开源软件，所有的开发都是由社区承担，采用分布式的架构，不同的项目之间几乎没有耦合，所以可以方便的进行开发定制。

综合比较，第二回合，OpenStack胜。

Roud3: 更低的成本

又如前面说到的，CloudStack由于其某种程度带有商业软件属性，平台架构又比较集中，模块间耦合度比较高，导致其二次开发的成本较高。但OpenStack面临的问题是，由多个项目组成，每个项目都要单独安装，并且要保证项目间的协作，所以部署会比较麻烦。而且以Openstack目前发展的状况看来，不同版本之间项目可能会有较大的变动，因此版本间的升级会比较困难，由此带来的运维成本不好估算。

但我们还要考虑到的是，OpenStack和 CloudStack虽然都对VMware的ESXi虚拟化技术提供支持，但支持方式是不一样的。CloudStack要经过vCenter 才可以实现对ESXi宿主机上虚拟机的管理；而OpenStack支持直接和ESXi通信，实现对虚拟机的基本管理，只有高级功能才需要vCenter的 支持。针对目前中小企业普遍采用VMware的免费虚拟化技术而没有vCenter的现状，这也是在平台选择时需要考虑的。

本回合OpenStack 险胜。

Round 4: 开放的标准和API(60%)。

我们已经知道，OpenStack和CloudStack都是功能强大的开源云平台，满足企业私有云建设的需求，并且因为开放开源，都可以根据需要进行定制。OpenStack对外提供丰富和功能强大的API，使得资源可以被用户方便的使用和调度，同时提供和Amazon AWS（Amazon Web Services）兼容的API。CloudStack同样地对外提供自身API和与Amazon AWS相兼容的API。

所以这轮，双方算打个平手。

小结：

单就Zenoss调查报告所显示的用户需要程度*高的四个标准来看，OpenStack似乎基本保持不败。但这并不代表它尽善尽美，而且如果从使用户操作方便，简便易用的角度看来，CloudStack应该更胜一筹。

我们再来回顾这个数据：超过86%的企业关注OpenStack,排在第二位的CloudStack只有44%。这个数据显示，很多用户有可能同时关注这两项技术。技术强不强是客观的，主要还是要看用户自身的需要。但就目前来看，基于OpenStack更加开放的架构，以及众多技术厂商的支持，加上OpenStack 自身迅速成长壮大的势头，从长远来看对企业还是非常有益的。

原文链接:
https://cloud.tencent.com/info/a2f24a2ecb6954523d51a899f2c5d785.html

Amazon Elastic File System (Amazon EFS) 是AWS云上一个全托管的弹性NFS文件系统服务。EFS具有简单易用并可扩展的特性，与AWS的其他云服务紧密集成，同时也可以被本地数据中心所使用。EFS设计为可根据文件存储变化而自动进行扩缩容，同时对应用不产生中断。用户无须手动去进行存储空间的管理。EFS托管服务会自动管理文件存储底层的基础架构，用户无须关心文件系统部署、补丁管理和配置维护的技术细节，相比以往自建NFS服务器的方式，运维效率得到提高，成本也相应下降。

目前EFS已在在西云数据运营的 AWS 中国（宁夏）区域和光环新网运营的 AWS 中国（北京）区域上线。

EFS架构与基本概念

在控制台实际操作前，我们可以先简单了解一下EFS的架构和基本概念

上图是一个AWS区域中EC2实例访问EFS的架构示例，几个常见的概念简述如下：

文件系统(Filesystem)
EFS是一个区域性的服务，即托管文件系统的数据和元数据会自动存储在AWS区域内的多个可用区，以实现跨可用区的数据保护。VPC内的EC2实例或用户数据中心内的服务器均可通过网络以Network File System version4(NFS v4.1和V4.0)协议对文件系统进行访问。

挂载目标(Mount Target)
VPC中的EC2实例通过挂载目标来访问文件系统。挂载目标提供了VPC内的一个IP地址，每个可用区可以配置一个挂载目标，以便作为该可用区内的NFS服务器端点。挂载目标虽然是一个静态IP，但本身是进行高可用设计的，后面对应的是冗余的资源。EC2实例挂载时，可以直接指定一个对与文件系统一一对应的DNS域名，该域名会自动解析到EC2实例所在子网所对应的挂载目标上，从而简化文件系统的挂载工作。如果通过挂载帮助程序，则可以直接指定文件系统ID。

权限控制
在网络层面，每个挂载目标可以设定一个或多个安全组，即类似于防火墙，可以设定哪些EC2实例有权限访问该挂载目标从而挂载文件系统。此外，用户可以使用文件系统策略(File System Policy)和访问点(Access Point)来进行更细粒度的权限控制。

接下来会以宁夏区为例介绍如何快速部署一个EFS文件系统并挂载至EC2实例上

1 创建文件系统

1.1 配置网络访问

指定EFS文件系统所对应的VPC，及在对应的子网创建挂载目标并设置安全组。

一个文件系统仅对应一个VPC，但其他VPC的EC2实例可以通过VPC Peering打通VPC间的通道后再进行EFS文件系统挂载。
每个可用区建议对应创建一个挂载目标，这样可以确保不同可用区的EC2实例均可挂载文件系统。如果该可用区中有多个子网，只需要选择其中一个即可，该可用区下所有子网均可以访问到对应的挂载目标。
如果后续文件系统需要更换VPC，可以先将挂载目标删除后再进行更换。
本次演示会使用向导所指定的VPC默认安全组，同时后续EC2实例也会挂载该安全组以便与挂载目标进行通信。

1.2 配置文件系统设置

指定EFS文件系统的标签、生命周期管理策略、与性能相关的模式设置和数据加密等

通过标签(Tag)可以为文件系统进行描述

通过生命周期管理策略, EFS可以自动将指定时间（如7或14天或至*长90天）未访问的数据自动从EFS Standard转换至EFS IA(Infrequent Access, 不常访问）。该功能可以简单的理解为数据自动的冷热分层。EFS IA对应的是冷存储层，相比EFS Standard来说单位存储成本更低，且不会牺牲可用性、持久性和弹性等EFS的存储特性。需要注意到除了存储成本，EFS IA会按照数据访问量进行收费。简单来说，对于不常访问的数据，迁移至IA可以看到明显的成本优化。通过生命周期管理策略可以自动进行不常访问的数据的迁移，从而自动进行成本优化而无须人工干预。在这个演示中我们暂时不启用生命周期管理策略。

吞吐量模式：分为突增(Bursting)和预置(Provisioned)两种。在突增模式下，文件系统的吞吐性能随着存储容量增加而增长。典型文件系统的负载通常会猛增，在短时间内吞吐量较高，而其余时间吞吐量较低。因此，突增模式下EFS可在一段时间内突增到高吞吐量。对于存储容量较小但又需要较高吞吐量的场景，则可以使用预置模式，直接设定EFS文件系统的吞吐量上限。在这个演示我们使用默认的突增模式
性能模式：分为通用(General Purpose)和*大I/O(Max I/O)两种。通用模式适合于*多数的EFS文件系统使用场景，特别是对延时较为敏感的应用。如果希望有更高的吞吐量和IOPS要求，则可以考虑*大I/O模式，但该模式下元数据的操作延时会相对较高。在这个演示我们使用默认的通用模式。
加密：EFS可以与KMS结合，从而实现对存储在EFS文件系统内的数据进行加密。在这个演示中我们暂时不开启加密功能。

1.3 配置客户端访问

通过文件系统策略(File System Policies)可以指定NFS客户端对EFS文件系统所具有的权限, 包括读写权限，是否要求传输加密等。而访问点(Access Points)是 EFS文件系统中特定于应用程序的入口点，以管理应用程序对共享数据集的访问。通过访问点发出的所有文件系统请求可以被强制执行用户身份（包括用户组）。访问点还可以为文件系统强制执行不同的根目录，客户端只能访问指定目录或之下目录中的数据。

在这个演示中我们暂时不对文件系统权限和访问点进行配置，仅使用前面配置的安全组来做访问权限的控制。

1.4 审核与创建

*后我们检查一下配置是否正确 ，没问题的话就可以开始创建文件系统了

文件系统成功创建后，可以在控制台查看文件系统状态，挂载目标状态等信息。注意到此时文件系统还没有数据写入，目前的容量显示只有6KB（文件系统相关元数据的存储开销）

2. 挂载文件系统

2.1 部署EC2实例并配置安全组

接下来我们在刚才创建的文件系统对应的VPC中部署一台EC2实例，需要关联EFS文件系统挂载目标所对应的安全组，在这个演示中我们使用了VPC默认的安全组

可以看到这个默认安全组放通所有的流量，但是来源仅限于这个安全组。也就是说只要挂载了这个安全组的EC2实例，就可以与EFS挂载目标进行通信而不受限制。生产环境可以根据实际需要进一步缩小放通的端口范围等

2.2 安装EFS挂载帮助程序(Mount Helper)并挂载文件系统

EFS文件系统支持NFS协议，可以直接使用原有的NFS客户端来进行NFS文件系统挂载。另外EFS也提供了一个挂载帮助程序，以简化文件系统挂载，同时提供对EFS独特功能（如IAM认证，TLS传输加密和访问点等）。在文件系统状态页面，会有相应的链接和说明告诉用户如何来进行文件系统挂载：

这里我们以安装了Amazon Linux 2且类型为m5.large的EC2实例，演示如何从本地VPC用EFS挂载帮助程序来挂载文件系统：

首先登录EC2实例，安装EFS挂载程序：

sudo yum -y install amazon-efs-utils

• 1

接着创建挂载点目录：

sudo mkdir /mnt/efs

• 1

然后通过EFS挂载程序进行文件系统挂载

sudo mount -t efs fs-c4f11721:/ /mnt/efs

• 1

注意：
目前通过yum安装的EFS挂载程序对国内区域的文件系统域名处理有问题，会导致挂载文件系统时出现类似如下报错：

Failed to resolve "fs-c4f11721.efs.cn-northwest-1.amazonaws.com" - check that your file system ID is correct.
See https://docs.aws.amazon.com/console/efs/mount-dns-name for more detail.

• 1
• 2

目前解决方法是通过下面的命令修改配置文件：

echo -e '\n[mount.cn-north-1]\ndns_name_suffix = 
amazonaws.com.cn\n\n[mount.cn-northwest-1]\ndns_name_suffix = 
amazonaws.com.cn' | sudo tee -a /etc/amazon/efs/efs-utils.conf

• 1
• 2
• 3

再重新进行挂载即可。
该问题已经在*新的efs-utils版本上得到修复，很快新版本会更新至Amazon Linux RPM Repository中，目前用户也可以从Github上直接下载*新版本的EFS挂载程序以规避该问题，具体可查看参考资料中的相关链接

3. 检查文件系统

至此我们已经完成了文件系统的创建，接下来我们可以进行写入测试，并检查文件系统的状态。
通过dd往EFS文件系统写入一个20G的文件

sudo time dd if=/dev/zero of=/mnt/efs/20G-dd-$(date +%Y%m%d%H%M%S.%3N) bs=1M count=20480 conv=fsync


20480+0 records in 
20480+0 records out 
21474836480 bytes (21 GB) copied, 203.763 s, 105 MB/s 
0.06user 10.66system 3:23.81elapsed 5%CPU (0avgtext+0avgdata 3040maxresident)k 
0inputs+41943040outputs (0major+340minor)pagefaults 0swaps

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

可以看到这里统计的吞吐量是105MB/s。根据EFS官方文档提到的突增吞吐量的说明，小于1TB的文件系统，均可突增到100MB/s；而对于超过1TB的文件系统，存储在EFS标准上每1TB数据则可以突增100MB/s。另外需要注意到的是，EFS文件系统的性能实际上与上文提到性能模式、EC2实例网络带宽、并发压力和IO类型等等许多因素都有关，如果需要进行压力测试，可以查看参考资料里关于性能的文档链接

此时检查文件系统状态，此时可以看到文件系统的实际大小已更新为20GB：

小结

从这个演示我们可以看到EFS是一个托管的NFS文件服务， 用户只需要进行简单的配置就可以快速部署出一个高可用并可无限扩展的NFS文件系统。结合EFS的生命周期管理策略，数据可以实现冷热分层，从而降低存储成本。通过文件系统策略和访问点，用户还可以实现更为细粒度的权限控制。相关的技术细节可以参考EFS官方文档。

现在就开始动手测试起来吧！

许多客户对 Amazon EFS 倍加推崇，因为它使得在云中创建并运行高度可扩展、高度可用且高持久性的共享文件系统变得格外轻松。只需短短数秒，就可以创建一个符合 NFSv4 的文件系统，并将其挂载到多个（多达数千个）Amazon EC2 实例或本地服务器上。

Amazon EFS 为基于 Linux 的工作负载提供了一个简单、可扩展且有弹性的文件系统，并且可在不中断应用程序的情况下按需扩展到 PB 级。Amazon EFS 支持各种使用案例，从需要*高吞吐量的高度并行、横向扩展的工作负载到单线程、延迟敏感的工作负载，不一而足。使用案例包括迁移至云上的传统企业应用程序、大数据分析、Web 服务和内容管理、应用程序开发和测试、媒体和娱乐工作流程、数据库备份和容器存储等。

我的日常工作之一是帮助客户评估、设计和实施存储解决方案以支持不同的应用程序和工作负载。我发现，那些刚开始使用 Amazon EFS 的客户对这种高级文件系统还缺乏了解。在您开始评估和测试 Amazon EFS 之前，我希望与您分享一些*佳实践。本文将帮助您充分利用 Amazon EFS。

创建 Amazon EFS 文件系统

如果您还没有创建 Amazon EFS 文件系统，请使用 AWS 管理控制台或 AWS 命令行界面 (CLI) 创建一个。完成开始使用 Amazon Elastic File System 主题中的步骤 1、2 和 3。几分钟后，您应该会登录到挂载了 Amazon EFS 文件系统的 Amazon EC2 实例。

试用

在客户挂载文件系统之后，让我们先来检查一下文件系统的大小。在挂载了 EFS 文件系统的 EC2 实例的命令行处运行 df。应会返回与下文类似的内容，这将以1KB数据库块的数量来表示文件系统大小。

如果您和我一样，很难直接理解一个如此庞大的数值（16 位），那么您可使用 df -h 命令来获取一个便于理解的表示。上述命令的执行结果显示您拥有 8EB 以上的可用存储。但事实上， Amazon EFS 是一个弹性文件系统，可随着您添加和删除数据自动扩展和缩减，而您只需要为实际使用的存储付费（在本例中为零）。您不再需要费心考虑如何预置存储，您只需为使用的存储付费。

由于 Amazon EFS 易于上手，因此您可能希望尽快深入了解并评估 Amazon EFS 的性能，一种常见的方法是使用“touch”命令测试评估 Amazon EFS 性能。这种测试会生成大量的零字节文件。我见过用 Perl、Python、Java 和其他语言编写的这类测试。

本文将使用 bash 脚本，您会看到生成 1024 个文件的速度有多快。在 EC2 实例上运行以下命令，请确保将存储路径指向已挂载的 Amazon EFS 文件系统。

time for i in {1..1024}; do
  sudo touch /mnt/efs/deleteme.$i;
  done;

• 1
• 2
• 3

用了多长时间？ 在我的测试中，仅用了 16.808 秒便在 Amazon EFS 上生成了 1024 个文件。

如果您认为生成 1024 个零字节文件所用的时间过长，请仔细检查该命令以确保其正确无误。删除*组 1024 个零字节文件后，再次运行该命令。结果如何呢？ 几乎一样。

如果您还是认为生成 1024 个零字节文件需要的时间太长，可以将其与其他存储平台进行比较。更改命令并针对挂载到实例的 Amazon EBS 卷运行该命令。运行以下命令，确保更改路径以使用 Amazon EBS 卷。在本例中，我将写入 ec2-user 主目录。

time for i in {1..1024}; do
  sudo touch ~/deleteme.$i;
  done;

• 1
• 2
• 3

用了多长时间？ 在我的测试中，仅用了 5.112 秒便在 EBS 上生成了 1024 个零字节文件。这是 root 卷，即一个 10-GB gp2 EBS 卷。在本例中，与 EFS 相比，写入 EBS 的操作要快 3.28 倍。

在这类情况下，我会多假设几种场景。如果重新编写命令以使用多个线程会怎样？ 这将允许您并行生成文件。进入 GNU Parallel，这是一个用于并行执行串行操作的开源 shell 工具。该工具已添加到 Amazon Linux 存储库中，因此在安装并启用 EPEL rpm 软件包后，可以使用 sudo yum install parallel -y 命令将其安装到 Amazon Linux 2 上。有关更多信息，请参阅 GNU Parallel。

运行以下命令，安装 GNU Parallel 并使用多个线程生成 1024 个零字节文件。

time seq 1 1024 | sudo parallel --will-cite -j 32 touch 
/mnt/efs/deleteme2.{};

• 1
• 2

将该命令重新编写为使用 32 个作业（或 32 个线程）后，仅仅在 8.647 秒内便生成了相同的 1024 个零字节文件，速度提高了 94%。

如果将多线程命令重新编写为写入多个目录会怎样？ 每个线程写入一个单独的目录。这会将写入操作分布在多个 inode 上。

如果您不熟悉 inode，请注意 inode 是一种 Unix 风格的数据结构，用于描述文件系统对象，例如文件和目录。当多个线程尝试更新同一个 inode 时，会发生 inode 争用，由于存在网络延迟，这种情况在网络文件系统中更为明显。运行以下命令，使用 32 个线程生成 1024 个零字节文件，每个线程在自己的目录中生成 32 个文件。32 个目录，每个目录中包含 32 个文件，共 1024 个文件。

sudo mkdir -p /mnt/efs/{1..32}
time seq 1 32 | sudo parallel --will-cite -j 32 touch 
/mnt/efs/{}/deleteme3.{1..32};

• 1
• 2
• 3

将命令重新编写为使用 32 个作业（或 32 个线程），并让每个线程在自己的目录中生成文件后，仅在短短 0.776 秒内便生成了 1024 个零字节文件。这比*个单线程单目录测试快了 21 倍。

如果将同一文件系统挂载到 2、10、100 或1000 个 Amazon EC2 实例，又会怎样？ 如果文件系统支持关后开一致性、跨多个存储服务器和多个可用区的数据持久性以及没有单点故障的高可用性，则会生成多少个文件？

后续步骤

这只是用来有效评估和试用 Amazon EFS 的一个测试。要详细了解其性能特性，我建议您浏览一下 GitHub 上的 Amazon EFS 教程。该教程不仅包含我刚刚进行的试用，还通过更多例子说明了并行性的优势。此外，还说明了 I/O 大小、EC2 实例类型和不同的文件传输工具对性能造成的显著影响。AWS DataSync 也使用这些技术改进 EFS 文件系统往来传输数据的性能。

有关 GNU Parallel 的更多信息，请参阅 USENIX 杂志 2011 年 2 月刊上的“GNU Parallel – 强大的命令行工具”。

小结

Amazon EFS 文件系统可分布在无限量的存储服务器上，从而允许对文件系统对象进行大规模并行访问。这种分布式设计避免了传统文件服务器固有的瓶颈和约束。

在本次试用中，我利用了 Amazon EFS 的这些优势，将生成 1024 个零字节文件的时间从 16.808 秒减少到了 0.776 秒，速度提高了 2100%。

在本文中，我只展示了两条建议。您可以根据这些建议更好地利用 Amazon EFS 的分布式数据存储设计，并实现对文件系统数据的大规模并行访问。

*条建议是使用多个线程并行访问 EFS。第二条建议是使用多个线程并行访问多个目录或 inode。要了解有助于您更好地理解和利用 EFS 的分布式设计的其他建议，请查看 Amazon EFS 教程。

原文链接:https://aws.amazon.com/cn/blogs/china/how-to-test-drive-amazon-elastic-file-system/