© Георгиевский Анатолий, Барышков Дмитрий, 02.09.2007

Распределенная файловая система

В статье показана проблема надежности и быстродействия файловой системы при организации параллельных вычислений. Анонсированиа работа по проектированию распределенной файловой системы для кластера.

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

Базовые принципы построения РФС

Децентрализация

На нашем кластере используется файловая система nfs, которая позволяет смонтировать домашнюю папку (/home) на все вычислительные узлы и тем самым предоставить доступ к общим дисковым ресурсам. Недостатком такой системы является централизация хранения данных, что создает узкое место ограничивающее пропускную способность и производительность кластера.

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

Конечно существуют специализированные кластерные файловые системы. НО, нет открытой файловой системы, которая могла бы поставляться в составе дистрибутивов GNU/Linux. И, что самое главное, мы не встречали упоминаний о файловых системах обеспечивающих децентрализацию управления. Как правило предлагаются решения основанные на передаче и распределении ролей между узлами системы.

Проблема реализации распределеного хранения в том, чтобы обеспечить одновременный доступ на изменение данных. Возникает проблема реализации блокировок доступа на время модификации данных.

Реструктуризация

Топология сети и количество узлов в сети может меняться в процессе работы Изменения структуры сети должны вносится без остановки работы системы. Не должно быть выделеного узла отвечающего за корневую папку.

Рациональное использование дискового пространства

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

Распределенное хранение данных, когда данные равномерно распределены по узлам, снижает надежность системы. Поскольку нерабочее состояние одного из узлов приводит к нерабочему состоянию системы в целом. А снижение быстродействия одного из узлов может привести к снижению быстродействия системы в целом. Отсюда возникает необходимость клонирования данных (репликации), чтобы данные были доступны всегда одновременно с нескольких узлов.

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

Репликация даных и локальное кеширование

Каждый узел должен принимать решение, есть ли необходимость копирования (репликации) данных. Каждая операция копирования должна удовлетворять одной из поставленных целей и повышать упорядоченность системы. Ценность и приоритет операции можно опеделить математически, если каждой цели сопоставить математический критерий необходимости выполенения операции.

Цели репликации:

  • Отказоустойчивость,
  • Быстродействие,
  • Оптимизация топологии размещения данных.

Цепочки блоков

Реализация файловой системы основана на концепции блочного умтройства. Примером блочного устройства является диск или флеш память, когда запись производится по блокам и секторам, блоками фиксированной длины.

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

Тезис хранения цепочек блоков, а не файлов, позволяет предоставлять доступ к фрагментам файлов до завершения операции копирования.

Контроль версии блока

Ещё одна возможность повышения производительности системы - это контроль версии. Если удается избежать повторного копирования данных, можно разгрузить сетевой трафик. Идея организации контроля версии взята из протокола http. Владелец блока сообщает при пересылке некоторое число, E-Tag, которое характеризует версию блока. При повторном запросе того же блока, владельцу отсылается версия локальной копии, E-Tag, в ответе на запрос содержится либо содержимое блока, либо сообщение, что данне остались без изменений. В данном механизме контроля версии отсутствует привязка ко времени внесения изменений и снята необходимость контроля версии на локальном узле. Алгоритм вычисления E-Tag остается на усмотрение владельца блока.

Возможность аппаратного ускорения

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

Дополнительная информация

  • Проект распределенной файловой системы

(2 сентября 2007 г.)