Постоянность метаданных файловой системы

Пространство имён HDFS хранится на NameNode-сервере. NameNode-сервер использует транзакционный лог, называемый EditLog для постоянной записи каждого изменения над метаданными файловой системы. Создание нового файла вызывает вставку записи в EditLog. Точно так же изменение уровня репликации файла вызывает вставку новой записи. NameNode-сервер использует файл локальной операционной системы для сохранения EditLog. Всё пространство имён файловой системы, включая отображение блоков на файлы и свойства файловой системы сохранено в файле FsImage. Файл FsImage также сохраняется в локальной файловой системе NameNode-сервера.

NameNode-сервер сохраняет картину всего пространства имён файловой системы и отображение имён в памяти. Ключевые элементы метаданных разработаны компактно, так чтобы 4 Гб оперативной памяти хватило для работы с большим количество файлов и директорий. При запуске NameNode-сервера, он считывает информацию из файлов FsImage и EditLog с диска, применяет транзакции из EditLog к представлению в памяти файла FsImage и сохраняет новую версию файла FsImage на диск. Это может вызвать усечение старых данных лога из-за транзакций, применённых к постоянному файлу FsImage. Этот процесс называется сохранение контрольной точки. В текущей реализации сохранение контрольной точки выполняется при запуске NameNode-сервера. Ведётся работа над поддержкой периодического сохранения контрольной точки.

DataNode-сервер сохраняет файлы HDFS в локальной файловой системе. DataNode-сервер не имеет предположения о содержании HDFS файлов. Он сохраняет каждый блок данных в отдельный файл локальной файловой системы. DataNode-сервер не создаёт все файлы в одной системе. Вместо этого он использует эвристку для определения оптимального количества файлов в директории и соответственно создаёт поддиректории. Не оптимально создавать все файлы в одной директории, потому что локальная файловая система может не поддерживать работу с большим количеством файлов в одной директории. При запуске DataNode-сервер сканирует файлы локальной файловой системы и генерирует список всех блоков данных, которые соответствуют всем этим файлам, и посылает отчёт NameNode-серверу: это и есть отчёт о блоках.

Протоколы взаимодействия.

Все протоколы взаимодействия HDFS базируются на протоколе TCP/IP. Клиент подключается к настраиваемому TCP порту на NameNode-сервере.

Устойчивость

Основной целью HDFS является надёжное сохранение данных даже в случае отказа.

Отказы дисков, heartbeat и процесс перереплицирования

Каждый DataNode-сервер периодически посылает heartbeat NameNode-серверу. Сетевые обрывы могут вызвать потерю соединения между частью DataNode-серверов и NameNode-сервером. NameNode-сервер определяет это по отсутствию сообщений heartbeat. NameNode-сервер помечают такие узлы как мёртвые и в дальнейшем не направляет на них новые запросы на чтение/запись. Любые данные, которые были зарегистрированы на отказавших DataNode-серверах, становятся более недоступными для HDFS. Отказ DataNode-сервера может вызвать ререпликацию размещённых на нём данных. NameNode-сервер отслеживает, какие блоки требуют ререпликации и запускает этот процесс. Необходимость в репликации может возникать по многим причинам: недоступность DataNode-сервера, повреждение реплики, отказ жёсткого диска, увеличение уровня репликации файла.

Перебалансировка кластера

Архитектура HDFS совместима со схемами перебалансировки данных. Схема может автоматически перемещать данные с одного DataNode-сервера, если размер свободного пространства на нём ниже порогового. В случае высокой востребованности определённого файла, схема может динамически создать дополнительные реплики и перебалансировать данные в кластере. Такие схемы балансировки на данный момент не реализованы.

Целостность данных

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

Отказ хранилища метаданных

FsImage и EditLog являются основными структурами данных HDFS. Повреждение этих файлов может вызвать отказ всего кластера HDFS. По этой причине, NameNode-сервер может быть настроен для ведения нескольких копий FsImage и EditLog. Любое обновление этих файлов вызывает синхронное обновление копий. Это может уменьшить возможное количество операций в секунду над файловой системой. Тем не менее, это уменьшение приемлемо, потому что даже если приложение требовательно к производительности операций ввода вывода, то оно не требовательно к производительности метаданных. При перезапуске NameNode-сервера для использования выбираются последние относящиеся к нему файлы FsImage и EditLog.

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

Организация данных

Блоки данных

HDFS Разработан для поддержки больших файлов. Приложения требующие HDFS оперируют большими наборами данных. Такие приложение пишут данные единожды но читают их многократно и требуют высоких скоростей чтения. HDFS поддерживает такую модель работы с файлами. Типичный размер блока в HDFS равен 64 Мб. Таким образом HDFS файлы поделены на блоки по 64 Мб, и, если это возможно, каждый блок размещается на разных DataNode-сереверах.

Staging

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

Изложенный выше подход был принят после внимательного изучения целевых приложений HDFS. Такие приложения требуют поточной записи файлов. Клиент пишет в удаленный файл напрямую без буферизации на стороне клиента, скорость и перегрузка сети оказывают значительное негативное влияние. Такой подход не обходится без прецедентов. Ранние РФС, например AFS, использовали кэширование на стороне сервера для увеличения производительности.

Replication Pipelining

Когда клиент осуществляет запись данных в HDFS файл, эти данные в первую очередь записываются в локальный файл, как было изложено предыдущем разделе. Предположим, что уровень репликации HDFS файла равен трём. Когда локальный файл накапливает полный блок пользовательских данных, клиент получает список DataNode-серверов от NameNode-сервера. Этот список содержит DataNode-серверы, которые будут содержать реплики этого блока. Клиент сбрасывает блок данных на первый DataNode-сервер. Первый DataNode-сервер начинает получает получать данные маленькими частями (4 КБ), записывает каждую часть в её локальный репозиторий и перемещает ей на второй DataNode-сервер в списке. Второй DataNode-сервер, в свою очередь, принимая каждую часть блоков, записывает её в соответствующий репозиторий и сбрасывает её на третий DataNode-сервер. В конечном счёте, третий DataNode-сервер записывает данные в соответствующий локальный репозиторий. Таким образом, DataNode-сервер может получать данные от предыдущего сервера и перенаправлять данные к следующему. Так данные копируются с одного DataNode-сервер на другой.

Классификатор

Не нашли, что искали? Воспользуйтесь поиском по сайту: