第一部分CEPH1.1 特点Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。

1.2 组成CEPH文件系统有三个主要模块：a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。

b)OSD簇：用于存储所有的数据和元数据。

c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和目录名）1.3 架构原理Client：用户I/O：输入/输出MDS：Metadata Cluster Server 元数据簇服务器OSD：Object Storage Device 对象存储设备Client通过与OSD的直接通讯实现I/O操作。

这一过程有两种操作方式：1. 直接通过Client实例连接到Client；2. 通过一个文件系统连接到Client。

当一个进行打开一个文件时，Client向MDS簇发送一个请求。

MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。

注意文件节点号与文件意义对应。

如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。

MDS同时赋予Client操作权（如果该Client还没有的话）。

目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。

在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client 都允许）。

之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。

CEPH产生一组条目来进行文件数据到一系列对象的映射。

为了避免任何为文件分配元数据的需要。

对象名简单的把文件节点需要与条目号对应起来。

对象复制品通过CRUSH（著名的映射函数）分配给OSD。

例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。

通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。

任何不存在的对象或字节序列被定义为文件洞或0。

同样的，如果Client打开文件进行写操作。

它获得使用缓冲写的能力。

任何位置上的数据都被写到合适的OSD上的合适的对象中。

Client 关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。

它重新定义了那些存在的并包含文件数据的对象的集合。

CEPH的设计思想有一些创新点主要有以下两个方面：第一，数据的定位是通过CRUSH算法来实现的。

传统的，或者通常的并行文件系统，数据的定位的信息是保存在文件的metadata 中的，也就是inode结构中，通过到metadata server上去获取数据分布的信息。

而在Ceph中，是通过CRUSH 这个算法来提供数据定位的。

第二，元数据服务器可以提供集群metadata server 服务。

只要当我们了解了其结构后，感觉并没有太大的特点。

元数据服务器一般就用来存储文件和目录的信息，提供统一的命名服务。

在Ceph中，元数据的inode ， dentry，以及日志都是在对象存储集群RADOS中存储，这就使得metadata的持久化都是在远程的RADOS中完成，metadata server 不保存状态，只是缓存最近的inode 和 dentry项，当metadata server 失效后，其所所有信息都可以从RADOS中获取，可以比较容易恢复。

CEPH最核心的，就是RADOS就是RADOS（resilient automatic distributed object storage). 其resilient 指的是可以轻松扩展，automatic 指的是其对象存储集群可以处理failover， failure recovery。

RADOS 对象集群其对外提供了一个高可用的，可扩展的，对象集群，从客户端的角度看，就是一个统一命名空间的对象存储。

1.4 使用方式(一)Ceph 的Monitor用来监控集群中所有节点的状态信息，完成类似配置服务的功能。

在Ceph 里，配置主要就是cluster map ，其保存集群所有节点信息，并和所有的节点保持心跳，来监控所有的节点状态。

其通过Paxos算法实现实现自身的高可用，也就是说，这个Ceph Monitor 是不会有单点问题的。

目前流行的zookeeper 的功能，以及实现都类似。

(二)对象存储Ceph文件系统中的数据和元数据都保存在对象中。

对于对象存储，通常的定义是：一个Object，由三部分组成（id，metadata，data），id是对象的标识，这个不必多说。

所谓的metadata，就是key/value的键值存储，至于用来保存什么信息，由文件系统的语义定义。

data就是实际存储的数据。

Ceph的对象，包括四个部分（id，metadata，attribute，data），在Ceph里，一个Object，实际就对应本地文件系统的一个文件，一个对象的attribute，也是key/value的键值对，其保存在本地文件系统的文件的扩展属性中。

对象的metadata就是key/value的键值对，目前Ceph保存在google开源的一个key/value存储系统leveldb中，或者自己写的一个key/value 存储系统中。

数据就保存在对象的文件中。

对于一个对象的更新，都需要写日志中来保持一个Object数据的一致性（consistence），日志有一个单独的设备或者文件来保存。

(三)副本存储一个PG（placement group）由一个OSD列表组成，OSD的个数，就是对象的副本数，一个三副本的PG就是一个主，两个副本的OSD列表组成。

一个PG和OSD列表的映射关系，是通过CRUSH算法计算的，知道PG的id，和当前的cluster map，就可以通过CRUSH算法，计算出OSD列表。

特别强调的是，一个PG是逻辑层概念，也就是说，一个OSD，可能同时是一个或者多个PG的主，同时是另一个PG的从。

一个OSD处于多个PG组中。

一个PG就是复制和修复的基本单位。

每个OSD本地保存其所在的PG列表就可以了，其它OSD可以通过输入当前的该OSD保存的cluster map 和 PG 的id ，通过CRUSH计算得出。

(四)Ceph的容错处理对于Ceph文件系统，错误分两类：一类是磁盘错误或者数据损坏（ disk error or corruptted data），这类错误OSD会自己报告和处理。

（self report ）；第二类是OSD失去网络连接导致该OSD不可达（unreachable on the network）这种情况下需要主动检测（active monitor），在同一个PG组中的其它OSD会发心跳信息互相检测。

这种检测的一个优化的方法就是，当replication复制操作时，就可以顺带检测，不用发单独的消息来检测，只有一段时间没有replication 操作时，才发ping消息里检测。

OSD的失效状态有两种：一种是down状态，这种状态下，被认为是临时错误。

在这种情况下，如果是primay，其任务由下一个replicate接手。

如果该OSD没有迅速恢复（quickly recovery），那么就被标记为out状态，在这种状态下，将有新的osd加入这个PG中。

如何标记一个OSD 从down状态标记为out状态？由于网络分区的问题，需要通过 Ceph Monitor 来裁定。

(五)Ceph 的写流程客户端先写主副本，然后同步到两个从副本。

主副本等待从副本的ack消息和apply消息。

当主副本收到ack消息，说明写操作已经写在内存中完成，收到apply 消息，说明已经apply到磁盘上了。

如果在写的过程中，主副本失效，按顺序下一个从副本接管主副本的工作，这个时候是否返回给客户端写正确？在这种情况下，客户端只是判断正常工作的（acting）的 OSD的返回结果，只要所有正常工作的OSD返回即认为成功，虽然这时候可能只有两副本成功。

同时该临时primay必须保存所有操作的recovey队列里，如果原primay恢复，可以replay所有recovery队列里的操作，如果主副本从down到out状态，也即是永久失效，临时primay转正，由临时primay为正式primay，只是需要加入一个新的OSD到该PG中。

如果是从副本失效，就比较简单。

临时失效，主replay所有写操作，如过永久失效，新加入一个OSD到PG中就可以了。

(六)恢复当有OSD失效，恢复或者增加一个新的OSD时，导致OSD cluster map的变换。

Ceph处理以上三种情况的策略是一致的。

为了恢复，ceph保存了两类数据，一个是每个OSD的一个version，另一个是PG修改的log，这个log包括PG修改的object 的名称和version。

当一个OSD接收到cluster map的更新时：1）检查该OSD的所属的PG，对每个PG，通过CRUSH算法，计算出主副本的三个OSD2）如何该PG里的OSD发生了改变，这时候，所有的replicate向主副本发送log，也就是每个对象最后的version，当primay 决定了最后各个对象的正确的状态，并同步到所有副本上。

3）每个OSD独立的决定，是从其它副本中恢复丢失或者过时的（missingor outdated）对象。

(如何恢复? 好像是整个对象全部拷贝，或者基于整个对象拷贝，但是用了一些类似于rsync的算法？目前还不清楚）4）当OSD在恢复过程中，delay所有的请求，直到恢复成功。

第二部分GlusterFSGlusterFS是Scale-Out存储解决方案Gluster的核心，它是一个开源的分布式文件系统，具有强大的横向扩展能力，通过扩展能够支持数PB存储容量和处理数千客户端。

GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。

GlusterFS基于可堆叠的用户空间设计，可为各种不同的数据负载提供优异的性能。

GlusterFS支持运行在任何标准IP网络上标准应用程序的标准客户端，用户可以在全局统一的命名空间中使用NFS/CIFS等标准协议来访问应用数据。