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挂了（重启就好了）

Storage

  • how to store a file in a machine
    • Metadata 和 实际文件
      • 实际文件
        • 连续存储：windows，碎片整理，整理连续存储删除后留下来的空挡
        • 分开存储：linux，分成若干个block
          • keypoint: 1 block = 1024 byte，
            • 分的太大：最后一块block浪费
            • 分的太小：在Metadata中保存的index信息会很多，访问次数增加
          • advantage
            • 方便检查错误
            • fragmentation

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

  1. 直接在硬盘上修改
  2. 读出来那一块chunk，再写回去
  3. 直接新写一块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.硬盘空间比较大的
  • 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）

https://www.jiuzhang.com/qa/627/

results matching ""

    No results matching ""