Octopus:an RDMA-enabled Distributed Persistent Memory File System-论文读后感

注意

第一次写论文读后感，主要是用于记录自己的学习和思考过程，如有侵权请联系本人删除，谢谢~

写在最前面

Octopus是一个分布式持久文件系统，其主要是利用新出现的两种硬件:NVM和RDMA。感觉主要利用了RDMA，对当前文件系统的一些问题的改进。主要针对的问题：
1、多层次堆叠的软件设计----在新硬件下软件开销比重太高；
2、当采用新硬件时，网络吞吐量较高，Server很容易成为系统瓶颈；
3、现有分布式系统的两阶段提交，存在复杂的网络交互过程；
4、普通的RDMA send/recv和read/write在进行消息传递时，既需要接收方进行轮询查找，同时还不保证立刻响应，效率较低。
解决方法：
1、针对问题1----采用持久共享内存池的分布式KV存储机制，同时应用RDMA直接读写语义，绕过文件的多次不必要复制；
2、针对问题2----采用客服端主动IO的方式，其实质就是GFS的元数据和数据分离的思想，服务器只提供文件的元数据，真实的数据让客服端再去数据所在位置获取；
3、针对问题3----采用本地修改，再使用RDMA同步的方式，减少不必要的网络交互；
4、针对问题4----采用新的RDMA语义，里面还有一个额外字段，可以告诉接收方消息所在地址，同时能够让接收方立即响应。

背景

NVM和RDMA的发展，为存储和网络硬件提供了很好的性能，但是当前存在的分布式系统严格隔离了文件系统层、网络层，和重分层的软件设计使得高速硬件得不到充分的利用。

存在的问题

然而，这些文件系统严格隔离了文件系统层和网络层，只替换了它们的数据管理和通信模块，而没有重构内部文件系统机制。
现存的分布式文件系统严格隔离了文件系统层和网络层，仅仅是替换数据管理和通信模块，而没有重构文件系统的内部机制。在使用RDMA和NVM的情况下，软件的延迟所占整个延迟的比接近100%，而在使用磁盘时，大约占2%；同时其也只获取InfiniBand 原始带宽的15%。

可能的原因

1、分层的网络设计，会造成访问远程存储时，存在多次不必要的拷贝，软件所占延迟比例较高，不能充分的开发硬件的带宽资源；
2、数据在内存中进行了多次拷贝，包括用户buffer、文件系统page cache、网络buffer，虽然在低速硬件上可行，但在高度硬件上就有很大的负面影响；
3、当网络变的很快时，若Server处理太多的Client端请求，Server端很快就会称为系统的瓶颈；
4、传统的基于事件驱动的RPC，在硬件提供低延迟通信时，就会产生相对较高的通知延迟；
5、分布式文件系统在一致性上，由于多次网络往返和复杂的处理逻辑，具有很大的开销。(这个问题应该是没有新硬件也存在)

提出的方案

1、避免了文件系统和网络层的严格隔离；通过与NVM和RDMA特性紧密耦合，重新设计文件系统内部机制；
2、数据管理时，Octopus通过将NVM导出到全局空间，其可以直接访问一个共享的持久内存池；避免了把分布式文件系统堆叠在本地文件系统之上，消除了冗余的内存拷贝；
3、数据传输时，卸载数据流到Client端，减轻Server端的压力，从而提高网络的吞吐量；
4、元数据管理时，Octopus提供了一种带有发送者身份的自认证RPC，使用RDMA写原语进行快速通知；
5、通过将RDMA写和原子操作相结合的方式，使用收集-分派方式，提供一种新的分布式事务机制，用于低开销的一致性。

Octopus设计

高吞吐率的数据IO：
1、通过一个共享持久内存池的方式，减小不必要的内存复制；
2、通过Client端主动的方式(即Server端只提供元数据，实际数据还是Client端自己去获取的方式)，提高小IO的吞吐率(让Server不成为其瓶颈)；

低延迟的元数据访问：
1、通过自认证RPC的方式，提供一种低延迟、可扩展的元数据RPC；
2、通过收集-派发事务的方式减小一致性开销。

Octopus由两部分组成：Clients和Data servers；Octopus没有集中的元数据服务器，数据以hash的方式分布在不同的Data servers上。文件的元数据和数据分布在同一个Data servers上，但它的父目录和兄弟文件可能分布在其他节点上。

在每一个Data servers，数据区域在整个集群中进行共享，用于远程访问。而元数据区域为了一致性的原因，保证私有的状态。Data Server的数据区域由6个部分组成：

1、超级块：保证文件系统的元数据；
2、Message pool(消息池):用于交换数据的临时元数据RPC消息的存储；
3、Metadata Index Zone(元数据索引区)：用带链的hash表索引文件的元数据；
4、Metadata Zone(元数据区)：存放文件的元数据；
5、Data Zone：存放文件的数据
6、Log Zone(日志区):用于存放事件日志，用来保存文件系统的一致性。
由于元数据和数据存放在Data Server的不同位置，所以Octopus访问他们有不同的方法：对于私有的元数据，其采用现有文件系统优化的RPC进行访问；对于共享的元数据，其采用RDMA的语义直接进行读写。

数据操作：
通过使用RDMA，同时采用共享可持久内存池的方式，Octopus减少了不必要的内存拷贝；
Octopus通过增加网络往返，采用Client主动的方式，来分摊Server的负载；

元数据操作：
对于元数据，Octopus利用RDMA的write语义重新设计了一个低延迟、可扩展的RPC用于元数据操作；
通过收集远程服务器的数据进行本地日志记录，然后分配到远端的方式，减少分布式事务的一致性开销。

数据IO

Shared Persistent Memory Pool–共享持久内存池

在具有NVM和RDMA的文件系统中，内存的拷贝是文件IO的最大开销。现有的分布式文件系统直接堆叠在本地文件系统之上，会造成IO访问的多次不必要的内存拷贝。会有FS Image->page cache->user space buffer->mbuf->NIC->NIC->mbuf->User Space buffer的7次拷贝。而Octopus通过提供共享持久性内存池的机制，去直接管理数据，而不堆叠在本地文件系统之上，可以有效的减少文件的拷贝次数，只拷贝4次。

Client-Active Data I/O Client端主动IO

对于通常的数据IO而言，比如读IO，其是Server端准备好数据再发给Client端，通常在一个网络往返上完成。而对于高速网络时，Server端很容易称为系统瓶颈。对于远程IO，吞吐量本限制在网络和Server吞吐量的低值上。当装备RDMA时，Server的处理容量成为了小IO的吞吐量瓶颈。
Octopus提出了一种新的方式：首先使用自认证RPC，在Client端和Server端进行元数据交换；最后，Client在获取元数据后，直接使用RDMA的read/write语义读取实际数据，而不需要Server CPU的参与(因为RDAM的read/write是一种单边操作，所以不需要Server CPU的参与)。这样就提高了吞吐率。

元数据

Self-Identified Metadata RPC 自认证RPC

自认证RPC：使用RDMA的write_with_imm命令，这个命令里面绑定了一个identifier字段(里面包括node_id和offset)。这个命令和RDMA write命令的不同：
1、其可以绑定一个字段(这个字段就告诉了Server，消息所在位置)，这个字段既可以让Server端不在message buffer中搜索；也可以告诉Server端返回给Client端时应该写入的message buffer位置；
2、可以让Server进行立刻响应。
这样就提高了Server端的吞吐量。

Collect-Dispatch Transaction 收集-分派事务机制

分布式文件系统需要考虑并发控制和Server之间更新的奔溃一致性。
传统的2阶段提交能够保证一致性，但是他需要在协调者和参与者上都进行加锁和记录日志，他会存在复杂的网络交互，用于协调协调者和参与者之间的日志记录顺序。
Octopus提供了收集-分派事务机制。1、其采用在协调者本地记录日志，在运用RDMA write语义的远程更新到参与者的方式，保证一致性。这样就不存在复杂的协调过程，并且更新日志时也不用远程CPU的参与。从而减轻了协议开销。
2、其使用GCC和RDMA组合加锁的方式，来进行并发控制。在协调者端，其使用GCC加解锁的方式；而对于协调者，其先使用GCC进行加锁，再在协调者调用RDMA write语义远程更新完成后，再有协调者调用RDMA进行解锁。RDMA解锁也不需要远程CPU的参与。