Lecture #07 & #08

分布式文件系统（松耦合）

§通过网络实现的文件系统
§旨在将数据存储在多台机器，AKA服务器上
§通过网络访问客户端的数据
§应用程序在客户端上执行
§松散耦合的vs. 紧密耦合

新职责

§容错：许多磁盘和节点增加了失败的可能性。 目前，大多数分布式文件系统都可以容忍组件故障。
§高度可用：分布式文件系统通常拥有许多用户。 用户希望能够随时访问他们的数据。
§一致性：需要分布式事务支持
§可扩展：随着数据集的增长，分布式文件系统也在增长
预计将随用户需求而扩展

并行VS分布式

§数据分发

• 分布式文件系统可以在单个存储节点上存储整个对象（文件）
• 并行文件系统跨多个存储节点分发单个对象的数据
  §对称性
• 分布式文件系统通常在存储与其共存的体系结构上运行
  应用程序（并非总是如此，例如GoogleFS，Ceph）
• 并行文件系统通常在体系结构上运行存储在物理上与计算系统分离（这里也不总是如此）
  §容错
• 分布式文件系统承担容错责任
• 并行文件系统在企业共享存储上运行
  §工作量
• 分布式文件系统适用于松散耦合的分布式应用程序（想想数据密集计算）
• 并行文件系统以HPC应用程序为目标，这些应用程序往往执行高度协调的I / O访问，并有大量的带宽要求
  §重载条款！
• 许多文件系统声称都是

NFS（Network File System）

一般home目录都是使用NFS服务共享，架构上就是多个节点的客户端共同共享一个服务端的目录。

NFS服务端实现

NFS也是定义了一个虚拟文件系统（也是建立在本地文件系统之上）

• 不去管理 服务器上的本地磁盘的布局和数据。

Server在本地文件系统之上实例化NFS卷

• 由具体文件系统管理的本地硬盘驱动器（EXT，ReiserFS，...）

NFS客户端的Locking和Caching

依旧是采用锁的机制来避免争用和重叠区域的问题。
读的数据和写的数据都是远程的。
§NFSv4支持文件的有状态锁定

• 客户端通知服务器锁定请求
• 服务器可以通知客户端未完成的锁定请求
• 锁定是基于租约的：客户端可以在lease时间内，不用反复去服务端所要锁
• 失去与服务器放弃锁定的联系
  §允许NFS客户端上有一个缓存，远程文件的副本以供后续访问，在性能上要更好。

NFS Tradeodds

NFS只需要一个Server

它究竟是不是分布式文件系统，有是的一方面也有不是的一方面。

• 是的！ 客户端通过网络与存储服务器进行通信
• 不！ NFS仅支持单个存储服务器，许多客户端可能导致服务器争用

PNFS

可以有多个Server，其中一个作为Mangement server，作为元数据的服务端。客户端一旦通过元数据知道数据的信息就可以不通过mangement server。客户端通过RPC（远程数据访问）来对服务存储直接进行读写。

GFS（Google File System）

搜索引擎通过分布式把各种网页爬下来，进行索引和分析。Google主要是针对自己的一些应用来开发的GFS文件系统。

开发动机

谷歌需要一个良好的分布式文件系统

• 大量数据的冗余存储在廉价和不可靠的电脑
  §为什么不使用现有的文件系统？
• 谷歌的问题与其他人不同，不同的工作量和设计优先级
• GFS专为Google应用和工作负载而设计，Google应用专为GFS设计

Google文件系统工作量

§Google文件系统存储数十亿个对象
§Object= Web文档（大小〜千字节）
§文件很大：~10 GB

• Filescontainmany（orderofmillions）的对象
  §难以管理数十亿个文件，即使文件系统可以支持它
  §主要是吞吐量密集型工作负载

§大多数文件不停的附加新数据 - 大型顺序写入
§随机写入非常罕见
§文件只写一次，然后才能读取
§读取是顺序的
§大型流式读取和小型随机读取
§高带宽比低延迟（可以牺牲短暂响应时间）更重要
§Google应用程序：

• 扫描数据存储库的数据分析程序（关键词搜索）
• 数据流应用程序（视频播放） - 存档
• 生成（中间）搜索结果的应用程序

GFS：假设

§高组件故障率

• 高冗余硬件
  §“适度”数量的巨型文件
• 只有几百万
• 每个都是100MB或更大; 典型的多GB文件
  §文件是一次写入，大多数附加到 - 也许同时发生
  §大型流式读取
  §高持续吞吐量优于低延迟

GFS：设计

§存储为块的文件 （chunks就相当于PVFS的object） - 固定大小（64MB）
§通过复制实现可靠性

• 每个块都在3 +块的错误中复制
  §单一主人协调访问，保持元数据 - 简单集中管理
  §没有数据缓存
• 由于大型数据集，流式读取，效益不大
  §熟悉的界面，但自定义API
• 简化问题; 专注于Google应用
• 创建，删除，打开，关闭，读取，写入。
• 重要添加：记录追加，快照

GFS：架构

§服务器：商品linux机器，运行用户级服务器进程

• Chunk servers：存储数据块（数千）
• 主服务器：存储元数据，管理块服务器（只有一个！）（虽然有副本）
  §多个客户端：不存储数据，只对主服务器和块服务器执行请求（RPC），以及写入/读取数据块服务器（数千）。

chunks：
§数据单位：块

• 文件被拆分为固定大小的块
• 每个块获得一个唯一的64位标识符：chunk handle标识 - 由主服务器分配
  •确保独特性
  •可以选择块服务器
  §块服务器将本地磁盘上的块数据存储为Linux文件

chunk 复制

§客户端使用以下方式向块服务器发送读/写请求：
chunk handle，字节范围
§每个块都在多个服务器上复制

• 默认：3个副本，用户可以调整命名空间的不同级别
  §chunk handle被缓存，客户端可以查找多个chunk handle

GFS：元数据

§Master管理三种类型的元数据

• 文件和块名称空间（也保持持久性）

• 从文件映射到块（也保持持久）

• 每个块的副本的位置

  §持久性元数据保留在主服务器和远程复制副本的操作日志中
  §未永久存储的块位置，每个chunck存在哪不需要log记录，可以重新从chunk server中找到

• 在主启动时，从块服务器检索的位置
  §所有元数据保存在内存中：快速

In Memory 的元数据

§潜在的顾虑：整个系统的容量受到主机具有多少内存的限制
§64MB块== 64字节的元数据
§使用前缀压缩存储的文件命名空间，<64字节
每个文件
§十亿个文件？ 10 - 100 GB ......
§“如果需要支持更大的文件系统，为主机增加额外内存的成本是一个很小的代价，需要付出简单，可靠，性能和灵活性的代价”

Chunk的位置

chunk 服务端管理着chunk，
Master从chunk服务端启动时去检索chunk handle
Master 控制chunk的位置
Master轮询chunk服务器去ping一个message 看他是不是alive，还是fail了，这个叫heartbeat，

Metadata操作日志

§必须将所有元数据操作写入主节点和影子节点的持久日志
§在刷新日志之前可以对操作进行批处理
§Master在启动时重播日志
§主要检查点内存状态定期（一旦日志达到一定大小）
§仅需要重放自上一个检查点以来的日志条目
§检查点以b-tree形式存储
§在新日志可以使用时创建检查点

概念：log结构化写入

在今天的文件系统中非常常见，直接建一个log，里面写好要改哪些东西，然后read的时候去看最后一个log是什么，然后最后更新的log是最新的数据。
§就地写入需要读 - 修改 - 写
§日志结构化写入基于到达顺序以顺序方式放置数据块

• 可以是不同的文件，文件的不同区域等。
• 要求头部信息识别文件，区域等。
• 可以是原子的！ 无论是成功还是失败，全有或全无
• 可以将操作整合在一起以提高性能

系统交互 - 客户端/主服务器/块服务器

§数据变更 mutation
§快照 snapshot

租约和变更顺序

§Mutation 改变元数据或块的内容
§每个变更都在所有复制品上执行，一个副本改了，其他的都要同步改 （Leases就是一个时间段，）
§用于维护复制副本的一致性
§Master授予其中一个副本，作为主副本来管chunk的变更怎么送到每一个副本，那么就有一个Leases时间段之内，这个副本是主副本。
§主副本来选择块的所有变更的序列顺序。

Leases

§Leases旨在最大限度地减少Master的管理开销
§初始超时为60秒
§主副本的请求来自master的扩展
§主副本可以撤销Leases

control flow和Data flow分开
control flow是说要怎么保证一致性和顺序逻辑上的，DAta flow从物理拓扑上来讲，怎么传数据有效。

Snapshots

GFS提供Snapshots操作以制作文件或目录树的副本
§例如 创建庞大数据集的分支副本
§例如 检查点在试验前的当前状态变化
§用于实现它的写时复制技术 copy-on-write技术

• 最小化开销，建一个snapshots就是一个copy副本，那么直接全部制作副本成本巨大，所以采用读的时候直接是share共享，只有写的时候才做copy操作。

容错 - 检测故障

§所有chunk服务器定期向主服务器发送message，称为heartbeats.
§一旦主服务器在该段时间后（通常是heartbeats速率的两倍）没有收到来自块服务器的消息，主服务器会认为chunk服务器已经down了
§Heartbeats还包含其他信息，例如块标识符和Lease扩展请求

某一个chunk服务器down，那么就需要Re-replication
重新复制
§一旦住服务器检测到故障：

• Pullchunk：来自另一个副本的复制chunk，告诉副本
  将chunk复制到另一个chunk服务器
• 主服务器在内存和log日志上更新块信息
  §主机分配块版本以区分陈旧副本

副本放置

§影响安置的因素
§均衡磁盘利用率：磁盘利用率低于平均值的块服务器具有更高的权重
§块服务器上的最近创建：指示对该块服务器的传入大量写入
§在机架上分发复制品以确保可靠性

• 不同的电源
• 不同的网络交换机

高可用性 - Mater副本

§Master将所有操作复制到主副本

• 副本将状态保持在内存中并从主服务器复制操作日志
  §Shadows：主人的复制品，但不是完全镜像
• 如果Master down了，则仅提供对主站状态的读取访问权限
• 可以落后于Master的状态
• 定期读取主操作日志，存储它并应用于其状态

checksuns
数据恢复，校验和计算
§读取：为服务器上的每次读取完成校验和计算

• 没有额外的I / O.
• 计算可能与I / O重叠
  §写入：按书面计算的校验和
• 更容易追加，逐步更新重叠校验和块
• 覆盖更难，需要读取，验证，计算，写入