文件系统开发手记-第2篇 我为什么要在Lustre上做QoS

QoS是Quality of Service的简写，顾名思义，就是保证服务质量。小希我经过多年的苦熬，终于将服务端QoS（NRS TBF）加入主线，同时各种对于QoS改进也在进行中，另外客户端的QoS也在测试阶段。纵观各类文件系统，QoS并不常见，因此我猜想有人会有疑问，为什么要在Lustre实现QoS呢？

实用场景对Lustre的诸多要求，首先最重要的是性能和容量。容量基本上在体系结构设计阶段就已经由可扩展性决定了，所以容量上限基本对分布式文件系统不构成区分度，因为横向地堆容量实在太简单了。所以各位看官如果在做分布式文件系统选型，容量方面的限制基本可以瞄一眼就过。在容量方面，基本上不用担心Lustre，尤其是分布式元数据DNE实现之后。

性能就不光是由架构决定了，聚合带宽通过堆硬件可以勉强挤出来，但是延迟和单点性能受实现细节的影响可就大了。Lustre虽然经历了多年优化，但仍然存在短板，仍然是聚合带宽高，大块数据读写性能高，但读写延迟大，小文件读写性能低，单点性能存在瓶颈的问题。小希我这些年在Lustre代码中淫浸越久，就越体会到这不足，例如单客户端元数据的性能限制，readahead算法的问题，CLIO导致的小文件读写的延迟，等等。这些问题，我也会在以后的文章中陆续分析，敬请期待。不过各位看官请注意，我说的Lustre这短板只是相对于自身的长处而言，没准其他的分布式文件系统做得更差，而且大概率地，其他地分布式系统确实做得更差。毕竟Lustre是高性能存储领域的佼佼者。这就像我们听到学霸说自己某科很烂，千万不能误以为自己这科比他／她好，其实门门科目都被他／她残酷碾压。

写到这，突然感觉前戏好长。好吧，闲话少叙。QoS对Lustre的重要性，不亚于quota对Lustre的重要性。QoS，简单粗暴的理解，就是对性能的分配。相对地，quota，就是对容量的分配。当性能和容量总体不够用的情况下，当然是不顾一切地追求二者。一旦够用，就自然而然地走向细致化。对细致化地分配容量和性能的强烈需求，小希我认为主要不在于技术的内在逻辑，而在于商业动机。

所谓技术的内在逻辑就是，复杂庞大的Lustre系统管理者需要强大的工具监视和控制文件系统的资源使用，以维持系统的正常稳定运转。已经有不止一个用户询问我如何从文件系统层防止某个无脑应用耗尽所有带宽。与本地文件系统不同，Lustre这种大型的集群文件系统，往往是由多个用户和组织共享，因此也更需要QoS。当文件系统还在本地文件系统的时候，这一需求并不明显。但是文件系统发展到了Lustre这个阶段，一个系统被更多地在多个用户、组和项目之间共享，它对于管理的精细化需求也更强烈。例如，当小希我在Ext4社区提出要实现project quota的时候，有个问题被反复问及，那就是究竟project quota有何用途。这个问题对于使用Lustre的人来说不言而喻，但是对于Ext4却并不明朗，这就鲜明地体现了Ext4和Lustre在这方面的不同。着一点在QoS上也成立，因此小希我大胆预测，Ext4等本地文件系统的QoS功能并没有太大市场，因此也不会在近期实现。

而商业动机，指的是使用QoS的重要甚至主要动机是收费管理。根据存储空间实用量来来收费已经out了。用户的聪明过人永远无需怀疑。小希我就多次听闻各类招法。作业一跑完，马上清理数据，誊清空间，这尚算得是合理避费。利用quota缺陷，用1MB小文件窃取存储空间，也是见怪不怪。单纯基于空间使用量来收费，就像是餐馆按照体重增量来收取餐费，虽然操作简单，但是是在客观上鼓励食客多吃贵菜，多上厕所。对餐馆来说不利于控制成本，对食客来说，不利于饮食均衡。基于QoS和quota综合指标进行收费，站在文件系统管理者的角度，是限制了应用对系统带宽的无度占用，激励用户对应用IO模式进行分析和优化，站在用户的角度，是反向监督了文件系统提供方的服务质量，获得了应用的可见带宽保障。

然而，quota功能在各类文件系统上古已有之，但QoS却仍是新新事物。其原因不在于需求，而在于技术难度。技术难度过高，即使需求再旺盛，也只得望梅止渴。技术实现已成可能，但需求却凋敝萎靡，那技术实现也只能烂在土里。客户需求和技术供给像一对夫妇，只有干材烈火，琴瑟和鸣才能蒸蒸日上。需求催生了实现，而技术实现又反哺需求，两者互相促进。QoS之所以出现得晚，并不是客户需求不旺，只是技术实现太难。难的原因，首先在于性能的稳定相对容量的扩展更难获得。存储容量一早就得以堆得很大，但性能却一直拖着后腿。试想一群饿狼分一块肉丁，当然是先到先得，谁壮谁吃，哪还用得着量杯和餐刀。而且，各种IO模式下的文件系统性能表现，就像是从各个角度看庐山，远近高低各不相同。聚合带宽、单点带宽、单线程带宽、元数据速率，IO延迟，各种指标不一而足。而容量却不同，一个Byte，一个inode number就足以描述所有指标。这些原因导致了quota早早地就在Lustre里面实现了，但是QoS却迟迟没有动工。

各位看官可能觉得小希我上面是在扯胡，但是正是在上面一段胡思乱想之后，小希我开始了TBF QoS的开发。功能一推出，就出人意料地获得了社区的广泛支持，甚至最近开始被大名鼎鼎如雷贯耳的NASA关注，真是让小希我喜出望外。这并不在全我预料之中，小希我当时有勇气开始开发TBF QoS，只是因为看到Lustre经过多年的发展，实现QoS已经初具条件。首先Lustre性能尤其是聚合带宽基数已经相当大，单个应用很少完全占掉所有带宽。这一点从我们苦逼的存储厂商怎么跑性能测试就可以看出，一定要多线程，多客户端，调优参数，折腾好长时间，才能充分发挥出存储设备的聚合性能。带宽足够，才使得在各个用户、应用之间分配性能成可能。因为这些原因，我所做QoS工作，只是水到渠成，顺水推舟而已。

 本文章欢迎转载，请保留原始博客链接http://blog.csdn.net/fsdev/article