Прочитав статью «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 и все основанные на ней скрипты не работают и после завершения загрузки?
Допустим, мы победили все эти проблемы, и хотим отдать свежесозданный раздел другим машинам по 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:
И в завершение: как известно, включить модуль zfs в ядро мешает несовместимость CDDL, под которой выпущена ZFS, и GPL v2 в ядре. Поэтому каждый раз при обновлении ядра модуль пересобирается через DKMS. Иногда у модуля это получается, иногда (когда ядро уж слишком новое) — нет. Следовательно, самые свежие фишки (и багфиксы KVM и LIO-Target) из последних ядер вы будете получать с некоторой задержкой.
Каков же вывод? Использовать ZFS в продакшене надо с осторожностью. Возможно, те конфигурации, которые без проблем работали на других ФС, работать не будут, а те команды, которые вы без опаски выполняли на LVM, будут вызывать взаимоблокировки.
Зато в продакшене под Linux вам теперь доступны все фишки ZFS vol. 28 — дедупликация, он-лайи компрессия, устойчивость к сбоям, гибкий менеджер томов (его, кстати, можно использовать отдельно) и т. д. В общем удачи и успехов вам!
Вначале — лирическое отступление. 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
Версия пакета — 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 — дедупликация, он-лайи компрессия, устойчивость к сбоям, гибкий менеджер томов (его, кстати, можно использовать отдельно) и т. д. В общем удачи и успехов вам!
