технологии хранения и обработкибольших объёмов данныхРаспределённые файловые системы

Дмитрий Барашев19 февраля 2016 г.

Computer Science Center

Этот материал распространяется под лицензией

Creative Commons”Attribution - Share Alike” 3.0

http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru

сверстано в онлайн LATEX редакторе

P

a

peeriapapeeria.com

начнём с хранения

• Грузовик данных где-то надо хранить• Ты слышал, что для этого используется«распределённая файловая система» aka DFS¹

• Может тебе она тоже нужна?

¹Distributed File System

3/67

“Распределённая система – это когдападение неизвестной машины бог весть гдеприводит к тому, что я не могу продолжатьсвою работу.L. Lamport ”

4/67

сегодня в программе

Характеристики данных

Основные концепции

Особенности распределенных ФС

Немного истории

Google File System/Hadoop File System

GlusterFS

5/67

нужна ли тебе dfs?

Может быть и нетЗависит от характеристик твоих данных

6/67

размер

• Данные не помещаются на локальный диск?• Ты их редко читаешь или обновляешь?

• Возможно, достаточно купить диск большегообъёма.

7/67

размер

• Данные не помещаются на локальный диск?• Ты их редко читаешь или обновляешь?• Возможно, достаточно купить диск большегообъёма.

7/67

поток

• Данные поступают с умеренной скоростью(XXМб/сек) ?

• Их предполагается читать?

• Возможно, достаточно диска большего объёмаили магнитной ленты

8/67

поток

• Данные поступают с умеренной скоростью(XXМб/сек) ?

• Их предполагается читать?• Возможно, достаточно диска большего объёмаили магнитной ленты

8/67

использование

• Пользователям важен быстрый произвольныйдоступ?

• Они переживут downtime до 15 минут?

• Возможно, достаточно файл-сервера сжурналированием и резервными копиями

9/67

использование

• Пользователям важен быстрый произвольныйдоступ?

• Они переживут downtime до 15 минут?• Возможно, достаточно файл-сервера сжурналированием и резервными копиями

9/67

может и правда не нужна?

• Данные не помещаются на одном диске ипредполагется их массовая обработка?

• Твои пользователи читают большиепоследовательные фрагменты?

• Пользователи не согласны ждать восстановленияпосле сбоя диска или блока питания?

• Ты мечтаешь о линейной масштабируемости?

• Тебе, наверное, надо вспомнить про какую-нибудьDFS

10/67

может и правда не нужна?

• Данные не помещаются на одном диске ипредполагется их массовая обработка?

• Твои пользователи читают большиепоследовательные фрагменты?

• Пользователи не согласны ждать восстановленияпосле сбоя диска или блока питания?

• Ты мечтаешь о линейной масштабируемости?• Тебе, наверное, надо вспомнить про какую-нибудьDFS

10/67

сегодня в программе

Характеристики данных

Основные концепции

Особенности распределенных ФС

Немного истории

Google File System/Hadoop File System

GlusterFS

11/67

файловая система

• Модель данных, программные компоненты,персистентные структуры данных и API

• Предоставляет абстракцию для доступа к данным,находящимся на каком-то физическом носителе

• Традиционная модель• Файл: объект с именем и бессмысленным для ФСсодержанием

• Каталог: список файлов и вложенных каталогов• Каталоги и файлы образуют дерево –пространство имен

• Файл уникально идентифицируется путем:/usr/bin/vim

12/67

метаинформация

• Для пользователя информация – это содержаниефайлов

• Для ФС интереснее метаинформация: названиефайла, список блоков, время модификации, правадоступа

13/67

локальные файловые системы

• Более или менее тесно интегрированы с ядром• Обычно хранят данные на локальном HDD• Блоки размером несколько килобайт• Могут кешировать страницы

14/67

локальные фс: linux

15/67картинка с IBM developerWorks

сегодня в программе

Характеристики данных

Основные концепции

Особенности распределенных ФС

Немного истории

Google File System/Hadoop File System

GlusterFS

16/67

распределенная фс

• Модель примерно та же• Компоненты распределены по разным машинам• Распределенность существенно влияет нанекоторые решения

17/67

компоненты рфс

• Клиент: API для прикладных приложений и коддля коммуникации с сервером

• Серверы файлов: хранят содержимое файлов• Серверы метаданных²: знают, какой файл гдележит и многое еще

²если они имеются

18/67

аспекты функционирования

• Прозрачность размещения файлов• Совместный доступ• Кеширование• Репликация• Единая точка отказа• Наличие состояния• Шаблоны доступа• Масштабируемость• API

19/67

прозрачность размещения файлов

• Прикладному приложению известен только путь• Чем меньше информации о физическомрасположении закодировано в путь, тем лучше

Пример 1/192.168.0.10/sda1/home/alice/kitten.jpgтут пожалуй информации многовато

• …при сохранении здравого смысла

20/67

прозрачность размещения файлов

• Прикладному приложению известен только путь• Чем меньше информации о физическомрасположении закодировано в путь, тем лучше

Пример 1/192.168.0.10/sda1/home/alice/kitten.jpgтут пожалуй информации многовато

• …при сохранении здравого смысла

Пример 2/TheEarth/home/alice/kitten.jpgа тут ФС придется самостоятельно выбрать континент

20/67

совместный доступ и кеширование

• Централизованная система: атомарные чтение изапись; блокировки; журналирование

• Распределенная ФС: сетевые задержки,репликация усложняют жизнь

21/67

варианты управления совместным доступом

• синхронные чтение и запись• write-through cache: чтение из кеша, синхроннаязапись

• сессионное кеширование: чтение и запись в кеш,синхронизация при закрытии, политикаопределения победителя при конкурирующейзаписи

• файлы после создания становятсянеизменяемыми

• запись возможна только в конец (append-only)• клиенты, открывшие файл уведомляются озаписях

• полноценные транзакции 22/67

репликация

• Синхронная или асинхронная• Политика согласованности реплик• Запись в реплики

23/67

единая точка отказа

• Сбой в единой точке отказа³ делаетнеработоспособной всю систему

• Сервер метаданных – кандидат на SPoF• …и еще и на узкое место

• Два сервера метаданных – кандидаты нанесогласованность

³Single Point of Failure

24/67

наличие состояния

• Сервер с состоянием (stateful) знает все прооткрытые файлы в данный момент• тратит на это память и больно падает• но зато может кое-какие операцииоптимизировать

• Сервер без состояния (stateless) возможно будетповторять действия при каждом запросе• но зато быстро восстановится после падения

• У сервера метаданных всегда есть состояние

25/67

шаблоны доступа

• Какого размера типичный файл?• Что важнее – надежность или скорость?• Что важнее – среднее время одного случайногочтения или суммарная пропускная способностьпоследовательного чтения?

26/67

масштабируемость

• Хочется линейную• было N дисков и K машин• стало ×2 данных – добавили N дисков, сохранилипропускную способность

• нужна в два раза большая пропускнаяспособность – добавили K машин, распределилиданные

• На практике у линейной масштабируемостимножество препятствий• пропускная способность сети, сетевыхинтерфейсов файловых серверов,производительность сервера каталогов,блокировки

27/67

предоставляемый api

• POSIX: такой же как у локальных ФС, не нужноменять прикладные программы

• Какой-то свой, в связи с ограничениями илидополнительными возможностями

28/67

сегодня в программе

Характеристики данных

Основные концепции

Особенности распределенных ФС

Немного истории

Google File System/Hadoop File System

GlusterFS

29/67

nfs

• Network File System• Рождена Sun’ом в начале 1980-х и жива-здоровадо сих пор, используется во многих корпорациях

• POSIX API, клиент монтирует удаленный диск влокальный каталог

• На сервере NFS демон тоже работает состандартным интерфейсом файловой системы

• Поддерживаются блокировки и сессионноекеширование

30/67

nfs

31/67картинка с IBM developerWorks

afs

• Andrew File System. Рождена в университетеCarnegie Mellon в 1980-х

• Сессионное кеширование, нотификации обизменениях, блокировки файлов

• Моментальные read-only снимки томов• Не POSIX API

32/67

и другие

• CIFS, aka Samba, aka Windows Shared Folders• Ceph, GlusterFS, Lustre, QFS, etc.

33/67

сегодня в программе

Характеристики данных

Основные концепции

Особенности распределенных ФС

Немного истории

Google File System/Hadoop File System

GlusterFS

34/67

братья или однофамильцы?

• GFS – закрытая реализация, подробно описаннаяв статье

• HDFS – открытая реализация, построенная попринципам GFS. Рождена в Apache SoftwareFoundation.

• Позднее за HDFS взялась Yahoo, и сейчас HDFSиспользуется повсеместно

• QFS: реализация на C++

35/67

предпосылки

• Начало 2000-х, Google развивает поиск• Большие файлы (порядка NGb) записываются ичитаются пакетными процессами (crawler, indexer)

• Пропускная способность важнее быстрогослучайного доступа

• Ширпотребные компьютеры, в совокупностичасто выходящие из строя

36/67

основные моменты архитектуры

• Много файловых серверов⁴, один активныйсервер метаданных (мастер)

• Файлы хранятся фрагментами⁵ по 64Mb• Фрагменты одного файла могут храниться наразных серверах

• Каждый фрагмент реплицируется на 3 различныхфайловых сервера

⁴chunk server⁵chunk

37/67

основные моменты архитектуры ii

• Приоритетные операции с файлом: большоепоследовательное чтение и конкурентноенаращивание

• Метаданные клиент получает от мастера, данныенепосредственно от файловых серверов

• Клиент может кешировать метаданные, но некеширует содержимое файлов

• POSIX API не поддерживается

38/67

развертывание gfs

• Ячейка⁶ – единица развертывания• В ячейке один мастер и много файловых серверов• Ячейка GFS примерно соответствует физическомудатацентру

⁶cell

39/67

архитектура gfs-ячейки

40/67

обязанности мастера

• Поддерживать пространство имен и егоотображение во фрагменты

• Обзвон файловых серверов, «проверка связи»,выдача указаний, сбор состояния

• Размещение фрагментов при их создании,дополнительной репликации илиперебалансировке

• Пересылка данных, однако, осуществляетсянапрямую между репликами и/или клиентом

41/67

метаданные

• Пространство имён• Отображение имени файла в список фрагментов• Расположение реплик каждого фрагмента

42/67

мутации метаданных

• Метаданными управляет мастер в своейоперативной памяти

• Теневые серверы дублируют его действия• Изменения метаданных атомарны, изолированныи долговечны• в пространстве имен используются иерархическиеблокировки

• мутации метаданных журналируются и журналреплицируется на теневых серверах

• Пространство имён и отображениефайл-фрагменты хранятся долговечно.

• Расположение фрагментов собирается в процессесозвона с файловыми серверами

43/67

свойства фрагмента

• При создании получает уникальный неизменныйидентификатор и номер версии

• При мутациях номер версии увеличивается

44/67

взаимодействие клиента и мастера при чтении

• Приложение собирается прочитать фрагмент• GFS библиотека звонит мастеру, тот возвращаетадреса реплик – файловых серверов, хранящихфрагмент – и актуальный номер версии

• GFS библиотека напрямую звонит одному изфайловых серверов с просьбой вернуть нужныйдиапазон внутри данного фрагмента

• Дальнейшее общение клиента и файловогосервера идет напрямую

• Если реплика сообщает, что её фрагмент имеетменьший номер версии, то значит она протухла.Клиент обращается к другой.

45/67

взаимодействие при записи

• Запись в фрагмент на нескольких репликах• Мастер выбирает реплику-дирижёра записи• Клиент передает данные всем репликам• Когда все реплики получили данные, клиентпосылает главной указание произвести запись

• Главная реплика выбирает порядок применениямутаций, применяет их локально и рассылаетрепликам указание синхронно применитьмутации в том же порядке

• Если все хорошо то клиент счастлив

А ну как если нет?

46/67

взаимодействие при записи

• Запись в фрагмент на нескольких репликах• Мастер выбирает реплику-дирижёра записи• Клиент передает данные всем репликам• Когда все реплики получили данные, клиентпосылает главной указание произвести запись

• Главная реплика выбирает порядок применениямутаций, применяет их локально и рассылаетрепликам указание синхронно применитьмутации в том же порядке

• Если все хорошо то клиент счастлив

А ну как если нет?

46/67

модель согласованности

• Характеристики байтового региона:согласованный и определенный

• Регион согласован (consistent), если у негоодинаковое значение во всех репликах

• Регион определен (defined) после записи, если онсогласован и клиенты видят ровно те данные,которые были записаны

• Успешная запись при отсутствии конкурирующихзаписей производит определённый регион

• Конкурирующие успешные записи могутпроизвести согласованные, но неопределённыеданные

47/67

атомарная операция наращивания

• Операция наращивания⁷ в традиционных ФС:запись по смещению, которое клиент считаетсмещением конца файла

• Наращивание в GFS: я сделаю согласованныйопределённый регион с твоей записью и вернутебе получившееся смещение

• В «хорошем» случае все почти как в операциипроизвольной записи• Если в нынешнем фрагмента нет места для всейзаписи, то создадут новый

⁷append

48/67

атомарная операция наращивания ii

• Плохой случай: какая-то из реплик не осилилазапись

• Клиент повторяет операцию, и главная репликаназначает новое смещение

• Результат: в некоторых репликах могут бытьполные или частичные дубликаты добавляемыхданных, но рано или поздно появитсясогласованный определённый регион

Реплики фрагмента не обязательно бинарноидентичны

49/67

атомарная операция наращивания ii

• Плохой случай: какая-то из реплик не осилилазапись

• Клиент повторяет операцию, и главная репликаназначает новое смещение

• Результат: в некоторых репликах могут бытьполные или частичные дубликаты добавляемыхданных, но рано или поздно появитсясогласованный определённый регион

Реплики фрагмента не обязательно бинарноидентичны

49/67

схема наращивания

50/67

неопределённые данные

• И произвольная запись и наращивание могутпроизвести неопределённые и несогласованныерегионы

• Выяснение осмысленности хранящихся в регионеданных становится заботой приложения• контрольные суммы записи• контрольные точки в файле

51/67

время жизни главной реплики

• Главная реплика назначается мастером иполучает билет⁸ на 60 секунд

• Если билет просрочен, главная реплика не имеетправа осуществлять операции записи

• Билет можно продлевать• Каждый новый билет, выданный главной реплике,увеличивает номер версии фрагмента

• Мастер может отобрать билет раньше срока

⁸lease

52/67

операция фиксации состояния

• Фиксация состояния⁹ делает почти мгновеннуюкопию файла или каталога методом copy-on-write• отбираются все выданные билеты• делается копия метаданных дерева• новые файлы ассоциируются с оригинальнымифрагментами

• Когда кто-то захочет изменить данные, онзапросит адрес главной реплики фрагмента

• В этот момент мастер распорядится создатьфрагмент-копию

⁹snapshot

53/67

проблемы файлового сервера

• Данные на файловом сервере могут повредитьсяиз-за аппаратного или программного сбоя

• ФС может проспать мутацию фрагмента и егофрагмент протухнет (номер версии меньше чемна мастере)

54/67

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

• Фрагменты разбиваются на блоки размером 64Kbи для каждого блока считается контрольная сумма

• Контрольные суммы хранятся в памяти ижурналируются отдельно от данных

• При чтении файловый сервер сравнивает КСблока с записанной и в случае противоречия бьётв набат

55/67

устаревшие фрагменты, удаление файлов исборка мусора

• Фрагмент может устареть• Стратегия удаления

• отметить как удалённый и переместить в Trash,записав момент удаления

• через некоторое время удалить из метаданныхсовсем

• Стратегия сбора мусора• Файловые серверы сообщают мастеру IDхранимых фрагментов

• Мастер смотрит в свои метаданные: отображениефайла во фрагменты

• Первое множество без второго = мусор• Файловый сервер удаляет мусор по своемуусмотрению

56/67

требования меняются

• Google 2010-х годов – это интерактивныеприложения

• Файлов больше, их размер меньше• Речь уже об эксабайтах• Требования по времени произвольного доступажестче

• GFS ячейка достигает предела возможностей приколичестве файлов 50M и объеме несколькопетабайт

57/67

colossus

• Шардированные метаданные• Простая репликация заменена кодамиРида-Соломона

• Подробности практически неизвестны

58/67

недостатки репликации

• N реплик – это конечно хорошо, но …• Диска тратится в N раз больше• Выхода из строя всего N машин достаточно чтобыпотерять 1 фрагмент

59/67

алгоритмы коррекции ошибок

• Уменьшение избыточных данных• Повышение надежности: чтоб потерять данныенужно вывести из строя существенно большемашин

• Reed-Solomon encoding: n исходных дисков + mконтролирующих гарантируют восстановлениепри выходе из строя любых k <= m дисков

• Конфигурация n = 8,m = 4 надежнее обычнойрепликации с фактором 3 и требует в два разаменьше места

60/67

алгоритмы коррекции ошибок

• Уменьшение избыточных данных• Повышение надежности: чтоб потерять данныенужно вывести из строя существенно большемашин

• Reed-Solomon encoding: n исходных дисков + mконтролирующих гарантируют восстановлениепри выходе из строя любых k <= m дисков

• Конфигурация n = 8,m = 4 надежнее обычнойрепликации с фактором 3 и требует в два разаменьше места

60/67

сегодня в программе

Характеристики данных

Основные концепции

Особенности распределенных ФС

Немного истории

Google File System/Hadoop File System

GlusterFS

61/67

архитектура glusterfs

• Машины объединяются в ячейку (trusted pool).Вход строго по приглашениям!

• Демоны на сервере• glusterfsd экспортирует в ячейку кирпичи(bricks)

• glusterd создает и поддерживает тома изкирпичей

• Кирпичом называется пара файловыйсервер+экспортируемая локальная файловаясистема

• Томом называется список кирпичей. Том можнозамонтировать в локальную ФС

62/67

сервера метаданных нет

• Выделенного сервера метаданных нет.• Пространство имен поддерживается файловымисистемами под кирпичами

63/67

распределённый том

• Том состоит из N кирпичей• Пространство имен делится на Nнепересекающихся партиций

• Партиция – диапазон 32-битных чисел,поделённый на N частей

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

• Упавший кирпич – потеря части данных

64/67

реплицируемый том

• Том состоит из N кирпичей• Файл синхронно записывается на все кирпичи• Данные не теряются из-за падения кирпичей• Необходимо поддерживать согласованностьзаписи

65/67

распределённый реплицируемый том

• Распределённый• Реплицируемый

66/67

что там с метаданными

• Сервера метаданных нет• Информация о составе тома есть• Метаданные тома должны бытьсинхронизированы

• Внутри ячейки должен быть механизм принятиярешений

67/67