打算部署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的概念，不漏痕迹的取回使用者所需要的文件或目录资料