Software & Systems

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

В последние годы просматриваются тенденции увеличения производительности суперЭВМ путем увеличения количества вычислительных узлов c общей памятью. Если еще в начале 90-х годов основные позиции занимали суперЭВМ, состоящие из одного многопроцессорного узла на общей памяти (SMP), и требования к файловым системам (ФС) исходили из принципа централизации, то сейчас все верхние позиции списка TOP500, рейтингового списка самых мощных компьютеров, занимают многоузловые системы, и требования к файловым системам существенно меняются.

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

Второе требование – способность к масштабированию – предъявляется как непосредственно к носителям информации, так и к механизмам обеспечения разделяемого доступа к этим носителям.

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

Не стоит забывать и о таких требованиях, как репликация данных, целостность и восстанавливаемость данных после сбоев.

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

Параллельная кластерная ФС. Принципы работы различных ПФС рассмотрим на примере абстрактной параллельной кластерной ФС (ПКФС).

ПКФС, а именно хорошо масштабируемая и удовлетворяющая описанному комплексу требований ФС, может состоять из вычислительных узлов, подключенных к дискам или дисковой подсистеме через коммутирующую фабрику. Все узлы в кластере имеют равноправный доступ к разделяемым дискам. Данные распределяются по всем дискам равномерно для достижения максимального ускорения на операциях чтения и записи. Коммутирующая фабрика может быть сетью хранения информации SAN (Storage area network), построенной по технологии FC (Fibre channel) или по технологии iSCSI (SCSI по TCP/IP).В качестве альтернативы, индивидуально подключенные диски к узлу ФС могут использоваться вычислительным узлом на программном уровне через сеть общего назначения. Операции чтения и записи ПКФС данных и метаданных различными узлами полностью синхронизированы. Для соблюдения целостности данных ПКФС использует механизм распределенной блокировки, максимально сохраняя при этом все преимущества параллельного доступа к файлам с множественных узлов.

ПКФС с помощью механизма работы с метаданными поддерживает тысячи дисков, каждый из которых может достигать емкости в несколько терабайт, тем самым поддерживая емкость систем хранения до нескольких петабайт.

Распределение данных по дискам, упреждающее чтение и кэширование записи. Для достижения максимальной пропускной способности на операциях чтения и записи в один большой файл ПКФС распределят данные по всем предоставленным дискам и дисковым контроллерам. Количество дисков, подключенных к одному узлу, может быть большим благодаря технологии SAN, где для идентификации устройства SCSI используется его логический номер.

Большие файлы в ПКФС делятся на блоки равной длинны, последовательно размещенные на разных дисках: первый блок на первом диске, второй на втором, …, блок N на диске N, блок N+1, на первом диске и так далее. Чтобы минимизировать относительно долгую операцию позиционирования головок диска на нужный блок, используются блоки подходящей длинны. Для современных дисков размер блока ФС разумно выбирать 256 КБ. Если много больших файлов, тогда большой размер блока позволит за одну операцию ввода-вывода считать или записать большее количество данных. Малые файлы и концы больших файлов можно сохранять в блоках меньшего размера фиксированной длины, называемых подблоками ФС. Это позволяет экономить дисковое пространство и несущественно снижает производительность, особенно когда ПКФС использует механизмы упреждающего чтения и кэширование записи. 

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

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

Поддержка директорий. ПКФС использует механизм extensible hashing для организации директорий с большим количеством файлов. В директории, которая занимает больше одного блока, блок с нужным именем файла можно найти, применив хэш-функцию к имени и взяв n нижних бит как номер нужного блока (n зависит от размера директории).

При пополнении директории механизм extensible hashing добавляет блоки для дальнейшего размещения списка файлов. Как только не хватает места в блоке, указанном хэш-функцией, блок делится надвое. Логический номер нового блока директории вычисляется как номер старого блока с добавлением единички в (n+1) бит. Записи списка с ‘1’ в (n+1) бите хэш-фунции перемещаются в новый блок, остальные блоки остаются неизменными. Большие директории в общем случае выглядят как разбросанный файл с дырками, представленными блоками директории, которые не были разбиты надвое. Проходя разбросанные регионы директории в списке директории, можно определить, как часто блок был раздвоен и как много бит в значении хэш-функции, а также вычислить номер блока, содержащего нужную нам запись директории. Для этого необходим доступ только к одному блоку директории, не зависимо от размеров и структуры директории.

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

Каждый узел кластера имеет отдельный журнал для каждой ФС, сохраняемый в той же ФС. Такой порядок предназначен для доступности журнала для других узлов ФС и восстановления целостности ФС другим узлом в случае отказа узла, ведшего журнал. Для восстановления целостности ФС достаточно, не дожидаясь отказавшего узла, исполнить изменения, которые зарегистрированы в журнале.

После того как все изменения, запротоколированные в журнале, сделаны, протокол может быть очищен. Таким образом, размер журнала может быть фиксирован.

Распределенные блокировки и централизованная синхронизация. Производительность кластерной ФС может существенно превосходить производительность некластерной ФС, если использовать параллелизм операций чтения и записи сразу с нескольких узлов. С другой стороны, необходимость соблюдения целостности информации и POSIX-семантики ограничивают параллелизм. ПКФС гарантирует исполнение POSIX-се­мантики на одиночном узле для операций по всему кластеру. Например, если два процесса на различных узлах запрашивают один и тот же файл, то гарантируется, что первый узел, читая файл, будет видеть изменения другого узла, который пишет в этот файл. Исключение составляют записи atime. Учитывая популярность общего использования информации для множественного чтения информации различными узлами без изменения этой информации и дороговизну синхронизации чтения в таких случаях, ПКФС делает синхронизацию периодически, если не заданно другое.

Существует два подхода к организации необходимой синхронизации:

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

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

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

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

В механизме распределенных блокировок применяется менеджер централизованных глобальных блокировок, который запускается на одном из узлов кластера, в связке с локальными менеджерами на каждом узле ФС. Глобальный менеджер блокировок координирует процесс блокирования данных локальными менеджерами, раздавая так называемые блокировочные жетоны, которые дают право на блокировку данных без дополнительного обмена сообщениями каждый раз, когда данные блокируются или разблокируются. Повторяющийся запрос на чтение или запись одних и тех же данных одним и тем же узлом требует только одного сообщения для получения прав на объект – блокировочного жетона. Как только узел получил свой жетон от менеджера централизованных глобальных блокировок, последующая операция на том же узле может получить блокировку от локального менеджера без необходимости дополнительных обменов сообщениями между узлами кластера. Только когда на другом узле понадобится совершить операцию с заблокированными данными, возникнет необходимость отозвать блокировочный жетон с первого узла, дабы выдать жетон другому узлу.

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

Механизм побайтовой блокировки можно проиллюстрировать следующим примером. Первый узел для записи в файл получает жетон блокировки на весь файл. Пока этот файл не требуется другим узлам, все операции чтения/записи происходят локально, без обменов сообщениями между узлами. Когда второй узел начинает запись в наш файл, он потребует отзыва права побайтной блокировки хотя бы на свою часть файла. Первый узел, получив запрос на подтверждение прав на выданный побайтовый жетон на весь файл, проверит необходимость в данном файле, и если файл уже закрыт, то блокировка будет освобождена и жетон на весь файл будет выдан второму узлу. В этом случае механизм побайтовой блокировки ведет себя так же, как и механизм файловой блокировки и так же эффективен, так как требуется только один обмен жетонами для доступа ко всему файлу. Если файл еще не закрыт, первый узел уступит право только на часть файла. То есть если первый узел последовательно пишет с байта O1, а второй с O2, то первый узел уступит блокировку с байта O2 до бесконечности, если O2> O1, и с начала файла до O1, если O2

Информация о начальном байте и размере записываемого блока указывается в системном вызове процедуры write(). Это – требуемая  область, а желаемая область  включает в себя еще и последующие области записи данным узлом. Для последовательной записи желаемая область – это область от байта начала записи до бесконечности. Механизм побайтовой блокировки отзовет жетон только у того узла, с которым конфликтует операция записи; сервер блокировки выдаст жетон на блокировку такой области файла, которая будет наибольшей бесконфликтной областью.

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

Для приложений, которые не требуют выполнения POSIX-семантики и разделяют данные одного файла между узлами с очень маленьким размером блокируемых данных, ФС должна иметь возможность отключать механизм побайтовой блокировки и переключаться на механизм доставки данных, который можно описать как централизованное разделение функций ввода-вывода данных различным узлам. Блоки файла друг за другом назначаются узлам так, чтобы только один определенный узел смог бы  писать или читать назначенный блок. Операция чтения или записи пересылается узлу, отвечающему за нужный блок файла. Если приложение использует множественные блоки малого размера одного файла на разных узлах, то такой механизм будет более эффективен, чем механизм распределенной блокировки, так как необходимо небольшое количество обменов сообщениями с жетонами и нет необходимости записывать кэш-память узла в случае отзыва жетона у владельца. Время от времени происходит сброс кэш-памяти, который может происходить параллельно на всех узлах.

Синхронизация доступа к метаданным файла. Для хранения атрибутов файла и адресов блоков данных ФС использует «inodes» и списки блоков данных (косвенных блоков). Конкурентная запись в один и тот же файл различными узлами приводит к конфликтному изменению записи inode и косвенных блоков, так как при записи меняются размер файла, время последнего изменения (mtime) и, возможно, списки блоков данных. Применение механизма блокирования записи метаданных всего файла приведет к постоянному конфликту при любой операции записи. Однако есть и более эффективный механизм блокировки совместной записи inode. При этом механизме конфликт возникает только в то время, когда есть запрос на размер файла или время его создания или когда процесс читает файл за меткой конца файла. Один из узлов, который запрашивает доступ к файлу, назначается метаузлом для данного файла. Только этот узел может читать или писать inode файла. Каждый пишущий узел содержит свою копию записи inode в кэш-памяти и пересылает изменения записи inode метаузлу периодически или когда отзывается жетон блокировки совместной записи из-за запроса по операциям stat() или read() от другого узла. Метаузел обрабатывает информацию об изменениях записи inode, оставляя наибольший размер и более позднее время изменения файла. Операциям, которые изменяют размер и время создания файла нестандартно (trunc() или utime()), требуется эксклюзивная блокировка записи inode.

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

Таким образом, ФС, используя механизм распределенных блокировок, гарантирует выполнение POSIX-семантики (системные функции stat() предоставляют последнюю информацию о размере и времени обновления файла), а операции работы с записью inode и косвенными блоками синхронизируются по принципу централизации (пересылки изменений к метаузлу файла). Таким образом, наш механизм позволяет писать различным узлам в один и тот же файл без конфликтов блокировок метаданных и дополнительных сообщений метаузлу при каждой операции записи.

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

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

Выделение дискового пространства предусматривает изменение информации в таблице размещения, которое должно быть синхронизировано между узлами. Для правильного распределения данных по дискам, операция записи должна выделять место для одиночных блоков данных на отдельных дисках. Необходимо организовать таблицу размещений так, чтобы минимизировать конфликты между узлами и чередовать записи о свободном месте на разных дисках. Таблица разделяется на большое число n непересекающихся регионов, каждый регион содержит статус размещения 1/n-го блока каждого диска ФС. Такая карта позволяет ФС размещать дисковое пространство правильно, разделяя данные по всем дискам, обращаясь только к одному региону. Такой подход минимизирует конфликты блокировок, так как различные узлы могут выделять место в разных регионах. Общее число регионов определяется при создании ФС и исходит из числа узлов ПФС.

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

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

Глобальные метаданные ФС. Кроме файловых метаданных, ФС требуется такая информация, как конфигурация системы, квоты, списки доступа и расширенные атрибуты. Наша ФС использует распределенные блокировки для защиты целостности метаданных, но во многих случаях для координирования и сбора изменений метаданных более эффективным является централизация. Например, механизм квотирования позволяет выделять сравнительно большое место самим узлам, время от времени советуясь с менеджером квотирования.

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

Можно преодолеть эту проблему раздачей функций выдачи жетонов нескольким узлам кластера. Самый простой способ передачи функций раздачи жетонов – это применение hash-функции к номеру inode файла. Но это не дает необходимой масштабируемости в массовом параллельном обращении к одному файлу. В самом худшем случае конкурентная запись в файл с множества узлов породит побайтовый блокировочный жетон на каждый блок данных файла. Так как размер файла теоретически не ограничен, то и размер данных каждого жетона тоже не ограничен. Можно разделить право выдавать жетоны на один файл между всеми узлами кластера, но тогда получение блокировки на весь файл, что происходит в традиционных случаях, будет неоправданно дорогим. Не допустить бесконечного роста числа выданных жетонов можно, отслеживая использование оперативной памяти и уменьшая число выданных жетонов отзывом и выдачей их заново.

Конфликты блокировок – основная причина высокой нагрузки менеджера блокировок. Когда узел сокращает или освобождает жетон, данные и метаданные, которые покрываются жетоном, должны быть записаны на диск и/или выброшены из кэш-памяти.

Отказоустойчивость. Кластер ФС может достигать больших размеров, а это означает, что вопрос устойчивости к системным сбоям и выходу оборудования из строя поднимается на первые места.

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

Если сбойный узел вел журнал регистрации транзакций на общем диске, то восстановить согласованность представляется простым выполнением восстановительного процесса на рабочем узле по записанному журналу. После того как метаданные согласованны, менеджер блокировок может освободить блокировочные жетоны, занимаемые узлом, вышедшим из строя. По алгоритму механизма распределенных блокировок нужно убедиться, что неисправный узел должен был владеть всеми жетонами на метаданные, которые были изменены в кэш-памяти этого узла и еще не записаны на диск в момент сбоя. Метаданные, измененные плохим узлом, будут недоступны для других узлов, пока не закончится процесс восстановления, и только тогда, когда процесс закончится, блокировки метаданных будут сняты. Это справедливо и для механизмов, где применяется более централизованный подход к блокировкам, например, для изменения и оповещения о размере файла и mtime. Даже когда операции записи, порождающие подобные изменения метаданных, не синхронизированы через механизм распределенных блокировок, метаданные еще недоступны и защищены протоколом механизма распределенных блокировок (в этом случае через жетон метаузла).

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

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

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

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

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

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

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

Сбой дисков. Так как данные и метаданные распределяются по всем дискам равномерно, то потеря одного диска может привести к потере части большинства файлов. Для защиты от потери диска ФС применяются механизмы избыточности, такие как удвоение дисковых контроллеров, удвоение сетевых путей до дисков и RAID-техно­логии. При использовании RAID-технологии важно, чтобы размер RAID-блока данных был кратен размеру блока ФС для увеличения эффективности работы ПФС.

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

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

Для выполнения системных операций за приемлемое время требуется применение элементов параллелизма на системном уровне. Для координирования системных операций один из узлов кластера ФС назначается системным менеджером ФС. Системный менеджер занимается вопросами координации кластерных системных операций. Менеджер содержит несколько записей, похожих на inode, и раздает работу другим узлам. Если узел ФС закончит работу в своей зоне раньше, он может запросить дополнительную зону у менеджера. Для больших систем хранения нужно предусматривать выполнение всех системных операций в фоновом режиме при регулируемом приоритете системных операций. Исключением является операция полной проверки целостности ФС, когда требуется размонтировать ФС.

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