Файловые системы ближайшего будущего. Часть 2
Hammer
dragonflybsd.org/hammer
Hammer – это 64-битная кластерная файловая система, построенная на B-деревьях, созданная специально для своего проекта DragonFly BSD известным гуру из FreeBSD Project, - Мэттью Диллоном (Matthew Dillon).
Давайте перечислим основные возможности Hammer, которые доступны уже на данный момент (или реализация которых близка к завершению): . Hammer – это файловая система, доступная немедленно даже после падения и перезагрузки системы, здесь нет fsck.
. Размер ФС Hammer может достигать размера до 1 экзабайта (1 миллиард гигабайт), при этом вмещать в себя до 256 томов, каждый из которых может достигать размера до 4 петабайт (4096 терабайт).
. Возможность отката любой дисковой операции и возврата состояния ФС в определенную точку.
. Метод крупнозернистой истории реализуется через мгновенные снимки ФС (снапшоты). По умолчанию системный крон генерирует один снапшот в день, который хранится в течение 60 дней. Количество и частота снапшотов не ограничена. Все хранимые снапшоты индексируются также
посредством B-дерева таким образом, чтобы сделать их хранение на носителях максимально эффективным. Каждый отдельный снапшот полностью отражает состояние файловой системы в заданный промежуток времени. Параллельный метод мелкозернистой истории фиксирует все системные операции в пределах около 20-60 секунд, которые также доступны для отката или повтора (undo/redo options), а также их анализа в случае любого сбоя (мелкозернистая история используется, чтобы избежать избыточных и ресурсоемких операций, характерных для снапшотов, при этом не теряя непрерывного контроля за системой).
. Возможность инкрементального зеркалирования без использования очередей операций, поддержка режима "один master и много slave".
. Заканчивается тестирование работы в multi-master режиме с распределением данных на несколько хостов сети (резервирование за счет
дублирования данных на разные машины). Также реализована поддержка асинхронных транзакций.
. Возможности для создания псевдо-файловой системы (PFS) внутри файловой системы Hammer. Можно создать до 65.535 таких файловых систем. Каждая PFS задействует независимое пространство нумерации inode'ов, что позволяет использовать ее в качестве источника или цели репликации. . Реализована система контроля максимально эффективного распределения пропускной способности канала при выполнении множественного бэкапа ФС (или ее PFSs) на ее slave-PFSs, физически находящиеся на удаленных хостах.
. Поддержка автоматического объединения дубликатов данных на всех PFS (дедупликация).
. Из недостатков – для очистки и реблокинга ФС (pruning/reblocking ops) требуется регулярный запуск специальной сервисной задачи (она выполняется быстро, как правило, в пределах нескольких минут).
Нелишним будет еще раз подчеркнуть, что Hammer в стабильной версии доступен на данный момент лишь на своей родной DragonFly BSD (имеется экспериментальный FUSE-модуль для Linux, который позволяет работать с этой ФС в режиме read-only).
Ссылки по теме Hammer:
http://en.wikipedia.org/wiki/HAMMER
http://www.dragonflybsd.org/hammer/hammer.pdf
http://dlorch.github.com/hammer-linux/
XFS
www.xfs.org
Несмотря на солидных новичков, описанных выше, также в список ФС будущего был включен и яркий представитель “старой школы”, которым в полной мере является самая прогрессивная ФС 90-х годов – XFS. Хотя нужно сразу отметить, что несмотря на то, что XFS во многом проигрывает всем трем вышерассмотренным представителям “новой школы” по отдельным решениям, при этом, в общем и целом, XFS смотрится достаточно современно, вполне удовлетворяя потребности индустрии на “сегодня”, тогда как вышерассмотренные ФС проектируются уже скорее исходя из вызовов “грядущего завтра”. Итак, XFS – это 64-битная высокопроизводительная журналируемая файловая система, созданная компанией Silicon Graphics, полностью основанная на уже проверенной временем технологии B-деревьев. Следуя уже привычной схеме, приведем ее типичные черты, также остановившись и на недостатках, которые отчетливо проступают по мере ее использования в современных условиях.
. Реализована поддержка очень больших файлов.
. Несмотря на то, что официально XFS везде позиционируется как настоящая 64-битная ФС, стратегия дискового драйвера реализована так, что он везде, где это только возможно, избегает использования 64-битного режима адресации, используя 32-битную адресацию, для чего активно используются AGs (allocation group, AG).
. XFS официально - журналируемая файловая система, но опять же, с той лишь оговоркой, что фиксируются лишь изменения метаданных, включая операции с суперблоком, AGs, inodes, каталогами и свободным пространством. При этом XFS вообще никак не журналирует пользовательские данные.
. Другая яркая индивидуальная особенность XFS, что эта ФС была изначально спроектирована с прицелом обеспечения максимально
высокопроизводительного доступа к файловой системе, вплоть до сотен Mb/s. Для этого реализовано специальное распараллеливание I/O-запросов, активно применяется стратегия размещения файлов как можно более непрерывно, имеется отложенное выделение зон (delayed file extent
allocation), реализовано многопоточное чтение-запись (по потоку на каждый экстент), используется агрессивная стратегия группировки
(clustering) запросов на запись и т.д., - что в сумме очень актуально в современных условиях повсеместного распространения скоростных дисковых устройств.
. Нужно отметить ярко выраженное следствие применения механизма отложенного размещения, о котором мы упомянули выше: его эффективность прямо пропорциональна имеющейся величине оперативной памяти (RAM), что опять-таки очень выгодно при современных тенденциях развития серверного оборудования.
. Реализация журнала транзакций является самым противоречивым в устройстве XFS, так как дизайн таков, что через него проходят все изменения метаданных файловой системы.
. Слабое место XFS – скорость обработки каталогов, содержащих большое количество файлов: при таком сочетании условий сложность реализации алгоритма листинга каталогов приводит к некоторым провалам производительности этой ФС. В таком случае рекомендуется использование специальной утилиты xfs_fsr для оптимизации работы файловой систем и устранения узких мест в скорости отклика файловой системы.
И все-таки, несмотря на несколько скептическое отношение к XFS в этом обзоре, следует признать, что у этой ФС есть реальные шансы претендовать на большое будущее. Как сообщает ведущий разработчик из Red Hat Валери Орорэ (Valerie Aurora), эта крупная компания всерьез заинтересовалась XFS, пригласив к себе на работу ее трех самых активных разработчиков. Уже в 2010 году RedHat сделала более 70% всех коммитов в драйвер XFS для ядра Linux, а в 2011-2012 годах намерена продолжить серьезное развитие XFS, для достижения паритета ее возможностей с ведущими ФС “новой школы”.
Интересно также, что, по словам Эрика Сандина (Eric Sandeen), еще одного из разработчиков XFS в RedHat, XFS, которая традиционно считается очень сложной реализацией ФС, в процессе ее развития постепенно упрощается – что хорошо заметно даже через постепенную регрессию строк в ее Linux- драйвере, тогда как те же btrfs и ext4 демонстрируют взрывной рост сложности по мере своего развития. Этот же разработчик отмечает, что если дополнительно учесть очень тщательное комментирование XFS (примерно 40% всех строк в исходниках драйвера – это комментарии к коду), то раздувание и усложнение кодовой базы btrfs будет даже еще большим (против 17% комментариев соответственно).
Ссылки по теме XFS:
http://oss.sgi.com/projects/xfs/
http://xfs.org/index.php/XFS_FAQ
http://oss.sgi.com/projects/xfs/design_docs/
http://filesystems.nm.ru/my/xfs_arch.pdf
http://xfs.org/index.php/XFS_Status_Updates
Практические выводы
Ну что ж, ознакомившись с наиболее перспективными файловыми системами ближайшего будущего по версии экспертов Google, попробуем определиться и сделать свой выбор, чтобы как следует подготовиться, как выразился вышеупомянутый разработчик из Google, к приходу “Эпохи Больших Данных”. Для удобства я свел все общие данные о рассмотренных нами ФС в таблицу.
И нашу практическую часть обзора предлагаю начать с XFS. Эта файловая система очень хорошо масштабируется, она уже сейчас способна оперировать огромными объемами данных. Большая скорость ввода-вывода – конек этой файловой системы. Дополнительным условием эффективности XFS является наличие качественного питания (внезапные отключения достаточно неприятны для нее) и больших объемов оперативной памяти на сервере, что позволяет раскрыть весь потенциал механизма отложенного размещения и прочих “ленивых” техник, обильно реализованных в XFS. Сильная многопользовательская нагрузка на хранилище позволяет продемонстрировать XFS свой инновационный механизм параллельной записи и низкую ресурсоемкость.
При этом важно понимать, что идеала не существует, и узким местом именно этой ФС являются операции над большим количеством мелких файлов или удаление развесистых деревьев каталогов - в этом случае вы вряд ли увидите ту производительность, на которую рассчитывали. Если не считать большой проблемой невозможность уменьшить размер уже созданной ФС – вот, пожалуй, и все узкие места этой надежной и уже проверенной временем файловой системы. Что касается конкретных реализаций, то XFS прекрасно чувствует себя как на Linux, так и на FreeBSD, поэтому выбрать платформу для хранилища здесь есть из чего.
Что же касается ZFS, то первое что приходит на ум, это параноидальное недоверие этой ФС к железу, когда контроль за целостностью данных носит многоуровневый и чрезвычайно изощренный характер. Здесь невольно вспоминается, что на заре SATA, когда первые диски с этим интерфейсом выпускались с большим количеством брака, порождая проклятия особенно со стороны обладателей ext2, разработчиков ZFS на многих конференциях можно было увидеть в майках с мессианской надписью “ZFS любит SATA”, они как бы подчеркивали, что эта ФС способна позаботиться о вверенных ей данных, даже если само “железо” не всегда способствует этому. Поэтому, если у вас в серверной обилие дешевого железа, или ваши серверы хранят просто бесценные данные (или, для наибольшей изощренности, и то и другое вместе) – ZFS будет очень удачным выбором.
С другой стороны – степень масштабируемости системы под ZFS просто безгранична. Если учесть скорость ее работы, как правило выше среднего, и огромный выбор и гибкость настроек (добавьте сюда родной менеджер томов и программный RAID-контроллер) – это, пожалуй, идеальный выбор для создания больших хранилищ данных. И если последнее утверждение можно смело отнести к Solaris/FreeBSD, то в отношении Linux нужно сделать отдельную важную оговорку.
ZFS не была включена в ядро Linux из-за патентных ограничений, и чтобы обойти это, был собран FUSE-модуль для поддержки этой ФС в Linux на пользовательском уровне. Конечно, потери скорости и стабильности работы в таком варианте ФС огромны. Но, к счастью, существует как минимум два сторонних решения, где поддержка ZFS реализована все-таки на уровне ядра в качестве самостоятельного модуля. Это, прежде всего, Native ZFS во главе с Брайаном Белендорфом (проект финансируется Министерством энергетики США). Во-вторых, альтернативный, но такой же открытый и бесплатный вариант от индийской компании KQ Infotech. Лично я рекомендую остановиться на последнем варианте, так как это более качественная и полная реализация ZFS для Linux (дополнительно обеспечена поддержка ZFS POSIX Layer). Но, в обоих случаях, несмотря на все озвученные плюсы, ZFS все- таки не самый сильный выбор для Linux, так как вы останетесь с этим выбором наедине, лишенные поддержки со стороны официальных разработчиков ядра, тем более если учесть скорое пришествие Btrfs…
Кстати, о Btrfs. Имеет смысл рассматривать эту ФС пока применительно только к ОС Linux (то же самое можно сказать и о Hammer к DragonFlyBSD), и можно определенно сказать, что через годик-другой это будет наиболее универсальный и взвешенный выбор для этой ОС из всех возможных. А пока… эта файловая система отлаживается, расширяется, растет и активно проходит фазу становления, необходимую для ее окончательного взросления. По словам ее ведущего разработчика, переход на эту ФС в качестве основной для Linux запланирован на 2013 год.
Заключение
Возвращусь к примеру, с которого мы начали эту статью, где докладчик Майкл Рубин в качестве примера выбора ФС сообщил, что Google на данный момент использует на своих Linux-серверах ФС ext4 с полностью отключенным журналированием, полагаясь на аппаратные решения для сохранения целостности своих данных. Как оказалось, в стандартной конфигурации ext4 операции журналирования понижали производительность системы на 23-35% в зависимости от типа журнала, что оказалось в итоге неприемлемым для поискового гиганта. “Поэтому выбор системы, ее режим работы и даже оборудование для ее реализации – задача сугубо индивидуальная. При этом важно всегда смотреть вперед и не забывать про перспективу: ext4 позволяет провести прозрачную миграцию на Btrfs, поэтому мы остановились именно на ней”, – объясняет стратегический выбор своей компании Майкл Рубин.
Игорь Савчук
dragonflybsd.org/hammer
Давайте перечислим основные возможности Hammer, которые доступны уже на данный момент (или реализация которых близка к завершению): . Hammer – это файловая система, доступная немедленно даже после падения и перезагрузки системы, здесь нет fsck.
. Размер ФС Hammer может достигать размера до 1 экзабайта (1 миллиард гигабайт), при этом вмещать в себя до 256 томов, каждый из которых может достигать размера до 4 петабайт (4096 терабайт).
. Возможность отката любой дисковой операции и возврата состояния ФС в определенную точку.
. Метод крупнозернистой истории реализуется через мгновенные снимки ФС (снапшоты). По умолчанию системный крон генерирует один снапшот в день, который хранится в течение 60 дней. Количество и частота снапшотов не ограничена. Все хранимые снапшоты индексируются также
посредством B-дерева таким образом, чтобы сделать их хранение на носителях максимально эффективным. Каждый отдельный снапшот полностью отражает состояние файловой системы в заданный промежуток времени. Параллельный метод мелкозернистой истории фиксирует все системные операции в пределах около 20-60 секунд, которые также доступны для отката или повтора (undo/redo options), а также их анализа в случае любого сбоя (мелкозернистая история используется, чтобы избежать избыточных и ресурсоемких операций, характерных для снапшотов, при этом не теряя непрерывного контроля за системой).
. Возможность инкрементального зеркалирования без использования очередей операций, поддержка режима "один master и много slave".
. Заканчивается тестирование работы в multi-master режиме с распределением данных на несколько хостов сети (резервирование за счет
дублирования данных на разные машины). Также реализована поддержка асинхронных транзакций.
. Возможности для создания псевдо-файловой системы (PFS) внутри файловой системы Hammer. Можно создать до 65.535 таких файловых систем. Каждая PFS задействует независимое пространство нумерации inode'ов, что позволяет использовать ее в качестве источника или цели репликации. . Реализована система контроля максимально эффективного распределения пропускной способности канала при выполнении множественного бэкапа ФС (или ее PFSs) на ее slave-PFSs, физически находящиеся на удаленных хостах.
. Поддержка автоматического объединения дубликатов данных на всех PFS (дедупликация).
. Из недостатков – для очистки и реблокинга ФС (pruning/reblocking ops) требуется регулярный запуск специальной сервисной задачи (она выполняется быстро, как правило, в пределах нескольких минут).
Нелишним будет еще раз подчеркнуть, что Hammer в стабильной версии доступен на данный момент лишь на своей родной DragonFly BSD (имеется экспериментальный FUSE-модуль для Linux, который позволяет работать с этой ФС в режиме read-only).
Ссылки по теме Hammer:
http://en.wikipedia.org/wiki/HAMMER
http://www.dragonflybsd.org/hammer/hammer.pdf
http://dlorch.github.com/hammer-linux/
XFS
www.xfs.org
. Реализована поддержка очень больших файлов.
. Несмотря на то, что официально XFS везде позиционируется как настоящая 64-битная ФС, стратегия дискового драйвера реализована так, что он везде, где это только возможно, избегает использования 64-битного режима адресации, используя 32-битную адресацию, для чего активно используются AGs (allocation group, AG).
. XFS официально - журналируемая файловая система, но опять же, с той лишь оговоркой, что фиксируются лишь изменения метаданных, включая операции с суперблоком, AGs, inodes, каталогами и свободным пространством. При этом XFS вообще никак не журналирует пользовательские данные.
. Другая яркая индивидуальная особенность XFS, что эта ФС была изначально спроектирована с прицелом обеспечения максимально
высокопроизводительного доступа к файловой системе, вплоть до сотен Mb/s. Для этого реализовано специальное распараллеливание I/O-запросов, активно применяется стратегия размещения файлов как можно более непрерывно, имеется отложенное выделение зон (delayed file extent
allocation), реализовано многопоточное чтение-запись (по потоку на каждый экстент), используется агрессивная стратегия группировки
(clustering) запросов на запись и т.д., - что в сумме очень актуально в современных условиях повсеместного распространения скоростных дисковых устройств.
. Нужно отметить ярко выраженное следствие применения механизма отложенного размещения, о котором мы упомянули выше: его эффективность прямо пропорциональна имеющейся величине оперативной памяти (RAM), что опять-таки очень выгодно при современных тенденциях развития серверного оборудования.
. Реализация журнала транзакций является самым противоречивым в устройстве XFS, так как дизайн таков, что через него проходят все изменения метаданных файловой системы.
. Слабое место XFS – скорость обработки каталогов, содержащих большое количество файлов: при таком сочетании условий сложность реализации алгоритма листинга каталогов приводит к некоторым провалам производительности этой ФС. В таком случае рекомендуется использование специальной утилиты xfs_fsr для оптимизации работы файловой систем и устранения узких мест в скорости отклика файловой системы.
И все-таки, несмотря на несколько скептическое отношение к XFS в этом обзоре, следует признать, что у этой ФС есть реальные шансы претендовать на большое будущее. Как сообщает ведущий разработчик из Red Hat Валери Орорэ (Valerie Aurora), эта крупная компания всерьез заинтересовалась XFS, пригласив к себе на работу ее трех самых активных разработчиков. Уже в 2010 году RedHat сделала более 70% всех коммитов в драйвер XFS для ядра Linux, а в 2011-2012 годах намерена продолжить серьезное развитие XFS, для достижения паритета ее возможностей с ведущими ФС “новой школы”.
Интересно также, что, по словам Эрика Сандина (Eric Sandeen), еще одного из разработчиков XFS в RedHat, XFS, которая традиционно считается очень сложной реализацией ФС, в процессе ее развития постепенно упрощается – что хорошо заметно даже через постепенную регрессию строк в ее Linux- драйвере, тогда как те же btrfs и ext4 демонстрируют взрывной рост сложности по мере своего развития. Этот же разработчик отмечает, что если дополнительно учесть очень тщательное комментирование XFS (примерно 40% всех строк в исходниках драйвера – это комментарии к коду), то раздувание и усложнение кодовой базы btrfs будет даже еще большим (против 17% комментариев соответственно).
Ссылки по теме XFS:
http://oss.sgi.com/projects/xfs/
http://xfs.org/index.php/XFS_FAQ
http://oss.sgi.com/projects/xfs/design_docs/
http://filesystems.nm.ru/my/xfs_arch.pdf
http://xfs.org/index.php/XFS_Status_Updates
Практические выводы
Ну что ж, ознакомившись с наиболее перспективными файловыми системами ближайшего будущего по версии экспертов Google, попробуем определиться и сделать свой выбор, чтобы как следует подготовиться, как выразился вышеупомянутый разработчик из Google, к приходу “Эпохи Больших Данных”. Для удобства я свел все общие данные о рассмотренных нами ФС в таблицу.
И нашу практическую часть обзора предлагаю начать с XFS. Эта файловая система очень хорошо масштабируется, она уже сейчас способна оперировать огромными объемами данных. Большая скорость ввода-вывода – конек этой файловой системы. Дополнительным условием эффективности XFS является наличие качественного питания (внезапные отключения достаточно неприятны для нее) и больших объемов оперативной памяти на сервере, что позволяет раскрыть весь потенциал механизма отложенного размещения и прочих “ленивых” техник, обильно реализованных в XFS. Сильная многопользовательская нагрузка на хранилище позволяет продемонстрировать XFS свой инновационный механизм параллельной записи и низкую ресурсоемкость.
При этом важно понимать, что идеала не существует, и узким местом именно этой ФС являются операции над большим количеством мелких файлов или удаление развесистых деревьев каталогов - в этом случае вы вряд ли увидите ту производительность, на которую рассчитывали. Если не считать большой проблемой невозможность уменьшить размер уже созданной ФС – вот, пожалуй, и все узкие места этой надежной и уже проверенной временем файловой системы. Что касается конкретных реализаций, то XFS прекрасно чувствует себя как на Linux, так и на FreeBSD, поэтому выбрать платформу для хранилища здесь есть из чего.
Что же касается ZFS, то первое что приходит на ум, это параноидальное недоверие этой ФС к железу, когда контроль за целостностью данных носит многоуровневый и чрезвычайно изощренный характер. Здесь невольно вспоминается, что на заре SATA, когда первые диски с этим интерфейсом выпускались с большим количеством брака, порождая проклятия особенно со стороны обладателей ext2, разработчиков ZFS на многих конференциях можно было увидеть в майках с мессианской надписью “ZFS любит SATA”, они как бы подчеркивали, что эта ФС способна позаботиться о вверенных ей данных, даже если само “железо” не всегда способствует этому. Поэтому, если у вас в серверной обилие дешевого железа, или ваши серверы хранят просто бесценные данные (или, для наибольшей изощренности, и то и другое вместе) – ZFS будет очень удачным выбором.
С другой стороны – степень масштабируемости системы под ZFS просто безгранична. Если учесть скорость ее работы, как правило выше среднего, и огромный выбор и гибкость настроек (добавьте сюда родной менеджер томов и программный RAID-контроллер) – это, пожалуй, идеальный выбор для создания больших хранилищ данных. И если последнее утверждение можно смело отнести к Solaris/FreeBSD, то в отношении Linux нужно сделать отдельную важную оговорку.
ZFS не была включена в ядро Linux из-за патентных ограничений, и чтобы обойти это, был собран FUSE-модуль для поддержки этой ФС в Linux на пользовательском уровне. Конечно, потери скорости и стабильности работы в таком варианте ФС огромны. Но, к счастью, существует как минимум два сторонних решения, где поддержка ZFS реализована все-таки на уровне ядра в качестве самостоятельного модуля. Это, прежде всего, Native ZFS во главе с Брайаном Белендорфом (проект финансируется Министерством энергетики США). Во-вторых, альтернативный, но такой же открытый и бесплатный вариант от индийской компании KQ Infotech. Лично я рекомендую остановиться на последнем варианте, так как это более качественная и полная реализация ZFS для Linux (дополнительно обеспечена поддержка ZFS POSIX Layer). Но, в обоих случаях, несмотря на все озвученные плюсы, ZFS все- таки не самый сильный выбор для Linux, так как вы останетесь с этим выбором наедине, лишенные поддержки со стороны официальных разработчиков ядра, тем более если учесть скорое пришествие Btrfs…
Кстати, о Btrfs. Имеет смысл рассматривать эту ФС пока применительно только к ОС Linux (то же самое можно сказать и о Hammer к DragonFlyBSD), и можно определенно сказать, что через годик-другой это будет наиболее универсальный и взвешенный выбор для этой ОС из всех возможных. А пока… эта файловая система отлаживается, расширяется, растет и активно проходит фазу становления, необходимую для ее окончательного взросления. По словам ее ведущего разработчика, переход на эту ФС в качестве основной для Linux запланирован на 2013 год.
Заключение
Возвращусь к примеру, с которого мы начали эту статью, где докладчик Майкл Рубин в качестве примера выбора ФС сообщил, что Google на данный момент использует на своих Linux-серверах ФС ext4 с полностью отключенным журналированием, полагаясь на аппаратные решения для сохранения целостности своих данных. Как оказалось, в стандартной конфигурации ext4 операции журналирования понижали производительность системы на 23-35% в зависимости от типа журнала, что оказалось в итоге неприемлемым для поискового гиганта. “Поэтому выбор системы, ее режим работы и даже оборудование для ее реализации – задача сугубо индивидуальная. При этом важно всегда смотреть вперед и не забывать про перспективу: ext4 позволяет провести прозрачную миграцию на Btrfs, поэтому мы остановились именно на ней”, – объясняет стратегический выбор своей компании Майкл Рубин.
Игорь Савчук
Компьютерная газета. Статья была опубликована в номере 09 за 2012 год в рубрике soft
