Впервые в hadoop, установите кластер серверов Debian 3 только для практики.
Я изучал передовые методы работы с hadoop и наткнулся на: JBOD без файловой системы RAID: ext3, ext4, xfs - ничего из того причудливого материала COW, который вы видите с zfs и btrfs
Итак, я задаю эти вопросы ...
Везде, где я читал, JBOD лучше, чем RAID в hadoop, и что лучшими файловыми системами являются xfs, ext3 и ext4. Помимо файловой системы, которая имеет смысл, почему они лучшие ... как вы реализуете этот JBOD? Вы увидите мое замешательство, если выполните поиск в Google самостоятельно, JBOD намекает на линейный придаток или комбинацию всего лишь нескольких дисков, вроде как логический том, по крайней мере, так некоторые люди объясняют это, но, похоже, hasoop хочет Несовместимый JBOD. Ни одно тело не расширяет это ...
- Вопрос 1) Что все в мире Hadoop подразумевают под JBOD и как вы это реализуете?
- Вопрос 2) Все ли так просто, как монтировать каждый диск в отдельный каталог?
- Вопрос 3) Означает ли это, что hadoop лучше всего работает на JBOD, где каждый диск просто монтируется в другой каталог?
Вопрос 4) И тогда вы просто указываете hadoop на эти data.dirs?
Вопрос 5) Я вижу, что JBODS идет двумя путями: либо каждый диск идет на отдельное монтирование, либо линейное объединение дисков, что может быть выполнено в mdadm --linear mode, или lvm, я уверен, может это сделать, поэтому я не вижу большого разобраться с этим ... И если это так, где mdadm --linear или lvm могут использоваться, потому что люди JBOD ссылаются на это объединение дисков, то это лучший способ "JBOD" или линейно объединить диски для хадуп?
Это не по теме, но может ли кто-нибудь проверить, правильно ли это? Файловые системы, которые используют cow, копирование при записи, такие как zfs и btrfs, просто замедляют работу hadoop, но не только то, что реализация cow является пустой тратой с hadoop.
Вопрос 6) Почему COW и такие вещи, как RAID, являются пустой тратой на hadoop? Я вижу это так, как будто ваша система дает сбой, и вы используете право if, чтобы восстановить ее, к тому времени, когда вы восстановите свою систему, в hdfs было так много изменений, что, вероятно, эта машина будет просто считаться неисправной, и было бы лучше воссоедините его с нуля (представьте его как новый новый датанод) ... Или как система hadoop увидит старый датанод? Я предполагаю, что он не будет думать, что это старый или новый или даже датанод, он просто будет рассматривать его как мусор ... Идк ...
Вопрос 7) Что произойдет, если Hadoop обнаружит, что узел данных упал с кластера, а затем узел данных снова подключится к сети с данными, которые немного старше? Есть ли степень, до какого возраста должны быть данные ??? как вообще эта тема?
ОТВЕТЫ НА ВОПРОСЫ 1 - 4
Я только что понял, что мой вопрос настолько прост, но мне так сложно его объяснить, что мне пришлось разделить его на 4 вопроса, и я все еще не получил ответа, который ищу, от того, что звучит как очень умные люди , поэтому я должен спросить иначе ..
На бумаге я мог бы легко или с рисунком ... Попробую еще раз словами ..
Если запутались в том, что я задаю в вопросе JBOD ...
** просто интересно, о каком JBOD все говорят в мире hadoop **
JBOD определяются по-другому с помощью hadoop, чем в обычном мире, и я хочу знать, как лучший способ реализовать hadoop - это объединить jbods (sda + sdb + sdc + sdd) или просто оставить диски в покое (sda, sdb, sdc , SDD)
Я думаю, что приведенное ниже графическое представление лучше всего объясняет, о чем я прошу
(СПОСОБ JBOD 1)
нормальный мир: jbod - это объединение дисков - тогда, если бы вы использовали hadoop, вы бы наложили data.dir (где виртуальные сайты hdfs) на каталог внутри этого объединения дисков, ТАКЖЕ все диски будут отображаться как 1 .. . Итак, если бы у вас были sda, sdb и sdc в качестве дисков данных на вашем узле, вы бы сделали их как некоторый entity1 (либо с оборудованием материнской платы, либо mdadm или lvm), который является линейным объединением sda, sdb и sdc . затем вы монтируете этот объект1 в папку в пространстве имен Unix, например / mnt / jbod /, а затем настраиваете hadoop для работы в нем.
ОБЗОР ТЕКСТА: если каждый диск 1, диск 2 и диск 3 имели размер 100 ГБ, 200 ГБ и 300 ГБ соответственно, то этот jbod был бы большим, а hadoop от этого узла увеличился бы на 600 ГБ.
* 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 мне кажется, что они хотят, чтобы каждый диск был отделен. Поэтому я бы смонтировал диск sda, sdb и sdc в пространстве имен unix в / mnt / a и / mnt / b и / mnt / c ... кажется, из чтения в Интернете многие эксперты hadoop классифицируют jbods как просто связка дисков, чтобы в unix они выглядели как диски, а не как объединение дисков ... и тогда, конечно, я могу объединить их, чтобы стать одним объектом либо с диспетчером логических томов (lvm), либо с mdadm (рейдовым или линейным способом, linear предпочтительнее для jbod) ...... но ...... не давайте не объединять их, потому что в мире хадупов кажется, что jbod - это просто группа дисков, сидящих отдельно друг от друга ...
если каждый диск 1 и disk2 и диск 3 были размером 100 ГБ, 200 ГБ и 300 ГБ соответственно, то каждый монтируемый disk1 -> / mnt / a и disk2 -> / mnt / b и disk3 -> / mnt / c будет каждый размером 100 ГБ и 200 ГБ и 300 ГБ соответственно, а емкость hadoop от этого узла увеличится на 600 ГБ.
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? **
- Оба случая получат hadoop 600 ГБ ... это всего лишь 1. выглядит как concat или один объект, который представляет собой комбинацию всех дисков, что я всегда считал jbod ... Или это будет как 2, где каждый диск в системе монтируется в другой каталог, конечный результат одинаков для емкости hadoop ... просто интересно, лучший ли это способ для производительности
