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

Дмитрий Барашев
bigdata@barashev.net
Computer Science Center

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

Creative Commons ”Attribution - Share Alike” 3.0
http://creativecommons.org/...
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
Нужна ли тебе DFS1 ?

1

Distributed File System
Нужна ли тебе DFS1 ?

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

1

Distributed File System
Размер

▶

Данные не помещаются на локальный диск?

▶

Это коллекция фоточек и фильмов?
Размер

▶

Данные не помещаются на локальный диск?

▶

Это коллекция фоточек и фильмов?

▶

Купи двухтерабайтный внешний д...
Обновления

▶

Новые данные поступают постоянно?

▶

Ты собираешься с ними что-то делать?
Обновления

▶

Новые данные поступают постоянно?

▶

Ты собираешься с ними что-то делать?

▶

Если нет, то записывай их на...
Использование

▶

Твои пользователи читают и пишут данные
конкурентно?

▶

Они редактируют одну презентацию, и легко
попью...
Использование

▶

Твои пользователи читают и пишут данные
конкурентно?

▶

Они редактируют одну презентацию, и легко
попью...
Может и правда не нужна?

▶

У тебя много данных и ты их обрабатываешь?

▶

Хочешь уменьшить соотношение V/S где V –
разме...
Может и правда не нужна?

▶

У тебя много данных и ты их обрабатываешь?

▶

Хочешь уменьшить соотношение V/S где V –
разме...
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
Файловая система
▶

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

▶

Предоставляет абстракц...
Метаинформация

▶

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

▶

Для ФС интереснее метаинформация: название
файл...
Локальные файловые системы

▶

Более или менее тесно интегрированы с ядром

▶

Обычно хранят данные на локальном HDD

▶

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

картинка с IBM developerWorks
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
Распределенная ФС

▶

Модель примерно та же

▶

Компоненты распределены по разным машинам

▶

Распределенность существенно...
Компоненты РФС

▶

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

▶

Серверы файлов: хранят соде...
Аспекты функционирования

▶

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

▶

Совместный доступ

▶

Кеширование

▶

Репликация

▶

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

▶

Прикладному приложению известен только путь

▶

Чем меньше информации о физическом
расп...
Прозрачность размещения файлов

▶

Прикладному приложению известен только путь

▶

Чем меньше информации о физическом
расп...
Совместный доступ и кеширование

▶

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

▶

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

синхронные чтение и запись

▶

write-through cache: чтение из кеша, синхронная
...
Репликация

▶

Синхронная или асинхронная

▶

Политика согласованности реплик

▶

Запись в реплики
Единая точка отказа

▶
▶

Сбой в единой точке отказа2 делает
неработоспособной всю систему
Сервер метаданных – кандидат на...
Наличие состояния

▶

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

▶

Сервер без состо...
Шаблоны доступа

▶

Какого размера типичный файл?

▶

Что важнее – надежность или скорость?

▶

Что важнее – среднее время...
Масштабируемость
▶

Хочется линейную
▶
▶

▶

▶

было N дисков и K машин
стало в 2N данных – добавили N дисков,
сохранили п...
Предоставляемый API

▶

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

▶

Какой-то свой, в связ...
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
NFS

▶

Network File System

▶

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

картинка с IBM developerWorks
AFS

▶

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

▶

Сессионное кеширование, нотификации об
изм...
и другие

▶

CIFS, aka Samba, aka Windows Shared Folders

▶

Ceph, GlusterFS, Lustre, <add your file system
here>
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
Братья или однофамильцы?

▶

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

▶

HDFS – открытая реализация построе...
Предпосылки

▶

Начало 2000-х, Google завоевывает поиск

▶

Большие файлы (порядка N Gb) записываются и
читаются пакетными...
Основные моменты архитектуры
▶

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

▶

Файлы хранятся фрагм...
Развертывание GFS

▶

Ячейка – единица развертывания

▶

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

▶

Ячейка GFS при...
Архитектура GFS-ячейки
Обязанности мастера

▶

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

▶

Обзвон файловых серверов, «прове...
Мутации метаданных

▶

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

▶

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

▶

Приложение собирается прочитать фрагмент

▶

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

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

▶

Регион согласован, если у нег...
Атомарная операция наращивания
▶

▶

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

▶

Гарантия: успешная операция наращивания
производит согласованный определённый
регион,...
Схема наращивания
Неопределённые данные

▶

▶

И произвольная запись и наращивание могут
произвести неопределённые и несогласованные
регионы...
Время жизни главной реплики

▶

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

▶

Если билет ...
Операция фиксации состояния

▶

Фиксация состояния (snapshot) делает почти
мгновенную копию файла или каталога
методом cop...
Проблемы файлового сервера

▶

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

▶

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

▶

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

▶

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

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

▶

▶

отметить ка...
Требования меняются
▶

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

▶

Файлы меньше в размерах и больше в
количеств...
Требования меняются
▶

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

▶

Файлы меньше в размерах и больше в
количеств...
Сегодня в программе
Характеристики данных
Основные концепции
Особенности распределенных ФС
Немного истории
Google File Sys...
ФС без сервера метаданных

▶

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

▶

Если файл пере...
Недостатки репликации

▶

N реплик – это конечно хорошо, но …

▶

Диска тратится в N раз больше

▶

Выхода из строя всего ...
Алгоритмы коррекции ошибок

▶

Уменьшение избыточных данных

▶

Повышение надежности: чтоб потерять данные
нужно вывести и...
Алгоритмы коррекции ошибок

▶

Уменьшение избыточных данных

▶

Повышение надежности: чтоб потерять данные
нужно вывести и...
Литература I
Alex Davies and Alessandro Orsaria.
Scale out with glusterfs.
Linux J., 2013(235), November 2013.
Sanjay Ghem...
Литература II
M. Tim Jones.
Анатомия файловой системы Linux.
http://www.ibm.com/developerworks/ru/
library/l-linux-filesys...
Upcoming SlideShare
Loading in …5
×

2014_02_14_BigData

1,152 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,152
On SlideShare
0
From Embeds
0
Number of Embeds
826
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2014_02_14_BigData

  1. 1. Big Data’14 Лекция I: распределенные файловые системы Дмитрий Барашев bigdata@barashev.net Computer Science Center 10 февраля 2014
  2. 2. Этот материал распространяется под лицензией Creative Commons ”Attribution - Share Alike” 3.0 http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru P peeria A сверстано в онлайн LTEX редакторе a papeeria.com
  3. 3. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  4. 4. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  5. 5. Нужна ли тебе DFS1 ? 1 Distributed File System
  6. 6. Нужна ли тебе DFS1 ? Может быть и нет Зависит от характеристик твоих данных 1 Distributed File System
  7. 7. Размер ▶ Данные не помещаются на локальный диск? ▶ Это коллекция фоточек и фильмов?
  8. 8. Размер ▶ Данные не помещаются на локальный диск? ▶ Это коллекция фоточек и фильмов? ▶ Купи двухтерабайтный внешний диск и забудь про DFS
  9. 9. Обновления ▶ Новые данные поступают постоянно? ▶ Ты собираешься с ними что-то делать?
  10. 10. Обновления ▶ Новые данные поступают постоянно? ▶ Ты собираешься с ними что-то делать? ▶ Если нет, то записывай их на ленту или HDD и забудь про DFS
  11. 11. Использование ▶ Твои пользователи читают и пишут данные конкурентно? ▶ Они редактируют одну презентацию, и легко попьют чаю полчаса если сервер отключится?
  12. 12. Использование ▶ Твои пользователи читают и пишут данные конкурентно? ▶ Они редактируют одну презентацию, и легко попьют чаю полчаса если сервер отключится? ▶ Установи файл-сервер с журналированием и резервными копиями и забудь про DFS
  13. 13. Может и правда не нужна? ▶ У тебя много данных и ты их обрабатываешь? ▶ Хочешь уменьшить соотношение V/S где V – размер данных, S - скорость обработки одним CPU ? ▶ Твои пользователи читают большие последовательные фрагменты? ▶ Они будут очень огорчены сбоем диска или блока питания?
  14. 14. Может и правда не нужна? ▶ У тебя много данных и ты их обрабатываешь? ▶ Хочешь уменьшить соотношение V/S где V – размер данных, S - скорость обработки одним CPU ? ▶ Твои пользователи читают большие последовательные фрагменты? ▶ Они будут очень огорчены сбоем диска или блока питания? ▶ Тебе, наверное, надо вспомнить про какую-нибудь DFS
  15. 15. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  16. 16. Файловая система ▶ Модель данных, программные компоненты, персистентные структуры данных и API ▶ Предоставляет абстракцию для доступа к данным, находящимся на каком-то физическом носителе Традиционная модель ▶ ▶ ▶ ▶ ▶ Файл: объект с именем и бессмысленным для ФС содержанием Каталог: список файлов и вложенных каталогов Каталоги и файлы образуют дерево – пространство имен Файл уникально идентифицируется путем: /usr/bin/vim
  17. 17. Метаинформация ▶ Для пользователя информация – это содержание файлов ▶ Для ФС интереснее метаинформация: название файла, список блоков, время модификации, права доступа
  18. 18. Локальные файловые системы ▶ Более или менее тесно интегрированы с ядром ▶ Обычно хранят данные на локальном HDD ▶ Блоки размером несколько килобайт ▶ Могут кешировать страницы
  19. 19. Локальные ФС: Linux картинка с IBM developerWorks
  20. 20. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  21. 21. Распределенная ФС ▶ Модель примерно та же ▶ Компоненты распределены по разным машинам ▶ Распределенность существенно влияет на некоторые решения
  22. 22. Компоненты РФС ▶ Клиент: API для прикладных приложений и код для коммуникации с сервером ▶ Серверы файлов: хранят содержимое файлов ▶ Серверы метаданных: знают, какой файл где лежит и многое еще
  23. 23. Аспекты функционирования ▶ Прозрачность размещения файлов ▶ Совместный доступ ▶ Кеширование ▶ Репликация ▶ Единая точка отказа ▶ Наличие состояния ▶ Шаблоны доступа ▶ Масштабируемость ▶ API
  24. 24. Прозрачность размещения файлов ▶ Прикладному приложению известен только путь ▶ Чем меньше информации о физическом расположении закодировано в путь, тем лучше ▶ …при сохранении здравого смысла
  25. 25. Прозрачность размещения файлов ▶ Прикладному приложению известен только путь ▶ Чем меньше информации о физическом расположении закодировано в путь, тем лучше ▶ …при сохранении здравого смысла Пример 1 /192.168.0.10/sda1/home/alice/kitten.jpg тут пожалуй информации многовато Пример 2 /TheEarth/home/alice/kitten.jpg а тут ФС придется самостоятельно выбрать континент
  26. 26. Совместный доступ и кеширование ▶ Централизованная система: атомарные чтение и запись; блокировки; журналирование ▶ Распределенная ФС: сетевые задержки, репликация усложняют жизнь
  27. 27. Варианты управления совместным доступом ▶ синхронные чтение и запись ▶ write-through cache: чтение из кеша, синхронная запись ▶ сессионное кеширование: чтение и запись в кеш, синхронизация при закрытии, политика определения победителя при конкурирующей записи ▶ файлы после создания становятся неизменяемыми ▶ запись возможна только в конец (append-only) ▶ клиенты, открывшие файл уведомляются о записях ▶ полноценные транзакции
  28. 28. Репликация ▶ Синхронная или асинхронная ▶ Политика согласованности реплик ▶ Запись в реплики
  29. 29. Единая точка отказа ▶ ▶ Сбой в единой точке отказа2 делает неработоспособной всю систему Сервер метаданных – кандидат на SPoF ▶ ▶ 2 …и еще и на узкое место Два сервера метаданных – кандидаты на несогласованность Single Point of Failure
  30. 30. Наличие состояния ▶ Сервер с состоянием (stateful) знает все про открытые файлы в данный момент ▶ ▶ ▶ Сервер без состояния (stateless) возможно будет повторять действия при каждом запросе ▶ ▶ тратит на это память и больно падает но зато может кое-какие операции оптимизировать но зато быстро восстановится после падения У сервера метаданных всегда есть состояние
  31. 31. Шаблоны доступа ▶ Какого размера типичный файл? ▶ Что важнее – надежность или скорость? ▶ Что важнее – среднее время одного случайного чтения или суммарная пропускная способность последовательного чтения?
  32. 32. Масштабируемость ▶ Хочется линейную ▶ ▶ ▶ ▶ было N дисков и K машин стало в 2N данных – добавили N дисков, сохранили пропускную способность нужна в два раза большая пропускная способность – добавили K машин, распределили данные На практике у линейной масштабируемости множество препятствий ▶ пропускная способность сети, сетевых интерфейсов файловых серверов, производительность сервера каталогов, блокировки
  33. 33. Предоставляемый API ▶ POSIX: такой же как у локальных ФС, не нужно менять прикладные программы ▶ Какой-то свой, в связи с ограничениями или дополнительными возможностями
  34. 34. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  35. 35. NFS ▶ Network File System ▶ Рождена Sun’ом в начале 1980-х и жива-здорова до сих пор, используется во многих корпорациях ▶ POSIX API, клиент монтирует удаленный диск в локальный каталог ▶ На сервере NFS демон тоже работает со стандартным интерфейсом файловой системы ▶ Поддерживаются блокировки и сессионное кеширование
  36. 36. NFS картинка с IBM developerWorks
  37. 37. AFS ▶ Andrew File System. Рождена в университете Carnegie Mellon в 1980-х ▶ Сессионное кеширование, нотификации об изменениях, блокировки файлов ▶ Моментальные read-only снимки томов ▶ Не POSIX API
  38. 38. и другие ▶ CIFS, aka Samba, aka Windows Shared Folders ▶ Ceph, GlusterFS, Lustre, <add your file system here>
  39. 39. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  40. 40. Братья или однофамильцы? ▶ GFS – закрытая реализация, подробно описанная в статье ▶ HDFS – открытая реализация построенная по принципам GFS ▶ Позднее за HDFS взялась Yahoo, и сейчас HDFS используется повсеместно ▶ QFS: реализация на C++
  41. 41. Предпосылки ▶ Начало 2000-х, Google завоевывает поиск ▶ Большие файлы (порядка N Gb) записываются и читаются пакетными процессами (crawler, indexer) ▶ Пропускная способность важнее быстрого случайного доступа ▶ Ширпотребные компьютеры, в совокупности часто выходящие из строя
  42. 42. Основные моменты архитектуры ▶ Много файловых серверов, один активный сервер метаданных (мастер) ▶ Файлы хранятся фрагментами по 64Mb ▶ Каждый фрагмент реплицируется на 3 различных файловых сервера ▶ У фрагмента номер, монотонно возрастающий во время жизни фрагмента ▶ Приоритетные операции с файлом: большое последовательное чтение и конкурентное наращивание ▶ Кеширования на клиенте не производится ▶ POSIX API не поддерживается
  43. 43. Развертывание GFS ▶ Ячейка – единица развертывания ▶ В ячейке один мастер и много файловых серверов ▶ Ячейка GFS примерно соответствует физическому датацентру
  44. 44. Архитектура GFS-ячейки
  45. 45. Обязанности мастера ▶ Поддерживать пространство имен и его отображение во фрагменты ▶ Обзвон файловых серверов, «проверка связи», выдача указаний, сбор состояния ▶ Размещение фрагментов при их создании, дополнительной репликации или перебалансировке ▶ Пересылка данных, однако, осуществляется напрямую между репликами и/или клиентом
  46. 46. Мутации метаданных ▶ Метаданными управляет мастер ▶ Теневые серверы дублируют его действия Изменения метаданных атомарны, изолированны и долговечны ▶ ▶ ▶ в пространстве имен используются иерархические блокировки мутации метаданных журналируются и журнал реплицируется на теневых серверах
  47. 47. Взаимодействие клиента и мастера при чтении ▶ Приложение собирается прочитать фрагмент ▶ GFS библиотека звонит мастеру, тот возвращает адреса реплик – файловых серверов, хранящих фрагмент ▶ GFS библиотека напрямую звонит одному из файловых серверов с просьбой вернуть нужный диапазон внутри данного фрагмента ▶ Дальнейшее общение клиента и файлового сервера идет напрямую
  48. 48. Взаимодействие при записи 1. Приложение хочет записать данные в фрагмент, хранящийся на нескольких репликах 2. Мастер выбирает главную по записи среди всех реплик 3. Клиент получает адреса всех реплик и передает им данные 4. Когда все реплики получили данные, клиент посылает главной указание произвести запись 5. Главная реплика выбирает порядок применения мутаций, применяет их локально и рассылает репликам указание применить мутации в том же порядке 6. Если все хорошо то клиент счастлив
  49. 49. Взаимодействие при записи 1. Приложение хочет записать данные в фрагмент, хранящийся на нескольких репликах 2. Мастер выбирает главную по записи среди всех реплик 3. Клиент получает адреса всех реплик и передает им данные 4. Когда все реплики получили данные, клиент посылает главной указание произвести запись 5. Главная реплика выбирает порядок применения мутаций, применяет их локально и рассылает репликам указание применить мутации в том же порядке 6. Если все хорошо то клиент счастлив А что если не все хорошо?
  50. 50. Модель согласованности ▶ Характеристики байтового региона: согласованный и определенный ▶ Регион согласован, если у него одинаковое значение во всех репликах ▶ Регион определен после записи, если он согласован и клиенты видят ровно те данные, которые были записаны ▶ Успешная запись при отсутствии конкурирующих записей производит определённый регион ▶ Конкурирующие успешные записи могут произвести согласованные, но неопределённые данные
  51. 51. Атомарная операция наращивания ▶ ▶ Гарантия: успешная операция наращивания производит согласованный определённый регион, смещение которого определяет GFS В «хорошем» случае все почти как в операции произвольной записи ▶ Главная реплика назначает смещение и может попросить произвести запись в следующий фрагмент, если в текущем нет места ▶ В «плохом» случае клиент повторяет операцию, и главная реплика назначает новое смещение ▶ Результат: в некоторых репликах могут быть дубликаты, полные или частичные добавляемых данных, но рано или поздно появится согласованный определённый регион
  52. 52. Атомарная операция наращивания ▶ ▶ Гарантия: успешная операция наращивания производит согласованный определённый регион, смещение которого определяет GFS В «хорошем» случае все почти как в операции произвольной записи ▶ Главная реплика назначает смещение и может попросить произвести запись в следующий фрагмент, если в текущем нет места ▶ В «плохом» случае клиент повторяет операцию, и главная реплика назначает новое смещение ▶ Результат: в некоторых репликах могут быть дубликаты, полные или частичные добавляемых данных, но рано или поздно появится согласованный определённый регион Реплики фрагмента не являются бинарно идентичными!
  53. 53. Схема наращивания
  54. 54. Неопределённые данные ▶ ▶ И произвольная запись и наращивание могут произвести неопределённые и несогласованные регионы Выяснение осмысленности хранящихся в регионе данных становится заботой приложения ▶ ▶ контрольные суммы записи контрольные точки в файле
  55. 55. Время жизни главной реплики ▶ Главная реплика назначается мастером и получает билет (lease) на 60 секунд ▶ Если билет просрочен, главная реплика не имеет права осуществлять операции записи ▶ Билет можно продлевать ▶ Каждый новый билет, выданный главной реплике, увеличивает номер версии фрагмента ▶ Мастер может отобрать билет раньше срока
  56. 56. Операция фиксации состояния ▶ Фиксация состояния (snapshot) делает почти мгновенную копию файла или каталога методом copy-on-write ▶ ▶ ▶ отбираются все выданные билеты делается копия метаданных дерева новые файлы ассоциируются с оригинальными фрагментами ▶ Когда кто-то захочет изменить данные, он запросит адрес главной реплики фрагмента ▶ В этот момент мастер распорядится создать фрагмент-копию
  57. 57. Проблемы файлового сервера ▶ Данные на файловом сервере могут повредиться из-за аппаратного или программного сбоя ▶ ФС может проспать мутацию фрагмента и его фрагмент устареет (номер версии меньше чем на мастере)
  58. 58. Целостность данных ▶ Фрагменты разбиваются на блоки размером 64Kb и для каждого блока считается контрольная сумма ▶ Контрольные суммы хранятся в памяти и журналируются отдельно от данных ▶ При чтении файловый сервер сравнивает КС блока с записанной и в случае противоречия бьёт в набат
  59. 59. Устаревшие фрагменты, удаление файлов и сборка мусора ▶ ▶ Фрагмент может устареть Стратегия удаления ▶ ▶ ▶ отметить как удалённый и переместить в Trash, записав момент удаления через некоторое время удалить из метаданных совсем Стратегия сбора мусора ▶ ▶ ▶ ▶ Файловые серверы сообщают мастеру ID хранимых фрагментов Мастер смотрит в свои метаданные: отображение файла во фрагменты Первое множество без второго = мусор Файловый сервер удаляет мусор по своему усмотрению
  60. 60. Требования меняются ▶ Google 2010-х годов – это интерактивные приложения ▶ Файлы меньше в размерах и больше в количестве ▶ Речь уже о пета и эксабайтах ▶ Требования по времени произвольного доступа жестче ▶ GFS ячейка достигает предела возможностей при количестве файлов 50M и объеме несколько петабайт
  61. 61. Требования меняются ▶ Google 2010-х годов – это интерактивные приложения ▶ Файлы меньше в размерах и больше в количестве ▶ Речь уже о пета и эксабайтах ▶ Требования по времени произвольного доступа жестче ▶ GFS ячейка достигает предела возможностей при количестве файлов 50M и объеме несколько петабайт GFS в Google больше не используется, на смену пришел Colossus
  62. 62. Сегодня в программе Характеристики данных Основные концепции Особенности распределенных ФС Немного истории Google File System/Hadoop File System Бонус трек
  63. 63. ФС без сервера метаданных ▶ Применяем хеш к полному имени файла и получаем номер(а) файловых серверов ▶ Если файл переименовывается, он оставляет свой новый адрес на старом месте ▶ Если нужно увеличить число файловых серверов, используем схему, похожую на extensible hashing ▶ Реализация: GlusterFS
  64. 64. Недостатки репликации ▶ N реплик – это конечно хорошо, но … ▶ Диска тратится в N раз больше ▶ Выхода из строя всего N машин достаточно чтобы потерять 1 фрагмент
  65. 65. Алгоритмы коррекции ошибок ▶ Уменьшение избыточных данных ▶ Повышение надежности: чтоб потерять данные нужно вывести из строя существенно больше машин
  66. 66. Алгоритмы коррекции ошибок ▶ Уменьшение избыточных данных ▶ Повышение надежности: чтоб потерять данные нужно вывести из строя существенно больше машин ▶ Reed-Solomon encoding: n исходных дисков + m контролирующих гарантируют восстановление при выходе из строя любых k <= m дисков ▶ Конфигурация n = 8, m = 4 надежнее обычной репликации с фактором 3 и требует в два раза меньше места
  67. 67. Литература I Alex Davies and Alessandro Orsaria. Scale out with glusterfs. Linux J., 2013(235), November 2013. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. 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.
  68. 68. Литература 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 for fault-tolerance in RAID-like systems. Software Practice and Experience, 27(9):995–1012, 1997. В.Г. Олифер and Н.А. Олифер. Сетевые операционные системы. Питер, 2002.

×