差异总结表
LustreFS | HadoopFS | GlusterFS | |
Metadata Server | 有。存在单点故障。 MDS使得用户可以访问到存储在一个或多个MDT上的元数据。每个MDS管理着LustreFS中的文件名和目录,并且为一个或者多个MDT提供网络请求处理。 | 有。存在单点故障。 Namenode是一个中心服务器,负责管理文件系统的命名空间以及客户端对文件的访问。集群中的Datanode一般是一个节点一个,负责管理它所在节点上的存储。 | 无。不存在单点故障。 靠运行在各个节点上的动态算法来代替MDS,不需同步元数据,无硬盘I/O瓶颈。 |
POSIX兼容 | 是 | 不完全。为了实现对文件的流式读取,放宽了对POSIX的要求 | 是 |
用户/组的配额 | 支持 | 支持 | 不详 |
权限控制 | Access Control List (ACL) | 独立实现的一个和POSIX系统类似的文件和目录的权限模型 | 不详 |
快照 | Lustre可以创建所有卷的快照,并且在快照系统中把他们集合在一起,以供Lustre挂载。 | 利用快照,可以让HDFS在数据损坏时恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能,但计划在将来的版本进行支持。 | 不支持 |
网络支持 | 可支持各种网络,如 Infiniband(光纤),TCP/IP, Quadrics Elan, Myrinet (MX and GM) 和 Cray。 | 只支持TCP/IP | 支持很多种网络,如千兆以太网,百兆以太网,Infiniband(光纤)。 |
文件分割 | 采用RAID 0模式,将数据分割到一定数量的对象中去,每个对象包含很多数据块。当一个被写入的数据块超过了这个对象的容量时,下一次写入将被存储到下一个目标中。Lustre可以把文件最多分布到160个目标存储上。 | 一个典型的数据块大小是64MB。因而,HDFS中的文件总是按照64M被切分成不同的块,每个块尽可能地存储于不同的Datanode中。 | 不支持 |
备份及恢复 | 提供两个备份工具,一个用于扫描文件系统,一个用于打包备份和加压恢复。 | 支持数据复制。采取一定的策略,将文件的多个副本存放到不同的节点。在读取副本的时候,系统会自动选择最近的副本。 | 支持数据复制,提供全局的命名空间。多个文件的多个副本可以被放置到不同的host上去。这意味着,host以及所有与其相关的磁盘可以因为任何原因而下线,而由其它弄得host来担任文件的完整副本(例如网络分割,甚至只是系统维护)。读取副本时,系统会选择最近的副本。 |
故障自救 | Lustre中的MDS可以被配置成一个主动/被动对,而OSS通常被配置成主动/主动对,这样可以提供没有任何开销的冗余。通常,热备的MDS是另一个LustreFS的活跃MDS,所以在集群之中不会出现空闲的设备。 | 心跳信号检测机制。每个Datanode节点周期性地向Namenode发送心跳信号。 Namenode是HDFS集群中的单点故障所在。如果Namenode机器故障,是需要手工干预的。目前,自动重启或在另一台机器上做Namenode故障转移的功能还没实现。 | 当系统中出现永久性损坏的时候(如一台服务器的磁盘发生故障,导致本地文件无法读取),系统会更换主机并将其加入集群,并自动开始恢复过程。Gluster对一些假定的故障(如硬件故障, 磁盘故障,网络被分割,以外断电)都有处理预案,系统会自动处理这些故障,而不需要管理员的参与。 |
技术支持 | Sun Microsystems | Apache Hadoop项目组 | Gluster |
商业应用 | 为全球100大高性能存储计算(High-Performance Computing-HPC)集群中的40%多提供支持。目前已经拥有成千上万的客户端系统,PB级的存储,数百GB/s的I/O吞吐量。由于Lustre的可扩展性,它在石油,燃气,制造业,媒体,金融等行业得到广泛应用。近年来在ISP(Internet Service Provider)方面的应用呈现增长趋势。 | Hadoop由Doug Cutting在2004年开始开发,2008年开始流行于中国,2009年在中国已经火红,包括中国移动、百度、网易、淘宝、腾讯、金山和华为等众多公司都在研究和使用它,另外还有中科院、暨南大学、浙江大学等众多高校在研究它。 | 世界各地有100多个地区在测试或者使用Guster。大多集中在欧洲和美国地区。亚洲及中国用户较少。 |
动态扩容 | 件数据存在OSS上的对象中。LustreFS的容量以及总的存储带宽可以在不打断任何操作的情况下,通过增加新的带有OST的OSS来实现动态扩展。 | 不详 | 支持动态扩容。可以通过简单的操作动态增加存储,服务器和客户端。 |
扩展能力 | 高扩展性。在产业化环境中,大多数集群的客户端节点在1万到2万左右,最多可以支持到2.6万个客户端节点。目前足以支持40PB的文件系统。 | 在一个集群里可扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。 | 支持线性扩展。可以轻松地扩展到数百PB的量级。 |
安装 | 略微复杂 | 简单 | 简单。在Ubuntu等发行版Linux中有内嵌的软件源的支持。 |
开发语言 | C | Java | C |
I/O特性 | Lustre在产业化环境中的部署目前可以提供100 GB/s的性能。在试验环境中,可以达到130GB/s以及13000 creates/s的性能。 Lustre单独客户端的节点的吞吐量最大可以达到2 GB/s,而OSS最大可以达到2.5 GB/s。在Oak Ridge National Laboratories,Lustre运行在Spider File System上,达到了240 GB/s的性能。 在千兆以太网中,写的速度保持在100 MB/s左右。 | 千兆以太网中,写的速度保持在65 MB/s左右。读的速度保持在117 MB/s左右。但对小文件的写入则只有3 MB/s左右的速度。 |
Lustre,Hadoop, Gluster各自独特的特点
Lustre:
- 基于对象的存储模型
- 支持不同版本之间的互操作
- 用户可以同时对同一文件的不同部分进行操作
Hadoop:
- 流数据访问
- 支持大文件,及数以千万计的数据集
- “一次写入多次读取”的文件访问模型
- 安全模式
- 流水线式的复制
- 浏览器和JAVA接口
- 可恢复一定时间段之前删除的文件
Gluster:
- 线性扩展
- 用运行在各个节点的动态算法取代MDS
- 支持多种存储和文件协议
- 基于FUSE
Hadoop与Lustre的分级比较
把hadoop分为4级:mapper input, mapper output, reducer input, reducer output。
1. Map input:
(1)有文件块的位置信息
Hadoop:以流的形式执行每一个读写任务,只有很少的远程网络I/O。
Lustre:通过每一个客户端并行地执行每一个读写任务。
(2)无文件块的位置信息
Hadoop:以流的形式执行每一个读写任务,只有很少的远程网络I/O。
Lustre:通过每一个客户端并行地执行每一个读写任务,比Hadoop的远程网络I/O要少。
添加文件块的位置信息,可以使得读写操作尽可能地在本地进行,从而可以使网络流量降到最低,并可以提升读写速度。
2. Map output:读/写
HDFS:写在本地的Linux文件系统上,而不是HDFS本身。
Lustre:写在Lustre上。
3. Recude input
HDFS:使用HTTP从远端的Map节点获取Map输出。
Lustre:会简历一个与Map输出之间的硬连接。
4. Reduce output:写
HDFS:Reduce任务会把结果写入HDFS,每个Reducer是串行的。
Lustre: Reduce任务会把结果写入Lustre,每个Reducer是并行的。
Lustre与其它文件系统的比较(见下图)