GPFS杂记——三大关键组件

概述

大致架构

一个GPFS可以通过多个node挂载，每个node拥有一个独立的log，集群所有node的log是共享的，任意node可以代表已宕机node执行recovery，而不必等待宕机node复活，通过re-apply已宕机node的log，即可快速恢复文件系统metadata一致性。

主要流程

GPFS使用inode和间接块保存文件属性和data block address，使用directory block以extensible hashing方式组织某个directory内的entry，进而实现大目录的文件名快速查找。创建一个新文件，需要更新一个directory block和一个新inode，分别获取directory block、inode的锁，均在buffer cache更新，记录log record，先将对应的log record强制刷disk，再将已修改inode及directory block写回disk，假如node已将direcotry block刷盘、尚未将inode刷盘即宕机，其log可以保证重做inode。log可以是固定长度，一旦其所描述的更新均已被写回disk，该log record即可被丢弃。不同node并发读写一个文件时，唯一异常是atime更新不会立即对所有node可见。

并发控制——token manager

GPFS的DLM，使用一个集中的global lock manager运行在集群某个node，与运行在每个node的local lock manager协作，global lock manager通过分发lock token在local lock manager之间协调锁资源，lock token传递授予分布式锁的权利，而不需要每次获取或释放锁的时候产生一个单独的消息交换，同一个node重复访问相同的disk object，只需要一次消息交互，当另一个node需要该锁时，需要额外的消息从第一个node撤回lock token，以便可以授予第二个node。lock token也扮演着维护cache一致性的作用。

    使用byte-range lock同步file data的读写（最小区间是一个sector），也可以同步data block的分配，第一个node写某个文件，会获取整个文件的byte-range token（0至∞），只要没有其他node访问该文件，所有的读写操作均在本地处理而不需要与其他node交互，当第二个node开始写该文件，它需要撤回至少一部分byte-range token，当第一个node接收到撤回请求，它会检查该文件是否正在使用，若已经关闭则放弃整个token，第二个node可以获取整个token，若尚未关闭则仅放弃一部分token。假设第一个node顺序写至O1，第二个node需要写O2，第一个node会放弃从O2至∞（若O2 >O1）或者从0至O1（若O2

    只要访问模式允许预测被访问文件在特定node即将访问的区域，token协商协议能够通过分割byte-range token最小化冲突，不仅仅是简单的顺序访问模式，也包括方向顺序、向前或向后跨越式访问等访问模式。

    token manager，跟踪集群内所有授予node的lock token，针对一个token的获取、放弃、升级、降级等操作，均需与token manager通信一次，token manager会实时监控自己的内存使用情况，适当地撤回一些token以杜绝无限制的增长。当需要撤回一个token时，由发起node向所有以冲突模式持有token的node发送撤回消息，收集全部回复打包发给token manager，也允许一次获取多个token，例如，某个文件第一次被访问时，可以一次性申请inode token、metanode token、byte-range token。当node删除一个文件时，node不会立即放弃该文件相关的token，随后创建新文件时会复用该inode，进而减少token通信。

元数据组织——metanode

多个node写同一个文件会导致并发更新inode及间接块，基于inode引入shared write lock，允许多个node并发写，仅需要准确文件大小及mtime的操作会冲突，某个访问该文件的node会被指定为metanode，仅metanode可以读写disk inode，其他node仅更新本地缓存的inode拷贝，定期或者当shared write token被另一个node上的stat()或read()操作撤回时，将其更新传给metanode，metanode通过保留最大size和mtime合并来自多个node的inode更新，非单调更新文件大小和mtime的操作（trunc()或utimes()）需要获取exclusive inode lock，间接块的更新也是使用类似的方式同步。

    GPFS使用分布式锁保证POSIX语义，inode及间接块使用集中方式，这允许多个node写同一个文件时，更新metadata没有锁冲突，每次写操作不需要从metanode获取信息。指定文件的metanode是借助token server动态选举的，当一个node第一次访问文件，它尝试获取该文件的metanode token，其他node学习，当metanode不再访问该文件，并且相关修改已移出cache，该node会放弃它的metanode token，并停止相应行为，当它随后收到一个来自其他node的metadata请求，它会发送一个拒绝的答复，其他node会尝试通过获取metanode token接管metanode角色。

空间管理——allocation manager

allocation map记录文件系统所有disk block的分配状态（free或in-use），每个disk block最多可以被分成32个subblock，用于保存数据或者小文件，一个disk block包含32个bit，以及用于查找指定大小空闲disk block或subblock的链表。分配磁盘空间需要更新allocation map，必须在node之间协调，将map分成若干个固定数量的可独立锁定region，不同的node可以从不同的region分配空间，仅一个node负责维护所有region的空闲空间统计信息，该allocation manager node在mount阶段读取allocation map初始化空闲空间统计信息，其他node定期汇报分配回收情况，每当node正在使用的region空间耗尽时，它会向allocation manager请求一个region，而不是所有node单独查找包含空闲空间的region，一个文件可能包含不同region的空间，删除一个文件需要更新allocation map，其它node正在使用的region会发送到对应node执行，allocation manager会定期发布哪些node正在使用哪些region的提示消息，促进构造发送释放请求。

node故障

 当某个node故障，通过运行log recovery恢复metadata至一致状态，释放该node持有的token等资源，任命其他node接管该node负责的metanode、allocation manager、token manager等角色。若某个node已经发送metadata更新请求至旧metanode，旧metanode故障后，一直未收到确认该更新已提交的应答，会重新发送请求至新metanode，因为metadata更新请求均是幂等的，所以新metanode可以重做该请求。