云存储-Google的云存储技术细节 GFS

云存储和云计算的出现是在信息海量存储和处理的需求下产生的，所以是否是真正的云，首先要解决存储和计算的问题。

 

一：云存储

采用类似Key/value模式和Schema Free列表模式 属于抽象化的数据模型，在转向商业应用的实际过程中，需要解决目前的流行系统所能够完成的可能性问题；

 

PC机可以Linux,Windows,Mac,但是后两者都难以承担作为廉价集群的任务，更适合作为用户的终端机；

Linux系统下，如果搭建云存储呢，分布式文件系统，分布式数据库，分布式搜索引擎，分布式Web服务器，分布式缓存，呵呵，的确可以找出很多；

但是这些众多的分布式组件能否彼此有效的组合为支持云存储呢，只有具体的实践才能够见证。

 

Google的设计具有颠覆性，起始也是在充分借鉴了这些分布式组件的基础上，全新设计出一套适合自身业务要求的存储引擎:

1:分布式文件系统GFS

2:BigTable提供数据的结构化和半结构化视图

3:MegaStore则在BigTable基础上在事务支持方面有更加面向数据库，支持组内数据ACID原则

4:Chubby则对GFS和BigTable起到控制器的作用，主服务器的选举、元数据的存储、粗粒度的锁服务

5:SSTable作为BigTable内部用来存储的文件，具有特定的格式

 

针对上述的几个核心模块，每一个都涵盖了很多的技术细节，为了通俗易懂，只有尽可能简单的分析：

一: GFS分布式文件系统，这个不属于Google的最先发明，也有很多类似的分布式文件系统

分布式文件系统需要解决的问题

a:抽象在操作系统的文件系统之上的一个应用程序

b:能够支持大规模存储的规划和复制的合理方案【多个副本的负载均衡，异步复制】

c:文件如何存储，如何快速被检索、访问

d:存储结构的多样性，key/value格式，目录格式，多维格式 【存储节点如何设计】

e:客户端如何和多个存储节点交互【追踪器如何设计】

f:如何在多个客户端跟多个存储节点实现平衡【负载均衡、任务调度】

g:为客户端访问提供透明一致性的访问接口

h:如何管理多个节点的故障转移，提供系统的可用性

 

总结：分布式文件系统，需要设计好存储节点和控制节点【追踪器】，以及提供尽可能好的管理工具和访问接口；

 

 带着这些问题，可以看一下Google的GFS是如何解决这些问题的

GFS：海量非结构化信息的存储平台，并提供了数据的冗余备份、上万台服务器的自动负载均衡以及失效服务器的检测等机制

 

GFS的设计原则：

一：以普通PC作为存储节点、控制节点，数据支持冗余备份、自动检测机器是否有效提供服务，故障机器的自动恢复。

二：存储文件为大文件100M到10G之间，必须对大文件的读写操作做出优化

三：系统存在大量的追加写，写入的内容很少变化，很少出现随机写，支持高效的追加写

四：数据的读取多数为顺序读，少量的随机读

 

这些设计原则让我想起此前所设计的企业级文档引擎的部分原则：

一：提供对非结构化的数据的有效存储、存储支持灵活的分级和目录

二：对大数据文件G级别的文件的上传、备份、下载

三：能够对大数据的内容快速的检索并且定位

四：对大文件的操作比较费时，不要影响其他业务的正常操作

 

根据上述的设计原则，了解一下GFS的整体架构

 三部分组成：

1:唯一的主控服务器{Master}

   负责管理工作

2: 众多的Chunk服务器

  负责数据存储并响应GFS客户端的读、写请求

3:GFS客户端

  负载跟数据存储节点交互，屏蔽访问的细节，让具体应用操作跟本地操作一样

 

GFS的文件系统：

类似Linux/Windows的文件系统，有目录和存放在整个目录下的文件构成的树形结构,可以理解为命名空间

/data/bizdomain/module/timestamp/datafile

GFS提供类似的文件创建、删除、读取和写入等常见的操作接口(API)

 

Chunk:存储数据的物理单元，比如一个大文件，最终还是被分割为具体的固定大小的块来存储 【Chunk】，每个chunk的大小为64M,一个文件通常有多个Chunk组成

 

每个文件可能拥有不同的Chunk，而且这些Chunk可以存储到不同的Chunk服务器上，每个Chunk服务器存储的Chunk可以是来自不同文件的chunk,

而在Chunk服务器内部，会对Chunk进一步分割，为具体的一个Block, Block为一个基本的存储操作单元。

 

GFS的整体架构描述如下：

1：主控服务器，维护GFS命名空间，维护Chunk命名空间

为了识别不同的Chunk,每个Chunk都有一个唯一编号，所有的编号构成了Chunk命名空间，GFS主控服务器还记录每个Chunk存储在那台Chunk服务器上的信息；

GFS系统内部必须维持文件到Chunk之间的映射关系

 

2：chunk服务器，负载对Chunk的实际存储，同时响应GFS客户端对自己负责的Chunk的读、写请求

 

3：GFS客户端，负责读取、更新数据

 实例：一个客户请求，读取支持文件，从P位置开始，读取长度为L

app--->send (filename,start_position,read_length) 到 GFS客户端，客户端介绍到后，内部转换为具体的Chunk序号，再发给

GFS主控服务器，主控服务器根据管理元数据，获取对应的存储Chunk服务器的位置，再返回给GFS客户端

GFS客户端然后，和具体的Chunk服务器建立连接，发送对应的读取的chunk编号的读取范围，Chunk服务器收到请求后，返回对应的数据

 

上述的实现类似文档引擎的实现：

1:有客户端供客户上传、下载文件 【该客户端需要接受文件、或者文件编号】，无需关注文件存储的位置

2:接受到文件编号，主控端首先根据文件编号，获取对应的存储节点位置，以及存储节点路径，将信息返回给客户端

3:客户端建立跟存储节点连接后，下载指定的文件

 

GFS主控服务器

采用主从架构，单一主控服务器，多个存储服务器

GFS管理如下元数据

1：GFS命名空间和Chunk命名空间

2:  从文件到其所属Chunk之间的映射关系

3：每个Chunk在那台Chunk服务器上存储的信息 【为了防止故障，每个chunk会被复制多份】

 

GFS将命名空间以及文件到Chunk映射表都记录在系统日志中，日志被存储在多台机器上

对于第三类元数据，主控服务器启动时会询问每个Chunk服务器，并定期询问来保持最新的信息

 

主控服务器的其它职能：

创建新Chunk以及备份数据，不同的Chunk服务器之间的负载均衡，如果那个chunk不可用，则负责生成新的备份，以及垃圾回收。

 

在数据备份和迁移时，需要考虑：

1：保持Chunk数据的可用性，当某个chunk不可用时，及时备份

2：尽可能减少网络传输压力

 

系统的写交互能力：

一个Chunk有多个备份，如果需要更新，则多个备份都需要同步更新

GFS的实现思路：

选择一个主备份，两个次备份，当需要更新时，发出3个Chunk备份请求，如果所有备份请求都接受到返回，则通知主备份开始写入，

待主备份写入完毕，返回给客户端，客户端通知次备份写入开始，如果次备份写入完毕，整体返回备份完成；

 

如果中间出现问题，则撤销返回；

 

http://hi.baidu.com/huareal/item/c488ade7fa2e4bf8e0a5d4be