hadoop - hadoop中使用哪种JBOD？和COD与hadoop？

Question

hadoop的新手，仅设置3个debian服务器群集进行练习。

我正在研究hadoop的最佳做法，发现:
JBOD无RAID
文件系统:ext3，ext4，xfs-使用zfs和btrfs看不到任何花哨的COW内容

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

我读过JBOD的每个地方都比hadoop中的RAID更好，而且最好的文件系统是xfs，ext3和ext4。除了文件系统之类的东西，这些东西都是最好的，这是完全有道理的...您如何实现此JBOD？如果您用Google搜索自己的内容，您会看到我的困惑，JBOD暗示了线性附件或一堆磁盘的组合，就像逻辑卷一样，至少这就是某些人的解释方式，但是hadoop似乎想要一个不结合的JBOD。没有人会为此而扩张...

问题1)JBOD在hadoop世界中的每个人意味着什么，您如何实现？

问题2)是否就像将每个磁盘都装载到不同目录一样简单？

问题3)这是否意味着hadoop可以在JBOD上最好地运行，在JBOD上，每个磁盘都简单地挂载到了不同的目录？

问题4)然后，您只需将hadoop指向那些data.dirs？

问题5)
我看到JBODS有2种方式，要么每个磁盘都进入单独的挂载，要么线性磁盘连接，这可以通过mdadm --linear模式完成，或者lvm我也可以做到，所以我看不出有什么大不了的那...如果是这种情况，那么可以使用mdadm --linear或lvm，因为JBOD人们所指的是磁盘的这种连接，那么这是对“Hadoop”进行“JBOD”或线性连接的最佳方法？

这不是主题，但是有人可以验证这是否正确吗？使用Cow的文件系统(如zfs和btrfs)在写入时会进行复制，这只会减慢hadoop的速度，不仅会因为cowoop的使用浪费了cow的实现。

问题6)为什么COW和RAID之类的东西浪费在hadoop上？
我认为这就像您的系统崩溃了一样，您使用了if来还原它的能力，到您还原系统时，对hdfs进行了太多更改，可能会认为该机器是有故障的，因此最好从头开始重新加入(将其作为新的新数据节点)...或者hadoop系统将如何看到较旧的数据节点？我的猜测是它不会认为它的旧的或新的，甚至是一个datanode，它只会将其视为垃圾... idk ...

问题7)如果hadoop看到一个数据节点从集群上掉下来，然后该数据节点重新联机并且数据稍旧，该怎么办？数据必须多久才存在一个范围？这个话题怎么样？

重新排序问题1至4

我刚刚意识到我的问题很简单，但是我很难解释，我不得不将其分解为4个问题，但听起来仍然很聪明，但我仍然没有找到我想要的答案个人，所以我必须重新询问。.

在纸上，我可以轻松地绘制，也可以使用绘图...我将再次尝试用文字..

如果对我在JBOD问题中询问的内容感到困惑...

**只是想知道每个人在hadoop世界中一直指的是哪种JBOD **

JBOD在hadoop中的定义与在正常世界中不同，我想知道实现hadoop的最佳方法是在jbods(sda + sdb + sdc + sdd)上还是仅将磁盘(sda，sdb， sdc，sdd)

我认为以下图形表示了我要问的最好的

(JBOD方法1)

正常世界:jbod是磁盘的混叠-然后，如果您使用hadoop，则将data.dir(在hdfs虚拟站点所在的位置)覆盖在该磁盘目录中的目录上，所有磁盘也都显示为1。 ..因此，如果您在节点中将sda和sdb和sdc作为数据磁盘，则将使em看起来像是一个entity1(通过主板的硬件或mdadm或lvm)，它是sda和sdb的线性连接，并且sdc。然后，您可以将此entity1挂载到Unix namespace 中的文件夹(如/mnt/jbod/)，然后设置hadoop以在其中运行。

文本摘要:如果磁盘1和disk2和磁盘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 namespace 中将磁盘sda和sdb和sdc挂载到/mnt/a和/mnt/b和/mnt/c ...从网络上看，很多hadoop专家将jbods归类为一堆磁盘，以便统一处理，它们看起来像磁盘，而不是磁盘的连接……然后，我当然可以结合起来，然后通过逻辑卷管理器(lvm)或mdadm(以raid或线性方式，线性首选jbod)......但是...... nah不能将它们组合在一起，因为在hadoop世界中，jbod似乎只是一群坐在它们旁边的磁盘...

如果磁盘1和disk2和磁盘3分别为100gb，200gb和300gb，则分别装入disk1->/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或磁盘分离进行hadoop的最佳实践-根据在线文档，这仍然是jbod？ **

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

Answer 1

我可以尝试回答几个问题-告诉我您有何不同意见。

1.JBOD:只是一堆磁盘；一组驱动器，每个驱动器都可以作为独立驱动器直接访问。
在Hadoop Definitive Guide中，主题为什么不使用RAID？ 表示，RAID读写性能受到阵列中最慢的磁盘的限制。
另外，在使用HDFS的情况下，数据复制发生在位于不同机架中的不同计算机之间。即使机架发生故障，这也可以处理潜在的数据丢失。因此，RAID不是必需的。 Namenode可以使用链接中提到的RAID。

2.是表示在每台计算机(例如/disk1，/disk2，/disk3等)中安装的独立磁盘(JBOD)，但未分区。

3、4和5 阅读附录

6和7。 Check this link，以了解如何进行块复制

评论后的附录:

Q1。每个人都指的是哪种方法是最佳的实践，因为可以结合使用此组合jbod或磁盘分离-根据在线文档，这仍然是jbod？

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

You should also set the dfs.data.dir property, which specifies a list of directories for a datanode to store its blocks. Unlike the namenode, which uses multiple directories for redundancy, a datanode round-robins writes between its storage directories, so for performance you should specify a storage directory for each local disk. Read performance also benefits from having multiple disks for storage, because blocks will be spread across them, and concurrent reads for distinct blocks will be correspondingly spread across disks.

For maximum performance, you should mount storage disks with the noatime option. This setting means that last accessed time information is not written on file reads, which gives significant performance gains.

Q2。为什么LVM不是一个好主意？

Avoid RAID and LVM on TaskTracker and DataNode machines – it generally reduces performance.

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

Check this link代表 提示1 更多详细信息。在某些情况下，运行Hadoop作业时使用LVM的速度较慢。