Технологии хранения и обработки больших объёмов...
TRANSCRIPT
технологии хранения и обработкибольших объёмов данныхРаспределённые файловые системы
Дмитрий Барашев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