Некоторые направления развития файловых систем

^[1]

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

В традиционных системах хранения данных действия осуществляются как над небольшими блоками информации определенных размеров, так и над метаданными. На сегодняшний день развиваются системы хранения объектов, где вместо блоков с данными оперируют объектами, имеющими различные параметры. Системы хранения объектов базируются на стандарте T-10 Object Storage Devices (OSD).

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

Рисунок 1 – Блочная и объектная системы хранения

Одним из примеров файловых систем, построенных над системой хранения объектов, может служить exofs ^[2] (Extended Object File System).

Схему exofs можно изобразить следующим образом:

Рисунок 2 – Схема exofs

Виртуальный переключатель файловых систем VFS (Virtual File System Switch) дает доступ к exofs, а exofs уже взаимодействует с системой хранения объектов через локальный инициатор OSD.

Хотя хранение объектов является интересной идеей, Рави Тандон (Ravi Tandon), выпускник факультета компьютерных наук, считает, что будущее за log-структурированными файловыми системами. «Это мое мнение, так как в дальнейшем развитии систем хранения большую роль сыграют flash и SSD-технологии», – говорит Рави. Log-структурированные файловые системы идеально подходят для твердотельных накопителей, поскольку в этом случае операции записи распределяются равномерно по всему устройству, что ведет к снижению количества циклов стирания данных – это позволяет значительно продлить срок жизни SSD.

Идея log-структурированной файловой системы была предложена еще в 1988 году Джоном Остераутом (John Ousterhout) и Фредом Дуглисом (Fred Douglis), а реализована в 1992 году в операционной системе Sprite. Суть здесь в следующем: файловая система представляется в виде циклического журнала, куда записываются новые данные и метаданные, причем свободное место всегда берется с конца. Это означает, что в журнале может оказаться множество копий одного файла, но активной будет всегда считаться самая актуальная из них. Эта интересная особенность позволяет получить несколько преимуществ.

Рисунок 3 – Log-структурированная файловая система

Этот подход к хранению данных ведет к снижению накладных расходов при записи – запись осуществляется последовательно, данные быстрее оказываются на диске, потому файловая система работает быстрее. Еще Рави Тандон пишет, что log-структурированные системы поддерживают такие функции, как контроль версий и восстановление данных, фактически позволяя вам «путешествовать во времени».

Примером log-структурированной файловой системы может служить NILFS2 ^[3]. NILFS2 действительно умеет создавать моментальные снимки состояния файловой системы. Это очень удобно, если вам потребовалось восстановить ранее удаленные или утерянные файлы. Однако за все приходится платить, log-структурированная файловая система также не лишена недостатков – здесь приходится использовать сборщик мусора, чтобы удалить старые данные и метаданные. В эти моменты может наблюдаться значительное снижение производительности.

Два рассмотренных типа файловых систем конечно хороши (хоть и не лишены недостатков), однако есть и другие стоящие идеи. В частности, Джефф Дарси (Jeff Darcy), программист и блогер, считает ^[4], что в течение нескольких лет произойдет разделение на локальные и распределенные файловые системы, где вторые будут строиться на основании первых. Что касается первого случая, то последнее время все большую популярность приобретают файловые системы ZFS и Btrfs.

ZFS (Zettabyte File System) – это 128-битная файловая система, которая поддерживает файлы до смешного огромных размеров (16 эксабайт) и способна работать с дисковыми объемами до 256 зеттабайт. Лидер проекта ZFS Джефф Бонвик (Jeff Bonwick) сказал, что «заполнение 128-битных файловых систем превысит квантовые возможности хранения данных на Земле». «Вы не сможете заполнить и хранить 128-битный объем, не вскипятив при этом океаны», – отметил ^[5] Бонвик.

Пример того, насколько велики эти числа: если создавать тысячу файлов ежесекундно, то для достижения предела количества файлов в ZFS потребуется около 9000 лет. Вообще файловая система ZFS спроектирована таким образом, чтобы нельзя было столкнуться с какими-либо ограничениями в обозримом будущем.

Рисунок 4 – Традиционные файловые системы и ZFS

ZFS строится поверх виртуальных пулов с данными (zpool). Получается так, что все подключенные диски являются частью одного гигантского раздела. Более того, диски могут связываться друг с другом в виртуальные RAID-массивы, которые обладают способностью к «самоисцелению». Еще эта файловая система позволяет делать снапшоты, чтобы восстановить данные в случае повреждения. Подробнее о ZFS можно узнать здесь ^[6].

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

Что же касается распределенных файловых систем, то, по словам Джеффа Дарси, который занимается разработкой GlusterFS ^[7], за ними будущее. Однако в этом случае приходится уделять много внимания надежности. Вообще распределенная файловая система – это скопление независимых компьютеров, которые для пользователя выглядят как единая целостная система.

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

Рисунок 5 – Загрузка (слева) и выгрузка (справа) для DFS ^[8]

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

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

Кстати, совсем недавно мы рассказывали о том, как проверить надежность дата-центра (тут ^[9] и тут ^[10]). Помимо этого мы привели примеры ^[11] наших кейсов и подготовили календарь ^[12] мероприятий на 2016 год по теме ИТ-инфраструктуры, ИБ и телекома.

Автор: ИТ-ГРАД

Источник ^[13]