分布式文件系统
Distributed File Systems
2013-7-29
1
1 引言
2013-7-29
2
1.1 概述
文件系统是分布式系统的关键成分
有些时候只是局部使用 许多计算在使用文件作为共享资源时最便于描述 分布式文件系统在所有分布式部件中是最好开发的部分， 因为网络普遍支持工作站池

2013-7-29
11
2.2 目录服务接口
关键问题： 所有机器得到的文件系统视图能够一样吗？
所有机器得到的文件系统视图需要一样吗？ 性能因素会使得公共视图不合需要，即使可以得到 标准的实现策略： 优化最常见的情形 并不向所有用户分布完全的文件系统，限制开销 增加管理开销（决定哪些用户可以看到文件系统的哪些 部分），减少分布式的工作 增加了不常见操作的工作 (delete vs. read)
R/W
2
Client
2013-7-29 9
2.1.2 远程访问
Server
支持文件的远程操作
(Open/Close, R/W等) 文件保留在服务器 较低的起始延迟，但是每次操 作必须通过网络
Open R/W Close 1 2
对客户存储空间的要求小
Client
2013-7-29 10
2013-7-29 13
2.2.1 目录服务接口的名字解决方案
使用名字空间表示所有元素的方法是通用的 要求路径到 I-Node 的翻译适用于所有类型的对象

要求使用 I-Node 表示所有的对象类型

使用实际的方法
名字空间的对象类型 文件：最常用的元素
目录 设备文件：访问设备驱动器 安装点：标识物理文件系统边界 符号链接：

M1:P1 / A B M3:P3 / C D E / F
P1:/A 翻译为M2:P2:/
优点是将对分布性的认识限定在 系统的特殊部分

Path到I-Node的翻译 I-Node操作 本地 Mx 本地操作 远程Mx 远程操作
M2:P2
I-Node ID 现在必须包含机器
位置独立性
文件的移动独立于路径名的变化
/net/server/root不是位置透明的，但是可 以实现位置无关性
2013-7-29 19
2.2.4 目录服务接口的一致性
文件系统名字空间能够在每一台机器上看起来一样吗？
文件系统名字空间需要在每一台机器上看起来一样吗？ 一致性意味着每台机器具有访问每个文件的权力 共享的传递属性

合成操作：在目录上安装一个分区
2013-7-29 15
2.2.2 目录服务接口（文件系统合成）
P1是根分区，为文件系统提 供根 (/) P2 和 P3 是分离的物理部分， 安装在P1上的目录上

P1 / A B P3 / D E / F
16
A和B是P1的目录 用mount操作掩盖
一些可能的方法

2013-7-29
UNIX 语义 会话(Session)语义 不变(Immutable)文件语义 原子事务语义
26
3.2 Unix 语义
对文件的每次操作马上在所有进程中都可见 紧跟在一次写之后的读将返回刚刚写入的值
对于这个文件的所有用户
对于所有文件操作都要求一个全局的全排序，以能 够返回最近的值
30
3.4 不变文件语义
不可能有任何的更新
简化了共享和复制

不可能为写或添加 open 一个文件 只可以修改目录入口 可以创建一个新文件替换原文件 也适合于许多应用

2013-7-29 12
2.2.1 目录服务接口的名字方案
名字空间可以是任意的 用名字和斜杠 (正或反斜杠)最常用，似乎也是最好的

文件系统中的所有对象使用同样形式的符号 最节省 (简洁的表达式)
在同样的名字空间描述用户和程序操作 路径名 (名字空间元素) 操作系统使用自己的内部表示 数据结构引用 (I-Node) 路径名到 I-Node 的翻译 提供对名字空间所有元素的访问
共享文件 A 的任意两台机器就意味着所有主机都可以看到 A
否则共享 A 的主机的名字空间不同于那些不共享 A的主机
显然，共享某些文件的每个系统不愿意共享每个文件
2013-7-29
20
2.2.4 目录服务接口的一致性
完全一致因此只是一个具有吸引力的理论思想，在 实践中是毫无意义的 名字空间的子集一致性无疑是有用的
许多ITTC Linux上的/usr/local 是到 /net/hegel/d4/rtools/...的符号链接
提供了一层的信息隐藏 出现在所有机器上的单个名字空间都是一样的
2013-7-29 23
2.2.5 目录服务接口的名字空间结构
需求和方法依然在发展中
需要什么和什么是划算的等仍然是一个开放的 问题
2013-7-29 6
2.1 文件服务接口
文件属性 与文件相关，但不是文件的一部分 拥有者、大小、创建时间、访问权限 可变/不变 文件创建后可以修改吗？ 通常是可以的，但是这类文件的分布更加困难 不变文件只支持 CREATE 和 READ 不变文件消除了所有一致性因素，所以简化了缓存和复制 权能(Capabilities)：一种访问控制方法 对象明确地向持有者授予访问权 可以从用户传递给用户
将文件传输给 OPEN 或者第一个 READ的客户 在 CLOSE 或者最后一次 WRITE后返 回给服务器 R/W 操作在客户本地实现 概念上简单 要求许多的客户存储 移动整个文件引入了较大的延迟 通信可能增加或减少
取决于R/W体积和文件大小
1
2
Open
Close
1
有时是全局的，有时是特殊的机器集合
2013-7-29
22
2.2.5 目录服务接口的名字空间结构
用户和管理员都必须得到很好的服务
有时是冲突的目标：简单性和透明性
三种常用的方法
机器 + 路径: /machine/path 将远程文件系统安装到本地文件系统 透明的符号链接到不透明的名字上

2013-7-29 14
2.2.2 目录服务接口（文件系统合成）
名字空间是虚拟的，但是文件系统内容是物理的 必须处理多个物理部件 多个物理元素的合成具有的优点： 适度的文件系统伸缩

向名字空间添加任意数目的分区 位置透明性 隐藏物理分区的失效或替换 适度的分布 在文件系统内区分分布的部件 分布的部件仅仅是另一个物理分区
文件服务
文件系统向客户提供的服务内容的规范
文件服务器
在一台机器上实现文件服务的进程
2013-7-29
3
1.2 分布式文件系统设计
理想情况下，一个分布式文件系统应该是透明的
计算和使用文件系统的人不知道分布性 这取决于若干部件的透明性
两个主要部件
文件服务接口
Hale Waihona Puke 对单个文件的操作 目录服务接口 一组文件的操作 名字空间问题
单机环境下使用一个共享I-Node控制所有文件操作 文件数据在所有用户之间共享数据结构 分布式文件服务器必须仿造这种行为 性能上隐含着“即时更新” 细粒度操作增加了开销
2013-7-29 27
3.2 Unix 语义
分布式UNIX语义
可以使用一个单个的集中服务器，对所有操作进行串行 化 在许多使用模式的情况下性能低下
2013-7-29 21
2.2.4 目录服务接口的一致性
无论采用怎样的一致性语义，仍然需要维持共享/分布数据集的 一致的全局视图
怎样支持共享数据集单元操作的语义
系统必须支持一个元素符号，为任何给定机器形成名字空间
文件系统 (分区)一般地是元素 mount 是合成的操作符
支持分区的主机输出分区，使它成为可用的共享
2013-7-29
29
3.3 会话语义
语义可以任意选择更新顺序
违反了常见的 UNIX 语义(UNIX语义允许父子进 程共享一个文件指针)
两个进程追加一个文件数据，如果写操作顺序交错，则 会产生累积结果
会话语义只会产生其中一个进程的结果
与程序员以前的经验不同的语义，必须谨慎使用
2013-7-29
2013-7-29
17
2.2.2 目录服务接口（文件系统合成）
合成 (mounting)也常用于为一个文件系统的变种 创建一般接口
基于FTP的远程访问、WWW (HTTP) 文件系统 加密的和压缩的文件系统
文件系统概念的一般化
许多操作支持一般文件系统 文件系统在 Linux 和其他系统间切换

mount /dev/P2 /A P2 每个分区是一个分离的文件系 统

2013-7-29
分离的 I-Node 池
Path I-Node: /A/C
P1:/A翻译为P2:/
C
2.2.2 目录服务接口（文件系统合成）
考虑分区Ids包含机器标识 M1:P1 Path I-Node: /A/C
公用软件和公共信息通常是共享的 安全和其他使用方式的保密还不清楚
可信工作组是最常用的模式
2013-7-29
24
3 文件共享语义
2013-7-29
25
3.1 文件共享的语义
多个进程共享同一文件的处理方法 每个进程的读写语义必须精确定义
这首先关系到每个进程进行修改的时候 在文件中的反映 它们何时对其它进程可见