Hadoop大事记

2004年– 最初的版本(现在称为HDFS和MapReduce)由Doug Cutting和Mike Cafarella开始实施。
2005年12月– Nutch移植到新的框架,Hadoop在20个节点上稳定运行。
2006年1月– Doug Cutting加入雅虎。
2006年2月– Apache Hadoop项目正式启动以支持MapReduce和HDFS的独立发展。
2006年2月– 雅虎的网格计算团队采用Hadoop。
2006年4月– 标准排序(10 GB每个节点)在188个节点上运行47.9个小时。
2006年5月– 雅虎建立了一个300个节点的Hadoop研究集群。
2006年5月– 标准排序在500个节点上运行42个小时(硬件配置比4月的更好)。
06年11月– 研究集群增加到600个节点。
06年12月– 标准排序在20个节点上运行1.8个小时,100个节点3.3小时,500个节点5.2小时,900个节点7.8个小时。
07年1月– 研究集群到达900个节点。
07年4月– 研究集群达到两个1000个节点的集群。
08年4月– 赢得世界最快1 TB数据排序在900个节点上用时209秒。
08年10月– 研究集群每天装载10 TB的数据。
09年3月– 17个集群总共24 000台机器。
09年4月– 赢得每分钟排序,59秒内排序500 GB(在1400个节点上)和173分钟内排序100 TB数据(在3400个节点上)。

Hadoop发展历史

Hadoop这个名字不是一个缩写,它是一个虚构的名字。该项目的创建者,Doug Cutting如此解释Hadoop的得名:”这个名字是我孩子给一头吃饱了的棕黄色大象命名的。我的命名标准就是简短,容易发音和拼写,没有太多的意义,并且不会被用于别处。小孩子是这方面的高手。Googol就是由小孩命名的。”
Hadoop及其子项目和后继模块所使用的名字往往也与其功能不相关,经常用一头大象或其他动物主题(例如:”Pig”)。较小的各个组成部分给与更多描述性(因此也更俗)的名称。这是一个很好的原则,因为它意味着可以大致从其名字猜测其功能,例如,jobtracker 的任务就是跟踪MapReduce作业。
从头开始构建一个网络搜索引擎是一个雄心勃勃的目标,不只是要编写一个复杂的、能够抓取和索引网站的软件,还需要面临着没有专有运行团队支持运行它的挑战,因为它有那么多独立部件。同样昂贵的还有:据Mike Cafarella和Doug Cutting估计,一个支持此10亿页的索引需要价值约50万美元的硬件投入,每月运行费用还需要3万美元。 不过,他们相信这是一个有价值的目标,因为这会开放并最终使搜索引擎算法普及化。
Nutch项目开始于2002年,一个可工作的抓取工具和搜索系统很快浮出水面。但他们意识到,他们的架构将无法扩展到拥有数十亿网页的网络。在 2003年发表的一篇描述Google分布式文件系统(简称GFS)的论文为他们提供了及时的帮助,文中称Google正在使用此文件系统。 GFS或类似的东西,可以解决他们在网络抓取和索引过程中产生的大量的文件的存储需求。具体而言,GFS会省掉管理所花的时间,如管理存储节点。在 2004年,他们开始写一个开放源码的应用,即Nutch的分布式文件系统(NDFS)。
2004年,Google发表了论文,向全世界介绍了MapReduce。 2005年初,Nutch的开发者在Nutch上有了一个可工作的MapReduce应用,到当年年中,所有主要的Nutch算法被移植到使用MapReduce和NDFS来运行。
Nutch中的NDFS和MapReduce实现的应用远不只是搜索领域,在2006年2月,他们从Nutch转移出来成为一个独立的Lucene 子项目,称为Hadoop。大约在同一时间,Doug Cutting加入雅虎,Yahoo提供一个专门的团队和资源将Hadoop发展成一个可在网络上运行的系统(见后文的补充材料)。在2008年2月,雅虎宣布其搜索引擎产品部署在一个拥有1万个内核的Hadoop集群上。
2008年1月,Hadoop已成为Apache顶级项目,证明它是成功的,是一个多样化、活跃的社区。通过这次机会,Hadoop成功地被雅虎之外的很多公司应用,如Last.fm、Facebook和《纽约时报》。(一些应用在第14章的案例研究和Hadoop维基有介绍,Hadoop维基的网址为http://wiki.apache.org/hadoop/PoweredBy。)
有一个良好的宣传范例,《纽约时报》使用亚马逊的EC2云计算将4 TB的报纸扫描文档压缩,转换为用于Web的PDF文件。 这个过程历时不到24小时,使用100台机器运行,如果不结合亚马逊的按小时付费的模式(即允许《纽约时报》在很短的一段时间内访问大量机器)和 Hadoop易于使用的并行程序设计模型,该项目很可能不会这么快开始启动。
2008年4月,Hadoop打破世界纪录,成为最快排序1TB数据的系统。运行在一个910节点的群集,Hadoop在209秒内排序了1 TB的数据(还不到三分半钟),击败了前一年的297秒冠军。同年11月,谷歌在报告中声称,它的MapReduce实现执行1TB数据的排序只用了68 秒。 在2009年5月,有报道宣称Yahoo的团队使用Hadoop对1 TB的数据进行排序只花了62秒时间。
构建互联网规模的搜索引擎需要大量的数据,因此需要大量的机器来进行处理。Yahoo!Search包括四个主要组成部分:Crawler,从因特网下载网页;WebMap,构建一个网络地图;Indexer,为最佳页面构建一个反向索引;Runtime(运行时),回答用户的查询。WebMap是一幅图,大约包括一万亿条边(每条代表一个网络链接)和一千亿个节点(每个节点代表不同的网址)。创建和分析此类大图需要大量计算机运行若干天。在 2005年初,WebMap所用的基础设施名为Dreadnaught,需要重新设计以适应更多节点的需求。Dreadnaught成功地从20个节点扩展到600个,但需要一个完全重新的设计,以进一步扩大。Dreadnaught与MapReduce有许多相似的地方,但灵活性更强,结构更少。具体说来,每一个分段(fragment),Dreadnaught作业可以将输出发送到此作业下一阶段中的每一个分段,但排序是在库函数中完成的。在实际情形中,大多数WebMap阶段都是成对存在的,对应于MapReduce。因此,WebMap应用并不需要为了适应MapReduce而进行大量重构。
Eric Baldeschwieler(Eric14)组建了一个小团队,我们开始设计并原型化一个新的框架(原型为GFS和MapReduce,用C++语言编写),打算用它来替换Dreadnaught。尽管当务之急是我们需要一个WebMap新框架,但显然,标准化对于整个Yahoo! Search平台至关重要,并且通过使这个框架泛化,足以支持其他用户,我们才能够充分运用对整个平台的投资。
与此同时,我们在关注Hadoop(当时还是Nutch的一部分)及其进展情况。2006年1月,雅虎聘请了Doug Cutting,一个月后,我们决定放弃我们的原型,转而使用Hadoop。相较于我们的原型和设计,Hadoop的优势在于它已经在20个节点上实际应用过。这样一来,我们便能在两个月内搭建一个研究集群,并着手帮助真正的客户使用这个新的框架,速度比原来预计的快许多。另一个明显的优点是Hadoop 已经开源,较容易(虽然远没有那么容易!)从雅虎法务部门获得许可在开源方面进行工作。因此,我们在2006年初设立了一个200个节点的研究集群,我们将WebMap的计划暂时搁置,转而为研究用户支持和发展Hadoop。

Hadoop主要子项目

* Hadoop Common: 在0.20及以前的版本中,包含HDFS、MapReduce和其他项目公共内容,从0.21开始HDFS和MapReduce被分离为独立的子项目,其余内容为Hadoop Common
* HDFS: Hadoop 分佈式文件系統 (Distributed File System) - HDFS (Hadoop Distributed File System)
* MapReduce:并行计算框架,0.20前使用 org.apache.hadoop.mapred 旧接口,0.20版本开始引入org.apache.hadoop.mapreduce的新API
* HBase: 类似Google BigTable的分布式NoSQL列数据库。(HBase 和 Avro 已经于2010年5月成为顶级 Apache 项目[1])
* Hive:数据仓库工具,由Facebook贡献。
* Zookeeper:分布式锁设施,提供类似Google Chubby的功能,由Facebook贡献。
* Avro:新的数据序列化格式与传输工具,将逐步取代Hadoop原有的IPC机制。

CPU工作原理

在了解CPU工作原理之前,我们先简单谈谈CPU是如何生产出来的。CPU是在特别纯净的硅材料上制造的。一个CPU芯片包含上百万个精巧的晶体管。人们在一块指甲盖大小的硅片上,用化学的方法蚀刻或光刻出晶体管。因此,从这个意义上说,CPU正是由晶体管组合而成的。简单而言,晶体管就是微型电子开关,它们是构建CPU的基石,你可以把一个晶体管当作一个电灯开关,它们有个操作位,分别代表两种状态:ON(开)和OFF(关)。这一开一关就相当于晶体管的连通与断开,而这两种状态正好与二进制中的基础状态“0”和“1”对应!这样,计算机就具备了处理信息的能力。
但你不要以为,只有简单的“0”和“1”两种状态的晶体管的原理很简单,其实它们的发展是经过科学家们多年的辛苦研究得来的。在晶体管之前,计算机依靠速度缓慢、低效率的真空电子管和机械开关来处理信息。后来,科研人员把两个晶体管放置到一个硅晶体中,这样便创作出第一个集成电路,再后来才有了微处理器。
看到这里,你一定想知道,晶体管是如何利用“0”和“1”这两种电子信号来执行指令和处理数据的呢?其实,所有电子设备都有自己的电路和开关,电子在电路中流动或断开,完全由开关来控制,如果你将开关设置为OFF,电子将停止流动,如果你再将其设置为ON,电子又会继续流动。晶体管的这种ON与OFF的切换只由电子信号控制,我们可以将晶体管称之为二进制设备。这样,晶体管的ON状态用“1”来表示,而OFF状态则用“0”来表示,就可以组成最简单的二进制数。众多晶体管产生的多个“1”与“0”的特殊次序和模式能代表不同的情况,将其定义为字母、数字、颜色和图形。举个例子,十进位中的1在二进位模式时也是“1”,2在二进位模式时是“10”,3是“11”,4是“100”,5是“101”,6是“110”等等,依此类推,这就组成了计算机工作采用的二进制语言和数据。成组的晶体管联合起来可以存储数值,也可以进行逻辑运算和数字运算。加上石英时钟的控制,晶体管组就像一部复杂的机器那样同步地执行它们的功能。
CPU的内部结构
现在我们已经大概知道CPU是负责些什么事情,但是具体由哪些部件负责处理数据和执行程序呢?
1.算术逻辑单元ALU(Arithmetic Logic Unit)   ALU是运算器的核心。它是以全加器为基础,辅之以移位寄存器及相应控制逻辑组合而成的电路,在控制信号的作用下可完成加、减、乘、除四则运算和各种逻辑运算。就像刚才提到的,这里就相当于工厂中的生产线,负责运算数据。
2.寄存器组 RS(Register Set或Registers) RS实质上是CPU中暂时存放数据的地方,里面保存着那些等待处理的数据,或已经处理过的数据,CPU访问寄存器所用的时间要比访问内存的时间短。采用寄存器,可以减少CPU访问内存的次数,从而提高了CPU的工作速度。但因为受到芯片面积和集成度所限,寄存器组的容量不可能很大。寄存器组可分为专用寄存器和通用寄存器。专用寄存器的作用是固定的,分别寄存相应的数据。而通用寄存器用途广泛并可由程序员规定其用途。通用寄存器的数目因微处理器而异。

        3.控制单元(Control Unit)   正如工厂的物流分配部门,控制单元是整个CPU的指挥控制中心,由指令寄存器IR(Instruction Register)、指令译码器ID(Instruction Decoder)和操作控制器0C(Operation Controller)三个部件组成,对协调整个电脑有序工作极为重要。它根据用户预先编好的程序,依次从存储器中取出各条指令,放在指令寄存器IR中,通过指令译码(分析)确定应该进行什么操作,然后通过操作控制器OC,按确定的时序,向相应的部件发出微操作控制信号。操作控制器OC中主要包括节拍脉冲发生器、控制矩阵、时钟脉冲发生器、复位电路和启停电路等控制逻辑。
4.总线(Bus)   就像工厂中各部位之间的联系渠道,总线实际上是一组导线,是各种公共信号线的集合,用于作为电脑中所有各组成部分传输信息共同使用的“公路”。直接和CPU相连的总线可称为局部总线。其中包括: 数据总线DB(Data Bus)、地址总线AB(Address Bus) 、控制总线CB(Control Bus)。其中,数据总线用来传输数据信息;地址总线用于传送CPU发出的地址信息;控制总线用来传送控制信号、时序信号和状态信息等。
CPU的工作流程
由晶体管组成的CPU是作为处理数据和执行程序的核心,其英文全称是:Central Processing Unit,即中央处理器。首先,CPU的内部结构可以分为控制单元,逻辑运算单元和存储单元(包括内部总线及缓冲器)三大部分。CPU的工作原理就像一个工厂对产品的加工过程:进入工厂的原料(程序指令),经过物资分配部门(控制单元)的调度分配,被送往生产线(逻辑运算单元),生产出成品(处理后的数据)后,再存储在仓库(存储单元)中,最后等着拿到市场上去卖(交由应用程序使用)。在这个过程中,我们注意到从控制单元开始,CPU就开始了正式的工作,中间的过程是通过逻辑运算单元来进行运算处理,交到存储单元代表工作的结束。
数据与指令在CPU中的运行
刚才已经为大家介绍了CPU的部件及基本原理情况,现在,我们来看看数据是怎样在CPU中运行的。我们知道,数据从输入设备流经内存,等待CPU的处理,这些将要处理的信息是按字节存储的,也就是以8位二进制数或8比特为1个单元存储,这些信息可以是数据或指令。数据可以是二进制表示的字符、数字或颜色等等。而指令告诉CPU对数据执行哪些操作,比如完成加法、减法或移位运算。
我们假设在内存中的数据是最简单的原始数据。首先,指令指针(Instruction Pointer)会通知CPU,将要执行的指令放置在内存中的存储位置。因为内存中的每个存储单元都有编号(称为地址),可以根据这些地址把数据取出,通过地址总线送到控制单元中,指令译码器从指令寄存器IR中拿来指令,翻译成CPU可以执行的形式,然后决定完成该指令需要哪些必要的操作,它将告诉算术逻辑单元(ALU)什么时候计算,告诉指令读取器什么时候获取数值,告诉指令译码器什么时候翻译指令等等。
假如数据被送往算术逻辑单元,数据将会执行指令中规定的算术运算和其他各种运算。当数据处理完毕后,将回到寄存器中,通过不同的指令将数据继续运行或者通过DB总线送到数据缓存器中。
基本上,CPU就是这样去执行读出数据、处理数据和往内存写数据3项基本工作。但在通常情况下,一条指令可以包含按明确顺序执行的许多操作,CPU的工作就是执行这些指令,完成一条指令后,CPU的控制单元又将告诉指令读取器从内存中读取下一条指令来执行。这个过程不断快速地重复,快速地执行一条又一条指令,产生你在显示器上所看到的结果。我们很容易想到,在处理这么多指令和数据的同时,由于数据转移时差和CPU处理时差,肯定会出现混乱处理的情况。为了保证每个操作准时发生,CPU需要一个时钟,时钟控制着CPU所执行的每一个动作。时钟就像一个节拍器,它不停地发出脉冲,决定CPU的步调和处理时间,这就是我们所熟悉的CPU的标称速度,也称为主频。主频数值越高,表明CPU的工作速度越快。
如何提高CPU工作效率
既然CPU的主要工作是执行指令和处理数据,那么工作效率将成为CPU的最主要内容,因此,各CPU厂商也尽力使CPU处理数据的速度更快。
根据CPU的内部运算结构,一些制造厂商在CPU内增加了另一个算术逻辑单元(ALU),或者是另外再设置一个处理非常大和非常小的数据浮点运算单元(Floating Point Unit,FPU),这样就大大加快了数据运算的速度。
而在执行效率方面,一些厂商通过流水线方式或以几乎并行工作的方式执行指令的方法来提高指令的执行速度。刚才我们提到,指令的执行需要许多独立的操作,诸如取指令和译码等。最初CPU在执行下一条指令之前必须全部执行完上一条指令,而现在则由分布式的电路各自执行操作。也就是说,当这部分的电路完成了一件工作后,第二件工作立即占据了该电路,这样就大大增加了执行方面的效率。
另外,为了让指令与指令之间的连接更加准确,现在的CPU通常会采用多种预测方式来控制指令更高效率地执行。
多核cpu工作原理
        双核的优势不是频率,而是对付同时处理多件事情。一个核心理论上同时只能干一件事,比如你同时在后台BT下载,前台一边看电影一边拷贝文件一边联QQ……,这么多程序同时需要CPU来响应,怎么办?靠操作系统!
        window本身就是多线程操作系统(DOS就是单线程系统,dos下2核4核和单核没区别,处理一个任务时必须停下来等待处理结束才能干下一件事),它可以把每个处理任务划分为多“份”,多个处理任务按顺序排成队列,这样单核心的CPU可以一次处理一“份”,轮流处理每个程序的“份”,这样你感觉就是CPU同时在干几件事了。但如果CPU不够强劲,同时排队等待处理的东西太多了,你就会感觉系统在等待,有延时,反应慢等等症状。再或者某个程序出现错误,死机了,很可能造成后面排队的其他任务都在那里干等,造成系统无反应的情况,按热启键都没反应。理论上如果现在有颗6G频率的单核CPU,单论处理性能应该与1个3G双核近似,甚至更高一些,因为目前双核比单核也就快不到2倍。
        原本计算机一直以单核心的工作频率作为性能的衡量,之所以放弃单核是因为目前的技术水平令单核性能继续提升遇到了瓶颈,4G P4的夭折让依靠频率提升性能的路子走进死胡同,不得已改走多核心路线,以核心数量来弥补处理能力的不足。不过慢慢的这些多核心的频率又开始奔3G去了,随着45nm的出现,双核上4G应该可以想象,所以一方面每个核心的性能还在发展,另一方面多核心集成的手段双管齐下,这样CPU的性能可以迅速提升,继续保持摩尔定律。     多核CPU就是基板上集成有多个单核CPU,早期PD双核需要北桥来控制分配任务,核心之间存在抢二级缓存的情况,后期酷睿自己集成了任务分配系统,再搭配操作系统就能真正同时开工,2个核心同时处理2“份”任务,速度快了,万一1个核心死机,起码另一个U还可以继续处理关机、关闭软件等任务。较早的操作系统如XP等需要装双核或多核补丁,能更好发挥性能或更稳定,Vistia下就不需要。
        目前几乎所有的程序在编写时是按单核心CPU写的(多核心程序优化对程序员来说是个噩梦,目前好像还没有合适的编程软件能让程序员轻松编写针对多核心的程序),因此对多核的利用率不是很高,分配任务时,往往1个核心满负荷,另一个还有空闲(留些空闲也对,要应付随时发生的其它命令)。一般2核心性能也就比单核心高60~70%甚至更低。
        4核或者将来的8核说白了还是多个核心独自处理各自的“份”,不过人多力量大,速度快,响应时间短,不易死机。当然耗电、协调性都会是个考验。

云计算虚拟化策略中的三大关键要点

摘要:虚拟化已经深入了IT各个领域。面对虚拟化潮流,唯有顺势而为早日做好部署,才能在未来的竞争中获得优势。     当然,在整个IT环境中实施虚拟化部署并不是件容易的事情,通常来说,这其中包括有:
–决定实施虚拟化的设备(全部还是部分)
–决定实施虚拟化平台的软硬件,比如是Hyper-V还是VMware或者Xenapp
–先从小部分服务器和工作站开始搭建平台,并全面测试其工作性能和资源消耗情况
–为冗余/故障设立合理的备份措施,并利用工具进行监视和纠错
从虚拟化角度来说,它的好处有很多,比如减少硬件、集中化管理、节省运营成本甚至有助于环保–低功耗(也可以称之为硬件污染)。执行虚拟化环境所带来的影响是多方面的。但它有没有负面影响呢?
虚拟化平台资源尤其是底层的硬件设备,都是可以实现共享的。主机上的虚拟机并不知道共享同一台主机的客户情况, 否则它们将会造成客户机之间的竞争。总的来说,如果所有资源密集型任务都在同一时间涌向客户机,就可能会影响到主机的性能表现。另一个缺点是,如果虚拟化平台上的主机性能受到影响,那么,它就会既影响到主机本身还会影响到共享同一主机的其他客户。
为此,我们提出在实施虚拟化策略的过程中,不能忽视以下三个关键要点:
1、日益增多的碎片会造成I/O瓶颈和性能下降问题–虚拟化平台中,文件出现碎片或者写入到磁盘的分区过于分散。
2、数据被删除时虚拟磁盘空间不会随之缩减。
3、虚拟机会争夺I/O资源,而且它们使用的时候不能跨平台有效地实施优先级。
这些问题可能会降低虚拟机的性能,也会影响迁移到虚拟平台的实现。不过,避免资源冲突和实现系统优化可以弥补这些不足。删除文件系统中的碎片有助于降低I/O资源消耗。更小的I/O请求将有助于I/O性能和可靠性的持久发挥。
磁盘空间是很宝贵的资源,虚拟环境下任何空间的浪费都不可接受的。对磁盘空间使用状况进行持续监测,特别是动态环境下的空间使用状况的监测,显得更加重要。

云计算中的虚拟化的性能提升

摘要:过去10年里,虚拟技术帮助IT工程师实现了整合资源,节约成本,助力企业增长等目标。不过,虚拟化究竟能产生多大影响呢?跟现代服务器技术打交道的工程师应该懂得利用该技术资源,帮助企业增长、扩大。通过在一台物理主机上安装多个虚拟机器,数据中心运行会更流畅,而且硬件设备的数量可以相对减少。新型的惠普ProLiant服务器配置了英特尔8核处理器,可以负载5至6台虚拟机。那么,明明可以实施虚拟化,为什么我们还紧抓住硬件不放呢?
虚拟化变得越来越容易,网络工程师也越发能接受虚拟技术。然而,现在对该技术的运用却出现了下降趋势。最近,许多公司的做法是,买一台服务器,把工作负荷放在存储网络(SAN),再安装管理程序和虚拟机。尽管这个方法可行,但IT管理员却常常略过影响虚拟服务器性能的某些重要步骤。
了解虚拟化技术
一般来讲,虚拟技术有两种类型:主机架构和裸机架构。主机架构环境下,服务器有预先安装的操作系统,例如WindowsServer2008。管理员会在原操作系统上加载安装虚拟化软件。裸机架构则完全移除原有操作系统,重新安装Linux/Unix-basedkernel作为管理程序。基本上,虚拟技术是直接安装在硬件上的。CitrixSystems的XenServer适用裸机架构,VMware公司两种技术都能提供。
裸机架构的最大优势在于虚拟机不需要其他软件就能直接访问基础硬件资源。不过,裸机架构要求更新型的硬件,譬如机载服务器必须是Intel-VT或是AMD-V。这意味着,升级的旧服务器利用不了这项技术。虽然如此,主机架构管理程序总是可以利用的。
资源利用
无论对于物理主机还是虚拟机,合理的资源分配都是至关重要的。在部署前,必须了解利用这些硬件要达到什么目的。要进行不间断的高端SQL查询?或者公司计划安装一些应用软件满足一部分用户不定期访问的要求?明白了目标是什么,管理员才能进行合理架设,处理相应工作负荷,更重要的是,伴随基础设施的变化,整个架构也能做出相应调整。
谈到物理硬件,有三个主要的升级办法:
1.硬盘驱动器对于升级硬盘驱动器能显著改善虚拟机性能的说法,大家几乎没有异议。如果现有环境不是把存储网络作为工作负荷的中心,可以考虑用多个高速硬盘来实现升级。对于小型公司,由于不需使用集中存储排列,通常是升级物理硬件内置容量。也就是说,通过更新性能更好的驱动来升级RAID排列,整个运行环境会有很大提高,冗余也会增加。
对于已有存储区域网的较大规模环境,考虑利用现有的技术。存储区域网老化了吗?依附在存储区域网上的驱动是否运行得够快,能够快速和无缝地访问一项工作负荷吗?IT工程师考虑这个问题时,经常会跳过更换存储区域网这个想法,而让他们感到疑惑的是尽管有了新服务器和新虚拟化软件,他们的虚拟基础设施为何运行缓慢。
2.CPU虚拟机装到物理机上时,机载处理器利用率更高了。
从IT工程师的角度看,更快的CPU总能提供更快的处理速度。物理主机有空间允许CPU升级甚至是增加。许多机器配置了开放性CPU槽,以备扩容之需。
3.RAM升级RAM可能是挖掘虚拟主机性能最经济有效的办法。通过在主机上升级内存,能够给每台虚拟机分配更多的RAM。任何一台服务器都能承载比平常更多的RAM。增加RAM之后,工程师就能再次检查虚拟机是如何利用资源的。从而,可以根据实际需要,额外分配内存给特定机器以提高效率。

OpenStack的架构

OpenStack的架构
1. OpenStack是什么
OpenStack既是一个社区,也是一个项目和一个开源软件,它提供了一个部署云的操作平台或工具集。其宗旨在于,帮助组织运行为虚拟计算或存储服务的云,为公有云、私有云,也为大云、小云提供可扩展的、灵活的云计算。
OpenStack旗下包含了一组由社区维护的开源项目,他们分别是OpenStack Compute(Nova),OpenStack Object Storage(Swift),以及OpenStack Image Service(Glance)。
OpenStack Compute[1],为云组织的控制器,它提供一个工具来部署云,包括运行实例、管理网络以及控制用户和其他项目对云的访问(the cloud through users and projects)。它底层的开源项目名称是Nova,其提供的软件能控制IaaS云计算平台,类似于Amazon EC2和Rackspace Cloud Servers。实际上它定义的是,与运行在主机操作系统上潜在的虚拟化机制交互的驱动,暴露基于Web API的功能。
OpenStack Object Storage[2],是一个可扩展的对象存储系统。对象存储支持多种应用,比如复制和存档数据,图像或视频服务,存储次级静态数据,开发数据存储整合的新应用,存储容量难以估计的数据,为Web应用创建基于云的弹性存储。
OpenStack Image Service[1],是一个虚拟机镜像的存储、查询和检索系统,服务包括的RESTful API允许用户通过HTTP请求查询VM镜像元数据,以及检索实际的镜像。VM镜像有四种配置方式:简单的文件系统,类似OpenStack Object Storage的对象存储系统,直接用Amazon’s Simple Storage Solution (S3) 存储,用带有Object Store的S3间接访问S3。
三个项目的基本关系如下图1-1所示:
1-1 OpenStack三个组件的关系
2.云服务提供商的概念架构
OpenStack能帮我们建立自己的IaaS,提供类似Amazon Web Service的服务给客户。为实现这一点,我们需要提供几个高级特性:
a)允许应用拥有者注册云服务,查看运用和计费情况;
b)允许Developers/DevOps folks创建和存储他们应用的自定义镜像;
c)允许他们启动、监控和终止实例;
d)允许Cloud Operator配置和操作基础架构
这四点都直击提供IaaS的核心,现在假设你同意了这四个特性,现在就可以将它们放进如下所示的概念架构2-1中。
2-1 OpenStack 概念架构
在此模型中,作者假设了需要与云交互的四个用户集:developers, devops, owners and operators,并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法(presentation, logic and resources),它带有两个正交区域。
展示层,组件与用户交互,接受和呈现信息。Web portals为非开发者提供图形界面,为开发者提供API端点。如果是更复杂的结构,负载均衡,控制代理,安全和名称服务也都会在这层。
逻辑层为云提供逻辑(intelligence)和控制功能。这层包括部署(复杂任务的工作流),调度(作业到资源的映射),策略(配额等等),镜像注册image registry (实例镜像的元数据),日志 (事件和计量) 。
假设绝大多数服务提供者已经有客户身份和计费系统。任何云架构都需要整合这些系统。
在任何复杂的环境下,我们都将需要一个management层来操作这个环境。它应该包括一个API访问云管理特性以及一些监控形式(forms)。很可能,监控功能将以整合的形式加入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了monitoring和admin API,在更完全的架构中,你将见到一系列的支持功能,比如provisioning和 configuration management。
最后,资源层。既然这是一个compute云,我们就需要实际的compute、network 和 storage资源,以供应给我们的客户。该层提供这些服务,无论他们是服务器,网络交换机,NAS(network attached storage)还是其他的一些资源。
3. OpenStack Compute架构
3.1OpenStack Compute逻辑架构
OpenStack Compute逻辑架构中,组件中的绝大多数可分为两种自定义编写的Python守护进程(custom written python daemons)。
a)接收和协调API调用的WSGI应用(nova-api, glance-api, etc)
b)执行部署任务的Worker守护进程(nova-compute, nova-network, nova-schedule, etc.)
然而,逻辑架构中有两个重要的部分,既不是自定义编写,也不是基于Python,它们是消息队列和数据库。二者简化了复杂任务(通过消息传递和信息共享的任务)的异步部署。
逻辑架构图3-1如下所示:
3-1 OpenStack Compute逻辑架构
从图中,我们可以总结出三点:
a)终端用户(DevOps, Developers 和其他的 OpenStack 组件)通过和nova-api对话来与OpenStack Compute交互。
b)OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息,以执行API请求。
c)OpenStack Glance基本上是独立的基础架构,OpenStack Compute通过Glance API来和它交互。
其各个组件的情况如下:
a)nova-api守护进程是OpenStack Compute的中心。它为所有API查询(OpenStack API 或 EC2 API)提供端点,初始化绝大多数部署活动(比如运行实例),以及实施一些策略(绝大多数的配额检查)。
b)nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂,但是基本原理很简单:从队列中接收行为,然后在更新数据库的状态时,执行一系列的系统命令执行他们。
c)nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商,比如,ISCSI和AoE。
d)Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务,然后执行任务以操控网络,比如创建bridging interfaces或改变iptables rules。
e)Queue提供中心hub,为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。
f)SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型,在用的实例,可用的网络和项目。理论上,OpenStack Compute能支持SQL-Alchemy支持的任何数据库,但是当前广泛使用的数据库是sqlite3(仅适合测试和开发工作),MySQL和PostgreSQL。
g)OpenStack Glance,是一个单独的项目,它是一个compute架构中可选的部分,分为三个部分:glance-api, glance-registry and the image store. 其中,glance-api接受API调用,glance-registry负责存储和检索镜像的元数据,实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store,包括OpenStack Object Storage (Swift)
h)最后,user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然,也有其他可用的Web前端。
3.2概念映射
将逻辑架构映射到概念架构中(如3-2所示),可以看见我们还缺少什么。
3-2 逻辑架构到概念架构的映射
这种覆盖方式并不是唯一的,这里的只是作者的理解。通过覆盖OpenStack Compute 逻辑组件,Glance和Dashboard,来表示功能范围。对于每一个覆盖,都有相应的提供该功能的逻辑组件的名称。
a)在这种覆盖范围中,最大的差距是logging和billing。此刻,OpenStack Compute没有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。真正的焦点是logging和Billing的整合。这能通过以下方式来补救。比如代码扩充,商业产品或者服务或者自定义日志解析的整合。
b)Identity也是未来可能要补充的一点。
c)customer portal也是一个整合点。user dashboard(见运行的实例,启动新的实例)没有提供一个界面,来允许应用拥有者签署服务,跟踪它们的费用以及声明有问题的票据(lodge trouble tickets)。而且,这很可能对我们设想的服务提供商来说是合适的。
d)理想的情况是,Admin API会复制我们能通过命令行接口做的所有功能。在带有Admin API work的Diablo 发布中会更好。
e)云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前,OpenStack Compute 提供 nova-instancemonitor,它跟踪计算结点使用情况。未来我们还需要三方工具来监控。
f)Policy是极其重要的方面,但是会与供应商很相关。从quotas到QoS,到隐私控制都在其管辖内。当前图上有部分覆盖,但是这取决于供应商的复杂需求。为准确起见,OpenStack Compute 为实例,浮点IP地址以及元数据提供配额。
g)当前,OpenStack Compute内的Scheduling对于大的安装来说是相当初步的。调度器是以插件的方式设计的,目前支持chance(随机主机分配),simple(最少负载)和zone(在一个可用区域里的随机结点。)分布式的调度器和理解异构主机的调度器正在开发之中。
如你所见,OpenStack Compute为我们想象的服务提供商,提供了一个不错的基础,只要服务提供商愿意做一些整合。
3.3OpenStack Compute系统架构
OpenStack Compute由一些主要组件组成。“Cloud controller”包含很多组件,它表示全局状态,以及与其他组件交互。实际上,它提供的是Nova-api服务。它的功能是:为所有API查询提供一个端点,初始化绝大多数的部署活动,以及实施一些策略。API 服务器起cloud controller web Service前端的作用。Compute controller 提供compute服务资源,典型包含compute service,Object Store component可选地提供存储服务。Auth manager提供认证和授权服务,Volume controller为compute servers提供快速和持久的块级别存储。Network controller提供虚拟网络使compute servers彼此交互以及与公网进行交互。Scheduler选择最合适的compute controller来管理(host)一个实例。
OpenStack Compute建立在无共享、基于消息的架构上。Cloud controller通过HTTP与internal object store交互,通过AMQP和scheduler、network controller、 和volume controller 来进行通信。为了避免在等待接收时阻塞每个组件,OpenStack Compute用异步调用的方式。
为了获得带有一个组件多个备份的无共享属性,OpenStack Compute将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中,必要时用质子事务。
对系统状态的请求会从store中读出。在少数情况下,控制器也会短时间缓存读取结果。
3.4OpenStack Compute物理架构
OpenStack Compute采用无共享、基于消息的架构,非常灵活,我们能安装每个nova- service在单独的服务器上,这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性,是Dashboard必须被安装在nova-api服务器。几种部署架构如下:
a)单结点:一台服务器运行所有的nova- services,同时也驱动虚拟实例。这种配置只为尝试OpenStack Compute,或者为了开发目的;
b)双结点:一个cloud controller 结点运行除nova-compute外的所有nova-services,compute结点运行nova-compute。一台客户计算机很可能需要打包镜像,以及和服务器进行交互,但是并不是必要的。这种配置主要用于概念和开发环境的证明。
c)多结点:通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点,你能在两结点的基础上,添加更多的compute结点,形成多结点部署。在较为复杂的多结点部署中,还能增加一个volume controller 和一个network controller作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例,至少是4个结点是最好的。
一个可能的Openstack Compute多服务器部署(集群中联网的虚拟服务器可能会改变)如下3-3所示:
3-3 OpenStack Compute物理架构一
如果你注意到消息队列中大量的复制引发了性能问题,一种可选的架构是增加更多的Messaging服务器。在这种情形下,除了可以扩展数据库服务器外,还可以增加一台额外的RabbitMQ服务器。部署中可以在任意服务器上运行任意nova-service,只要nova.conf中配置为指向RabbitMQ服务器,并且这些服务器能发送消息到它。
下图3-4是另外一种多结点的部署架构。
3-4 多结点的部署架构二
3.5 OpenStack Compute服务架构
因为Compute有多个服务,也可能有多种配置,下图3-5显示了总体的服务架构,以及服务之间的通信系统。
3-5 OpenStack Compute服务架构
4.OpenStack Image Service
OpenStack Image Service包括两个主要的部分,分别是API server和Registry server(s)。
OpenStack Image Service的设计,尽可能适合各种后端仓储和注册数据库方案。API Server(运行“glance api”程序)起通信hub的作用。比如各种各样的客户程序,镜像元数据的注册,实际包含虚拟机镜像数据的存储系统,都是通过它来进行通信的。API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service就是通过这些机制来实际保存进来的虚拟机镜像的。
OpenStack Image Service支持的后端仓储有:
a)OpenStack Object Storage。它是OpenStack中高可用的对象存储项目。
b)FileSystem。OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。这个简单的后端会把镜像文件写到本地文件系统。
c)S3。该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。
d)HTTP。OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。这种存储方式是只读的。
OpenStack Image Service registry servers是遵守OpenStack Image Service Registry API的服务器。
根据安装手册,这两个服务安装在同一个服务器上。镜像本身则可存储在OpenStack Object Storage, Amazon’s S3 infrastructure,fileSystem。如果你只需要只读访问,可以存储在一台Web服务器上。
5.OpenStack Object Storage
5.1 关键概念
a)Accounts和 Account Servers
OpenStack Object Storage系统被设计来供许多不同的存储消费者或客户使用。每个用户必须通过认证系统来识别自己。为此,OpenStack Object Storage提供了一个授权系统(swauth)。
运行Account服务的结点与个体账户是不同的概念。Account服务器是存储系统的部分,必须和Container服务器和Object服务器配置在一起。
b)Authentication 和 Access Permissions
你必须通过认证服务来认证,以接收OpenStack Object Storage连接参数和认证令牌。令牌必须为所有后面的container/object操作而传递。典型的,特定语言的API处理认证,令牌传递和HTTPS request/response 通信。
通过运用X-Container-Read: accountname和 X-Container-Write: accountname:username,你能为用户或者账户对对象执行访问控制。比如,这个设置就允许来自accountname账户的的任意用户来读,但是只允许accountname账户里的用户username来写。你也能给OpenStack Object Storage中存储的对象授予公共访问的权限,而且可以通过Referer头部阻止像热链接这种基于站点的内容盗窃,来限制公共访问。公共的container设置被用作访问控制列表之上的默认授权。比如,X-Container-Read: referer: any 这个设置,允许任何人能从container中读,而不管其他的授权设置。
一般来说,每个用户能完全访问自己的存储账户。用户必须用他们的证书来认证,一旦被认证,他们就能创建或删除container,以及账户之类的对象。一个用户能访问另一个账户的内容的唯一方式是,他们享有一个API访问key或你的认证系统提供的会话令牌。
c)Containers and Objects
一个Container是一个存储隔间,为你提供一种组织属于属于你的数据的方式。它比较类似于文件夹或目录。Container和其他文件系统概念的主要差异是containers不能嵌套。然而,你可以在你的账户内创建无数的containers。但是你必须在你的账户上有一个container,因为数据必须存在Container中。
Container取名上的限制是,它们不能包含“/”,而且长度上少于256字节。长度的限制也适用于经过URL编码后的名字。比如,Course Docs的Container名经过URL编码后是“Course%20Docs”,因此此时的长度是13字节而非11字节。
一个对象是基本的存储实体,和表示你存储在OpenStack Object Storage系统中文件的任何可选的元数据。当你上传数据到OpenStack Object Storage,它原样存储,由一个位置(container),对象名,以及key/value对组成的任何元数据。比如,你可选择存储你数字照片的副本,把它们组织为一个影集。在这种情况下,每个对象可以用元数据Album :
Caribbean Cruise 或Album : Aspen Ski Trip来标记。
对象名上唯一的限制是,在经过URL编码后,它们的长度要少于1024个字节。
上传的存储对象的允许的最大大小5GB,最小是0字节。你能用内嵌的大对象支持和St工具来检索5GB以上的对象。对于元数据,每个对象不应该超过90个key/value对,所有key/value对的总字节长度不应该超过4KB。
d)Operations
Operations是你在OpenStack Object Storage系统上执行的行为,比如创建或删除containers,上传或下载objects等等。Operations的完全清单可以在开发文档上找到。Operations能通过ReST web service API或特定语言的API来执行。值得强调的是,所有操作必须包括一个来自你授权系统的有效的授权令牌。
e)特定语言的API绑定
一些流行语言支持的API 绑定,在RackSpace云文件产品中是可用的。这些绑定在基础ReST API上提供了一层抽象,允许变成人员直接与container和object模型打交道,而不是HTTP请求和响应。这些绑定可免费下载,使用和修改。它们遵循MIT许可协议。对于OpenStack Object Storage,当前支持的API绑定是:PHP,Python,Java,C#/.NET 和Ruby。
5.2 Object Storage如何工作
a)Ring
Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作,他们都需要合相应的Ring进行交互以确定它在集群中的位置。
Ring用zones,devices,partitions,和replicas来维护映射,在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。Ring也负责确定失败场景中接替的设备。(这点类似HDFS副本的复制)。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack Object Storage installation所有设备中。分区需要移动的时候,Ring确保一次移动最少的分区,一次仅有一个分区的副本被移动。
权重能用来平衡分区在磁盘驱动上的分布。Ring在代理服务器和一些背景进程中使用。
b)Proxy Server
代理服务器负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次请求,它都查询在Ring中查询account, container, or object的位置,并以此转发请求。公有APIs也是通过代理服务器来暴露的。
大量的失败也是由代理服务器来进行处理。比如一个服务器不可用,它就会要求Ring来为它找下一个接替的服务器,并把请求转发到那里。
当对象流进或流出object server时,它们都通过代理服务器来流给用户,或者通过它从用户获取。代理服务器不会缓冲它们。
Proxy服务器的功能可以总结为:查询位置,处理失败,中转对象。
c)Object Server
Object Server,是非常简单的blob存储服务器,能存储、检索和删除本地磁盘上的对象,它以二进制文件形式存放在文件系统中,元数据以文件的扩展属性存放。
对象以源于对象名的hash和操作的时间戳的路径来存放。上一次写总会成功,确保最新的版本将被使用。删除也视作文件的一个版本:这确保删除的文件也被正确复制,更旧的把本不会因为失败情形离奇消失。
d)Container Server
其主要工作是处理对象列表,它不知道对象在哪里,只是知道哪些对象在一个特定的container。列表被存储为sqlite 数据库文件,类似对象的方式在集群中复制。也进行了跟踪统计,包括对象的总数,以及container中使用的总存储量。
e)Account Server
它是类似于Container Server,除了它是负责containers的列表而非对象。
f)Replication
设计副本的目的是,在面临网络中断或驱动失败等临时错误条件时,保持系统在一致的状态。
副本进程会比较本地的数据和每个远处的副本,以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段,而containe和 account replication 用的是Hash和共享的高水印结合的方法。
副本的更新,是基于推送的。对于对象副本,更新是远程同步文件到Peer。Account和container replication通过HTTP or rsync把整个数据库文件推送遗失的记录。
副本也通过tombstone设置最新版本的方式,确保数据从系统中清除。
g)更新器(Updaters)
有时,container 或 account数据不能被立即更新,这通常是发生在失败的情形或高负载时期。如果一个更新失败,该更新会在文件系统上本地排队,更新器将处理这些失败的更新。事件一致性窗口(eventual consistency window)最可能来起作用。比如,假设一个container服务器正处于载入之中,一个新对象正被放进系统,代理服务器一响应客户端成功,该对象就立即可读了。然而,container服务器没有更新Object列表,所以更新就进入队列,以等待稍后的更新。Container列表,因此可能还不会立即包含这个对象。
实际上,一致性窗口只是与updater运行的频率一样大,当代理服务器将转发清单请求到响应的第一个container服务器中,也许甚至还不会被注意。在载入之下的服务器可能还不是服务后续清单请求的那个。另外两个副本中的一个可能处理这个清单。
h)Auditors
Auditors会检查objects, containers, 和 accounts的完整性。如果发先损坏的文件,它将被隔离,好的副本将会取代这个坏的文件。如果发现其他的错误,它们会记入到日志中。
5.3 OpenStack Object Storage物理架构
Proxy Services 偏向于CPU和network I/O 密集型,而 Object Services, Container Services, Account Services 偏向于disk and networkI/O 密集型。
可以在每一服务器上安装所有的服务,在Rackspace内部, 他们将Proxy Services放在他们自己的服务器上,而所有存储服务则放在同一服务器上。这允许我们发送10G的网络给代理,1G给存储服务器,从而保持对代理服务器的负载平衡更好管理。我们能通过增加更多代理来扩展整个API吞吐量。如果需要获得Account或 Container Services更大的吞吐量,它们也可以部署到自己的服务器上。
在部署OpenStack Object Storage时,可以单结点安装,但是它只适用于开发和测试目的。也可以多服务器的安装,它能获得分布式对象存储系统需要的高可用性和冗余。
有这样一个样本部署架构,如图5-1所示。一个Proxy 结点,运行代理服务,一个Auth 结点,运行认证服务,五个Storage结点,运行Account,Container和Object服务。
5-1 五个Storage结点的OpenStack Object Storage物理架构
参考文献
[1] OpenStack Compute Administration Manual.
http://docs.openstack.org/cactus/openstack-compute/admin/content.
[2] OpenStack Object Storage Developer Guide.http://docs.openstack.org/.