GIGA+调研

 背景

1.现在越来越多的科学计算和网络服务将文件系统视为一个高速的轻量级“数据库”，将文件当做一个大目录下的无结构记录；

2.程序级的并发导致对元数据服务的并发性要求越来越高

目前文件系统的瓶颈：

1.由单一MDS管理元数据，限制了系统的扩展性

2.将目录的子树分散到不同的mds上管理，但是每个目录及其子树仍然由单一的mds管理；

3.有些系统允许将server作为代理，将请求发送到真正的server上，但是仍然没能解决单目录变化的吞吐量的限制；

4.对称的共享磁盘文件系统，虽然通过使用分布式锁和一致性缓存解决了单目录下并发更新的问题，但是对于并发创建仍然是系统的瓶颈；

5.允许客户端缓存元数据可以加速读速度，但是仍然无法解决更新操作的瓶颈问题

 GIGA+的目标：    

GIGA+尽量避免同步开销，并且尽量减少元数据的迁移； 客户端不换成目录的条目，仅仅缓存目录的索引信息； 客户端缓存的索引信息可能是过期的，此时客户端可能将请求发送到陈旧的server上，则陈旧的server将最新的目录索引信息返回给客户端；当有新的server加入系统时，也将元数据的迁移降到最低并且延迟通知客户端。主要包括以下几点：

1.server水平扩展data partition而不需要维持系统的同步；

2.允许使用过期的partition-to-server映射map；

3.支持在线增加server节点，并且尽量减少数据的迁移

         GIGA+扩展了Fagin的extendible hash方案。extendible hash用来决定将hash值的多少bit位视为有效位，其余的bit位视为无效位留着扩展用。算法使用了两层数据结构：上层是一个indirection，称为header-table（头指针表），每个头指针指向二层数据结构的头。indirection使用一个header-table保存指向partition的指针；header-table中的多个项可以指向同一个partition。header-table中的项使用一个递增的基数索引。GIGA+中，目录条目的名字通过hash与key对应。

         GIGA+中的重要变量是header-table，它保存了索引bitmap和基数。基数与bitmap的增长有关。

         基数随着header-table大小的改变而改变。header-table有2r个条目，每个指向一个partition；如果系统中正好有2r个partition，则每个表项指向不同的partition，否则有部分条目指向同一个partition。当系统中的partition超过2r个时，需要扩大header-table。此时将r加1，即将header-table扩容一倍。当新建一个partition时，原来partition中一半的key将被分配给新的partition。使用r-bit基数中的新加的一位来决定哪些key需要被分配给新的partition；如新加的bit位为1，则将该key分配给新的partition。

 

Bitmap 

GIGA+支持单目录下million甚至billion的文件数目，它使用一个a simple, dense, 的fine-grain bitmap，该bitmap用来将一个文件的文件名映射到一个目录的partition上，或者是映射到一个server上。客户端使用该bitmap查找文件名所对应的partition所在的server，server使用该bitmap来标示其他接收了partition splitting的客户端并且用来更新客户端的索引。Bitmap被缓存在内存中。

每个server需要记录自身的partition分裂后新产生的partition被迁移到的目标server，partition的split历史记录被作为各个partition的属性保存到本地。每个server不需要维护一份全局状态信息，每个server能够增加或者减少它的partition，而无需维护一致性锁以及同步的开销。

采用延迟更新client上的bitmap，当客户端发送的请求被交给了错误的server，server再更新client上的bitmap，这样避免了server更新时需要维护client的bitmap的开销。

bucket0放在huge directory的home server上，home server根据目录名求hash选出；之后分裂产生的partition使用round-robin算法放置。bitmap的前N位指示目录的放置的home server。如图，只有3个server，partition-0根据目录名的hash值被放在S2上，以后产生的partition根据round-robin算法依次放置在S0，S1，S2，S0…上。

Partition放置的server id计算方式如下：

Server计算partition id如下：

 

 

映射和splitting partition

GIGA+用一个bitmap记录partition tree和它所对应的server，在bitmap中的每一位代表一个partition标志，同时每个bit位都被确定地映射到某个目录的server list中的一个server上。当新建一个目录时，如果该目录只有一个partition，则在bitmap中相应的第0号bit被置为“1”，其余的bit位都被置为“0”，表明没有其他的partition。

当目录增长得过大时，溢出的目录将被分割出一个新的partition，同时在bitmap中的相应位置被更新为‘1’。如果一个partition的index是i，在树中的深度为r，那么该partition是0号partition经过r次分裂的结果，当下次分裂时，它将在较大的分区中的文件移动到i+2^rpartition中，同时将两个partition的深度都更新为r+1. 查找partition-_i，首先通过文件名hash得到K值，将K值对2[r]求模，找到符合要求的r值，则找到了该partition所在的server。

GIGA+的最终目标是使得每个server能够本地决定将一个partition分割为多个，而不需要维护系统的顺序性和一致性。server能够本地决定将一个partition分割为两个，GIGA+的server没有全局的partition-to-server映射信息，每个server只有部分索引信息。server除了知道它自己管理的partition信息外，当一个server上的partition被分割后，该server需要记录分割后的子partition被迁移到的目标server。

GIGA+中data partition的示意图，T3时刻，S1管理深度为3的P1，并且知道它原来将P1分为P3和P5，P3和P5分别保存在S0和S2上。server通常不知道其他server上的partition分割情况，所以T3时刻，S0不知道P5，而S1不知道P2。

GIGA+的全局索引信息是所有目录的partition历史记录的合，通过对每个server上的mapping信息求闭包，可以计算出全局索引。客户端也不会维护系统的全局索引信息，然而，一个客户端能够通过从目录的0号partition遍历其分割历史获取该目录的所有partition。然而，计算出来的这些partition也随时可能变成陈旧的信息，尤其是当目录被频繁更改时

         每个小目录的基数都是从0开始的，这个基数保存在HD table结构中。bucket在bitmap中的位置代表了该bucket的索引。在extendible hash策略中，该索引就是二叉树中的一个节点，节点在树种的深度代表了这个索引的基数，并不要求所有server的基数都是一致的。同一个huge directory的基数可能是不同步的。另一个server定位到的bucket可能是一个空的bucket，此时，需要回溯该server上的bitmap查找这个bucket的父目录。bitmap索引时自底向上回溯的，直到找到0号bucket。

         客户端和server将huge directory的状态信息保存在一个hash table中。header table结构中保存了bitmap、基数和home server，在indexing scheme中server用它们定位文件的位置。其中使用一个冲突链保存hash冲突的handle，新的inode总是加到链的链尾。server上还保存了一组指向bucket属性nodes的指针，bucket属性node记录了该bucket中当前的文件数，还有一个bucket锁，用来维护bucket级的并发一致性。

         Huge Dir Node通过hash分配到Hash table中，当有huge dir的hash值冲突时，将冲突的node添加到冲突链上，后加入的node放在链尾。保存了：bitmap，radix以及大目录的home server信息。

每个server支持的directory的数目受hash冲突链结构的大小限制？每个大目录需要占用一个hash冲突链中的一个结构？

 

 

 

 

 

 

 

 

Client的不一致性

客户端常常维护的是一份过期的bitmap，当客户端将请求发送到了错误的server上，server会计算出相应partition所在的server，并且将最新的bitmap发送给客户端。代价：客户端需要额外的定位server的开销，每个server上需要维护其他server上的partition信息，为了加速客户端bitmap的更新，server在更新client的bitmap时不仅仅只更新相关的一条partition信息。

当系统中有2^s个server时，如果partition的深度超过s，则之后一个partition分裂的两份都将放在同一个server上，这样能够避免bitmap的无限增长（客户端陈旧的bitmap也不好导致partition请求被错误地定位到其他server上）。

节点加入

GIGA+中，每个目录对应一组server list，我们能够在合适的时间选择适合的目录进行重新分配。在server重新分配目录期间，不允许客户端更新本地的bitmap，在此期间，允许server代理执行已经被迁移走的partition的操作。

当系统中加入一个新的server时，系统的负载平衡立即被打破，它将系统server上的部分目录条目迁移到新加入的server上。为了避免修改所有目录的映射 ，GIGA+将原来目录增长的映射和新加入server的映射区分开。对于新加入的server，GIGA+不适用round-robin映射方法，而是顺序地将新产生的partition映射到新加入的server上。round-robin的优势是当目录很小并且正在增长时，具有很好并发度；顺序的优势是不会影响原来的映射关系。

初始时，系统中有三个server，每个server上有5个partition，P0--P14使用round-robin算法映射。系统中新加入两个server，之后产生的partition P15--P20将采用新的映射方式：i div M，i是partition的序号，M是原来初始系统中每个server上的partition数目。

GIGA+中，server或client上记录的系统中server的数目可能也是旧的信息。系统中新加入server的编号由集群文件系统的配置管理协议分配（eg：HDFS的Zookeeper）。当系统中的server发现有新的server加入系统后，它将检查自己管理的partition，当发现有partition包含的条目满足阈值时，将split满足要求的partition，并且将新的partition迁移到新加入的server上。

失效处理

GIGA+在server永久失效是，使用chained-declusteringj技术提高目录的可用性。该技术为partition提供多个副本，并且副本和原始partition存放在相邻的两个server上。这样方便将一个server上的部分读请求迁移到相邻的节点上，因此，当一个节点失效后，能够避免有改副本的节点成为访问的瓶颈（可以将该节点上原来的部分访问迁移到其他节点上）还有一些系统使用该技术实现负载均衡，然而GIGA+已经通过hash方式实现了负载均衡。

通常的读写操作，客户端将请求发送到primary partition所在的server上，primary直接处理渡请求，对于写请求，则要在返回客户端前在相邻节点上写一份副本数据。如果客户端请求多次超时，则客户端将标记为失效的请求发送给副本所在的server上。收到失效标记的server将在server间诊断是否有节点失效当某个节点失效或是重新配置后，由它的副本接替它的工作，并且使用chain-declustering技术将部分读访问迁移到其他server上。该转换过程通过在返回给客户端的消息中添加一个标志，表明server已经失效，并且已经使用了chain-declustering将负载迁移。客户端可能继续向primary发送请求，然后发现server已经

失效，或者直接想副本节点发送请求，然后被重定向到primary上重新尝试。