В чем различия zookeeper, задач узла журнала и менеджера журнала кворума в hadoop?

Question

Изучая материал на нескольких веб-сайтах и ​​в видеороликах, меня смущают функциональные возможности и различия в назначении трех компонентов hadoop ZooKeeper, Journal Node и Quorum Journal Manager.

Может ли кто-нибудь объяснить мне причины изобретения каждого из вышеперечисленных и различия в целях и функциях вышеупомянутых трех компонентов?

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

Answer 1

Подумайте об этом так: zookeeper - это группа людей, каждый из которых назначен наблюдать за фабрикой и координировать их, узел журнала - это место, где все менеджеры фабрики могут проверять статус и координаты других. QJM - это комбинация того и другого, которая должна использоваться в HA для лучшей координации в случае сбоя.

zookeeper координирует hbase regionservers и другие модули hadoop, которые требуют zookeeper.

узел журнала координирует датодуды hadoop с namenode.

QJM координирует серверы регионов, используя технику, используемую узлом журнала

на основной настройке hadoop только распределенный узел необходим в случае распределенной настройки

Answer 2

Во-первых, кворум означает, что для принятия решений необходимо большинство. Итак, когда вы видите слово "кворум", вы должны думать о кластере, говоря это; конфигурация с несколькими хостами. Вы можете услышать этот термин для Zookeeper и Journal Nodes.

Краткое описание их функциональности поможет вам различить их назначение.

Zookeeper: Zookeeper является центральным приложением для синхронизации информации, которую приложения должны часто проверять. Может быть много информации, которая нужна приложению, например структура имен, информация, информация о конфигурации (или просто конфигурации) и т. Д. Наиболее распространенный случай - это конфигурация приложения. Когда вы изменяете конфигурацию, которая относится, скажем, к 80 серверам, чтобы синхронизировать это изменение со всеми узлами, вам необходимо разработать службу синхронизации. Само приложение может иметь эту функцию. Но представьте, что вы добавили в свою среду еще 12 приложений. Вы должны заботиться о службе синхронизации каждого приложения по одному. Вот где приходит zookeeper. Zookeeper может самостоятельно управлять всей этой информацией. Если вы настроите его как кластер (вам нужно нечетное количество хостов. Почему?), Вы будете иметь высокую доступность для Zookeeper (случаи аварийного переключения) и иметь кворум Zoopeeker.

Узел журнала: в кластере Hadoop высокой доступности у вас есть несколько Namenodes, работающих в активном / пассивном режиме. Активный наменоде информирует узел журнала об изменениях. Узел stand by name запрашивает узел журнала о том, что изменилось. Как и в случае с Zookeeper, если вы настроили кластерную конфигурацию (здесь также нужно нечетное количество хостов. Почему?), Вы также обладаете высокой доступностью для функций узла журнала и имеете диспетчер журнала кворума.

На самом деле я не слышал, чтобы они устанавливались как один хост или узел, за исключением лабораторных целей (vm in pc).

Answer 3

1. Зоопарк

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

Роль Zookeeper в экосистеме Hadoop:

Во время процесса отработки отказа Hadoop Namenode ZooKeeper использовался, чтобы избежать сценария разделения мозгов, чтобы состояние узла имени не отклонялось из-за отработки отказа.

Обратитесь к этому сообщению для более подробной информации:

Как работает процесс отработки отказа Hadoop Namenode?

2. JournalNode (используется в процессе аварийного переключения Namenode)

Чтобы резервный узел сохранял свое состояние синхронизированным с активным узлом, оба узла связываются с группой отдельных демонов, называемых "JournalNodes" (JNs).

Машины JournalNode - машины, на которых вы запускаете узлы JournalNode. Демон JournalNode является относительно легким, поэтому эти демоны могут быть разумно размещены на машинах с другими демонами Hadoop, например NameNodes, JobTracker или YARN ResourceManager.

Примечание. Должно быть не менее 3 демонов JournalNode, поскольку изменения в журнале редактирования должны быть записаны для большинства JN. Это позволит системе терпеть отказ одной машины

3. Quorum Journal Manager (QJM) позволяет обмениваться журналами редактирования между активными и резервными именами узлов.

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