OpenStack之Swift学习

Posted 2020-10-05

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值与远端的其他副本进行对比，如果不同，则会做出相应的复制替换操作

本文出自 “11097124” 博客，请务必保留此出处http://11107124.blog.51cto.com/11097124/1962076