职位名称：Hadoop工程师
职位年薪：20-30万工作地点：北京
招聘企业：某知名上市互联网公司所属部门：技术部所属行业：互联网·电子商务,基金·…汇报对象：开发经理企业性质：国内上市公司下属人数：0企业规模：5000-10000人
岗位职责
岗位职责：
1. 将投入到对hadoop、hive、hbase等相关产品进行预言、开发、应用中；
2. 解决海量数据不断增长面临的挑战，解决业务需求。
任职资格：
1. 熟练使用java集合类，IO，并发编程；
2. 熟悉jvm运行机制及内存管理；
3. 熟悉Linux/Unix操作系统，熟悉脚本编程(Shell/Perl/Python其中一种）；
4. 了解HADOOP原理，对于分布式系统有一定了解；
5. 有优秀的学习能力，具有强烈的主观能动性；
6. 计算机或相关专业本科或以上学历。
岗位要求
学历要求：全日制统招本科或以上性别要求：不限语言要求：普通话专业要求：不限年龄要求：25-35总工作年限：2年以上
任职资格的具体描述：
岗位职责：
1. 将投入到对hadoop、hive、hbase等相关产品进行预言、开发、应用中；
2. 解决海量数据不断增长面临的挑战，解决业务需求。
任职资格：
1. 熟练使用java集合类，IO，并发编程；
2. 熟悉jvm运行机制及内存管理；
3. 熟悉Linux/Unix操作系统，熟悉脚本编程(Shell/Perl/Python其中一种）；
4. 了解HADOOP原理，对于分布式系统有一定了解；
5. 有优秀的学习能力，具有强烈的主观能动性；
6. 计算机或相关专业本科或以上学历。
薪酬福利
职位年薪：20-30万薪资构成：底薪年假福利：国家标准社保福利：国家标准
—————————————————————————————————————————–
职位名称：Hadoop开发工程师
职位年薪：15-18万工作地点：北京
招聘企业：某互联网广告公司所属部门：IT部门所属行业：互联网·电子商务,广告·…汇报对象：部门负责人企业性质：私营·民营企业下属人数：0企业规模：100-499人
岗位职责
1、负责搭建hadoop集群，并维护与管理；
2、负责hadoop平台上的数据存储，数据维护和优化；
3、负责编写pig,hive等分析脚本；
4、负责把分析结果导入到数据库中,为BI提供基础数据分析。
岗位要求
学历要求：全日制统招本科或以上性别要求：不限语言要求：普通话专业要求：不限年龄要求：25-40总工作年限：3年以上
任职资格的具体描述：
1、本科以上学历，3年以上相关工作经验；
2、对数据结构、算法有深刻理解；
3、熟悉linux开发环境；
4、熟悉python、shell、perl中的一种；
5、有hadoop集群部署和开发经验；
6、熟悉pig,hive,hbase, spooq,flume,scribe(优先考虑)；
7、熟悉java开发(精通优先考虑)。
薪酬福利
职位年薪：15-18万薪资构成：底薪年假福利：国家标准社保福利：国家标准居住福利：住房补贴

开源云计算技术有很多， 包括Eucalyptus、OpenNebula和OpenStack等。其中很多开源技术都存在商业版，导致开源的版本功能很少或者不完善。我选择用OpenStack来实现开源云构建，因为OpenStack是完全开源的技术，没有任何收费版本或者商业版本。OpenStack是由Rackspace和NASA共同开发的云计算平台，帮助服务商和企业内部实现类似于Amazon EC2和S3的云基础架构服务（Infrastructure as a Service，IaaS）。OpIenStack包含两个主要模块：Nova和Swift，前者是NASA开发的虚拟服务器部署和业务计算模块；后者是Rackspack开发的分布式云存储模块，两者可以一起用，也可以分开单独用。OpenStack除了有Rackspace和NASA的大力支持外，后面还有包括Dell，Citrix，Cisco，Canonical这些重量级公司的贡献和支持，发展速度非常快，有取代另一个业界领先开源云平台Eucalyptus的态势。
开源云技术构建
随着信息建设的发展，每个单位的信息中心都会面临越来越多的服务器和越来越多的部门需要自己的服务器。原来单位里是按照部门给分配服务器，这样虽然看起来很好，每个部门有自己的服务器。但是资源浪费很大，因为并不是每个部门都可以把服务器资源使用到满负荷，而且每个部分还要有人管理服务器的硬件维护。虚拟化可以很好的解决这个问题，但是对于多服务器的资源整合和动态分配，资源的统一管理等方面虚拟化并不能全部解决。
我们的想法是在企业的信息中心建立企业内部的私有云。将闲置的服务器资源组成企业的私有云平台来为各个部门服务。考虑到初期的建设难度和技术门槛，我们开始完全可以基于开源的OpenStack技术从原来的虚拟化过度到IaaS（基础设施即服务）的云平台上面。
OpenStack总体上分为三个部分组成Nova、Swift和Glance。Nova负责云计算平台的资源管理。Swift是存储模块，负责映像存储、备份和归档等。Glance是映像服务模块，负责云平台中虚拟化系统的映像管理。OpenStack每个模块之间是无关联的，我们可以将所有模块部署在一台服务器，也可以部署在多台服务器。作为初步体验云平台，我们完全可以用2台服务器加一台客户机来实现云计算平台的部署。具体部署可以参考OpenStack的官方手册，这里就不在列出。随着云的建立，我们可以将单位中各个部门的服务器全部放在云里。每个部门的服务器其实就是云里的一个虚拟化实例，所有数据统一存储在Glance模块创建的卷里。每个实例可以很方便的在云里不同的硬件服务器中迁移和动态分配不同的资源给实例。
随着信息化发展，云计算平台将会越来越普及。企业早一步实现自己的云平台，就能在将来的发展中具有更大优势。通过云的应用，可以降低信息化建设成本并降低各部门重复投资的硬件与管理成本。而且目前开源云技术已经日趋成熟和稳定，完全可以满足企业的日常需要。

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这个名字不是一个缩写，它是一个虚构的名字。该项目的创建者，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 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机制。

摘要：虚拟化已经深入了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的架构
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/.

HDFS支持权限控制的设计是基于POSIX模型，支持按用户、用户组、其他用户的读写执行控制权限。
在linux命令行下，可以使用下面的命令修改文件的权限、文件所有者，文件所属组：
•hadoop fs –chmod （修改文件所有者，文件所属组，其他用户的读、写、执行权限）
•haddop fs –chown （修改文件所有者）
•hadoop fs –chgrp （修改文件所属组）
不同用户使用不同的linux帐户即可访问到特定文件。
启动hadoop hdfs系统的用户即为超级用户，可以进行任意的操作。