Distributed File System
Scenario
- read and write file
- store a file
- bigger better? > 1000T
- multiple machines to store files
- how many machines
Service
- single machine, client -> server
- multiple machines
- P2P,每一台server都是平等的
- 优点:没有single point failure
- 缺点:协作机制比较复杂,多台机器的数据需要经常通信来保持一致(不是每个node都存相同的数据,而是有相同的数据可以存在多个node上to backup)。
- master 来管理servers
- 优点:数据存储可以用partition的方式,由master来管理(master本身不存储数据)。数据容易保持一致
- 缺点:master挂了(重启就好了)
- P2P,每一台server都是平等的
Storage
- how to store a file in a machine
- Metadata 和 实际文件
- 实际文件
- 连续存储:windows,碎片整理,整理连续存储删除后留下来的空挡
- 分开存储:linux,分成若干个block
- keypoint: 1 block = 1024 byte,
- 分的太大:最后一块block浪费
- 分的太小:在Metadata中保存的index信息会很多,访问次数增加
- advantage
- 方便检查错误
- fragmentation
- keypoint: 1 block = 1024 byte,
- 实际文件
- Metadata 和 实际文件
if it is a large file
- Key point: big block, a.k.a, 1 chunk = 64M = 64 * 1024K
- Advantage
- reduce size of metadata
- Disadvantage
- waste some space (small files/last chunk)
save extra-large file in several machine? 10p
- one master + many ChunkServers
- metadata和index放在master
- Chunk Servers = Slave Serves
- 也可以吧每个chunk上的offset保存在那个server上,另外开辟一个index区。这样可以减少master上的metadata的size,同时也减少了master和chunkserver的traffic(chunk offset改变不需要通知master)
- 存储一个10p的文件的metadata需要
- 1chunk=64MB needs 64B (经验值)
- 10P=16*10^6 chunk needs 10G (can be stored in memory, access faster)
Write a file to GFS
- one vs multiple
- 当写入过程中出错了,需要重新写入。一次的话需要传输整个文件,多次的话只要重新传一小部分
- 多次写入的话,按照chunk来存储,所以也按照chunk来传输
- 由client进行分割,把文件分割成若干个chunk并给对应的chunk index
- 每个chunk是如何写入server?通过跟master沟通,得到master分配的chunkserver位置,然后再向chunkserver transfer data。写完之后,chunkserver必须通知client和master已经完成
- 每次涉及到传输的时候,都必须要考虑到失败的情况
- 不能直接通过master来写,不然master会成为系统的瓶颈
- 这里的client是database,而不是user/browser
modify file
which chunk?what if chunk size changed? larger, smaller
- 直接在硬盘上修改
- 读出来那一块chunk,再写回去
- 直接新写一块chunk,然后之前的那块作废,指针指向新的这块
前两个都会存在chunk size变化的问题,所以在GFS上,相当于重新写一份。并且为了保证数据的一致性,修改的时候要上锁,必须要等修改完了才能继续进行后面的操作。所以效率很低。因而在GFS不常进行写操作
How to read a file from GFS
也是分块读取,从master上获取一个chunk list,然后再去对应的chunkserver上读取
Master Task
- 保存所有file的metadata
- 存储map(file name + chunk index -> chunk server)
- 读取的时候找到对应的chunkserver
- 写入时候分配空闲的chunkserver
- 不能直接让master来写,会照成bottlenectk
Scale
one work solution:
- storage
- 普通文件系统: metadata, block
- 大文件: block -> chunk
- 多机器超大文件: chunkserver + master
- 写入
- Master + client + chunkserver 沟通
- master维护metadata和chunkserver表
- 读出
- Master + client + chunkserver 沟通
Question:
- single master failure
- it is ok for most of time
- how to identify whether a chunk on the disk is broker
- CheckSum 校验码,把所有数XOR异或在一起,可以用来检查一位错误
- 如果是checksum错了话,也是代表这个chunk有问题。因为checksum本身就存在这个chunk的末尾
- 1 checksum size = 4bytes = 32bit,所以对于1P的file,checksum=1P/64MB*3bit = 62.5MB
- 何时写入?一边写一边计算,最后加到chunk的末尾即可
- 何时检查?周期性VS读取时候检查,二者都需要
- 多位错误的话,可以用MD5,SHA1等别的方法
- how to avoid chunk data loss when a chunkserver is dwon/fail
- Replica
- 需要多少个备份?3, 2份放在相对比较近的地方,1份放在较远的地方。
- 选择chunkserver的策略根据1.最近写入比较少的LRU 2.硬盘空间比较大的
- Replica
- how to recover
- ask master to get the data from backup server
- how to find whether a chunkserver is down
- chunkserver 主动向master汇报 heartbeat
- Scale about the write lead election
- client在同时写多个chunkserver的时候,会成为bottleneck,这个时候可以指定某个chunkserver成为队长,client只负责给队长,队长再分配给别的chunkserver,此时只需要进行servers之间的通信。速度会快很多。
- 选择队长,最近的vs最闲的
- how to solve chunkserver failure
- 比如队长一直收不到某个机器的信号,说明这个机器坏了。此时队长告知client和master出现错误, client进行retry即可。这个时候对于坏掉的那个server,不要进行修复,直接把数据转移到别的server(from backup)