OpenStack 存储技术Word文件下载.docx
《OpenStack 存储技术Word文件下载.docx》由会员分享，可在线阅读，更多相关《OpenStack 存储技术Word文件下载.docx（13页珍藏版）》请在冰豆网上搜索。
对象存储
AmazonS3
Glance
Imageasaservice
VM磁盘镜像存储和管理
AmazonAMIcatalog
Cinder
BlockStorageasaservice
块存储
AmazonEBS
回页首
OpenStack对象存储—Swift
OpenStackObjectStorage（Swift）是OpenStack开源云计算项目的子项目之一,被称为对象存储，提供了强大的扩展性、冗余和持久性。
Swift并不是文件系统或者实时的数据存储系统，它称为对象存储，用于永久类型的静态数据的长期存储，这些数据可以检索、调整，必要时进行更新。
Swift前身是RackspaceCloudFiles项目，随着Rackspace加入到OpenStack社区，于2010年7月贡献给OpenStack，作为该开源项目的一部分。
Swift目前的最新版本是OpenStackHavana。
Havana版本中Swift新增特性如下：
∙Multiple-Region-Replication：
支持对象异地复制容灾。
∙Memcache：
增加对轮询Memcache连接的支持。
∙More-Optimization：
并发IO支持，多网段分流支持，在多地复制情况下加强不同Proxy-Server的亲和度。
Swift特性
在OpenStack官网中，列举了很多Swift特性，其中最引人关注的是以下几点。
极高的数据持久性
一些朋友经常将数据持久性（Durability）与系统可用性（Availability）两个概念混淆，前者也理解为数据的可靠性，是指数据存储到系统中后，到某一天数据丢失的可能性。
例如AmazonS3的数据持久性是11个9，即如果存储1万（4个0）个文件到S3中，1千万（7个0）年之后，可能会丢失其中1个文件。
那么Swift能提供多少个9的SLA呢？
下文会给出答案。
针对Swift在新浪测试环境中的部署，他们从理论上测算过，Swift在5个Zone、5×
10个存储节点的环境下，数据复制份是为3，数据持久性的SLA能达到10个9。
完全对称的系统架构
“对称”意味着Swift中各节点可以完全对等，能极大地降低系统维护成本。
无限的可扩展性
这里的扩展性分两方面，一是数据存储容量无限可扩展；
二是Swift性能（如QPS、吞吐量等）可线性提升。
因为Swift是完全对称的架构，扩容只需简单地新增机器，系统会自动完成数据迁移等工作，使各存储节点重新达到平衡状态。
无单点故障
在互联网业务大规模应用的场景中，存储的单点一直是个难题。
例如数据库，一般的HA方法只能做主从，并且“主”一般只有一个；
还有一些其他开源存储系统的实现中，元数据信息的存储一直以来是个头痛的地方，一般只能单点存储，而这个单点很容易成为瓶颈，并且一旦这个点出现差异，往往能影响到整个集群，典型的如HDFS。
而Swift的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。
整个Swift集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。
简单、可依赖
简单体现在架构优美、代码整洁、实现易懂，没有用到一些高深的分布式存储理论，而是很简单的原则。
可依赖是指Swift经测试、分析之后，可以放心大胆地将Swift用于最核心的存储业务上，而不用担心Swift捅篓子，因为不管出现任何问题，都能通过日志、阅读代码迅速解决。
Swift架构概述
SwiftArchitectural主要有三个组成部分：
ProxyServer、StorageServer和ConsistencyServer。
其架构如图1所示，其中Storage和Consistency服务均允许在StorageNode上。
Auth认证服务目前已从Swift中剥离出来，使用OpenStack的认证服务Keystone，目的在于实现统一OpenStack各个项目间的认证管理。
图1.Swift架构
主要组件
ProxyServer
ProxyServer是提供SwiftAPI的服务器进程，负责Swift其余组件间的相互通信。
对于每个客户端的请求，它将在Ring中查询Account、Container或Object的位置，并且相应地转发请求。
Proxy提供了RESTAPI，并且符合标准的HTTP协议规范，这使得开发者可以快捷构建定制的Client与Swift交互。
StorageServer
StorageServer提供了磁盘设备上的存储服务。
在Swift中有三类存储服务器：
Account、Container和Object。
其中Container服务器负责处理Object的列表，Container服务器并不知道对象存放位置，只知道指定Container里存的哪些Object。
这些Object信息以sqlite数据库文件的形式存储。
Container服务器也做一些跟踪统计，例如Object的总数、Container的使用情况。
ConsistencyServer
在磁盘上存储数据并向外提供RESTAPI并不是难以解决的问题，最主要的问题在于故障处理。
Swift的ConsistencyServers的目的是查找并解决由数据损坏和硬件故障引起的错误。
主要存在三个Server：
Auditor、Updater和Replicator。
Auditor在每个Swift服务器的后台持续地扫描磁盘来检测对象、Container和账号的完整性。
如果发现数据损坏，Auditor就会将该文件移动到隔离区域，然后由Replicator负责用一个完好的拷贝来替代该数据。
图2给出了隔离对象的处理流图。
在系统高负荷或者发生故障的情况下，Container或账号中的数据不会被立即更新。
如果更新失败，该次更新在本地文件系统上会被加入队列，然后Updaters会继续处理这些失败了的更新工作，其中由AccountUpdater和ContainerUpdater分别负责Account和Object列表的更新。
Replicator的功能是处理数据的存放位置是否正确并且保持数据的合理拷贝数，它的设计目的是Swift服务器在面临如网络中断或者驱动器故障等临时性故障情况时可以保持系统的一致性。
图2.隔离对象的处理流
Ring
Ring是Swift最重要的组件，用于记录存储对象与物理位置间的映射关系。
在涉及查询Account、Container、Object信息时，就需要查询集群的Ring信息。
Ring使用Zone、Device、Partition和Replica来维护这些映射信息。
Ring中每个Partition在集群中都（默认）有3个Replica。
每个Partition的位置由Ring来维护，并存储在映射中。
Ring文件在系统初始化时创建，之后每次增减存储节点时，需要重新平衡一下Ring文件中的项目，以保证增减节点时，系统因此而发生迁移的文件数量最少。
应用场景
Swift提供的服务与AmazonS3相同，适用于许多应用场景。
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的结合，窃以为是值得关注的方向。
OpenStack镜像存储—Glance
Glance项目提供虚拟机镜像的发现、注册、取得服务。
Glance提供RESTAPI可以查询虚拟机镜像的metadata，并且可以获得镜像。
通过Glance，虚拟机镜像可以被存储到多种存储上，比如简单的文件存储或者对象存储（比如OpenStack中swift项目），Havana版本中Glance新增特性如下：
∙Multiple-Image-Location：
支持镜像存储到多种不同类型的存储池。
∙More-Drivers：
加入了Sheepdog支持，并且Cinder也可以作为后端存储驱动之一。
Glance的几个重要概念：
1.Imageidentifiers：
Image使用URI作为唯一标识，URL符合以下格式：
<
GlanceServerLocation>
/images/<
ID>
GlanceServerLocation是镜像的所在位置，ID是镜像在Glance的唯一标识。
2.ImageStatuses共四种状态。
queued标识该镜像ID已经被保留，但是镜像还未上传。
saving标识镜像正在被上传。
active标识镜像在Glance中完全可用。
killed标识镜像上传过程中出错，镜像完全不可用。
3.DiskandContainerformat
DiskFormat：
rawvhdvmdkvdiisoqcow2akiariami
ContainerFormat:
ovfbareakiariami
当diskformat为akiariami时，diskformat和containerformat一致。
4.ImageRegistries
使用Glance，镜像metadata可以注册至imageregistries。
只要为imagemetadata提供了restlikeAPI，任何web程序可以作为imageregistries与Glance对接。
当然，Glance也提供了参考实现。
更多信息可以参考onControllingServers，来自于Glance提供的Glanceregistryserver。
Glance的架构：
图3.Glance的架构
Glance被设计为可以使用多种后端存储。
前端通过APIServer向多个Client提供服务。
Glance目前提供的参考实现中RegistryServer仅是使用Sql数据库存储metadata，Glance支持S3、Swift，简单的文件存储及只读的HTTPS存储。
也支持其他后端，如分布式存储系统（SheepDog或Ceph）。
OpenStack块存储—Cinder
OpenStack到Folsom版本有比较大的改变，其中之一就是将之前在Nova中的部分持久性块存储功能（Nova-Volume）分离了出来，独立为新的组件Cinder。
主要核心是对卷的管理，允许对卷、卷的类型、卷的快照进行处理。
它并没有实现对块设备的管理和实际服务，而是为后端不同的存储结构提供了统一的接口，不同的块设备服务厂商在Cinder中实现其驱动支持以与OpenStack进行整合。
在CinderSupportMatrix中可以看到众多存储厂商如NetAPP、IBM、SolidFire、EMC和众多开源块存储系统对Cinder的支持。
Havana版本中Cinder新增特性如下：
∙Volume-Resize：
在可用情况下调整卷大小。
∙Volume-Backup-To-Ceph：
现在卷可以备份到Ceph集群中。
∙Volume-Migration：
现在不同用户间可以透明地转移和交换卷。
∙QoS：
增加限速相关的元信息供Nova和其Hypervisor使用。
更多的存储厂商加入和完善了自己的Cinder驱动，如Huawei、Vmware、Zadara。
Cinder架构图
图4.Cinder的架构
点击查看大图
关闭[x]
Cinder服务
APIservice：
负责接受和处理Rest请求，并将请求放入RabbitMQ队列。
Schedulerservice:
处理任务队列的任务，并根据预定策略选择合适的VolumeService节点来执行任务。
目前版本的cinder仅仅提供了一个SimpleScheduler,该调度器选择卷数量最少的一个活跃节点来创建卷。
Volumeservice:
该服务运行在存储节点上，管理存储空间。
每个存储节点都有一个VolumeService，若干个这样的存储节点联合起来可以构成一个存储资源池。
为了支持不同类型和型号的存储，当前版本的Cinder为VolumeService添加如下drivers。
当然在Cinder的blueprints当中还有一些其它的drivers，以后的版本可能会添加进来。
本地存储：
LVM（iSCSI）,Sheepdog（sheepdog）
▫网络存储：
NFS,RBD（Ceph）
IBM:
Storwizefamily/SVC（iSCSI/FC），XIV（iSCSI），GPFS，zVM
▫Netapp:
NetApp（iSCSI/NFS）
▫EMC:
VMAX/VNX（iSCSI），Isilon（iSCSI）
▫Solidfire:
Solidfirecluster（iSCSI）
▫HP:
3PAR（iSCSI/FC）,LeftHand（iSCSI）
Cinder如何支持典型存储
从目前的实现来看，Cinder对本地存储和NAS的支持比较不错，可以提供完整的CinderAPIV2支持，而对于其它类型的存储设备，Cinder的支持会或多或少的受到限制，下面是Rackspace对于PrivateCloud存储给出的典型配置：
1.本地存储
对于本地存储，cinder-volume可以使用LVM驱动，该驱动当前的实现需要在主机上事先用LVM命令创建一个cinder-volumes的卷组,当该主机接受到创建卷请求的时候，cinder-volume在该卷组上创建一个逻辑卷,并且用openiscsi将这个卷当作一个iscsitgt给输出.当然还可以将若干主机的本地存储用sheepdog虚拟成一个共享存储，然后使用sheepdog驱动。
2.EMC
图5.EMC块存储架构
3.Netapp
图6.Netapp块存储架构
HuaWei
图7.HuaWei块存储架构
传统存储与OpenStack云存储对比
表2.对比
传统存储架构
openstack云存储架构
海量数据承载能力
扩展方式是通过增加硬件配置实现，属于Scaleup方式
存储系统可以达到PB级别的扩展空间更适合海量数据的存储、ScaleOut
高可用
昂贵的硬件保证系统的高可用
通过系统自身的机制，即软件完成的自动化、智能机制来保证系统可用性
存储资源动态调配的能力
存储资源分配给应用后，难以回收再分配
计算和存储资源虚拟化，可以按照需求分配，动态调整
低资源利用率，高能耗
35%-75%的TCO节省，30%以上的软硬件成本节省，CPU利用率提升到60%-80%，70%-80%运营成本节约
运维效率和成本
运维效率低，维护成本高，硬件准备周期长
部署时间缩短到分钟级，减少硬件准备周期
管理复杂度
高
低
结束语
OpenStack是设计用来管理共有云和私有云的。
很多公司认为OpenStack有希望让他们能拥有一些单一专有云的功能，一些如谷歌、亚马逊及微软经营的云那样的功能。
同时OpenStack是基于友好的Apache2开源协议，任何人都能参与设计和开发，甚至提出创立自己的项目。
只要经过社区讨论，并达成一致，就可以按照您的标准。
开源的力量是强大的，随着社区半年一次的发布，Swift﹑Glance和Cinder将会越来越好。
本文只是OpenStack存储初级性的一次调查报告，进一步深入探索可以查看参考资料了解有关OpenStack存储的更多相关信息。
参考资料
学习
∙参考OpenStack存储,您可以获得OpenStack官方网站对于存储的概要介绍。
∙参考Swift文档，您可以获得Swift的官方文档开发信息。
∙参考CinderWiki，您可以获得Cinder的官方介绍。
∙参考GlanceWiki,您可以获得Glance的官方介绍。
∙参考Swift中文文档，您可以查看Swift的中文文档信息。
∙参考从OpenStack的角度看块存储的世界，您可以查看块存储的一些基本概念信息。
∙developerWorks云计算站点提供了有关云计算的更新资源，包括
o云计算简介。
o更新的技术文章和教程，以及网络广播，让您的开发变得轻松，专家研讨会和录制会议帮助您成为高效的云开发人员。
o连接转为云计算设计的IBM产品下载和信息。
o关于社区最新话题的活动聚合。
讨论
∙加入developerWorks中文社区。
查看开发人员推动的博客、论坛、组和维基，并与其他developerWorks用户交流。
升级会员 