OpenStack里的三种存储

OpenStack里的三种存储
[转]http://www.openstack.cn/?p=446 http://cloud.51cto.com/art/201304/387374.htm
Swift——提供对象存储 (Object Storage)，在概念上相似于Amazon S3服务，不过swift具备很强的扩展性、冗余和持久性，也兼容S3 API

Glance——提供虚机镜像(Image)存储和管理，包括了不少与Amazon AMI catalog类似的功能。(Glance的后台数据从最初的实践来看是存放在Swift的)。

Cinder——提供块存储(Block Storage)，相似于Amazon的EBS块存储服务，目前仅给虚机挂载使用。

(Amazon一直是OpenStack设计之初的假象对手和挑战对象，因此基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于 AWS中的重要的EC2服务，OpenStack中是Nova来对应，而且保持和EC2 API的兼容性，有不一样的方法能够实现)

三个组件中，Glance主要是虚机镜像的管理，因此相对简单;Swift做为对象存储已经很成熟，连CloudStack也支持它。Cinder是比较新出现的块存储，设计理念不错，而且和商业存储有结合的机会，因此厂商比较积极。

Swift

关于Swift的架构和部署讨论，除了官方网站，网上也有不少文章，这里就不重复.从开发上看，最近也没有太大的结构性调整，因此我想主要说说比较适用的应用领域好了。

从我所了解的实际案例来看，Swift出现的领域有4个，(应该还有更多，但愿你们看到实际用例可以指教)

1.网盘

Swift的对称分布式架构和多proxy多节点的设计致使它从基因里就适合于多用户大并发的应用模式，最典型的应用莫过于相似Dropbox的网盘应用，Dropbox去年末已经突破一亿用户数，对于这种规模的访问，良好的架构设计是可以支撑的根本缘由。

Swift的对称架构使得数据节点从逻辑上看处于同级别，每台节点上同时都具备数据和相关的元数据。而且元数据的核心数据结构使用的是哈希环，一致 性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具备较好的容错性和可扩展性。另外数据是无状态的，每一个数据在磁盘上都是完整的存储。这几 点综合起来保证了存储的自己的良好的扩展性。

另外和应用的结合上，Swift是说HTTP协议这种语言的，这使得应用和存储的交互变得简单，不须要考虑底层基础构架的细节，应用软件不须要进行任何的修改就可让系统总体扩展到很是大的程度。

2.IaaS公有云

Swift在设计中的线性扩展，高并发和多租户支持等特性，使得它也很是适合作为IaaS的选择，公有云规模较大，更多的遇到大量虚机并发启动这种 状况，因此对于虚机镜像的后台存储具体来讲，实际上的挑战在于大数据(超过G)的并发读性能，Swift在OpenStack中一开始就是做为镜像库的后 台存储，通过RACKSpace上千台机器的部署规模下的数年实践，Swift已经被证实是一个成熟的选择。

另外若是基于IaaS要提供上层的SaaS 服务，多租户是一个不可避免的问题，Swift的架构设计自己就是支持多租户的，这样对接起来更方便。

3.备份归档

RackSpace的主营业务就是数据的备份归档，因此Swift在这个领域也是久经考验，同时他们还延展出一种新业务–“热归档”。因为长尾效 应，数据可能被调用的时间窗愈来愈长，热归档可以保证应用归档数据可以在分钟级别从新获取，和传统磁带机归档方案中的数小时而言，是一个很大的进步。

4. 移动互联网和CDN

移动互联网和手机游戏等产生大量的用户数据，数据量不是很大可是用户数不少，这也是Swift可以处理的领域。

至于加上CDN，若是使用Swift，云存储就能够直接响应移动设备，不须要专门的服务器去响应这个HTTP的请求，也不须要在数据传输中再通过移 动设备上的文件系统，直接是用HTTP 协议上传云端。若是把常常被平台访问的数据缓存起来，利用必定的优化机制，数据能够从不一样的地点分发到你的用户那里，这样就能提升访问的速度，我最近看到 Swift的开发社区有人在讨论视频网站应用和Swift的结合，窃觉得是值得关注的方向。

Glance

Glance比较简单，是一个虚机镜像的存储。向前端nova(或者是安装了Glance-client的其余虚拟管理平台)提供镜像服务，包括存储，查询和检索。这个模块自己不存储大量的数据，须要挂载后台存储(Swift，S3。。。)来存放实际的镜像数据。

Glance主要包括下面几个部分：

l API service： glance-api 主要是用来接受Nova的各类api调用请求，将请求放入RBMQ交由后台处理，。

l Glacne-registry 用来和MySQL数据库进行交互，存储或者获取镜像的元数据，注意，刚才在Swift中提到，Swift在本身的Storage Server中是不保存元数据的，这儿的元数据是指保存在MySQL数据库中的关于镜像的一些信息，这个元数据是属于Glance的。

l Image store： 后台存储接口，经过它获取镜像，后台挂载的默认存储是Swift，但同时也支持Amazon S3等其余的镜像。

Glance从某种角度上看起来有点像虚拟存储，也提供API，能够实现比较完整的镜像管理功能。因此理论上其余云平台也可使用它。

Glance比较简单，又限于云内部，因此没啥能够多展开讨论的，不如看看新出来的块存储组件Cinder，目前我对Cinder基本的见解是整体的设计不错，细节和功能还有不少须要完善的地方，离一个成熟的产品还有点距离。

Cinder

OpenStack到F版本有比较大的改变，其中之一就是将以前在Nova中的部分持久性块存储功能(Nova-Volume)分离了出来，独立为 新的组件Cinder。它经过整合后端多种存储，用API接口为外界提供块存储服务，主要核心是对卷的管理，容许对卷，卷的类型，卷的快照进行处理。

Cinder包含如下三个主要组成部分

API service：Cinder-api 是主要服务接口, 负责接受和处理外界的API请求，并将请求放入RabbitMQ队列，交由后端执行。 Cinder目前提供Volume API V2

Scheduler service: 处理任务队列的任务，并根据预约策略选择合适的Volume Service节点来执行任务。目前版本的cinder仅仅提供了一个Simple Scheduler, 该调度器选择卷数量最少的一个活跃节点来建立卷。

Volume service: 该服务运行在存储节点上，管理存储空间，塔处理cinder数据库的维护状态的读写请求，经过消息队列和直接在块存储设备或软件上与其余进程交互。每一个存 储节点都有一个Volume Service，若干个这样的存储节点联合起来能够构成一个存储资源池。

Cinder经过添加不一样厂商的指定drivers来为了支持不一样类型和型号的存储。目前能支持的商业存储设备有EMC 和IBM的几款，也能经过LVM支持本地存储和NFS协议支持NAS存储，因此Netapp的NAS应该也没问题，好像华为也在努力中。我前段时间还在 Cinder的blueprints看到IBM的GPFS分布式文件系统，在之后的版本应该会添加进来

到目前为止，Cinder主要和Openstack的Nova内部交互，为之提供虚机实例所须要的卷Attach上去，可是理论上也能够单独向外界提供块存储。

部署上，能够把三个服务部署在一台服务器，也能够独立部署到不一样物理节点

如今Cinder仍是不够成熟，有几个明显的问题还没很好解决，一是支持的商业存储还不够多，并且还不支持FC SAN，另外单点故障隐患没解决，内部的schedule调度算法也太简单。另外因为它把各类存储整合进来又加了一层，管理却是有办法了，可是效率确定是 有影响，性能确定有损耗，但这也是没办法的事了。

Openstack经过两年多发展，变得愈来愈庞大。目前光存储就出现了三种：对象存储、镜像存储和块存储。这也是为了知足更多不一样的需求，体现出 开源项目灵活快速的特性。总的说来，当选择一套存储系统的时候，若是考虑到未来会被多个应用所共同使用，应该视为长期的决策。Openstack做为一个 开放的系统，最主要是解决软硬件供应商锁定的问题，能够随时选择新的硬件供应商，将新的硬件和已有的硬件组成混合的集群，统一管理，固然也能够替换软件技 术服务的提供商，不用动应用。这是开源自己的优点!