Это 6-й день моего участия в августовском испытании обновлений.Подробности о мероприятии:Испытание августовского обновления

текст

HDFS HA是用来解决NameNode 单点故障问题的，
HDFS 联邦是用来解决 NameNode 内存瓶颈问题的。

Единая точка отказа NameNode

Расположение NameNode в HDFS очень важно, и в нем абсолютно нет места для отказа.

Поскольку информация метаданных всей файловой системы HDFS управляется NameNode, доступность NameNode напрямую определяет доступность всей HDFS.

В эпоху Hadoop1.x у NameNode есть единая точка отказа, и процесс NameNode не может работать должным образом, что повлияет на нормальное использование всего кластера, и вся HDFS будет недоступна.

Такие данные, как Hive или HBase, хранятся в HDFS, и все платформы, такие как Hive или HBase, не могут использоваться, что может привести к невозможности нормального использования многих платформ в вашем производственном кластере.

Процесс восстановления данных путем перезапуска NameNode также займет много времени.

Архитектура высокой доступности NameNode HDFS

В Hadoop2.x решена проблема единственной точки HDFS NameNode. Общая архитектура высокой доступности NameNode HDFS показана на рисунке.

Из приведенного выше рисунка видно, что архитектура высокой доступности NameNode в основном разделена на следующие части:

В типичном кластере высокой доступности две отдельные машины действуют как NameNodes.

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

Активный/резервный контроллер переключения ZKFailoverController

ZKFailoverController работает как независимый процесс и контролирует переключение ведущий-ведомый NameNode.

ZKFailoverController может вовремя определить состояние работоспособности NameNode и реализовать автоматический выбор активного/резервного режима и переключение с помощью Zookeeper при сбое основного NameNode.Конечно, NameNode в настоящее время также поддерживает ручное переключение активного/резервного режима, которое не зависит от Zookeeper.

Назначение кластера Zookeeper — обеспечить первичную и вторичную поддержку выбора для первичных и вторичных контроллеров коммутации.

Основные обязанности ZKFailoverController

мониторинг здоровья

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

управление сессиями

Если NameNode исправен, ZKFailoverController сохранит открытый сеанс в Zookeeper.

Если NameNode при этом все еще находится в активном состоянии, то kfc также будет иметь znode эфемерного типа в Zookeeper.Когда NameNode умрет, znode будет удален, а резервный NameNode получит блокировку. основной NN и пометить статус как Active.

Когда отключенный NameNode снова запускается, он снова зарегистрирует Zookeeper и обнаружит, что уже есть блокировка znode, он автоматически перейдет в состояние ожидания и т. д. и т. д. для обеспечения высокой надежности.

Hadoop2.x поддерживает только конфигурацию до 2 узлов имен, Hadoop3.x поддерживает более 2 узлов имен.

главные выборы

Как упоминалось выше, механизм упреждающей блокировки реализуется путем поддержки кратковременного znode в Zookeeper для определения того, какой NameNode находится в активном состоянии.

Общая система хранения Quorum Journal Node

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

Любая модификация пространства имен, сделанная Active Node, отправит журнал записей модификации большинству JN.

Резервные узлы могут читать изменения из JN и время от времени отслеживать их изменения в EditLog.

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

При отработке отказа Standby гарантирует, что все изменения были прочитаны из JN, прежде чем перевести себя в активное состояние, что гарантирует полную синхронизацию состояния пространства имен (обоих NameNodes) до того, как произойдет отработка отказа.

Узел DataNode

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

DataNode будет одновременно сообщать информацию о местоположении блока данных первичному NameNode и вторичному NameNode.

Федерация

Федерация генерирует фон

Читая содержимое перед столбцом, мы знаем, что метаданные кластера HDFS хранятся в памяти NameNode.

Когда кластер расширяется до определенного масштаба, метаданные, хранящиеся в памяти NameNode, могут быть очень большими.Поскольку все операции HDFS будут взаимодействовать с NameNode, когда кластер большой, NameNode станет узким местом кластера.

До появления Hadoop2.x в HDFS было только одно пространство имен, и в HDFS не было возможности изолировать файлы.

По этой причине в Hadoop2.x был представлен механизм федерации, который может решать следующие сценарии.

1. Масштабируемость кластера HDFS. Несколько NameNodes отвечают за часть каталога, поэтому кластер можно расширить до большего количества узлов, а количество файловых хранилищ больше не ограничено из-за ограничений памяти в 1.0.
2. Более эффективная работа. Несколько NameNodes одновременно управляют разными данными и предоставляют внешние службы, что обеспечит пользователям более высокую пропускную способность чтения и записи.
3. Хорошая изоляция. Пользователи могут передавать различные бизнес-данные различным узлам имен для управления в соответствии со своими потребностями, поэтому влияние между различными предприятиями будет небольшим.

Архитектура управления данными HDFS

Хранение данных имеет иерархическую структуру. Другими словами, вся информация и управление хранимыми данными размещается на стороне NameNode, а реальные данные хранятся в каждом DataNode.

Эти данные, управляемые одним и тем же NameNode, находятся в одном и том же пространстве имен, и одно пространство имен соответствует одному пулу блоков.

Пул блоков — это набор блоков в одном пространстве имен.Конечно, это наш самый распространенный случай единого пространства имен.

То есть, когда Name Node управляет всей информацией метаданных в кластере, если мы столкнемся с проблемой высокого использования памяти NameNode, упомянутой выше, что нам делать в это время?

Пространство метаданных все еще растет, и слепое увеличение размера JVM NameNode определенно не является долговременным решением. В это время родился механизм HDFS Federation.

Архитектура Федерации

Слишком большой объем памяти NameNode. Мы можем полностью переместить большой файловый каталог на другой NameNode для управления. Что еще более важно, эти NameNode совместно используют все DataNodes в кластере.

Они по-прежнему находятся в одном кластере. Принципиальная структура HDFS Federation показана на рисунке.

HDFS Federation — это горизонтально масштабируемое решение для решения проблемы единственной точки NameNode. Создает несколько независимых NameNodes и пространств имен.

Это позволяет службе именования HDFS расширяться по горизонтали, а узлы NameNodes в федерации HDFS управляют своими собственными пространствами имен независимо друг от друга.

В настоящее время данные в одном пуле блоков хранятся не только в DataNode, но и в нескольких.

В случае HDFS Federation разделены только управление и хранение метаданных, а хранилище реальных данных является общим.

Ссылки на литературу

Сяо Жуй и Лей Ганъюэ, главные редакторы «Практики разработки больших данных Hadoop & Spark»