Пользователь
0,1
рейтинг
4 октября 2012 в 11:41

Администрирование → ZFS on Linux — не все так просто из песочницы

Прочитав статью «ZFS on Linux — легко и просто», решил поделиться своим скромным опытом использования этой ФС на паре Linux-серверов.

Вначале — лирическое отступление. ZFS — это круто. Это настолько круто, что перекрывает все недостатки ФС, портированной с идеологически другой платформы. Ядро Solaris работает с иными примитивами, нежели Linux, поэтому, чтобы сделать возможным перенос ZFS с использованием кода Solaris, разработчики создали слой совместимости SPL — Solaris Porting Layer. Прослойка эта работает вроде бы нормально, но она — дополнительный код в режиме ядра, который вполне может быть источником сбоев.

ZFS не до конца совместима с Linux VFS. Например, нельзя управлять списками контроля доступа через POSIX API и команды getfacl/setfacl, что очень не нравится Samba, которая хранит в ACL разрешения NTFS. Поэтому выставить нормальные права на Samba-папки и файлы не получится. Samba, теоретически, поддерживает ZFS ACL, но этот модуль под Linux еще собрать надо… А вот расширенные атрибуты ФС в ZFS on Linux присутствуют и работают отлично.

Кроме того, Solaris в 32-х битной редакции использует иной механизм распределения памяти, нежели Linux. Поэтому, если вы решились попробовать ZFS on Linux на архитектуре x86, а не x86_64 — готовьтесь к глюкам. Вас ждет стопроцентная загрузка процессора на элементарных операция и километры ошибок в dmesg. Как пишут разработчики ZFS on Linux: «You are strongly encouraged to use a 64-bit kernel. At the moment zfs will build in a 32-bit environment but will not run stably».

ZFS — это своеобразная «вещь в себе», и она хранит в метаданных такие параметры, которые нетипичны для Linux. Например — имя точки монтирования ФС задается в ее настройках, а сама ФС монтируется командой zfs mount, что автоматически делает ее несовместимой с /etc/fstab и прочими способами монтирования ФС в Linux. Можно, конечно, выставить mountpoint=legacy и все-таки воспользоваться mount, но это, согласитесь, неизящно. В Ubuntu проблема решается пакетом mountall, который содержит специфичные для ZFS скрипты монтирования и пропатченную команду mount.

Следующая проблема — мгновенные снимки системы, так называемые снэпшоты. Вообще, ZFS содержит очень эффективную реализацию снэпшотов, которая позволяет создавать «машину времени» — комплект снимков, скажем, за месяц, с разрешением 1 снимок в 15 минут. Мейнтейнеры Ubuntu конечно, включили эту возможность в пакет zfs-auto-snapshot, который и создает комплект снимков, правда, более разряженный по времени. Проблема в том, что каждый снимок отображается в каталоге /dev в виде блочного устройства. Цикличность создания снэпшотов такова, что за месяц мы получим 4+24+4+31+1=64 блочных устройста на каждый том пула. Тоесть, если у нас, скажем, 20 томов (вполне нормальное значение, если мы используем сервер для виртуализации), мы получим 64*20=1280 устройств за месяц. Когда же мы захотим перезагрузиться, нас будет ждать большой сюрприз — загрузка очень сильно затянется. Причина — при загрузке выполняется утилита blkid, опрашивающая все блочные устройства на предмет наличия файловых систем. То ли механизм определения ФС в ней реализован криво, то ли блочные устройства открываются медленно, но так или иначе процесс blkid убивается ядром через 120 секунд по таймауту. Надо ли говорить, что blkid и все основанные на ней скрипты не работают и после завершения загрузки?

Горячие новости
Только что попробовал поставить пакет zfs-auto-stapshot и протестировать его более полно. Результат — ротация не работает, старые версии снэпшотов не удаляются (error 134). Так что за месяц мы получим 4*24+24*31+4+31+1=876 снэпшотов для одного тома или 18 396 для 20 томов. Скрипт, отвечающий за снэпшоты, наверное, можно как нибудь поправить…
Версия пакета — 1.0.8-0ubuntu1~oneric1, ОС — Debian Sid x86_64

Допустим, мы победили все эти проблемы, и хотим отдать свежесозданный раздел другим машинам по iSCSI, FC или как-нибудь еще через систему LIO-Target, встроенную в ядро. Не тут то было! Модуль zfs при загрузке использует основной номер 230 для создания блочных устройств в каталоге /dev. LIO-Target (точнее, утилита targetcli) без последних патчей не считает устройство с таким номером готовым для экспортирования. Решение — исправить одну строчку в файле /usr/lib/python2.7/dist-packages/rtslib/utils.py, или добавить параметр загрузки модуля zfs в файл /etc/modprobe.d/zfs.conf:

options zfs zvol_major=240

И в завершение: как известно, включить модуль zfs в ядро мешает несовместимость CDDL, под которой выпущена ZFS, и GPL v2 в ядре. Поэтому каждый раз при обновлении ядра модуль пересобирается через DKMS. Иногда у модуля это получается, иногда (когда ядро уж слишком новое) — нет. Следовательно, самые свежие фишки (и багфиксы KVM и LIO-Target) из последних ядер вы будете получать с некоторой задержкой.

Каков же вывод? Использовать ZFS в продакшене надо с осторожностью. Возможно, те конфигурации, которые без проблем работали на других ФС, работать не будут, а те команды, которые вы без опаски выполняли на LVM, будут вызывать взаимоблокировки.

Зато в продакшене под Linux вам теперь доступны все фишки ZFS vol. 28 — дедупликация, он-лайи компрессия, устойчивость к сбоям, гибкий менеджер томов (его, кстати, можно использовать отдельно) и т. д. В общем удачи и успехов вам!
@lovecraft
карма
55,0
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (56)

  • +3
    Спасибо, мне хватило глюков btrfs и xfs. Вернусь-ка я на свой старый добрый рейзер3…
    • +4
      Не в курсе какие там новости о reiser4?
      Начало было очень неплохое, но как-то все заглохло…
      • +7
        думаю, что вопрос будет подниматься после освобождения рейзера. И вопрос будет — сразу хоронить, или сперва вспомнить как это, программировать на не-квантовых компах
      • 0
        Недавно была новость, что вышел патч для ядра 3.5.3. Собственно на sourseforge и лежит: sourceforge.net/projects/reiser4/
      • +3
        Готовится следующее жертвоприношение.
    • +2
      в моей практике всё наоборот.

      reiserfs использовал с ядра 2.4.17 (да, ещё из тех времён), e3, e4 — как появилась.

      ext-фс ни разу не помирали. Хотя бы с рутом в read-only система стартует и даже по ssh подключиться можно.

      reiser3 помирала трижды (до невосстанавливаемого состояния), причём один раз был баг известный (пофикшен кажется в 2.4.18, cвязан с файлами больше 2 Гб), а два раза ФС падала сама по себе без видимых причин. А иногда, когда система не помирала насовсем, удалённо починить всё равно было нельзя — она не монтировалась, пока руками не сделаешь fsck --fix-fixable.

      На третий раз — в 2006 году — я решил, что это закономерность, и забыл про неё навсегда. С тех пор у меня в линуксах ФС вообще ни разу не умирали, потому, что это ext3 или ext4.

      Так что хе-хе, «вернуться в reiser3» — это наверное самый страшный из кошмаров.
      • +1
        рейзер сдыхал у меня два раза. один раз — мой косяк с рейдом, один раз — бедблок посреди журнала.
        вот последнее её убило совсем, данные слил без проблем на винде (!!). там читалка рейзера журнал не умеет, и его просто игнорит — слилось всё, потерь в важных данных не нашел никаких.

        ext4 заглючивал буквально недавно и очень неприятно — см.ниже.
        еще с ext4 ноут регулярно требовал ребута — fs падала в RO из-за внутренней неконсистентности.
        при ребуте fsck что-то чинило и всё работало дальше без проблем. надоело, на btrfs такого нет.
        но «засыпание» диска на btrfs надоедает
    • 0
      мне кажется рейзер никогда не был в mainstream и теперь вообще не в фаворе.
      гугл уже вроде всем объяснил, что ext4 без журнала на UPS это «нашевсио».
    • +2
      А что с XFS не так, если не секрет? Я пользуюсь давно только ей, никаких нареканий пока не было.
  • +4
    Не холивара ради… Я поддерживаю исследовательское начало linux комьюнити, новые фишки это прекрасно. Но вряд ли решусь использовать в продакшене что-то кроме ext4+lvm. Имхо btrfs, zfs пока для экспериментов и торрентохранилок.
    • 0
      спасибо, ext4 у меня в продакшене тоже уже сыпалось так, что я на btrfs перешел. оно стабильнее.
      • +2
        Чудеса. Как же ее нагнуть надо было чтобы она посыпалась? А btrfs разве еще не experimental?
        • 0
          Всего-то на раздел писались бакапы. В один «прекрасный» день, места — ноль.
          «du -hs .» говорит «тут файла на 25гиг». «df -h .» говорит «тут заняты все 50».
          смотрю ls -la — файлов свежих нет просто половины.
          размонтировал, fsck — найдена потеря, чего-то там фиксед. монтирую обратно — всё на месте, du/df сходятся.

          повторялось раза три. ядра 3.2.0 и 3.4.1.
          на btr худшее пока что ловил — это просадка IO до невозможного уровня.
          • 0
            Ага, и дикие тормоза при fsync().
    • 0
      Пользуем zfs в продакшне, правда на BSD :)
      Вполне стабильно.
      Есть noreturn проблемы, но они есть на всех фс (например поломка дисков в райд, при некотором стечении обстоятельств можно потерять пул).
  • +1
    Сразу извиняюсь за ламерский вопрос.

    Чем zfs лучше, чем btrfs? Или в каких случаях может понадобиться использовать именно zfs?
    • +2
      Тем что на solaris (и возможно на freebsd) она уже стабильна. Btrfs ещё не стабильна ни где.
    • 0
      дедупликации у Btrfs пока нету как минимум.
      • 0
        да там всё завтраками кормят про RAID 5,6.
        а вы про дедупликацию…
    • +1
      ZFS решает рейд на уровне ФС (до сих пор не могу понять зачем этот не-UNIX-way придуман)
      у ZFS снапшоты / роллбэки / бакап по-фичастей
      ZFS как бы stable (на соляре), btrfs experimental всюду
      • 0
        рейд не делается на уровне ФС, поэтому ZFS и «нарушает» слои.
        LVM + ФС = ZFS образно говоря
        • 0
          о чем я и говорю. единственный плюс от такого нарушения — у рейда есть точные данные о фактической занятости блоков. но хорошо ли это? и можно ли передать эти данные более другим способом?
      • 0
        не холивара ради… почему «не-UNIX-way»? что в этом плохого?
        • 0
          unix-way это четкое разделение ответственности. 1 задача решается одной утилитой и решается хорошо.
          сложная задача решается суперпозицией маленьких, отлаженных утилит.
          ZFS сливает в себя функции LVM, mdadm, дедупликатора, вроде как еще и drbd, еще и ФС…
          • 0
            в отличие от drbd оно работает через iscsi как с обычным scsi-устройством, не задумываясь, что через сеть, так что его «не сливает». drbd было бы если бы они свой сетевой протокол придумали, а не использовали iscsi
      • 0
        ZFS готова к продакшену на FreeBSD с сентября 2009 года: svnweb.freebsd.org/base?view=revision&revision=197221
    • 0
      у ZFS есть множество вкусняшек.
      мне нравится тот факт, что ZFS исходит из факта, что устройство может ошибаться, и дополнительно контролирует блоки данных с помощью 256-битных контрольных сумм.

      для полной уверенности есть scrubbing
      xgu.ru/wiki/ZFS
      • 0
        то есть производительность этой FS-переростка ниже плинтуса?
        • +1
          У нее крутая производительность.

          Работаю с ZFS где-то с 2006 года, отличная штука.

          Если хотите серьезный файл сервер с солидной нагрузкой — забудьте о Linux и тем более о Windows. Кстати не пробовал ZFS на FreeBSD. Говорят что она там хорошо уже работает.

          Мои любимая конфигурация раскидать pool на несколько серверов зеркалом через iSCSI и получить по сути онлайн backup который содержит все данные до самого падения. А не какой-то ночной вариант.
          • 0
            На БСД с онлайн бекапом пока плохо (iscsi не умеет immediate mode пока что).
            Но можно добиться этого с помощью HAST, правда бекап будет на уровне пулов а не самой бсд.
            • 0
              в конце не бсд, а фс.
          • +1
            А кто вам сказал про файл сервер? Нужен доступ к файлам из операционной системы. У автора, к примеру, сервер виртуалок, а не «файловый сервер».

            а вообще под линухом LVM+ваша любимая fs решает все задачи ZFS.
            • 0
              Виртуалки как раз кошернее на ZFS:
              1) Каждая виртуалка созданная по образу это снэпшот фс эталона.
              2) Zfs легко позволяет «хостить» блочные разделы внутри себя.
              3) Загрузка образа эталона это zfs export | zfs import.

              Посмотрите на то как SmartOS использует ZFS.
              • 0
                1) в lvm тоже есть снапшоты, и их поддерживают многие fs, вообще для вашего случая именно снапшоты необязательные. Достаточно copy on write в файловой системе.

                2) любой файл в линухе через loop превращается в блочный раздел

                3) исходя из вышеописанного rm,cp :)

                вобщем вы придумали способ использовать zfs, но это не значит что это нельзя сделать другими средствами.
                • 0
                  > 1) в lvm тоже есть снапшоты, и их поддерживают многие fs, вообще для вашего случая именно снапшоты необязательные. Достаточно copy on write в файловой системе.

                  Видел я снапшоты в LVM — не надо такого.

                  > 2) любой файл в линухе через loop превращается в блочный раздел

                  этот а тут это делается из коробки, да еще и iscsi можно экспортировать прямо из zfs. И настроить zfs можно конкретно под этот раздел. Удобнее чем в мерзком линуксе с мерзким lvm.

                  > вобщем вы придумали способ использовать zfs, но это не значит что это нельзя сделать другими средствами.

                  Не важно «что» важно «как»
                  • 0
                    2) это тоже «из коробки» вообщето, причем из гораздо более доступной коробки, которая ставится сразу в любом дистре :)

                    учитывая столько лишних лэеров в zfs, то это самое «как» с zfs получается мягко скажем «не прямым путём»…
                    • 0
                      Это в ZFS много слоев? в 97% ситуациях все будет делать утилита zfs. Это в LVM + fs надо будет использовать пять разных утилит.
                      • 0
                        Вот что значит пользователь а не разработчик… конечно в zfs внутри много слоёв, чего стоит только описанный в статье scl
            • 0
              Увы, LVM довольно тормозная система, в которой вовсе не предусмотрена дедупликация или сжатие.

              Да, я использую LVM, много где помогает. Там где мне нужны снапшоты и стабильность, там LVM + ext4.
              Но при активном снапшоте производительсноть системыможет падать до минимально допустимого (ночью) уровня.
              • +1
                Это довольно громкое заявление «тормозная система». Кроме того я не зря написал "+ ваша любимая фс". LVM делает ровно ту работу, которая на нее возложена. Дедупликация на её уровне несколько бессмысленная не находите?

                Я бы не использовать ext4 там где «нужна стабильность», так как в одном из худших сценариев, её восстановление займёт время квадратично её размеру…
            • 0
              > а вообще под линухом LVM+ваша любимая fs решает все задачи ZFS.

              Допустим, есть софтверный RAID-5 (+ любимая ФС), с которого производится чтение данных. Как определить, что один из дисков в программном RAID-5 начинает сыпаться?

              ZFS делает это очень легко и непринуждённо on-line, причём без потери данных и без вывода мусора — в случае с вашим программным RAID-5 будет отдаваться мусор, пока не сделают проверку и ребилд массива. Cыплющийся носитель в пуле ZFS будет оставаться в строю, пока до конца не «замолчит».
              • 0
                cat /proc/mdstat :)
                • 0
                  Сыплющийся, но не отвалившийся от RAID-5 винчестер покажет?
                  • 0
                    У меня показывал, метил как «unchecked» и начинал авто перепроверку.
                    • 0
                      То есть команда «cat /proc/mdstat» проводит экспересс-диагностику массива и запускает, если обнаружен сыплющийся носитель, проверку всего массива, я правильно понял логику работы?
                      • 0
                        нет, комманда cat /proc/mdstat показывает содержимое прок-файла /proc/mdstat в котором в текстовом виде отображено текущее состояние массивов.
                        • 0
                          «zpool status» тоже показывает состояние пулов в текущий момент времени. LUN пула может быть в трёх состояниях: выключен из массива, резильверинг (обновление на нём информации) и в работе.
                          • 0
                            Хмм… вы спросили «как определить» я написал. Перепроверка рейда же делается автоматически если один из дисков выдал ошибку на записть.
    • 0
      Ну, я поставил ZFS ради одной вещи — L2ARC. Эта штука позволяет подключать SSD-диск в качестве кэша к дисковому тому. Правда кэширование — только на чтение. Под Linux тоже есть что-то в этом духе, но не мейнлайн-ядре и с непонятной поддержкой.

      Дедупликация — это, конечно, модно, но экономит только место, а не IOPS. Дедупликация хороша для виртуальных сред, но все равно проигрывает thin provisioning средствами гипервизора или блочного устройства (например, Device Mapper-а в Linux).

      Компрессия тоже экономит место, и немного — IOPS, но размер экономии сильно зависит от самих данных.

      Так что какая ФС лучше, надо смотреть «по месту».
      • 0
        Там есть а-ля кэш на запись. Точнее log device.

        ZIL называется. Ускоряет запись на медленные устройства.
      • 0
        да, L2ARC на SSD тоже используем на высоконагруженных серверах под видеостриминг, очень эффективно работает.
      • 0
        Компрессия экономит IOPSы на маленьких файликах очень сильно. Compilebench показывает на btrfs+компрессия вдвое большую производительность практически всех тестов по ср. с btrfs без компрессии.
  • 0
    Полностью поддерживаю автора, он рассказал о том, чего в действительности важно почти всегда, но было не важно в моём случае.

    У меня опыт работы с ZFS — это исключительно задача, допускающая потерю данных и баги. Если будет совсем бажить, то можно от ZFS отказаться и использовать ext4.

    Конечно, вся надежда на BTRFS, но когда её приведут в удобоваримый вид совсем не ясно.
  • 0
    Использовал ее для той же задачи — файл сервер с некритичными данными. Сама ФС, как я понимаю, сверхстабильна, и в случае чего, можно снять диски, закинуть их на сервер с OpenIndiana и починиться. Но вот реализация конкретно для Linux не то чтобы рановата для продакшена, но должна использоваться с оговорками. Вот об оговорках я и написал ).

    Надеюсь, через год можно будет внедрять в ответственных проектах. А вот когда допилять btrfs — вопрос. ZFS, по крайне мере, стабильно работает на Solaris, а btrfs стабильно пока нигде не работает.
    • 0
      Как я понял историю с btrfs то забойщиком по ее созданию был Oracle.

      Я думаю после покупки Sun btrfs для Oracle стал неактуален. Они не позиционируют Linux как операционку для тяжелых задач и зачем им собственно делать btfrs когда они продают Solaris.

      Я думаю когда они говорят что они полностью продолжат работать над Linux, то они слегка лукавят. Им необходимо будет как то их дифференцировать.
  • 0
    Только что сейчас глянул,

    говорят что портируют DTrace и Containers на Linux.

    Ни слова о ZFS. Это естественно, им я думаю уже и Nexenta как гвоздь в заднице.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.