转自:http://blog.chinaunix.net/u/13229/showart_270314.html
AFS文件系统学习笔记
● 什么是 AFS 文件系统?
.AFS 是 Andrew File System 的缩写,他是一种分散式的文件系 统 ( Distributed File System )可以将分散在不同机器上磁盘空间组合成一个共有的磁盘空间,让使用者能够在不同的机器上使用相同的文件系统来管理自己的文件 .
● AFS 的 运行模式
.AFS 采用 C/S(Client/Server) 的工作模式 ,Client 发送请求到 Server 提取文件 ,Server Machine 提供文件给请求的 Client 。
当 Client Machine 上的某个 Porcess 第一次需要某个文件资料时 ,Client Machine 上的一个名叫 Cache Manager 的 Process ,便会负责找出存放有该文件的 Server( 他会从 CellServ 配置文件中找到 VLDB 服务器,在经由 VLDB 找到相应文件存放的 Server), 使用 RPC 通信协议来取回文件存储于自己的 Cache 中,之后就可以直接读写于 Cache 中的资料了,这期间 Cache Manager 会适时的和 Server Machine 通信来更新资料,有了 Cache Manager 的帮助使得网络的负荷减轻,因为当我们读写一个在其他机器上的资 料时,不再需要每次都经由网络去读取,而由 Cache Manage 判断在 Cache 的资料是否和 Server Machine 上所存的相同,若相同,就直接使用 Cache 上的资料 , 如此一来 节省了部分读取文件时所需要的传送,更减少了原本 Server 上的磁盘 I/O 负荷。
● OpenAFS 基本原理
OpenAFS 试图 免除安装和管理用于使不同文件系 统 合作的 软 件 时 的痛苦。 OpenAFS 也能使不同文件系 统 更有效地合作。尽管 UNIX 及其引人注目的后 继 者 Plan 9 的最初目 标 是文件,但是商 业现实 指出,与其 彻 底重构 现 代的网 络 文件系 统 ,不如添加另一个分布式文件系 统层 。
1983 年 Carnegie Mellon University 的 编 程人 员开发 了 AFS 。此后不久, 该 大学成立了一家叫做 Transarc 的公司来出 售基于 AFS 的服 务 。1998 年 IBM 收 购 了 Transarc ,并使 AFS 成 为 一个 开 放源 码产 品,叫做 OpenAFS 。但是,故事并未就此 结 束,因 为 OpenAFS 衍生了其他的分布式文件系 统 ,如 Coda 和 Arla , 这 些我将在后面 谈 到。 存在 针对 所有主要操作系 统 的各 种 客 户 机,及大量的 过时 文档 资 料。 Gentoo.org 为 使 OpenAFS 对 Linux 用 户 可用做出了特 别贡 献,即使其他机构在需要分布式文件系 统时 似乎仍然 是指 NFS 。
● OpenAFS 如何 进 行管 理
NFS 是位置无 关 的,它把本地目 录 映射到 远 程文件系 统 位置。 OpenAFS 对 用 户隐 藏了文件位置。因 为 可能所有的源文件都以 读 写副本的形式保存在 复 制到的不同文件服 务 器位置上,必 须 保持 复 制的副本同 步 。 为 此要使用一 项 称作 Ubik 的技 术 ,它源于 单词 “ubiquitous (无所不在) ” ,是 东 欧拼写法。 Ubik 过 程使 AFS 文件系 统 上的文件、目 录 和卷 (volume) 保持同 步 ,但是通常运行三个以上文件服 务 器 进 程的系 统获 益最多。系 统 管理人 员 可以将一个 AFS 站点的几个 AFS cell 分 组 —— 这 个以前的 缩 写 词 AFS 已 经 被保留在 OpenAFS 文件系 统 的 语义 中了。 管理人 员 将决定 AFS cell 的数目,以及 cell 使存 储 器和文件 对 站点内的其他 AFS cell 可用的程度。
● AFS 中 的几个名词解释
Cell :一个管理单元,由一个 Group 或一个管理单位所负责管理建筑的 基本单元,通常是由许多文件及目录所组成的一个结构,不同的 Cell 可以组合成为一个 AFS File Space
通常是一个主服务器和几个附加服务器组成一个 Cell 每个 Cell 共用自己的 VLDB 。
Partition :一般常使用电脑的人,对于硬盘 上的 Partiton 一定不会陌生,对于一个分散文件 系统而言,这个系统管理既然是文件,必会和硬盘扯上关系,使得 AFS 对于硬盘同样可以分 Partition ,但是 AFS 中的分区必须是 /vicepXX 这样的形式 XX 可以是 a-zz 中的任意组合或单个字母。
Volumes :在每个 Partition 上可以再分更小的单元,我们称之为 Volumes ,对于使用者而言,并不需要太注意 Volumes 到底是做什么的,因为使用者使用 AFS ,只是想好好好使用自己的文件,而不必要理会 Volume 或者 Partition ,这两者都只是 AFS 对于硬盘空间的管理,适用者所需要的 AFS 的系统管理都已经帮你弄好了
AFS 管理人 员 把 cell 划分 为 所 谓 的卷 。 虽 然卷可以随硬 盘 分区 协 同 扩 展 (co-extensive) ,但大多数管理人 员 都不会将整个分区只分 为 一个卷。AFS 卷 实际 上是由一 个 单 独的、称作 Volume Manager 的 UNIX 类 型的 进 程管理的。 您可以以一 种 常 见 的方式从 UNIX 文件系 统 目 录 安装卷。但是,您可以将 AFS 卷从一个文件服 务 器移 动 到另一个文件服 务 器 —— 同 样 是由一个 UNIX 类 型的 进 程来管理的 —— 但是 UNIX 目 录 不能从一个分区 实际 地移 动 到另一个分区上。 AFS 通 过 Volume Location Manager 自 动 跟踪卷和目 录 的位置,并留意 复 制的卷和目 录 。因此, 每 当文件服 务 器非 预 期地停止操作,用 户 根本无需担心,因 为 AFS 会把用 户 切 换 到另一个文件服 务 器机器上的 复 制卷,而用 户 可能都不会注意到。
用 户 从来不 对 AFS 服 务 器上的文件 进 行操作。他 们 操作已 经 由客 户 端 缓 存管理器从文件服 务 器中取出的文件。 Cache Manager 是居留在客 户 机操作系 统 内核中的一只非常有趣的猛 兽 。(您可以在 2.4 版本以上的任何内核中运行 Cache Manager )。
Mount Point :分散文件系统的最大特色是,不需要专门的指定一部机器作为文 件的存储,相反的,任何一部机器都可以使存储文件的 Server ,也可以成为提出要求存取某个文件的 Client ,那么,文件都分散存储在不同的机器上,使用者要如何存取它所需要的文件呢?
前面提过 Volume 的概念,让我们从 Volume 的概念出发,各位可以将 Volume 视做一个箱子,负责存一个目录文 件,当你下达了 CD 命令更换目前所在的目录,有两种情况会发生,第一种情况是,所更换的目录仍在同一个 Volume ,第二种情况是,需要换到另一个 Volume 中,此时便需要一个指标来指示, 所要更换的目录是在哪一个 Volume ,好到该 Volume 所在处取出该 Volume 的资料,这个指标便成为 Mount Points 。
简单一点来说, AFS 系统是利用 Mount Points 的概念,不漏痕迹的取回使用者所 需要的文件或目录资料
CacheManager : Cache Manager 可以响 应 本地 应 用程序的 请 求,来跨 AFS 文 件系 统 取出文件。当然,如果 该 文件是 经 常更改的源文件,那 么 文件存在于几 个 复 制版本中可能不太好。 因 为 用 户 很可能要 频 繁地更改 经 常被 请 求的源文件,所以您会遇到两个 问题 :首先,文件很可能被保存在客 户 机 缓 存内,而同 时还 保存在几个文件服 务 器机器上的几个 复 制卷内;然后, Cache Manager 不得不更新所有的卷。文件服 务 器 进 程把文件 发 送到客 户 机 缓 存内并随其附 带 一个回 调 ,以便系 统 可以 处 理 发 生在其他地方的任何更改。如果用 户 更改了 缓 存在其他地方的 复 制文件,原始文件服 务 器将会激活回 调 ,并提醒原始 缓 存版本它需要更新。
分布式版本控制系 统 也面 临这 个 经 典 问题 ,但是有一点重要的区 别 :分布式版本控制系 统 在断 开时 可以运行得很好,而 AFS 文件系 统 的任一部分都不能断 开 。断 开 的 AFS 部分无法再次与原来的文件系 统连 接。失效的文件服 务 器 进 程必 须 与仍在运行的 AFS 文件服 务 器重新同 步 ,但是不能添加可能在它断 开 后保存在本地的新更改。
● AFS 的 体系结构
● AFS 分布式文件系统计算环境