Блог

Я новичок в hadoop, поэтому у меня есть некоторые сомнения. Если главный узел выходит из строя, что произошло с кластером hadoop? Можем ли мы восстановить этот узел без каких-либо потерь? Можно ли сохранить вторичный главный узел для автоматического переключения на главный при сбое текущего?

У нас есть резервная копия namenode (вторичный namenode), поэтому мы можем восстановить namenode из вторичного namenode при сбое. Таким образом, как мы можем восстановить данные в datanode при сбое datanode? Вторичный namenode — это резервная копия namenode, только не в datenode, верно? Если узел выходит из строя до завершения задания, поэтому в job tracker есть ожидающее задание, это задание продолжается или перезапускается с первого в свободном узле?

Как мы можем восстановить все данные кластера, если что-нибудь случится?

И мой последний вопрос, можем ли мы использовать программу C в Mapreduce (например, пузырьковую сортировку в mapreduce)?

Заранее спасибо

Хотя уже слишком поздно отвечать на ваш вопрос, но это может помочь другим..

Прежде всего позвольте мне познакомить вас с узлом Secondary Name:

Он содержит изображение пространства имен, резервное копирование файлов журнала редактирования за последний час (настраивается). И его работа заключается в объединении последнего имени узла NameSpaceImage и редактировании файлов журналов для загрузки обратно в Name Node в качестве замены старого. Наличие вторичного NN в кластере не является обязательным.

Теперь перейдем к вашим проблемам..

• Если главный узел выходит из строя, что произошло с кластером hadoop?

Поддерживая ответ Frail, да, hadoop имеет единую точку отказа, поэтому вся ваша текущая задача, такая как Map-Reduce или любая другая, использующая сбойный главный узел, остановится. Весь кластер, включая клиент, перестанет работать.

• Можем ли мы восстановить этот узел без каких-либо потерь?

Это гипотетически, без потерь это наименее возможно, так как будут потеряны все данные (блочные отчеты), которые были отправлены узлами данных на узел имен после последнего резервного копирования, выполненного вторичным узлом имен. Почему я упомянул меньше всего, потому что, если узел name выходит из строя сразу после успешного резервного копирования, выполняемого вторичным узлом name, он находится в безопасном состоянии.

• Можно ли сохранить вторичный главный узел для автоматического переключения на главный при сбое текущего?

Это просто возможно администратором (пользователем). И чтобы переключить его автоматически, вам нужно написать собственный код из кластера, код для мониторинга кластера, который быстро настроит узел дополнительного имени и перезапустит кластер с новым адресом узла имени.

• У нас есть резервная копия namenode (вторичный namenode), поэтому мы можем восстановить namenode из вторичного namenode при сбое. Таким образом, как мы можем восстановить данные в datanode при сбое datanode?

Речь идет о факторе репликации, у нас есть 3 (по умолчанию, как лучшая практика, настраиваемые) реплики каждого файлового блока в разных узлах данных. Таким образом, в случае сбоя на данный момент у нас есть 2 резервных узла данных. Более поздний узел Name создаст еще одну реплику данных, содержащихся в сбойном узле данных.

• Вторичный namenode — это резервная копия namenode, только не в datenode, верно?

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

• Если узел выходит из строя до завершения задания, поэтому в job tracker есть ожидающее задание, это задание продолжается или перезапускается с первого в свободном узле?

HDFS принудительно попытается продолжить задание. Но опять же это зависит от фактора репликации, осведомленности о стойке и других настроек, сделанных администратором. Но если следовать рекомендациям Hadoop в отношении HDFS, то сбой не произойдет. JobTracker получит реплицированный адрес узла для продолжения.

• Как мы можем восстановить все данные кластера, если что-нибудь случится?

Перезапустив его.

• И мой последний вопрос, можем ли мы использовать программу C в Mapreduce (например, пузырьковую сортировку в mapreduce)?

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

Я просто попробовал. Надеюсь, это поможет вам, а также другим.

* Предложения / улучшения приветствуются.*

В настоящее время кластер hadoop имеет единственную точку отказа, которая является namenode.

И о вторичном узле isssue (из apache wiki) :

Термин «вторичный узел имени» несколько вводит в заблуждение. Это не узел имени в том смысле, что узлы данных не могут подключаться к вторичному узлу имени и ни в коем случае не могут заменить основной узел имени в случае его сбоя.

Единственная цель вторичного узла name — выполнять периодические контрольные точки. Вторичный узел имени периодически загружает текущее изображение узла имени и редактирует файлы журнала, объединяет их в новое изображение и загружает новое изображение обратно на (основной и единственный) узел имени. См. Руководство пользователя.

Таким образом, если узел имени выходит из строя, и вы можете перезапустить его на том же физическом узле, тогда нет необходимости завершать работу узлов данных, необходимо перезапустить только узел имени. Если вы больше не можете использовать старый узел, вам нужно будет скопировать последнее изображение в другое место. Последнее изображение можно найти либо на узле, который был основным до сбоя, если таковой имеется; или на вторичном узле с именем. Последний будет последней контрольной точкой без последующих журналов редактирования, то есть там могут отсутствовать самые последние изменения в пространстве имен. В этом случае вам также потребуется перезапустить весь кластер.

Есть хитрые способы преодолеть эту единственную точку отказа. Если вы используете дистрибутив cloudera, воспользуйтесь одним из способов, описанных здесь. Распределение Mapr имеет другой способ обработки этого spof.

Наконец, вы можете использовать любой отдельный язык программирования для записи map reduce поверх потоковой передачи hadoop.

Хотя уже слишком поздно отвечать на ваш вопрос, но это может помочь другим .. сначала мы обсудим роль демонов Hadoop 1.X, а затем ваши проблемы..

1. Какова роль узла вторичного имени это не совсем резервный узел. он периодически считывает журналы редактирования и создает обновленный файл fsimage для узла name. он периодически получает метаданные от узла name, сохраняет их и использует при сбое узла name. 2. какова роль узла name, он является менеджером всех демонов. его главный процесс jvm, который выполняется на главном узле. он взаимодействует с узлами данных.

3. какова роль job tracker: он принимает задания и распределяет их среди трекеров задач для обработки на узлах данных. его называют процессом сопоставления

4. какова роль трекеров задач он выполнит программу, предоставленную для обработки существующих данных на узле данных. этот процесс вызывается как map .

ограничения hadoop 1.X

1. единственная точка отказа, которая является узлом name, поэтому мы можем поддерживать высококачественное оборудование для узла name. если произойдет сбой узла name, все будет недоступно

Решения решением для единой точки отказа является hadoop 2.X, который обеспечивает высокую доступность.

высокая доступность с hadoop 2.X

теперь ваши темы ….

Как мы можем восстановить все данные кластера, если что-нибудь случится?если кластер выходит из строя, мы можем перезапустить его..

Если узел выходит из строя до завершения задания, поэтому в job tracker есть ожидающее задание, это задание продолжается или перезапускается с первого в свободном узле?у нас по умолчанию 3 реплики данных (я имею в виду блоки) для обеспечения высокой доступности, это зависит от администратора, сколько у него реплик set…so трекеры заданий продолжат работу с другой копией данных на другом узле данных

можем ли мы использовать программу C в Mapreduce (например, пузырьковую сортировку в mapreduce)?по сути, mapreduce — это механизм выполнения, который будет решать или обрабатывать большие проблемы с данными (хранение плюс обработка) распределенными способами. мы выполняем обработку файлов и все другие базовые операции с использованием программирования mapreduce, поэтому мы можем использовать любой язык, на котором мы можем обрабатывать файлы в соответствии с требованиями.

архитектура hadoop 1.X
в hadoop 1.x есть 4 основных демона

Я просто попробовал. Надеюсь, это поможет вам, а также другим.

Предложения / улучшения приветствуются.