При том, что Apache Hadoop – высоконадежная экосистема хранения и аналитики больших данных, отказы случаются и в ней. Сегодня в рамках обучения начинающих администраторов и разработчиков Hadoop разберем, какие типы сбоев возможны в распределенной файловой системе HDFS и механизмы их предупреждения, а также рассмотрим процедуру вывода узлов из кластера для их профилактического обслуживания и ремонта.
Точки отказа в Hadoop HDFS
Сперва напомним, что проект Hadoop состоит из 4-х основных модулей: Hadoop Common, MapReduce, YARN и HDFS. Именно распределённая файловая система HDFS (Hadoop Distributed File System) обеспечивает хранение файлов на узлах данных (DataNodes), адреса которых находятся на специальном мастер-сервере имен (NameNode). Таким образом, потенциальными точками отказа в HDFS являются NameNode и DataNodes. Однако HDFS включает механизмы предупреждения сбоев на этих узлах и средства смягчения их последствий.
Резервирование NameNode
NameNode — это главный узел, который хранит такие метаданные, как имя файла, количество блоков, количество реплик, расположение и идентификаторы блоков. В первой версии Hadoop узел NameNode был единственной точкой отказа, т.к. даже при сохранении всех метаданных на диске, время их восстановления было очень велико (около 30 минут). 2-я версия Apache Hadoop с механизмами высокой доступности решает эту проблему за счет резервирования NameNode путем дублирования. Одномоментно активен только один мастер-узел, при выходе из строя которого ответственность за обслуживание клиентов сразу же переходит к резервному серверу имен. Такое единственное лидерство NameNode обеспечивается одним из 2-х способов:
- Quorum Journal Manager (QJM) для хранения edit-логов, где права на запись данных имеет только активный NameNode, а резервный мастер-узел может только читать;
- общее хранилище, в котором активный мастер-узел изменяет информацию edit-логов, а резервный NameNode – ищет эти изменения. Если NameNode выходит из строя, он прекращает доступ к этому общему хранилищу.
Активный и резервный мастер-узлы всегда синхронизированы друг с другом и имеют одинаковые метаданные, совместно используя высокодоступное общее хранилище логов. Резервный NameNode читает общий edit-log, чтобы синхронизировать свое состояние с активным мастер-узлом.
Узлы данных отправляют отчеты о блоках HDFS в оба NameNode, потому что отображения блоков хранятся в памяти мастер-узла, а не на диске. Резервный мастер-узел периодически принимает контрольные точки пространства имен активного NameNode [1]. Таким образом, благодаря резервированию отказ системы Hadoop из-за выхода из строя мастер-узла маловероятен и возможен только в случае одновременного сбоя на обоих NameNode, что случается редко. Примечательно, что в свежем релизе Apache Hadoop 3.3.1, выпущенном в июне 2021 года, можно запускать сразу несколько резервных NameNode, что еще более увеличивает надежность и отказоустойчивость всего кластера. Подробнее об этом читайте в нашей новой статье.
Реплицирование на узлах данных
В HDFS для предотвращения сбоя и потери данных на Data Nodes используется репликация, когда один блок данных хранится в нескольких местах. По умолчанию коэффициент репликации для HDFS равен 3, т.е. для исходного блока данных будет две копии (реплики).
По умолчанию Hadoop размещает первую реплику на том же узле, а вторую — на другой стойке кластера, выбранной случайным образом. Третья копия размещается на той же стойке, что и вторая, но на другом узле. Дальнейшие реплики размещаются на случайных узлах кластера, распределенных по разным стойкам.
По умолчанию DataNode непрерывно отправляет контрольные сигналы (heartbeat) на NameNode каждые 3 секунды. Если NameNode не получает heartbeat-сигнал от узла данных в течение 10 минут (тайм-аут по умолчанию), то мастер-узел посчитает этот сервер данных неработоспособным, проверит доступность данных в нем и инициирует репликацию. Таким образом, если один DataNode выйдет из строя, мастер-узел предоставит адрес реплики данных [1]. Это практически полностью исключает сбой Big Data системы из-за отказа DataNode, т.к. одновременный выход из строя всех узлов кластера, где хранятся реплики данных, крайне маловероятен. На первый взгляд, такая стратегия горячей репликации исключает возможность профилактического ремонта или обслуживания серверов, однако, это не так. Как администратор может вывести узел из эксплуатации, не потеряв данные, мы расскажем далее.
Обслуживание узлов в кластере Hadoop: на заметку администратору
NameNode хранит актуальные сведения не только о состоянии узлов данных в плане их живучести, а также содержит информацию об эксплуатации узла, чтобы администратор кластера знал, какие сервера работают, а какие — выведены из эксплуатации или находится на сервисном обслуживании. Таким образом, с точки зрения эксплуатации узел может находиться в одном из следующих состояний (adminState) [2]:
- NORMAL — в эксплуатации;
- DECOMMISSIONED – выведен из эксплуатации;
- DECOMMISSION_INPROGRESS – перевод в состояние DECOMMISSIONED;
- IN_MAINTENANCE – на сервисном обслуживании;
- ENTERING_MAINTENANCE – перевод в состояние обслуживания.
Когда администратор кластера Hadoop выводит из эксплуатации DataNode, он сначала переводится в состояние DECOMMISSION_INPROGRESS. После того, как все блоки данных на этом узле будут полностью реплицированы в другом месте на основе заданного коэффициента репликации каждого блока, DataNode переходит в состояние DECOMMISSIONED. Теперь администратор кластера Hadoop может выключить узел для выполнения долгосрочного ремонта или профилактического обслуживания. А после проведения этих операций, сервер можно снова включить в кластер.
Иногда нужно отключить узел данных на несколько минут или пару часов для краткосрочного ремонта или обслуживания, не выполняя полную репликацию блоков HDFS. Когда администратор переводит сервер в состояние обслуживания (IN_MAINTENANCE), он сперва переходит в состояние ENTERING_MAINTENANCE. Пока все блоки HDFS на этом узле данных, минимально реплицируются в другом месте, DataNode будет немедленно переведен в состояние IN_MAINTENANCE. По завершении сервисных операций администратор может вручную вывести узел из состояния обслуживания или с помощью настроенного тайм-аута, который позволяет задать максимальную продолжительность нахождения узла в статусе IN_MAINTENANCE. По истечении этого тайм-аута DataNode автоматически перейдет в NORMAL без вмешательства человека.
Таким образом, сервисные операции, которые может выполнить администратора кластера Hadoop относительно узла данных, включают следующее:
- вывод из эксплуатации;
- повторное включение в кластер;
- перевод в состояние обслуживания;
- вывод из состояния обслуживания.
Чтобы провести любую из этих операций, администратор кластера Hadoop должен выполнить два шага:
- обновите файлы конфигурации на уровне хоста, чтобы указать желаемое состояние целевых серверов.
- Запустить команду hdfs dfsadmin [-refreshNodes], чтобы мастер-узел NameNode перезагрузил файлы конфигурации уровня хоста.
По умолчанию NameNode поддерживает только вывод из эксплуатации и повторное включение узла в кластер, игнорируя операции администрирования, связанные с обслуживанием. Информация о работающих хостах прописывается в файле dfs.hosts, а о выведенных из эксплуатации, например, с целью профилактического обслуживания или ремонта, в файле dfs.hosts.exclude. При этом выведенные узлы отмечены как в файле dfs.hosts, так и в dfs.hosts.exclude. При этом есть два формата файлов конфигурации, основанных на разных факторах [2]:
- имя хоста, где каждая строка включает имя хоста/IP-адрес узла данных. Это формат по умолчанию.
- JSON-конфигурация, где каждый элемент отображается на один узел данных, и каждый узел данных может иметь несколько свойств. Именно этот новый формат конфигурации используется для перевода узлов в состояние обслуживания.
Таким образом, JSON-формат конфигурации поддерживает общие свойства узлов данных и позволяет администратору Hadoop-кластера провести сервисные операции с DataNode. Например, хосты узлы host1 и host2 находятся в рабочем состоянии, host3 выведен из эксплуатации, а host4 переведен в состояние обслуживания. Тогда JSON-конфигурация этих узлов будет выглядеть так [3]:
[
{
«hostName»: «host1»
},
{
«hostName»: «host2»,
«upgradeDomain»: «ud0»
},
{
«hostName»: «host3»,
«adminState»: «DECOMMISSIONED»
},
{
«hostName»: «host4»,
«upgradeDomain»: «ud2»,
«adminState»: «IN_MAINTENANCE»
}
]
Поскольку за отслеживание состояний узлов данных отвечает NameNode, при проведении сервисных операций с DataNode, администратору Hadoop придется поработать с настройками мастер-узла. Для большинства случаев подойдут значения по умолчанию, заданные в файле hdfs-default.xml, но иногда может потребоваться изменить следующие параметры [3]:
- dfs.namenode.maintenance.replication.min — минимальный коэффициент репликации рабочего блока данных HDFS в случае режима обслуживания, по умолчанию равен 1;
- dfs.namenode.decommission.interval – периодичность, с которой NameNode проверяет завершение вывода узлов данных из эксплуатации или состояния обслуживания. По умолчанию равен 30 секунд, другие единицы времени (минуты, часы и пр.) задаются в конфигурации heartbeat.interval. Без дополнительного указания единиц времени используются секунды.
- dfs.namenode.decommission.blocks.per.interval — приблизительное количество блоков HDFS для обработки за интервал вывода из эксплуатации или состояния обслуживания, определенном в namenode.decommission.interval. По умолчанию равен 500000.
- dfs.namenode.decommission.max.concurrent.tracked.nodes — максимальное количество узлов данных в состояниях DECOMMISSION_INPROGRESS или ENTERING_MAINTENANCE, которые одновременно сможет отслеживать NameNode, т.к. это потребляет дополнительную память, пропорциональную количеству блоков HDFS на узле данных. Ограничение этого предела снижает риски при выводе большого количества узлов. По умолчанию этот параметр равен 100, а значение 0 означает отсутствие ограничений.
В следующий раз мы продолжим разговор про основы Hadoop и рассмотрим потенциальные точки отказа на другом core-компоненте этой Big Data платформы – системе YARN, а также способы их обхода. А практически освоить все тонкости администрирования и эксплуатации Apache Hadoop вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
