OpenStack之Swift学习

Swift是OpenStack云存储服务的重要组件，它提供了高可用、分布式、持久性、大文件的对象存储服务。此外Swift还能够利用一系列的便宜硬件存储设备，提供安全、可靠的存储服务。

问：为何使用Swift？它有什么优势？

1：数据的持久性

数据的持久性是衡量存储系统的重要指标。持久性就是指用户的数据存储到系统中后丢失的可能性。为了防止数据的丢失，提升数据的持久性，Swift采用冗余Replica(副本)的处理方法，Replica的默认值为3.

2：架构对称性

对称性是指Swift架构设计上，每一个服务器节点的功能和做用是相等的，而不是采用HDFS(hadoop distributed file system)主从架构。由于采用主从架构，每每会由于master的压力过大，增长维护的困难，一旦master节点挂掉，便会致使服务的不可靠性。而对称性的便利就是系统维护简单，且不会由于某个节点挂掉，对服务形成影响

3：无单节点故障

Swift采用对称性设计，因此每一个节点的地位彻底相等，因此没有一个节点是单点的。即系统的性能不会由于某个节点的实效而形成整个系统不可用。此外Swift对元数据（数据的描述信息，如全部者，权限，类型等）的处理与对象文件的存储方式相同，即都是采用彻底多份均匀随机分布存储。

4:可扩展性

当王Swift中新加入一个节点时，会带来

1. 存储容量增长    

2. 系统性能上升

由于是对称架构，因此系统的扩展也相对简单。但新加入的节点，其并未存储数据，而为了保证新节点与旧节点的地位平等，就必然要将Swift上已经存储的数据迁移到新的节点上。

因此面临的问题之一就是，随着存储数据量的增大，会面临大量的数据迁移，从而增长了迁移的难度和消耗的时间。而这也是制约swift系统推广的缘由之一

5：简单可靠

Swift采用的原理比较简单。其架构设计、代码和算法都比较易懂、且还提供了较高的可靠性、且维护也比较容易

Swift的架构

Swift中的服务器主要有如下3种

1. 认证节点，即提供身份的验证

   若是只单独使用Swift的话，其验证服务能够直接使用Swift内置的认证服务，并将此内置的认证服务放在认证节点上；而若是将Swift放在OpenStack中的话，那么Swift就会才用keystone提供的认证服务，而此时认证节点就不属于Swift了

   

   2.代理节点，转发客户端的请求给Swift + 提供Swift API服务进程

       Proxy server提供了Rest-full API，这让开发者能够基于Swift API构建本身的应用程序

   3.存储节点，将磁盘存储服务转换为Swift中的存储服务，因为存储目标的不一样，存储节点上运行的             存储服务也分为如下三种：

 Object Server：对象服务（即指用户要存储的数据）提供了二进制大对象存储服务，对象数据是直接利用文件系统的存储功能，可是对象的元数据是存放在文件系统的扩展属性中的，所以Object Server 须要底层文件系统提供扩展属性

Container Server：容器服务（容器之存储组件，能够将容器理解为文件夹，可是容器不能 像文件夹那样进行嵌套）主要处理对象列表。但从容器到对象是单一映射关系，即容器服务不知道对象存放在哪一个容器上，但却知道容器上存放了那些对象。这部分信息以文件的形式存放，采用彻底均匀随机多份存储（与对象数据的存储方式同样）惟一不一样的是采用的是SQlite格式进行存储（一种轻型关联式，嵌套式的数据库，占用资源很是少，在嵌入式中均有使用）  

     

Account Server：帐户服务主要是处理容器列表，除此以外帐户与容器服务并没有什么不一样

 一个简单的Swift部署实例就是将对象服务，容器服务，帐户服务都部署在存储节点上。若是采用这种方式部署且保证硬件的配置相同，则存储节点的地位是平等的。

Swift故障处理

Swift的真正难点在于，因为数据的损坏或者物理硬件故障形成了数据的不一致性！

存储系统通常采用彻底均匀随机多备份的方式避免丢失的数据，不过也所以带来了多个备份之间的数据可能不一致的问题。好比一个文件有3个备份，分别存放在A、B、C服务器上，可是因为A服务器忽然断电等意外状况，等重启以后A的数据确定一B和C的不一样

而Swift主要采用下面三个服务来保证在遇到故障时保证数据的一致性：

Auditor：审计服务，审计器会反复检测帐户、容器、对象的一致性。一旦发现某个文件的数据不完整，会马上将此文件隔离。而后Auditor会通知Replication×××，让其从其余一直的副本复制并替换此文件。若是出现其余错误，如全部的副本都挂了，则会将此错误信息记录入日志

Updater：更新器的主要做用是延迟更新。延迟的主要缘由是为了因对用户数据上传的过程当中出现故障或者异常。在正常的状况下，其更新顺序为：用户上传数据成功后，Object Server向Container Server发起通知，通知Container Server某个Container中新加入了一个Object。Container Server收到该通知，更新好Object列表后，会向Account Server发起通知。Container Server收到通知并更新Container 列表。而这是理想的更新顺序。

在实际应用中，因为网络断开、系统高负载、磁盘写入等待等各类缘由的干扰，都有可能致使更新的失败，而当某个更新失败以后，这次更新的操做会被加入到更新队列中，而后由Updater处理这些失败了的更新工做。

Replicator：×××负责用完整的副本替换掉损坏的数据。一般会每隔一段时间自动扫描一下本地文件的hash值，并将此hash值与远端的其余副本进行对比，若是不一样，则会作出相应的复制替换操做