CA-NFS：2009存储界的一篇雄文

无意中在2009的fast大会上看到这样一篇雄文，作者一针溅血（的确是溅血）的指出了以前分布式文件系统关于负载均衡等方面的调度策略存在的致命缺陷——服务端几乎对他服务的对象的情况一无所知，在服务端看来，每一个单位时间内接受到的I/O请求都是等价的，无论他是阻塞的，非阻塞的，同步的，异步的，因而在这个基础上搞负载均衡那纯粹是扯淡。于是作者雄赳赳气昂昂的自己提出了广为流传的NFS的改进版本--CA-NFS,根据数据结果，在各种不同的负载下，性能平均提升20%。看的情不自禁就努力把它翻译出来了，时间不够加上实力不行，有些地方翻译的不准确，前面附了原文，大家凑合着看吧。

 

CA-NFS: A Congestion-Aware Network File System

翻译：胡浩源

 

摘要

我们发明了一个关于分布式文件系统异步请求的自适应策略的整体框架。这个系统是完整的，它可以管理所有的资源：包括网络带宽，服务端I／O，服务端CPU，以及客户端和服务端内存初始化。它可以加速，延缓或者取消异步请求从而直接提升应用程序觉察到的性能。我们在一个网上拍卖服务上使用了拥塞代价，协调文件系统客户端使用的资源，这样他们可以侦测到不足从而修正他们资源的使用情况。我们把我们的成果集成到了CA-NFS上（一个针对目前非常流行的NFS的扩展）。实验结果表明，在各种不同的负载下，CA－NFS在执行方面比NFS提升了差不多20％。

 

 

 

介绍

分布式文件系统客户端同时消耗服务端和网络资源，完全不考虑他们的操作和他们未来的请求以及其他客户端的关系。每一个客户端请求都消耗系统的性能，特别是在针对的它的一个或者更多资源的负载需求在不断增长的情况下。当更大的容量，更大的工作负载，更多的用户都导致它的拥塞程度增加的时候，所有的客户端操作都分享了延迟的导致的代价。无论如何，客户端对服务端资源的拥塞程度完全不知情。

   
当系统处于拥塞状态的时候，网络文件服务端试图最大化针对客户端的吞吐能力，确保他们能从流速率的提高上受益。由于这种处理方式不能区分客户端文件系统操作的紧急程度和优先级，因此效果并不理想。从服务器的角度看来，任何时间的客户端操作都是同等重要的。这完全是彻头彻尾的谬论。文件系统操作有不同的优先级。一些需要马上处理，而很多则可以延缓。客户端的同步操作（媒体数据，读）比异步操作（大部分写，预读）更需要及时处理，因为它在完成前将一直阻塞拒绝其他的应用程序调用。同时，根据客户端的状态，某些特定的异步操作比其他的更为紧急。比如客户端的内存使用率非常高的情况下，它的所有写操作将变成同步，导致系统性能剧烈下滑。

在本论文中，我们给分布式系统开发了一种性能管理体系，它能动态的评定系统负载，管理系统资源，调度客户端异步操作。当系统资源到达了极限的时候，我们应用优先级策略，优先考虑阻塞的请求，以及优先级继承，比如：写操作有更高的优先级，因此它将阻塞读操作，这样不那么重要的异步I/O操作将不会妨碍即时的同步请求。另一方面，如果系统负载低下，我们将攻击性的处理更多的异步操作，这样自可以避免有可能即将到来的类似操作，从而降低系统拥塞率。

这个体系结构基于整体拥塞代价机制，几乎囊括了所有服务端和客户端的临界资源，从客户端缓存到服务端磁盘子系统。整体意味着不仅仅是端到端机制，它在客户端和服务端之间平衡所有资源。整体意味这系统将定位不同配置的不同瓶颈，以及一直保持对资源不足0的变化作出反应。

服务端通过增减系统中异步读写的代价来强制编码资源，这样子的目的是让客户端缴械投降（？这是什么东西，有哪位知道赐教一下）。当服务端代价上升的时候，未资源编码的客户端将延缓异步操作以减少负载。这样子可以避免那些不太重要的贱命一条的操作阻塞我们无比珍贵的网络和服务端I/O系统。都这么忙了还来凑热闹，太不像话了。

以下我们要展示的算法基于资源利用，和以往的离线代价算法（他们自以为自己无所不知）相比，提供了一种有竞争力的解决方案。相对于移动临界值的启发法而言，这种解决方式是系统和负载分离的。

我们扩展了NFS协议，我们称之为CA-NFS协议（拥塞感知网络文件系统）。我们在linux的NFS服务端，客户端以及内存管理中应用了CA-NFS，试验结果表明，在大量不同的负载情况下，我们提升了超过20%的系统性能。

系统操作

在这个部分，我们给出了和异步操作调度有关的比较直接的经验知识和他们在资源利用方面起到的作用。我们同时演示了在竞价和拍卖中客户端的自适应方式。

 

异步写

异步写的主要（或者是唯一）影响因素就是客户端是否有足够的内存。只有当客户端还有足够的内存的时候，写才是异步的;当一个系统无法为写操作分配内存的时候，它将阻塞这个写操作一直到内存重新可用。这意味着当内存已经无法继续分配（或者可供分配的空间不够大）的时候，在此之后的写操作就会都变成同步的，这将会导致严重的性能下降。

同时由于此时队列中未完成的写操作将直接和硬盘交互，这将同时影响读性能，造成网络和磁盘的排队时延。

 

SA-NFS的异步写机制和传统的NFS不同。NFS客户端一旦接受到write()的指令立刻将数据写入服务端缓存，同时将其读入本地缓冲区。这样子，缓冲页将同时在客户端和服务器被标示为“脏”的。为了将这些数据写到硬盘里，客户端必须再发送一个commit的信息。何时提交取决于以下几个因素。传统来说，当一个脏的缓冲区达到了预先设定的一个寿命值的时候会被清空。现在的系统更多的是使用脏数据占使用内存的比例，一旦达到了预先设定的值就清空这一片内存。那个时候，一个守护进程就会被唤醒并且不断清楚被标示为”脏“的页面直到清理出足够多的页面可供稳定使用。

和NFS不同，SA-NFS自适应的加速或者延缓它的写操作。它通过强制服务器同步数据到稳定存储体（个人认为是磁盘缓存）来加速写操作（同时这样子也使得客户端不用缓存相应的数据），这是基于这样一种考虑，如果服务器的负载和资源利用率非常低，就不需要在稍后的时间再来处理这些操作（而是直接执行）。当然，客户端也可以为了保持它的缓存内容而要求加速写操作，这样子可以维持一个比较高的缓存命中率。注意加速写操作并不意味着写操作变成了同步模式，相反，加速写操作实际上是迅速唤醒客户端的回写机制。（有点迷糊，这些数据到底是写到客户端还是服务端的？）。

加速写机制会增加服务端的资源使用情况并且立刻占用大量带宽。在后台写机制的系统上，很多操作还没到达服务端就被取消了，比如，重复写同一个文件页面，或者创建然后删除一个临时文件。由于这些原因，加速写导致服务器增加的负载可以避免一些。无论如何，加速写没有坏处，因为只有当服务端负载非常低的时候我们才会使用加速写。

延缓写可以在接到write（）指令的时候避免将脏数据拷贝到服务端。相反，客户端一直将数据保存在本地直到服务端资源利用率变低为止。客户端评价异步写的代价，比如用他们占用的内存。