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

Операционная система	Ядро Linux
Тип	Распределенная файловая система
Лицензия	Собственный

Файловая система Google ( GFS или GoogleFS , не путать с файловой системой GFS Linux) — это проприетарная распределенная файловая система, разработанная Google для обеспечения эффективного и надежного доступа к данным с использованием больших кластеров стандартного оборудования . Файловая система Google была заменена Colossus в 2010 году. ^{[ 1 ]}

Дизайн

Файловая система Google предназначена для взаимодействия между системами, а не для взаимодействия между пользователями. Серверы фрагментов автоматически реплицируют данные.

GFS усовершенствована с учетом основных потребностей Google в хранении и использовании данных (в первую очередь, поисковой системы ), которая может генерировать огромные объемы данных, которые необходимо сохранять; Файловая система Google выросла из более ранней разработки Google, «BigFiles», разработанной Ларри Пейджем и Сергеем Брином на заре существования Google, когда она еще находилась в Стэнфорде . Файлы делятся на фрагменты фиксированного размера по 64 мегабайта , аналогичные кластерам или секторам в обычных файловых системах, которые перезаписываются или сжимаются крайне редко; файлы обычно добавляются или читаются. Он также разработан и оптимизирован для работы на вычислительных кластерах Google, плотных узлах, состоящих из дешевых «обычных» компьютеров, а это означает, что необходимо принять меры предосторожности против высокой частоты отказов отдельных узлов и последующей потери данных. Другие проектные решения ориентированы на высокую пропускную способность , даже если за это приходится платить задержкой .

Кластер GFS состоит из нескольких узлов. Эти узлы делятся на два типа: один главный узел и несколько серверов фрагментов . Каждый файл разделен на фрагменты фиксированного размера. Серверы фрагментов хранят эти фрагменты. Каждому фрагменту во время создания главный узел присваивает глобально уникальную 64-битную метку, при этом сохраняются логические сопоставления файлов с составляющими его фрагментами. Каждый фрагмент реплицируется несколько раз по сети. По умолчанию он реплицируется три раза, но это можно настроить. ^{[ 2 ]} Файлы, пользующиеся большим спросом, могут иметь более высокий коэффициент репликации, в то время как файлы, для которых клиент приложения использует строгую оптимизацию хранения, могут реплицироваться менее трех раз — чтобы справиться с политиками быстрой очистки мусора. ^{[ 2 ]}

Главный сервер обычно хранит не сами фрагменты, а все метаданные , связанные с фрагментами, такие как таблицы, сопоставляющие 64-битные метки с местоположениями фрагментов и файлы, которые они составляют (сопоставление файлов с фрагментами), местоположения копий фрагментов, какие процессы читают или записывают в конкретный фрагмент или делают «снимок» фрагмента для его репликации (обычно по инициативе главного сервера, когда из-за сбоев узлов количество копий фрагмента упало ниже установленного числа). Все эти метаданные поддерживаются в актуальном состоянии главным сервером, периодически получающим обновления от каждого сервера фрагментов («сообщения Heartbeat»).

Разрешения на изменения обрабатываются системой ограниченных по времени и истекающих «аренды», где главный сервер предоставляет разрешение процессу на ограниченный период времени, в течение которого ни один другой процесс не будет получать от главного сервера разрешение на изменение фрагмента. . Модифицирующий сервер фрагментов, который всегда является основным держателем фрагментов, затем распространяет изменения на серверы фрагментов с помощью резервных копий. Изменения не сохраняются до тех пор, пока все серверы фрагментов не подтвердят их, что гарантирует завершение и атомарность операции.

Программы получают доступ к фрагментам, сначала запрашивая у главного сервера местонахождение нужных фрагментов; если чанки не используются (т.е. не существует невыполненной аренды), Мастер отвечает, сообщая местоположения, а затем программа связывается и получает данные напрямую с сервера фрагментов (аналогично Kazaa и его супернодам ).

В отличие от большинства других файловых систем, GFS не реализована в ядре , операционной системы а вместо этого предоставляется в виде библиотеки пользовательского пространства . ^{[ 3 ]}

Интерфейс

Файловая система Google не предоставляет интерфейс POSIX . ^{[ 4 ]} Файлы организованы иерархически в каталогах и идентифицируются по именам путей. Поддерживаются такие файловые операции, как создание, удаление, открытие, закрытие, чтение, запись. Он поддерживает добавление записей, что позволяет нескольким клиентам одновременно добавлять данные в один и тот же файл, при этом гарантируется атомарность.

Производительность

Принимая решение по результатам сравнительного анализа, ^{[ 2 ]} при использовании с относительно небольшим количеством серверов (15) файловая система достигает производительности чтения, сравнимой с производительностью одиночного диска (80–100 МБ/с), но имеет пониженную скорость записи (30 МБ/с) и относительно медленное (5 МБ/с) добавление данных в существующие файлы. Авторы не приводят результатов по времени случайного поиска. Поскольку главный узел не участвует напрямую в чтении данных (данные передаются с сервера фрагментов непосредственно клиенту чтения), скорость чтения значительно увеличивается с увеличением количества серверов фрагментов, достигая 583 МБ/с для 342 узлов. Объединение нескольких серверов также обеспечивает большую емкость, хотя она несколько снижается за счет хранения данных в трех независимых местах (для обеспечения избыточности).

См. также

Большой стол
Облачное хранилище
Облачный магазин
Fossil — родная файловая система Plan 9.
GPFS Общая параллельная файловая система IBM
GFS2 Глобальная файловая система Red Hat 2
Apache Hadoop и его «Распределенная файловая система Hadoop» (HDFS), Java-продукт с открытым исходным кодом, аналогичный GFS.
Список продуктов Google
MapReduce
Файловая система Moose
ЯщерицаFS

Ссылки

^ Ма, Эрик (29 ноября 2012 г.). «Колосс: преемник файловой системы Google (GFS)» . Системные учебники. Архивировано из оригинала 12 апреля 2019 г. Проверено 10 мая 2016 г.
^ Jump up to: ^а ^б ^с Гемават, Гобиофф и Люнг, 2003 .
^ Кириазис, Димосфенис (2013). Службы хранения больших объемов данных для облачных сред . IGI Global. п. 13. ISBN 9781466639355 .
^ Маршалл Кирк МакКьюсик; Шон Куинлан (август 2009 г.). «GFS: эволюция в ускоренном темпе» . Очередь АКМ . 7 (7): 10–20. дои : 10.1145/1594204.1594206 . Проверено 21 декабря 2019 г.

Библиография

Гемават, С.; Гобиофф, Х.; Люнг, ST (2003). «Файловая система Google». Материалы девятнадцатого симпозиума ACM по принципам операционных систем - SOSP '03 (PDF) . п. 29. CiteSeerX 10.1.1.125.789 . дои : 10.1145/945445.945450 . ISBN 1581137575 . S2CID 221261373 .

Внешние ссылки

«GFS: Эволюция в ускоренной перемотке вперед», Очередь , ACM .
«Оценка файловой системы Google, часть I», Storage mojo .

[ma-1] Ма, Эрик (29 ноября 2012 г.). «Колосс: преемник файловой системы Google (GFS)» . Системные учебники. Архивировано из оригинала 12 апреля 2019 г. Проверено 10 мая 2016 г.

[FOOTNOTEGhemawatGobioffLeung2003-2] Jump up to: ^а ^б ^с Гемават, Гобиофф и Люнг, 2003 .

[3] Кириазис, Димосфенис (2013). Службы хранения больших объемов данных для облачных сред . IGI Global. п. 13. ISBN 9781466639355 .

[convo-4] Маршалл Кирк МакКьюсик; Шон Куинлан (август 2009 г.). «GFS: эволюция в ускоренном темпе» . Очередь АКМ . 7 (7): 10–20. дои : 10.1145/1594204.1594206 . Проверено 21 декабря 2019 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]