Будущее файловых систем Linux
На прошедшем в начале марте этого года мероприятии Vault, организованным Linux Foundation в Бостоне, было много разговоров о файловых системах и хранилищах. Если думаете, что там не было сказано ничего нового, то вы ошибаетесь.
Файловые системы в Линуксе, такие как Btrfs и варианты хранилищ постоянно развиваются. Технология FacebookStorage прошла долгий путь с момента, когда Линус Торвальдс принял ее до ее поддержки самой системой.В прошлые годы, к примеру, были попытки использовать флэш-накопители в качестве основного диска для сервера и SSD-диска для увеличения скорости работы с данными, приближаемой к работе с ОЗУ.Использование флэш-накопителей предложила компания SanDisk на базе решения InfiniFlash, которое предполагалось использовать в качестве замены жестких дисков при цене $1–2 за гигабайт.
В то же время, Big Data, облачные вычисления и контейнеризация предполагали поиск новых путей. Чтобы решить эти проблемы, разработчики Линукс развивают существующие файловые системы и хранилища файлов, а так же работают над новыми.
BtrfsК примеру, Крис Мэйсон, разработчик Facebook, и один из мейнтейнеров Btrfs, поделились информацией, как Facebook использует эту файловую систему. Она интересна тем, что хорошо подходит для работы как с большим количеством небольших файлов, так и с файлами до 16 экзабайт; собирается в рейд-массив; имеет встроенную систему сжатия и поддержку различных устройств хранения.
Конечно, Facebook широко использует Linux. Если быть точней, то в основном используются ядра 3.10 и 3.18 и собственный дистрибутив, основанный на базе CentOS. Для Facebook Btrfs стала поистине спасением, эта файловая система ведет себя стабильно и показывает большую скорость работы с бесконечными операциями ввода/вывода, производимыми участниками социальной сети. Это если брать хорошие новости. Из плохого — Btrfs показала себя очень плохо в работе с традиционными серверами хранения баз данных типа MySQL. Для них Facebook использует XFS. Для управления обоими файловыми системами применяется открытая распределенная файловая система Gluster, Facebook, с которыми работают рука-об-руку ведущие разработчики ядра Linux и Btrfs, занимаются увеличением скорости работы с системами хранения баз данных. Мейсон с коллегами добился приемлемой работы RocksDB на Btrfs.RocksDB это быстрая система хранения в формате ключ-значение, которая может быть использована как основа для клиент-серверной базы данных.С Btrfs помимо этого не все так гладко. Она содержит ошибки, которые проявляются в разные моменты. К примеру, вам хватило ума решить забить жесткий диск до отказа, но Btrfs будет обрывать запись доходя до определенной точки заполненности хранилища.Так же, команда разрабочтиков Btrfs работает над дедупликацией данных. Этот метод сжатия данных наиболее хорошо показывает себя тогда, когда в хранилище имеется большое количество хранимых файлов, мало отличающихся друг от друга, или имеющие много похожих элементов, как при хранении резервных копий. Мейсон так и сказал: «Это нужно не всем, он если это нужно, то это нужно по-настоящему!» Но Btrfs не единственная файловая система, над которой ведется серьезная работа и на которую следует ставить все. Джон Спрей, ведущий разработчик Red Hat рассказал о распределенной системе хранения Ceph.
Ceph FSCeph — это open source разработка эластичного легко масштабируемого петабайтного хранилища. В основе лежит объединение дисковых пространств нескольких десятков серверов в объектное хранилище, что позволяет реализовать гибкую многократную псевдослучайную избыточность данных. Разработчики Ceph дополняют такое объектное хранилище еще тремя проектами: 
RADOS Gateway — S3- и Swift-совместимый RESTful интерфейс RBD — блочное устройство с поддержкой тонкого роста и снапшотами Ceph FS — распределенная POSIX-совместимая файловая система Ceph представляет собой распределенную, легкомасштабируемое хранилище, которое позволяет создать объединение из серверов в объектное хранилище для реализации гибкой многократной псевдослучайной избыточности данных (RADOS, Reliable Autonomic Distributed Object Store). Разработчики выделяют такие основные компоненты:
OSD (Object Storage Device, устройство хранения объектов) Daemon: демон хранилища для сервиса, который обеспечивает связь с OSD (физической или логической единицей хранения данных). Этот демон должен быть запущен на каждом из серверов кластера, каждому OSD может быть указан отдельный жесткий диск с рейд массивом, LVM или пул Btrfs. По умолчанию создаются три пула: данные, метаданные и RDB MDS (Meta-Data Server, сервер хранения метаданных): Он построен в виде POSIX-файловой системы. Если вы не используете файловую систему Ceph, то сервер метаданных не потребуется. MON (Monitor): легковесный демон, который обеспечивает связь между внешними приложениями и клиентами. Так же предоставляет согласование для расширения в кластере Ceph/RADOS. Разработчики Ceph рекомендуют использовать для файловой системы в ханилище Btrfs, хотя XFS может быть лучшей альтернативой для «боевого» применения.После поглощения компании-владельца Ceph — Inktank в 2014 году, Red Hat плотно занялась подготовкой CephFS для применения в продакшене.Над CephFS еще предстоит большая работа, пускай она и работает, но в ней отсутствуют такие важные инструменты для мониторинга или тестрования/исправления ошибок.В данный момент Red Hat как раз занимается разработкой fsck и системой журналирования, а так же улучшения возможности создания снапшотов, улучшения контроля над клиентами или интеграцией в контейнеры и облака. На сегодняшний день, по словам Спрея, CephFS в качестве файловой системы могут использовать, либо очень крутые и храбрые, либо очень глупые.
Остальное по-мелочи
Из того, что было интересного на бостонской встрече: Джеф Лэйтон, ведущий разработчик компании Primary Data, рассказал, что занимается созданием эмуляции отключения электропитания для тестирования файловых систем. Эта возможность будет добавлена в приложение xfstests. Не смотря на название, помимо XFS, есть поддержка основной части популярных на данный момент файловых систем.
Рик ванРиел, разработчик Red Hat, поделился проблемой работы с ОЗУ в качестве хранилища данных. Т.е оно работает, если использовать эти ресурсы как ОЗУ, или как хранилище, но когда потребуется что-то большее, возникают трудности. К примеру, нет возможности создания снапшотов для резервного копирования, при использовании оперативной памяти по назначению.Пока решения нет, но программисты работают над этим. И пока в Линуксе существует большое количество всевозможных файловых систем и хранилищ, работы будет предостаточно. Технологии не стоят на месте. ОС Linux работает на всем, начиная с простого гаджета типа кофеварки, десктопов, облачных систем и заканчивая супер-компьютерами, у которых разные требования к хранению данных.
