Google File System ( GFS или GoogleFS , не путать с файловой системой GFS Linux) — это фирменная распределённая файловая система , разработанная Google для обеспечения эффективного и надёжного доступа к данным с использованием больших кластеров товарного оборудования . Файловая система Google была заменена на Colossus в 2010 году. [1]
GFS улучшена для основных потребностей Google в хранении и использовании данных (в первую очередь поисковой системы ), что может генерировать огромные объемы данных, которые необходимо сохранить; Google File System выросла из более ранней работы Google, «BigFiles», разработанной Ларри Пейджем и Сергеем Брином в ранние дни Google, когда она все еще находилась в Стэнфорде . Файлы делятся на фрагменты фиксированного размера по 64 мегабайта , похожие на кластеры или сектора в обычных файловых системах, которые только крайне редко перезаписываются или сжимаются; файлы обычно добавляются или считываются. Она также разработана и оптимизирована для работы на вычислительных кластерах Google, плотных узлах, которые состоят из дешевых «товаров» компьютеров, что означает, что необходимо принять меры предосторожности против высокой частоты отказов отдельных узлов и последующей потери данных. Другие проектные решения выбирают высокую пропускную способность данных , даже если это происходит за счет задержки .
Кластер GFS состоит из нескольких узлов. Эти узлы делятся на два типа: один главный узел и несколько серверов фрагментов . Каждый файл делится на фрагменты фиксированного размера. Серверы фрагментов хранят эти фрагменты. Каждому фрагменту главный узел назначает глобально уникальную 64-битную метку во время создания, и поддерживаются логические сопоставления файлов с составными фрагментами. Каждый фрагмент реплицируется несколько раз по всей сети. По умолчанию он реплицируется три раза, но это можно настроить. [2] Файлы, которые пользуются большим спросом, могут иметь более высокий коэффициент репликации, в то время как файлы, для которых клиент приложения использует строгие оптимизации хранения, могут реплицироваться менее трех раз - для того, чтобы справиться с политиками быстрой очистки мусора. [2]
Главный сервер обычно не хранит сами фрагменты, а все метаданные , связанные с фрагментами, такие как таблицы, сопоставляющие 64-битные метки с местоположениями фрагментов и файлами, которые они составляют (сопоставление файлов с фрагментами), местоположения копий фрагментов, какие процессы читают или записывают в конкретный фрагмент или делают «моментальный снимок» фрагмента в соответствии с его репликацией (обычно по инициативе главного сервера, когда из-за сбоев узлов количество копий фрагмента падает ниже установленного числа). Все эти метаданные поддерживаются в актуальном состоянии главным сервером, периодически получающим обновления от каждого сервера фрагментов («сообщения Heart-beat»).
Разрешения на изменения обрабатываются системой ограниченных по времени, истекающих "аренды", где главный сервер предоставляет разрешение процессу на конечный период времени, в течение которого ни один другой процесс не получит разрешение от главного сервера на изменение куска. Модифицирующий сервер куска, который всегда является основным держателем куска, затем распространяет изменения на серверы куска с резервными копиями. Изменения не сохраняются, пока все серверы куска не подтвердят, тем самым гарантируя завершение и атомарность операции.
Программы получают доступ к фрагментам, сначала запрашивая у главного сервера местоположение нужных фрагментов; если фрагменты не используются (т. е. отсутствуют неисполненные договора аренды), главный сервер отправляет ответ с указанием местоположения, а затем программа связывается с сервером фрагментов и получает данные напрямую (аналогично Kazaa и его суперузлам ).
В отличие от большинства других файловых систем, GFS не реализована в ядре операционной системы , а вместо этого предоставляется как библиотека пользовательского пространства . [3]
Файловая система Google не предоставляет интерфейс POSIX . [4] Файлы организованы иерархически в каталогах и идентифицируются по именам путей. Поддерживаются такие файловые операции, как создание, удаление, открытие, закрытие, чтение, запись. Она поддерживает функцию добавления записи, которая позволяет нескольким клиентам добавлять данные в один и тот же файл одновременно, и атомарность гарантируется.
Исходя из результатов сравнительного тестирования [2] , при использовании с относительно небольшим количеством серверов (15) файловая система достигает производительности чтения, сопоставимой с производительностью одного диска (80–100 МБ/с), но имеет пониженную производительность записи (30 МБ/с) и относительно медленную (5 МБ/с) при добавлении данных к существующим файлам. Авторы не представляют результатов по времени случайного поиска. Поскольку главный узел не участвует напрямую в чтении данных (данные передаются с сервера фрагментов непосредственно на клиент чтения), скорость чтения значительно увеличивается с количеством серверов фрагментов, достигая 583 МБ/с для 342 узлов. Агрегирование нескольких серверов также обеспечивает большую емкость, хотя она несколько снижается за счет хранения данных в трех независимых местах (для обеспечения избыточности).