【云计算】Openstack中的Swift资料整理及CAP原理简介

shisgmei

文章来源于互联网
1. 什么是Swift?
　　OpenStackObject Storage（Swift）是开源的，用来创建可扩展的、冗余的、对象存储（引擎）。Swift使用标准化的服务器存储PB级可用数据。但它并不是文件系统（file system），实时的数据存储系统（real-timedata storage system）。Swift看起来更像是一个长期的存储系统 （long term storage system），为了获得、调用、更新一些静态的永久性的数据。比如说，适合存储一些这样类型的数据：虚拟机镜像，图片存储，邮件存储，文档的备份。没有“单点”或者主控结点（master point of control），Swift看起来具有更强的扩展性、冗余和持久性。
　　OpenStack Object Storage 最开始是由Rackspace开发，并于2010年7月贡献给OpenStack，作为其开源子项目。OpenStack Object Storage 最初作为 RackspaceCloud Files service 的主体实现，工程代号为Swift。
2. Swift适合用来存什么
　　l IaaS 存储平台（例如可与OpenStack Compute集成来存储服务器镜像）
　　l 图片、文档存储
　　l 网络平台后端
　　l 长期保存的日志文件
　　总结：Swift适合用来存储大量的、长期的、需要备份的对象。
3. Swift怎么用
　　Swift使用“用户/容器/对象名”（account/container/object）来唯一确定一个对象。Account就是Swift中的用户，每个用户下面会有任意数量的容器（类似于文件夹），每个容器下可以有任意数量的对象（类似于文件）。
　　Swift使用REST API来访问。例如我们可以通过HTTP GET请求来下载对象，通过HTTP HEAD请求来获取对象的元数据，通过HTTP DELETE请求来删除一个对象等等。
4. Swift的架构
4.1. Swift特性
　　l 大量对象的存储（Storage of large number of objects）
　　l 大对象的存储（Storage of large sized objects）
　　l 数据冗余（Data Redundancy）
　　l 档案能力——存储大数据集（Archival capabilities - Work with large datasets）
　　l 虚拟机和云应用的数据容器（Data container for virtial machines and cloud apps）
　　l 流媒体的能力（Media Streaming capabilities）
　　l 对象存储安全（Secure storage of objects）
　　l 备份和档案（Backup and archival）
　　l 极高的扩展性（Extreme scalability）
4.2. Swift的组件
4.2.1. 环（The Ring）
　　环负责管理存储在磁盘上的一个实体的名字和这个实体所在物理位置之间的映射关系。对accounts、containers和objects 都有独立的ring server与之对应，但他们的工作方式是一样的。当其它组件对object、container或account有任何操作时，都要和适当的ring server交互来确定他们在集群中的位置。
　　环通过区域，设备，分区，复制份数来维护映射。在环中每一个分区都会被复制（在集群中默认的是三份）。
　　集群中，分区可以用权重来平衡它们的分布，例如当不同大小的设备被使用时。
　　在出错的情况下，环也负责确定哪一个设备来接手服务。
　　环被代理服务器和一些后台进程所使用（例如复制进程）。
4.2.2. 代理服务器（Proxy Server）
　　代理服务器，负责把Swift的其它部分连接起来。对于每一个请求，代理服务器将在环（ring）中查找account、container或者object，相应地将请求路由到对应的服务器上。
　　同时Proxy Server也对外提供公共API，也就是外界通过Proxy Server来访问Swift服务。
　　
4.2.3. 对象服务器（Object Server）
　　对象服务器是一个简单的用于存储、检索、删除存储在本地设备上的objects的二进制存储服务器（blob storage server）。Objects以二进制文件的形式，连带着存储在扩展属性（xattrs）中的元数据，被存储在文件系统中，这需要存储objects的基础文件系统支持文件的xattrs。像ext3的一些文件系统，默认是关闭xattrs的。
4.2.4. 容器服务器（Container Server）
　　容器服务器的主要职责是处理objects的列表。它不知道这些objects被存储在何处，只知道哪些objcts是归属于某一指定的容器中。
　　objects列表以sqlite数据库文件的形式存储，并且像objects那样在集群中被备份。包含obejcts总数量和容器已用容量的信息也将被追踪统计。
4.2.5. 账户服务器（Account Server）
　　Account Server与Container Server非常类似，唯一不同的在于，account server是用来列举containers清单的，而非objects清单。
4.2.6. 复制器（Replication）
　　复制器被设计用来当系统面临临时性错误（比如断网或设备错误）时，保护系统的一致性。
　　复制进程通过将本地数据与每一个远程备份进行比较，来确保它们都是最新版本的数据。
　　Object复制器使用一个哈希列表来迅速地比较每一个分区的子部分，同时container和account复制器使用哈希表和共享高峰标记。
　　复制操作的更新是基于PUSH的方式。比如object的复制操作，更新就是一个往其他节点同步文件的过程。Account和container的复制操作通过HTTP来PUSH丢失的记录,或着远程同步全部的数据库文件。
复制器同时也确保数据从系统的删除。当一个条目(object, container, account)被删除，一个“墓碑”将作为此目标的最新版本被设置。复制器将见到此“墓碑”，并将确保此目标被从所有的系统中删除。
4.2.7. 更新器（Updaters）
　　有的时候，容器或账户数据不能被立即更新，这通常发生在出现错误或者系统过载时。
　　当一个更新失败时，更新操作就会在本地文件系统上排队，然后更新器会处理这些失败的更新。这时最终一致性的窗口会适时地出现。
　　比如，假设当一个容器服务器处于低负载中并且一个新的对象被放到系统中时，一旦代理服务器向客户端回复成功消息，此对象就将立即可读。然而，容器服务器不会立即更新对象的列表，并且因此更新将被排队以等待稍候的更新。此刻容器列举的清单，可能不回立马包含此对象。
　　在实践中，一致性窗口的大小仅仅与更新器运行的频率一致，并且代理服务器不会将list请求转递给最初对请求进行回复的那个Container Server。低负载的服务器可能不会接手接下来的list请求——其他的两个备份中的一个会处理此list请求。
4.2.8. 审计器（Auditors）
　　审计器通过爬行本地服务器来检查对象，容器和账户的完整性。
　　当一个文件被发现有损坏（比如一点损坏），它将被隔离，并且复制器将同其他的副本复制一份来代替此损坏的文件。
　　如果有别的错误发生，它们将被记录日志（比如列举一个对象时，在所有的它应该位于的容器服务器中都无法找到）。
4.3. Swift典型部署结构
　　
　　
5. Swift对CAP的支持程度
5.1. 什么是CAP
　　CAP理论是由美国著名科学家，Berkerly大学Brewer教授提出的。后来麻省理工学院的两位科学家证明了CAP理论的正确性。虽然在后来近十年的时间很多人对CAP理论提出了很多异议，但是在NoSQL的世界中，它还是非常有参考价值的。CAP理论：
　　分布式系统中，有三种重要的属性，分别是：
　　l 一致性(Consistency)：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。
　　l 可用性(Availability)：每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。
　　l 分区可容忍性(Tolerance of network Partition)：在出现网络分区（比如断网）的情况下，分离的系统也能正常运行。
　　CAP理论的意思是，一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。
　　
　　工程实践对网络分区考虑较少，一般可以认为：一致性和写操作的可用性不能同时满足，即如果要保证强一致性，那么出现机器故障的时候，写操作需要等机器重启或者机器上的服务迁移到别的机器才可以继续。
　　分布式系统的一致性和采用的一致性模型有关。一致性简单的可以分为强一致性、弱一致性、最终一致性；而一致性的变体大体有Causal consistency, Read-your-writes consistency, Session consistency, Monotonic read consistency, Monotonic write consistency等。这里不做赘述，只对部分做简单举例。
　　l 强一致性：支付业务上多采用；
　　l 弱一致性和最终一致性：需要等待一个“一致性窗口”的时间之后才能读取到最新值；
　　l session一致性：用户发表的微博，评论数据，用户可以马上看到，但是其他用户要等一段时间。
　　一致性模型多和业务逻辑有很大关联，不同的业务对CAP的取舍也不尽相同，这里不赘述。
5.2. Swift对CAP的支持
　　下图对部分SQL和NoSQL系统按照CAP做了一个归类。可以和Swift做一个参照。
　　

　　
　　通过比较，可以认为，Swift为AP系统。
　　Consistency：
　　l Swift的一致性归为弱一致性模型。Swift由updater保证最终一致性，auditor保证存储对象的完整性。
　　l Swift只能保证数据的最终一致性，即，如果upload(update也是一种upload)一个object,从其他客户端GET这个object，不一定是最新的。当然，大部分情况(指网络不拥塞，没有单点故障时)，这种情况不会发生。因此，工程实践中，如果业务需要，我们可能需要加入自己的一致性策略，比如在object的metadata中记录版本信息，系统统一管理object的版本变更——但这会损失一些性能。
　　Availability：
　　l 基于python对hash的 原生支持，swift中广泛使用了hash算法。比如均衡ring中partition的分布，object  update备份策略。异步的replication操作。
　　l sqlite控制account/container/object的相关信息，简化了维护成本
　　l memcache缓存的机制。
　　Tolerance of network Partition：并没有网络分区。
　　l 牵强的说，Swift提供zone的概念，建议根据不同的故障原因分zone，以规避故障引起的风险。
　　l 每个storage node各自维护自己的account/container/object信息，而不是单点统一管理。
　　l 一致性hash使ring中的partition均匀分布，其实partition是分区域的，当然，这是从代码的角度看。
　　l 副本的冗余存储。
6. 参考资料
　　Openstack Swift云存储项目架构概览翻译：http://blog.iyunv.com/xjtuse_mal/article/details/6674164
　　Swift架构概述：http://swift.openstack.org/overview_architecture.html
　　nosql关于CAP取舍的一个分类：http://blog.nahurst.com/visual-guide-to-nosql-systems