Библиотека сайта 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.4. Практическое использование файловой системы в компании Yahoo!
Кластеры HDFS большого размера в компании Yahoo! включают в свой состав около 4000 серверов. Типичный сервер кластера имеет два четырехядерных процессора Xeon, работающих с тактовой частотой 2.5 ГГц, 4-12 подключенных напрямую жестких диска SATA (каждый объемом в два терабайта), 24 ГБ оперативной памяти и соединение Ethernet со скоростью 1 ГБит/с. Семьдесят процентов объема дискового пространства выделено для файловой системы HDFS. Остальное пространство зарезервировано для операционной системы (Red Hat Linux), файлов журнала, а также для записи выходных данных системы MapReduce (промежуточные данные системы MapReduce не хранятся в файловой системе HDFS).
Сорок серверов из одной стойки совместно используют IP-свитч. Свитчи стоек подключены к каждому из восьми центральных свитчей. Центральные свитчи позволяют установить соединение между стойками и ресурсами за границами кластера. В каждом кластере сервер метаданных и сервер резервных копий снабжаются объемом оперативной памяти до 64 ГБ; приложения никогда не выполняются на этих серверах. В общем, кластер из 4000 серверов располагает 11 ПБ (петабайт равен 1000 терабайтам) доступного дискового пространства для хранения трехкратно скопированных блоков, при этом 3.7 ПБ дискового пространства доступно для пользовательских приложений. В течение многих лет эксплуатации файловой системы HDFS, серверы из состава кластера улучшали свои характеристики благодаря использованию новых технологий. Новые серверы кластера всегда имели более производительные процессоры, большие объемы дискового пространства и оперативной памяти. Более медленные серверы с меньшими объемами дискового пространства выводились из эксплуатации или перемещались в кластеры, зарезервированные для использования в процессе разработки и тестирования Hadoop.
На примере кластера большого размера (из 4000 серверов) можно рассмотреть процесс обслуживания 65 миллионов файлов и 80 миллионов блоков. Так как каждый блок обычно подвергается трехкратной репликации, каждый сервер данных приложений хранит 60000 копий блоков. Каждый день пользовательские приложения создают по два миллиона новых файлов на каждом кластере. Кластер из 40000 серверов компании Yahoo! позволяет использовать сетевое хранилище объемом 40 ПБ.
Переход проекта в разряд ключевых компонентов набора технологий компании Yahoo! подразумевает появление ряда технических проблем, возникающих из-за отличия исследовательского проекта от проекта, отвечающего за сохранность множества петабайт корпоративных данных. Прежде всего эти проблемы связаны с устойчивостью работы системы и надежностью хранения данных. Но также важны и экономическая эффективность, возможность совместного использования ресурсов членами сообщества пользователей и простота обслуживания администраторами системы.
8.4.1. Долговечность хранения данных
Трехкратная репликация данных является надежной мерой, направленной против потери данных в результате непредсказуемых отказов серверов. Едва ли компания Yahoo! когда-нибудь пострадала от потери блока в таких обстоятельствах; для кластера большого размера значение вероятности потери блока в течение одного года меньше 0.005. Ключевым для понимания является тот факт, что около 0.8 процентов серверов выходят из строя в течение каждого месяца. (Даже если работоспособность сервера в конечном счете будет восстановлена, попыток восстановления хранившихся на нем данных обычно не предпринимается.) Таким образом, описанный в примере выше кластер больших размеров теряет каждый день один или два сервера. Этот же кластер повторно создаст копии 60000 блоков, хранившихся на отказавшем сервере, примерно за две минуты: повторная репликация проходит быстро, так как она выполняется в параллельном режиме и масштабируется в зависимости от размера кластера. Вероятность отказа нескольких серверов с копиями одного блока в течение двух минут, приводящего к утрате данных блока, достаточно низка.
Непредсказуемый отказ множества серверов является другой угрозой. В данном случае наиболее часто наблюдаемым является отказ свитча стойки или центрального свитча. Файловая система HDFS допускает потерю свитча стойки (каждый блок имеет копию на сервере из другой стойки). Некоторые неисправности центрального свитча могут действительно привести к отсоединению части стоек от кластера и в таком случае часть блоков может оказаться недоступной. В любом случае, восстановление работы свитча позволяет восстановить недоступные для кластера копии блоков. Другим непредсказуемым типом отказа является случайное или преднамеренное отключение электроснабжения кластера. Если отключение электроснабжения затрагивает стойки, скорее всего некоторые блоки станут недоступны. Но восстановление электроснабжения не избавит от проблем, так как половина процента серверов не переживет перезагрузку в результате отключения электроснабжения. По статистике, которая подтверждается на практике, кластер большого размера будет терять часть блоков в результате перезагрузки из-за отключения электроснабжения.
В дополнение к отказу серверов, хранимые данные также могут быть повреждены или потеряны. Сканер блоков сканирует все блоки кластера большого размера раз в две недели и находит около 20 поврежденных копий блоков в ходе сканирования. Поврежденные блоки заменяются в момент их обнаружения.
8.4.2. Возможности совместного использования ресурсов HDFS
По мере роста масштабов эксплуатации файловой системы HDFS, в нее были добавлены возможности для совместного использования ресурсов большим количеством отдельных пользователей. Первой такой возможностью был фреймворк прав доступа, спроектированный в соответствии со схемой прав доступа Unix для файлов и директорий. В этом фреймворке файлы и директории имели отдельные права доступа для владельца, других членов группы, ассоциированной с данным файлом или директорией, а также для других пользователей. Принципиальным отличием между правами доступа Unix (POSIX) и HDFS является отсутствие у обычных файлов в HDFS разрешений на исполнение и битов "sticky".
В ранних версиях HDFS применялся слабый механизм идентификации: ваше имя сообщалось серверу узлом, с помощью которого вы подключались. При доступе к HDFS клиентское приложение должно предоставить системе имен идентификационные данные, полученные из доверенного источника. Использование других служб управления идентификационными данными также возможно; начальная реализация использует Kerberos. Пользовательское приложение может использовать тот же фреймворк для подтверждения того, что система имен также является подлинной. Также система имен может запросить идентификационные данные у любого сервера данных приложений из состава кластера.
Общий объем доступного дискового пространства задается количеством серверов данных приложений и дисковым пространством каждого из этих серверов. Опыт эксплуатации ранних версий HDFS показал необходимость введения политики ограничения использования ресурсов группами пользователей. Данная политика должна быть введена не только для справедливого распределения ресурсов, но и для защиты от приложений, записывающих данные на множество узлов и исчерпывающих системные ресурсы, что тоже очень важно. В случае с HDFS метаданные всегда хранятся в оперативной памяти, поэтому размер пространства имен (зависящий от количества файлов и директорий) является также конечным ресурсом. Для управления ресурсами хранилища и пространства имен каждой директории должна соответствовать квота, устанавливающая общее дисковое пространство, которое может быть занято файлами в дереве поддиректорий пространства имен, начинающегося с этой директории. Отдельная квота также может быть установлена для общего количества файлов и директорий в этом дереве поддиректорий.
Архитектура файловой системы HDFS предусматривает тот факт, что большинство приложений будут передавать большие объемы данных, а программный фреймворк MapReduce чаще всего генерирует множество небольших результирующих файлов (по одному для каждой задачи), еще больше исчерпывая ресурсы пространства имен. Для удобства дерево директорий может быть упаковано в единственный файл архива Hadoop (Hadoop Archive file). Файл HAR аналогичен привычным файлам архивов tar, JAR или Zip, но операции файловой системы могут применяться к индивидуальным файлам этого архива, а также файл HAR может прозрачно использоваться в качестве исходного файла для выполнения задачи MapReduce.
8.4.3. Масштабирование и объединение файловой системы
Масштабирование сервера метаданных было ключевой задачей при разработке [Shv10]. Так как сервер метаданных хранит пространство имен и данные о расположении блоков в оперативной памяти, объем доступной памяти сервера метаданных ограничивает количество файлов, а также количество адресуемых блоков. Также данное обстоятельство ограничивает дисковое пространство, которое может обслуживаться сервером метаданных. Пользователям предлагается создавать файлы большего размера, но это предложение не выполняется, так как оно требует изменений в поведении приложений. Более того, мы встречаем новые классы приложений для HDFS, которым требуется хранить большое количество файлов малого размера. Для управления использованием диска были добавлены квоты, а также инструмент архивирования, но они не предоставляют фундаментального решения проблемы масштабирования.
Новая функция позволяет использовать несколько независимых пространств имен (и серверов метаданных) для разделения между ними физического дискового пространства кластера. Пространства имен используют блоки, сгруппированные в пул блоков (Block Pool). Пулы блоков аналогичны логическим единицам (LUN) системы хранилищ SAN, а пространство имен вместе с пулом блоков аналогично разделу файловой системы.
Этот подход имеет массу достоинств помимо расширения возможностей масштабирования: появляется возможность изоляции пространства имен различных приложений для улучшения доступности всего кластера. Абстракция в форме пула блоков позволяет другим службам использовать хранилище блоков, возможно, с другой структурой пространства имен. Мы планируем исследовать другие подходы для улучшения масштабирования, такие, как хранение только части данных пространства имен в оперативной памяти и использование действительно распределенной реализации сервера метаданных.
Приложения предпочитают использовать единственное пространство имен. Пространства имен могут монтироваться для работы в такой унифицированной форме. Таблица монтирования на стороне клиента является эффективным методом реализации этой идеи в сравнении с таблицей на стороне сервера: она позволяет избежать использования системы удаленных вызовов процедур (RPC) для взаимодействия с таблицей на стороне сервера, а также не является восприимчивой к отказам. Простейшим подходом является создание разделяемого пространства имен для всего кластера; этот подход может быть реализован путем добавления на стороне клиента аналогичной монтируемой таблицы для каждого клиента кластера. Таблицы монтирования на стороне клиента также позволяют приложениям создавать частные пространства имен. Эти пространства аналогичны пространствам имен процессов, используемым для работы с технологиями удаленного исполнения в распределенных системах [PPT+93, Rad94, RP93].
Далее: 8.5. Выученные уроки и 8.6. Благодарности