use*_*961 6 raid hadoop zfs ext3
hadoop的新手,只设置了3个debian服务器集群进行练习.
我正在研究hadoop的最佳实践并遇到过:JBOD没有RAID文件系统:ext3,ext4,xfs - 没有你用zfs和btrfs看到的那些花哨的COW东西
所以我提出这些问题......
我读到JBOD的地方比hadoop中的RAID要好,而且最好的文件系统是xfs,ext3和ext4.除了完全有意义的文件系统之外,为什么那些是最好的...你如何实现这个JBOD？你会看到我的混乱,如果你自己搜索谷歌,JBOD暗示一个线性附属物或只是一堆磁盘的组合,有点像一个逻辑卷,至少这是一些人如何解释它,但hadoop似乎想要一个JBOD没有结合.没有身体扩展...
问题4)然后你只是将hadoop指向那些data.dirs？
问题5)我看到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看到一个从集群上掉下来的数据节点,然后datanode重新上线,数据稍微老一点,会发生什么？数据的年龄有多大？这个话题怎么样？
我刚刚意识到我的问题很简单,但我很难解释它我必须把它分成4个问题,我仍然没有得到我正在寻找的答案,听起来像是非常聪明的人,所以我必须重新提出不同的问题..
在纸面上,我可以很容易地或用绘图......我会再次尝试用词.
如果对我在JBOD问题中提出的问题感到困惑......
**只是想知道每个人在hadoop世界中指的是什么样的JBOD都是**
在正常的世界中,JBOD与hadoop的定义不同,我想知道如何在jbods(sda + sdb + sdc + sdd)的concat上实现hadoop的最佳方法,或者只留下磁盘(sda,sdb,sdc) ,SDD)
我认为下面的图形表示解释了我最好的问题
普通世界:jbod是磁盘的连接 - 然后如果你要使用hadoop,你会将data.dir(其中hdfs virtualy sites)覆盖到这个磁盘内的目录中,所有磁盘都会显示为1 ..所以如果你的节点中有sda和sdb以及sdc作为你的数据磁盘,那么你会把它看作是某个entity1(主板的硬件或mdadm或lvm),这是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
..另一个观点是这个......
在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大,则每个挂载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..
**每个人指的是哪种方法最好的做法是hadoop这个组合jbod或分离磁盘 - 根据在线文档,这仍然是一个jbod？**
我可以尝试回答几个问题 - 告诉我你不同意的地方.
1.JBOD:只是一堆磁盘; 一组驱动器,每个驱动器都可以作为独立驱动器直接访问.从Hadoop权威指南,主题为什么不使用RAID？,说RAID读写性能受阵列中最慢的磁盘限制.此外,在HDFS的情况下,数据的复制发生在驻留在不同机架中的不同机器上.即使机架出现故障,也可以处理潜在的数据丢失.因此,RAID不是必需的.Namenode虽然可以使用链接中提到的RAID.
2.是这意味着安装在每台机器中的独立磁盘(JBOD)(例如/ disk1,/ disk2,/ disk3等)但未分区.
3,4和5阅读附录
6和7. 检查此链接以查看块的复制是如何发生的
评论后的附录:
Q1.每个人都提到哪种方法是最好的做法,对于hadoop这个组合jbod或磁盘的分离 - 根据在线文档,这仍然是一个jbod？
可能的答案:来自Hadoop权威指南 -
您还应该设置dfs.data.dir属性,该属性指定用于存储其块的datanode的目录列表.与使用多个目录进行冗余的namenode不同,datanode 在其存储目录之间进行循环写操作,因此为了 提高性能,应为每个本地磁盘指定一个存储目录.读取性能也有利于存储多个磁盘,因为块将分布在它们之间,并且不同块的并发读取将相应地分布在磁盘上.
为获得最佳性能,您应使用noatime选项安装存储磁盘.此设置意味着上次访问的时间信息不会写入文件读取,从而显着提高性能.
Q2.为什么LVM不是个好主意？
避免在TaskTracker和DataNode机器上使用RAID和LVM - 它通常会降低性能.
这是因为LVM在计算机中的各个已装入磁盘上创建逻辑层.
请查看此链接以获取提示1更多详细信息.在运行Hadoop作业时,使用LVM的用例很慢.
我参加聚会迟到了，但也许我可以插一句：
问题 1）hadoop 世界中的每个人都对 JBOD 意味着什么，你是如何实现的？
只是一堆磁盘……您只需格式化整个磁盘并将其包含在数据节点上的“hdfs-site.xml andmapred-site.xml oryarn-site-xml”中。Hadoop 负责跨磁盘分配块。
问题2）是否像将每个磁盘安装到不同目录一样简单？
是的。
问题 3) 这是否意味着 hadoop 在 JBOD 上运行得最好，其中每个磁盘都只是挂载到不同的目录？
是的。Hadoop 对数据进行校验和并定期验证这些校验和。
问题 4）然后你只是将 hadoop 指向那些 data.dirs？
确切地。但是有用于数据存储 (HDFS) 和计算（MapReduce、YARN、..）的目录，您可以为某些任务配置不同的目录和磁盘。
问题 5）我看到 JBODS 有 2 种方式，每个磁盘都转到单独的挂载，或者磁盘的线性连接，这可以完成 mdadm --linear 模式，或者 lvm 我敢打赌我也可以这样做，所以我看不到大不了...如果是这样的话，可以使用 mdadm --linear 或 lvm 因为 JBOD 人们所指的是这种磁盘连接，那么这是“JBOD”或线性连接磁盘的最佳方式对于hadoop？
问题是有故障的磁盘。如果您保持简单并且一次只挂载每个磁盘，则只需更换该磁盘。如果您mdadm在 ja JBOD 配置中使用或 LVM，您很容易丢失更多数据，以防磁盘死机，因为条带或连接配置可能无法在磁盘故障中幸存下来。由于更多块的数据分布在多个磁盘上。
问题 6) 为什么 COW 和 RAID 之类的东西在 hadoop 上是一种浪费？我认为就好像你的系统崩溃了，你用 if 来恢复它，当你恢复系统时，hdfs 已经发生了很多变化，它可能只会认为那台机器有故障，最好是从头开始重新加入它（将它作为一个新的数据节点）......或者 hadoop 系统将如何看到旧的数据节点？我的猜测是它不会认为它是旧的或新的，甚至是数据节点，它只会将其视为垃圾...... Idk......
HDFS 是原生文件系统之上的一个完全独立的层。磁盘故障是意料之中的，这就是为什么所有数据块在多台机器上至少复制 3 次的原因。HDFS 还进行自己的校验和，因此如果块的校验和不匹配，则使用该块的副本，并且 HDFS 将删除损坏的块。
所以理论上对 Hadoop 驱动器使用 RAID 或 COW 是没有意义的。
如果您必须处理无法立即更换的有故障的磁盘，这将是有意义的。
问题 7) 如果 hadoop 看到一个 datanode 从集群中掉下来，然后 datanode 以稍微旧的数据重新上线，会发生什么？数据必须有多大程度？？？？这个题目怎么样？
NameNode 有一个块列表及其在数据节点上的位置。每个块都有一个校验和和位置。如果集群中的数据节点出现故障，名称节点会将此数据节点的块复制到其他数据节点。
如果一个较旧的数据节点上线，它会将它的块列表发送到 NameNode，并且根据已经复制的块数量，它将删除该数据节点上不需要的块。
数据的年龄并不重要，它只与块有关。如果 NameNode 仍然维护这些块并且 datanode 拥有它们，它们将再次被使用。
理论上，Hadoop 不需要这些文件系统提供的附加功能。但是，由于您通常将便宜且巨大的 4TB+ 桌面驱动器用于数据节点，如果这些磁盘开始出现故障，您可能会遇到问题。
ext4 在发生故障时以只读方式重新挂载，此时您会看到磁盘从数据节点上的 HDFS 中脱落，它被配置为松动驱动器，或者如果不允许出现磁盘故障，您将看到数据节点死亡。这可能是一个问题，因为现代驱动器通常会出现一些坏扇区，但在大多数情况下仍然可以正常运行，并且 fsck 磁盘并重新启动 datanode 是一项密集的工作。
另一个问题是通过 YARN/MapReduce 进行计算。这些也会在磁盘上写入中间数据，如果这些数据被损坏或无法写入，您将遇到错误。我不确定 YARN/MapReduce 是否也校验它们的临时文件 - 我认为它是通过实现的。
ZFS 和 btrfs 为现代驱动器上的此错误提供了一些弹性，因为它们能够更好地处理损坏的元数据并避免fsck由于内部校验和而导致的冗长检查。
我正在 ZFS 上运行一个 Hadoop 集群（只是带有 LZ4 的 JBOD），其中有很多磁盘显示出一些坏扇区，这些磁盘已经超出保修期，但仍然表现良好，尽管有这些错误，但它仍能正常工作。
如果您可以立即更换有故障的磁盘，那就没什么关系了。如果您需要忍受部分损坏的磁盘，ZFS/btrfs 会在您更换磁盘之前为您争取一些时间。
不需要 COW，因为 Hadoop 负责复制和安全。如果您将未压缩的数据存储在集群上，则压缩会很有用。ZFS 中的 LZ4 不应该提供性能损失，并且可以加速顺序读取（就像 HDFS 和 MapReduce 那样）。
反对 RAID 的情况是至少 MapReduce 正在实现类似的东西。 HDFS 可以同时读取和写入所有磁盘，并且通常运行多个映射和减少作业，可以使用整个磁盘来写入和读取其数据。
如果您将 RAID 或条带化置于 Hadoop 之下，则这些作业都必须将它们的读取和写入排入单个 RAID 控制器的队列中，总体而言它可能会变慢。
根据您的工作，对磁盘对使用 RAID-0 之类的东西是有意义的，但请务必首先验证顺序读取或写入确实是您工作的瓶颈（而不是网络、HDFS 复制、CPU 等）。 ) 但首先要确保你正在做的事情值得付出努力和麻烦。
| 归档时间： |
|
| 查看次数： |
4788 次 |
| 最近记录： |