AFS文件系统

AFS文件系统

历史

AFS是美国卡内基梅隆大学CMU与IBM联合研制的（项目开始于1982年，相关文章始见于1986年），发行了几个版本，AFS3.0是顶峰之作。其后，针对AFS的工作转移到Transarc公司，AFS演变为OSF的分布式计算环境（DCE）的分布式系统（DFS）组成部分。1998 年 IBM 收购了 Transarc，并使 AFS 成为一个开放源码产品，叫做 OpenAFS。同时， OpenAFS 衍生了其他的分布式文件系统，如 Coda 和 Arla。其版本发展如下图所示：

AFS的版本演化

基本概念

AFS是专门为在大型分布式环境中提供可靠的文件服务而设计的。AFS扩展性好，能够扩展到几千个节点，提供一个统一的位置无关的名字空间。AFS规定了以"/afs/cellname"为第一级目录的基本结构，使用户能够在任何地方都能够使用同一个目录地址对自已的文件进行透明访问。

AFS的挂载示例

AFS中几个重要的概念：

单元（Cell）：是AFS一个独立的维护站点（如上图的ihep.ac.cn），通常代表一个组织的计算资源。一个存储节点在同一时间内只能属于一个站点；而一个单元可以管理数个存储节点。

卷（Volumes）：是一个AFS目录的逻辑存储单元，我们可以把它理解为AFS的cell之下的一个文件目录，如上图单元ihep.ac.cn之下的usr目录。AFS系统负责维护一个单元中存储的各个节点上的卷内容保持一致。

挂载点（Mount Points）：关联目录和卷的机制，挂载点<---> 卷，例如上图的/afs/ihep.ac.cn/usr这个挂载点就关联在usr卷上。

复制（Replication）：隐藏在一个单元之后的卷可能在多个存储节点上维护着备份，但是他们对用户是不可见的。当一个存储节点出现故障是，另一个备份卷会接替工作。

缓存和回调（Caching and Callbacks）：AFS依靠客户端的大量缓存来提高访问速度。当被多个客户端缓存的文件被修改时， 必须通过回调来通知其他客户端更新。

Tokens和Access Control List：用于访问权限管理，这里不在赘述。

设计架构

AFS 管理人员把单元划分为所谓的卷。虽然卷可以随硬盘分区协同扩展 (co-extensive)，但大多数管理人员都不会将整个分区只分为一个卷。AFS 卷实际上是由一个单独的、称作 Volume Manager 的 UNIX 类型的进程管理的。您可以以一种常见的方式从 UNIX 文件系统目录安装卷。但是，您可以将 AFS 卷从一个文件服务器移动到另一个文件服务器 —— 同样是由一个 UNIX 类型的进程来管理的 —— 但是 UNIX 目录不能从一个分区实际地移动到另一个分区上。AFS 通过 Volume Location Manager 自动跟踪卷和目录的位置，并留意复制的卷和目录。因此，每当文件服务器非预期地停止操作，用户根本无需担心，因为 AFS 会把用户切换到另一个文件服务器机器上的复制卷，而用户可能都不会注意到。用户从来不对 AFS 服务器上的文件进行操作。他们操作已经由客户端缓存管理器从文件服务器中取出的文件。

AFS部署示例

AFS服务器运行下列进程：

文件服务器（File Server）进程：这个进程响应客户工作站对文件服务的请求，维护目录结构，监控文件和目录状态信息，检查用户的访问。

卷宗服务器（Volume Server）进程：此进程处理与卷宗有关的文件系统操作，如卷宗生成、移动、复制、备份和恢复。

基本监察服务器（Basic OverSeer Server）进程：这个进程运行于有BOS设定的服务器。它监控和管理运行其他服务的进程并可自动重启服务器进程，而不需人工帮助。

卷定位服务器（Volume Location Server）进程：该进程提供了对文件卷宗的位置透明性。即使卷宗被移动了，用户也能访问它而不需要知道卷宗移动了。

鉴别服务器（Authentication Server）进程：此进程通过授权和相互鉴别提供网络安全性。用一个“鉴别服务器”维护一个存有口令和加密密钥的鉴别数据库，此系统是基于Kerberos的。

保护服务器（Protection Server）进程：此进程基于一个保护数据库中的访问信息，使用户和组获得对文件服务的访问权。

更新服务器（Update Server）进程：此进程将AFS的更新和任何配置文件传播到所有AFS服务器。

备份服务器（Backup Server）：维护备份数据库中的信息并管理卷的备份操作。

缓存管理器（Cache Manager）：响应本地应用程序的请求，来跨 AFS 文件系统取出文件。并存放在缓存中。

AFS通 过在客户端大量开辟文件缓存来提高性能。如果文件是经常更改的源文件，那么文件的几个复制版本存在于多个客户端中可能不太好。因为用户很可能要频繁地更改 经常被请求的源文件，所以您会遇到两个问题：首先，文件很可能被保存在客户机缓存内，而同时还保存在几个文件服务器机器上的几个复制卷内；然后，Cache Manager不得不更新所有的卷。文件服务器进程把文件发送到客户机缓存内并随其附带一个回调，以便系统可以处理发生在其他地方的任何更改。如果用户更改了缓存在其他地方的复制文件，原始文件服务器将会激活回调，并提醒原始缓存版本它需要更新。

分布式版本控制系统也面临这个经典问题，但是有一点重要的区别：分布式版本控制系统在断开时可以运行得很好，而 AFS 文件系统的任一部分都不能断开。断开的 AFS 部分无法再次与原来的文件系统连接。失效的文件服务器进程必须与仍在运行的 AFS 文件服务器重新同步，但是不能添加可能在它断开后保存在本地的新更改

AFS还配有一套用于差错处理，系统备份和AFS分布式文件系统管理的实用工具程序。例如，SCOUT定期探查和收集AFS文件服务器的信息。信息在给定格式的屏幕上提供给管理员。设置多种阈值向管理者报告一些将发生的问题，如磁盘空间将用完等。另一个工具是USS，可创建基于带有字段常量模板的用户帐户。Ubik提供数据库复制和同步服务。一个复制的数据库是一个其信息放于多个位置的系统以便于本地用户更方便地访问这些数据信息。同步机制保证所有数据库的信息是一致的。

总结

AFS的优势：

1．历史悠久，技术成熟。

2．有较强的安全性（基于Kerberos）。

3．支持单一、共享的名字空间。

4．良好的客户端缓存管理极大的提高了文件操作的速度。

但以AFS作为机群中的共享文件系统也存在一些问题：

1．消息模型：和NFS一样，AFS作为早期的分布式文件系统是基于消息传递（Message-Based）模型的，为典型的C\S模式，客户端需要经过文件服务器才能访问存储设备，维护文件共享语义的开销往往很大。

2．性能方面：它使用本地文件系统来缓存最近被访问的文件块，但却需要一些附加的极为耗时的操作，结果，要访问一个AFS文件要比访问一个本地文件多花一倍的时间。

3．吞吐能力不足：AFS设计时考虑得更多的是数据的可靠性和文件系统的安全性，并没有为提高数据吞吐能力做优化，也没有良好的实现负载均衡；而当今互联网应用则经常面对海量数据的冲击，必须提高文件系统的I/O并行度，最大化数据吞吐率。

4．容错性较差：由于它采用有状态模型，在服务器崩溃，网络失效或者其他一些像磁盘满等错误时，都可能产生意料不到的后果。

5．写操作慢：AFS为读操作做优化，写操作却很复杂，读快写慢的文件系统不能提供好的读、写并发能力。

6．不能提供良好的异地服务能力，不能良好的控制热点信息的分布

AFS 的后代

由于一些对新文件系统的尝试，AFS 已经明显要退出了。两个这样的结合了开发人员从原始分布式文件系统架构中学到的经验的系统就是：Coda 和瑞典开放源码志愿者的成果 Arla。

Coda 文件系统是改进原始的 AFS 系统的第一次尝试。1987 年在 Carnegie Mellon University，开发人员想要使 Coda 成为对 AFS 的一次自觉的改进，当时 AFS 达到了 V2.0 版本。在上个世纪 80 年代末 90 年代初，Coda 文件系统首次发布了一个不同的缓存管理器：Venus。虽然 Coda 的基本功能集与 AFS 的类似，但是 Venus 支持支持 Coda 的客户机的连续操作，即使客户机已经从分布式文件系统断开了。Venus 具有与 AFS Cache Manager 完全相同的功能，即把文件系统任务从内核内部的 VFS 层取出。

从 1993 年起，编程人员就开始开发 Arla，这是一个提供 OpenAFS 的 GPL 实现的瑞典项目，但是大部分的开发都发生在 1997 年以后。Arla 模仿 OpenAFS 模仿得非常好，只是 XFS 文件系统必须运行在所有运行 Arla 的操作系统上。Arla 已经达到 V0.39 版本了，而且，就像 OpenAFS 一样，运行在所有的 BSD 流派、内核 V2.0x 版本以上的许多 Linux 内核以及 Sun Solaris 之上。Arla 确实为 AFS 实现了一个原本不在 AFS 代码中的功能：断开操作。但是具体情况可能会不同，开发人员也还没有完成测试。

至今，AFS及其变种仍然活跃在分布式文件系统的研究和应用领域。