Выбор распределенной файловой системы для Linux. Пару слов о Ceph и остальных
Существует несколько десятков файловых систем, все из них предоставляют пользовательские интерфейсы для хранения данных. Каждая из систем хороша по-своему. Однако, в наш век высоких нагрузок и петабайтов данных для обработки, оказалось довольно непросто подыскать то, что нужно, стоит лишь задуматься о распределенных данных, распределенных нагрузках, множественном монтировании rw и о прочих кластерных прелестях.
Задача: организовать распределенное файловое хранилище
— без самосборных ядер, модулей, патчей,
— с возможностью множественного монтирования в режиме rw,
— POSIX совместимость,
— отказоустойчивость,
— совместимость с уже использующимися технологиями,
— разумный overhead по I/O операциям по сравнению с локальными файловыми системами,
— простота конфигурации, обслуживания и администрирования.
В работе мы используем Proxmox и контейнерную виртуализацию OpenVZ. Это удобно, это летает, у этого решения больше плюсов, чем у аналогичных продуктов. По крайней мере для наших проектов и в наших реалиях.
Сам storage везде монтируется по FC.
OCFS2
У нас был успешный опыт использования данной файловой системы, решили сначала попробовать ее. Proxmox с недавнего времени перешел на редхатовское ядро, в нем поддержка ocfs2 выключена. Модуль в ядре есть, но на форумах openvz и proxmox не рекомендуют его задействовать. Мы попробовали и пересобрали ядро. Модуль версии 1.5.0, кластер из 4 железных машин на базе debian squeeze, proxmox 2.0beta3, ядро 2.6.32-6-pve. Для тестов использовался stress. Проблемы за несколько лет остались те же самые. Все завелось, настройка данной связки занимает полчаса от силы. Однако, под нагрузкой кластер может самопроизвольно развалиться, что ведет к тотальному kernel panic на всех серверах сразу. За сутки тестов машины перезагружались в общей сложности пять раз. Это лечится, но доводить такую систему до работоспособного состояния довольно тяжело. Пришлось также пересобирать ядро и включать ocfs2. Минус.
Хоть ядро и редхатовское, модуль по умолчанию включен, завестись мы и здесь так и не смогли. Все дело в proxmox, которые со второй версии придумали свой кластер с шахматами и поэтессами для хранения своих конфигов. Там cman, corosync и прочие пакеты из gfs2-tools, только все пересобранные специально для pve. Оснастка для gfs2, таким образом, из пакетов просто так не ставится, так как предлагает сначала снести весь proxmox, что мы сделать не могли. За три часа зависимости удалось победить, но все опять закончилось kernel panic. Попытка приспособить пакеты для proxmox для решения наших проблем успехом не увенчалась, после двух часов было принято решение отказаться от этой идеи.
Остановились пока на ней.
POSIX совместимая, высокая скорость работы, отличная масштабируемость, несколько смелых и интересных подходов в реализации.
Файловая система состоит из следующих компонентов: 
1. Клиенты. Пользователи данных.
2. Сервера метаданных. Кэшируют и синхронизируют распределенные метаданные. С помощью метаданных клиент в любой промежуток времени знает, где находятся нужные ему данные. Также сервера метаданных выполняют распределение новых данных.
3. Кластер хранения объектов. Здесь в виде объектов хранятся как данные, так и метаданные.
4. Кластерные мониторы. Осуществляют мониторинг здоровья всей системы в целом.
Фактический файловый ввод/вывод происходит между клиентом и кластером хранения объектов. Таким образом, управление высокоуровневыми функциями POSIX (открытие, закрытие и переименование) осуществляется с помощью серверов метаданных, а управление обычными функциями POSIX (чтение и запись) осуществляется непосредственно через кластер хранения объектов.
Любых компонентов может быть несколько, в зависимости от стоящих перед администратором задач.
Файловая система может быть подключена как напрямую, с помощью модуля ядра, так через FUSE. С точки зрения пользователя, файловая система Ceph является прозрачной. Они просто имеют доступ к огромной системе хранения данных и не осведомлены об используемых для этого серверах метаданных, мониторах и отдельных устройствах, составляющих массивный пул системы хранения данных. Пользователи просто видят точку монтирования, в которой могут быть выполнены стандартные операции файлового ввода / вывода. С точки зрения администратора имеется возможность прозрачно расширить кластер, добавив сколько угодно необходимых компонентов, мониторов, хранилищ, серверов метаданных.
Разработчики гордо называют Ceph экосистемой.
GPFS, Lustre и прочие файловые системы, а также надстройки, мы не рассматривали в этот раз, они либо очень сложны в настройке, либо не развиваются, либо не подходят по заданию.
Конфигурация и тестирование
Конфигурация стандартная, все взято из Ceph wiki. В целом файловая система оставила приятные впечатления. Собран массив 2Тб, пополам из SAS и SATA дисков (экспорт блочных устройств по FC), партиции в ext3.
Ceph storage примонтирован внутрь 12-и виртуальных машин на 4 hardware nodes, осуществляется чтение-запись со всех точек монтирования. Четвертые сутки стресс-тестов проходят нормально, I/O выдается в среднем 75 мб/с. на запись по пику.
Мы пока не рассматривали остальные функции Ceph (а их осталось еще довольно много), также есть проблемы с FUSE. Но хотя разработчики предупреждают, что система экспериментальная, что ее не стоит использовать в production, мы считаем, что если очень хочется, то можно -_-
Прошу всех заинтересованных, а также всех сочувствующих, в личку. Тема очень интересная, ищем единомышленников, чтобы обсудить возникшие проблемы и найти способы их решения.
Источник
Выбираем файловую систему независимую от ОС
Всем привет. Недавно я задался вопросом как организовать обмен файлами между операционными системами. Предположим, я хочу установить сразу три основные ос на своём ноутбуке: линукс, виндовз и хакинтош. Каждая ос предназначается для своих задач: Линукс — для работы и программирования, винда — для игр и хак — просто для разных экспериментов.
Поскольку я создаю обучающие видео ролики о линуксе, мне удобнее работать именно на нём. Но монтировать хочется попробовать в «финальном вырезе». Уж очень мне приглянулась идея магнитной ленты времени.
Так вот, задача стоит такая: нужен раздел на системном накопителе, причём с такой файловой системой, которая поддерживается на чтение и запись всеми перечисленными операционками. На этом разделе будут храниться скачанные из интернета файлы и меж-операционные проекты.
Как такая задача решалась мной раньше? Раньше я использовал только винду с линуксом, поэтому задачи обмена с apple os не возникало. Конечно, хотелось использовать открытую и родную фс для линукса — ext4. Но на винде её смонтировать непросто. Нужно устанавливать бесплатный (но проприетарный) Paragon ExtFS for Windows. И ладно, если бы это работало, но к сожалению данное ПО повреждает вам раздел с линуксом. Напоролся пару раз, и всякое желание пользоваться этим по пропало.
А вот виндовая фс под линуксом читается и пишется без проблем. Нужно всего лишь установить ntfs-3g драйвер. Он работает в юзерспейсе. Файловая система проприетарная, но решение работает.
Теперь же я хочу использовать ещё и хакинтош, и хочется разобраться какие ещё есть варианты для решения этой задачи, кроме ntfs.
На самом деле вариантов немного. Давайте разберёмся, какие есть файловые системы, и какие из них являются более или менее универсальными.
Fat32 — всем известная древняя фс, является самой универсальной в плане переносимости, но и самой убогой в плане ограничений. Была разработана давно, не поддерживает файлы размером более 4 Гб. Проприетарная. Для моих задач не подходит.
Ntfs — родная фс для винды, проприетарщина. Линукс, как я уже писал выше, её поддерживает с помощью стороннего драйвера (ntfs-3g). Мак нативно её не понимает, хотя можно доустановить соответствующее по. Есть несколько вариантов, как платных, так и бесплатных. Ни один из них мне не нравится. ntfs-3g работает в userspace (с медленной скоростью), а платные решения — платные.
Hfs+ — одна из худших фс, когда либо созданных. Родная для мак ос, но нисколько не универсальная. Можно примонтировать на линуксе, а для винды опять же есть платные решения — в пролёте.
Ext4 — одна из правильных фс, родная для линукс. Но в плане монтирования в неродных ос — опять проблемы. За платные решения для хакинтоша и для винды опять просят денег. Есть и бесплатные решения, к примеру ext2fsd, но этот драйвер не умеет писать в ext4. В пролёте.
Udf — одна из правильных фс, поддерживается нативно всеми ос. Эта фс была бы лучшим вариантом, если бы не компания apple. Изначально udf создавалась для оптических носителей, но она может быть спокойно использована на обычном жёстком магнитном диске. НО! Из-за того, что яблочники не реализовали поддержку этой фс с раздела, вся задумка отменяется. Даже последняя мак ос Х поддерживает данную фс только если всё блочное устройство не имеет таблицы разделов. На гитхабе есть скрипт format-udf, который может подготовить носитель специальным образом: в начальном блоке данных прописывается mbr, говорящий что раздел начинается прямо там же где и сам mbr. Т.е. накопитель как бы одновременно и с таблицей разделов (то что понимает винда), и вроде как и без таблицы разделов. Этот способ предполагает что носитель будет внешний, а мне нужно сделать exchange раздел именно на внутреннем накопителе. Так что данный вариант тоже в пролёте.
exFat — проприетарщина, но нативно работает как в винде, так и в маке. Это очень хорошо. А что в линуксе?
Спрашивается, а почему тогда данный драйвер не поддерживается из коробки? Потому что его нет в ядре. Мердж этого кода (пусть и gpl-ного) в mainline — это по сути троян от мелких (из-за патентов). Торвальдс это понимает, и, понятное дело, ядро не отравит.
В линуксе монтировать exfat можно либо с помощью exfat-fuse драйвера, либо с помощью exfat-nofuse. Конечно, лучше nofuse, так как он будет работать быстрее. Но его придётся собирать каждый раз при обновлении ядра. Благо, для автоматизации этой задачи есть механизм dkms.
Я останавливаюсь на exfat. Да, проприетарщина, но ничего не поделаешь. Зато всё нативно работает, и “танцы с бубном” отсутствуют: во всех трех операционных системах есть нативная поддержка и возможность поставить эту фс именно на раздел. Ограничения в 4 Гб нет. И в целом, это решение достаточно простое.
Надеюсь, вы узнали что-то новое для себя и выберите подходящий вариант исходя из ваших нужд.
Апдейт 4 февраля 2020:
Оказывается раздел с exfat невозможно ни растянуть, ни сжать. Причём даже на самой винде. Не учёл этот момент при выборе решения. Если нужно изменить размер раздела — придётся только бекапить данные в другое место и пересоздавать раздел уже с нужным размером.
С UDF в этом плане дела не лучше. Вот здесь лежит табличка, описывающая возможности по работе с разделами в gparted.
Источник
Какую файловую систему выбрать для Linux
Если вы только переходите с Windows, то, наверное, уже привыкли, что вам доступна только одна файловая система — NTFS и выбирать просто нет из чего. Но в Linux ситуация совсем другая. Здесь существует огромное множество файловых систем и постоянно создаются новые.
В сегодняшней небольшой статье мы постараемся разобраться какую файловую систему выбрать для Linux, и какие вообще доступны варианты.
Выбор файловой системы для Linux
Все файловые системы можно разделить на два типа: это обычные файловые системы и файловые системы следующего поколения. К обычным файловым системам относится используемая в большинстве дистрибутивов Ext4, она имеет все необходимые для полноценной работы возможности, но не более того.
Файловые системы следующего поколения — это BtrFS, ZFS и другие им подобные. Кроме стандартных возможностей они добавляют такие интересные вещи как дедупликация данных, управление томами, размещение файловой системы на нескольких физических дисках, контрольные суммы для данных, прозрачное сжатие и шифрование, снимки состояния, а также многое другое. Несмотря на все эти преимущества, новые файловые системы ещё не всегда стабильны и не поддерживаются не во всех дистрибутивах, а многие из их возможностей просто не нужны обычным пользователям.
Если кратко отвечать на вопрос, какую файловую систему выбрать для Linux — то ответ — Ext4. Она разработана очень давно, но зато очень стабильна и проверена временем. Она используется по умолчанию во многих дистрибутивов, а её лимитов хватит с головой, как для домашних пользователей, так и для большинства серверов. Но эта файловая система относится к обычным. Если вы не хотите её использовать дальше мы рассмотрим несколько альтернатив, доступных для выбора в установщике Ubuntu.
1. Ext
Про семейство файловых систем Ext я больше не буду говорить в этой статье. Про всё можно подробно прочитать в статье Файловая система Ext4. Там рассказана история развития этой файловой системы, а также её плюсы и минусы. Для установки Linux лучше всего подойдёт файловая система Ext4 из-за её стабильности и огромному количеству руководств по настройке в интернете.
2. XFS
Файловая система XFS разработана в Silicon Graphics в 1994 году для операционной системы SGI IRX. Расшифровывается как eXtended File System. Для Linux она была портирована в 2001 и немного позже её начали использовать в Red Hat Enterprice Linux в качестве файловой системы по умолчанию. Хотя эту файловую можно отнести к обычным, она изначально была рассчитана на работу с большими дисками. Она очень похожа на Ext4, тоже поддерживает журналирование и не подвержена фрагментации, но её можно только увеличить, уменьшить раздел с этой файловой системой нельзя. Ещё XFS показывает хорошую производительность при работе с большими файлами, но медленее работает с большим количеством маленьких файлов по сравнению с другими файловыми системами.
3. JFS
Файловая система JFS или Journaled File System разработана компанией IBM для системы IBM AIX в 1990 году, а чуть позже она была портирована и для Linux. В отличие от Ext3, в которой был добавлен журнал для сохранения целостности файловой системы, JFS была изначально журналируемой. В журнале сохраняются только метаданные. Файловая система одинаково быстро работает с как с большими, так и с маленькими файлами, а ещё её также как и XFS нельзя уменьшить, только увеличить. Несмотря на то, что эта файловая система доступна в большинстве дистрибутивов, её редко используют, а значит и её разработка и выявление багов идет медленнее.
4. BtrFS
Мы добрались к первой файловой системе следующего поколения. Это B—Tree File System. Её разработал Крис Масон во время своей работы в компании Oracle в 2006 году. Она поддерживает множество интересных возможностей, таких как управление томами, снимки состояния, прозрачное сжатие и дефрагментацию в реальном времени. Файловая система разрабатывалась как качественная и новая альтернатива для файловых систем семейства Ext. Даже основной разработчик Ext4 Теодор Цо считает, что за Btrfs или подобной ей файловой системой будущее, а Ext4 рано или поздно останется в прошлом. Сейчас BtrFS используется по умолчанию в SUSE Linux, как в серверной, так и обычной редакции. Она уже считается стабильной, но многие всё ещё боятся её использовать.
5. ReiserFS
Файловую систему ReiserFS разработал Ганс Рейзер специально для Linux в 2001 году. В неё было включено множество возможностей недоступных для Ext4. Как и в Ext4 здесь есть журналирование либо только метаданных, либо вместе с данными. Поддерживается управление томами, есть возможность добавить кэширующий быстрый диск. ReiserFS — очень быстрая и умеет упаковывать несколько файлов в один блок, чтобы уменьшить использование памяти. Однако, разработка этой файловой системы была заброшена после того, как Ганс Райзер сел в тюрьму в 2008. Версия файловой системы Raiser4 всё ещё не попала в ядро, поэтому для использования на перспективу лучше выбрать Btrfs.
6. ZFS
ZFS была разработана для Solaris компанией Sun Microsystems и сейчас она принадлежит Oracle в 2005 году. Немного позже она была портирована для Linux и начиная с Ubuntu 16.04 доступна в установщике для использования в качестве корневой файловой системы. Она похожа на BtrFS, потому что поддерживает управление томами, контрольные суммы для всех данных, прозрачное сжатия и прозрачное шифрование. Её тоже можно отнести к файловым системам следующего поколения. По архитектуре, это 128 битная файловая система, в то же время как Ext4 — 64 битная. Поэтому лимиты у неё очень большие и в обозримом будущем мы к ним даже не приблизимся. Но Линус Торвальдс, создатель ядра Linux не советует использовать ZFS.
Выводы
Ещё в списке файловых систем установщика есть Swap и FAT, но обе эти файловые системы нельзя использовать для корневого раздела Linux. Первая используется для раздела подкачки и не предназначена для хранения файлов, а вторая — это старая файловая система от Microsoft, не поддерживающая многих необходимых атрибутов и возможностей.
Есть и другие файловые системы, например F2FS, разработанная специально для SSD, но они используются ещё реже. Для себя я вижу два варианта — это либо Btrfs, потому что она активно развивается, разработана для Linux и разработчики SUSE ей доверяют, а также Ext4, потому что очень стабильна и проверена временем. А какую файловую систему для Linux используете вы? Какие лучшие файловые системы Linux? Напишите в комментариях!
Источник
