Ceph简介

记录一点对 “Ceph: A Scalable, High-Performance Distributed File System” 的翻译和理解

才开始翻译，有不好的地方请见谅。

摘要

Ceph是一个分布式文件系统，它具有高效、可靠和可扩展的特性。它在不可靠的对象存储设备（OSD）上使用一种伪随机Hash算法（CRUSH）很好的分离了数据存储和元数据管理。它通过在每一个OSD都会运行一个半自治的“对象文件系统”（运行在本地文件系统之上的Ceph组件）来实现数据复制、失效检测和故障恢复。使用一个元数据集群提供高效的元数据管理，其能达到250000 ops/s。并在各种负载下都有很好的IO性能。

简介

系统设计师一直想提高文件系统的性能，因为这对大部分应用的整体性能有关键性的影响。传统的方案，想NFS[20]，提供了一个直观的模型：一台服务器通过导出其文件系统信息，让多个客户端可以将这个文件系统映射到本地命名空间中。尽管其应用很广泛，但是客户端/服务器模式的固有中心化管理体系对系统的扩展性有很大的影响。

较多的现代分布式文件系统采用了基于对象的存储架构，也就是说将传统的硬盘替换为了具有智能的对象存储设备(OSDs)，该设备会使用CPU、网络和本地Cache加上底层的硬盘或者RAID[4,7,8,32,35]。OSDs替换了传统的基于块分配磁盘的方案，让客户端读取或写入一段字节到一个个对象(Objects)中，打散底层硬盘块分配任务到一个个设备本身。客户端和一台元数据服务器(metadata server，MDS)交互来执行元数据操作(open, rename)，和OSDs交互来执行IO操作(read, write)，这样极大的提高了系统扩展性。

采用这种模型的系统由于几乎没有元数据服务器的扩展，所以一直遭遇系统扩展性限制的问题。继续依赖像块分配列表和inode表这样的传统文件系统原则，会限制系统的扩展性和性能，并且降低系统的可靠性。

Ceph，一个具有高性能和高可靠性的同时，提供前所未有的扩展性的分布式文件系统。它的架构是基于PB级分布式文件系统内部是动态的的假设：大的系统必定是逐步增长的，节点失效是常态，并且系统的负载也一直变化着。

Ceph使用通用的函数替代了块分配表来解耦数据和元数据操作。这使得Ceph可以使用OSDs提供的智能来打散复杂的数据操作(序列化更新，数据冗余，故障检测和恢复)。Ceph使用自适应的元数据集群架构来提供系统扩展性和元数据访问效率。我们将讨论在系统的目标和负载假设条件下系统架构设计的选择，分析这些选择对系统扩展性和性能的影响，以及设计一个可使用的原型系统的经验。

系统概述

Ceph文件系统有三个主要的组件：客户端(每一个客户端会暴露一个近POSIX文件系统的接口给进程)；OSDs集群(存储所有的数据和元数据)；MSDs集群(管理命名空间(namespace: 文件名和目录)，安全性(security)，一致性(consistency)和连续性(coherence)). Ceph是近POXIS接口，因为为了更好的满足应用需要和提高系统效率我们扩展了POXIS接口并选择性的对一些语义(semantics)采用了若一致性处理。

这个架构的主要目标是扩展性(大于几百PB)，效率和可靠性。多维度的考虑了扩展性，包括总体存储容量，系统吞吐量，每个客户端的效率，目录效率和文件效率。我们的目标负载可能是成千上万的客户端同时读取或者写入同一个文件，或者在同一个文件夹下创建文件。这种场景在超级计算集群中的科学计算场景很常见，但也越来越多的在通用目的下见到。更重要的是，我们发现分布式文件系统的负载是动态变化的，随着时间的改变，数据和元数据的访问会有很大的不同。Ceph通过三个巧妙的设计解决了在保证可扩展性的同时获得高的效率，可靠性和可用性：数据和元数据解耦，动态分布元数据，和可靠的自治分布式对象存储。

数据和元数据解耦——Ceph最大程度上的分离了元数据管理和数据存储。元数据操作(open, rename, 等)被元数据集群管理，而客户端直接访问OSDs进行IO操作(read, write)。基于对象的存储一直以来都承诺提高系统的可扩展性。Ceph不同于那些将一个长的块分配表替换为一个短的对象分配表的对象存储，它完全的去除了分配表的使用。Ceph将数据分配到一系列可以预知的对象中，然后使用CRUSH算法[29]，将对象映射到各个存储设备。这使得任何程序都可以计算出组成一个文件的对象所保存的位置，消除了对象列表的使用必要，简化了系统设计，降低了元数据服务器的负载。

动态分布的元数据管理——应为元数据操作占了一个文件系统负载的一半[22]，高效的元数据管理对系统整体性能至关重要。Ceph使用了树分割的元数据集群架构(Dynamic Subtree Partitioning)[30]，这种方式可以自适应的将文件目录树的管理分配到数百个MDSs。一个动态的目录树分区被一个MDS保存在本地，提高了更新效率和聚合效率。另外，元数据服务器的负载分布完全依赖与当前的访问模式，这允许Ceph在任何负载下高效的使用可用的MDS资源并且得到接近线性的扩展能力。

可靠的自治分布式对象存储——一个大的系统有几千个设备组成，这让他们天生就具有动态的特性：动态增长，新节点的加入，旧节点的退出，设备经常失效，大量的数据被创建、移动、删除。所有这些因素都需要数据的分布能自我适应以高效的使用现存的设备并且保证副本个数。Ceph将数据迁移、复制、错误检测、故障恢复的任务交给用于保存数据的OSDs集群，也就是说从更上一层看，OSDs集群提供一个单一的逻辑对象存储给客户端和元数据服务器集群。这样让Ceph能更高效的使用OSDs展现的智能得到一个可靠的、高可用的和能线性扩展的对象存储。

我们描述Ceph客户端的操作、元数据服务器的操作、分布式对象存储的操作和刚才介绍的三个特性对这些操作的作用，我们同时也描述我们的原型系统的进度。

客户端操作

我们通过对Ceph客户端的描述来介绍Ceph的总体操作，和它和应用程序之间的交互。Ceph客户端执行应用程序代码并提供文件系统接口给应用程序。在Ceph的原型系统中，Ceph客户端完全在用户空间(user space)执行，可以通过直接链接(linking)访问或者使用FUSE[25](用户空间文件系统接口)将文件系统挂载到本地。每个客户端管理自己的文件数据缓存能够提供链接访问方式使用，并且它独立于内核页(kernel page)或者缓冲缓存(buffer cache)。

文件IO和权限

当进程打开一个文件，客户端会发送一个请求到MDS集群。其中一台MDS通过文件系统的层级关系将文件名转换为文件inode节点(唯一的inode编号、文件所有者、模式(mode)、大小和其他文件的元数据信息)，如果文件存在并且可以被访问，则MDS返回inode编号、文件大小和用来将文件数据映射到不同对象(object)的分条(striping)策略。MDS还会返回给客户端该用户允许的操作权限信息。现阶段权限信息由4bit组成，分别表示可读、缓存读(cache reads)、可写、缓存写(buffer writes)。以后权限信息会扩展关于安全的键使客户端能向OSDs证明，它能访问其上的数据[13, 19]。接下来MDS要做的就是管理权限、保护文件一致性和实现合适的语义(semantics)。

Ceph有多种将文件数据映射到一系列对象的策略。为了避免文件分配元信息(file allocation metadata)的使用，对象名只是简单的由文件inode编号和条数组成(strip number)。然后使用一个全局映射函数CRUSH将对象和它的副本映射到OSDs。举例来说，如果一个或者多个客户端打开一个文件进行读操作，一个MDS赋予它们读和缓存读文件内容的权限。客户端通过inode编号，布局和文件大小可以找到所有的包含文件数据对象，并直接到OSD集群中读取数据。任何不存在的字节区间或者对象被定义为文件空洞或者零区(zeros)。同样的，如果一个客户端打开一个文件进行写，则它被赋予缓存写的权限，客户端写入的任何数据都将写到合适的OSD上的合适的对象上的合适的位置。客户端在关闭文件时放弃获取的权限，并向MDS提供新的文件大小信息（即写入操作的最后偏移量(offset)），这样就重新定义了这个文件的这组对象所包含的数据。

客户端同步

POSIX语义明确规定读取操作将读取任何已经写入的数据，写入操作是原子的（覆盖写(overlapping)和同时写操作会以特定的顺序依次执行）。当一个文件被多个客户端打开时（有客户端要求写操作），则MDS会收回以前给出的读缓存和写缓存能力，强制客户端对该文件的IO达到同步。也就是说，每个读写操作都会被阻塞，指导这次操作被OSD确认。这样将更新的序列化和同步的操作都交给了每个OSD。当一次写操作超过一个对象的边界时，客户端获取受影响对象的排他锁（被各自的OSD所赋予），并立即提交写操作和解锁操作，以获得理想的序列化。通过异步的获取锁和提交数据，对象锁被用来缓解大文件写操作的延迟。

毫无疑问，同步IO会影响应用程序的性能，特别是小数据量的读写时更为突出（最少和OSD的一次通信延迟）。尽管共享读写在普通应用中较少，但是对效率要求高的科学计算中却很常见。因此经常需要弱一致性来提高效率，尽管CEPH可以通过全局转换支持弱一致性，并且其他很多分布式文件系统就是弱一致的[20]，但是效率和全局的一致性不能兼得。

正是处于这个原因，高性能计算协会（HPC）提出了一组高性能的POSIX/IO扩展接口，CEPH实现了其中一部分。值得注意的是，这里面包含了一个O_LAZY标记，允许应用程序打开文件时减弱对共享写文件条件的需要。对效率要求高的程序，可以自己管理一致性（同时写一个文件的不同部分）来将同步IO变为缓存读写。如果需要，应用程序可以通过调用lazyio_propagate将缓存中的数据写入磁盘(flush)，调用lazyio_synchronize来保证任何后续的读操作都能读到最新的数据。因此CEPH的同步模型通过同步IO保证了多客户端共享写的一致性和正确的读写操作，并为效率要求高的应用程序提供了弱一致性的扩展接口。

命名空间操作

客户端和文件系统命名空间的交互是用过元数据服务器管理的。读操作(readdir, stat)和更新操作(unlink, chmod)是由MDS同步提供来保证操作是有序的，一致的，正确的和安全的。为了简单起见，客户端没有锁和租约。

CEPH为常见的元数据访问场景进行了优化。每一个readdir操作都跟随一个对每个文件的stat操作(ls -l)是非常常见并在大文件夹访问时会牺牲很大的效率。在CEPH中readdir操作只需要一次MSD请求，它会获取包括inode内容在内的整个文件夹的信息。默认情况下，如果一个readdir操作后立即执行一个多多个stat操作，那么会返回临时缓存里面的信息；否则则丢弃。尽管这种弱一致性可能使得，在这段间隙时间内对inode的更改不可见，但这换来大量的性能提升也是值得的。这种行为被readdirplus[31]扩展明确实现，它将返回lstat的结果和目录项。

CEPH允许对元数据信息进行更长时间的缓存，类似早期版本的NFS，缓存30秒。但这会很大程度上破环一致性。

个人理解

这篇文件应该讲的是CephFS，Ceph还有其他的客户端像RADOSGW和RBD设备