GFS (Google File System)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 22:49, 20 мая 2016.
GFS (Google File System)
Операционная система: Linux kernel
Тип ПО: distributed file system
Лицензия: proprietary
Веб-сайт {{#property:P856}}

GFS (англ. Google File System) — большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации.

История

По некоторым сведениям работа над GFS была начата еще в 2000 году; общие принципы построения были довольно подробно описаны в документе, представленном на ACM SIGOPS Operating Systems Review в 2003 году [1]. Обновленная GFS второй версии (2009 год) имеет кодовое название Colossus[2].

Свойства системы

  • Система строится из большого количества обыкновенного недорого оборудования, которое часто дает сбои. Должны существовать мониторинг сбоев, и возможность в случае отказа какого-либо оборудования восстановить функционирование системы.
  • Система должна хранить много больших файлов. Как правило, несколько миллионов файлов, каждый от 100 Мб и больше. Также часто приходится иметь дело с многогигабайтными файлами, которые также должны эффективно храниться. Маленькие файлы тоже должны храниться, но для них не оптимизируется работа системы.
  • Как правило, встречаются два вида чтения: чтение большого последовательного фрагмента данных и чтение маленького объема произвольных данных. При чтении большого потока данных обычным делом является запрос фрагмента размером в 1Мб и больше. Такие последовательные операции от одного клиента часто читают подряд идущие куски одного и того же файла. Чтение небольшого размера данных, как правило, имеет объем в несколько килобайт. Приложения, критические по времени исполнения, должны накопить определенное количество таких запросов и отсортировать их по смещению от начала файла. Это позволит избежать при чтении блужданий вида назад-вперед.
  • Часто встречаются операции записи большого последовательного куска данных, который необходимо дописать в файл. Обычно, объемы данных для записи такого же порядка, что и для чтения. Записи небольших объемов, но в произвольные места файла, как правило, выполняются не эффективно.
  • Система должна реализовывать строго очерченную семантику параллельной работы нескольких клиентов, в случае если они одновременно пытаются дописать данные в один и тот же файл. При этом может случиться так, что поступят одновременно сотни запросов на запись в один файл. Для того чтобы справится с этим, используется атомарность операций добавления данных в файл, с некоторой синхронизацией. То есть если поступит операция на чтение, то она будет выполняться, либо до очередной операции записи, либо после.
  • Высокая пропускная способность является более предпочтительной, чем маленькая задержка. Так, большинство приложений в Google отдают предпочтение работе с большими объемами данных, на высокой скорости, а выполнение отдельно взятой операции чтения и записи, вообще говоря, может быть растянуто.

Файлы в GFS организованы иерархически, при помощи каталогов, как и в любой другой файловой системе, и идентифицируются своим путем. С файлами в GFS можно выполнять обычные операции: создание, удаление, открытие, закрытие, чтение и запись. Более того, GFS поддерживает резервные копии, или снимки (snapshot). Можно создавать такие резервные копии для файлов или дерева директорий, причем с небольшими затратами.

Архитектура GFS

GFS предназначена для хранения больших объемов данных (петабайты). Файлы в ФС поделены на куски фиксированного размера (в терминологии GFS – «chunk») по 64 Мб (в общем случае).

Файлы данных хранятся на chunk-узлах (в терминологии GFS – «Chunkserver»). Chunkserver на аппаратном уровне представляет commodity-оборудование. Поэтому (и не только поэтому) для обеспечения надежного хранения данных данные в GFS автоматически реплицируются как минимум трижды.

Кроме Chunk-сервер в GFS есть единственный Master-сервер. Master представляет собой вычислительный узел, ответственный за координацию и мониторинг сhunk-сервер. По аналогии с NameNode в HDFS, Master в GFS отвечает за:

  • работу с метаданными – пространства имен, file-to-chunk маппинг, информация о доступе к данным;
  • операции над chunk, в том числе сборка мусора («осиротевших» chunk);
  • мониторинг Chunk-серверов посредством hearbeat-сообщений.

Как и в случае с NameNode в HDFS, Master-узел в GFS является потенциальным «узким местом» системы, имеет избыточное число ответственностей и является единичной точкой отказа.

Архитектура GFS [1]

Структура GFS

В системе существуют мастер-сервера и chunk-сервера, собственно, хранящие данные. Как правило, GFS кластер состоит из одной главной машины мастера (master) и множества машин, хранящих фрагменты файлов chunk-серверы (chunkservers). Клиенты имеют доступ ко всем этим машинам. Файлы в GFS разбиваются на куски (chunk, можно сказать фрагмент). Chunk имеет фиксированный размер, который может настраиваться. Каждый такой chunk имеет уникальный и глобальный 64 — битный ключ, который выдается мастером при создании chunk. Chunk-серверы хранят chunk, как обычные Linux файлы, на локальном жестком диске. Для надежности каждый chunk может реплицироваться на другие chunk-серверы. Обычно используются три реплики. Мастер отвечает за работу с метаданными всей файловой системы. Метаданные включают в себя пространства имен, информацию о контроле доступа к данным, отображение файлов в chunk, и текущее положение chunk. Также мастер контролирует всю глобальную деятельность системы такую, как управление свободными chunk, сборка мусора (сбор более ненужных chunk) и перемещение chunk между chunk-серверами. Мастер постоянно обменивается сообщениями (HeartBeat messages) с chunk-серверами, чтобы отдать инструкции, и определить их состояние (узнать, живы ли еще). Клиент взаимодействует с мастером только для выполнения операций, связанных с метаданными. Все операции с самими данными производятся напрямую с chunk-серверами. GFS — система не поддерживает POSIX API, так что разработчикам не пришлось связываться с VNode уровнем Linux. Разработчики не используют кеширование данных, правда, клиенты кешируют метаданные. На chunk-серверах операционная система Linux и так кеширует наиболее используемые блоки в памяти. Вообще, отказ от кеширования позволяет не думать о проблеме валидности кеша (cache coherence).

Мастер

Использование одного мастера существенно упрощает архитектуру системы. Позволяет производить сложные перемещения chunk, организовывать репликации, используя глобальные данные. Казалось бы, что наличие только одного мастера должно являться узким местом системы, но это не так. Клиенты никогда не читают и не пишут данные через мастера. Вместо этого они спрашивают у мастера, с каким chunk-сервером они должны контактировать, а далее они общаются с chunk-серверами напрямую.

Рассмотрим, как происходит чтение данных клиентом. Сначала, зная размер chunk, имя файла и смещение относительно начала файла, клиент определяет номер chunk внутри файла. Затем он шлет запрос мастеру, содержащий имя файла и номер chunk в этом файле. Мастер выдает chunk-серверы, по одному в каждой реплике, которые хранят нужный нам chunk. Также мастер выдает клиенту идентификатор chunk.

Затем клиент решает, какая из реплик ему нравится больше (как правило та, которая ближе), и шлет запрос, состоящий из chunk и смещения относительно начала chunk. Дальнейшее чтения данных, не требует вмешательства мастера. На практике, как правило, клиент в один запрос на чтение включает сразу несколько chunk, и мастер дает координаты каждого из chunk в одном ответе.

Размер chunk является важной характеристикой системы. Как правило, он устанавливается равным 64 мегабайт, что гораздо больше, чем размер блока в обычной файловой системе. Понятно, что если необходимо хранить много файлов, размеры которых меньше размера chunk, то будем расходоваться много лишней памяти. Но выбор такого большого размера chunk обусловлен задачами, которые приходится компании Google решать на своих кластерах. Как правило, что-то считать приходится для всех документов в интернете, и поэтому файлы в этих задачах очень большого размера.

Метаданные

Мастер хранит три важных вида метаданных: пространства имен файлов и chunk, отображение файла в chunk и положение реплик chunk. Все метаданные хранятся в памяти мастера. Так как метаданные хранятся в памяти, операции мастера выполняются быстро. Состояние дел в системе мастер узнает просто и эффективно. Он выполняется сканирование chunk-серверов в фоновом режиме. Эти периодические сканирования используются для сборки мусора, дополнительных репликаций, в случае обнаружения недоступного chunk-сервера и перемещение chunk, для балансировки нагрузки и свободного места на жестких дисках chunk-серверов. Мастер отслеживает положение chunk. При старте chunk-сервера мастер запоминает его chunk. В процессе работы мастер контролирует все перемещения chunk и состояния chunk-серверов. Таким образом, он обладает всей информацией о положении каждого chunk.

Важная часть метаданных — это лог операций. Мастер хранит последовательность операций критических изменений метаданных. По этим отметкам в логе операций, определяется логическое время системы. Именно это логическое время определяет версии файлов и chunk. Так как лог операций важная часть, то он должен надежно храниться, и все изменения в нем должны становиться видимыми для клиентов, только когда изменятся метаданные. Лог операций реплицируется на несколько удаленных машин, и система реагирует на клиентскую операцию, только после сохранения этого лога на диск мастера и диски удаленных машин.

Мастер восстанавливает состояние системы, исполняя лог операций. Лог операций сохраняет относительно небольшой размер, сохраняя только последние операции. В процессе работы мастер создает контрольные точки, когда размер лога превосходит некоторой величины, и восстановить систему можно только до ближайшей контрольной точки. Далее по логу можно заново воспроизвести некоторые операции, таким образом, система может откатываться до точки, которая находится между последней контрольной точкой и текущем временем.

Базовые принципы

Основными принципами, заложенными инженерами Google в GFS являются:

  • Аппаратные неисправности в кластерных системах нужно рассматривать как норму, а не как исключение.
  • Данные уже имеют огромный размер и их объем будет только расти. Система ввода-ввода должна быть спроектирована с расчетом на размер данных, которыми она будет оперировать.
  • Файлы изменяются путем добавления новых данных в конец файла, а не путем переписывания существующих данных. Запись в произвольные места, как не непоследовательное чтение данных из файла гипернеэффективны. Эффективно использование подхода «write once, read many».
  • Дизайн распределенной ФС, не должен полагаться на дизайн приложений, его использующих. Таким образом файловая система должна знать минимальное количество сведений о клиентах и характере операций над данными, которые эти клиенты осуществляют.

Особенности GFS

GFS разделяет потоки данных и потоки команд. Потоки команд проходят от Master к клиентам и от Master к Chunk-серверам. В то время как потоки данных проходят от Chunkserver к клиентам напрямую, минуя Master. Это позволяет увеличить способность к масштабируемости всего GFS кластера в целом, так как Master не является «узким местом» при обмене данными с клиентами.

Кроме «стандартных» для ФС команд: create, delete, open, close, read, write – GFS также поддерживает операции snapshot и record append. Snapshot эффективно создает копию файла или директории, а record append позволяет добавлять данные в конец файла одновременно нескольким клиентам с гарантией атомарности изменений.

Как и во всех системах, построенных по архитектуре Master-Slave, Master сервер в GFS является единичной точкой отказа. Для того, чтобы максимально нивелировать влияние недоступности Master на общую доступность системы в GFS функционирует система логгирования операций и checkpoint'ов (при достижении лога определенных объемов). Кроме того, есть:

  • система мониторинга за доступностью Master;
  • «Shadow» Master, которые позволяет минимизировать время «поднятия» нового Master;
  • каноническое имя Master, по которому обращаются к Master-серверу клиенты, позволяет с помощь DNS alias за максимально короткий срок переключить клиентов на новый Master.

Примечание

  1. 1,0 1,1 [1], The Google File System // 19th Symposium on Operating Systems Principles, 2003.
  2. [2], Файловая система Google: колосс против информационного слона // "Компьютерра-Онлайн", 04 сентября 2013.