ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

system desing 系统设计(三): 分布式文件系统distributed file system设计原理

2022-08-16 12:31:51  阅读:46  来源: 互联网

标签:sector 文件 存储 slave distributed system master file 磁盘


   1、众所周知,数据要想永久保存,肯定是要放磁盘的啦!磁盘和内存不一样,内存最小的存储单位是byte,1 byte = 8bit;但是磁盘不一样了,最小存储单位是 sector, 1 sector = 512byte!而在磁盘上,数据都是以文件file的形式存储的。假如文件大小是1kb,那就需要在磁盘上找2个sector来存放!那么问题来了,现在磁盘的容量都是TB级别的,每个sector的大小是512byte,那么磁盘上有billion级别的sector,读取的时候怎么知道这2个sector的位置了?所以肯定是要在磁盘上找个地方存文件sector位置的。除此以外,文件自生还有很多属性要存储,比如文件名、大小、创建时间、创建用户等(大家打开文件夹,看到文件list时就能看到这些文件属性了),如下图: 

         

         这些属性统称为metadata(当然也包括了文件数据本身存放在sector的位置);因为对mestadata的访问频率远高于文件内容本身,所以metadata一般会和文件内容数据分开存放,比如刚开机时,就会把所有文件的metada读到内存,后续直接从内存读metadata,然后从里面找到这2个sector在磁盘为位置,进而从磁盘把文件内容读出来!整个流程就是这样的,但问题很明显:sector只有512byte,导致磁盘sector的数量是billion级别的,光是存储sector的位置就要耗费GB级别的空间,该怎么优化了?

  既然sector的颗粒度太小,导致管理成本高,那就提升磁盘存储的颗粒度呗!这里一次性把8个sector看成整体,8*512byte = 4096byte =4kb,这里定义为block!所以现在metadata的结构展示如下:

       

     block的大小和memory page的大小一样了,但如果按照block划分空间,产生的数据块还是很多,需要存储block offset的耗费还是很大。比如存储高清、蓝光电影,需要耗费上百GB的磁盘,如果按照4kb的block来计算,需要26 milliom个的block来存储,要记录这么多block offset,这个文件的mestadata该多大啊!为了减少metadata的大小,只能进一步提升颗粒度了,这里继续把最小存储单元的大小设置为64MB,称之为chunk!此时如果再存储100GB的文件,只需要 1600个chunk了,极大减轻了metadata的存储压力!图示如下:

          

    此时的文件存储,还仅限于单机!如果现在要存10PB数据,单机肯定是存不下的,怎么在集群上存储这些数据了?

    2、单机存不下,肯定就要考虑cluster集群的啦!一个集群,少则几个node,多则几千甚至数万nodes,这么多nodes,该怎么去管理和运维了?

  (1)集群的管理和组织方式有两种:P2P和master-slave模式!

  • P2P模式的经典代表就是block chain、bt下载等!在这种网络下,每个节点都是对等equality的!整个chain上随时都可以加入新节点,也随时都可以下线节点!在block chain这种去中心化decentralization设计理念和模式下,这种对等的节点是完全可行的,但现在需要设计的是file system,如果每个节点都是对等的,用户怎么去管理几千上万个节点的集群了?
  • 为了方便管理和运维,最终还是需要centralized网络模式,所以master-slave这种模式至今仍然大行其道!想想也是:大到国家的运营,小到公司的运作,哪一个不是中心化、分层级的了?管理上都是层层下推的!

     确定了master-slave模式,接着该讨论master和slave的功能定位了!从名字就能看出来,master是管理节点,slave是具体干活的,所以很自然而然的就能想到: master负责管理和分配slave,slave负责具体的存储数据!图示如下:

       

       master存放了大文件的metadata,最重要的就是index了:记录了文件chunk在哪个slave的哪个offset!为了更加灵活,slave可以自行决定文件存放在哪个chunk!

    经过上述铺垫,distributed file system写入流程就容易理解了,如下:

       

  •     client找到master,指定文件的写入路径;同时master存储文件的chunk list,便于后续读取
  •     master找到合适的slave,返回给client;这里合适的标准是什么了?(1)硬件负载低的  (2)反应速度快的(网速快)(3)当然也可以通过consistency hash算法找slave
  •    client把数据写入master指定的slave

    读的过程类似:

      

  •   client从master那里得到文件的chunk list  
  •     client找到slave读取数据

  (2)上面解决了数据分布式存储问题,可万一slave宕机了怎么办?slave的磁盘坏了怎么办?一个大型集群有数千甚至上万节点,有少量节点宕机正常,怎么才能确保数据不丢失了?

  •   Erasure Coding 纠删码:额外需要50%左右的校验数据。一旦原来的数据丢失,会根据校验数据恢复。但由于恢复时会做大量的计算,所以恢复的效率并不高!
  •        replica 副本:这是目前最常见的数据备份方式,大名鼎鼎的HDFS采用的就是3副本,也就是同样的数据在3个不同的node分别存放。一旦其中一个副本损坏,立即通过另外2副本恢复数据!

       replica 副本的存储过程如下:

  

 

  •  client找master分配slave。由于是3副本,肯定要写到3台不同的节点;
  •  为了避免client多头对接,client只把数据传给其中一个slave,再由该slave把数据传到另外两个slave(内网速度快的嘛);首个存储数据的slave叫队长,选取的标准:负载低的、响应速度快的

     存好后读的时候就简单了:3个slave随便找个就行啦!不过有一点要注意:数据存放后会随同一起存放checksum(可以是简单粗暴地把数据相加,也可以是取MD5等)!读取数据时也会检查checksum,如果不一致,说明数据损坏了,需要修复,最直接的办法就是找master帮忙,提供另外两副本的slave,然后从这两个slave取数据修复,流程如下:

  

 

       读数据时,如果连slave整机都宕机了,直接选取另外两个读取,流程如下:

       

 

   大型集群,master为了随时随地都能了解到slave的情况,以便后续的任务分配,需要slave每隔固定的时间给master发送消息,以告诉master自己仍然live,这种机制叫heartbeat!

        

 总结:

1、分布式文件系统,核心就是把文件拆分成chunk大小,合理地存放在不同的节点!

2、集群中master负责分配slave节点、记录文件在slave的chunk;slave负责存放数据

3、数据损坏后,slave会找master提供另外2副本的位置,然后通过这2副本恢复

 

参考:

1、https://www.bilibili.com/video/BV1Za411Y7rz?p=55&vd_source=241a5bcb1c13e6828e519dd1f78f35b2   GFS设计

标签:sector,文件,存储,slave,distributed,system,master,file,磁盘
来源: https://www.cnblogs.com/theseventhson/p/16589737.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有