Embed Size (px)
Citation preview
Big Data’15Лекция I: распределенные файловые системы
Дмитрий Барашев[email protected]
Computer Science Center
17 февраля 2015
Этот материал распространяется под лицензией
Creative Commons ”Attribution - Share Alike” 3.0http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru
сверстано в онлайн LATEX редакторе
P
a
peeriapapeeria.com
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
Начнём с хранения
▶ Грузовик данных где-то надо хранить▶ Ты слышал, что в Google для этого используетсяDFS1 aka «распределённая файловая система»
▶ Может тебе она тоже нужна?
1Distributed File System
..
“A distributed system is a system where I can’tget any work done if a machine I’ve neverheard of crashes.L. Lamport .. ”
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
Нужна ли тебе DFS?
Может быть и нетЗависит от характеристик твоих данных
Размер
▶ Данные не помещаются на локальный диск?▶ Это коллекция фоточек и фильмов?
▶ Купи двухтерабайтный внешний диск и забудьпро DFS
Размер
▶ Данные не помещаются на локальный диск?▶ Это коллекция фоточек и фильмов?▶ Купи двухтерабайтный внешний диск и забудьпро DFS
Обновления
▶ Новые данные поступают постоянно?▶ Ты собираешься с ними что-то делать?
▶ Если нет, то записывай их на ленту или HDD изабудь про DFS
Обновления
▶ Новые данные поступают постоянно?▶ Ты собираешься с ними что-то делать?▶ Если нет, то записывай их на ленту или HDD изабудь про DFS
Использование
▶ Твои пользователи читают и пишут данныеконкурентно?
▶ Они переживут downtime до 15 минут?
▶ Установи файл-сервер с журналированием ирезервными копиями и забудь про DFS
Использование
▶ Твои пользователи читают и пишут данныеконкурентно?
▶ Они переживут downtime до 15 минут?▶ Установи файл-сервер с журналированием ирезервными копиями и забудь про DFS
Может и правда не нужна?
▶ У тебя много данных и ты их обрабатываешь?▶ Ты готов увеличить число процессоров в N раз,если это сделает обработку в N раз быстрее?
▶ Твои пользователи читают большиепоследовательные фрагменты?
▶ Они будут очень огорчены сбоем диска илиблока питания?
▶ Тебе, наверное, надо вспомнить прокакую-нибудь DFS
Может и правда не нужна?
▶ У тебя много данных и ты их обрабатываешь?▶ Ты готов увеличить число процессоров в N раз,если это сделает обработку в N раз быстрее?
▶ Твои пользователи читают большиепоследовательные фрагменты?
▶ Они будут очень огорчены сбоем диска илиблока питания?
▶ Тебе, наверное, надо вспомнить прокакую-нибудь DFS
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
Файловая система
▶ Модель данных, программные компоненты,персистентные структуры данных и API
▶ Предоставляет абстракцию для доступа кданным, находящимся на каком-то физическомносителе
▶ Традиционная модель▶ Файл: объект с именем и бессмысленным для ФСсодержанием
▶ Каталог: список файлов и вложенных каталогов▶ Каталоги и файлы образуют дерево –пространство имен
▶ Файл уникально идентифицируется путем:/usr/bin/vim
Метаинформация
▶ Для пользователя информация – этосодержание файлов
▶ Для ФС интереснее метаинформация: названиефайла, список блоков, время модификации,права доступа
Локальные файловые системы
▶ Более или менее тесно интегрированы с ядром▶ Обычно хранят данные на локальном HDD▶ Блоки размером несколько килобайт▶ Могут кешировать страницы
Локальные ФС: Linux
картинка с IBM developerWorks
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
Распределенная ФС
▶ Модель примерно та же▶ Компоненты распределены по разным машинам▶ Распределенность существенно влияет нанекоторые решения
Компоненты РФС
▶ Клиент: API для прикладных приложений и коддля коммуникации с сервером
▶ Серверы файлов: хранят содержимое файлов▶ Серверы метаданных: знают, какой файл гдележит и многое еще
Аспекты функционирования
▶ Прозрачность размещения файлов▶ Совместный доступ▶ Кеширование▶ Репликация▶ Единая точка отказа▶ Наличие состояния▶ Шаблоны доступа▶ Масштабируемость▶ API
Прозрачность размещения файлов
▶ Прикладному приложению известен только путь▶ Чем меньше информации о физическомрасположении закодировано в путь, тем лучше
▶ …при сохранении здравого смысла
Пример 1/192.168.0.10/sda1/home/alice/kitten.jpgтут пожалуй информации многовато
Пример 2/TheEarth/home/alice/kitten.jpgа тут ФС придется самостоятельно выбрать континент
Прозрачность размещения файлов
▶ Прикладному приложению известен только путь▶ Чем меньше информации о физическомрасположении закодировано в путь, тем лучше
▶ …при сохранении здравого смысла
Пример 1/192.168.0.10/sda1/home/alice/kitten.jpgтут пожалуй информации многовато
Пример 2/TheEarth/home/alice/kitten.jpgа тут ФС придется самостоятельно выбрать континент
Совместный доступ и кеширование
▶ Централизованная система: атомарные чтениеи запись; блокировки; журналирование
▶ Распределенная ФС: сетевые задержки,репликация усложняют жизнь
Варианты управления совместнымдоступом
▶ синхронные чтение и запись▶ write-through cache: чтение из кеша, синхроннаязапись
▶ сессионное кеширование: чтение и запись вкеш, синхронизация при закрытии, политикаопределения победителя при конкурирующейзаписи
▶ файлы после создания становятсянеизменяемыми
▶ запись возможна только в конец (append-only)▶ клиенты, открывшие файл уведомляются озаписях
▶ полноценные транзакции
Репликация
▶ Синхронная или асинхронная▶ Политика согласованности реплик▶ Запись в реплики
Единая точка отказа
▶ Сбой в единой точке отказа2 делаетнеработоспособной всю систему
▶ Сервер метаданных – кандидат на SPoF▶ …и еще и на узкое место
▶ Два сервера метаданных – кандидаты нанесогласованность
2Single Point of Failure
Наличие состояния
▶ Сервер с состоянием (stateful) знает все прооткрытые файлы в данный момент
▶ тратит на это память и больно падает▶ но зато может кое-какие операцииоптимизировать
▶ Сервер без состояния (stateless) возможнобудет повторять действия при каждом запросе
▶ но зато быстро восстановится после падения▶ У сервера метаданных всегда есть состояние
Шаблоны доступа
▶ Какого размера типичный файл?▶ Что важнее – надежность или скорость?▶ Что важнее – среднее время одного случайногочтения или суммарная пропускная способностьпоследовательного чтения?
Масштабируемость
▶ Хочется линейную▶ было N дисков и K машин▶ стало ×2 данных – добавили N дисков, сохранилипропускную способность
▶ нужна в два раза большая пропускнаяспособность – добавили K машин, распределилиданные
▶ На практике у линейной масштабируемостимножество препятствий
▶ пропускная способность сети, сетевыхинтерфейсов файловых серверов,производительность сервера каталогов,блокировки
Предоставляемый API
▶ POSIX: такой же как у локальных ФС, не нужноменять прикладные программы
▶ Какой-то свой, в связи с ограничениями илидополнительными возможностями
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
NFS
▶ Network File System▶ Рождена Sun’ом в начале 1980-х и жива-здоровадо сих пор, используется во многих корпорациях
▶ POSIX API, клиент монтирует удаленный диск влокальный каталог
▶ На сервере NFS демон тоже работает состандартным интерфейсом файловой системы
▶ Поддерживаются блокировки и сессионноекеширование
NFS
картинка с IBM developerWorks
AFS
▶ Andrew File System. Рождена в университетеCarnegie Mellon в 1980-х
▶ Сессионное кеширование, нотификации обизменениях, блокировки файлов
▶ Моментальные read-only снимки томов▶ Не POSIX API
и другие
▶ CIFS, aka Samba, aka Windows Shared Folders▶ Ceph, GlusterFS, Lustre, <add your file systemhere>
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
Братья или однофамильцы?
▶ GFS – закрытая реализация, подробноописанная в статье
▶ HDFS – открытая реализация, построенная попринципам GFS. Рождена в Apache SoftwareFoundation.
▶ Позднее за HDFS взялась Yahoo, и сейчас HDFSиспользуется повсеместно
▶ QFS: реализация на C++
Предпосылки
▶ Начало 2000-х, Google завоевывает поиск▶ Большие файлы (порядка N Gb) записываются ичитаются пакетными процессами (crawler,indexer)
▶ Пропускная способность важнее быстрогослучайного доступа
▶ Ширпотребные компьютеры, в совокупностичасто выходящие из строя
Основные моменты архитектуры▶ Много файловых серверов3, один активныйсервер метаданных (мастер)
▶ Файлы хранятся фрагментами4 по 64Mb▶ Каждый фрагмент реплицируется на 3различных файловых сервера
▶ Приоритетные операции с файлом: большоепоследовательное чтение и конкурентноенаращивание
▶ Метаданные клиент получает от мастера,данные непосредственно от файловых серверов
▶ Клиент может кешировать метаданные, но некеширует содержимое файлов
▶ POSIX API не поддерживается3chunk server4chunk
Развертывание GFS
▶ Ячейка5 – единица развертывания▶ В ячейке один мастер и много файловыхсерверов
▶ Ячейка GFS примерно соответствуетфизическому датацентру
5cell
Архитектура GFS-ячейки
Обязанности мастера
▶ Поддерживать пространство имен и егоотображение во фрагменты
▶ Обзвон файловых серверов, «проверка связи»,выдача указаний, сбор состояния
▶ Размещение фрагментов при их создании,дополнительной репликации илиперебалансировке
▶ Пересылка данных, однако, осуществляетсянапрямую между репликами и/или клиентом
Метаданные
▶ Пространство имён▶ Отображение имени файла в список фрагментов▶ Расположение реплик каждого фрагмента
Мутации метаданных
▶ Метаданными управляет мастер в своейоперативной памяти
▶ Теневые серверы дублируют его действия▶ Изменения метаданных атомарны,изолированны и долговечны
▶ в пространстве имен используютсяиерархические блокировки
▶ мутации метаданных журналируются и журналреплицируется на теневых серверах
▶ Пространство имён и отображениефайл-фрагменты хранятся долговечно.
▶ Расположение фрагментов собирается впроцессе созвона с файловыми серверами
Свойства фрагмента
▶ При создании получает уникальныйнеизменный идентификатор и номер версии
▶ При мутациях номер версии увеличивается
Взаимодействие клиента и мастера причтении
▶ Приложение собирается прочитать фрагмент▶ GFS библиотека звонит мастеру, тот возвращаетадреса реплик – файловых серверов, хранящихфрагмент – и актуальный номер версии
▶ GFS библиотека напрямую звонит одному изфайловых серверов с просьбой вернуть нужныйдиапазон внутри данного фрагмента
▶ Дальнейшее общение клиента и файловогосервера идет напрямую
▶ Если реплика сообщает, что её фрагмент имеетменьший номер версии, то значит она протухла.Клиент обращается к другой.
Взаимодействие при записи
1. Приложение хочет записать данные вфрагмент, хранящийся на нескольких репликах
2. Мастер выбирает главную по записи среди всехреплик
3. Клиент получает адреса всех реплик ипередает им данные
4. Когда все реплики получили данные, клиентпосылает главной указание произвести запись
5. Главная реплика выбирает порядок применениямутаций, применяет их локально и рассылаетрепликам указание синхронно применитьмутации в том же порядке
6. Если все хорошо то клиент счастлив
А что если не все хорошо?
Взаимодействие при записи
1. Приложение хочет записать данные вфрагмент, хранящийся на нескольких репликах
2. Мастер выбирает главную по записи среди всехреплик
3. Клиент получает адреса всех реплик ипередает им данные
4. Когда все реплики получили данные, клиентпосылает главной указание произвести запись
5. Главная реплика выбирает порядок применениямутаций, применяет их локально и рассылаетрепликам указание синхронно применитьмутации в том же порядке
6. Если все хорошо то клиент счастливА что если не все хорошо?
Модель согласованности▶ Характеристики байтового региона:согласованный и определенный
▶ Регион согласован6, если у него одинаковоезначение во всех репликах
▶ Регион определен7 после записи, если онсогласован и клиенты видят ровно те данные,которые были записаны
▶ Успешная запись при отсутствииконкурирующих записей производитопределённый регион
▶ Конкурирующие успешные записи могутпроизвести согласованные, но неопределённыеданные
6consistent7defined
Атомарная операция наращивания▶ Гарантия: успешная операция наращиванияпроизводит согласованный определённыйрегион, смещение которого определяет GFS
▶ В «хорошем» случае все почти как в операциипроизвольной записи
▶ Главная реплика назначает смещение и можетпопросить произвести запись в следующийфрагмент, если в текущем нет места
▶ В «плохом» случае клиент повторяет операцию,и главная реплика назначает новое смещение
▶ Результат: в некоторых репликах могут бытьдубликаты, полные или частичные добавляемыхданных, но рано или поздно появитсясогласованный определённый регион
Реплики фрагмента не являются бинарноидентичными!
Атомарная операция наращивания▶ Гарантия: успешная операция наращиванияпроизводит согласованный определённыйрегион, смещение которого определяет GFS
▶ В «хорошем» случае все почти как в операциипроизвольной записи
▶ Главная реплика назначает смещение и можетпопросить произвести запись в следующийфрагмент, если в текущем нет места
▶ В «плохом» случае клиент повторяет операцию,и главная реплика назначает новое смещение
▶ Результат: в некоторых репликах могут бытьдубликаты, полные или частичные добавляемыхданных, но рано или поздно появитсясогласованный определённый регион
Реплики фрагмента не являются бинарноидентичными!
Схема наращивания
Неопределённые данные
▶ И произвольная запись и наращивание могутпроизвести неопределённые и несогласованныерегионы
▶ Выяснение осмысленности хранящихся врегионе данных становится заботойприложения
▶ контрольные суммы записи▶ контрольные точки в файле
Время жизни главной реплики
▶ Главная реплика назначается мастером иполучает билет8 на 60 секунд
▶ Если билет просрочен, главная реплика неимеет права осуществлять операции записи
▶ Билет можно продлевать▶ Каждый новый билет, выданный главнойреплике, увеличивает номер версии фрагмента
▶ Мастер может отобрать билет раньше срока
8lease
Операция фиксации состояния
▶ Фиксация состояния9 делает почти мгновеннуюкопию файла или каталога методомcopy-on-write
▶ отбираются все выданные билеты▶ делается копия метаданных дерева▶ новые файлы ассоциируются с оригинальнымифрагментами
▶ Когда кто-то захочет изменить данные, онзапросит адрес главной реплики фрагмента
▶ В этот момент мастер распорядится создатьфрагмент-копию
9snapshot
Проблемы файлового сервера
▶ Данные на файловом сервере могутповредиться из-за аппаратного илипрограммного сбоя
▶ ФС может проспать мутацию фрагмента и егофрагмент протухнет (номер версии меньше чемна мастере)
Целостность данных
▶ Фрагменты разбиваются на блоки размером64Kb и для каждого блока считаетсяконтрольная сумма
▶ Контрольные суммы хранятся в памяти ижурналируются отдельно от данных
▶ При чтении файловый сервер сравнивает КСблока с записанной и в случае противоречиябьёт в набат
Устаревшие фрагменты, удалениефайлов и сборка мусора
▶ Фрагмент может устареть▶ Стратегия удаления
▶ отметить как удалённый и переместить в Trash,записав момент удаления
▶ через некоторое время удалить из метаданныхсовсем
▶ Стратегия сбора мусора▶ Файловые серверы сообщают мастеру IDхранимых фрагментов
▶ Мастер смотрит в свои метаданные:отображение файла во фрагменты
▶ Первое множество без второго = мусор▶ Файловый сервер удаляет мусор по своемуусмотрению
Требования меняются
▶ Google 2010-х годов – это интерактивныеприложения
▶ Файлов больше, их размер меньше▶ Речь уже об эксабайтах▶ Требования по времени произвольного доступажестче
▶ GFS ячейка достигает предела возможностейпри количестве файлов 50M и объеме несколькопетабайт
GFS в Google больше не используется, на сменупришел Colossus
Требования меняются
▶ Google 2010-х годов – это интерактивныеприложения
▶ Файлов больше, их размер меньше▶ Речь уже об эксабайтах▶ Требования по времени произвольного доступажестче
▶ GFS ячейка достигает предела возможностейпри количестве файлов 50M и объеме несколькопетабайт
GFS в Google больше не используется, на сменупришел Colossus
Colossus
▶ Шардированные метаданные▶ Простая репликация заменена кодамиРида-Соломона
▶ Подробности практически неизвестны
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File System/Hadoop File System
Бонус трек
ФС без сервера метаданных
▶ Применяем хеш к полному имени файла иполучаем номер(а) файловых серверов
▶ Если файл переименовывается, он оставляетсвой новый адрес на старом месте
▶ Если нужно увеличить число файловыхсерверов, используем схему, похожую наextensible hashing
▶ Реализация: GlusterFS
Недостатки репликации
▶ N реплик – это конечно хорошо, но …▶ Диска тратится в N раз больше▶ Выхода из строя всего N машин достаточночтобы потерять 1 фрагмент
Алгоритмы коррекции ошибок
▶ Уменьшение избыточных данных▶ Повышение надежности: чтоб потерять данныенужно вывести из строя существенно большемашин
▶ Reed-Solomon encoding: n исходных дисков + mконтролирующих гарантируют восстановлениепри выходе из строя любых k <=m дисков
▶ Конфигурация n = 8,m = 4 надежнее обычнойрепликации с фактором 3 и требует в два разаменьше места
Алгоритмы коррекции ошибок
▶ Уменьшение избыточных данных▶ Повышение надежности: чтоб потерять данныенужно вывести из строя существенно большемашин
▶ Reed-Solomon encoding: n исходных дисков + mконтролирующих гарантируют восстановлениепри выходе из строя любых k <=m дисков
▶ Конфигурация n = 8,m = 4 надежнее обычнойрепликации с фактором 3 и требует в два разаменьше места
Литература I
Alex Davies and Alessandro Orsaria.Scale out with glusterfs.Linux J., 2013(235), November 2013.Sanjay Ghemawat, Howard Gobioff, and Shun-TakLeung.The Google file system.In ACM SIGOPS Operating Systems Review,volume 37, pages 29–43. ACM, 2003.M. Tim Jones.NFS: удобная и перспективная сетевая файловаясистема.http://www.ibm.com/developerworks/ru/library/l-network-filesystems/index.html/.Accessed: 23.01.2013.
Литература II
M. Tim Jones.Анатомия файловой системы Linux.http://www.ibm.com/developerworks/ru/library/l-linux-filesystem/.Accessed: 23.01.2013.James S. Plank et al.A tutorial on Reed-Solomon coding forfault-tolerance in RAID-like systems.Software Practice and Experience, 27(9):995–1012,1997.В.Г. Олифер and Н.А. Олифер.Сетевые операционные системы.Питер, 2002.
