2014_02_14_BigData

  • 843 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
843
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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