标签：
学习目标：
本次笔记的内容有：
做一些基于 OpenStack 的开发工作，如果花太多时间在部署环境和调试上是不太恰当的，不过 OpenStack 提供了一些自动化部署的工具。
[ 自动化部署分为三个层次：]
之前的 Sahara 就是用来支持 Hadoop 云化的。那么，Hadoop 的云化到底需要解决什么问题？
Hadoop 是用来做大数据处理的一个工具，Hadoop 有自己的生态圈，非常庞大，其中最重要的两个软件是 HDFS 分布式文件系统 和 MapReduce 任务调度框架。 HDFS 把文件分成块，把块分成三个副本放在不同的节点上，形成一个高可靠性的文件系统，MapReduce 把我们提交的数据和处理的任务 job 拆成不同的 task 分发到不同的节点上，以实现并行的处理，MapReduce 最大的特点就是能够把任务调度到离数据近的节点上，尽量的来减少数据在网络之间的传输，可以使用通用的廉价的 x86 服务器和网络设备来构建一个数据并行处理的系统。
Hadoop 使用的时候也有一个现实的问题：在生产环境使用的时候安装、部署、调试的工作很多，想要能把 Hadoop 云化，能够实现像 AWS 的 EMR 里面那样通过轻松的点点按钮就能在云端 provision 出一个 Hadoop 集群来。那么，实现这个目标会遇到什么问题呢？
OpenStack 有自己的虚拟机调度，Hadoop 里面有自己的任务调度，这是两个不同层次的资源调度。Hadoop 的 HDFS 的三个副本会在三个虚拟机里面，如果是跑在一台物理机上，如果物理机坏了那么三个副本就会消失，并没有达到它的可靠性的目的。
Hadoop 社区里面有一个开源的子项目叫作 Hadoop Virtual Extensions 简称 HVE，是由 VMware 主导的，主要组成部分如图所示：
Sahara 有两种模式，分别从部署管理和提供数据处理服务两个层次上对 Hadoop 云化做了一些工作。
Hadoop 节点会利用本地磁盘来构建一个分布式文件系统如图所示
虚拟机的本地根硬盘（Linux 上的 BDA）往往是临时的，它的生命周期往往和虚拟机的 Instance 的生命周期是一样的，如果我们在 Hadoop 云化的时候采用根硬盘来构建 HDFS 的话，虚拟机就会在需要的时候创建、不需要的时候就销毁了，那么 HDFS 里的数据便也会没了，这是不行滴。我们可以有另外一种选择：不使用根硬盘去构建 HDFS，而是使用 Cinder 提供的卷来做。但是这样还存在一个问题，那就是 MapReduce 会尽量把数据调度到离数据近的节点上去减少网络中数据的传输，而 Cinder 的卷通常都是通过网络来实现的，所以它就没有把 Hadoop 的优点利用起来，反而增加了网络的负担。Hadoop 通常又是基于通用的商用的廉价的网络设备来实现并行处理的，这样势必会降低整个 Hadoop 集群的性能。
总结出这对矛盾就是：如果使用本地的根硬盘，它的数据会丢失；如果使用Cinder，又会给网络带来很大的压力，而且降低了数据处理的速度。
[ 最正确的做法应该是：]
在 Hadoop 集群里面仍然使用本地的根硬盘来构建 HDFS，但是把数据源放在 Swift 里面，也就是说我们上传要处理的原始数据，还有要上传要运行的 Job 的时候并不是把它存到 HDFS 里面而是上传到 Swift 里面，然后Hadoop 集群 provision 出来以后，要运行 Job 的时候再从 Swift 里把这些数据读出来，处理完之后再把结果保存到 Swift 里边。然后由虚拟机构建的 Hadoop 集群就可以销毁了，那些根硬盘同时被销毁了也没有关系（因为我们的数据已经在 Swift 里面了）。如下图所示：
Hadoop 和 Swift 的集成现在已经做到了 Hadoop 社区的开源项目里面了。一说到 Hadoop 的云化，不得不提到 VMware 的 BDE（Big Data Extensions），这个 BDE 和 OpenStack 的 Sahara 非常像，但是在各个方面都做得比 Sahara 好很多，而且和 HVE 的集成非常好。
上面说到了 Hadoop 与 OpenStack 的结合，Hadoop 经常被认为是用来作大数据处理的，大数据基础设施的另外一方面是大数据的存储。说到 OpenStack 的存储，除了 Swift 以外还有 Ceph 系统。
Ceph 经常被用来作为 RBD 设备，提供块存储服务从架构上来说，Ceph 从上往下分为三个层次，如图所示：
Swift 里面更像我们传统说的文件的概念，我们把文件上传到 Swift 里面，作为一个对象存在那里，这也是它跟传统的文件系统作区分的一个概念。Ceph 的 Object 实际上是把一个文件给拆成了很多个 Object 分别放到底层的存储设备上，这个 Object 与普通的一个文件 Object 所指的东西是完全不一样的。其实底层实现的整个架构它的机制也是不一样的，Ceph 最下面的一层就是 RADOS 这一套对象存储，它本身就是一个完整的存储系统，所有 Ceph 系统中存储的用户数据事实上最后都是落实到这层上来存的。Ceph 里面所声称的这些高可靠性高可扩展性高性能高自动化等等特性也是由这层提供的，这层底层的硬件实际上是由大量的存储节点组成的，可以是 x86 服务器也可以是 ARM 的，它的核心是一个叫做 OSD 的东西，这个 OSD 是 Object Storage daemon。Ceph 里面的 OSD 虽然指的是 daemon（一个软件、一个服务进程），和 Cinder 里面定义的 OSD（object storage device）之间有很强的对应关系，可以认为是 Object Storage Device 简略的一个版本
[ 整个 RADOS 系统可以分为以下几个部分：逻辑结构 ]
[ Ceph 系统中的寻址流程：]
有一个比较大的特点，它的每一步都是通过计算得到的，中间没有查表，这就让 Ceph 的扩展性比较好
接着
在 RADOS 上面有一个叫作 LIBRADOS 这样一个库，这个库提供了一组可以直接访问 RADOS 系统的 API，这个地方是 RADOS 不是访问整个 Ceph。实际上说的 Ceph 的接口又是通过什么样的东西来提供的呢？实际上是通过再上面的一个层次，这个层次包括三个部分，一个是 RADOS 的 Gateway，第二个是 RBD 的模块，第三个是 CEPH FS（file system）。
RADOS 的 Gateway 是把底层的对象存储系统往外再次进行封装，提供一个兼容 Swift、兼容 Amazon S3 的对象存储的接口，这个接口也是 HTTP 的，另外一部分就是我们前面说的 RBD 的块设备，经常被作为 Cinder 的后端给虚拟机提供卷，第三块是 CEPH FS ,在 Ceph 的基础上封装了一个 POSIX 接口，形成了一个文件系统
Ceph 的架构、Ceph 的数据存储流程，注意区分两类对象存储以及 object 在不同场合的概念的不同。
[ Ceph受欢迎的原因：]
[ 关于对 Swift 或 Ceph 的选择：]
案例1：规模小，节点数量少的使用 Ceph，因为 Swift 至少要用到5个节点，划不来。
案例2：需要提供云盘的服务，做云盘就意味着要面对大量的用户，还希望用户的体验好，可以让用户来选择数据怎么存，这个时候选择 Swift 是更好的，一方面对于这种规模化部署的支持比较好，第二方面它有一些先进的 Feature，第三方面它的价格成本比 Ceph 要低一些
Container 技术
Hypervisor 在传统的意义上是指可以在一个宿主机上创建一个环境，这个环境里面我们可以创建一些虚拟机，虚拟机里面可以装客户操作系统 Guest OS ，然后这上面再装我们的中间件和应用等等。其实还有另外一种虚拟化技术，就是不用在里面再安装 Guest OS，直接基于宿主机的操作系统来做在上面做一些运营环境的隔离，做一些资源的划分等等，然后每一个形成一个容器，然后再让这些应用跑到这些容器里面，容器之间实际上底层是共享一个操作系统的，甚至可以共享一些公用的库。和传统的 Hypervisor 的方式来比，它有一个比较大的优势就是省去了 Guest OS 的开销，也有它的劣势比如里面只能使用和宿主机相同的操作系统，而没有办法再装像 Windows 等别的操作系统，甚至是同一个操作系统的不同的版本都会很困难，因为他的底层机制就不支持在里边再装一个操作系统的机制，直接用的就是宿主机的东西，这个就是我们说的 Container 技术，Linux 底下有一个比较著名的 Container 名字就直接叫作 Linux Container（LXC）
随着 Docker 的发展，Container 技术一下就火起来了。What is Docker？（Google YI XIA NI JIU Know）
[ OpenStack 与 Docker 的结合：]
End.
网络 MOOC 学习笔记
From 高校帮 《OpenStack 入门 @讲师 李明宇》
By 胡飞
at 2016/4/6 19:33:51
标签：
原文地址：http://blog.csdn.net/heartyhu/article/details/51087133
