Comments 10
Как-то не круто. Если бы вы по итогу сделали контейнеры для docker и завершили статью словами о том, что мол запустите пару команд docker и мини кластер готов, то вот это было очень круто. А так нет.
PS Или для vagrant.
PS Или для vagrant.
И зачем нам очередной оферхед от docker?
Особенно если учесть, что для разделения ресурсов внутри ноды cgroup можно использовать (в стандартной поставке уже все идет, 1 параметр в конфигах врубает его).
vargant это вообще в другую степь вас занесло.
для одного клика уже давно придуман Whirr: whirr.apache.org/
для тех кто хочет на голом железе разворачивать более удобным будет: cloudera manager & apache ambari
Особенно если учесть, что для разделения ресурсов внутри ноды cgroup можно использовать (в стандартной поставке уже все идет, 1 параметр в конфигах врубает его).
vargant это вообще в другую степь вас занесло.
для одного клика уже давно придуман Whirr: whirr.apache.org/
для тех кто хочет на голом железе разворачивать более удобным будет: cloudera manager & apache ambari
За тем, что статья о том, как развернуть «мини кластер» и, как я понял по словам «небольшого кластера Hadoop для опытов.… Все узлы будут работать на VirtualBox.», то кластер создается для разработки, а не продакшн деплоймента на серверы. Поэтому vagrant в моем комментарии таки к месту, да и любые другие технологии, которые позволяют развернуть (и убить тоже) все это дело быстро.
Для «мини кластер» имеется demo vm: скачал, запустил, тестируй
На данный момент это идеальный вариант для тех кто хочет просто посмотреть на свежую версию хадупа и пощупать ее.
www.cloudera.com/content/cloudera-content/cloudera-docs/DemoVMs/Cloudera-QuickStart-VM/cloudera_quickstart_vm.html
можно выбрать kvm,virtualbox,vmware образы.
>> то кластер создается для разработки
Каждый кто работал с хадупом знает, что кластер для разработки и для продакшена должен иметь хоть немного похожие машинки, в противном случае про разные извращения с оптимизацией придется забыть, в идеале это 2 одинаковых кластера, в худшем случае у вас такие же машинки, но их меньше. Кластер в виртуалбоксах на одной машине это из разряда фантастики, в этом случае 1 demo-vm c максимум ресурсов.
На данный момент это идеальный вариант для тех кто хочет просто посмотреть на свежую версию хадупа и пощупать ее.
www.cloudera.com/content/cloudera-content/cloudera-docs/DemoVMs/Cloudera-QuickStart-VM/cloudera_quickstart_vm.html
можно выбрать kvm,virtualbox,vmware образы.
>> то кластер создается для разработки
Каждый кто работал с хадупом знает, что кластер для разработки и для продакшена должен иметь хоть немного похожие машинки, в противном случае про разные извращения с оптимизацией придется забыть, в идеале это 2 одинаковых кластера, в худшем случае у вас такие же машинки, но их меньше. Кластер в виртуалбоксах на одной машине это из разряда фантастики, в этом случае 1 demo-vm c максимум ресурсов.
Я нашел вот это: github.com/Cascading/vagrant-cascading-hadoop-cluster, правда, пока не пробовал
Не советуйте использовать /usr/local/package_name там, где должно быть /opt/package_name. /usr/local повторяет структуру директорий /usr, а /opt предназначено как раз для ПО, которое тащит свою собственную иерархию папок с bin, sbin, lib итд.
Несколько замечаний:
1) Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X)…
Вы наверное решили так пошутить?
www.cloudera.com/content/support/en/documentation.html#Documentation-CDH4Documentation
hortonworks.com/products/hdp-2/#documentation
что клоудера уже давно hdfs 2.0 использует, а недавно и yarn по умолчанию включила,
что хортоны свою hdp-2.0 строят на второй ветке.
Пускай вас не пугает некоторая мешанина в версиях, обе эти компании являются наиболее активными разработчиками хадупа и в свои продукты бекпортят патчи которые шли еще только в альфу 2.x ветки. Если патч стабилен и является bugfix, то нечего ждать выхода 2.2.0, у клиентов проблемы и надо их решать.
2) Здесь параметр dfs.replication задает количество реплик, которые будут хранится на файловой системе. Оно не может быть больше, чем количество узлов в кластере.
да без проблем можно поставить сколько угодно много, например при создании har архивов по умолчанию в коде явно забито 20 реплик на индекс. Максимум что вы получите если узлов меньше чем уровень репликации, так это сообщение о том что некоторые блоки не дотягивают то установленного уровня репликации.
3) На каждом узле кластера изменим значения параметра dfs.replication в etc/hadoop/hdfs-site.xml
если вы не собираетесь запускать (именно из консоли конкретной машинки) задачи с тех машинок, то параметр бесполезен, так как нужен в первую очередь для namenode.
p.s. cloudera & hortonwork уже давно предоставляют как rpm со своими репозиториями для быстрого разворачивания кластера, так и автоматические тулзы cloudera manager и ambari соответсвенно. Использование ванильной сборки хадупа больше смахивает на мазохизм, так как крупные компании как раз и занимаются тем, что берут определенную версию и бекпортируют патчи из свежих разработок, а дальше предоставляют определенные гарантии, что ближайшие пару лет они будут вливать security fix в эти сборки и не менять api. Использую ванильную сборку вы получаете достаточно нестабильный продукт и полное отсутсвие поддержки, для примера оочень многие разработчики уже переключились на ветку 3.x, и патчи в 2.2.x попадут лишь очень избирательно, даже которые относятся к bugfix.
1) Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X)…
Вы наверное решили так пошутить?
www.cloudera.com/content/support/en/documentation.html#Documentation-CDH4Documentation
hortonworks.com/products/hdp-2/#documentation
что клоудера уже давно hdfs 2.0 использует, а недавно и yarn по умолчанию включила,
что хортоны свою hdp-2.0 строят на второй ветке.
Пускай вас не пугает некоторая мешанина в версиях, обе эти компании являются наиболее активными разработчиками хадупа и в свои продукты бекпортят патчи которые шли еще только в альфу 2.x ветки. Если патч стабилен и является bugfix, то нечего ждать выхода 2.2.0, у клиентов проблемы и надо их решать.
2) Здесь параметр dfs.replication задает количество реплик, которые будут хранится на файловой системе. Оно не может быть больше, чем количество узлов в кластере.
да без проблем можно поставить сколько угодно много, например при создании har архивов по умолчанию в коде явно забито 20 реплик на индекс. Максимум что вы получите если узлов меньше чем уровень репликации, так это сообщение о том что некоторые блоки не дотягивают то установленного уровня репликации.
3) На каждом узле кластера изменим значения параметра dfs.replication в etc/hadoop/hdfs-site.xml
если вы не собираетесь запускать (именно из консоли конкретной машинки) задачи с тех машинок, то параметр бесполезен, так как нужен в первую очередь для namenode.
p.s. cloudera & hortonwork уже давно предоставляют как rpm со своими репозиториями для быстрого разворачивания кластера, так и автоматические тулзы cloudera manager и ambari соответсвенно. Использование ванильной сборки хадупа больше смахивает на мазохизм, так как крупные компании как раз и занимаются тем, что берут определенную версию и бекпортируют патчи из свежих разработок, а дальше предоставляют определенные гарантии, что ближайшие пару лет они будут вливать security fix в эти сборки и не менять api. Использую ванильную сборку вы получаете достаточно нестабильный продукт и полное отсутсвие поддержки, для примера оочень многие разработчики уже переключились на ветку 3.x, и патчи в 2.2.x попадут лишь очень избирательно, даже которые относятся к bugfix.
Спасибо за замечания. Очень полезная информация про dfs.replication.
Про cloudera и hortonwork я, конечно, знал. Ясное дело, что держать продакшн лучше на поддерживаемых решениях.
В этой статье я просто захотел описать простое how-to, чтобы всегда можно было поднять свой hadoop и иметь представление о том, что же там внутри.
Про cloudera и hortonwork я, конечно, знал. Ясное дело, что держать продакшн лучше на поддерживаемых решениях.
В этой статье я просто захотел описать простое how-to, чтобы всегда можно было поднять свой hadoop и иметь представление о том, что же там внутри.
Всем добрый день. Предлагаю свою инструкцию по установке HDP 2.2 с помощью Ambari:
ihorbobak.com/index.php/2015/05/06/installing-hadoop-using-ambari-server
ihorbobak.com/index.php/2015/05/06/installing-hadoop-using-ambari-server
Немного для тех кто как я решил повторить шаги:
1) path пришлось сделать глобальным, в /etc/environment (хотя это возможно загоны моей системы)
2) в hdfs-site.xml необходимо убрать в пути «file:»
3) при создании файловой копи-паст лучше не делать, т.к. "–" приведенный в примере это ни разу не "-", который должен быть
1) path пришлось сделать глобальным, в /etc/environment (хотя это возможно загоны моей системы)
2) в hdfs-site.xml необходимо убрать в пути «file:»
3) при создании файловой копи-паст лучше не делать, т.к. "–" приведенный в примере это ни разу не "-", который должен быть
Sign up to leave a comment.
Настройка маленького кластера Hadoop 2.2.0 с нуля