openstack中cinder与swift、glance的区别

问题导读
1.你认为cinder与swift区别是什么？
2.cinder是否存在单点故障？
3.cinder是如何发展而来的？








在openstack中，咱们常常遇到这么个问题，cinder与swift的区别是什么？

cinder与swift各自的用途是什么？
cinder是块存储，用来给虚拟机挂扩展硬盘，就是将cinder建立出来的卷，挂到虚拟机里。cinder是OpenStack到F版，将以前在Nova中的部分持久性块存储功能（Nova-Volume）分离了出来，独立为新的组件Cinder

swift是一个系统，能够上传和下载，里面通常存储的是不常常修改的内容，好比用于存储 VM 镜像、备份和归档以及较小的文件，例如照片和电子邮件消息。更倾向于系统的管理


块存储具备安全可靠、高并发大吞吐量、低时延、规格丰富、简单易用的特色，适用于文件系统、数据库或者其余须要原始块设备的系统软件或应用。



上面其实不少感受不是太直观，我的认为cinder能够理解为我的电脑的移动硬盘，它能够随意格式化，随时存取。
对于swift能够做为网盘，相信对于云技术的同窗来讲，网盘应该是不陌生的，若是把一些常常用的内容，放到网盘中是很是不方便的。

Swift 仍是 Cinder？什么时候使用以及使用哪种？
那么，应该使用哪种对象存储：Swift 仍是 Cinder？答案取决于您的应用程序。若是须要运行商用或遗留应用程序，那么不多须要进行这种选择。这些应用程序不可能被编码来利用 Swift API，但您能够轻松挂载一个 Cinder 磁盘，它表现得就像是直接将存储附加到大多数应用程序。
固然，您还能够对新应用程序使用 Cinder，可是不会从 Swift 自动附带的弹性和冗余中获益。若是编程人员面对这样的挑战，那么 Swift 的分布式可扩展架构是一个值得考虑的特性。


单点故障
Swift 架构是分布式的，可防止全部单点故障和进行水平扩展。
cinder存在单点故障还未解决




更多内容，如下来自ibm资料库：


块存储 (Cinder)
Cinder 是 OpenStack Block Storage 的项目名称；它为来宾虚拟机 (VM) 提供了持久块存储。对于可扩展的文件系统、最大性能、与企业存储服务的集成以及须要访问原生块级存储的应用程序而言，块存储一般是必需的。
系统能够暴露并链接设备，随后管理服务器的建立、附加到服务器和从服务器分离。应用程序编程接口 (API) 也有助于增强快照管理，这种管理能够备份大量块存储。




对象存储 (Swift)

Swift 是两种产品中较为成熟的一个：自 OpenStack 成立以来一直是一个核心项目。Swift 的功能相似于一个分布式、可访问 API 的存储平台，可直接将它集成到应用程序中，或者用于存储 VM 镜像、备份和归档以及较小的文件，例如照片和电子邮件消息。

Object Store 有两个主要的概念：对象和容器。

对象就是主要存储实体。对象中包括与 OpenStack Object Storage 系统中存储的文件相关的内容和全部可选元数据。数据保存为未压缩、未加密的格式，包含对象名称、对象的容器以及键值对形式的全部元数据。对象分布在整个数据中心的多个磁盘中，Swift 能够借此确保数据的复制和完整性。分布式操做能够利用低成本的商用硬件，同时加强可扩展性、冗余性和持久性。

容器相似于 Windows® 文件夹，容器是用于存储一组文件的一个存储室。容器没法被嵌套，但一个租户能够供建立无限数量的容器。对象必须存储在容器中，因此您必须至少拥有一个容器来使用对象存储。

与传统的文件服务器不一样，Swift 是横跨多个系统进行分布的。它会自动存储每一个对象的冗余副本，从而最大程度地提升可用性和可扩展性。对象版本控制提供了防止数据意外丢失或覆盖的额外保护。


Swift 架构

Swift 架构包含三个组件：服务器、流程和环。

服务器

Swift 架构是分布式的，可防止全部单点故障和进行水平扩展。它包括如下四种服务器：

• 代理服务器
• 对象服务器
• 容器服务器
• 账户服务器
  

代理服务器为 OpenStack Object Storage 架构的其他部分提供一个统一的界面。它接收建立容器、上传文件或修改元数据的请求，还能够提供容器清单或展现存储的文件。当收到请求时，代理服务器会肯定账户、容器或对象在环中的位置，并将请求转发至相关的服务器。

对象服务器是一种简单的服务器，能够上传、修改和检索存储在它所管理的设备上的对象（一般为文件）。对象被存储在本地文件系统中，使用了扩展的属性保存全部的元数据。路径基于对象名称的散列和时间戳。

容器服务器实质上是对象的一个目录。它处理特定容器的对象的分配，并根据请求来提供容器清单。能够跨集群复制该清单，以提供冗余。

账户服务器经过使用对象存储服务来管理账户。它的操做相似于在内部提供了清单的容器服务器，在这种状况下，将会枚举分配到给定账户的容器。

流程

有几种预约的内部管理流程能够管理数据存储，包括复制服务、审计程序（auditor）和更新程序（updater）。

复制服务是相当重要的流程：确保整个集群的一致性和可用性。因为对象存储的一个主要吸引点是其分布式存储，因此 OpenStack 必须在瞬态错误条件下确保得到一致的状态，例如断电或组件故障。复制服务经过按期对比本地数据与远程副本并确保全部副本都包含最新版原本作到这一点。

为了最大程度地减小进行对比所需的网络流量的数量，该服务建立了每一个分区分段的一个散列（hash），并比较这些列表。容器和账户复制也可使用散列，但经过高水位标记（high-water mark）对这些散列进行了补充。实际的更新被推送，一般使用  rsync 来复制对象、容器和账户。

在删除对象、容器或账户时，复制器（replicator）还会执行垃圾收集来实施一致的数据删除。在删除时，系统会使用一个墓碑图片来标记最新版本，这是一个告诉复制器能够从全部重复的节点中删除对象、容器或账户的信号。

即便是最好的复制设计，也只在拥有实现该复制的组件时有效，不过，不管是硬件故障仍是软件故障，抑或只是由于产品能力不足，生产环境都必须可以重现这些故障。在 Swift 中，该操做是由更新程序和审计程序来完成的。

更新程序负责在系统面临故障时确保系统的完整性。当复制服务遇到一个问题，而且没法更新容器或账户时，就会出现一段时间的不一致，在此其间，对象虽然存在于存储中，但并未列出在全部容器或账户服务器上。在这种状况下，系统会在本地文件系统上对更新进行排队，并有一个更新程序会按期重试更新。

审计程序对这种不一致提供额外级别的保护。它们按期扫描本地存储库，验证账户、容器和对象的完整性。在确认任何损坏时，审计程序会隔离该元素，并使用来自另外一个复制物的副本替换它。若是发现了没法协调的不一致性（例如，对象不属于任何容器），审计程序就会将该错误记录在一个日志文件中。

环

用户和其余 OpenStack 项目会根据逻辑名称来引用存储实体，但最终，全部请求，不管是用于读取仍是用于写入，都必须映射到某个物理位置。为了完成这一操做，代理服务器和后台流程（包括复制服务）都必须可以将逻辑名称映射到物理位置。这种映射就称为一个环（ring）。账户、容器和对象都配有单独的环。环根据设备、分区、副本和专区来描述这一映射。

在此上下文中，术语分区 指的是环中所存储内容的逻辑子集。建议为每一个参与设备分配 100 个分区。分区均匀地分布在分配给 OpenStack Object Storage 的全部设备上。若是集群使用了不一样规格的驱动，那么有可能会分配权重，以便平衡各个设备上的分区的分布。

默认状况下，每一个分区可被复制三次。有可能会使用一个较大的数字来优化可用性，但这显然会增长存储消耗。环还会指定在故障场景中使用哪些设备来接管工做负载，以及在向集群添加设备或从中删除设备时如何从新分配分区。

环映射的最后一个元素是专区，用于启用数据亲和性和反亲和性，一个专区能够表示一个存储设备、一个物理服务器或者一个位置，例如机架、通道或数据中心，专区是用户可用来知足其需求的一个逻辑概念，但一般反映的是物理元素，例如位置、电源和网络链接。

Cinder 架构

Cinder 比 Swift 简单得多，由于它不提供自动对象分布和复制。图 1 显示了 Cinder 架构。

图 1. Cinder architecture

 

与其余 OpenStack 项目相似，Cinder 的功能经过 API 暴露给仪表板和命令行。它可以经过具备具象状态传输 (Representational State Transfer, REST) 的 HTTP API 来访问对象存储，并使用一个名为  Auth Manager 的 Python 类将身份验证归入 OpenStack Keystone。

API 解析全部传入的请求并将它们转发给消息队列，调度程序和卷服务器在该队列中执行实际的工做。在建立新的卷时，调度程序将会决定哪台主机应对该卷负责。默认状况下，它会选择拥有最多可用空间的节点。

卷管理程序管理着可动态附加的块存储设备，这些设备也被称为卷。它们可用做虚拟实例的启动设备，或做为辅助存储进行添加。Cinder 还为快照（卷的只读副本）提供了一种设备。而后可使用这些快照来建立新的卷，以供读写使用。

卷一般经过 iSCSI 附加到计算节点。块存储也须要某种形式的后端存储，在默认状况下，该后端存储是本地卷组上的逻辑卷管理，但能够经过驱动程序将它扩展到外部存储阵列或设备。

设置

实际的安装指令在发行版和 OpenStack 版本之间极为不一样。一般，它们可做为发行版的一部分。可是，必须完成相同的基本任务。本节将会介绍其中涉及的概念。

系统要求

OpenStack 依赖于一种 64 位 x86 架构；另外，它是为商用硬件而设计的，因此具备极低的系统要求。它能够在配有包含 8GB RAM 的单个系统上运行整套 OpenStack 项目。可是，对于大型的工做负载，它对于使用专用系统来实现存储相当重要。由于咱们的重点在商用设备上，因此不须要独立磁盘冗余阵列 (redundant array of independent disks, RAID) 功能，但使用至少两个四核 CPU、8-12GB 的 RAM 和 1GB 的网络适配器是一种明智之举。显然，硬盘或固态磁盘的大小取决于要存储的数据量和但愿的冗余级别。

安装

安装指令取决于发行版，更具体地讲，取决于您所选择的包管理实用程序。在许多状况下，必须声明存储库。因此，举例而言，若是您使用的是 Zypper，那么您要用 zypper ar 向 libzypp 公开：

点击查看代码清单

而后，安装所需的 Swift 和/或 Cinder 包。包管理实用程序应自动安装全部依赖关系。整个安装程序取决于您所指望的配置和 OpenStack 的准确版本。请务必查看安装指南中的权威说明，为了演示之目的，下面提供了适用于 Debian（例如 Ubuntu）、Red Hat（例如，Red Hat Enterprise Linux®、CentOS、Fedora）和 openSUSE 的一些主要命令。

Debian ：在全部主机上安装基础 Swift 包：

1. sudo apt-get install python-swift
   
2. sudo apt-get install swift
   
3. and the server-specific packages on the hosts that will be running them:
   
4. sudo apt-get install swift-auth
   
5. sudo apt-get install swift-proxy
   
6. sudo apt-get install swift-account
   
7. sudo apt-get install swift-container
   
8. sudo apt-get install swift-object

复制代码

Cinder 包包含 API、调度程序和卷管理程序：

1. sudo apt-get install cinder-api
   
2. sudo apt-get install cinder-scheduler
   
3. sudo apt-get install cinder-volume

复制代码

Red Hat ：在 Red Hat 系统上，使用的命令是：

1. sudo yum install openstack-swift
   
2. sudo yum install openstack-swift-proxy
   
3. sudo yum install openstack-swift-account
   
4. sudo yum install openstack-swift-container
   
5. sudo yum install openstack-swift-object
   
6. sudo yum install openstack-swift-doc
   
7. sudo yum install openstack-cinder
   
8. sudo yum install openstack-cinder-doc

复制代码

openSUSE ：使用如下命令：

1. sudo zypper install  openstack-swift
   
2. sudo zypper install  openstack-swift-auth 
   
3. sudo zypper install  openstack-swift-account 
   
4. sudo zypper install  openstack-swift-container 
   
5. sudo zypper install  openstack-swift-object 
   
6. sudo zypper install  openstack-swift-proxy
   
7. sudo zypper install openstack-cinder-api
   
8. sudo zypper install openstack-cinder-scheduler
   
9. sudo zypper install openstack-cinder-volume

复制代码

配置

配置 OpenStack Object Storage 安装涉及到为四个包的每个包量身定制配置文件：

• account-server.conf
• container-server.conf
• object-server.conf
• proxy-server.conf
  

配置文件安装在 /etc/swift/ 中。默认的一组选项在标准安装中运做良好，但在有特殊需求时，有必要编辑该配置。

使用场景

如欲了解如何使用 OpenStack 存储，能够想象这样一个场景：在该场景中，有一项服务使用一个文件系统和新代码运行了遗留软件，您想在该文件系统和新代码中使用分布式对象存储。适用于此项目的环境应该包括 Swift 和 Cinder。

首先来看一看 Cinder。

以具备 Member 角色的用户身份登陆到 OpenStack Dashboard。


在导航面板中的 Manage Computer 下，单击 Volumes > Create Volume。



图 2. 建立一个卷
 



卷应出如今项目的列表中。
图 3. 项目中的卷
 




编辑附件，以便将卷链接到其中一个计算实例。
图 4. 管理卷附件
 


OpenStack 建立一个唯一的 iSCSI 合格名称，并将其显示给目前具备活动 iSCSI 会话的计算节点。若是实例是逻辑存储（一般是一个 /dev/sdX 磁盘），那么可使用 Cinder 卷。

要想对您的项目使用 Swift，首先必须建立一个容器。

做为具备 Member 角色的用户身份登陆到 OpenStack Dashboard，在导航面板的 Object Store 下，单击 Containers > Create Container。 图 5. 建立容器
 

这是一个简单的操做，根本不会涉及提供任何数据。它只是一个名称而已。

当拥有容器以后，一般由应用程序使用对象填充它，并根据须要使用一个编程接口来检索这些对象。 图 6. 已填充的容器
 


不过，您还能够从仪表板上传对象。在 Object Store 下，单击 Containers > Upload Object 并提供一个包含存储内容的文件。 图 7. 上传对象

 

7.jpg (130.7 KB, 下载次数: 23)

下载附件  保存到相册

2014-11-17 10:50 上传

您还可使用界面来下载、复制或删除对象。

进一步补充：


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的架构和部署讨论，除了官方网站，网上也有不少文章，这里就不重复.(也能够参考我以前在OpenStack中国行活动中上海站演讲的PPT)。从开发上看，最近也没有太大的结构性调整，因此我想主要说说比较适用的应用领域好了。

从我所了解的实际案例来看，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主要包括下面几个部分：
1.API service： glance-api 主要是用来接受Nova的各类api调用请求，将请求放入RBMQ交由后台处理，。

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

3.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做为一个开放的系统，最主要是解决软硬件供应商锁定的问题，能够随时选择新的硬件供应商，将新的硬件和已有的硬件组成混合的集群，统一管理，固然也能够替换软件技术服务的提供商，不用动应用。这是开源自己的优点！

原文连接：http://www.aboutyun.com/thread-10060-1-1.html