Blogerator.org

× Версия для печати

Ну что ж, ознакомившись с меню, из наиболее перспективных файловых систем ближайшего будущего по версии экспертов Google, попробуем определиться и сделать свой выбор, чтобы как следует подготовиться, как выразился вышеупомянутый разработчик из Google, к приходу «Эпохи Больших Данных».

Для удобства, я свел все общие данные о рассмотренных нами ФС в таблицу (см. в конце этого поста).

И нашу практическую часть обзора предлагаю начать с XFS. Эта файловая система очень хорошо масштабируется, она уже сейчас способна оперировать огромными объемами данных. Большая скорость ввода-вывода — это конёк этой файловой системы.

Дополнительным условием эффективности XFS является наличие качественного питания (внезапные отключения достаточно неприятны для неё) и больших объемов оперативной памяти на сервере, что позволяет раскрыть весь потенциал механизма отложенного размещения и прочих «ленивых» техник обильно реализованных в XFS. Сильная многопользовательская нагрузка на хранилище — позволяет продемонстрировать XFS свой инновационный механизм параллельной записи и низкую ресурсоемкость.

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

Если не считать большой проблемой невозможность уменьшить размер уже созданной ФС — вот, пожалуй, и все узкие места этой надежной и уже проверенной временем файловой системы. Что касается конкретных реализаций, то XFS прекрасно чувствует себя как на Linux, так и на FreeBSD, поэтому выбрать платформу для хранилища здесь есть из чего.

Что же касается ZFS, то первое что приходит на ум, это параноидальное недоверие этой ФС к железу, когда контроль за целостностью данных носит многоуровневый и чрезвычайно изощренный характер. Здесь невольно вспоминается, что на заре SATA, когда первые диски с этим интерфейсом выпускались с большим количеством брака, порождая проклятия особенно со стороны обладателей ext2, разработчиков ZFS на многих конференциях можно было увидеть в майках с мессианской надписью «ZFS любит SATA», как бы подчеркивая этим, что эта ФС способна позаботиться о данных вверенных ей, даже если само «железо» не всегда способствует этому.

Поэтому, если у вас в серверной обилие дешевого железа, или ваши сервера хранят просто бесценные данные (или, для наибольшей изощренности, и то и другое вместе) — ZFS это очень удачный выбор. С другой стороны — степень масштабируемости системы под ZFS просто безгранична. Если добавить сюда скорость работы (для разгона этой ФС смотрите например известное руководство по её экстремальному разгону — ZFS Evil Tuning Guide), как правило, выше среднего, огромный выбор и гибкость настроек (добавьте сюда родной менеджер томов и программный RAID-контроллер) — это, пожалуй, идеальный выбор для создания больших хранилищ данных. И если последнее утверждение можно смело отнести к Solaris/FreeBSD, то в отношении Linux нужно сделать отдельную и важную оговорку.

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

Но, к счастью, существует как минимум три сторонних решения, где поддержка ZFS реализована всё-таки на уровне ядра в качестве самостоятельного модуля.

Но, в обоих случаях, несмотря на все озвученные плюсы, ZFS всё-таки не самый сильный выбор для Linux, т.к. вы останетесь с этим выбором наедине, лишенные поддержки со стороны официальных разработчиков ядра, тем более, если учесть скорое пришествие btrfs...

Кстати, о btrfs. Имеет смысл рассматривать эту ФС пока применительно только к ОС Linux (тоже самое можно сказать и о HAMMER к DragonFlyBSD), и можно определенно сказать, что через годик-другой — это будет наиболее универсальный и взвешенный выбор для этой ОС из всех возможных (хотя, стоит почитать интервью с Эдуардом Шишкиным из RedHat, который считает btrfs одним сплошным недоразумением).

А пока... эта файловая система отлаживается, расширяется, растет... активно проходит фазу становления необходимую для её окончательного взросления (например на текущей F16-RC2 при fsync тормозище системы с этой ФС просто неописуемые). Но по словам её ведущего разработчика — переход на эту ФС в качестве основной для Linux запланирован уже относительно скоро, на 2013 год.

~

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

Как оказалось, в стандартной конфигурации ext4 операции журналирования понижали производительность системы на 23%-35% в зависимости от типа журнала, что оказалось в итоге неприемлемым для поискового гиганта.

«Поэтому выбор системы, её режим работы и даже оборудования для её реализации — задача сугубо индивидуальная. При этом, важно всегда смотреть вперед и не забывать про перспективу: ext4 позволяет провести прозрачную миграцию на btrfs, поэтому, мы остановились именно на ней», — объясняет стратегический выбор своей компании Майкл Рубин.

Начало этой серии статей и их общее оглавление смотрите здесь.

Игорь Савчук // Системный Администратор, 2011