首页 » 云计算 » OPENSTACK » OpenStack入门 之 扩展话题

OpenStack入门 之 扩展话题

　
暂无评论　1,850次浏览

 

写在前面

学习目标：

  • 了解 OpenStack 的自动化部署

  • 了解 Hadoop 云化时存在的问题

  • 了解 Ceph 的简介及 Ceph 在 OpenStack 中的应用

  • 了解 OpenStack 与 Docker

本次笔记的内容有：

  • OpenStack 自动化部署

  • Hadoop 云化时存在的问题

  • 基于 OpenStack 实现 Hadoop 云化

  • Ceph 简介

  • Ceph 在 OpenStack 中的应用

  • OpenStack 与 Docker

1. OpenStack自动化部署

做一些基于 OpenStack 的开发工作，如果花太多时间在部署环境和调试上是不太恰当的，不过 OpenStack 提供了一些自动化部署的工具。

[ 自动化部署分为三个层次：]

  1. 单节点的自动安装。经常用于准备一个开发环境，甚至可以在一台笔记本上就可以完成一个 OpenStack 环境的搭建，常用的工具是 DevStack

  2. 集群化安装。最常用的工具是 puppet，puppet 不是 OpenStack 社区的东西，但是与 OpenStack 结合的比较紧密，用 puppet 来安装 OpenStack 也比较常见

  3. 多个集群的安装和部署。常见的工具是由 Mirantic 推出的 fuel，在运营商和做托管云业务的公司里面显得尤为重要，因为他们可能要面对不同的客户，要管理很多的 OpenStack 集群

2. Hadoop云化时存在的问题

之前的 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 主导的，主要组成部分如图所示：

Mypicpick20160406-150112.png

3. 基于OpenStack实现Hadoop云化

Sahara 有两种模式，分别从部署管理和提供数据处理服务两个层次上对 Hadoop 云化做了一些工作。

Hadoop 节点会利用本地磁盘来构建一个分布式文件系统如图所示

Mypicpick20160406-150454.png

Mypicpick20160406-150625.png

虚拟机的本地根硬盘（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 里面了）。如下图所示：

Mypicpick20160406-151724.png

Hadoop 和 Swift 的集成现在已经做到了 Hadoop 社区的开源项目里面了。一说到 Hadoop 的云化，不得不提到 VMware 的 BDE（Big Data Extensions），这个 BDE 和 OpenStack 的 Sahara 非常像，但是在各个方面都做得比 Sahara 好很多，而且和 HVE 的集成非常好。

4. Ceph简介

上面说到了 Hadoop 与 OpenStack 的结合，Hadoop 经常被认为是用来作大数据处理的，大数据基础设施的另外一方面是大数据的存储。说到 OpenStack 的存储，除了 Swift 以外还有 Ceph 系统。

Ceph 经常被用来作为 RBD 设备，提供块存储服务从架构上来说，Ceph 从上往下分为三个层次，如图所示：

Mypicpick20160406-153254.png

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 系统可以分为以下几个部分：逻辑结构 ]

Mypicpick20160406-155209.png

  • OSDs 整个系统的基石

  • Monitors 监控整个系统的状态

  • Clients 客户端，如果没有这个客户端，整个数据的读写会难以实现

[ Ceph 系统中的寻址流程：]

  1. 把这个文件拆成若干个 Objects

  2. 把这个 Objects 放到我们的PG组里面

  3. 每个组通过一个 CRUSH 算法给它映射到不同的 OSD 上，

有一个比较大的特点，它的每一步都是通过计算得到的，中间没有查表，这就让 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 接口，形成了一个文件系统

Mypicpick20160406-160541.png

Ceph 的架构、Ceph 的数据存储流程，注意区分两类对象存储以及 object 在不同场合的概念的不同。

5. Ceph在OpenStack中的应用

[ Ceph受欢迎的原因：]

  • 通过 Cinder 为虚拟机提供廉价的块存储服务。基于 x86，搭建分布式块存储系统（强调是块存储，因为它有强一致性的要求，有高性能的要求，这些在对象存储的里面是没有的，在HDFS里面也是比较弱的）。Cinder 支持 Ceph 提供的RBD设备，有了 Cinder 和 Ceph 的结合在搭建OpenStack集群的时候就不用去买存储设备了，可以直接用Ceph基于x86硬件普通的这种服务器，就可以搭一个块存储系统，提供给虚拟机去使用（提供给虚拟机做卷），成本低。在很多情况下，Ceph 的性能甚至超过了很多专业的存储设备。

  • Ceph 提供 Swift 兼容的对象存储接口，如果要实施一个 OpenStack 的部署，可以用同一套存储系统来做块和对象的存储，并不一定非要去安装一套 Swift。那么，有了 Ceph 以后还需不要 Swift？ Ceph 第一适合的是做块存储，是强一致性，Swift 默认是最终一致性，Swift 更符合对象存储的场景，Swift 有针对对象存储的先进的 Feature 比如说 Storage Policy 可以供用户去选择数据的存储策略，在很多商用的对象存储设备里都是没有的，所以说 Swift 在对象存储领域里是非常领先的，而且天生就是支持多租户的，与 OpenStack 的结合非常完美。

  • OpenStack 所有存储都支持 Ceph 作为后端

[ 关于对 Swift 或 Ceph 的选择：]

Mypicpick20160406-162757.png

案例1：规模小，节点数量少的使用 Ceph，因为 Swift 至少要用到5个节点，划不来。

案例2：需要提供云盘的服务，做云盘就意味着要面对大量的用户，还希望用户的体验好，可以让用户来选择数据怎么存，这个时候选择 Swift 是更好的，一方面对于这种规模化部署的支持比较好，第二方面它有一些先进的 Feature，第三方面它的价格成本比 Ceph 要低一些

6. OpenStack与Docker

Container 技术

Mypicpick20160406-164639.png

Mypicpick20160406-164927.png

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 的结合：]

  • 使用 Swift 做 Docker 镜像的存储后端

  • 用 Nova 调度和管理 Docker 容器

  • 使用 Heat 实现 Docker 容器

  • 使用 Heat 实现 Docker 的 Orchestration

  • 基于 Neutron 设计与实现适用于 Docker 的 SDN 方案

  • 用 Glance 来管理 Docker 的镜像

End.


原文链接：OpenStack入门 之 扩展话题，转载请注明来源！

赞 0