ceph学习（二）——设计架构

²  架构

针对的应用环境是海量文件存储，且底层的存储设备是不可靠的，系统的负载和访问随着时间会动态变化。客户端使用的是用户态程序。

 

²  元数据管理

         使用元数据集群管理元数据请求，元数据都集中存放在OSD上，元数据服务器只用了处理元数据请求已经缓存部分元数据信息；mds集群上缓存的元数据信息使用动态子树分割管理。

         进程打开一个文件：1.MDS解析文件名，将其转会为file inode；2.如果文件存在且访问是合法的，则MDS将文件的inode返回给客户端；3.MDS也可以授予客户端一定的权限（指定哪些操作是合法的，用4个字节标明，包括读，缓存读，写，写缓冲区）

         为了避免使用元数据记录文件的布局，对象名仅仅由文件的inode号和条带号组成；对象的副本通过CRUSH函数分配到OSD上。如果多个client读同一个文件，MDS授权他们读取并且缓存文件内容，通过inode号，layout和文件的大小，client能够为包含文件数据的对象命名并且定位到该对象，可以直接从OSD获取该对象。所有不存在的对象或是字节范围被定义为“洞”或者“0”。如果一个客户端要写一个文件，MDS授予它使用缓冲区写的权限，当文件被关闭时客户端的写权限被撤销，同时将新的文件大小提交到MDS，MDS重新定义该文件的对象信息。

         当写操作跨越对象边界时，客户端获取相关对象的排它锁，然后立即提交写操作，释放锁，通过申请锁和异步刷新数据，对象锁可以掩饰大量写的延迟。有的环境对系统性能有很高的要求，此时就会牺牲系统的一致性，从而获取较高的系统响应。ceph提供特殊的open调用，在打开文件时指定O_LAZY参数，允许应用程序对共享写操作降低一致性要求。lazyio _propagate将指定一个范围的字节并将其刷新到对象存储设备上, lazyio_synchronize确保以后读到的数据都是最新的。

         ceph优化readdir操作，readdir只涉及一次MDS交互，在收到readdir请求后，MDS将返回整个目录的信息，当readdir后有stats查看请求，则可以直接从缓存信息中获取，否则将整个目录的信息舍弃。为了将最新的写操作返回，MDS暂停其他的写操作，收集各个修改操作，将最近的修改内容返回给stats请求。

         MDS使用日志更新数据日志记录允许MDS能够快速有效地将更新的元数据信息发送给OSD集群，同时，每个MDS上的日志能够将重复的元数据更新合并。MDS恢复尚未完成，但是日志能够在一个MDS失效后帮助另一个节点恢复失效节点临界区中的信息，有助于恢复系统的状态。

         ceph的动态子树分割：动态地将缓存的元数据信息分布到一组节点上每个MDS统计自己目录下条目的热度，使用一个计数器来统计，当条目被访问时，计数器+1，同时也会影响其祖先节点，为每个MDS提供一个表述负载分布情况的权值树。定期检查MDS的负载，需要时迁移部分合适大小的子树以维持系统的负载均衡。共享存储和名字空间锁保证了内存中数据迁移的正确性，同时对系统一致性影响最小。

（根据条目的访问频度作为负载，实现热点迁移à没有考虑各个节点的服务能力，网络的状况，是否可靠？）

         元数据服务器的负载均衡和热点问题：1.有大量读访问的目录被复制到多个节点上分散负载；2.当某个目录特别大或是有很重的写负载时，它的部分目录将被迁移到其他节点上客户端访问非热点元数据时，可以将请求直接定位到相应的元数据服务器上；当访问的是热点数据时，客户端将被告知元数据在其他metadata server上或是在多个server上。每个mds的响应会更新客户端缓存的权限，同时会更新与处理条目相关的inode以及它的祖先。

ceph的设计架构和实现机制能够保证，在故障发生前后以及故障产生的过程中，系统的性能保持不变。Ceph有两大特点：1. 每个文件的inode元数据结构相对较小，使得能够将inode结构保存在与它相关的目录项dentry中，此外，能够将一个文件的所有硬链接集中存放在一个辅助表（