Содержание статьи
Файловые системы, как и любой другой компонент современных операционных систем, постоянно развиваются и сменяют друг друга. С ростом объемов хранилищ информации и появлением новых технологий обработки данных старые подходы к хранению информации отмирают, и на смену им приходят более совершенные и приспособленные к современным условиям. Следующие четыре полосы журнала посвящены последним тенденциям в области развития ФС.
Freebsd и журналируемая файловая система
8 декабря прошлого года Джефри Роберсон, создатель планировщика ULE и один из активных разработчиков FreeBSD, сообщил в своем блоге (http://jeffr-tech.livejournal.com) о проводимой работе над механизмом журналирования для стандартной файловой системы FFS (Fast FileSystem) ОС FreeBSD. Эта новость сразу стала поводом для насмешек со стороны многочисленных троллей, которые в очередной раз окрестили BSD-системы ходячим трупом. Однако никто из них так и не понял сути происходящего. На самом деле разработанный Джефри механизм журналирования не совсем стандартен и достаточно прост, а его появлению 5 или даже 10 лет назад мешало только то, что в нем просто не было необходимости. Чтобы понять, почему, и в чем отличия нового механизма от появившегося не так давно GEOM-модуля gjournal (который теоретически позволяет прикрутить журнал даже к FAT12) или механизма журналирования «официальных» файловых систем Linux, обратимся к истории.
Исторически файловая система представляет собой совокупность метаданных и блоков, непосредственно хранящих пользовательские данные. Во время произведения какой-либо операции над файлом происходит модификация сразу нескольких областей ФС, включая шаги по изменению метаданных и модификацию содержимого файла. Например, при создании нового файла, кроме непосредственной записи его содержимого на диск, ФС должна сделать следующее:
- Записать информацию о файле (тип, права доступа, количество ссылок и т.д.) в таблицу inode;
- Пометить блоки, выделенные для хранения файла, как занятые;
- Записать связку “inode:имя_файла” в файл каталога.
Причем все эти действия должны быть выполнены именно в такой последовательности. В идеальном мире все было бы прекрасно, однако реальность вносит свои коррективы. Подсистеме VFS, лежащей уровнем выше, и кэшу жесткого диска ничего неизвестно о метаданных. Для них вся записываемая информация — простой набор байт, поэтому если метаданные будут записываться на диск в асинхронном режиме, проходя через кэш VFS и жесткого диска, никто не сможет гарантировать их запись в правильном порядке. Это обязательно приведет к противоречивому состоянию ФС в случае сбоя («повисшие» указатели, неоднозначная принадлежность ресурсов, «осиротевшие» ресурсы), и тогда — привет, fsck, а в некоторых случаях — пересоздание ФС.
Для решения этой проблемы можно использовать комбинированный режим записи, при котором метаданные будут записаны в синхронном режиме, а данные — в асинхронном. Тогда фатальных ошибок ФС можно избежать, и даже если сбой произойдет между вторым и третьим шагом вышеприведенной последовательности, ошибки будет легко исправить с помощью выполнения fsck даже на уже смонтированной ФС. Но вот засада: синхронный режим записи приводит к колоссальным потерям производительности, а сама запись идет очень медленно.
Для обхода этой проблемы в свое время было предложено множество различных способов, из которых особенно популярным стал механизм журналирования. Суть проста: где-то в файловой системе отводится небольшой участок для хранения журнала. Когда возникает запрос на создание или модификацию файла, вся информация об изменяемых при этом метаданных объединяется и помещается в журнал с помощью единой атомарной операции записи. Непосредственная же запись метаданных происходит в асинхронном режиме. В момент, когда все метаданные файла попадут на диск, соответствующая запись удаляется из журнала. В случае сбоя для приведения ФС в непротиворечивое состояние будет достаточно просто извлечь из журнала все записи и применить их к файловой системе. Это разумный компромисс между производительностью и стабильностью: хотя запись в журнал и сказывается на производительности, но далеко не так сильно, как синхронная запись метаданных на диск, при которой головке винчестера приходится метать ся между разными участками диска.
Разработчики FreeBSD пошли по другому пути, применив механизм под названием «мягкие обновления» (Soft Updates). В двух словах, его суть заключается в использовании специального кэша файловой системы для хранения изменений метаданных, их объединения и поддержки зависимости между друг другом. Это гарантирует правильную последовательность записи метаданных на диск и в то же время не требует их синхронной записи. При использовании «мягких обновлений» сбой может привести только к двум несогласованностям файловой системы: повисшие inode и блоки. Они не относятся к глобальным несоответствия м ФС (таким, например, как блоки, одновременно адресуемые двумя inode), поэтому она может быть смонтирована, а fsck запущен в фоновом режиме на уже смонтированной ФС (собственно, так и происходит, начиная с пятой ветки FreeBSD).
Единственный заметный минус Soft Updates в сравнении с журналом состоит в том, что запущенный в фоновом режиме fsck заметно кушает ресурсы, что при больших объемах дисков может привести к достаточно длительным провалам производительности. Само собой, такое положение вещей не нравилось многим, и, в конце концов, компании iXsystems, Yahoo! и Juniper networks «скинулись» и заплатили Джефри за исправление этого недочета.
Новая система журналирования (работа над которой велась совместно с автором «мягких обновлений» — Кирком МакКузиком) стала ничем иным, как простым расширением технологии Soft Updates. В отличие от традиционных систем журналирования, она регистрирует только те самые операции выделения и освобождения блоков и inode, тогда как все остальное берет на себя механизм Soft Updates. Благодаря этому удалось достичь минимальных размеров журнала и более высокой по сравнению с традиционным журналированием производительности.
SDFS — файловая система для виртуальных окружений
Модель облачных вычислений приобретает все большую популярность. Для многих компаний (и даже частных лиц) проще и выгоднее арендовать на время уже готовые к работе выделенные виртуальные серверы, чем покупать дорогостоящее серверное оборудование и оплачивать его поддержку. Виртуальные серверы удобны, надежны, их легко восстановить после сбоев. Однако провайдеру услуг облачных вычислений их содержание обходится в кругленькую сумму, что сказывается на стоимости аренды, и, следовательно, на популярности среди клиентов. В среде провайдеров постоянно идет поиск способов удешевления содержания виртуальных машин и всей инфраструктуры в целом. Один из способов сделать это заключается в использовании технологии дедупликации данных, которая позволяет сэкономить существенные средства на объемах дискового хранилища.
Дедупликация данных представляет собой процесс исключения избыточности данных путем удаления лишних копий информации и сохранения на их месте ссылок на единственный экземпляр. Чтобы понять, почем у это так важно, и сколько дискового пространства можно сэкономить, представь себе следующую картину: ты занимаешься предоставлением услуг типа «виртуальный сервер в аренду», и для любого обратившегося к тебе клиента создаешь виртуальный сервер на основе Red Hat Enterprise Linux 5. Дела идут хорошо, поток клиентов растет, и вскоре их количество приближается к отметке 1000. Ты имеешь хорошую прибыль, но большая ее часть уходит на покупку нового железа.
Если представить, что каждому клиенту ты выделяешь 10 Гб дискового пространства, то для обслуживания 1000 клиентов тебе понадобится примерно 10 Тб дискового пространства, а это около 20 жестких дисков по 500 Гб каждый. При этом как минимум четыре из них используются для хранения одних и тех же данных, ведь базовая инсталляция ОС занимает около 2 Гб, а все эти клиенты используют одну ОС. Сложив, получаем 2 Тб копий копий копий базовой инсталляции Red Hat Enterprise Linux 5. Применив дедупликацию, ты смог бы избавиться от всех этих копий, освободив солидный участок пространства, которое заняли бы еще 200 клиентов!
Поддержка дедупликации данных существует в некоторых решениях NAS и коммерческих программных продуктах. Она была добавлена в файловую систему ZFS в ноябре 2009 года, а совсем недавно была выпущена дедуплицирующая распределенная файловая система SDFS, разработанная в рамках открытого проекта Opendedup (www.opendedup.org). Несмотря на название, SDFS не является файловой системой в прямом смысле слова. Это прослойка, написанная на языке Java и реализованная с использованием механизма для создания файловых систем пространства пользователя fuse (fuse.sf.net). SDFS состоит из следующих компонентов:
- Fuse Based File System. Файловая система уровня пользователя, предоставляющая доступ к файлам и каталогам.
- Dedup File Engine. Сервис на стороне клиента, который принимает все запросы на доступ к файлам от файловой системы и отвечает за хранение метаданных и карты дубликатов, связанных с файлами и каталогами.
- Deduplication Storage Engine. Серверная сторона, движок дедупликации. Отвечает за хранение, извлечение и удаление повторяющихся данных. Для хранения данных использует низлежащую файловую систему или хранилище Amazon S3, индексируя блоки с помощью хэш-таблицы.
На всех машинах, которые должны участвовать в хранении данных, запускается движок дедупликации. На клиентских машинах, использующих хранилище данных, запускается сервис Dedup File Engine, который подключается к доступным движкам дедупликации и получает доступ к хранилищу. Для общения с Dedup File Engine файловая система (Fuse Based File System) использует механизм JNI (Java Native Interface).
Кроме стандартной файловой системы для хранения данных может использоваться хранилище Amazon S3. Общий размер ФС способен достигать 8 Пб, максимальный размер одного файла — 250 Гб, файловая система может быть «размазана» по 256 различным хранилищам, обслуживаемым Deduplication Storage Engine. Выявление и устранение дубликатов данных происходит на уровне блоков размером 4 Кб. Файловая система способна производить дедупликацию на лету (во время записи новых данных) или же запускаться в промежутках наименьшей активности операций ввода-вывода как фоновый процесс. Среди других особенностей SDFS можно отметить поддержку снапшотов на уровне файлов и каталогов, поддержку экспорта с помощью протоколов NFS и CIFS и достаточно высокую производительность.
CEPH — распределенная файловая система
Ситуация с распределенными файловыми системами в мире Open Source далека от идеала. Существует множество готовых для промышленной эксплуатации проектов, однако ни один из них не может похвастаться хорошим сочетанием важных для распределенных ФС характеристик. Одни обладают высокой надежностью, но проваливают тесты на производительность, другие вырываются в лидеры по скорости доступа, но обеспечивают не самый лучший показатель надежности и расширяемости, третьи могут расти почти до бесконечности, но издевательски медленны. Не удивительно, что исследовательские работы в этой области ведутся непрерывно, и почти каждый год мы становимся свидетелями рождения новой распределенной ФС, которая претендует на звание идеала. Это произошло и с файловой системой Ceph, которая оказалась настолько успешной, что код ее клиента было решено включить в Linux-ядро версии 2.6.34.
Ceph (http://ceph.newdream.net) имеет достаточно долгую историю развития; впервые ее архитектура была описана автором Сэйджем Вилом в его дипломной работе в 2006 году. К ноябрю 2007 года он представил стабильную версию, реализованную с использованием fuse, и начал работать над реализацией модуля для ядра Linux. Сегодня Ceph уже достаточно стабильна для повседневного использования.
Среди главных плюсов Ceph автор отмечает следующие:
- Совместимость со стандартом POSIX;
- Прозрачное масштабирование от десятка до тысячи узлов;
- Общий объем хранилища (может составлять сотни петабайт);
- Высокие показатели доступности и надежности;
- N-way репликация всех данных на множество узлов;
- Автоматическая ребалансировка данных в случае добавления/удаления узла для более эффективного использования ресурсов;
- Простота развертывания (большинство компонентов файловой системы реализованы в виде демонов пространства пользователя);
- Наличие fuse-клиента;
- Наличие клиента для ядра Linux.
В отличие от кластерных файловых систем, таких как GFS, OCFS2 и GPFS, которые опираются на симметричный доступ всех клиентов к общим блочным устройствам, Ceph разделяет управление данными и метаданными путем использования независимых кластеров (примерно так же, как это делает Lustre). Однако, в отличие от последней, узлы, управляющие метаданными и хранилищем, не требуют какой бы то ни было поддержки со стороны ядра; весь код работает в пространстве пользователя. Для хранения объектов данных узлы могут использовать блочные устройства, образы или низлежащую файловую систему. Когда один из узлов дает сбой, данные реплицируются самими узлами, благодаря чему достигается высокий уровень эффективности и масштабируемости.
Серверы, отвечающие за хранение метаданных (metadata server), представляют собой нечто вроде большого согласованного распределенного кэша на вершине кластера-хранилища, который динамически перераспределяет метаданные в ответ на изменение нагрузки и легко переносит выход узлов из строя. Metadata server использует особый подход для хранения метаданных, который позволяет достичь высоких показателей производительности. Например, inode-запись, имеющая только одну жесткую ссылку, помещается прямо в каталоговую запись.
Поэтому каталог вместе со всеми адресуемыми им inode'ами может быть загружен в кэш с помощью одной операции ввода-вывода. Содержимое очень больших каталогов фрагментируется и отдается на управление независимым metadata-серверам, благодаря чему операцию доступа к каталогу можно легко распараллелить.
По словам автора Ceph, наиболее важное достоинство его ФС заключает ся в полностью автоматизированном механизме ребалансировки и миграции при масштабировании от небольшого кластера, состоящего из нескольких узлов, до кластера корпоративных масштабов, в котором участвуют несколько сотен узлов. Этот процесс требует минимального вмешательства администратора, новые узлы могут быть подключены к кластеру, и все будет «просто работать».
Что там с ZFS?
На сегодняшний день ZFS остается самой продвинутой файловой системой, аналогов которой нет не только в мире Open Source, но и в среде коммерческого ПО. Она быстра, надежна, имеет богатый функционал и невероятно проста в администрировании. Изначально созданная компанией Sun Microsystems (привет Oracle) для операционной системы Solaris и анонсированная в 2005 году, она сразу стала лакомым кусочком для пользователей и разработчиков других операционных систем. Однако далеко не всем из них удалось почувствовать ее вкус.
Первыми претендентами на включение кода ZFS в свою ОС стали, конечно же, линуксоиды, готовые тащить в ядро все, что не привинчено болтами. Но судьба (роль которой, скорее всего, сыграла сама Sun) распорядилась иначе. Код ZFS, как и всей операционной системы OpenSolaris, оказался защищен лицензией CDDL, которая накладывает серьезные ограничения на его использование и, более того, совершенно несовместима с лицензией GPLv2, используемой ядром Linux. Фактически это означает, что есть только три пути включения ZFS в ядро: нелегальный, который включает в себя перенос ZFS без соблюдения закона об авторском праве, юмористический, при котором код Linux лицензируется под CDDL, и титанический, когда огромная кодовая база ZFS переписывается под GPL, да еще и с обходом Sun'овских патентов.
В общем — не комильфо, поэтому единственный способ задействовать ZFS в Linux — это использовать ее порт на fuse (http://zfs-fuse.net), страдающий багами и низкой производитель ностью, которая в силу архитектурных особенностей ZFS вряд ли сможет повыситься без переноса хотя бы части кода в ядро. Компания Apple также планировала внедрение ZFS в Mac OS X и даже успела выпустить экспериментальный драйвер и внедрить поддержку чтения ZFS в версию 10.5 Leopard, однако в октябре 2009 года проект закрыли без объяснения причин. Учитывая то, что лицензия BSD, покрывающая код ядра Mac OS X, позволяла без проблем перенести ZFS в ОС от Apple с минимальными затратами, такой поступок можно объяснить либо давлением со стороны Sun, либо глобальными изменениями в планах самой Apple.
В апреле 2007 года Павел Якуб Давидек закончил портирование ZFS в FreeBSD. На протяжении двух лет код был помечен как экспериментальный, но после исправления ряда проблем разработчик объявил о стабилизации порта, и 15 октября прошлого года FreeBSD стала первой ОС после Solaris, готовой к промышленной эксплуатации ZFS. По состоянию на 11 января 2010 года восьмая ветка FreeBSD полностью поддерживает zpool v14 (текущая версия ZFS в OpenSolaris: zpool v16).
Работа по поддержке ZFS велась и разработчиками NetBSD. В рамках проекта Google Summer of Code 2007 был представлен начальный (но неработающий) порт файловой системы. Работа по доведению кода до ума продолжилась как часть Summer of Code 2009, и в августе 2009 года поддержка ZFS была добавлена в репозиторий NetBSD.
Небольшая часть кода ZFS открыта под GPL, благодаря чему удалось интегрировать его в загрузчик GRUB, который теперь умеет выполнять загрузку с ZFS-раздела.
