После прочтения статьи «ZFS в Linux – легко и просто» , решил поделиться своим скромным опытом использования этой ФС на парочке Linux-серверов.
Сначала лирическое отступление.
ZFS - это круто.
Это настолько круто, что перекрывает все недостатки ФС, портированной с идеологически другой платформы.
Ядро Solaris работает на других примитивах, чем Linux, поэтому, чтобы сделать возможным портирование ZFS с использованием кода Solaris, разработчики создали уровень портирования Solaris (SPL).
Этот слой вроде бы работает нормально, но это дополнительный код в режиме ядра, который вполне может быть источником сбоев.
ZFS не полностью совместима с Linux VFS. Например, вы не можете управлять списками контроля доступа через POSIX API и команды getfacl/setfacl, что очень не нравится Samba, хранящей разрешения NTFS в ACL. Поэтому установить нормальные разрешения для папок и файлов Samba будет невозможно.
Samba теоретически поддерживает ZFS ACL, но этот модуль еще нужно скомпилировать под Linux. А вот расширенные атрибуты FS в ZFS в Linux присутствуют и работают отлично.
Кроме того, Solaris в 32-разрядной версии использует другой механизм распределения памяти, чем Linux. Поэтому, если вы решите попробовать ZFS в Linux на архитектуре x86, а не x86_64, готовьтесь к глюкам.
Вы испытаете 100% загрузку ЦП при выполнении основных операций и множество ошибок в dmesg. Как пишут разработчики ZFS on Linux: «Настоятельно рекомендуется использовать 64-битное ядро.
На данный момент zfs будет работать в 32-битной среде, но не будет работать стабильно».
ZFS — это своего рода «вещь в себе», и она хранит в метаданных параметры, не характерные для Linux. Например, в ее настройках указывается имя точки монтирования ФС, а сама ФС монтируется командой zfs mount, что автоматически делает ее несовместимой с /etc/fstab и другими способами монтирования ФС в Linux. Вы, конечно, можете установить mountpoint=legacy и по-прежнему использовать mount, но это, согласитесь, неэлегантно.
В Ubuntu проблема решается с помощью пакета mountall, который содержит сценарии монтирования, специфичные для ZFS, и исправленную команду монтирования.
Следующая проблема — мгновенные снимки системы, так называемые снапшоты.
В целом 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 и протестировать его более полно.
Результат: ротация не работает, старые версии снимков не удаляются (ошибка 134).
То есть за месяц мы получим 4*24+24*31+4+31+1=876 снимков для одного тома или 18 396 для 20 томов.
Скрипт, отвечающий за снимки, наверное, можно как-то поправить.
Версия пакета — 1.0.8-0ubuntu1~oneric1, ОС — Debian Sid x86_64. Допустим, мы преодолели все эти проблемы и хотим передать вновь созданный раздел другим машинам через iSCSI, FC или каким-либо другим способом через систему.
ЛИО-Цель , встроенный в ядро.
Не так! Модуль 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 в ядре.options zfs zvol_major=240
Поэтому при каждом обновлении ядра модуль пересобирается через DKMS. Иногда модуль удается, иногда (когда ядро слишком новое) — нет. Следовательно, вы получите новейшие функции (а также исправления ошибок KVM и LIO-Target) из последних ядер с некоторой задержкой.
Каков вывод? Используйте ZFS в производстве с осторожностью.
Возможно, те конфигурации, которые без проблем работали на других ФС, работать не будут, а те команды, которые вы благополучно выполнили на LVM, вызовут тупик .
Но в продакшене под Linux вам теперь доступны все возможности ZFS vol. 28 - дедупликация, онлайн-сжатие, отказоустойчивость, гибкий менеджер томов (кстати, его можно использовать отдельно) и т. д. В общем, удачи и успехов вам! Теги: #linux #Системное администрирование #Настройка Linux
-
Acer Aspire As3820Tg-333G32Mn Статья
19 Oct, 24 -
Что Такое Блог И Как Вы Его Используете?
19 Oct, 24 -
Почему Я Не Уезжаю Из Страны?
19 Oct, 24 -
Конфетти На Холсте
19 Oct, 24 -
Cms.net
19 Oct, 24 -
Комментирование Кода На Русском Языке
19 Oct, 24
