DFS Techniques
Introduce two key techniques of distributed file system.
Speech
下面我来给大家介绍分布式文件系统中另外两个核心技术。
-
首先是Scalability&Usability也就是DFS的可扩展性和可用性。
- 高可用的metadata
- DFS的metadata主要包括文件的命名空间、每个文件不同副本的位置、副本的的版本号等等。
- 在DFS中，metadata的存储主要有两种方式，一种是集中存储，把所有的元数据都存在一个metadata server，统一管理所有的元数据；另一种是将metadata分布到多个节点进行存储。这两种方式相比，集中存储更常用，将元数据和数据分离，整个系统拥有较高的吞吐量，便于实现。
- 以GFS为例，GFS的metadata主要包括三部分内容：命名空间、文件到chunk的映射关系、chunk的位置。 元数据存在唯一的GFS master中，文件按chunk进行划分，每个chunk的大小为64MB，每一个chunk会在多个chunk server中保存副本（默认为3个），chunk server将chunk作为Linux file保存在本地磁盘上。
- 如何根据metadata进行读操作：
- 应用程序调用GFS client提供的接口，表明要读取的文件名、偏移、长度。
- GFS Client将偏移按照规则翻译成chunk序号，发送给master。
- master将chunk id与chunk的副本位置告诉GFS client。
- GFS client向最近的持有副本的Chunkserver发出读请求，请求中包含chunk id与范围。
- ChunkServer读取相应的文件，然后将文件内容发给GFS client。
- Namespace delegation
DFS的命名空间主要是指DFS对文件目录的统一管理。分布式文件系统中，需要考虑并发在同一个目录下创建文件的情况。为了防止冲突，使用锁机制保证对命名空间的互斥访问。- 锁分为读锁和写锁，分别对应读操作和写操作。
- e.g.
- 如果对 /d1/d2/…/dn/leaf 进行操作
- 需要获得 /d1, /d1/d2, /d1/d2/…/dn 的读锁
- 需要 /d1/d2/…/dn/leaf 的读锁或者写锁
- 通过命名空间锁可以允许在相同目录发生并发的变化。比如多个文件在同一个目录被并发创建，每个创建会申请此目录的读锁和各自文件的写锁，不会导致冲突。目录的读锁可以保护在创建时此目录不会被删除、重命名或者执行快照。对相同文件的创建请求，由于写锁的保护，也只会导致此文件被串行的创建两次。因为命名空间的节点不少，全量分配读写锁有点浪费资源，所以它们都是lazy分配、用完即删。而且锁申请不是随意的，为了防止死锁，一个操作必须按特定的顺序来申请锁：首先按命名空间树的层级排序，在相同层级再按字典序。
- 可扩展性
DFS有很强的可扩展性，需要注意的问题：- 如何控制不同server之间的负载均衡
- 如何保证新加入的节点不会因短期负载压力过大而崩溃
- 如何更新元数据
- 高可用的metadata
-
然后是Fault-tolerance也就是容错性，DFS通过多副本机制保证容错性，副本之间要保证一致性。
- Checkpointing—metadata的崩溃一致性：metadata存在master的内存中，operation log记录重要的元数据变化的历史信息，是metadata的持久化记录，我们将它重复存在多个远程机器上，直到日志记录被flush到本地磁盘以及远程机器之后才会回复客户端。
- Leases—租赁机制：保证数据修改时的一致性。
- 由master指定primary replica和secondary replicas，60s后过期重新指定。
- 写操作流程：
- Client向master请求Chunk的副本信息，以及哪个副本（Replica）是Primary
- master回复client，client缓存这些信息在本地
- client将数据（Data）链式推送到所有副本
- Client通知Primary提交
- primary在自己成功提交后，通知所有Secondary提交
- Secondary向Primary回复提交结果
- primary回复client提交结果
- Data的一致性：
- 两种状态：consistent和defined，目的是在所有的replicas的执行相同的串行化操作序列保证file region的defined。
- Handshake检测故障停机
- Checksum检测数据可靠性
- Version控制数据一致性
- 返回哪个副本给Client
