2013 02 21_big_data_lecture_01

. . . . . .

BigdataЛекция I: распределенные файловые системы

Дмитрий Барашев[email protected]

Computer Science Center

21 февраля 2013

mailto:[email protected]

. . . . . .

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

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

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

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

Google File System

Тема для семинара

. . . . . .

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

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

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

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

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

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

. . . . . .

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

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

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

. . . . . .

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

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

. . . . . .

Локальные ФС: Linux

картинка с IBM developerWorks

http://www.ibm.com/developerworks/ru/library/l-linux-filesystem/

. . . . . .





Google File System


. . . . . .

Распределенная ФС

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

. . . . . .

Компоненты РФС

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

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

. . . . . .

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

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

. . . . . .

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

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

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

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

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

. . . . . .

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

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

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

. . . . . .

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

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

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

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

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

I полноценные транзакции

. . . . . .

Репликация

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

. . . . . .

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

I Сбой в единой точке отказа (Single Point ofFailure) делает неработоспособной всю систему

I Сервер метаданных – кандидат на SPoFI …и еще и на узкое местоI Два сервера метаданных – кандидаты нанесогласованность

. . . . . .

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

I Сервер с состоянием (stateful) знает все прооткрытые файлы в данный момент

I тратит на это память и больно падаетI но зато может кое-какие операцииоптимизировать

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

I но зато быстро восстановится после паденияI У сервера метаданных всегда есть состояние

. . . . . .

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

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

. . . . . .

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

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

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

I На практике у линейной масштабируемостимножество препятствий

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

. . . . . .





Google File System


. . . . . .

NFS

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

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

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

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

. . . . . .

NFS

картинка с IBM developerWorks

http://www.ibm.com/developerworks/ru/library/l-network-filesystems/index.html/

. . . . . .

AFS

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

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

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

. . . . . .

и другие

I CIFS, aka Samba, aka Windows Shared FoldersI Ceph, GlusterFS, Lustre, <add your file systemhere>

. . . . . .





Google File System


. . . . . .

Предпосылки

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

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

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

. . . . . .

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

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

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

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

I Кеширования на клиенте не производитсяI POSIX API не поддерживается

. . . . . .

Развертывание GFS

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

I Ячейка GFS примерно соответствуетфизическому датацентру

. . . . . .

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

. . . . . .

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

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

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

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

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

. . . . . .

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

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

I в пространстве имен используютсяиерархические блокировки

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

. . . . . .

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

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

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

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

. . . . . .

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

1. Приложение хочет записать данные вфрагмент, хранящийся на нескольких репликах

2. Мастер выбирает главную по записи среди всехреплик

3. Клиент получает адреса всех реплик ипередает им данные

4. Когда все реплики получили данные, клиентпосылает главной указание произвести запись

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

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

А что если не все хорошо?

. . . . . .

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

1. Приложение хочет записать данные вфрагмент, хранящийся на нескольких репликах

2. Мастер выбирает главную по записи среди всехреплик

3. Клиент получает адреса всех реплик ипередает им данные

4. Когда все реплики получили данные, клиентпосылает главной указание произвести запись

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

6. Если все хорошо то клиент счастливА что если не все хорошо?

. . . . . .

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

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

I Регион согласован, если у него одинаковоезначение во всех репликах

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

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

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

. . . . . .

Атомарная операция наращиванияI Гарантия: успешная операция наращиванияпроизводит согласованный определённыйрегион, смещение которого определяет GFS

I В «хорошем» случае все почти как в операциипроизвольной записи

I Главная реплика назначает смещение и можетпопросить произвести запись в следующийфрагмент, если в текущем нет места

I В «плохом» случае клиент повторяет операцию,и главная реплика назначает новое смещение

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

Реплики фрагмента не являютсябинарно идентичными!

. . . . . .

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

. . . . . .

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

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

I Выяснение осмысленности хранящихся врегионе данных становится заботойприложения

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

. . . . . .

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

I Главная реплика назначается мастером иполучает билет (lease) на 60 секунд

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

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

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

. . . . . .

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

I Фиксация состояния (snapshot) делает почтимгновенную копию файла или каталогаметодом copy-on-write

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

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

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

. . . . . .

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

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

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

. . . . . .

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

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

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

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

. . . . . .

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

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

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

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

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

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

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

. . . . . .

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

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

I Файлы меньше в размерах и больше вколичестве

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

GFS в Google больше не используется, на сменупришел Colossus

. . . . . .

Реализации, похожие на GFS

I Реализация Google File System закрытаI Открытые проекты, с GFS-like архитектурой:

I Apache HDFS: реализация на Java из проектаHadoop

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

. . . . . .

ФС без сервера метаданных

I Применяем хеш к полному имени файла иполучаем номер(а) файловых серверов

I Если файл переименовывается, он оставляетсвой новый адрес на старом месте

I Если нужно увеличить число файловыхсерверов, используем схему, похожую наextensible hashing

I Реализация: GlusterFS

. . . . . .





Google File System


. . . . . .

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

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

. . . . . .

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

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

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

. . . . . .


I Рассказать о применении кодировкиРида-Соломона для реализации хранилища,устойчивого к сбоям

I +5 баллов в копилку!

. . . . . .

Эта презентация сверстана в

Pa

peeria1LTEX в вашем браузере

alpha.papeeria.com

alpha.papeeria.com

. . . . . .

Литература ISanjay 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.M. Tim Jones.Анатомия файловой системы Linux.http://www.ibm.com/developerworks/ru/library/l-linux-filesystem/.Accessed: 23.01.2013.





. . . . . .

Литература II

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.

2013 02 21_big_data_lecture_01

Documents