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

текст

Обзор

Чтобы повысить надежность, HDFS использует технологию трех копий «грубой силы», которая вызывает проблему стоимости хранения. Промышленность изучает способы снижения затрат на хранение. Традиционная технология RAID естественным образом заимствована и объединена с HDFS. Благодаря сочетанию технологии Erasure Code (Erasuredcode) RAID стоимость хранения снижается с 3-кратного по сравнению с HDFS по умолчанию до 1,4-кратного. Начиная с Hadoop3.x, HDFS использует технологию кода стирания файлов (ErasuredCode) вместо механизма трех копий.

Код стирания (ErasuredCode/EC)

принцип

Существует три распространенных типа кодов стирания: тип Рида-Соломена, каскадные коды стирания с низкой плотностью и коды цифрового фонтана.

Здесь мы лишь кратко представим широко используемые коды стирания Рида-Соломена.

Из базовой формы кода коррекции это структура N данных + M проверка, в которой значения N и M данных и проверки могут быть установлены в соответствии с определенными правилами.

Когда 1~M блоков данных (либо данные, либо контрольные суммы) повреждены, общие данные все еще могут быть получены путем вычисления данных по оставшимся блокам данных, общие данные не будут потеряны, а хранилище по-прежнему доступно.

Как видно из рисунка, затирающее кодирование чем-то похоже на технологию RAID.Полоса (Stripe) состоит из множества блоков данных (Strips), которые делятся на блоки данных и контрольные блоки.

Однако, в отличие от RAID5 и RAID6, самой большой отличительной чертой кодов затирания с функциональной точки зрения является то, что соотношение данных контрольной суммы можно регулировать в соответствии с N+M, а количество контрольных блоков больше не ограничивается двумя. как 12+4, 6+3 и т.д.

Информацию о технологии RAID см. в моем блоге -Статья, чтобы понять, что такое технология RAID

Эволюция кода стирания: RS→LRC

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

Но дополнительное бремя кодирования стирания в основномОбъем вычислений и в несколько раз больше нагрузки на сеть.

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

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

Итак, есть ли возможности для улучшения?

Если вы внимательно проанализируете причину сбоя, то легко обнаружите две характеристики.

1. Все сбои приведут к одинаковой стоимости восстановления, будь то один диск или M дисков.
2. Вероятность отказа одного диска намного выше, чем вероятность одновременного отказа нескольких дисков, обычно выше 90%.

Таким образом, идеи оптимизации естественным образом сходятся на более склонном к отказу одного диска.

Как более эффективно справиться с таким высоковероятным событием?

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

LRC

LRC (локально восстанавливаемые коды) означает локальный код проверки, и его основная идея заключается в следующем:

Блоки проверки делятся на блоки глобальной проверки и блоки локальной проверки и рассчитываются группами во время устранения неисправности.

В качестве примера возьмем реализацию облачного хранилища Microsoft Azure (Windows Azure Storage):

1. Он использует кодирование LRC (12, 2, 2), 12 блоков данных кодируются как группа и дополнительно делит 12 блоков данных на две локальные группы, каждая локальная группа включает 6 блоков данных и рассчитывается отдельно. Генерируется локальный контрольный блок. , а затем из всех 12 блоков данных вычисляются два глобальных контрольных блока.
2. При возникновении любой ошибки блока данных исходные данные можно восстановить, просто используя блоки данных и проверки в локальной группе для расчета.
3. Стоимость восстановления (количество блоков данных, передаваемых по сети) изменена с 12, закодированных традиционным RS (124), на 6, накладные расходы сети 10 на процесс восстановления уменьшены вдвое, а коэффициент пространственной избыточности остается неизменным, который по-прежнему (12+2+2)/12=1,33

Суммировать

По сравнению с копированием, технология кодирования стирающего кода (Erasure Code), несомненно, значительно улучшит использование дискового пространства, однако из-за введения дополнительных операций кодирования и декодирования вычислительная мощность и сеть распределенной системы имеют определенные последствия. дополнительные требования. Простое понимание состоит в том, что производительность оборудования должна быть обновлена, а сетевое окружение также должно быть обновлено.Стоимость обновления на данном этапе все еще является большим бюджетом.

Однако из-за потери производительности он явно не подходит для онлайн-хранилищ, которые и без того находятся под большой нагрузкой и очень «горячие», поэтому большинство систем по-прежнему используют Erasure Code для офлайн-обработки холодных данных.

Поскольку LRC-кодирование уменьшает объем данных, передаваемых по сети 100, объем данных, задействованных в операции восстановления данных, и время восстановления могут быть в основном удвоены, но это происходит за счет снижения надежности и использования пространства.

HDFS RAID(Facebook)

1. Решение HDFS RAID создано Facebook в ветке Hadoop0.20-append.Чтобы не усложнять задачу, оно основано на HDFS без модификации HDFS и поддерживает только автономный (асинхронный) EC.
2. Узел RAID периодически сканирует конфигурацию и обнаруживает, что процесс преобразования файла, который необходимо преобразовать в EC, можно рассчитать локально или с помощью задач MapReduce.
3. Внутри RAID-узла есть поток BlockFixer, который периодически проверяет путь к файлу, настроенный как EC.Если в файле есть потерянные или поврежденные блоки, его необходимо пересчитать локально или через задание MapReduce, а затем сгенерированные блоки вставляются в файл. система.
4. Клиентской стороне не нужно изменять какой-либо код, просто измените конфигурацию, чтобы указать, что используемая файловая система — это DistributedRaidFileSystem.
5. Он инкапсулирует DFSClient и перехватывает запрос клиента DFS.Когда клиент DFS генерирует исключение ChecksumException или Block MissingException, DRFS перехватывает эти исключения, находит соответствующий файл четности, затем пересчитывает потерянный блок и возвращает его клиенту.

Общая структура HDFS RAID

Реализация HDFS RAID (реализация Facebook) в основном добавляет оболочку Contrib к существующей HDFS, как показано на рисунке. Причина, по которой он не изменяется напрямую в HDFS, заключается в том, что первоначальное объяснение разработчика состоит в том, что основной код HDFS уже достаточно сложен и не хочет его усложнять.

1. С точки зрения использования существует два основных сценария использования HDFS RAID: управление данными RAID и чтение данных RAID.
2. RAID-узел — это третий MasterNode, отличный от NameNode и ResourceManager в HDFS RAID.Он в основном используется для получения RPC-запросов от клиента и планирования каждого потока демона для завершения RAID-массизации данных, восстановления данных, удаления файла четности и других операций.

Подробное объяснение процессов RAID и unRAID

RAID-массив данных

Существует два сценария для RAID-массивов файловых данных.

1. Запускается выполнением команды raidFile через RAID Shell;
2. Поток TriggerMonitor периодически сканирует Политику и выполняет соответствующую операцию RAID в соответствии с новой информацией о конфигурации.

Восстановление поврежденных данных

триггерная сцена

1. Потеря данных или длительное повреждение происходят, когда клиент использует DRFS для чтения данных.
2. BlockIntegrityMonitor на узле RAID периодически получает блочные данные и обнаруживает, что данные неверны.
3. При выполнении fixblock через RAID Shell

Процесс восстановления поврежденных данных при чтении блока

1. В случае, когда DRFS настроена на стороне клиента и в качестве встроенной ФС используется DFS, при получении файла InputStream через FS.open возвращается экземпляр ExtFSDataInputStream.
2. При чтении данных через InputStream сначала прочитайте блок ответа через встроенную DFS и верните требуемые данные при нормальных обстоятельствах.
3. Когда встроенная DFS считывает блок, если возникает исключение CorruptionException или DecomissionException, оно будет перехвачено ExtFSDataInputStream. Получите восстановленный блок, вызвав метод RaidNode.unRaidCorruptionBlock(), и прочитайте данные из блока.

Исправление ветки Block Monitor

Поток BlockIntegrityMonitor на узле RAID проверяет систему на наличие конфликтующих или недопустимых данных с помощью инструмента проверки файлов, а затем периодически восстанавливает эти данные с помощью потоков BlockCopier и BlockFixer.

В локальном режиме процесс восстановления выполняется на RaidNode, а в режиме Dist процесс восстановления завершается кластером путем отправки задания.

HDFS-7285

1. Интеграция EC в HDFS

В отличие от HDFS RAID, HDFS-7285 интегрирует процесс кодирования в HDFS, что требует модификации всей внутренней реализации HDFS, включая DataNode, NameNode и клиент DFS. Решение поддерживает как онлайн, так и оффлайн EC.

2. Резюме: HDFS-7285 является более полным и производительным, чем HDFS RAID, а онлайн-EC позволяет сразу же снизить затраты на хранение.

Ozone

HDFS — это блочное хранилище на уровне приложений.Чтобы поддерживать нефайловую природу системных данных, Hortonworks улучшила HDFS, интегрированное блочное хранилище и хранилище объектов, а также предложила Ozone расширить HDFS от файловой системы до более сложных корпоративных приложений.

В прошлом архитектура HDFS разделяла управление метаданными и хранилище данных на два отдельных уровня.

Данные файлов хранятся на уровне хранения, содержащем тысячи серверов хранения (узлов), а метаданные хранятся на уровне метаданных файлов.

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

Ozone позволяет слою блочного хранилища HDFS дополнительно поддерживать нефайловую природу системных данных, а файловая блочная архитектура HDFS также будет поддерживать хранение ключей-значений и объектов.

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

Hortonworks считает, что HDFS естественным образом превратится в полноценную корпоративную систему хранения больших данных, а исходный код Ozone также будет открыт как проект Apache (HDFS-7240).

vSAN

HDFS — это блочное хранилище, вдохновленное статьей Google, но HDFS следует понимать как хранилище прикладного уровня.Программа полностью встроена в обычное пользовательское пространство ОС, а надежность хранилища гарантируется «буйными» тремя копиями.

Для доступа к HDFS требуется выделенный интерфейс, поэтому HDFS подходит только для простого программного обеспечения блочного хранения в домене Hadoop и не хранит многие корпоративные функции, такие как моментальные снимки, дедупликация и т. д.

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

С развитием распределенных технологий некоторые производители, специализирующиеся на системах хранения, естественно, задумываются об использовании серверов общего назначения для хранения данных, поэтому у них есть ряд решений, наиболее известным из которых является Virtual SAN от Vmware.

Технология кодирования удаления файлов Hadoop 3.x

В контексте ЕС чередование имеет несколько ключевых преимуществ.

Во-первых, он включает EC в режиме онлайн (немедленно записывает данные в формате EC), избегает фазы преобразования и немедленно экономит место для хранения.

Online EC также повышает производительность последовательного ввода-вывода за счет параллельного использования нескольких дисковых шпинделей, что особенно желательно в кластерах с высокопроизводительной сетью.

Во-вторых, он естественным образом распределяет небольшой файл по нескольким узлам данных и устраняет необходимость объединять несколько файлов в одну группу кодирования. Это значительно упрощает операции с файлами, такие как удаление, создание отчетов о квотах и ​​миграция между федеративными пространствами имен.

В типичном кластере HDFS на небольшие файлы может приходиться более трех четвертей всего объема хранилища. Чтобы лучше поддерживать небольшие файлы, на первом этапе работы HDFS поддерживает чередование EC.

В будущем HDFS также будет поддерживать непрерывную компоновку EC. См. проектную документацию и обсуждение для HDFS-7285 для получения дополнительной информации.

Расширение NameNode

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

Чтобы уменьшить потребление памяти NameNode для этих дополнительных блоков, вводится новый протокол иерархического именования блоков.

Идентификатор группы блоков можно вывести из идентификатора любого из ее внутренних блоков.

Это позволяет управлять на уровне группы блоков, а не на уровне блоков.

клиентское расширение

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

На пути вывода/записи DFSStripedOutputStream управляет набором потоков данных, по одному для каждого узла данных, сохраняя внутренний блок в текущей группе блоков.

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

На пути ввода/чтения DFSStripedInputStream преобразует запрошенный диапазон логических байтов данных во внутренние блоки, хранящиеся в узлах данных.

Затем он параллельно выдает запросы на чтение. В случае сбоя он выдает дополнительный запрос на чтение для декодирования.

Расширение узла данных

DataNode запускает дополнительную задачу ErasureCodingWorker (ECWorker) для фонового восстановления сбойных блоков Erasure Coding.

Неудачные блоки EC обнаруживаются NameNode, а затем выбираются узлы данных для восстановления. Задачи восстановления доставляются в виде откликов пульса.

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

При восстановлении будут выполняться три ключевые задачи.

1. Чтение данных с исходных узлов. Используйте выделенный пул потоков для параллельного чтения входных данных с исходных узлов. В соответствии с политикой EC он отправляет запросы на чтение всем исходным целевым объектам и считывает только минимальное количество входных блоков для реконструкции.
2. Декодируйте данные и сгенерируйте выходные данные: декодируйте новые данные и блоки четности из входных данных. Все отсутствующие блоки данных и четности декодируются вместе.
3. Перенесите полученный блок данных на целевой узел данных: после завершения декодирования восстановленный блок передается на целевой узел данных.

Политика кодирования стирания файлов

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

Политики кодирования Erasure инкапсулируют то, как файлы кодируются/декодируются.

Каждая политика определяется следующей информацией:

1. Режим EC: включает количество блоков данных и четности в группе EC (например, 6+3) и алгоритм кодека (например, Reed-Solomon, XOR).
2. Размер чередующейся ячейки: определяет степень детализации чередования операций чтения и записи, включая размер буфера и работу кодирования.

Стратегия называется кодек-номер блоков данных-номер блоков четности-размер ячейки.

В настоящее время поддерживаются пять встроенных стратегий: RS-3-2-1024k, RS-6-3-1024k, RS-10-4-1024k, RS-LEGACY-6-3-1024k, XOR-2-1- 1024к.

Также поддерживается схема репликации по умолчанию. Его можно установить только для каталога, чтобы заставить каталог принять схему 3-кратной репликации вместо наследования стратегии кодирования стирания его предков. Эта стратегия позволяет чередовать каталог схемы 3-кратной репликации с каталогом, кодированным стиранием.

Репликация всегда включена. Во всех политиках EC RS(6,3) включен по умолчанию.

Подобно политикам хранения HDFS, политики кодирования затирания устанавливаются для каталогов. Когда файл создается, он наследует политику EC своего ближайшего каталога-предка.

Политики EC уровня каталога влияют только на новые файлы, созданные в каталоге. После того, как файл создан, его политику кодирования удаления можно запросить, но нельзя изменить.

Если вы удалите закодированный файл, переименовав его в каталог с другой политикой EC, файл сохранит существующую политику EC.

Преобразование файла в другую политику EC требует перезаписи его данных; сделайте это, скопировав файл (например, через distcp), а не переименовав его.

Для distcp, пожалуйста, обратитесь к моему блогу -Что такое дистсп? Как передавать данные между двумя кластерами HDFS?

Мы позволяем пользователям определять свои собственные политики EC с помощью XML-файла, который должен включать следующие три части:

1. Версия макета: представляет собой версию формата XML-файла политики ЕС.
2. Режимы: Сюда входят все определяемые пользователем режимы EC.
3. Политики: Сюда входят все определяемые пользователем политики EC, каждая из которых состоит из идентификатора шаблона и размера ячейки чередования.

Пример XML-файла политики EC с именем user_ec_policies.xml.template находится в каталоге Hadoop conf, и пользователи могут на него ссылаться.

Intel ISA-L

Intel ISA-L расшифровывается как Intel Intelligent Storage Acceleration Library.

ISA-L — это набор оптимизированных низкоуровневых функций с открытым исходным кодом, предназначенных для приложений хранения.

Он включает быстрые коды стирания типа Рида-Соломона, оптимизированные для наборов инструкций Intel AVX и AVX2.

Коды стирания HDFS могут использовать ISA-L для ускорения вычислений кодирования и декодирования.

ISA-L поддерживает большинство основных операционных систем, включая Linux и Windows.

По умолчанию ISA-L не включен.