Что за JBOD в hadoop? и корова с hadoop?
Новичок в hadoop, только настройте кластер серверов 3 debian для практики.
Я изучал лучшие практики по hadoop и наткнулся на: JBOD без файловой системы RAID: ext3, ext4, xfs - ни одна из тех причудливых COW-вещей, которые вы видите с zfs и btrfs
Поэтому я поднимаю эти вопросы...
Везде, где я читаю, JBOD лучше, чем RAID в hadoop, и что лучшими файловыми системами являются xfs, ext3 и ext4. Помимо файловой системы, которая полностью имеет смысл, почему они лучшие... как вы реализуете этот JBOD? Вы увидите мое замешательство, если вы выполните поиск в Google самостоятельно, JBOD ссылается на линейный отросток или комбинацию всего лишь нескольких дисков, вроде логического тома, по крайней мере, так некоторые объясняют это, но, похоже, hadoop хочет JBOD, который не сочетается. Ни одно тело не расширяется на этом...
- Вопрос 1) Что все в мире hadoop подразумевают под JBOD и как вы это реализуете?
- Вопрос 2) Это так же просто, как монтировать каждый диск в другой каталог - это все?
- Вопрос 3) Означает ли это, что hadoop лучше всего работает на JBOD, где каждый диск просто монтируется в другой каталог?
Вопрос 4) И тогда вы просто указываете на этот файл data.dirs?
Вопрос 5) Я вижу, что JBODS идет двумя путями, либо каждый диск собирается на отдельное монтирование, либо на линейное соединение дисков, что может быть выполнено в режиме mdadm --linear, или lvm, я готов поспорить, что это тоже возможно, поэтому я не вижу большого иметь дело с этим... И если это так, где mdadm --linear или lvm могут быть использованы, потому что люди JBOD обращаются к этому конкатату дисков, тогда это лучший способ для "JBOD" или линейно конкатативных дисков для Hadoop?
Это не по теме, но может ли кто-нибудь проверить, правильно ли это? Файловые системы, использующие корову, копирование при записи, такие как zfs и btrfs, просто замедляют hadoop, но не только то, что реализация коровы - пустая трата с hadoop.
Вопрос 6) Почему COW и такие вещи, как RAID, бесполезны? Я вижу это так, как будто ваша система дает сбой, и вы пользуетесь возможностью восстановления, если к тому времени, когда вы восстановили свою систему, в hdf было так много изменений, что, вероятно, эта машина будет считаться неисправной, и было бы лучше присоединиться к нему с нуля (представить его как новую новую датододу)... Или как система hadoop увидит более старую датододу? Я предполагаю, что он не будет думать, что он старый или новый, или даже датодат, он просто увидит это как мусор... Ид...
Вопрос 7) Что произойдет, если hadoop увидит, что катод данных упал с кластера, а затем он возвращается в онлайн с данными немного старше? Есть ли степень того, сколько лет должны быть данные??? как эта тема?
ВОПРОСЫ ДЛЯ ЗАДАЧИ 1 ЧЕТ 4
Я только что понял, что мой вопрос настолько прост, но мне так трудно объяснить его, что мне пришлось разделить его на 4 вопроса, и я так и не получил ответ, который ищу, от того, что звучит как очень умные люди так что я должен переспросить по-другому..
На бумаге я мог легко или с рисунком... Я попытаюсь словами снова...
Если запутался в том, что я спрашиваю в вопросе JBOD...
** просто интересно, о каком JBOD все ссылаются в мире адопов, все **
JBOD определяются по-разному с помощью hadoop, чем в обычном мире, и я хочу знать, как наилучшим способом реализовать hadoop является использование jbods (sda + sdb + sdc + sdd) или просто оставить диски в покое (sda, sdb, sdc), SDD)
Я думаю, что графическое представление ниже объясняет, что я спрашиваю лучше всего
(СПОСОБ JBOD 1)
нормальный мир: jbod - это конкатенация дисков - тогда, если бы вы использовали hadoop, вы наложили бы data.dir (где hdfs virtualy sites) на каталог внутри этого конкатена дисков, ТАКЖЕ все диски выглядели бы как 1.. Таким образом, если бы вы использовали sda, sdb и sdc в качестве дисков данных в вашем узле, вы бы заставили их выглядеть как сущность 1 (с оборудованием материнской платы, или mdadm, или lvm), представляющую собой линейный конкат sda, sdb и sdc., Затем вы должны смонтировать этот entity1 в папку в пространстве имен Unix, такую как / mnt / jbod /, а затем настроить hadoop для запуска в нем.
РЕЗЮМЕ ТЕКСТА: если бы диск 1 и диск 2 и диск 3 были каждый по 100 ГБ и 200 ГБ и 300 ГБ соответственно, то этот jbod был бы 600 ГБ, а 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 классифицируют jbod просто как связка дисков, чтобы в unix они выглядели как диски, а не как конкат дисков... и тогда, конечно, я могу объединиться, чтобы стать одной сущностью либо с менеджером логических томов (lvm), либо с mdadm (в рейдовом или линейном режиме, линейный предпочтительнее для jbod)...... но...... нет, давайте не будем объединять их, потому что кажется, что в мире hadoop jbod - это просто набор дисков, которые сидят сами по себе...
если бы диск 1 и диск2 и диск 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... просто интересно, если это лучший способ для производительности
2 ответа
Я могу попытаться ответить на несколько вопросов - скажите мне, где вы не согласны.
1.JBOD: просто куча дисков; массив дисков, каждый из которых доступен напрямую как независимый диск. Из Hadoop Definitive Guide, тема Почему бы не использовать RAID? говорит, что производительность чтения и записи RAID ограничена самым медленным диском в массиве. Кроме того, в случае HDFS репликация данных происходит на разных компьютерах, находящихся в разных стойках. Это обрабатывает потенциальную потерю данных, даже если стойка выходит из строя. Итак, RAID не так уж и необходим. Namenode может использовать RAID, как указано в ссылке.
2.Да Это означает, что независимые диски (JBOD) монтируются на каждой из машин (например, /disk1, /disk2, /disk3 и т. Д.), Но не разбиваются на разделы.
3, 4 и 5 Читать Приложение
6 & 7. Проверьте эту ссылку, чтобы увидеть, как происходит репликация блоков
Приложение после комментария:
Q1. Какой метод все предпочитают использовать, это ЛУЧШАЯ ПРАКТИКА для hadoop с этой комбинацией jbod или разделением дисков - которая по-прежнему также является jbod согласно онлайн-документации?
Возможный ответ: из Hadoop Definitive Guide -
Вам также следует установить свойство dfs.data.dir, которое задает список каталогов для датоды, в которой хранятся его блоки. В отличие от namenode, который использует несколько каталогов для обеспечения избыточности, циклическая перестановка данных датодает записи между его каталогами хранения, поэтому для производительности вы должны указать каталог хранения для каждого локального диска. Производительность чтения также выигрывает от наличия нескольких дисков для хранения, поскольку блоки будут распределяться по ним, а параллельные чтения для отдельных блоков будут соответственно распределяться по дискам.
Для максимальной производительности вы должны монтировать диски хранения с опцией noatime. Этот параметр означает, что информация о времени последнего доступа не записывается при чтении файлов, что дает значительный прирост производительности.
Q2. Почему LVM не очень хорошая идея?
Избегайте RAID и LVM на машинах TaskTracker и DataNode - это обычно снижает производительность.
Это связано с тем, что LVM создает логический слой над отдельными подключенными дисками на машине.
Проверьте эту ссылку для СОВЕТА 1 более подробную информацию. В некоторых случаях использование LVM выполнялось медленно при выполнении заданий Hadoop.
Я опаздываю на вечеринку, но, может быть, я могу вмешаться:
JBOD
Вопрос 1) Что все в мире hadoop подразумевают под JBOD и как вы это реализуете?
Просто набор дисков... вы просто форматируете весь диск и включаете его в "hdfs-site.xml". and mapred-site.xml or yarn-site-xml` на датоде. Hadoop заботится о распределении блоков по дискам.
Вопрос 2) Это так же просто, как монтировать каждый диск в другой каталог - это все?
Да.
Вопрос 3) Означает ли это, что hadoop лучше всего работает на JBOD, где каждый диск просто монтируется в другой каталог?
Да. Hadoop выполняет контрольное суммирование данных и периодически проверяет эти контрольные суммы.
Вопрос 4) И тогда вы просто указываете на этот файл data.dirs?
Именно так. Но есть каталоги для хранения данных (HDFS) и вычислений (MapReduce, YARN, ..), для которых можно настроить разные каталоги и диски для определенных задач.
Вопрос 5) Я вижу, что JBODS идет двумя путями: либо каждый диск собирается в отдельное монтирование, либо линейное соединение дисков, что может быть выполнено в режиме mdadm --linear, или lvm, я готов поспорить, что это тоже возможно, поэтому я не вижу В этом дело... И если это так, то где mdadm --linear или lvm могут быть использованы, потому что люди JBOD обращаются к этому конкатату дисков, тогда это лучший способ использовать JBOD или линейно конкатные диски для Hadoop?
Проблема в неисправных дисках. Если вы делаете это просто и монтируете каждый диск за раз, вам просто нужно заменить этот диск. Если вы используете mdadm или LVM в конфигурации ja JBOD, которую вы имеете, склонны к потере большего количества данных в случае, если диск умирает, так как конфигурация с чередованием или concat может не пережить сбой диска. Поскольку данные для большего количества блоков распределяются по нескольким дискам.
Вопрос 6) Почему COW и такие вещи, как RAID, бесполезны? Я вижу это так, как будто ваша система дает сбой, и вы пользуетесь возможностью восстановления, если к тому времени, когда вы восстановили свою систему, в hdf было так много изменений, что, вероятно, эта машина будет считаться неисправной, и было бы лучше присоединиться к нему с нуля (представить его как новую новую датододу)... Или как система hadoop увидит более старую датододу? Я предполагаю, что он не будет думать, что он старый или новый, или даже датодат, он просто увидит это как мусор... Ид...
HDFS - это грамотно отдельный слой поверх вашей родной файловой системы. Ожидаются сбои диска, поэтому все блоки данных реплицируются как минимум 3 раза на нескольких машинах. HDFS также выполняет свою собственную контрольную сумму, поэтому, если контрольная сумма блока не совпадает, используется реплика этого блока, и поврежденный блок будет удален HDFS.
Поэтому в теории нет смысла использовать RAID или COW для накопителей Hadoop.
Это может иметь смысл, если вам приходится иметь дело с неисправными дисками, которые нельзя заменить немедленно.
Вопрос 7) Что произойдет, если hadoop увидит, что катод данных упал с кластера, а затем он возвращается в онлайн с данными немного старше? Есть ли степень того, сколько лет должны быть данные??? как эта тема?
NameNode имеет список блоков и их местоположений на датоделях. Каждый блок имеет контрольную сумму и местоположение. Если датодода падает в кластере, то наменоде копирует блоки этого датодода в другие датододы.
Если старый датодет подключается к сети, он отправляет свой список блоков в NameNode и в зависимости от того, сколько блоков уже реплицировано или нет, он удалит ненужные блоки в этом датоделе.
Возраст данных не важен, это только о блоках. Если NameNode по-прежнему поддерживает блоки, и у датодета есть они, они будут использованы снова.
ZFS / Btrfs / КПС
Теоретически они дополнительные функции, которые предоставляют эти файловые системы, не требуются для Hadoop. Однако, поскольку вы обычно используете дешевые и огромные 4 ТБ + настольные накопители для датоданных, вы можете столкнуться с проблемами, если эти диски начнут выходить из строя.
ext4 перемонтирует себя только для чтения при сбое, и в этот момент вы увидите, как диск выпадает из HDFS на датодете, если он настроен на потерю дисков, или вы увидите, как диск данных умирает, если сбои диска недопустимы. Это может быть проблемой, потому что современные накопители часто имеют плохие сектора, хотя по большей части все еще работают нормально, и требуется интенсивная работа с fsck для этих дисков и перезапуск датодета.
Другая проблема - это вычисления через YARN/MapReduce. Они также записывают промежуточные данные на диски, и если эти данные повреждены или не могут быть записаны, вы столкнетесь с ошибками. Я не уверен, что YARN / MapReduce также проверяет их временные файлы - я думаю, что это реализовано через.
ZFS и btrfs обеспечивают некоторую устойчивость к этим ошибкам на современных дисках, поскольку они лучше справляются с поврежденными метаданными и позволяют избежать длительных fsck проверки из-за внутренней контрольной суммы.
Я использую кластер Hadoop на ZFS (только JBOD с LZ4) с большим количеством дисков, на которых есть несколько поврежденных секторов, которые не имеют гарантии, но все еще работают хорошо, и работают нормально, несмотря на эти ошибки.
Если вы можете заменить неисправные диски мгновенно, это не имеет большого значения. Если вам нужно жить с частично сломанными дисками, ZFS/btrfs купит вас некоторое время, прежде чем заменять диски.
COW не нужен, потому что Hadoop заботится о репликации и безопасности. Сжатие может быть полезно, если вы храните данные без сжатия в кластере. LZ4 в ZFS не должен обеспечивать снижение производительности и может ускорять последовательное чтение (как это делают HDFS и MapReduce).
Спектакль
Случай с RAID заключается в том, что, по крайней мере, MapReduce реализует что-то похожее. HDFS может одновременно выполнять чтение и запись на все диски, и обычно выполняется несколько заданий сопоставления и сокращения, которые могут использовать целый диск для записи и чтения своих данных.
Если вы поместите RAID или чередование ниже Hadoop, все эти задания должны поставить в очередь свои операции чтения и записи на один контроллер RAID, и в целом это, вероятно, будет медленнее.
В зависимости от ваших заданий может иметь смысл использовать что-то вроде RAID-0 для пар дисков, но сначала убедитесь, что последовательное чтение или запись действительно является узким местом для вашей работы (а не сети, репликации HDFS, ЦП и т. Д.).) но сначала убедитесь, что то, что вы делаете, стоит работы и хлопот.