Библиотека сайта rus-linux.net
Распределенная файловая система Hadoop
Глава 8 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: The Hadoop Distributed File System
Авторы: Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, Suresh Srinivas
Дата публикации: 7 Июля 2012 г.
Перевод: А.Панин
Дата перевода: 8 Апреля 2013 г.
8.2. Архитектура
8.2.1. Сервер метаданных NameNode
Пространство имен файловой системы HDFS представлено иерархией файлов и директорий. Файлы и директории представлены структурами inode на сервере метаданных (NameNode). Структуры inode содержат такие атрибуты файла, как права доступа, метки времени модификации и последнего доступа, квоты для пространства имен и дискового пространства. Содержимое файла разделяется на большие блоки (обычно размером в 128 мегабайт, но этот размер также может задаваться пользователем для каждого из файлов) и каждый такой блок файла независимо копируется на множество серверов данных приложений. Текущая архитектура предусматривает возможность использования одного сервера метаданных (NameNode) для каждого кластера. Кластер может содержать тысячи серверов данных приложений и обслуживать десятки тысяч клиентов HDFS, так как каждый сервер данных приложений позволяет выполнять множество приложений одновременно.
8.2.2. Образ и журнал
Структуры inode и список блоков, являющиеся метаданными системы имен, называются образом. Сервер метаданных (NameNode) хранит образ пространства имен полностью в оперативной памяти. Постоянная копия образа, хранящаяся в локальной файловой системе сервера метаданных называется контрольной точкой. Данные изменений HDFS, сохраняемые в локальной файловой системе сервера метаданных перед произведением самих изменений, называются журналом. Данные о расположении скопированных блоков файлов не являются постоянной частью файла контрольной точки.
Каждая инициированная клиентом транзакция находит свое отражение в журнале, при этом изменения файла журнала принудительно записываются на диск перед отправкой подтверждения клиенту. Файл контрольной точки никогда не изменяется по инициативе сервера метаданных; новый файл записывается тогда, когда контрольная точка создается в ходе перезагрузки, при запросе от администратора или с участием сервера файлов контрольных точек (CheckpointNode), описанного в следующем разделе. В ходе запуска сервера метаданных происходит инициализация образа пространства имен с использованием файла контрольной точки, после чего в образ вносятся изменения из журнала. Новый файл контрольной точки и пустой журнал записываются в файловую систему сервера метаданных перед тем, как он начинает обслуживать клиентов.
Для повышения длительности хранения данных резервные копии файлов контрольной точки и журнала обычно хранятся на множестве независимых локальных разделов и на удаленных NFS-серверах. Первая мера предосторожности предотвращает потерю данных в случае выхода из строя отдельного раздела, вторая - в случае выхода из строя всего сервера. Если сервер метаданных сталкивается с ошибкой при копировании файла журнала в одну из директорий для его хранения, он автоматически исключает эту директорию из списка директорий. В том случае, если ни одна из директорий для хранения файлов не доступна, сервер метаданных автоматически прекращает свою работу.
Сервер метаданных использует систему с поддержкой программных потоков и обрабатывает запросы от множества клиентов одновременно. Операция сохранения данных транзакции на диск становится узким местом, так как всем потокам приходится ожидать завершения процедуры синхронной записи, инициированной одним из них. На самом деле, для оптимизации этого процесса сервер метаданных создает очередь из множества транзакций. Когда один из потоков сервера метаданных инициирует операцию записи, все ожидающие в очереди транзакции, выполняются вместе. Остающиеся потоки должны только проверить, были ли сохранены данные в ходе транзакций и не должны осуществлять принудительную запись.
8.2.3. Сервер данных приложений DataNode
Каждая копия блока файла на сервере данных приложений представлена двумя файлами в локальной файловой системе. Первый файл содержит сами данные, а второй - метаданные блока, включающие в себя контрольные суммы для блока данных и метку времени, относящуюся к моменту генерации блока. Размер файла данных равен используемому размеру блока и файл не занимает дополнительного дискового пространства для округления в строну повышения размера файла до размера блока таким образом, как это делается в традиционных файловых системах. Следовательно, если размер блока составляет половину установленного размера, он занимает объем локального диска, соответствующий только половине установленного размера блока.
Во время загрузки каждый сервер данных приложений соединяется с сервером метаданных и осуществляет операцию рукопожатия. Целью этой операции рукопожатия является проверка идентификатора пространства имен и версии программного обеспечения на сервере данных приложений. Если хотя бы одно из используемых сервером метаданных значений не совпадает со значением, используемым сервером данных приложений, сервер данных приложений автоматически прекращает свою работу.
Идентификатор пространства имен присваивается файловой системе во время форматирования. Этот идентификатор хранится на всех серверах кластера на постоянной основе. Серверы с различными идентификаторами пространств имен не смогут работать в рамках одного кластера, таким образом защищается целостность файловой системы. Только что инициализированному серверу данных приложений без идентификатора пространства имен разрешено входить в состав кластера и получать идентификатор пространства имен от него.
После рукопожатия сервер данных приложений регистрируется сервером метаданных. Серверы данных приложений постоянно хранят свои уникальные идентификаторы хранилищ. Идентификатор хранилища является внутренним идентификатором сервера данных приложений, который позволяет идентифицировать его даже после перезагрузки и присвоения ему другого IP-адреса или номера порта. Идентификатор хранилища присваивается серверу данных приложений при регистрации сервером метаданных в первый раз и никогда не изменяется после этого.
Сервер данных приложений сообщает о принадлежащих ему блоках данных серверу метаданных путем отправки отчетов о блоках. Каждый отчет содержит идентификатор блока, метку времени генерации блока и размер копии блока на сервере. Первый отчет о блоках отправляется немедленно после регистрации сервером метаданных. Последующие отчеты о блоках отправляются каждый час и предоставляют серверу метаданных актуальную информацию о расположении копий блоков в рамках кластера.
В процессе работы серверы данных приложений отправляют сообщения о состоянии (heartbeats) серверу метаданных для подтверждения того, что сервер данных приложений работает и копии блоков, хранящиеся на нем, доступны. Стандартным интервалом отправки сообщений о состоянии является трехсекундный интервал. В том случае, если сервер метаданных не получает сообщений состояний от сервера данных приложений в течение десяти минут, он считает, что сервер данных приложения не функционирует и копии блоков данных, хранившиеся на нем, недоступны. После этого сервер метаданных планирует операции создания новых копий хранившихся на отключенном сервере блоков на других серверах данных приложений.
Сообщения о состоянии серверов данных приложений также содержат информацию об общем объеме устройств хранения, процентном отношении использованного дискового пространства и количестве передач данных, осуществляемых в текущий момент. Эти статистические данные используются сервером метаданных для принятия решений о резервировании блоков и балансировке нагрузки.
Сервер метаданных не отправляет запросы напрямую серверам данных приложений. Он использует ответы на сообщения о состоянии для отправки инструкций серверам данных приложений. Инструкции включают в себя команды для копирования блоков на другие серверы, удаления локальных копий блоков, повторной регистрации, немедленной отправки отчетов о блоках и завершения работы сервера.
Эти команды особенно важны для поддержания целостности системы, следовательно критически важно поддерживать постоянную отправку сообщений о состоянии даже в крупных кластерах. Сервер метаданных может обрабатывать тысячи сообщений о состоянии в секунду без нарушения процесса выполнения других операций.
8.2.4. Клиент HDFS
Пользовательские приложения получают доступ к файловой системе с помощью клиента HDFS, библиотеки, экспортирующей интерфейс файловой системы HDFS.
Как и большинство традиционных файловых систем, HDFS поддерживает операции чтения, записи и удаления файлов, а также операции создания и удаления директорий. Пользователь описывает файлы и директории с помощью путей из пространства имен. Пользовательскому приложению не нужно беспокоиться о том, что метаданные и данные файлов из файловой системы хранятся на разных серверах или о том, что блоки имеют множество копий.
Когда приложение читает файл, клиент HDFS в первую очередь запрашивает у сервера метаданных список серверов данных приложений, хранящих копии блоков данных необходимого файла. Список сортируется на основании дистанции до клиента в рамках топологии сети. Клиент соединяется напрямую с сервером данных приложений и запрашивает передачу необходимого блока. Когда клиент осуществляет запись, он в первую очередь требует от сервера метаданных выбора серверов данных приложений для хранения копий первого блока файла. Клиент организует канал между несколькими серверами и отправляет данные. Когда первый блок передан, клиент запрашивает выбор следующих серверов данных приложений для хранения копий следующего блока. Организуется новый канал и клиент отправляет данные следующего блока. Выбор серверов данных приложений для каждого блока вероятнее всего будет различным. Взаимодействия между клиентом, сервером метаданных и серверами данных приложений отражены на Рисунке 8.1.
Рисунок 8.1: Клиент HDFS создает новый файл
В отличие от традиционных файловых систем, HDFS предоставляет API, позволяющий выявить расположения блоков данных файлов. Это обстоятельство позволяет таким приложениям, как фреймворк MapReduce планировать выполнение задач на тех серверах, где располагаются необходимые данные, тем самым повышая скорость чтения данных. Обычно файлы подвергаются трехкратной репликации. В случае работы с важными файлами или файлами, доступ к которым осуществляется очень часто, повышенная степень репликации повышает устойчивость к отказам и скорость чтения данных.
8.2.5. Сервер файлов контрольных точек CheckpointNode
Сервер метаданных в HDFS в дополнение к его основным задачам обработки клиентских запросов, может работать в одном из двух других режимов, выполняя функции сервера файлов контрольных точек (CheckpointNode) или сервера резервных копий (BackupNode). Режим работы устанавливается в процессе загрузки сервера.
Сервер файлов контрольных точек периодически комбинирует данные из существующего файла контрольной точки с данными из журнала для создания нового файла контрольной точки и пустого журнала. Сервер файлов контрольных точек обычно работает на отдельном от сервера метаданных узле, так как имеет аналогичные требования к оперативной памяти. Он загружает текущие файлы контрольной точки и журнала с сервера метаданных, объединяет их и возвращает новый файл контрольной точки серверу метаданных.
Периодическое создание файлов контрольных точек является одним из методов защиты метаданных файловой системы. Система может начать работу с наиболее поздним файлом контрольной точки в том случае, если все остальные постоянные копии образа пространства имен и журнала недоступны. Создание файла контрольной точки также позволяет серверу метаданных очистить журнал в тот момент, когда загружается новый файл контрольной точки. Кластеры HDFS работают в течение длительных промежутков времени без перезагрузок, при этом файл журнала также постоянно растет в течение этих промежутков времени. Если файл журнала достигнет очень большого объема, повысится вероятность его потери или повреждения. Также, очень большой файл журнала увеличивает период времени, требуемый для перезагрузки сервера метаданных. При работе большого кластера обработка файла журнала с событиями за неделю происходит в течение часа. Хорошей практикой является ежедневное создание файла контрольной точки.
8.2.6. Сервер резервных копий BackupNode
Недавно была представлена возможность использования сервера резервных копий (BackupNode) в HDFS. Как и в случае сервера файлов контрольных точек, сервер резервных копий позволяет периодически создавать файлы контрольных точек, но в дополнение к этому он поддерживает в оперативной памяти актуальный образ пространства имен файловой системы, который может быть синхронизирован с соответствующим образом сервера метаданных.
Сервер резервных копий принимает поток транзакций из пространства имен в форме файлов журнала от активного сервера метаданных, сохраняет свою копию журнала и применяет эти транзакции по отношению к своему образу пространства имен в оперативной памяти. Сервер метаданных рассматривает сервер резервных копий как хранилище файлов журнала, аналогичное хранилищу файлов журнала в локальных директориях. В случае неработоспособности сервера метаданных, образ пространства имен в оперативной памяти сервера резервных копий и файл контрольной точки на его диске будут содержать актуальные данные состояния пространства имен файловой системы.
Сервер резервных копий может создать файл контрольной точки без загрузки файлов контрольной точки и журнала с активного сервера метаданных, так как он и так имеет в распоряжении актуальный образ пространства имен файловой системы в оперативной памяти. Это обстоятельство делает процесс создания файла контрольной точки сервером резервных копий более эффективным, так как ему требуется только сохранить образ пространства имен в свои локальные директории.
Сервер резервных копий может рассматриваться как сервер метаданных, работающий в режиме только для чтения. Он хранит все метаданные файловой системы за исключением расположений блоков данных файлов. Он может выполнять все функции обычного сервера метаданных, не связанные с модификацией пространства имен или доступом к информации о расположении блоков данных файлов. Использование сервера резервных копий позволяет использовать сервер метаданных без постоянного хранилища, делегируя ответственность за постоянное хранение состояния пространства имен серверу резервных копий.
8.2.7. Обновления и снимки файловой системы
В процессе обновлений программного обеспечения вероятность повреждения файловой системы в результате ошибок программного обеспечения или обслуживающего персонала возрастает. Целью создания снимков файловой системы HDFS является минимизация потенциальных рисков повреждения данных системы во время ее обновлений.
Механизм снимков позволяет системным администраторам сохранить состояние файловой системы в неизменном виде, поэтому в том случае, если обновление системы приведет к потере данных или их повреждению, будет возможность отката изменений, вызванных обновлением системы, и возвращения пространства имен и состояния данных файловой системы HDFS к тому виду, в каком они были во время создания снимка.
Снимок (который может существовать только в единственном экземпляре) создается по усмотрению администратора кластера в любой момент после запуска системы. При запросе создания снимка сервер метаданных сначала считывает данные из файлов контрольной точки и журнала, объединяя их в оперативной памяти. После этого он записывает новые файлы контрольной точки и пустого журнала в других директориях таким образом, чтобы старые файлы контрольной точки и журнала не подверглись изменениям.
Во время обмена данными сервер метаданных отправляет серверам данных приложений команду создания локальных снимков. Локальный снимок на сервере данных приложений не может быть создан с помощью репликации директорий с файлами данных, так как эта операция потребовала бы удвоения объема устройств хранения данных каждого сервера данных приложений кластера. Вместо этого каждый сервер данных приложений создает копию директории для хранения данных, содержащую жесткие ссылки на существующие блоки данных. Когда сервер данных приложений удаляет блок, он удаляет только жесткую ссылку, а при модификациях блока в ходе поступления данных используется техника копирования при записи. Таким образом, копии старых блоков остаются нетронутыми в старых директориях.
Администратор кластера может осуществить откат файловой системы HDFS к состоянию в момент создания снимка при перезагрузке системы. Сервер метаданных восстановит файл контрольной точки, сохраненный во время создания снимка. Серверы данных приложений восстанавливают ранее переименованные директории и инициируют фоновый процесс удаления копий блоков, созданных после создания снимка. После использования функции отката не остается возможности для возврата в предыдущее состояние. Администратор кластера может освободить место, занятое данными снимка, использовав команду удаления снимка; для снимков, созданных во время обновления программного обеспечения эта операция завершается после обновления системы.
Эволюция системы может повлечь изменения в формате файлов контрольной точки и журнала сервера метаданных или представления копий файлов блоков на серверах данных приложений. Версия представления данных идентифицирует метод представления данных и постоянно хранится в директориях для файлов сервера метаданных и серверов данных приложений. В ходе загрузки каждый сервер сравнивает версию представления данных, используемую программным обеспечением, с версией представления данных, хранящихся в директориях, и автоматически преобразует данные из представлений устаревших форматов в новые. Преобразование требует обязательного создания снимка после перезагрузки сервера с использованием программного обеспечения, поддерживающего новую версию представления данных.
Далее: 8.3. Операции ввода/вывода и управление копиями блоков