hadoop中的JBOD是什么类型的?和COW with hadoop?

时间:2013-07-17 08:04:59

标签: hadoop raid ext3 zfs

hadoop新手,只设置了3个debian服务器群集进行练习。

我正在研究hadoop的最佳实践并遇到过: JBOD没有RAID 文件系统:ext3,ext4,xfs - 没有你用zfs和btrfs看到的那些花哨的COW东西

所以我提出这些问题......


我读到JBOD的地方比hadoop中的RAID要好,而且最好的文件系统是xfs,ext3和ext4。除了完全有意义的文件系统之外,为什么那些是最好的...你如何实现这个JBOD?你会看到我的混乱,如果你自己搜索谷歌,JBOD暗示一个线性附属物或只是一堆磁盘的组合,有点像一个逻辑卷,至少这是一些人如何解释它,但hadoop似乎想要一个JBOD没有结合。没有人体扩张......

  • 问题1)hadoop世界中的每个人对JBOD意味着什么,你是如何实现的?
  • 问题2)将每个磁盘安装到不同的目录是否一样简单?
  • 问题3)这是否意味着hadoop在JBOD上最佳运行,其中每个磁盘只是安装到不同的目录?
  • 问题4)然后你只是将hadoop指向那些data.dirs?

  • Question5) 我看到JBODS有两种方式,要么是每个磁盘进入单独的安装,要么是线性连续的磁盘,这可以做到mdadm - 线性模式,或者lvm我敢打赌也可以这样做,所以我没看到大问题那......如果是这样的话,可以使用mdadm --linear或lvm,因为JBOD人员所指的是这个磁盘的连续性,那么这是" JBOD"或者为hadoop线性连接磁盘?


这是偏离主题的,但有人可以验证这是否也是正确的?使用cow,写入时复制的文件系统,比如zfs和btrfs,只会减慢hadoop的速度,但不仅仅是因为hadoop是牛的实现。

  • 问题6)为什么COW和像RAID这样的东西浪费在hadoop上? 我看到它好像你的系统崩溃并且你使用if恢复它的重要性,当你恢复你的系统时,对hdfs进行了如此多的更改它可能只会认为该机器有故障并且它会更好从头开始重新加入它(把它作为一个全新的datanode)......或者hadoop系统将如何看待旧的datanode?我的猜测是它不会想到它的旧的或新的甚至是datanode,它只会把它看作垃圾...... Idk ......

  • 问题7)如果hadoop看到一个从群集上掉下来的数据节点然后数据节点重新上线,数据稍微老了会怎么样?数据的年龄有多大?这个话题怎么样?


重启问题1 THRU 4

  • 我刚刚意识到我的问题很简单,但我很难解释它,我不得不把它分成4个问题,我仍然没有得到答案我和#39;我正在寻找,听起来非常聪明的人,所以我必须以不同的方式重新提问......

  • 在纸面上,我可以轻松地或使用绘图......我会再次尝试用词......

  • 如果对我在JBOD问题中提出的问题感到困惑......

  • **只是想知道每个人在hadoop世界中指的是什么样的JBOD都是**

  • JBODs在正常情况下使用hadoop进行了不同的定义,我想知道如何在jbods(sda + sdb + sdc + sdd)的concat上实现hadoop的最佳方法,或者只留下磁盘(SDA,SDB,SDC,SDD)

  • 我认为下面的图形表示解释了我最喜欢的内容

(JBOD方法1)

  • 普通世界:jbod是磁盘的连接 - 然后如果你要使用hadoop,你会将data.dir(其中hdfs virtualy sites)覆盖到这个磁盘内的目录中,还有所有的磁盘将显示为1 ...所以,如果你的节点中有sda和sdb以及sdc作为数据磁盘,你可能会将em显示为某个entity1(使用主板的硬件或mdadm或lvm),这是一个线性的concat sda和sdb和sdc。然后你将这个entity1挂载到Unix名称空间中的文件夹,如/ mnt / jbod /,然后设置hadoop在其中运行。

  • 文本摘要:如果磁盘1和磁盘2以及磁盘3分别为100gb和200gb以及300gb大,则此jbod将为600gb大,并且来自此节点的hadoop将获得600gb的容量

* TEXTO-GRAPHICAL OF LINEAR CONCAT OF DISKS BEING A JBOD: * disk1 2 and 3 used for datanode for hadoop * disk1 is sda 100gb * disk2 is sdb 200gb * disk3 is sdc 300gb * sda + sdb + sdc = jbod of name entity1 * JBOD MADE ANYWAY - WHO CARES - THATS NOT MY QUESTION: maybe we made the jbod of entity1 with lvm, or mdadm using linear concat, or hardware jbod drivers which combine disks and show them to the operating system as entity1, it doesn't matter, either way its still a jbod * This is the type of JBOD I am used to and I keep coming across when I google search JBOD * cat /proc/partitions would show sda,sdb,sdc and entity1 OR if we used hardware jbod maybe sda and sdb and sdc would not show and only entity1 would show, again who cares how it shows * mount entity1 to /mnt/entity1 * running "df" would show that entity1 is 100+200+300=600gb big * we then setup hadoop to run its datanodes on /mnt/entity1 so that datadir property points at /mnt/entity1 and the cluster just gained 600gb of capacity

..另一个观点是这个......

(JBOD方法2)

    hadoop中的
  • 在我看来他们希望每个磁盘都是分开的。所以我会将unix命名空间中的磁盘sda和sdb以及sdc挂载到/ mnt / a和/ mnt / b和/ mnt / c ...看起来从网上阅读很多hadoop专家将jbods分类为只是一个一堆磁盘所以unix它们看起来像磁盘而不是磁盘的连续...然后当然我可以组合成为一个实体,使用逻辑卷管理器(lvm)或mdadm(以raid或线性方式,线性偏爱jbod)......但......不能让它们结合起来,因为它似乎在hadoop世界中jbod只是一堆坐在它们自己的磁盘......

  • 如果磁盘1和磁盘2以及磁盘3分别为100gb和200gb以及300gb,那么每个安装盘1 - > / mnt / a和disk2-> / mnt / b和disk3-> / mnt / c分别为100gb和200gb以及300gb,并且来自该节点的hadoop容量将增加600gb

TEXTO-GRAPHICAL OF LINEAR CONCAT OF DISKS BEING A JBOD * disk1 2 and 3 used for datanode for hadoop * disk1 is sda 100gb * disk2 is sdb 200gb * disk3 is sdc 300gb * WE DO NOT COMBINE THEM TO APPEAR AS ONE * sda mounted to /mnt/a * sdb mounted to /mnt/b * sdc mounted to /mnt/c * running a "df" would show that sda and sdb and sdc have the following sizes: 100,200,300 gb respectively * we then setup hadoop via its config files to lay its hdfs on this node on the following "datadirs": /mnt/a and /mnt/b and /mnt/c.. gaining 100gb to the cluster from a, 200gb from b and 300gb from c... for a total gain of 600gb from this node... nobody using the cluster would tell the difference..

问题摘要

**每个人指的是最佳实践,这是组合jbod 分离磁盘的最佳实践 - 根据在线文档,这仍然是一个jbod? **

  • 这两种情况都会获得hadoop 600gb ...它只是1.看起来像一个concat或一个实体,是所有磁盘的组合,这是我一直认为是jbod ...或者它将像2系统中的每个磁盘都安装到不同的目录,最终结果与hadoop容量完全相同...只是想知道这是否是性能的最佳方式

1 个答案:

答案 0 :(得分:8)

我可以尝试回答一些问题 - 告诉我你不同意的地方。

1.JBOD:只是一堆磁盘;一组驱动器,每个驱动器都可以作为独立驱动器直接访问。 从Hadoop Definitive Guide开始,主题为什么不使用RAID?,表示RAID读写性能受到阵列中最慢磁盘的限制。 此外,在HDFS的情况下,数据的复制发生在驻留在不同机架中的不同机器上。即使机架出现故障,也可以处理潜在的数据丢失。因此,RAID不是必需的。 Namenode虽然可以使用链接中提到的RAID。

2.是这意味着在每台机器上安装了独立磁盘(JBOD)(例如/ disk1,/ disk2,/ disk3等)但未分区。

3,4& 5 阅读附录

6& 7。 Check this link了解块的复制是如何发生的

评论后的附录:

<强> Q1。每个人都提到哪种方法最好的做法是对这个组合jbod或磁盘的分离 - 根据在线文档仍然是一个jbod?

可能的答案: 来自Hadoop权威指南 -

  

您还应该设置 dfs.data.dir 属性,该属性指定一个列表   用于存储其块的datanode的目录。不像   namenode,使用多个目录进行冗余,一个datanode   循环在其存储目录之间写入,所以   性能您应该为每个本地指定一个存储目录   磁盘即可。读取性能也可以从拥有多个磁盘中获益   存储,因为块将遍布它们,并且并发   不同块的读取将相应地分布在磁盘上。

     

为了获得最佳性能,您应该使用以下命令安装存储磁盘       noatime选项。此设置表示上次访问的时间信息       不会写入文件读取,这会显着提高性能。

<强> Q2。为什么LVM不是个好主意?

  

通常在TaskTracker和DataNode计算机上避免使用RAID和LVM   降低性能。

这是因为LVM在计算机中的各个已安装磁盘上创建了逻辑层。

Check this link 提示1 更多详情。有些用例在运行Hadoop作业时使用LVM的速度很慢。