一个可扩展,高性能的分布式文件系统
鉴于上次的openflow的文章是直译的,这次Ceph的翻译我增加了很多意译,加入自己的理解来重新组合一些语句,以便让文章更加通顺,容易理解.
译: Ceph-A Scalable, High-Performance Distributed File System.doc
图1: 系统架构. 客户端通过与OSD 直接交互来执行文件IO操作.每个进程既可以直接连接到可以客户端实例,也可以与一个挂载了的文件系统交互.
概述
Ceph文件系统有3个主要的组件:
1. 客户端:每个将一个类POSIX文件系统的接口暴露给一个主机或者进程的实例称之为客户端.
2. 一个OSD的集群: 用来选择性的存储所有数据和元数据.
3. 一个元数据服务器的集群: 用来管理命名空间(文件名和目录名),同时管理安全,一致性和相关性等.(见图1)
之所以称Ceph的接口是类POSIX的是因为我们发现这样更适合扩展接口和有选择地放宽一致性的语义,目的是为了更好的满足应用程序的需要及更好的提高系统性能.
这个架构的主要目标是提供可扩展性(包括几百PB甚至更多),性能以及可靠性.可扩展性是从多个不同维度来考虑的,包括总体的存储容量和系统的吞吐量,性能方面的考虑则包括了单个的客户端,目录以及文件. 我们的目标工作负荷包括如下的极端场景:几十,几百上到成千上万的主机并发的对一个文件进行读写或者同时在同一个文件夹下面建文件.这样的场景在运行高性能计算集群的科研应用上比较常见,这种场景也愈加明显的昭示着未来我们通用场景下的载荷.更重要的是, 我们意识到分布式文件系统的工作负载本身是动态的,与访问数据和元数据的显著差异密切相关,因为动态的应用程序以及数据集一直是变化的.Ceph直接解决了可扩展性的问题,与此同时还获得了高性能,高可靠性和高可用性,实现的方式是通过三个基础的设计特性:解耦的数据和元数据,动态分布的元数据管理和可靠的自动分布的对象存储.
文件I/O和操作能力集
当一个进程打开一个文件时,客户端会向MDS集群发出请求.一个MDS会层层遍历文件系统来将文件名翻译为文件inode, inode包括一个唯一的inode号,文件的所有者,权限,大小,以及其它的文件元数据.如果文件存在且访问被授权,MDS则会返回inode号,文件大小和用来映射文件数据到对象的条带分布策略相关的信息.MDS也可能会发给客户端一个操作能力集(如果客户端没有的话)指定那些操作是许可的.操作能力集目前包括4个比特用来控制客户端的4种能力:读,cache读,写,buffer写.未来这个集合会包括安全键值来允许客户端向OSD证明它们已授权读或者写.(当前的原型是信任所有的客户端).接下来MDS上与文件IO相关的工作包括管理保持文件一致性以及满足适当的文件语义.
Ceph采取了一系列的条带分布车来用来将文件数据映射到一个对象序列上.为了避免需要文件分配的元数据,对象名称仅仅就包括文件的inode号和条带号.对象的复制品然后通过CRUSH分配到OSD上,CRUSH是一个全局已知的映射函数(见5.1节). 例如,如果当一个或者多个客户端打开一个文件读的时候,一个MDS就会给他们赋权来读取和缓存文件内容.有了文件的inode号,分布和文件大小,客户端就能确定找到说我保护文件内容的对象的位置,直接从OSD集群即可读取.范围之外的任何对象或者直接被定义为文件”黑洞”,或者0.类似的,如果一个客户端打开文件写,他被赋权来写和缓冲数据,任何要写到文件内某个偏移位置的数据仅仅只需要写到相应的OSD里面的对象即可.客户端交出了关闭文件的操作能力,提供给MDS新的文件大小(所写的最大偏移), 这样也就重新定义了 (可能)存在且包含文件数据的对象集合.