Временная приостановка работы узлов Hadoop — фоновый кластер Hadoop

Интересно, можно ли установить «фоновый» кластер Hadoop. Я имею в виду, в конце концов, это предназначено для того, чтобы иногда иметь дело с узлами, которые недоступны или медленны.

Итак, предположим, что в каком-то университете есть компьютерный класс. Скажем, 100 ящиков, все с высококлассным настольным оборудованием, гигабитным etherner, возможно, даже с одинаковой установкой программного обеспечения. Линукс здесь тоже очень популярен.

Однако эти 100 коробок, конечно же, предназначены для настольных систем для студентов. Бывают случаи, когда лаборатория будет переполнена, но также бывают случаи, когда лаборатория будет пуста. Пользовательские данные в основном хранятся в центральном хранилище, скажем, в NFS, поэтому локальные диски используются не так часто.

Мне кажется хорошей идеей использовать системы в качестве кластера Hadoop во время их простоя. Простейшей настройкой, конечно же, было бы задание cron запускать кластер ночью и выключать утром. Однако и в течение дня многие компьютеры не будут использоваться.

Однако как бы Hadoop отреагировал, например, на узлы отключаются при входе любого пользователя? Можно ли легко «приостановить» (вытеснить!) узел в hadoop и при необходимости переместить его для замены? В идеале мы бы дали Hadoop возможность отложить вычисления перед приостановкой задачи (также для освобождения памяти). Как бы сделать такую ​​установку? Есть ли способ сообщить Hadoop, что узел будет приостановлен?

Насколько я могу судить, датаноды не должны быть остановлены, и, возможно, необходимо увеличить репликацию, чтобы иметь более 3 копий. С YARN также может быть проблема, заключающаяся в том, что при перемещении трекера задач на произвольный узел он может быть приостановлен в какой-то момент. Но, возможно, можно управлять тем, что есть небольшой набор узлов, который всегда включен и который будет запускать средства отслеживания задач.

Уместно ли просто stop tasktracker или отправить SIGSTOP (затем продолжить с SIGCONT)? Первый, вероятно, даст hadoop возможность отреагировать, второй будет продолжаться быстрее, когда пользователь скоро выйдет из системы (поскольку тогда задание может быть продолжено). Как насчет ПРЯЖИ?


person Has QUIT--Anony-Mousse    schedule 25.09.2012    source источник


Ответы (1)


Прежде всего, hadoop не поддерживает «вытеснение», как вы это описали. Hadoop просто перезапускает задачу, если обнаруживает, что таск-трекер не работает. Итак, в вашем случае, когда пользователь входит в систему, какой-то скрипт просто убивает тасктрекер, а джобтрекер помечает все мапперы/редукторы, которые были запущены на убитом тасктрекере, как FAILED. После этого эти задачи будут перенесены на другие узлы.

Конечно такой сценарий не бесплатный. По задумке, преобразователи и редьюсеры хранят все промежуточные данные на локальных хостах. Более того, редюсеры извлекают данные мапперов напрямую из тасктрекеров, где были выполнены мапперы. Таким образом, когда тасктрекер будет убит, все эти данные будут потеряны. А в случае с мапперами это не большая проблема, маппер обычно работает на относительно небольшом количестве данных (гигабайты?), а вот редюсер пострадает больше. Редюсер запускает перетасовку, что дорого с точки зрения пропускной способности сети и процессора. Если тасктрекер запускает какой-то редьюсер, перезапуск этого редьюсера означает, что все данные должны быть перекачаны еще раз на новый хост. И я припоминаю, что джобтрекер не сразу видит, что тасктрекер умер. Таким образом, убитые задачи не должны перезапускаться немедленно.

Если ваша рабочая нагрузка невелика, узлы данных могут жить вечно, не переводите их в автономный режим, когда пользователь входит в систему. Datanode потребляет небольшой объем памяти (256 МБ должно быть достаточно в случае небольшого объема данных), и если ваша рабочая нагрузка невелика, не потребляйте много процессорного и дискового ввода-вывода.

В заключение, вы можете настроить такую ​​конфигурацию, но не полагайтесь на хорошее и предсказуемое выполнение задания при модерируемых рабочих нагрузках.

person octo    schedule 27.09.2012
comment
Что ж, 100 узлов, которые доступны в 90% случаев, по-прежнему означают, что это дает дополнительные преимущества. Но очевидно, что это не идеальная установка для гарантированного времени отклика. Но, может быть, позволить студентам экспериментировать с ним, не покупая много дополнительного оборудования. - person Has QUIT--Anony-Mousse; 27.09.2012
comment
В случае студенческой игровой площадки эта установка будет работать. Я попытался описать, что будет, если убить тасктрекер. И предлагаю не заморачиваться с NFS, просто не останавливать узлы данных. - person octo; 27.09.2012