计算机研究与发展
JOURNAL OF COMPUTER RESEARCH
AND DEVELOPMENT
1999年 第36卷 第12期 Vol.36 No.12 1999



可扩展单一映象文件系统的设计、实现及评价
王建勇　祝明发　徐志伟　朱宁宁　张弛
摘　要　曙光超级服务器是典型的机群系统，COSMOS是为其研制开发的可扩展的单一映象文件系统.文中主要描述了COSMOS原型系统的设计、实现及评价.其中重点介绍了双粒度合作式缓存、分布式元数据管理及网络磁盘存储分组等关键技术，并利用I/O基准程序对原型文件系统进行了性能评价，测试结果表明了该原型系统在保证系统单一映象的基础上，具备良好的可扩展性.
关键词　单一映象文件系统,可扩展性,双粒度合作式缓存,网络磁盘分组,分布式元数据管理
中图法分类号　TP302
DESIGN,IMPLEMENTATION AND EVALUATION OF
A SCALABLE SINGLE-IMAGE FILE SYSTEM
WANG Jian-Yong*, ZHU Ming-Fa, XU Zhi-Wei, ZHU Ning-Ning, and ZHANG Chi
(Department of Computer Science and Technology, Peking University, Beijing 100871)
(National Research Center for Intelligent Computing Systems, Beijing 100080)
(Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100080)
Abstract　The Dawning super-server is a typical cluster system, for which a COSMOS file system has been developed. Mainly presented in this paper are the design, implementation, and evaluation of the prototype COSMOS file system. Here highlit are some key technologies including dual-granularity cooperative caching, distributed meta-data management, and network disk stripping. The performance of the prototype file system is also evaluated using the standard I/O benchmarks. The initial performance measurements show that our approach is a promising one in providing scalable single-image file system.
Key words　single-image file system, scalability, dual-granularity cooperative caching, network disk stripping, distributed meta-data management
1　引　　言
　　虽然现有的分布式文件系统如NFS［1］等已被人们广泛接受，并作为局域网环境下方便有效的共享数据的手段，但远远不能适应目前计算环境发展的要求.尤其最近几年工作站机群系统的迅猛发展，使计算能力有了较大提高，应用的I/O需求日益变大，用户对系统的单一映象、可扩展性和可用性等功能提出了更高的要求，同时机群系统也提供了更多可用的资源（包括高性能的网络、分布于各个节点上的更多可用的磁盘及内存、速度更快的处理器等），为实现高性能的文件系统提供了可能.曙光超级服务器是典型的机群系统，它的主要设计目标除了要提供高性能（即高带宽、低时延）的机间通信机制外，很重要的一点是要提供单一映象功能，诸如单一入口点、单一控制点、单一文件系统等等.我们为曙光超级服务器研制开发了文件系统——COSMOS，并基于其前期原型系统(以下简称为S2FS,即ascalable single-image file system)，对单一映象文件系统的可扩展性技术进行了研究，文中主要描述了S2FS原型系统的设计、实现及评价.
2　系统概况
　　虽然S2FS的设计环境是曙光超级服务器，但其所采用的技术却具有普遍性，适用于通常意义上的机群文件系统的设计.严格的单一系统映象、良好的I/O性能和可扩展性及保证应用程序的完全二进制兼容性是S2FS的主要设计目标.为此，S2FS选择了共享文件系统来作为实现单一系统映象的方法，采用合作式缓存及并行分布式的存储和控制技术来提高文件系统的I/O性能及可扩展性，并利用虚拟文件系统机制来保证与UNIX文件系统的完全二进制兼容.
　　图1给出了S2FS的系统结构.它由核心相关层和用户层两部分组成.S2FS的核心层是在虚拟文件系统一级中实现的，它主要是接收来自逻辑文件系统的I/O请求，并以一定的格式转发给用户层.S2FS的用户层是其主体部分，由3类用户级Daemon进程构成，被分别称为客户(client)、管理服务器(manager)和存储服务器(storager)，它们协调工作，共同完成核心层转发过来的I/O请求.其中存储服务器基于AIX的JFS实现了具体的数据存储，客户完成数据及元数据的缓存，而管理服务器负责缓存一致性的维护及元数据的存储管理.应用程序发出与S2FS相关的文件系统调用，经由逻辑文件系统和虚拟文件系统后，I/O请求被传给S2FS的本地客户，若I/O请求不能由本地客户的缓存得到满足，则转发给管理服务器，由管理服务器通知相应的客户或存储服务器来完成具体的文件操作，并把结果转发给本地客户，然后经过虚拟文件系统和逻辑文件系统把结果返回给应用程序.

图1　S2FS系统结构
3　关键技术
　　我们在满足单一系统映象和二进制兼容性等边界条件下，为了提高S2FS文件系统的I/O性能及可扩展性，设计了基于目录的无效使能协议，提出了双粒度缓存一致性协议［2］.为了避免单一服务器瓶颈问题，采用了数据存储与元数据管理分开的策略，并实现了分布式的数据存储和元数据管理.虽然美国加州大学伯克利分校的xFS系统已经采用了这种serverless的方案，但我们根据曙光超级服务器的特点选择了不同的实现机制.下面我们对S2FS的某些关键技术特点加以介绍.
3.1　双粒度合作式缓存
　　随着越来越多的分布式系统利用高性能的网络将各计算结点连接起来，远程内存正日益成为一种新型的内存结构层次，因为通过高带宽、低时延的网络对远程内存的访问要比本地磁盘快得多.这种远程缓存结构(remote caching architecture)［3］强调了各存储层次（即本地内存、远程内存和磁盘）之间性能上的差异.由于它允许系统中所有结点互相存取各自的本地内存以充分利用远程内存，这种对称式结构显然不同于传统的客户/服务器模型，因为如果系统中任一个客户的本地内存中包含了被请求的数据项，它都可以服务该请求，因而这是一种结点之间地位均等的(peer-to-peer)结构，有些文献［4］称之为合作式缓存(cooperative caching).
　　在使用缓存模型的文件系统中，一个重要的设计问题是决定缓存粒度，它通常也作为文件读/写操作的数据传输单位.缓存粒度要根据文件共享语义、网络通信带宽及时延、应用背景等因素来选择，例如若网络通信带宽较高而时延较大时，缓存粒度不应太小，否则通信开销会太大；相反，若文件共享语义较严格、且应用呈现出较多写共享的特点时，缓存粒度不应太大，否则会引起频繁的“假共享”事件的出现.
　　NFS和Sprite等分布式文件系统在打开文件时对已缓存数据进行有效性验证，而xFS提供了严格的合作式缓存一致性，它们在块一级通过令牌机制来维护缓存一致性.NFS和Sprite等系统使用的粗粒度缓存管理容易引起‘假共享’问题，在频繁的并发写共享(concurrent write-sharing)环境中它们的性能将会急剧下降.为了解决该问题，Sprite采用的方法是：当发生共享写时关掉缓存（cache disabling），而NFS干脆就没有提供严格的一致性保证.然而相对于粗粒度方案，像文件系统xFS在细粒度一级维护缓存一致性将会引起大量的服务器负载和某些不必要的开销.
　　我们为S2FS引入双粒度缓存管理的最初动机是为了克服粗粒度和细粒度方案中各自的缺点.当客户打开一个文件时若没有与其它客户发生冲突（即没有并发的写共享），服务器就授予该客户一个文件回调，当其它客户以冲突方式打开该文件时，服务器通知客户并回收该文件的回调.如果客户失掉了一个文件的回调，那么它将使用令牌机制并在块一级来管理文件缓存(块级的缓存状态转换如图2所示)，这样由于写共享而引起‘假共享’发生的可能性将会变小.

缓存(cache)状态转换条件：
1：读不命中请求；2、4、5、6：无效请求，转发后无效请求，缓存替换请求；
3、7、12：写不命中请求；8、13：令牌降级请求；11、16：写命中请求；
9、10：文件flush请求，系统sync请求；14、15：读命中请求，转发数据请求.
图2　客户端缓存有限状态图
　　我们设计的双粒度协议是在文件和数据块两个粒度上维护缓存一致性的，S2FS总是试图在文件一级进行缓存管理，当发生并发的写共享时才使用块一级的、基于目录的无效使能协议.这里我们给出‘并发写共享’的定义：当一个文件同时在多个结点上被打开，并且至少在其中一个结点上是以写方式打开的，那么该文件就称为正处于‘并发写共享’状态.由于客户很少以共享方式写数据，在细粒度（诸如数据块级）一级来维护缓存一致性会产生大量的工作负载，基于这些考虑，S2FS实现了双粒度缓存一致性协议.当一个客户打开一个文件且不处于‘并发写共享’状态时，管理器就授予该客户一个文件回调(callback)，并承诺当其它客户以冲突方式打开该文件时通知该客户，让该客户放弃文件回调.当客户收到一条‘回收文件回调’请求时，它可判断出此时某些其它客户正以‘并发共享写’方式打开该文件，从此它将在块级粒度上使用基于令牌的方案来维护缓存一致性.
　　S2FS对只读回调和读/写回调（以下简称写回调）作了区别.当一个客户创建一个新文件或者为修改一个文件而打开一个文件（例如，当文件存取模式是O_WRONLY或O_RDWR），且没有‘并发写共享’发生时，管理器将给予该客户一个写回调，否则，如果一个客户以O_RDONLY的存取模式打开一个文件且没有‘并发写共享’发生，该客户就得到一个读回调.图3刻画了客户端文件的5个回调状态以及它们的转换条件.若一个客户打开了一个文件却没有得到任何回调，则意味着并发的共享写正在进行之中.若一个客户拥有写回调，则它可推断出目前它是唯一打开了该文件的客户.

状态转换条件(这里的‘写’意味着文件打开的存取模式是O_WRONLY或O_RDWR，而‘读’则意味着文件的存取模式是O_RDONLY)：
1：文件创建，写打开；2、6：读打开；3、7、10、11：写关闭；4、8：读关闭；5、9、12、21：写打开；13、15：其它客户写关闭相同的文件；14：其它客户写(或读)打开同一个文件；16：其它客户写打开同一个文件；17、19：读打开，写打开，读关闭，写关闭；18、20：读打开，读关闭.
图3　S2FS客户端的文件级缓存有限状态转换图
　　在实现新协议的过程中.我们发现双粒度协议相对于单粒度协议有以下几个好处：①它能够减少由于维护缓存一致性而带来的服务器负载；②在有些情况下，它能够降低客户与服务器之间的通信量；③更为重要的是，它能够提供某些有帮助的提示（hint）信息，S2FS可以利用这些提示信息进一步缓解服务器端的负载以及客户/服务器间的网络开销.
3.2　网络磁盘分组存储
　　传统的分布式文件系统采用单一的文件服务器来响应来自所有客户的I/O请求，包括数据及元数据的存储和管理、缓存一致性的维护等功能.这种单一服务器的体系结构所具有的一个好处是其设计和实现的简单，然而它严重制约了系统的可扩展性和I/O性能，而且单一服务器容易形成单一出错点.为了克服传统文件系统单一服务器的缺点，我们在设计S2FS时，采用了无集中式服务器方案，虽然系统中存在多个服务器，由于S2FS实现了文件存储的位置透明性，在用户看来系统中只有一个虚拟的单一文件服务器.类似于xFS的做法，我们将数据的存储和元数据的管理分开来实现，由专门的被称为存储器的模块实现分布式的磁盘存储.同xFS不同的是，S2FS的存储器只负责存储文件（包括目录文件）数据，而元数据(如文件系统的超级块和索引节点等内容)由管理器负责存储.另外，S2FS是基于AIX操作系统实现的，由于AIX本身的文件系统JFS已对其元数据进行了日志式管理，并提供了异步I/O功能，且S2FS采用RAID1存储模型，不存在大量小块写的问题，因而它没有实现日志式存储功能，这一点也与xFS不同.
　　为了提高存储子系统的性能，就必须允许一个或多个客户以高的磁盘带宽存取单个文件或多个文件，同时能够有效地处理小文件的写请求.因而系统应当将数据分布于多个结点的多个磁盘上以提高并行度.为了实现系统的可扩展性目标，系统应当能够有效地支持成百上千个磁盘，因而系统应当能够灵活地控制磁盘分组（diskstripping）的并行度.磁盘分组是由P.Chen等人为实现大规模的磁盘阵列提出来的［5］，后来被xFS文件系统所采用，并被扩展为网络存储器分组［4］，我们也为S2FS系统实现了存储分组功能，并称之为网络磁盘分组，它比xFS的网络存储器分组更为复杂，因为xFS系统的存储服务器逻辑上对应于1个磁盘，而S2FS系统的存储器可根据系统配置同时挂多个磁盘，我们进行存储分组的基本单位是磁盘而不是存储器，这也是我们称之为网络磁盘分组的原因.
　　实现存储分组的关键数据结构是网络磁盘分组映射表，如图4中(a)所示，它完成了从存储分组标识符到组内一系列网络磁盘的转换.图4中(b)给出了S2FS系统中和图4中(a)对应的网络磁盘的逻辑关系.虽然我们为S2FS的存储模型选择了带镜像功能的RAID1结构，从图4可以看出，目前的版本还没有实现镜像功能，但在图4所示结构的基础上扩充该功能并不困难.
　　当某个客户收到文件创建请求后，它根据某种算法（如轮转法）选择一个管理器，由该管理器负责创建和管理该文件.收到创建文件请求后，管理器根据轮转法（round-robin）为被创建文件选择一个存储分组号和一个逻辑起始磁盘号，存储分组号决定了该文件对应的存储分组所包含的网络磁盘（即存储器和磁盘对），而逻辑起始磁盘号决定了文件的数据从哪一个网络磁盘开始存放.然后管理器向相应的存储器发送创建子文件请求，由存储器创建具体的子文件（注：S2FS系统的文件数据在存储器端是以JFS子文件的形式存在的).因而S2FS系统中数据在磁盘上的位置是由存储分组号和逻辑起始磁盘号来决定的.当客户读/写文件时，客户（或管理器）首先计算出被读/写数据的逻辑块号，根据该文件的存储分组号和逻辑起始磁盘号来计算出被读数据所在的逻辑磁盘号，然后向逻辑磁盘号所在的存储器发送读/写数据请求，存储器计算出被读数据在哪个磁盘上以及在子文件上的偏移量，进而执行JFS系统调用完成此次读/写操作.

图4　网络磁盘分组映射关系
3.3　分布式的元数据管理
　　为了实现单一系统映象，S2FS的一个关键设计原则是保证位置透明性：用户不用关心数据在合作式缓存和网络磁盘分组中的位置，因而如何确定系统数据的位置是非常重要的.在S2FS系统中，该任务是由管理器完成的，它通过分布式的元数据管理以提供可扩展的、分布式的位置服务.另外，管理器的另一个任务是维护合作式缓存一致性.
　　S2FS系统中的每个管理器只负责维护整个系统的一个文件子集的位置信息.管理器使用这些位置信息能够把客户的I/O请求转发到正确的缓存或存储位置，并协调多个客户对相同数据的存取.系统通过使用管理器映射表(见图5)来实现分布式的元数据管理，管理器映射表是一组结点标识符，用来指示哪一个结点管理哪一部分文件系统.系统首先把文件唯一的索引节点号作为输入，通过某个散列函数得到一个逻辑管理器号，以该逻辑管理器号作为下标可以从管理器映射表找出该文件对应的管理器，因而管理器映射表提供了一种抽象功能，便于实现管理服务的位置独立性.

图5　管理器映射表
　　Zebra是较早地把数据和控制路径分开实现的一个文件系统，但整个系统只有一个管理器［6］.xFS为了避免Zebra系统中单一管理服务器的瓶颈问题，它将系统的元数据分布在了多个管理器结点上，以提高系统的可扩展性［4］.事实上在xFS系统之前，许多大规模并行分布式共享内存系统已经采用了这种分布式策略：将有关缓存一致性的元数据分布在多个结点上.S2FS的元数据管理采用了与xFS非常类似的技术，但二者的具体实现仍存在不少差别.由于S2FS的存储子系统是基于AIX的物理文件系统JFS，而且存储分组的单位为网络磁盘而不是存储服务器，因而S2FS在元数据的内容和组织方面和xFS有较大差别，其inode不用记录文件中每块数据的磁盘位置，而是用〈存储分组标识符，起始逻辑磁盘号〉来代替.另外，由于S2FS与xFS的缓存管理（包括一致性协议和替换算法）不同，其有关缓存的元数据内容及其管理亦存在较大差别.S2FS的管理器与xFS的管理器还有一点是不同的：即前者除了对元数据进行管理外，还负责元数据的存储.


4　系统评价
　　我们将S2FS与NFS在相同的实验环境中进行了性能比较，以检验S2FS是否达到了我们的设计目标.我们的实验环境由6台PowerPC工作站组成，其上分别运行AIX4.1或AIX4.2，结点之间用10Mbit/s的以太网互连.这6个结点中，其中1台的主频为100MHz，其余均为133MHz.我们把其中1台主频为133MHz的机器作为NFS的服务器，NFS的客户结点也选用了剩余的主频为133MHz的机器.S2FS系统的管理器和存储器分布于这6个结点上.
　　下面我们通过标准的基准程序测试了S2FS原型系统的读/写文件带宽和可扩展性.对可扩展性的测试我们是基于Andrew基准程序的，它是由美国卡内基-梅隆大学开发的专门用于从应用程序一级测试文件系统性能的标准测试程序.它共分5个阶段，分别对应于创建目录、拷贝文件、列目录状态信息、扫描文件及编译文件.对文件读/写带宽的测试，我们采用了Bonnie基准程序.Bonnie是由TimBray编写的、专门用于测量文件系统的顺序读/写带宽的程序，它完成一系列的测试：大量的单个字符写带宽、大量整块的写带宽、重写（即先整块读出，然后再整块写回）带宽、大量的单个字符读带宽以及大量整块的读带宽.Bonnie运行结束时会打印出各个阶段平均每秒能够处理的字节数以及CPU的利用率.
4.1　读/写带宽
　　我们首先测试了S2FS系统的读/写带宽，并与NFS进行了对比.在我们的实验中，被读/写文件的大小为2M字节，每次读/写的数据块大小为8K字节.我们选择其中一台133MHz结点作为NFS的服务器，它也被用来运行S2FS原型系统的管理器和存储器.同时我们选择另一台133MHz的结点作为NFS和S2FS的客户端，并运行Bonnie基准程序.运行结果见图6和图7.

图6　基于Bonnie的写带宽测试

图7　基于Bonnie的读带宽测试
　　从图6可以看出，S2FS的写带宽（尤其是大块数据的写带宽）胜过NFS很多.而图7说明，S2FS读单个字符的性能优于NFS，而整块（8K字节）读的性能不如NFS，但在同一个数量级，造成这种局面的主要原因是：①我们的测试环境基于10bps的以太网，不能充分发挥S2FS系统的合作式缓存、分布式存储等技术优势；②S2FS原型系统尚未进行代码优化.我们相信在对S2FS进行代码优化并采用高性能的网络后，S2FS系统读大块数据的性能能够达到或超过NFS.
4.2　I/O可扩展性
　　在本实验中，我们分别启动了6个存储器和4个管理器，客户数目的变化范围是{1、2、3、4}.图8示出了在S2FS和NFS系统中，当客户由1个增加到4个时，平均每组Andrew程序的运行时间.可以看出，相对于NFS，S2FS系统中Andrew程序运行时间的增长趋势较为平缓.虽然NFS单个客户的性能要远远优于S2FS（这主要是由于S2FS核心层与客户Daemon之间的通信开销造成的），但当客户增加到4个时，S2FS的性能已超过NFS.这说明S2FS系统的可扩展性要好于NFS，同时也证明S2FS系统的无集中式服务器方案能够有效地克服传统文件系统的单一服务器瓶颈问题.

图8　基于Andrew的可扩展性测试
5　结　　论
　　传统的分布式文件系统由于采用了集中式的服务器，容易成为性能瓶颈，而且没有充分考虑计算技术的发展趋势，分布式系统的I/O瓶颈问题变得日益严重.本文采用合作式缓存、并行分布式的数据存储和元数据管理等措施，在保证系统单一映象和二进制兼容性的基础上，对适合于机群的分布式文件系统的可扩展性进行了研究.应用对I/O的需求是永无止境的，且其I/O存取特征也在不断发生变化，计算技术不断呈现出新的发展趋势，这一切都为我们未来研制新型的分布式文件系统提出了更大的挑战.
本课题得到国家“八六三”计划基金项目(项目编号863-306-ZD01)的资助.
作者简介：王建勇,男，1969年5月生，博士,主要研究领域为网络与分布式系统.
　　　　　祝明发,男，1945年5月生，研究员,博士生导师,主要研究领域为计算机体系结构及
　　　　　人工智能.
　　　　　徐志伟,男，1956年9月生，研究员,博士生导师,主要研究领域为高性能计算机系
　　　　　统.
　　　　　张弛，男，1975年5月生，硕士，主要研究领域为分布式系统.
作者单位：王建勇（北京大学计算机科学与技术系　北京100871）；
　　　　　祝明发　徐志伟　朱宁宁　张弛（国家智能计算机研究与开发中心　北京100080）　
　　　　　　　　　　　　　　　　　　　（中国科学院计算技术研究所　北京100080）
参考文献
　1　Sandberg R. The Sun network file system: Design, implementation and experience. In: Proceedings of USENIX Summer Conference, California: University of California Press, 1987. 300～313
　2　Wang Jianyong, Zhu Mingfa, Xu Zhiwei. Cooperative cache management in S2FS. In: Proc of the 6th International Conference on Parallel and Distributed Processing Techniques and Applications. Las Vegas, 1999
　3　Leff A, Wolf J L, Yu P S. Replication algorithms in a remote caching architecture. IEEE Transactions on Parallel and Distributed Systems, 1993, 4(11): 1185～1204
　4　Anderson T E et al. Serverless network file systems. ACM Transactions on Computer Systems, 1996, 14(1): 41～79
　5　Chen P, Lee E, Gibson G, Katz R et al. RAID: High-performance reliable secondary storage. ACM Computing Surveys, 1994, 26(2): 145～188
　6　Hartman J H, Ousterhout J K. The zebra striped network file system. ACM Transactions on Computer Systems, 1995, 13(3): 274～310
原稿收到日期：1999-05-18；修改稿收到日期：1999-07-20.
